Re: [PATCH] RFT: pinctrl: sunxi: convert to GPIO irqchip helpers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Linus,

On Fri, May 09, 2014 at 09:38:02AM +0200, Linus Walleij wrote:
> This switches the sunxi pinctrl driver over to using the generic
> gpiolib irqchip helpers for its chained irqs.
> 
> As the .to_irq() callback on the gpiochip was doing some function
> indexing this was moved over to the .irq_startup callback on the
> irqchip (where it belongs, since it is perfectly legal to request
> an irq from an irqchip without calling gpio_to_irq() first).
> 
> The gpio_chip was converted into a true member of the pinctrl
> struct instead of being a pointer to a separately allocated
> object, avoiding an unnecessary allocation and making it possible
> to use container_of() to get from the struct gpio_chip * back to
> the sunxi pinctrl state container.
> 
> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> ---
> Maxime, can you test this thing? And if it doesn't work, can you
> figure out what it is that I want you to do and do it ;-)
> This is done on top of your recently pulled sunxi series.

Thanks for your patches, I'll give it a try some time this week. This
is also a good occasion to discuss a serie of patches to rework
exactly this code.

Currently, we support only the interrupts on the older Allwinner SoCs,
that had only one bank and one parent interrupt.

On the newer ones, like the A31, there is, depending on wether it's
the "primary" or "secondary" pin controller, 2 or 4 interrupt banks,
with a parent interrupt for each bank.

The core logic still applies though, interrupts are still a special
muxing function, so we can definitely reuse this code.

What I did so far is having a single domain, with the same handler
registered for all the interrupts, and the various interrupts from the
various banks just being at a different offsets in the domain.

Basically, something like that:
http://code.bulix.org/ym3zuv-86191

Do you know if it would be possible to use the generic gpiolib
behaviour in such a case?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux