Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751872AbdIMIcY (ORCPT ); Wed, 13 Sep 2017 04:32:24 -0400 Received: from conssluserg-01.nifty.com ([210.131.2.80]:42818 "EHLO conssluserg-01.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751121AbdIMIcU (ORCPT ); Wed, 13 Sep 2017 04:32:20 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com v8D8W764012572 X-Nifty-SrcIP: [209.85.161.182] X-Google-Smtp-Source: AOwi7QA06Z11d52UtW6GwTyVF4fipIwETMuTMFzMK+5W6d1A254cTsWWSvGmWSFHzbJWXgycLVN/Qu2/wXlr+YpMyR8= MIME-Version: 1.0 In-Reply-To: <7e46f2a3-114f-0c34-d3c5-49e6422b9200@caviumnetworks.com> References: <1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com> <1504784522-26841-7-git-send-email-yamada.masahiro@socionext.com> <7e46f2a3-114f-0c34-d3c5-49e6422b9200@caviumnetworks.com> From: Masahiro Yamada Date: Wed, 13 Sep 2017 17:31:26 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 6/6] gpio: uniphier: add UniPhier GPIO controller driver To: David Daney Cc: Linus Walleij , David Daney , Marc Zyngier , Thomas Gleixner , "linux-gpio@vger.kernel.org" , Rob Herring , Jassi Brar , "devicetree@vger.kernel.org" , Jason Cooper , Masami Hiramatsu , "linux-kernel@vger.kernel.org" , Mark Rutland , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2811 Lines: 76 Hi. 2017-09-13 0:44 GMT+09:00 David Daney : > On 09/12/2017 07:03 AM, Linus Walleij wrote: >> >> On Thu, Sep 7, 2017 at 1:42 PM, Masahiro Yamada >> wrote: >> >>> This GPIO controller device is used on UniPhier SoCs. >>> >>> It also serves as an interrupt controller, but interrupt signals are >>> just delivered to the parent irqchip without any latching or OR'ing. >>> This is implemented by using hierarchy IRQ domain. >>> >>> Implementation note: >>> Unfortunately, the IRQ mapping from this controller to the parent is >>> random. (48, 49, ..., 63, 154, 155, ...) >>> If "interrupts" property is used, IRQ resources may be statically >>> allocated when platform devices are populated from DT. This can be >>> a problem for the hierarchy IRQ domain because IRQ allocation must >>> happen from the outer-most domain up to the root domain in order to >>> build up the stacked IRQ. (https://lkml.org/lkml/2017/7/6/758) >>> Solutions to work around it could be to hard-code parent hwirqs or >>> to invent a driver-specific DT property. >>> >>> Here, the new API irq_domain_push_irq() was merged by v4.14-rc1. >>> It allows to add irq_data to the existing hierarchy. It will help >>> to make this driver work whether the parent has already initialized >>> the hierarchy or not. >>> >>> Signed-off-by: Masahiro Yamada >>> --- >>> >>> Changes in v4: >>> - Add COMPILE_TEST and select IRQ_DOMAIN_HIERARCHY >>> - Reimplement irqchip part by using irq_domain_push_irq() >> >> >> Awesome improvement. There was a build error and I also >> would like David Daney to have a look at this so we know we >> use things the right way, > > > It looks correct to me. > > I haven't verified it, but I think the OF device-tree probing code for the > platform devices will automatically xlat-and-map all those irqs, so that the > irq_domain_push_irq() is required to get the domain hierarchy properly > configured. It would be similar to the PCI case where we configure all the > MSI-X and then do the irq_domain_push_irq() in the Cavium ThunderX driver. > > If interrupt handling has been verified to work with this driver, I would > say that we are probably using things "the right way". > > David. > V4 depends on 5 patches that got negative feedback in irqdomain subsystem. One more problem for this approach is to virtual IRQs are statically allocated during the driver probe. This looks a step backward to me. Recently, gpio_irqchip migrated to on-the-fly allocation in case some controllers may have lots of GPIO lines. Finally, I came up with another (I think, better) solution. I think v5 is less controversial, and works very well in on-the-fly manner. I am sending it shortly... -- Best Regards Masahiro Yamada