Re: [PATCH V5 2/4] arm/dt: add very basic dts file for babbage board

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Fri, Mar 18, 2011 at 03:54:32PM +0800, Shawn Guo wrote:
> On Thu, Mar 17, 2011 at 11:43:34PM -0600, Grant Likely wrote:
> > On Fri, Mar 18, 2011 at 09:49:17AM +0800, Shawn Guo wrote:
> > > On Thu, Mar 17, 2011 at 10:42:38AM -0600, Grant Likely wrote:
> > > > On Wed, Mar 16, 2011 at 11:51:39PM +0800, Jason Liu wrote:
> > > [...]
> > > > > +	aips@83f00000 {
> > > > > +		#address-cells = <1>;
> > > > > +		#size-cells = <1>;
> > > > > +		compatible = "simple-bus";
> > > > > +		ranges = <0x0 0x83f00000 0x100000>;
> > > > > +
> > > > > +		fec@ec000 {
> > > > > +			compatible = "fsl,imx51-fec";
> > > > > +			reg = <0xec000 0x1000>;
> > > > > +			interrupts = <0x57>;
> > > > > +			fec_clk-clock = <&fec_clk>, "fec";
> > > > 
> > > > Unfortunately we're leaking Linux implementation details here by
> > > > needing to use the name "fec_clk".  This will require some more
> > > > thought on the best way to handle (but I'm not asking you to change
> > > > anything yet).
> > > > 
> > > This constraint comes from function of_clk_get in drivers/of/clock.c:
> > > 
> > > struct clk *of_clk_get(struct device *dev, const char *id)
> > > {
> > > 	[...]
> > >         dev_dbg(dev, "Looking up %s-clock from device tree\n", id);
> > > 
> > >         snprintf(prop_name, 32, "%s-clock", id ? id : "bus");
> > >         prop = of_get_property(dev->of_node, prop_name, &sz);
> > > 	[...]
> > > }
> > > 
> > > The 'id' here is clk_lookup->con_id.  If we choose to use some fixed
> > > prop name here, the name leaking Linux implementation like 'fec_clk'
> > > will not need to be there.
> > > 
> > > What about fixing the name as 'bus-clock' used by the current
> > > implementation, or 'module-clock', or anything you can think of
> > > better?
> > 
> > Yeah, I though about that, but I'm being very careful about hard
> > coding anything in the core DT code because every platform seems to
> > want something different here, or want a different set of clocks.  I
> > don't have a good solution for this yet.
> > 
> We are not hard coding anything but a property name here.  We are hard
> coding property name everywhere in dt code, aren't we?

In this case, each platform seems to have a different naming
conventions for the set of clocks, and a different number of clocks.
I'm not willing to hard code the translations until I've got a better
understanding of the different needs between platforms.

What I might do is allow platform code to supply the core code with a
clock name translation table which might solve the problem nicely.

g.