From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shah, Nehal-bakulchandra" Subject: Re: [PATCH] pinctrl: amd: Add support for additional GPIO Date: Mon, 28 Nov 2016 15:27:25 +0530 Message-ID: References: <469f529e-818b-392f-9ddb-b02e87e50ca9@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-dm3nam03on0071.outbound.protection.outlook.com ([104.47.41.71]:59446 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932626AbcK1Ob0 (ORCPT ); Mon, 28 Nov 2016 09:31:26 -0500 In-Reply-To: Sender: linux-gpio-owner@vger.kernel.org List-Id: linux-gpio@vger.kernel.org To: Linus Walleij Cc: "linux-gpio@vger.kernel.org" , "gnurou@gmail.com" , "S-k, Shyam-sundar" , Marc Zyngier , Thomas Gleixner On 11/22/2016 4:14 PM, Linus Walleij wrote: > On Tue, Nov 22, 2016 at 11:19 AM, Shah, Nehal-bakulchandra > 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