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

[Richard Zhao]

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.

Thanks
Richard
> 
> > 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
>