Questions about MX6Q SSI in I2S slave mode

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Questions about MX6Q SSI in I2S slave mode

1,469件の閲覧回数
RobbieJiang
Contributor IV

Hi all,

I'm working to support WM8974 audio codec in MX6Q/Linux platform.

Similar to WM8962, the mono codec WM8974 is set as the clock master to output BLCK and FS to MX6Q SSI.

Allso WM8974 is set to work in I2S master mode, and MX6Q SSI works in I2S slave mode.

Here I have two questions.

1.

In MX6Q RM, section 61.8.1.4 "I2S mode" on page 5117 and page 5118,

"

In I2S slave mode(SSI_SCR[6:5]=10), the following settings are internally overridden by

the hardware:

• Normal mode is selected (SSI_SCR[3]=0)

• Tx frame sync length set to one-bit-long-frame (SSI_STCR[1]=1)

• Rx frame sync length set to one-bit-long-frame (SSI_SRCR[1]=1)

....

"

Here I can't understand why the FS length is set to "one-bit-long".

Because according to WM8974 or WM8962 data sheet,

when the audio codec works in I2S master mode,

it outputs the frame sync signal for both the left channel and the right channel,

and the length of frame sync for left / right channel data is "word-long"(e.g, 16/24/32 bits),

not "one-bit-long".

So why is the SSI  (in I2S slav mode) Tx/Rx frame sync length set to one-bit-long-frame,  instead of one-word-long-frame?

2.

According to the I2S specification,

during the low phase of frame sync signal, audio codec should transmit left channel data,

and during the high phase of FS, right channel data are transmitted.

But for mono codec such as wm8974, there is only one channel data.

Does it mean that there will be no data transmitted during one phase of FS?

Regards,

Robbie

ラベル(3)
0 件の賞賛
返信
2 返答(返信)

901件の閲覧回数
igorpadykov
NXP Employee
NXP Employee

Hi Robbie

1. actially SSI works in Normal mode, as RM states

"Normal mode is selected (SSI_SCR[3]=0)"

2. if wm8974 has only one channel data, the other will be filled

with data which puts wm8974 on that channel.

Best regards

igor

0 件の賞賛
返信

901件の閲覧回数
sinanakman
Senior Contributor III

Hi Robbie

I am not an expert on this but while I was working on

something similar my interpretation of :

frame sync length set to one-bit-long-frame (SSI_STCR[1]=1)

was that frame clock was changing state one bit before the

next frame. In my case I could see this on the scope and it

was fine for the driver. I hope this helps and  is related to what

you are asking.

Regards

Sinan Akman

0 件の賞賛
返信