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

[Magnus Damm]

On Thu, Apr 28, 2011 at 2:12 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj at jcrosoft.com> wrote:
> 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.
> How did you manage to get the clock for the earlytimer?

As you can see in the upstream SH-Mobile ARM code, the timer setup is
happening after the clocks have been initialized in the ->timer
callback in MACHINE_START()/MACHINE_END.

/ magnus