Message ID | 1315192383.3092.260.camel@deadeye (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Ben Hutchings <ben@decadent.org.uk> writes: Hi, > The GPIO implementations for these two machines depend on gpiolib, > so they must not select GENERIC_GPIO directly. They're not calling gpiochip_add afaik so they should really only select GENERIC_GPIO. > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk> > --- > This hould fix the build failure seen here: > https://buildd.debian.org/status/fetch.php?pkg=linux-2.6&arch=armel&ver=3.1.0%7Erc4-1%7Eexperimental.1&stamp=1315007168 The problem here is that gpio_request_one has been added to the ads7846 driver but gpio_request_one is not defined in GENERIC_GPIO case (I guess that other (arm and non-arm) platforms may hit similar troubles with gpio_request_one. One quick fix would be to add a gpio_request_one function say in asm-generic/gpio.h. One other fix would be to define gpio_request_one and gpio_request_array in each machine/platform/... specific header. Don't know what's the best solution. Arnaud
On Mon, Sep 05, 2011 at 08:54:30AM +0200, Arnaud Patard wrote: > The problem here is that gpio_request_one has been added to the ads7846 > driver but gpio_request_one is not defined in GENERIC_GPIO case (I > guess that other (arm and non-arm) platforms may hit similar troubles > with gpio_request_one. One quick fix would be to add a gpio_request_one > function say in asm-generic/gpio.h. One other fix would be to define > gpio_request_one and gpio_request_array in each > machine/platform/... specific header. Don't know what's the best > solution. It looks like gpio_request_one() and gpio_request_array() have been added at the wrong level in the GPIO support code. There's two levels to the GPIO support code: 1. GENERIC_GPIO - for platforms which use the gpio_* interfaces. 2. GPIOLIB - for platforms which want the gpio library for handling multiple GPIO controllers. There is nothing GPIOLIB specific to the gpio_request_*() interfaces, so to put them in gpiolib.c and include/asm-generic/gpio.h seems rather silly. On the other hand, for the single ARM kernel project, we do need everyone to move to GPIOLIB so that the GPIO calls can be bound appropriately at runtime - which means this problem goes away. So probably the right solution is for IXP4xx etc to move over completely to gpiolib.
Russell King - ARM Linux <linux@arm.linux.org.uk> writes: Hi, > On Mon, Sep 05, 2011 at 08:54:30AM +0200, Arnaud Patard wrote: >> The problem here is that gpio_request_one has been added to the ads7846 >> driver but gpio_request_one is not defined in GENERIC_GPIO case (I >> guess that other (arm and non-arm) platforms may hit similar troubles >> with gpio_request_one. One quick fix would be to add a gpio_request_one >> function say in asm-generic/gpio.h. One other fix would be to define >> gpio_request_one and gpio_request_array in each >> machine/platform/... specific header. Don't know what's the best >> solution. > > It looks like gpio_request_one() and gpio_request_array() have been added > at the wrong level in the GPIO support code. > > There's two levels to the GPIO support code: > > 1. GENERIC_GPIO - for platforms which use the gpio_* interfaces. > 2. GPIOLIB - for platforms which want the gpio library for handling multiple > GPIO controllers. > > There is nothing GPIOLIB specific to the gpio_request_*() interfaces, so > to put them in gpiolib.c and include/asm-generic/gpio.h seems rather silly. > > On the other hand, for the single ARM kernel project, we do need everyone > to move to GPIOLIB so that the GPIO calls can be bound appropriately at > runtime - which means this problem goes away. So probably the right > solution is for IXP4xx etc to move over completely to gpiolib. I thought about it but I considered it was too late to do that. I don't think that moving to gpiolib u300/ixp4xx in -rc is a good idea. imho doing it for next kernel is better but this won't solve the build failure. Of course, you can tell me I'm plain wrong and I'll look at converting them to gpiolib asap. Then we'll need some testers as I don't have neither u300 nor ixp4xx systems. Also, moving u300/ixp4xx to gpiolib will solve the issue for ARM but I fear that other architectures may be affected by similar trouble. Arnaud
On Mon, Sep 5, 2011 at 5:12 AM, Ben Hutchings <ben@decadent.org.uk> wrote: > @@ -830,7 +830,7 @@ config ARCH_U300 > select GENERIC_CLOCKEVENTS > select CLKDEV_LOOKUP > select HAVE_MACH_CLKDEV > - select GENERIC_GPIO > + select ARCH_REQUIRE_GPIOLIB > help > Support for ST-Ericsson U300 series mobile platforms. Please don't do that, it really is no gpiolib implementation. In the archives you can find patches I already submitted switching the U300 GPIO over to use gpiolib. However it fell to the ground due to the shortage of a mechanism in gpiolib to configure pin bias. I could try to hack around it but it would still be a hack :-( I sent several patches trying to adress that issue, none have been accepted. So instead I venture into inventing the pin control subsystem which is intended to handle complex controllers like these. It is at version 7 right now. Thanks, Linus Walleij
On Mon, Sep 05, 2011 at 02:41:30PM +0200, Linus Walleij wrote: > On Mon, Sep 5, 2011 at 5:12 AM, Ben Hutchings <ben@decadent.org.uk> wrote: > > > @@ -830,7 +830,7 @@ config ARCH_U300 > > select GENERIC_CLOCKEVENTS > > select CLKDEV_LOOKUP > > select HAVE_MACH_CLKDEV > > - select GENERIC_GPIO > > + select ARCH_REQUIRE_GPIOLIB > > help > > Support for ST-Ericsson U300 series mobile platforms. > > Please don't do that, it really is no gpiolib implementation. > > In the archives you can find patches I already submitted switching > the U300 GPIO over to use gpiolib. [...] OK. But it doesn't seem to work without gpiolib either: CC [M] drivers/input/touchscreen/ads7846.o drivers/input/touchscreen/ads7846.c: In function 'ads7846_setup_pendown': drivers/input/touchscreen/ads7846.c:970:3: error: implicit declaration of function 'gpio_request_one' Ben.
On Mon, Sep 5, 2011 at 6:22 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > On Mon, Sep 05, 2011 at 02:41:30PM +0200, Linus Walleij wrote: >> On Mon, Sep 5, 2011 at 5:12 AM, Ben Hutchings <ben@decadent.org.uk> wrote: >> >> > @@ -830,7 +830,7 @@ config ARCH_U300 >> > select GENERIC_CLOCKEVENTS >> > select CLKDEV_LOOKUP >> > select HAVE_MACH_CLKDEV >> > - select GENERIC_GPIO >> > + select ARCH_REQUIRE_GPIOLIB >> > help >> > Support for ST-Ericsson U300 series mobile platforms. >> >> Please don't do that, it really is no gpiolib implementation. >> >> In the archives you can find patches I already submitted switching >> the U300 GPIO over to use gpiolib. > [...] > > OK. But it doesn't seem to work without gpiolib either: > > CC [M] drivers/input/touchscreen/ads7846.o > drivers/input/touchscreen/ads7846.c: In function 'ads7846_setup_pendown': > drivers/input/touchscreen/ads7846.c:970:3: error: implicit declaration of function 'gpio_request_one' Yes. I don't know a good way out of this really :-( I'll start looking for the bad ways out, like hacking the GPIO driver to do GPIOLIB in a not-so-elegant way. Yours, Linus Walleij
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f23712d..a1dbc4b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -477,7 +477,7 @@ config ARCH_IXP4XX depends on MMU select CLKSRC_MMIO select CPU_XSCALE - select GENERIC_GPIO + select ARCH_REQUIRE_GPIOLIB select GENERIC_CLOCKEVENTS select HAVE_SCHED_CLOCK select MIGHT_HAVE_PCI @@ -830,7 +830,7 @@ config ARCH_U300 select GENERIC_CLOCKEVENTS select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV - select GENERIC_GPIO + select ARCH_REQUIRE_GPIOLIB help Support for ST-Ericsson U300 series mobile platforms.
The GPIO implementations for these two machines depend on gpiolib, so they must not select GENERIC_GPIO directly. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> --- This hould fix the build failure seen here: https://buildd.debian.org/status/fetch.php?pkg=linux-2.6&arch=armel&ver=3.1.0%7Erc4-1%7Eexperimental.1&stamp=1315007168 However, I have not yet tested it. Ben. arch/arm/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)