From: "ext David Brownell" <david-b@xxxxxxxxxxx>
Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
Date: Wed, 1 Oct 2008 09:15:45 -0700
> On Wednesday 01 October 2008, Felipe Balbi wrote:
> > > So mirroring "at91_clock_associate()" ... maybe this
> > > should be "omap_clock_associate()" not "clk_associate()".
> >
> > Well, I'm ok with that but I'd rather see clk_associate() moving to
> > clk api so anyone who needs that, could use it.
>
> Seems like that's an "implementor's interface" rather
> than a "user's interface".
>
> So something like a "clock library" (duck!) might be
> a good place for such a call... ;)
Or, this feature itself can be covered by 'virtual clock(vclk)'?
http://marc.info/?l=linux-omap&m=122066992729949&w=2
which means that,
in this case, if 'vclk' just has a single child, not multiple, it can
be used just as 'aliasing' of clock names, without touching the
contents of 'struct clk', since 'vclk' is a inhritance of 'struct clk'.
I think that the point here is how to __hide__ the real detail clock
information(names, numbers, functionalites and so on) from client
device drivers. Some driver may need to control multiple clocks at
once. Some may need a clock which has different names between omap1,
omap2/3 or target boards. Or some may need to control multiple clock
groups from the functional perspective. So I think that a *flexible*
infrastructure would be better to afford such requiments, keeping
'struct clk' as simple as possible.
Hiroshi DOYU
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
