Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Cc:     Sudeep Holla <sudeep.holla@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jason Cooper <jason@lakedaemon.net>,
        Marc Zyngier <marc.zyngier@arm.com>,
        open list <linux-kernel@vger.kernel.org>,
        linux-arm-msm@vger.kernel.org, Stephen Boyd <sboyd@codeaurora.org>,
        "Nayak, Rajendra" <rnayak@codeaurora.org>, asathyak@codeaurora.org
Subject: Re: [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt
 controller
To:     Lina Iyer <ilina@codeaurora.org>
References: <20180123175656.11942-1-ilina@codeaurora.org>
 <CAPKp9uY7z+HVNo9FOAfJ1zn-btcvFOt7mPCD0x_iLKUCfJOy6w@mail.gmail.com>
 <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 <sudeep.holla@arm.com>
Organization: ARM
Message-ID: <ea7e2c61-d1be-d97e-cf2e-08254389b04f@arm.com>
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
Precedence: bulk


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