From mboxrd@z Thu Jan  1 00:00:00 1970
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 28 Apr 2011 06:31:43 +0200
Subject: [PATCH] clkdev: add support to lookup for early platform device
In-Reply-To: <20110428033808.GE13539@linux-sh.org>
References: <1303308314-3213-1-git-send-email-plagnioj@jcrosoft.com>
	<20110427084247.GK17290@n2100.arm.linux.org.uk>
	<20110427103145.GF29103@game.jcrosoft.org>
	<20110427104758.GG29103@game.jcrosoft.org>
	<20110427150057.GH29103@game.jcrosoft.org>
	<20110428020910.GA13539@linux-sh.org>
	<20110428024559.GK29103@game.jcrosoft.org>
	<20110428030817.GC13539@linux-sh.org>
	<20110428031704.GL29103@game.jcrosoft.org>
	<20110428033808.GE13539@linux-sh.org>
Message-ID: <20110428043143.GP29103@game.jcrosoft.org>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

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.