[PATCH] clkdev: add support to lookup for early platform device
Paul Mundt
lethal at linux-sh.org
Wed Apr 27 23:38:08 EDT 2011
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.
More information about the linux-arm-kernel
mailing list