linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 20:05:12 +0000	[thread overview]
Message-ID: <20180125200512.GE12603@codeaurora.org> (raw)
In-Reply-To: <ea7e2c61-d1be-d97e-cf2e-08254389b04f@arm.com>

On Thu, Jan 25 2018 at 18:43 +0000, Sudeep Holla wrote:
>
>
>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:
>>
>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 ?
>
Every processor in the SoC has its own PDC and does exactly the same
thing in SW. The hardware blocks are replicated for each of the
'subsystem' and they behave similarly.

>Thanks for you patience and taking time to help me understand the design.
>
Sure.

Thanks,
Lina

  reply	other threads:[~2018-01-25 20:05 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
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 [this message]
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=20180125200512.GE12603@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).