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@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
