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. -- 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
