topic Re: sai1 bit clock and frame sync slave? in i.MX Processors

sai1 bit clock and frame sync slave?

johnadamson — Thu, 28 Mar 2019 13:07:16 GMT

I have hacked the fsl_sai.c driver to support 8-frame tdm on sai1 as a bit clock and frame sync master and successfully drove an AKM4458 eval board with the imx8mq eval board. My next step is to configure the imx8mq eval board as frame sync and bit clock slave, but after making the appropriate changes, I get nothing. Writes to the pcm device in ALSA eventually error out with a non-descript "I/O error", and it appears that the sai1 driver irq is never entered. I can see fsl_sai_trigger being called and the BCD bit in TCR2 and FSD bit in TCR4 appear to be cleared. I've tried both TX async, RX sync (sync to TX clock), and TX async RX async (async, TX should still use TX clock).

Does the pinctrl configuration need to be explicitly changed, or is the input/output direction automatically changed by changing the TCR registers? If there's something about the pinctrl configuration that has to change, I either didn't find it or didn't understand it enough to change it properly.

BCLK and FS signals look fine on the EVK as supplied by the external hardware.

Is there something else that must be done in software or the kernel configuration to change a working SAI1 clock master to a clock slave ?

There's something a bit odd about that trigger function, also. The original code:

* sets FIFO request DMA enable

* sets Transmitter enable (FSL_SAI_CSR_TERE)

* sets FSL_SAI_CSR_SE, which maps to bit 30. The documentation I have (Rev.0, 1/2018) shows this as "reserved"!

* sets TERE for the opposite side (TX/RX) if in sync mode

* sets some additional interrupt enable bits.

The ordering seems odd to me. Shouldn't everything be set up including the interrupt enables BEFORE enabling the transmitter? And what's up with the reserved bit? At first I thought that might be a typo for _SR, but if that were the case, there'd have to be a clear to go along with the set, and I'd also think that it would have to come first.

Any hints would be appreciated,

John

Re: sai1 bit clock and frame sync slave?

johnadamson — Thu, 28 Mar 2019 18:51:35 GMT

and an add-on question that may be even more basic...can the SAI1_TXC (sai_tx_bclk, ball E1) even BE configured as an input/slave for the imx8mq ?

I'm looking at the i.MX Pins Tool (v5) for the fsl-imx8mq-evk.mex, and while SAI1_TXFS is shown as an input/output, SAI1_TXC is shown as output, and the tool tip text helpfully tells me that the pin "Direction is not configurable for teh selected pin and peripheral."

I thought of using synchronous mode and clock swap, but the pins tool says the same thing about SAI1_RXC.

John

Re: sai1 bit clock and frame sync slave?

igorpadykov — Fri, 29 Mar 2019 05:24:14 GMT

Hi John

Bit Clock Direction can be set by BCD bit SAI Transmit Configuration 2 Register (TCR2) and

described in sect.SAI Transmit Configuration 2 Register (TCR2) i.MX8MDQ Reference Manual.

According to linux device tree sai documentation there is no slave option:

fsl-sai.txt\sound\bindings\devicetree\Documentation - linux-imx - i.MX Linux kernel

seems it is hardcoded in driver like sai->slave_mode[tx] :

fsl_sai.c\fsl\soc\sound - linux-imx - i.MX Linux kernel

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: sai1 bit clock and frame sync slave?

johnadamson — Fri, 29 Mar 2019 13:08:29 GMT

Thanks, igor,

Referring to IMX8MDQLQRM.pdf, 8.2.4.248 SW_PAD_CTL_PAD_SAI1_TXC SW PAD Control Register
(IOMUXC_SW_PAD_CTL_PAD_SAI1_TXC) can you advise on the correct settings for this register if I want to use the pin as an input?

And out of curiosity, can you explain why 8.2.4.247 SW_PAD_CTL_PAD_SAI1_TXFS SW PAD Control Register
(IOMUXC_SW_PAD_CTL_PAD_SAI1_TXFS) has an additional set of available bits (VSEL) ?

John

Re: sai1 bit clock and frame sync slave?

johnadamson — Fri, 29 Mar 2019 20:58:44 GMT

Found it.

In the devicetree binary, sai1grp_pcm (and sai1grp_pcm_b2m), there are two lines:
MX8MQ_IOMUXC_SAI1_TXFS_SAI1_TX_SYNC 0xd6
MX8MQ_IOMUXC_SAI1_RXD7_SAI1_TX_SYNC 0xd6

If I understand this correctly, this is defining two pads as both being the SAI frame sync. Not a problem (apparently) when the IMX8 is frame sync master, frame sync still shows up on SAI1_TXFS...but a big problem when the IMX8 is frame sync slave and the frame sync is only being supplied on SAI1_TXFS.

Is there a good place to post a patch to the device tree for the eval board? The meta-freescale list? Is there any disagreement that having two pads assigned to the same signal is a bad thing?

For completeness...

Does the pinctrl configuration need to be explicitly changed, or is the input/output direction automatically changed by changing the TCR registers? No, the input/output direction is automatically changed by changing the TCR registers. Assuming there aren't bugs in the pinctrl configuration to begin with.

Is there something else that must be done in software or the kernel configuration to change a working SAI1 clock master to a clock slave ? Nope, the TCR register bits for BCD and FSD are sufficient.

... sets FSL_SAI_CSR_SE, which maps to bit 30. The documentation I have (Rev.0, 1/2018) shows this as "reserved"! No clue, but commenting out the line appears to have no detrimental effect.

John

Re: sai1 bit clock and frame sync slave?

gabrielrivas — Wed, 09 Sep 2020 22:11:02 GMT

Is this TDM configuration possible on an SAI port other than SAI1? I have been trying the same as described here on SAI2 and can't get more than a single channel on the TDM frame.

Re: sai1 bit clock and frame sync slave?

injaneer1 — Wed, 02 Dec 2020 20:58:40 GMT

Could you share your DTS and Changes to make the SAI a master for frame and bit clock. I am trying to do the same for a TI chipset that needs to be the slave codec.

Thanks,

Chris