[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:38 Thu 28 Apr     , Paul Mundt wrote:
> On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:08 Thu 28 Apr     , Paul Mundt wrote:
> > > This is a non-argument until you demonstrate a use case where we have a
> > > reasonable expectation for the clock framework to be available and the
> > > slab allocator not.
> > > 
> > > If you're thinking about the SH earlyprintk case then I suggest you look
> > > at the sh-sci driver to see how we presently deal with the situation
> > > there.
> > the sh-sci driver expect the clock will enable for him
> > which did IIRC Magnus on sh-mobile
> > I do not want to do so
> > 
> > I've unfortunatly on at91 I use the early device during the map_io
> > 
> > so the slab is available and bootmem either
> > 
> Yes, on sh-sci we assume that the clock is supplied to the port that we
> are using for earlyprintk and we simply take over management of it via
> the clock framework when the rest of the driver core comes online.
> 
> Oddly enough, 100% of the time that we've wanted to have a serial console
> it's been on the same port as the boot loader, which has to do the
> initialization anyways. If you're using JTAG or something else for
> loading, you've already got to do register writes for setting up bus
> timings and the like, so it's not obvious why you can't set up some
> sensible defaults for the clock registers supplying your serial port,
> either.
> 
> On top of that, ARM also has its own earlyprintk and eartly uart debug
> macros available to you. If you're trying to bring more driver core stuff
> online before either of slab or bootmem are available to you outside of
> the context of the existing functionality: too bad. It's not worth the
> world of pain for a corner case of a corner case.
> 
> Again, until you explain concretely why you have this as a real use case
> that needs to be solved generically instead of some pointless theoretical
> wanking it's simply not possible to take this requirement seriously. This
> was the conclusion we came to when modelling the earlytimer and
> earlyprintk code for SH in the first place, and the burden of proof is on
> you to demonstrate why any of these things are insufficient for your
> platform.
in the map_io  I need to init the gpio drivers
and on AT91 we have between 3 and 5 pio bank which have different clock
and the resource for the gpio driver is soc specifc
so I switch the gpio driver to early device
so as the init of the gpio drivers I need to get the clock for each bank

as example on 9263
at91_gpio.0 use clock pioA
at91_gpio.1 use clock pioB
at91_gpio.2 use clock pioCDE
at91_gpio.3 use clock pioCDE
at91_gpio.4 use clock pioCDE

on 9g45
at91_gpio.0 use clock pioA
at91_gpio.1 use clock pioB
at91_gpio.2 use clock pioC
at91_gpio.3 use clock pioDE
at91_gpio.4 use clock pioDE

so I need to known the clock early if I want to be able to use the gpio
driver early

Best Regards,
J.