Re: [PATCH 1/3] [RFC] clk: introduce clk_associate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux