All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Russell King <linux@arm.linux.org.uk>,
	Dmitry Artamonow <mad_soft@inbox.ru>
Subject: Re: [PATCH 0/9] ARM: sa1100: Rework IRQ handling
Date: Tue, 19 Nov 2013 19:17:46 +0400	[thread overview]
Message-ID: <528B811A.1030501@gmail.com> (raw)
In-Reply-To: <CACRpkdZU3_EqhBjV68+okJwh7QONuxWVjKkrUO4PkwJhKrP+mQ@mail.gmail.com>

On 11/19/2013 05:00 PM, Linus Walleij wrote:
> On Fri, Nov 15, 2013 at 9:47 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>
>> This is a considerable rework of my previous attempt to update sa1100 irq
>> handling. IRQ code is updated to support MULTI_IRQ_HANDLER and is mostly
>> prepared to be converted to irqchip driver (if the need arises in future).
>> I have integrated idea of Linus Waleij to use irq domains. GPIO irq handling
>> is split to gpio driver, which also undergo an update/rewrite.
>
> Overall this is looking very nice. However when I apply this on top
> of (a working and booting) mainline HEAD, I get this:

[skipped]

> This is caused by the patch:
> "ARM: sa1100: convert gpio driver to be a proper platform driver"
>
> The reason: UARTs are initialized *very* early and the UART quirk used on the
> h3600 is using GPIOs through the .set_mctrl hooks back into
> arch/arm/mach-sa1100/h3xxx.c functions
> h3xxx_uart_set_mctrl()
> h3xxx_uart_get_mctrl()
>
> And that happens before the GPIO driver gets registered -> crash.

That is not the issue. The real issue is h3xxx using those gpio's 
without previously calling gpio_request. Unfortunately sa1100 driver 
doesn't have a good place to request gpios. When faced this problem 
during locomo refactoring, I ended up with the following piece of code:

========== Cut here ============
static struct gpio collie_uart_gpio[] = {
         { COLLIE_GPIO_CTS, GPIOF_IN, "CTS" },
         { COLLIE_GPIO_RTS, GPIOF_OUT_INIT_LOW, "RTS" },
         { COLLIE_GPIO_DTR, GPIOF_OUT_INIT_LOW, "DTR" },
         { COLLIE_GPIO_DSR, GPIOF_IN, "DSR" },
};

static bool collie_uart_gpio_ok;

static void collie_uart_set_mctrl(struct uart_port *port, u_int mctrl)
{
         if (!collie_uart_gpio_ok) {
                 int rc = gpio_request_array(collie_uart_gpio,
                                 ARRAY_SIZE(collie_uart_gpio));
                 if (rc)
                         printk("collie_uart_set_mctrl: gpio request 
%d\n", rc);
                 else
                         collie_uart_gpio_ok = true;
         }

         if (collie_uart_gpio_ok) {
                 gpio_set_value(COLLIE_GPIO_RTS, !(mctrl & TIOCM_RTS));
                 gpio_set_value(COLLIE_GPIO_DTR, !(mctrl & TIOCM_DTR));
         }
}
=========== Cut here ===============

Same goes for get_mctr().

Russell, Linus, what do you think about the previous solution?


Another solution would be to make sa1100 distinguish between console 
output (where it doesn't have to control rts/dtr) and normal uart work 
(where 'modem' lines should be used).

I have the feeling that sa11x0-serial driver would need to be somewhat 
modified at least. I understand the conception behind unified 
"port_fns", but I think that those should be split to a per-port 
platform data.

> This is why the device is registered from the machine in the first place
> I think.
>
> I don't know what the proper solution is, but I think you can keep most
> of the platform device conversion if you also keep the special initialization
> call.


That would be possible solution if we can't come up with usefull way to 
handle h3xxx (and collie) gpios.

-- 
With best wishes
Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: dbaryshkov@gmail.com (Dmitry Eremin-Solenikov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/9] ARM: sa1100: Rework IRQ handling
Date: Tue, 19 Nov 2013 19:17:46 +0400	[thread overview]
Message-ID: <528B811A.1030501@gmail.com> (raw)
In-Reply-To: <CACRpkdZU3_EqhBjV68+okJwh7QONuxWVjKkrUO4PkwJhKrP+mQ@mail.gmail.com>

On 11/19/2013 05:00 PM, Linus Walleij wrote:
> On Fri, Nov 15, 2013 at 9:47 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>
>> This is a considerable rework of my previous attempt to update sa1100 irq
>> handling. IRQ code is updated to support MULTI_IRQ_HANDLER and is mostly
>> prepared to be converted to irqchip driver (if the need arises in future).
>> I have integrated idea of Linus Waleij to use irq domains. GPIO irq handling
>> is split to gpio driver, which also undergo an update/rewrite.
>
> Overall this is looking very nice. However when I apply this on top
> of (a working and booting) mainline HEAD, I get this:

[skipped]

> This is caused by the patch:
> "ARM: sa1100: convert gpio driver to be a proper platform driver"
>
> The reason: UARTs are initialized *very* early and the UART quirk used on the
> h3600 is using GPIOs through the .set_mctrl hooks back into
> arch/arm/mach-sa1100/h3xxx.c functions
> h3xxx_uart_set_mctrl()
> h3xxx_uart_get_mctrl()
>
> And that happens before the GPIO driver gets registered -> crash.

That is not the issue. The real issue is h3xxx using those gpio's 
without previously calling gpio_request. Unfortunately sa1100 driver 
doesn't have a good place to request gpios. When faced this problem 
during locomo refactoring, I ended up with the following piece of code:

========== Cut here ============
static struct gpio collie_uart_gpio[] = {
         { COLLIE_GPIO_CTS, GPIOF_IN, "CTS" },
         { COLLIE_GPIO_RTS, GPIOF_OUT_INIT_LOW, "RTS" },
         { COLLIE_GPIO_DTR, GPIOF_OUT_INIT_LOW, "DTR" },
         { COLLIE_GPIO_DSR, GPIOF_IN, "DSR" },
};

static bool collie_uart_gpio_ok;

static void collie_uart_set_mctrl(struct uart_port *port, u_int mctrl)
{
         if (!collie_uart_gpio_ok) {
                 int rc = gpio_request_array(collie_uart_gpio,
                                 ARRAY_SIZE(collie_uart_gpio));
                 if (rc)
                         printk("collie_uart_set_mctrl: gpio request 
%d\n", rc);
                 else
                         collie_uart_gpio_ok = true;
         }

         if (collie_uart_gpio_ok) {
                 gpio_set_value(COLLIE_GPIO_RTS, !(mctrl & TIOCM_RTS));
                 gpio_set_value(COLLIE_GPIO_DTR, !(mctrl & TIOCM_DTR));
         }
}
=========== Cut here ===============

Same goes for get_mctr().

Russell, Linus, what do you think about the previous solution?


Another solution would be to make sa1100 distinguish between console 
output (where it doesn't have to control rts/dtr) and normal uart work 
(where 'modem' lines should be used).

I have the feeling that sa11x0-serial driver would need to be somewhat 
modified at least. I understand the conception behind unified 
"port_fns", but I think that those should be split to a per-port 
platform data.

> This is why the device is registered from the machine in the first place
> I think.
>
> I don't know what the proper solution is, but I think you can keep most
> of the platform device conversion if you also keep the special initialization
> call.


That would be possible solution if we can't come up with usefull way to 
handle h3xxx (and collie) gpios.

-- 
With best wishes
Dmitry

  reply	other threads:[~2013-11-19 15:17 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-15  8:47 [PATCH 0/9] ARM: sa1100: Rework IRQ handling Dmitry Eremin-Solenikov
2013-11-15  8:47 ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 1/9] ARM: sa1100 collie: use gpio-charger instead of pda-power Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 2/9] ARM: locomo: don't clobber chip data for chained irq Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 3/9] ARM: sa1100: switch to MULTI_IRQ_HANDLER Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 4/9] ARM: sa1100: convert gpio driver to be a proper platform driver Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-19 10:08   ` Linus Walleij
2013-11-19 10:08     ` Linus Walleij
2013-11-15  8:47 ` [PATCH 5/9] ARM: sa1100: add platform functions to handle PWER settings Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 6/9] ARM: sa1100: enable IRQ domains Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 7/9] ARM: sa1100: move gpio irq handling to GPIO driver Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-22 17:45   ` Russell King - ARM Linux
2013-11-22 17:45     ` Russell King - ARM Linux
2013-11-22 19:46     ` Dmitry Eremin-Solenikov
2013-11-22 19:46       ` Dmitry Eremin-Solenikov
2013-11-22 20:02       ` Russell King - ARM Linux
2013-11-22 20:02         ` Russell King - ARM Linux
2013-11-22 21:20         ` Dmitry Eremin-Solenikov
2013-11-22 21:20           ` Dmitry Eremin-Solenikov
2013-11-15  8:47 ` [PATCH 8/9] ARM: sa1100: move per-IRQ PWER settings to core code Dmitry Eremin-Solenikov
2013-11-15  8:47   ` Dmitry Eremin-Solenikov
2013-11-15  8:48 ` [PATCH 9/9] ARM: sa1100: refactor irq driver Dmitry Eremin-Solenikov
2013-11-15  8:48   ` Dmitry Eremin-Solenikov
2013-11-19 13:00 ` [PATCH 0/9] ARM: sa1100: Rework IRQ handling Linus Walleij
2013-11-19 13:00   ` Linus Walleij
2013-11-19 15:17   ` Dmitry Eremin-Solenikov [this message]
2013-11-19 15:17     ` Dmitry Eremin-Solenikov
2013-11-19 20:24     ` Linus Walleij
2013-11-19 20:24       ` Linus Walleij
2013-11-20  0:20       ` Russell King - ARM Linux
2013-11-20  0:20         ` Russell King - ARM Linux
2013-11-20  0:45         ` Dmitry Eremin-Solenikov
2013-11-20  0:45           ` Dmitry Eremin-Solenikov
2013-11-20  7:43           ` Dmitry Artamonow
2013-11-20  7:43             ` Dmitry Artamonow
2013-11-22 17:58           ` Russell King - ARM Linux
2013-11-22 17:58             ` Russell King - ARM Linux
2013-11-22 19:12             ` Dmitry Eremin-Solenikov
2013-11-22 19:12               ` Dmitry Eremin-Solenikov
2013-11-22 19:51               ` Russell King - ARM Linux
2013-11-22 19:51                 ` Russell King - ARM Linux
2013-11-22 21:23                 ` Dmitry Eremin-Solenikov
2013-11-22 21:23                   ` Dmitry Eremin-Solenikov
2013-11-20  0:40       ` Dmitry Eremin-Solenikov
2013-11-20  0:40         ` Dmitry Eremin-Solenikov
2013-11-22 17:33       ` Dmitry Eremin-Solenikov
2013-11-22 17:33         ` Dmitry Eremin-Solenikov
2013-11-22 21:35 ` Dmitry Eremin-Solenikov
2013-11-22 21:35   ` Dmitry Eremin-Solenikov

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=528B811A.1030501@gmail.com \
    --to=dbaryshkov@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mad_soft@inbox.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.