Re: [PATCH 0/2] ARM: dts: rskrza1: Add I2C and remaining LEDs

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

 



Hi Chris,

On Thu, Mar 21, 2019 at 1:16 PM Chris Brandt <Chris.Brandt@xxxxxxxxxxx> wrote:
> Look what fun you are having with an RZ/A1 board!
> You might have even more fun with a RZ/A2 board ;)
>
> > However, that also doesn't work, as the PL390 GIC supports rising edge
> > and high-level interrupts only.  Falling edge and low-level interrupts
> > on the IRQ pins seem to be an RZ/A1-specific GIC extension,
>
> Yes. I get this question a couple times a year.
>
> And no one wants rising or level high, so the GPIO interrupts would not
> work for them anyway.
>
> So, as you found:
>
> > I've just discovered commit 207c10b54ca81129 ("irq-gic: add support for
> > pins IRQ0-IRQ7") in rza_linux-4.14, but when using that, the system
> > locks up when pressing a switch :-(
>
> It might be because the interrupt routine needs to go in and clear the
> interrupt by writing to the 'IRQ Interrupt Request Register' (IRQRR).
> From the HW manual:
>
> "IRQRR is a 16-bit register that indicates interrupt requests from
> external input pins IRQ7 to IRQ0. If edge detection is set for the IRQ7 to
> IRQ0 interrupts, writing 0 to the IRQ7F to IRQ0F bits after reading IRQ7F
> to IRQ0F = 1 cancels the retained interrupts."

OK.

> > What am I doing wrong?
> > Do you have a better solution?
> > The IRQx support looks most promising, but needs some work (separate
> > compatible value, small driver with a custom .irq_set_type, deferring
> > the rest to the normal GIC driver).
>
> I not sure about a 'better' solution...just the one I tell people
> (although I need to make some App Note someday).
>
> Basically, I tell people they need to describe the IRQ in the Device
> Tree somewhere (so it can get allocated an interrupt ID).
> Then, they can call request_irq() from inside a custom driver if they
> want to.
> Or, they just make a very simple shim-driver in their board-xxx.c file
> that registers the interrupt and has a simple interrupt routine. Many
> times all people want to do is simply wire up an interrupt that the
> application can wait on. Or, use an IRQ pin to start an ADC conversion. Pretty
> simple stuff.
>
> Of course they can also use a UIO driver to do these kinds of things as
> well.
> As you know, the UIO subsystem will automatically turn of the interrupt
> each time, but users still need to write to the IRQRR register before
> turning the interrupt back on if using edge interrupts.
>
> I always thought what I really need to do is instead just make a
> separate driver like you suggested above because technical, the "IRQ" block is
> not really part of the GIC, it is a separate block that feeds interrupts
> into the GIC just like all the other peripherals, so it should be
> represented as a separate piece of hardware (ie, its own driver and
> capability string).

Right, that makes sense: a small irqchip driver, with 8 inputs, and 8 outputs.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux