[alsa-devel] CherryTrail SST firmware limitations query
(Sorry, re-sending as I wasn't subscribed to the alsa-devel mailing list on my previous attempt)
Hi Vinod
I am currently attempting to use the SSP0 port on an Intel X5-Z8300 SoC (Cherry Trail) with a new codec.
I have seen that you have committed SST firmware 'fw_sst_22a8.bin' and related SST audio soc drivers in the past, so I hope you don't mind if I ask you some questions about it here.
Primarily, I am wondering if there are any limitations imposed by that firmware binary that I need to be aware of. I haven't been able to find much information about what this firmware does or doesn't support.
For example, existing CHT SST machine drivers suggest that the PCM bit clock is fixed at 19.2MHz. Also, I am wondering if all SSP ports on the SoC are supported by that firmware, or if it is limited to just SSP2?
Are there any other limitations that I may need to be aware of in the firmware (or in the SSP back-end driver) when attempting to connect a new codec (TI PCM5122 initially) to SSP0.
Many thanks in advance for any help/advice you can provide.
Best regards, -Dan
On Thu, Jan 21, 2016 at 11:10:50PM +0000, Dan O'Donovan wrote:
(Sorry, re-sending as I wasn't subscribed to the alsa-devel mailing list on my previous attempt)
Hi Vinod
I am currently attempting to use the SSP0 port on an Intel X5-Z8300 SoC (Cherry Trail) with a new codec.
I have seen that you have committed SST firmware 'fw_sst_22a8.bin' and related SST audio soc drivers in the past, so I hope you don't mind if I ask you some questions about it here.
Primarily, I am wondering if there are any limitations imposed by that firmware binary that I need to be aware of. I haven't been able to find much information about what this firmware does or doesn't support.
That binary is not for CHT. Each Bin is specfic to a platform. I have the BYT and BSW versions, but not CHT
For example, existing CHT SST machine drivers suggest that the PCM bit clock is fixed at 19.2MHz.
Yes, the MCLK will be 19.2 here
Also, I am wondering if all SSP ports on the SoC are supported by that firmware, or if it is limited to just SSP2?
SSP2, for SSP0 we need to get a new version
Are there any other limitations that I may need to be aware of in the firmware (or in the SSP back-end driver) when attempting to connect a new codec (TI PCM5122 initially) to SSP0.
Bigger pole will be getting the firmware. Usually we support I2S and TDM modes
HTH
On 01/28/2016 04:24 PM, Vinod Koul wrote:
On Thu, Jan 21, 2016 at 11:10:50PM +0000, Dan O'Donovan wrote:
(Sorry, re-sending as I wasn't subscribed to the alsa-devel mailing list on my previous attempt)
Hi Vinod
I am currently attempting to use the SSP0 port on an Intel X5-Z8300 SoC (Cherry Trail) with a new codec.
I have seen that you have committed SST firmware 'fw_sst_22a8.bin' and related SST audio soc drivers in the past, so I hope you don't mind if I ask you some questions about it here.
Primarily, I am wondering if there are any limitations imposed by that firmware binary that I need to be aware of. I haven't been able to find much information about what this firmware does or doesn't support.
That binary is not for CHT. Each Bin is specfic to a platform. I have the BYT and BSW versions, but not CHT
For example, existing CHT SST machine drivers suggest that the PCM bit clock is fixed at 19.2MHz.
Yes, the MCLK will be 19.2 here
Also, I am wondering if all SSP ports on the SoC are supported by that firmware, or if it is limited to just SSP2?
SSP2, for SSP0 we need to get a new version
Are there any other limitations that I may need to be aware of in the firmware (or in the SSP back-end driver) when attempting to connect a new codec (TI PCM5122 initially) to SSP0.
Bigger pole will be getting the firmware. Usually we support I2S and TDM modes
Thanks very much for your reply, Vinod! That probably explains why I'm seeing clock signals from SSP0 but no audio data. Can you tell me who I could contact to request SST firmware for CHT with SSP0 support?
HTH
Are there any other limitations that I may need to be aware of in the firmware (or in the SSP back-end driver) when attempting to connect a new codec (TI PCM5122 initially) to SSP0.
Bigger pole will be getting the firmware. Usually we support I2S and TDM modes
Thanks very much for your reply, Vinod! That probably explains why I'm seeing clock signals from SSP0 but no audio data. Can you tell me who I could contact to request SST firmware for CHT with SSP0 support?
This doesn't make sense to me. To the best of my knowledge the firmware does support SSP0 but in a limited configuration compared to SSP0. It should work for regular 48kHz audio in I2S mode but not in TDM mode. If you see clock signals on SSP0 and no data then it's probably because the DSP routing controls are incorrect. The best fix would be to use SSP2 really to get all the functionality.
On 01/28/2016 06:05 PM, Pierre-Louis Bossart wrote:
Are there any other limitations that I may need to be aware of in the firmware (or in the SSP back-end driver) when attempting to connect a new codec (TI PCM5122 initially) to SSP0.
Bigger pole will be getting the firmware. Usually we support I2S and TDM modes
Thanks very much for your reply, Vinod! That probably explains why I'm seeing clock signals from SSP0 but no audio data. Can you tell me who I could contact to request SST firmware for CHT with SSP0 support?
This doesn't make sense to me. To the best of my knowledge the firmware does support SSP0 but in a limited configuration compared to SSP0. It should work for regular 48kHz audio in I2S mode but not in TDM mode. If you see clock signals on SSP0 and no data then it's probably because the DSP routing controls are incorrect. The best fix would be to use SSP2 really to get all the functionality.
Hi Pierre-Louis,
I've configured SSP0 for 48kHz audio in I2S mode, and I think the routing is correct (but would appreciate confirmation):
[Stream:'Headset Playback' -> 'media1_in'] -> ['media0_out mix 0' -> 'media0_out' -> 'pcm0_in'] -> ['codec_out0 mix 0' -> 'codec_out0'] -> [Stream:'ssp0 Tx']
To see the clocks on SSP0, I found that I had to replace 'SSP_CODEC' (3) with 0 wherever it was used in sound/soc/intel/atom/sst-atom-controls.c
Unfortunately, our board is about to go into mass production so my chances of getting it changed to SSP2 are very slim. Do you think it might be possible for us to get SSP0 working for I2S audio?
participants (3)
-
Dan O'Donovan
-
Pierre-Louis Bossart
-
Vinod Koul