From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
Date: Mon, 12 Dec 2011 15:15:20 -0800 [thread overview]
Message-ID: <20111212231519.GK32251@atomide.com> (raw)
In-Reply-To: <201112130005.35386.jkrzyszt@tis.icnet.pl>
* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 14:36]:
> (adding Greg Kroah-Hartman and linux-serial at vger.kernel.org to Cc:)
>
> On Monday 12 of December 2011 at 19:04:56, Tony Lindgren wrote:
> > * Janusz Krzysztofik <jkrzyszt@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, 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 detected, while
> consecutive open() response times may not be so critical. Perhaps Greg
> or another serial guru can shed some more light on this.
>
> But this way or another, we are talking about dirty hacks here IMHO.
Might be worth checking if some board specific __initcall helps here
too?
Regards,
Tony
next prev parent reply other threads:[~2011-12-12 23:15 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-11 20:11 [PATCH 00/10] ARM: OMAP1: ams-delta: replace custom I/O with GPIO Janusz Krzysztofik
2011-12-11 20:11 ` [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore Janusz Krzysztofik
2011-12-12 18:04 ` Tony Lindgren
2011-12-12 23:05 ` Janusz Krzysztofik
2011-12-12 23:15 ` Tony Lindgren [this message]
2011-12-12 23:44 ` Janusz Krzysztofik
2011-12-12 23:55 ` Tony Lindgren
2011-12-13 0:15 ` Janusz Krzysztofik
2011-12-14 13:10 ` Janusz Krzysztofik
2011-12-14 18:21 ` Tony Lindgren
2011-12-14 20:07 ` Janusz Krzysztofik
2011-12-14 22:10 ` Tony Lindgren
2011-12-14 11:13 ` Janusz Krzysztofik
2011-12-11 20:12 ` [PATCH 02/10] ARM: OMAP1: ams-delta: Convert latches to basic_mmio_gpio Janusz Krzysztofik
2011-12-11 20:12 ` [PATCH 03/10] ARM: OMAP1: ams-delta: Supersede custom led device by leds-gpio Janusz Krzysztofik
2011-12-11 20:12 ` [PATCH 04/10] LED: Drop leds-ams-delta driver Janusz Krzysztofik
2011-12-11 20:12 ` [PATCH 05/10] MTD: NAND: ams-delta: Use GPIO instead of custom I/O Janusz Krzysztofik
2011-12-11 20:12 ` [PATCH 06/10] ARM: OMAP1: ams-delta: Use GPIO API in modem setup Janusz Krzysztofik
2011-12-11 20:12 ` [PATCH 07/10] ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API Janusz Krzysztofik
2011-12-12 4:29 ` Mark Brown
2011-12-21 18:33 ` Liam Girdwood
2011-12-21 22:14 ` Janusz Krzysztofik
2011-12-22 9:25 ` Girdwood, Liam
2011-12-11 20:12 ` [PATCH 08/10] omapfb: lcd_ams_delta: Drive control lines over GPIO Janusz Krzysztofik
2011-12-12 11:24 ` Tomi Valkeinen
2011-12-11 20:12 ` [PATCH 09/10] input: serio: ams-delta: Toggle keyboard power " Janusz Krzysztofik
2011-12-12 8:18 ` Dmitry Torokhov
2011-12-11 20:12 ` [PATCH 10/10] ARM: OMAP1: ams-delta: Drop custom I/O functions Janusz Krzysztofik
2011-12-12 5:00 ` [PATCH 00/10] ARM: OMAP1: ams-delta: replace custom I/O with GPIO Jonathan McDowell
2011-12-19 23:08 ` [PATCH v2 0/7] " Janusz Krzysztofik
2011-12-19 23:08 ` [PATCH v2 2/7] ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio Janusz Krzysztofik
2011-12-20 0:06 ` Tony Lindgren
2011-12-20 0:59 ` Janusz Krzysztofik
2011-12-20 1:04 ` Tony Lindgren
2011-12-20 1:18 ` Janusz Krzysztofik
2011-12-20 2:13 ` Tony Lindgren
2011-12-20 2:24 ` [PATCH v2 2/7 v2] " Janusz Krzysztofik
2011-12-19 23:08 ` [PATCH v2 3/7] ARM: OMAP1: ams-delta: supersede custom led device by leds-gpio Janusz Krzysztofik
2011-12-19 23:08 ` [PATCH v2 4/7] LED: drop leds-ams-delta driver Janusz Krzysztofik
2011-12-19 23:08 ` [PATCH v2 5/7] MTD: NAND: ams-delta: use GPIO instead of custom I/O Janusz Krzysztofik
2011-12-21 19:12 ` Tony Lindgren
2011-12-21 19:45 ` Janusz Krzysztofik
2011-12-21 20:56 ` Artem Bityutskiy
2011-12-19 23:08 ` [PATCH v2 6/7] omapfb: lcd_ams_delta: drive control lines over GPIO Janusz Krzysztofik
2011-12-19 23:08 ` [PATCH v2 7/7] input: serio: ams-delta: toggle keyboard power " Janusz Krzysztofik
2011-12-20 22:10 ` [PATCH] " Janusz Krzysztofik
2011-12-21 19:09 ` Tony Lindgren
2011-12-21 19:55 ` Janusz Krzysztofik
2011-12-22 17:45 ` Dmitry Torokhov
2011-12-22 18:06 ` Tony Lindgren
[not found] ` <83e934adfc691b347534edb7788a67ab2e6bd7e1.1324331816.git.jkrzyszt@tis.icnet.pl>
2011-12-19 23:28 ` [PATCH v2 1/7][RESEND] ARM: OMAP1: ams-delta: register latch dependent devices later Janusz Krzysztofik
2011-12-20 18:06 ` Tony Lindgren
2011-12-20 20:34 ` Janusz Krzysztofik
2011-12-20 20:57 ` Tony Lindgren
2011-12-20 20:40 ` Russell King - ARM Linux
2011-12-20 20:51 ` [alsa-devel] " Janusz Krzysztofik
2011-12-20 21:54 ` [PATCH v2 1/7 v2] " Janusz Krzysztofik
2011-12-21 19:08 ` Tony Lindgren
2011-12-21 19:51 ` Janusz Krzysztofik
2011-12-21 20:07 ` Tony Lindgren
2011-12-22 10:39 ` Janusz Krzysztofik
2011-12-22 11:08 ` Jarkko Nikula
2011-12-22 11:10 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111212231519.GK32251@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).