[alsa-devel] [PATCH v4] ASoC: simple-card: add Device Tree support
mark.rutland at arm.com
Wed Nov 20 17:24:03 CET 2013
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
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?
More information about the Alsa-devel