[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Dec 2022 16:12:44 +0800
From: Yinbo Zhu <zhuyinbo@...ngson.cn>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
WANG Xuerui <kernel@...0n.name>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Juxin Gao <gaojuxin@...ngson.cn>,
Bibo Mao <maobibo@...ngson.cn>,
Yanteng Si <siyanteng@...ngson.cn>, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
Arnaud Patard <apatard@...driva.com>,
Huacai Chen <chenhuacai@...nel.org>,
Jianmin Lv <lvjianmin@...ngson.cn>,
Hongchen Zhang <zhanghongchen@...ngson.cn>,
Liu Peibao <liupeibao@...ngson.cn>, zhuyinbo@...ngson.cn
Subject: Re: [PATCH v5 2/3] gpio: loongson: add gpio driver support
在 2022/11/24 下午4:54, Linus Walleij 写道:
> On Thu, Nov 24, 2022 at 3:22 AM Yinbo Zhu <zhuyinbo@...ngson.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
>
Powered by blists - more mailing lists