From: Lina Iyer <ilina@codeaurora.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: 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
Date: Thu, 25 Jan 2018 15:54:28 +0000 [thread overview]
Message-ID: <20180125155428.GC24587@codeaurora.org> (raw)
In-Reply-To: <1ee07421-444d-adf7-bf6f-8a35c4884c14@arm.com>
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.
>> 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.
Thanks,
Lina
next prev parent reply other threads:[~2018-01-25 15:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 17:56 [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt controller Lina Iyer
2018-01-23 17:56 ` [PATCH RFC 1/4] drivers: irqchip: pdc: " Lina Iyer
2018-01-24 14:20 ` Marc Zyngier
2018-01-25 18:52 ` Lina Iyer
2018-01-30 17:56 ` Lina Iyer
2018-01-30 18:11 ` Marc Zyngier
2018-01-31 16:24 ` Lina Iyer
2018-01-31 16:46 ` Marc Zyngier
2018-02-01 16:49 ` Lina Iyer
2018-01-23 17:56 ` [PATCH RFC 2/4] dt-bindings/interrupt-controller: pdc: descibe PDC device binding Lina Iyer
2018-01-23 18:09 ` Sudeep Holla
2018-01-23 18:46 ` Lina Iyer
2018-01-24 14:24 ` Marc Zyngier
2018-01-30 15:20 ` Rob Herring
2018-01-23 17:56 ` [PATCH RFC 3/4] drivers: irqchip: pdc: log PDC info in FTRACE Lina Iyer
2018-01-23 18:13 ` Steven Rostedt
2018-01-25 15:45 ` Lina Iyer
2018-01-23 17:56 ` [PATCH RFC 4/4] drivers: irqchip: qcom: add pin information for SDM845 Lina Iyer
2018-01-24 14:20 ` Marc Zyngier
2018-01-25 18:14 ` Lina Iyer
2018-01-23 18:15 ` [PATCH RFC 0/4] irqchip: qcom: add support for PDC interrupt controller Sudeep Holla
2018-01-23 18:44 ` Lina Iyer
2018-01-24 10:10 ` Sudeep Holla
2018-01-24 17:43 ` Lina Iyer
2018-01-24 17:54 ` Sudeep Holla
2018-01-25 15:54 ` Lina Iyer [this message]
2018-01-25 16:39 ` Sudeep Holla
2018-01-25 18:13 ` Lina Iyer
2018-01-25 18:43 ` Sudeep Holla
2018-01-25 20:05 ` Lina Iyer
2018-01-26 11:39 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180125155428.GC24587@codeaurora.org \
--to=ilina@codeaurora.org \
--cc=asathyak@codeaurora.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=rnayak@codeaurora.org \
--cc=sboyd@codeaurora.org \
--cc=sudeep.holla@arm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).