Re: [PATCH v5 2/3] gpio: loongson: add gpio driver support

[Yinbo Zhu <zhuyinbo@loongson.cn>]

在 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
>