Bo Chen wrote:
with this piece of code, I reproduce your issue.
Now, I know the reason of this issue, work in oss mode, it will set the default clock to 8KHz, and then if change to other sample rate, for example 48KHz, the div is different, then it reports -EBUSY.
Indeed.
So, I think we won't change the ATMEL_SSC_CMR_DIV to ATMEL_SSC_TCMR_DIV and ATMEL_SSC_RCMR_DIV, as it will affect other users. We just deal with this situation in ATMEL_SSC_CMR_DIV block, check the direction, if the same direction change the div, then accept the change, otherwise, return -EBUSY.
Ok.
But I'm not sure it is possible to dig out the current direction in the .set_clkdiv callback? Perhaps the correct fix is to set the bits .symmetric_rates, .symmetric_channels and .symmetric_samplebits in the atmel_ssc_dai struct when the ssc dai is master? Then I expect that other mechanisms will kick in that will render the current CMR_DIV check pointless?
Is a dai driver allowed to change these symmetry bits after registration? Can they be set in the .set_sysclk callback? Perhaps in the ATMEL_SSC_CMR_DIV block itself? That callback should only be called when the dai is master, so that would be perfect...
Yes, the limitation would be a little bit more strict than today, but is it really common to require different modes on playback and capture?
Cheers, Peter