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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
