Message-ID: <403f9685-fd40-8948-d658-5acb63af04fb@arm.com>
Date:   Thu, 25 Jan 2018 16:39:26 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Lina Iyer <ilina@...eaurora.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        open list <linux-kernel@...r.kernel.org>,
        linux-arm-msm@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>,
        "Nayak, Rajendra" <rnayak@...eaurora.org>, asathyak@...eaurora.org
Subject: Re: [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt
 controller



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:
> 
>>>> Also when will this PDC wakeup interrupts get configured ?
>>>>
>>> The platform drivers configure the IRQ as a wake source and if the IRQ
>>> is one of those listed as routed to the PDC, the PDC is configured to
>>> sense the interrupt and when the application processor domain is powered
>>> on and the GIC can sense the interrupts, it is replayed to the GIC,
>>> which then wakes up the processor.
>>>
>>
>> Now why can't this be done in the firmware entirely, if it can
>> save/restore GIC state.
>>
> That is because platform drivers make the choice of which interrupts are
> wake up capable at runtime, based on the usecase. They have to have a
> way to tell the firmware to do that. Earlier we used IPC to tell the
> remote processor to handle that. Now we do that by writing to the
> registers locally from Linux.
> 
>>>> OK, understood. By transparent, I mean firmware can copy the interrupts
>>>> enabled in the GIC to the PDC. It need not be kernel driven.
>>>>
>>> Yes, through the hierarchy.
>>>
>>
>> /me confused. Are you saying it's possible for f/w to copy wakeup
>> sources from GIC to PDC or not ?
>>
> 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.

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.

>>> Yes. There is a partition and protected. So only permitted ELs can write
>>> to the registers. This is done by the firmware at boot.
>>>
>>
>> Just for myself to understand better, so you have multiple partitions in
>> PDC and one of them is given to EL1 or it just has one partition and
>> that can be configured so that only permitted ELx is allowed to access
>> it(in your case it's EL1)
>>
> Yes.

Yes for the former or the latter :) ?

-- 
Regards,
Sudeep

Powered by blists - more mailing lists