[PATCH 1/5] pintrl: meson: add interrupts to pinctrl data
Heiner Kallweit
hkallweit1 at gmail.com
Fri May 12 10:23:52 PDT 2017
Am 12.05.2017 um 11:51 schrieb Linus Walleij:
> On Fri, May 12, 2017 at 8:08 AM, Heiner Kallweit <hkallweit1 at gmail.com> wrote:
>
>> Following Jerome's suggestion I prepared a version making the irq multiplexer
>> an own device. Nice here is that with this approach basically only one line of
>> code needs to be changed in the existing pinctrl driver.
>>
>> As discussion basis I add it here w/o submitting a v2 of patch 5.
>
> I think this is the right way to go, but would ideally like some feedback from
> the irqchip maintainers.
>
> Have you looked at drivers/irqchip/irq-crossbar.c for inspiration?
> Also read
> Documentation/devicetree/bindings/arm/omap/crossbar.txt
>
> It uses an hierarchical domain for a similar cross-connection
> usecase.
>
When looking at the crassbar driver it seems to be quite similar to Jerome's
Meson GPIO IRQ driver version. Therefore I think we'd face the same challenges.
What is special about the Meson GPIO IRQ hw:
- We have only 8 parent IRQs for 100+ GPIO's.
- If a GPIO requests IRQ_TYPE_EDGE_BOTH (concrete example: mmc sd detection)
then we have to use two parent IRQs, one for each edge.
- We must be able to dynamically map a GPIO to a parent IRQ, e.g. if a driver
uses gpiod_to_irq().
These specifics are the reason why I do the mapping magic in the irq_set_type
callback of the irq_chip. Only in this callback I have all the info needed to
do the mapping.
> Under any circumstances I think decoupling the IRQ multiplexer
> and dealing with it in separate is easier for maintainance and
> also for the irq maintainers to review.
>
Then I'll submit the latest version with the separated device as v2 and we'll
see which further review comments and suggestions for alternative approaches
come in.
Rgds, Heiner
> Yours,
> Linus Walleij
>
More information about the linux-amlogic
mailing list