On Tue, Sep 16, 2008 at 10:14 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 09:36:22AM -0400, Jon Smirl wrote:
> [...]
>> >> >> -/*
>> >> >> - * Not implemented, yet.
>> >> >> - */
>> >> >> -static inline int gpio_to_irq(unsigned int gpio)
>> >> >> +static inline unsigned int gpio_to_irq(unsigned int gpio)
>> >> >> {
>> >> >> - return -ENOSYS;
>> >> >> + return gpio;
>> >> >
>> >> > "GPIO 0" is valid gpio, but "IRQ 0" isn't valid virq. So you
>> >> > can't do 1:1 mapping. :-(
>> >>
>> >> I changed the GPIO numbers inside of Linux to match the virqs.
>> >>
>> >> ofchip->gc.base = IRQ_GPIO_WKUP(0);
>> >
>> > Well, I didn't say that it will not work, what I'm trying to say
>> > is that I don't quite like the idea of 1:1 mapping for all gpio
>> > chips.
>> >
>> > It is error prone, i.e. gpio_to_irq() can't fail, so you can't
>> > tell if gpio to irq translation really happened or not. Plus
>> > we might decide to not do 1:1 mapping for other gpio chips.
>>
>> From reading the ARM code my understanding is that gpio_to_irq() and
>> irq_to_gpio() are meant to be fast paths without error checking.
>
> Nope. gpio_to_irq and irq_to_gpio don't have to be fast.
>
>> In
>> the gpiolib doc it says these functions should only take a couple of
>> instructions.
>
> This is for gpio_get/set_value and gpio_set_direction*.
>
>> You'll detect errors if you take an invalid IRQ from the function and
>> feed it into any of the rest of the IRQ API.
>
> Assume that GPIO 8 does not translate to any IRQ, but IRQ 8 is still
> valid virq b/c it is mapped for another IRQ controller (particularly
> lots of kernel code assumes that IRQ 8 is 8259 PIC's CMOS interrupt,
> the PIC and IRQ8 is widely used on PowerPC).
Set the base in the GPIO struct such that this won't happen. You can
set the base greater than MAX_IRQ.
Just because a CPU has a GPIO 8 in the manual does not mean that is
has to be assigned GPIO 8 in the kernel. The GPIO numbers in the
kernel are just handles, they can be any number. VIRQs don't use the
physical IRQ number.
In the code I posted all of the internal GPIO numbers were in the
150-180 range.
Assign GPIO numbers above the maximum VIRQ on the CPU...
#define IRQ_GPIO(x) (MPC52xx_IRQ_HIGHTESTHWIRQ + x)
#define IRQ_GPIO_WKUP(x) (IRQ_GPIO(32) + x)
Use the base of the GPIO struct to translate to the internal pin number.
ofchip->gc.base = IRQ_GPIO_WKUP(0);
static int mpc52xx_wkup_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
unsigned int ret;
Adjust for the offset .,..
ret = (in_8(®s->wkup_ival) >> (7 - gpio - gc.base)) & 1;
pr_debug("%s: gpio: %d ret: %d\n", __func__, gpio, ret);
return ret;
}
>
> So gpio_to_irq will succeed, and request_irq will succeed too. Though
> this would be not correct.
>
>> The idea for setting the GPIO number equal to the VIRQ number came out
>> of the ARM code. Making GPIO==VIRQ greatly simplified the code.
>
> Adding .to_irq callback won't complicate code either, but will let
> you do the things right.
>
> As for the ARM code... ARM has been using GPIO API long before
> GPIOLIB, and back then you didn't have many options.
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
>
--
Jon Smirl
[EMAIL PROTECTED]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
