Re: [PATCH RFC v2 01/16] ARM: call clk_of_init from time_init

From: SÃren Brinkmann
Date: Wed Sep 04 2013 - 16:59:20 EST


Hi Sebastian,

On Wed, Sep 04, 2013 at 10:52:09PM +0200, Sebastian Hesselbarth wrote:
> On 09/04/2013 10:41 PM, SÃren Brinkmann wrote:
> >On Wed, Sep 04, 2013 at 09:32:24PM +0200, Sebastian Hesselbarth wrote:
> >[ ... ]
> >>For mach-zynq I prepared a patch set that brings it close to .init_time
> >>removal. I have pushed it to
> >> https://github.com/shesselba/linux-dove.git zynq-clk-init-v1
> >>and will maybe post a patch set after this one is done.
> >
> >I think Steffen had a similar approach and we turned it down:
> >Your proposal lets the clkc map the SLCR's registers. I think
> >that approach is not right. It might be okay now, since the
> >SLCR driver is pretty much a useless skeleton. But in general,
> >there is a driver for the SLCR which maps that register
> >region. No other driver should mess with it.
> >
> >Actually, one early version of my clkc looked pretty much like what you
> >propose now and we changed it because of above reason.
>
> Erm, passing the base address to clkc is less "mess with it" then
> get it from DT?
>
> Anyways, having a custom .init_time gives you full control over
> of_clk_init and clocksource_of_init back again thanks to your
> suggestion.
>
> I'll stop converting zynq and let you decide on your own ;)

As I said, currently it's rather messy and neither solution is perfect.
Steffen seemed to already have looked towards syscon and regmap, which
are probably the right ways of making the SLCR regs available to other users.
Sure, passing down the pointer is not perfect, but having two drivers
map the same memory region seems slightly worse to me. And it would even
fail for one driver if you properly used request_mem_region() and friends.

SÃren


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/