Patchwork Add MPC52xx simple interrupt GPIO support

Hello,

I've got a target derived from the Lite5200 that needs to use simple
interrupt GPIO pins. I created a patch to support this kind of GPIO.

I would need your opinion and like to hear any criticism. Esp. the
facts that I ad to split up struct mpc52xx_gpio and that the GPIO
numbering might get mixed up concern me.

Because I'm somewhat new to git, at least when it comes to create and
incorporate patches via mail, you have to point out those errors as
well. The first thing I found lready out ist, that my patch isn't
signed off. I'll do that with an final version if I get the chance to
deliver one.


And here the patch:


Add MPC52xx simple interrupt GPIO support

Split of struct mpc52xx_sint_gpio from struct mpc52xx_gpio to allow a
+	.match_table = mpc52xx_simple_interrupt_gpiochip_match,
+	.probe = mpc52xx_simple_interrupt_gpiochip_probe,
+	.remove = mpc52xx_gpiochip_remove,
+};
+
+/*
  * GPIO LIB API implementation for gpt GPIOs.
  *
  * Each gpt only has a single GPIO.
@@ -444,6 +599,9 @@ static int __init mpc52xx_gpio_init(void)
 	if (of_register_platform_driver(&mpc52xx_simple_gpiochip_driver))
 		printk(KERN_ERR "Unable to register simple GPIO driver\n");
 
+	if (of_register_platform_driver(&mpc52xx_simple_interrupt_gpiochip_driver))
+		printk(KERN_ERR "Unable to register simple interrupt GPIO driver\n");
+
 	if (of_register_platform_driver(&mpc52xx_gpt_gpiochip_driver))
 		printk(KERN_ERR "Unable to register gpt GPIO driver\n");

Hi Roman,

Thanks for this work.  Comments below.

On Thu, Feb 26, 2009 at 7:24 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> Hello,
>
> I've got a target derived from the Lite5200 that needs to use simple
> interrupt GPIO pins. I created a patch to support this kind of GPIO.
>
> I would need your opinion and like to hear any criticism. Esp. the
> facts that I ad to split up struct mpc52xx_gpio and that the GPIO
> numbering might get mixed up concern me.

While I understand why this patch is written the way it is, I don't
think it is the right approach.

This patch changes the mpc5200 gpio binding to adapt to a Linux
internal implementation detail.  Specifically, the of_mm
infrastructure only allows a 1:1 relationship between a 'struct
of_gpio_chip' and a 'struct gpio_chip'.  When working with device
trees, this is the wrong way around.  The device tree describes the
hardware, not the Linux implementation details.

An argument could be made that the current binding isn't ideal and
that it would be better to split the simple, interrupt and output-only
gpio pins into separate nodes, but that pretty much comes down to a
matter of opinion as the existing binding describes the hardware just
fine.  I'm actually of the opinion that it would be better to fewer
gpio nodes, not more, by merging the simple and wakeup pins into a
single node, but what's done is done and there is no technical reason
for changing the current binding.

So, that leaves the problem working with the of_mm infrastructure.  I
think the correct solution is to modify of_gpio_chip to hold an array
of struct gpio_chip and to change of_gpio_simple_xlate() to handle it.
 Maybe something like:

struct of_gpio_chip {
        int gpio_cells;
        int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
                     const void *gpio_spec, enum of_gpio_flags *flags);
        struct gpio_chip gc[1];
};

and add an allocator function that takes care of allocating the
required size of the gc array.  There are details to work out of
course, but I thing this would be the more robust solution.

Cheers,
g.

On Thu, Feb 26, 2009 at 10:06:59PM -0700, Grant Likely wrote:
> Hi Roman,
> 
> Thanks for this work.  Comments below.
> 
> On Thu, Feb 26, 2009 at 7:24 AM, Roman Fietze
> <roman.fietze@telemotive.de> wrote:
> > Hello,
> >
> > I've got a target derived from the Lite5200 that needs to use simple
> > interrupt GPIO pins. I created a patch to support this kind of GPIO.
> >
> > I would need your opinion and like to hear any criticism. Esp. the
> > facts that I ad to split up struct mpc52xx_gpio and that the GPIO
> > numbering might get mixed up concern me.
> 
> While I understand why this patch is written the way it is, I don't
> think it is the right approach.
> 
> This patch changes the mpc5200 gpio binding to adapt to a Linux
> internal implementation detail.  Specifically, the of_mm
> infrastructure only allows a 1:1 relationship between a 'struct
> of_gpio_chip' and a 'struct gpio_chip'.  When working with device
> trees, this is the wrong way around.  The device tree describes the
> hardware, not the Linux implementation details.
> 
> An argument could be made that the current binding isn't ideal and
> that it would be better to split the simple, interrupt and output-only
> gpio pins into separate nodes, but that pretty much comes down to a
> matter of opinion as the existing binding describes the hardware just
> fine.  I'm actually of the opinion that it would be better to fewer
> gpio nodes, not more, by merging the simple and wakeup pins into a
> single node, but what's done is done and there is no technical reason
> for changing the current binding.
> 
> So, that leaves the problem working with the of_mm infrastructure.  I
> think the correct solution is to modify of_gpio_chip to hold an array
> of struct gpio_chip and to change of_gpio_simple_xlate() to handle it.
>  Maybe something like:
> 
> struct of_gpio_chip {
>         int gpio_cells;
>         int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
>                      const void *gpio_spec, enum of_gpio_flags *flags);
>         struct gpio_chip gc[1];
> };

I'd suggest to not touch of_gpio_chip structure, I'd like to keep
of_gpio_chip struct 1:1 bound to a pure gpio_chip structure. This keeps
things simple and understandable on the low level.

And when you need several gpio controllers bound to some Linux struct,
I would rather suggest this:

struct mpc5200_gpio_controller {
	void __iomem *regs;
	void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
	struct of_gpio_chip of_gc[1];
};

In the of_gc->xlate callback you'll always get &of_gc[0], but since you
know that this is mpc5200 controller, you can add needed offset depending
on gpio_spec.

(s/mpc5200/of_multi_mm/ or something like this, if you'll manage to
do this for the general case.)


OTOH, there is even more straightforward solution, all you actually need
is to define "HW GPIO" bindings (which are wkup, which are interrupt, etc.),
and then:

void mpc5200_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
{
	if (mpc5200_is_wkup(gpio))
		write to the wkup registers block;
	else if (mpc5200_is_int(gpio))
		write to the int registers block;
	else
		...
}

That is, the same thing we do for the interrupt controllers.

(Note that these "if"s can be replaced by a table, as in
arch/powerpc/sysdev/qe_lib/qe_ic.c).

On Mon, Mar 2, 2009 at 10:16 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Thu, Feb 26, 2009 at 10:06:59PM -0700, Grant Likely wrote:
>>  Maybe something like:
>>
>> struct of_gpio_chip {
>>         int gpio_cells;
>>         int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
>>                      const void *gpio_spec, enum of_gpio_flags *flags);
>>         struct gpio_chip gc[1];
>> };
>
> I'd suggest to not touch of_gpio_chip structure, I'd like to keep
> of_gpio_chip struct 1:1 bound to a pure gpio_chip structure. This keeps
> things simple and understandable on the low level.
>
> And when you need several gpio controllers bound to some Linux struct,
> I would rather suggest this:
>
> struct mpc5200_gpio_controller {
>        void __iomem *regs;
>        void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
>        struct of_gpio_chip of_gc[1];
> };
>
> In the of_gc->xlate callback you'll always get &of_gc[0], but since you
> know that this is mpc5200 controller, you can add needed offset depending
> on gpio_spec.

Fair enough.  That works too.

> OTOH, there is even more straightforward solution, all you actually need
> is to define "HW GPIO" bindings (which are wkup, which are interrupt, etc.),
> and then:
>
> void mpc5200_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
> {
>        if (mpc5200_is_wkup(gpio))
>                write to the wkup registers block;
>        else if (mpc5200_is_int(gpio))
>                write to the int registers block;
>        else
>                ...
> }
>
> That is, the same thing we do for the interrupt controllers.

Ugh, I'd really do not want to use this approach.  The GPIOs path is
too long as is.  When GPIOs are used for things like JTAG or other bus
emulation, every cycle counts.  As much as possible the long path,
such as figuring out which chip, should be preprocessed so that it is
already known by the time the set/get/direction hooks are called.

IRQ controllers typically need to deal with far lower frequencies on
the IRQ line.

>
> (Note that these "if"s can be replaced by a table, as in
> arch/powerpc/sysdev/qe_lib/qe_ic.c).

Even with the table it is a cost I don't want in the GPIO handler.  If
it were possible to do so, I'd even like to remove the spinlocks from
the hooks, but that isn't an option at the moment.

g.