[PATCH RFC] clk: add support for automatic parent handling

Richard Zhao richard.zhao at freescale.com
Sun Apr 24 22:03:49 EDT 2011

On Thu, Apr 21, 2011 at 01:35:42PM +0100, Mark Brown wrote:
> On Thu, Apr 21, 2011 at 02:20:22PM +0200, Thomas Gleixner wrote:
> > On Thu, 21 Apr 2011, Mark Brown wrote:
> > > There's nothing intrinsic about the concept of a clock which means that
> > > it needs to be memory mapped or have a particular set of registers for
> > > us to work with.  This sounds like something that ought to be factored
> > > out but it's not obvious to me that it should be part of the core struct.
> > Care to look over the various implementations and find out that a lot
> > of them look like:
> Please bear in mind that due to the fact that we've currently got one
> clock implementation per subarchitecture anything off-SoC has some
> serious barriers to implementation in kernel.  For the system management
> units you'd be looking at very new systems, this is a new development.
How many arch have off-soc clocks? Where's the source? 
At least for arm, nearly all is memory mapped clock registers. clk is free
to override, we just need abstract the most common things.

> > Just in about 100 variations of the theme. Which is basically the same
> > as we have in irq chip implementations. And I showed how much of these
> > things can be factored out when done right. And even if a particular
> > clock does not implement enable/disable calls, then having
> > regs.enable_reg around is not a problem.
> This is why I said "This sounds like something that ought to be factored
> out but it's not obvious to me that it should be part of the core
> struct" above - I agree strongly that we should have a generic memory
> mapped implementation which factors out all the redundant code you'd get
> for these clocks.
> > Because that's what we implement via container_of now. And we can add
> > such stuff which is obvious right away.
> That's exactly the sort of thing I'm suggesting.  You were asking for
> this to be part of struct clk itself, embedding the struct clk in a
> struct mm_clk (or whatever) and having standard ops for the mm_clk a
> much better abstraction.
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

More information about the linux-arm-kernel mailing list