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: >>>> 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. > OK, better. >> 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. >>>> 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. > /me confused. Are you saying it's possible for f/w to copy wakeup sources from GIC to PDC or not ? >>>> >>>> 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. > 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) -- Regards, Sudeep -- 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
