Hi Mark Rutland
Thank you for your feedback
It means "if system doesn't support common clock". I will fix it
When you say "doesn't support common clock", you mean the code for that platform is incompatible with the common clock framework? It seems very messy to allow a Linux-internal implementation detail (which is expected to change) to leak into a binding...
Some CPU doesn't support common clock, like PowerPC (?) This is Mark (Brown) comment
-------------------- So, ideally. However we have to consider the fact that the clock API isn't reliably available makes this harder than it should be. Even among the DT using platforms at least PowerPC still uses a custom clock API. We could just use this as a carrot to push people to convert though. ---------------------
of_property_read_u32(np,"system-clock-frequency",&dai->sysclk);What it this isn't present?
If sysclk doesn't have common clock support
Huh? That's not what I asked.
What if the dt has neither a clock or a system-clock-frequency property?
OK, sorry for my English
This happen if cpu/codec was slave, not strange things. Please check "Example". in there, "simple-audio,codec" has clocks but, "simple-audio,cpu" doesn't have it, and "simple-audio,codec" has "bitclock-master" and "frame-master"; This case, codec chip creates audio play/capture clock from system clock, and "cpu" use it. This is the reason why the name is "system-clock-frequency" instead of "clock-frequency" The image is like this
clocks / +- simple card --+ system clock | |-> playback -------------+-[codec]--[cpu] | | |<- capture +----------------+
Best regards --- Kuninori Morimoto