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

[Saravana Kannan]

On 04/27/2011 09:31 PM, Jean-Christophe PLAGNIOL-VILLARD 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.
> in the map_io  I need to init the gpio drivers

Why? Are you under the impression that GPIO is IO and hence needs to be 
mapped by map_io?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.