[RFC PATCH] CLK: Allow parent clock and rate to be configured in DT.

[Sascha Hauer]

On Tue, Mar 26, 2013 at 12:12:22PM +0100, Martin Fuzzey wrote:
> On 25/03/13 14:29, Sascha Hauer wrote:
> >Put it differently. OpenBSD might have much better clock support.
> >Imagine it can dynamically figure out the correct esdhc
> >frequencies for different usecases on the fly. In this situation
> >it would be counterproductive if Linux requires static values for
> >these in the devicetree.
> It shouldn't *require* them.
> If they are in a separate subtree of the DT OpenBSD would be free to
> ignore them and use its better method.
> >>The cko case is even worse - due to a board design decision that
> >>clock needs to have
> >>a frequency suitable for supplying some external chip. We don't want
> >>board specific code in
> >>the platform clock code and we're trying to get away from board files...
> >The codec could be provided a phandle to the cko clk. This is hardware
> >description and is fine for putting into the devicetree.
> Sure but just the phandle isn't enough.
> We also need the frequency and the parent.
> 
> For the frequency the driver could, and maybe should, set it (and
> indeed I've submitted a patch for this for the sgtl5000 driver).
> 
> But IMHO it's not the driver's business to be setting the parent
> clock (the driver just gets a phandle and
> shouldn't know if it can be reparented).
> 
> Maybe if and when the clock framework learns how to reparent clocks
> during set_rate() this problem may go away but
> I'm not entirely comfortable with that - I'm sure there are cases
> where it will be better to manually specify the parent clock.
> 
> >I know that we currently have no place to put such information. There
> >recently was a similar discussion with CMA descriptions in the
> >devicetree and I remember several other discussions of the same type,
> >all of which ended at the dont-know-but-not-in-the-devicetree point.
> Yes, I looked up the CMA discussion which, AFAICT ended with a proposition
> to use chosen to which there was no reply :(
> 
> I quite understand (and agree with) not wanting to scatter linux
> specific configuration
> data all over the DT but, given that there are clearly usecases for
> this type of
> configuration,  I fail to see the conceptual difference between:
> 
> 1) Pure hardware DT plus a completely seperate "config-tree"
> 2) DT with a configuration node ("chosen" or probably better
> something like "linux-config")
> 
> Except that 1) requires more work to implement.
> Even if the DT parser and tooling were reused it would still require:
> * A means of passing another blob to the kernel
> * A means of providing the parsed data to drivers
> 
> Both of these are obtained "for free" with solution 2), whilst still
> retaining the
> separation of the tree into "hardware" and "configuration"
> 
> It would be possible for hardware vendors to ship the pure hardware
> part and then
> add the configuration node either at runtime in the bootloader or by
> a preprocessing
> tool "dtcat"?
> 
> Other OSs would simply ignore the "linux-config" node (and could add
> "bsd-config" node too)

I'm absolutely not against doing this. I'm only against introducing this
through the back door. I think we need a good place in the devicetree
where to put such configuration stuff and we need some agreement what
(and what not) should be there.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |