On Tue, Nov 19, 2013 at 02:03:21AM +0000, Kuninori Morimoto wrote:
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.
I would be happier if we could unify the common clock infrastructure, it would make this kind of thing a lot lessy messy. However, I'm not against the system-clock-frequency property for now.
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
Sorry for the confusion, I'll try to be less ambiguous in future :)
What I was trying to get at here is that if there is neither a clock or a system-clock-frequency property in the device tree, dai->sysclk will not have been initialised in this path. Is this a valid case, and will dai->sysclk have a well-defined, sane value?
Thanks, Mark.