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;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 16903604D4
Date:   Wed, 24 Jan 2018 17:43:10 +0000
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
Message-ID: <20180124174310.GA24587@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <494fa715-aff0-19f2-0ee9-78d8c0b33775@arm.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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:
>>> Hi Lina,
>>>
>>> On Tue, Jan 23, 2018 at 5:56 PM, Lina Iyer <ilina@codeaurora.org> wrote:
>>>> On newer Qualcomm Techonologies Inc's SoCs like the SDM845, the GIC
>>>> is in a
>>>> power domain that can be powered off when not needed. Interrupts that
>>>> need to
>>>> be sensed even when the GIC is powered off, are routed through an
>>>> interrupt
>>>> controller in an always-on domain called the Power Domain Controller
>>>> a.k.a PDC.
>>>> This series adds support for the PDC's interrupt controller.
>>>>
>>>
>>> Sorry for the basic questions:
>>>
>>> 1. Will the GIC be powered off in any other state other than System
>>> suspend ?
>>>
>> Yes. When all the CPUs are in idle, there is an opportunity to power off
>> the CPU's power domain and the GIC. QCOM SoCs have been doing that for
>> many generations now.
>>
>
>OK interesting, in that case so either GIC state is saved/restored with
>some out of tree patches or the firmware takes care of it and it's
>transparent to Linux ?
>
Yes. It is handled by a remote processor, which is aware that the application
processor subsystem has been powered off.

>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.

>>> 2. Why this needs to be done in Linux, why can't it be transparent and
>>> hidden
>>>    in the firmware doing the actual GIC power down ? I assume Linux is
>>> not
>>>    powering down the GIC.
>> No. You are right, Linux is not powering off the GIC directly. A
>> dedicated processor for power management in the SoC does that. Platform
>> drivers in Linux, know and configure the wakeup interrupts (depending on
>> the usecase). This is runtime specific and this is the way to tell the
>> SoC to wake up the processor even if the GIC and the CPU domain were
>> powered off.
>>
>
>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.

>>>
>>> 3. I see some bits that enable secure interrupts in one of the patch.
>>> Is that even
>>>    safe to allow Linux to enable some secure interrupts in PDC ?
>>>
>> Linux should not and would not configure secure interrupts. We would not
>> have permissions for secure interrupts. The interrupt names might be a
>> misnomer, but the interrupts listed in patch #4 are all non-secure
>> interrupts.
>>
>
>OK. So I can assume PDC is partitioned in secure and non-secure. If not
>it's safe not have any access for PDC in the kernel. Couple of designs
>of similar PDC I have seen is system wide and does handle even secure
>part of the system. That was the main reason for checking.
>
Yes. There is a partition and protected. So only permitted ELs can write
to the registers. This is done by the firmware at boot.

Thanks,
Lina