lkml.org 
[lkml]   [2022]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 2/3] gpio: loongson: add gpio driver support
From
Date


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

\
 
 \ /
  Last update: 2022-12-12 09:14    [W:0.071 / U:1.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site