[alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver

[Mike Turquette]

Quoting Mark Rutland (2013-08-19 02:35:43)
> On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote:
> > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote:
> > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote:
> > > > > > > Also I would make this option required. Use a dummy clock for
> > > > > > > mux
> > > > > > > inputs that are grounded for a specific SoC.
> > > > > > 
> > > > > > Some clocks are not from CCM and we haven't defined in
> > > > > > imx6q-clk.txt,
> > > > > > so in most cases we can't provide a phandle for them, eg:
> > > > > > spdif_ext.
> > > > > > I think it's a bit hard to force it to be 'required'. An
> > > > > > 'optional'
> > > > > > looks more flexible to me and a default one is ensured even if
> > > > > > it's
> > > > > > missing.
> > > > > 
> > > > > <&clks 0> is the dummy clock. This can be used for all input clocks
> > > > > not
> > > > > defined by the SoC.
> > > > 
> > > > Where does this assumption come from? Is it documented anywhere?
> > > 
> > > This is how all i.MX clock bindings currently are. See
> > > Documentation/devicetree/bindings/clock/imx*-clock.txt
> > 
> > OK, thanks.
> > 
> > I guess we need some discussion on dummy clocks vs skipped clocks. I think 
> > we want some consistency on this, don't we?
> > 
> > If we really need a dummy clock, then we might also want a generic way to 
> > specify it.
> 
> What do we actually mean by a "dummy clock"? We already have bindings
> for "fixed-clock" and co friends describe relatively simple
> preconfigured clocks.

Some platforms have a fake clock which defines noops callbacks and
basically doesn't do anything. This is analogous to the dummy regulator
implementation. A central one could be registered by the clock core, as
is done by the regulator core.

I'll add this to the todo list.

Regards,
Mike

> 
> If a clock isn't actually wired, we shouldn't describe it at all, or
> we're describing what Linux wants to think rather than what the hardware
> actually is. That can easily be handled with clock-names.
> 
> Thanks,
> Mark.