Messages in this thread | | | Subject | Re: [PATCH v5 2/3] gpio: loongson: add gpio driver support | From | Yinbo Zhu <> | Date | Mon, 12 Dec 2022 16:12:44 +0800 |
| |
在 2022/11/24 下午4:54, Linus Walleij 写道: > On Thu, Nov 24, 2022 at 3:22 AM Yinbo Zhu <zhuyinbo@loongson.cn> wrote: >> 在 2022/11/24 上午6:05, Linus Walleij 写道: > >>> But these drivers can not rely on the .gpio_to_irq() callback >>> to be called before an IRQ is requested and used. >> >> I may not have made it clear before that the gpio irq chip for other >> platforms may need to be implemented, but the loongson platform may be >> special. >> >> I mean that the loongson platform use gpio irq does not need to rely on >> gpio_to_irq, because loongson interrupt controller driver has covered >> gpio irq. The specific reason is my above explanation. >> >> so, Can I not realize gpio irq chip? > > Isn't this a hierarchical irqchip then? > > Please consult the following from > Documentation/driver-api/gpio/driver.rst: > > --------------------------------- > > GPIO drivers providing IRQs > =========================== > > It is custom that GPIO drivers (GPIO chips) are also providing interrupts, > most often cascaded off a parent interrupt controller, and in some special > cases the GPIO logic is melded with a SoC's primary interrupt controller. > > The IRQ portions of the GPIO block are implemented using an irq_chip, using > the header <linux/irq.h>. So this combined driver is utilizing two sub- > systems simultaneously: gpio and irq. > > It is legal for any IRQ consumer to request an IRQ from any irqchip even if it > is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and > irq_chip are orthogonal, and offering their services independent of each > other. > > gpiod_to_irq() is just a convenience function to figure out the IRQ for a > certain GPIO line and should not be relied upon to have been called before > the IRQ is used. > > Always prepare the hardware and make it ready for action in respective > callbacks from the GPIO and irq_chip APIs. Do not rely on gpiod_to_irq() having > been called first. > > We can divide GPIO irqchips in two broad categories: > > - CASCADED INTERRUPT CHIPS: this means that the GPIO chip has one common > interrupt output line, which is triggered by any enabled GPIO line on that > chip. The interrupt output line will then be routed to an parent interrupt > controller one level up, in the most simple case the systems primary > interrupt controller. This is modeled by an irqchip that will inspect bits > inside the GPIO controller to figure out which line fired it. The irqchip > part of the driver needs to inspect registers to figure this out and it > will likely also need to acknowledge that it is handling the interrupt > by clearing some bit (sometime implicitly, by just reading a status > register) and it will often need to set up the configuration such as > edge sensitivity (rising or falling edge, or high/low level interrupt for > example). > > - HIERARCHICAL INTERRUPT CHIPS: this means that each GPIO line has a dedicated > irq line to a parent interrupt controller one level up. There is no need > to inquire the GPIO hardware to figure out which line has fired, but it > may still be necessary to acknowledge the interrupt and set up configuration > such as edge sensitivity. Hi Linus,
My patch had send it to v11, but I have some issues. it seems more appropriate add them here. the issue as follows:
mask_irq/unmask_irq/irq_ack/ function always be called by handle_level_irq/handle_edge_irq in current irq domain. and the handle_level_irq/handle_edge_irq will be called by handle_irq_desc that ask know which irq is.
when a peripheral need to use a gpio irq that gpio irq driver need know irq status and call irq desc->irq_handler.
so I don't got it about which case it is unnecessary to know which irq. > > --------------------------------- > > You find an example of a hierarchical GPIO irqchip using the > GPIOLIB_IRQCHIP in drivers/gpio/gpio-ixp4xx.c.
Loongson-2 gpio irq hardware only a enable register, and when a gpio irq happen, then will has a such flow: "cpuintc -> liointc -> gpioinc -> generic_handle_domain_irq -> handle_level_irq -> peripheral-action(action->handler)"
generic_handle_domain_irq need rely on specific hwirq that ask gpio irq hardware has a status register but Loongson-2 gpio irq hardware doesn't have it.
so I still think it wasn't appropriate that for loongson-2 gpio driver add a irq chip.
Yinbo. > > Yours, > Linus Walleij >
| |