Re: [PATCH] pinctrl: amd: Add support for additional GPIO

["Shah, Nehal-bakulchandra" <Nehal-Bakulchandra.shah@xxxxxxx>]

On 11/22/2016 4:14 PM, Linus Walleij wrote:
> On Tue, Nov 22, 2016 at 11:19 AM, Shah, Nehal-bakulchandra
> <Nehal-Bakulchandra.shah@xxxxxxx> wrote:
> 
>> I understood that chained irq and devm_irq can't be used together. Surely,
>> I will rework on the patch.
> 
> OK! :)
> 
> We have a case where devm_request_threaded_irq() is used like this,
> that is called *nested* irqs, when an interrupt-handling thread is called
> from within another interrupt-handling thread.
> 
> But since this handler is not threaded, but rather a hardirq, it is not
> a viable option.
> 
>> The reason behind using devm_irq is that in our
>> upcoming platform bios may report two gpio controllers. Both will have same IRQs.
>> In my understanding if I use chained irq handler, it will not be clear interrupt
>> is due to which gpio controller.It may lead to serve irq twice.
> 
> This is a shared IRQ line.
> 
> How stressful that it is shared between two cascaded irqchips!
> 
> Shared IRQs should nominally be handled by the leafs of the interrupt
> handlers returning IRQ_HANDLED and the ones that did not
> trigger an IRQ returning IRQ_NONE.
> 
> With a chained handler the assumption is that the flow handler
> is not really returning anything, just dispatching down to the
> consumer (device etc) to return IRQ_HANDLED if it was
> their IRQ.
> 
> If you want to "bail out" of the chained handler (in your
> case what you pass to gpiochip_set_chained_irqchip())
> just check if the IRQ status register happens to be zero,
> and in that case return; before even calling
> chained_irq_enter().
> 
> I do not know if there is a way to mark a line as shared
> in a chained flow handler!
> 
> The current assumption is that gpiochip_set_chained_irqchip()
> is called for one or many *different* IRQs. That will work.
> But if it is called twice for the *same* IRQ, we might need
> some special work inside gpiochip_set_chained_irqchip()
> to make this work properly with shared IRQs...
> 
>> Please let me know if anything is incorrect in my understanding or if there is
>> a better way to handle this situation.
> 
> I think reading a bit in kernel/irq/chip.c to see what is really
> happening with chained IRQs help a lot. If there are unclarities,
> it needs to be discussed with the IRQchip maintainers
> (Marc & Thomas).
> 
> Yours,
> Linus Walleij
> 
Hi Linus,

Thanks for your valuable input. Currently due to some limitations in IP we are restricting number of GPIO controller to 1. Hence Bios also will report 1 GPIO controller. So now to make it simple i will submit patch for Addtional GPIO Bank and adding IRQCHIP_SKIP_SET_WAKE flag. I will submit that patch in separate mail. Now regarding the another GPIO controller once limitation and behavior will be cleared i will make a separate patch.

Regards
Nehal Shah
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html