From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751218AbeAYSnr (ORCPT ); Thu, 25 Jan 2018 13:43:47 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:39364 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751011AbeAYSnq (ORCPT ); Thu, 25 Jan 2018 13:43:46 -0500 Cc: Sudeep Holla , Thomas Gleixner , Jason Cooper , Marc Zyngier , open list , linux-arm-msm@vger.kernel.org, Stephen Boyd , "Nayak, Rajendra" , asathyak@codeaurora.org Subject: Re: [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt controller To: Lina Iyer References: <20180123175656.11942-1-ilina@codeaurora.org> <20180123184442.GA12243@codeaurora.org> <494fa715-aff0-19f2-0ee9-78d8c0b33775@arm.com> <20180124174310.GA24587@codeaurora.org> <1ee07421-444d-adf7-bf6f-8a35c4884c14@arm.com> <20180125155428.GC24587@codeaurora.org> <403f9685-fd40-8948-d658-5acb63af04fb@arm.com> <20180125181309.GA12603@codeaurora.org> From: Sudeep Holla Organization: ARM Message-ID: Date: Thu, 25 Jan 2018 18:43:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180125181309.GA12603@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/01/18 18:13, Lina Iyer wrote: > On Thu, Jan 25 2018 at 16:39 +0000, Sudeep Holla wrote: >> >> >> On 25/01/18 15:54, Lina Iyer wrote: >>> On Wed, Jan 24 2018 at 17:54 +0000, Sudeep Holla wrote: >>>> >>>> >>>> On 24/01/18 17:43, Lina Iyer wrote: >>>>> On Wed, Jan 24 2018 at 10:10 +0000, Sudeep Holla wrote: >>>>>> >>>>>> >>>>>> On 23/01/18 18:44, Lina Iyer wrote: >>>>>>> On Tue, Jan 23 2018 at 18:15 +0000, Sudeep Holla wrote: > >>> Platform drivers leave their interrupts enabled at the GIC. Only >>> interrupts that are wakeup capable are of interest when the processor is >>> powered down. The remote processor (or f/w) will need to know the set of >>> wakeup capable interrupts and then configure the PDC by copying from >>> GIC. As mentioned earlier, it is simplified by letting Linux write to >>> the PDC reqisters directly. >>> >> >> OK looks like I have not properly conveyed what I wanted to :( >> So lets take a peripheral A which has GIC interrupt X and a >> corresponding PDC interrupt Y. >> >> IIUC you want to configure Y from Linux while X is still enabled. >> >> 1. GICv3 masks all the interrupts(~X) that are not wakeup sources. >>   So when you say "platform drivers leave their interrupts enabled at >>   the GIC", it's not completely correct. >> > During idle path, the interrupts remain enabled. The GIC configuration > is retained, but the controller cannot sense interrupts because the > GIC logic is powered off. The PDC takes over for GIC at this time. > Ah OK, so PDC interrupts needs to be enabled all the time then. I was missing that. >> 2. GIC CPU interface is disabled in firmware, so it's better to copy the >>   wakeup source to PDC just before that in the firmware. >> >> 3. Remote f/w must just know the mapping to PDC(X) for all the enabled >>   interrupts(Y) at the GIC and enable them accordingly at PDC. Is that >>   not what you have in the array in patch 4 ? >> >> I find above approach simpler instead of getting those wakeup >> interrupts defined per peripheral in DT. Further if there are any secure >> wakeup interrupts the firmware can also deal with that. >> > You assume that the remote processor is capable of doing all that. It is > better to de-centralize all this and have individual processors do the > work of configuring their wake up sources. We used to do that in earlier > SoCs but with SDM845, we moved to de-centralized model to reduce latency > and take the load off from time-critical idle path at the remote > processor. Dumping all this work into the firmware/PSCI is not desirable > either. > It may have some advantages to decentralize but will that not cause issues in complex systems ? I assume even modem and other processors can access and configure these wakeup interrupts. What happens if 2 such processors try to access it at the same time ? Thanks for you patience and taking time to help me understand the design. -- Regards, Sudeep