Hi Mark Thank you for your explanation > > I'm now confusing. We can set system clock on audio card, for example > > simple-card case, it is called as "system-clock-frequency". > > In my understanding, this "system clock" and above "master clock" are same clock. > > but "system clock" is fixed rate (= not related to audio clock in many cases). > > Because of this, some codec doesn't request synchronous between > > master clock <-> audio clock, but, some codec requests synchronous it. > > Am I wrong ?? > > A lot of CODECs can to varying degrees tolerate this but it will tend to > show up in performance numbers, it's often not immediately obvious just > from a listening test. Usually those that don't mind have a FLL or PLL > they're using to generate the actual audio master clock at a useful rate > for dividing down, or sometimes fancy digital logic to match things > up. > > It's not a problem to have this configurable, I'm just thinking it might > be better to have the default be the other way around so that we default > to synchronous but can turn that off if it's required. OK, I see. I checked existing DT, and default synchronous <-> asynchronous exchange seems no problem. So, synchronous will be default in v2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
