Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Sunday 11 of December 2011 at 21:11:59, Janusz Krzysztofik wrote:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Please ignore this patch, I'm going to submit a replacement, based on an
alternative approach suggested by Tony.
Thanks,
Janusz
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 4e24436..a6eaf38 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -528,7 +528,7 @@ static int __init bgpio_platform_init(void)
{
return platform_driver_register(bgpio_driver);
}
-module_init(bgpio_platform_init);
+postcore_initcall(bgpio_platform_init);
static void __exit bgpio_platform_exit(void)
{
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111214 04:40]: On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Sounds better for sure than what we currently have :) Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
(adding Mark Brown and Liam Girdwood - regulator experts - to Cc:) On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111214 04:40]: On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Sounds better for sure than what we currently have :) Hmm, better doesn't necessarily mean good enough... I forgot about the sound device, which shares its latch based GPIO pins with the modem, so should be registered after the modem. To make things still more complicated, one of those GPIO pins provides power to both devices, so a still better solution I'd like to introduce would be a GPIO controlled regulator device which feeds both the modem and the sound card with power. I've had a look at both generic regulator drivers, fixed.c and gpio- regulator.c, both controlling devices over GPIO pins, and found those drivers registered at subsys_initcall level, calling gpio_request*() at probe time. Then again, we would need that base_mmio_gpio driver already registered before subsys_initcall. Any suggestions? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111214 11:36]: (adding Mark Brown and Liam Girdwood - regulator experts - to Cc:) On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111214 04:40]: On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Sounds better for sure than what we currently have :) Hmm, better doesn't necessarily mean good enough... I forgot about the sound device, which shares its latch based GPIO pins with the modem, so should be registered after the modem. To make things still more complicated, one of those GPIO pins provides power to both devices, so a still better solution I'd like to introduce would be a GPIO controlled regulator device which feeds both the modem and the sound card with power. I've had a look at both generic regulator drivers, fixed.c and gpio- regulator.c, both controlling devices over GPIO pins, and found those drivers registered at subsys_initcall level, calling gpio_request*() at probe time. Then again, we would need that base_mmio_gpio driver already registered before subsys_initcall. Any suggestions? Sounds like yet another case for the deferred probe patches posted few weeks ago? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Usually moving things earlier and earlier is an endless loop
adding more and more nasty dependencies..
I'd rather see things getting initialized later as regular
device drivers so we have decent kernel error messages when
something goes wrong without having to enable debug_ll.
Regards,
Tony
Created against linux-3.2-rc5.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
drivers/gpio/gpio-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 4e24436..a6eaf38 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -528,7 +528,7 @@ static int __init bgpio_platform_init(void)
{
return platform_driver_register(bgpio_driver);
}
-module_init(bgpio_platform_init);
+postcore_initcall(bgpio_platform_init);
static void __exit bgpio_platform_exit(void)
{
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Let me try.
From patch 2/10 ARM: OMAP1: ams-delta: Convert latches to
basic_mmio_gpio:
@@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
+ platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
+ BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
Here I'm accessing the latches from ams_delta_init() (.init_machine
hook) with gpio_request_array() in order to:
a) clear their contents,
b) avoid accessing them, from ams_delta_latch_write(), never requested.
I could imagine clearing their contents with something like
*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;
instead, i.e., the way the old code used to, than accessing those GPIO
pins not requested, until they are finally requested by drivers updated
to use gpiolib with successive patche. Would this be acceptable?
However,
From patch 6/10 ARM: OMAP1: ams-delta: Use GPIO API in modem setup:
@@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void _modem_pm(struct uart_port *port, unsigned int state, unsigned
old)
+{
+ if (state != old)
+ gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(_MODEM_VIRT),
@@ -492,6 +488,7 @@ static struct plat_serial8250_port
ams_delta_modem_ports[] = {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = _modem_pm,
},
{ },
};
@@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device = {
},
};
+static struct gpio _modem_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ .flags = GPIOF_DIR_IN,
+ .label = modem_irq,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_nreset,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_codec,
+ },
+};
+
static int __init ams_delta_modem_init(void)
{
int err;
@@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, modem);
+ err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
if (err) {
- pr_err(Couldn't request gpio pin for modem\n);
+ pr_err(Couldn't request gpio pins for modem\n);
return err;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
-
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
return platform_device_register(ams_delta_modem_device);
}
Before the change, only one GPIO pin, that IRQ, driven with omap_gpio
driver which is registered from postcore, was gpio_request()ed. Now, two
more, gpio-generic driven pins, are also requested _and_ initialized in
order to make the modem accessible. The ams_delta_modem_init() is
installed with arch_initcall().
I could imagine initializing those modem pins the old way I've suggested
above, but I can see no good solution to delegate calling of that
gpio_request*() to the 8250 driver. For me, the only hook passed to the
driver with platform_data that can be suitable is the .pm hook. However,
when I tried to remove powering up the modem (rising up
AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only
from that .pm hook, the device was not detected, so I wonder if and when
that hook is called, and if it is before probe, then perhaps powering
up the modem chip from there is too late for the device to get up before
being examined. But then, maybe if we initialize the pin the old way
from arch init, it would be enough for the device to be
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 14:36]:
(adding Greg Kroah-Hartman and linux-ser...@vger.kernel.org to Cc:)
On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111211 11:41]:
This will allow boards with custom memory mapped GPIO ports to set up
and use those port pins while initializing devices from arch init.
Care to explain a bit more why you need to initialize those devices
early on?
Let me try.
From patch 2/10 ARM: OMAP1: ams-delta: Convert latches to
basic_mmio_gpio:
@@ -307,8 +487,8 @@ static void __init ams_delta_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
- /* Clear latch2 (NAND, LCD, modem enable) */
- ams_delta_latch2_write(~0, 0);
+ platform_add_devices(_latch_devices, ARRAY_SIZE(_latch_devices));
+ BUG_ON(gpio_request_array(_latch_gpios, ARRAY_SIZE(_latch_gpios)));
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
Here I'm accessing the latches from ams_delta_init() (.init_machine
hook) with gpio_request_array() in order to:
a) clear their contents,
b) avoid accessing them, from ams_delta_latch_write(), never requested.
I could imagine clearing their contents with something like
*(volatile __u8 *) AMS_DELTA_LATCH2_VIRT = 0;
*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = 0;
instead, i.e., the way the old code used to, than accessing those GPIO
pins not requested, until they are finally requested by drivers updated
to use gpiolib with successive patche. Would this be acceptable?
Thanks for explaining, it's best to use gpio calls instead :)
How about just add some __initcall into your board-*.c file to
do the required setups a bit later? Just make sure you exit
early if (!machine_is...) fails.
However,
From patch 6/10 ARM: OMAP1: ams-delta: Use GPIO API in modem setup:
@@ -482,6 +472,12 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void _modem_pm(struct uart_port *port, unsigned int state, unsigned
old)
+{
+ if (state != old)
+ gpio_set_value(AMS_DELTA_GPIO_PIN_MODEM_NRESET, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(_MODEM_VIRT),
@@ -492,6 +488,7 @@ static struct plat_serial8250_port
ams_delta_modem_ports[] = {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = _modem_pm,
},
{ },
};
@@ -504,6 +501,24 @@ static struct platform_device ams_delta_modem_device =
{
},
};
+static struct gpio _modem_gpios[] __initconst = {
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ .flags = GPIOF_DIR_IN,
+ .label = modem_irq,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_nreset,
+ },
+ {
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
+ .flags = GPIOF_OUT_INIT_HIGH,
+ .label = modem_codec,
+ },
+};
+
static int __init ams_delta_modem_init(void)
{
int err;
@@ -515,16 +530,11 @@ static int __init ams_delta_modem_init(void)
ams_delta_modem_ports[0].irq =
gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
- err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, modem);
+ err = gpio_request_array(_modem_gpios, ARRAY_SIZE(_modem_gpios));
if (err) {
- pr_err(Couldn't request gpio pin for modem\n);
+ pr_err(Couldn't request gpio pins for modem\n);
return err;
}
- gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
-
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
return platform_device_register(ams_delta_modem_device);
}
Before the change, only one GPIO pin, that IRQ, driven with omap_gpio
driver which is registered from postcore, was gpio_request()ed. Now, two
more, gpio-generic driven pins, are also requested _and_ initialized in
order to make the modem accessible. The ams_delta_modem_init() is
installed with arch_initcall().
I could imagine initializing those modem pins the old way I've suggested
above, but I can see no good solution to delegate calling of that
gpio_request*() to the 8250 driver. For me, the only hook passed to the
driver with platform_data that can be suitable is the .pm hook. However,
when I tried to remove powering up the modem (rising up
AMS_DELTA_GPIO_PIN_MODEM_NRESET) from the arch init and do this only
from that .pm hook, the device was not detected,
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [111212 15:13]: On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: Might be worth checking if some board specific __initcall helps here too? If I only knew how I could insert a board specific __initcall between two points from where the generic-gpio first, then the 8250 driver, are called. Any hints? Hmm, can't you do all that in the order you want in ams_delta_modem_init()? Or make that into a late_initcall so you have generic-gpio available? It seems that the pieces of code you're talking about don't need to be initialized early, just needs to be done in the right order to get things working. I think I've got it, thanks! Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
