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: > >>> 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. >>> >> >> OK looks like I have not properly conveyed what I wanted to :( >> So lets take a peripheral A which has GIC interrupt X and a >> corresponding PDC interrupt Y. >> >> IIUC you want to configure Y from Linux while X is still enabled. >> >> 1. GICv3 masks all the interrupts(~X) that are not wakeup sources. >> So when you say "platform drivers leave their interrupts enabled at >> the GIC", it's not completely correct. >> > During idle path, the interrupts remain enabled. The GIC configuration > is retained, but the controller cannot sense interrupts because the > GIC logic is powered off. The PDC takes over for GIC at this time. > 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 ? Thanks for you patience and taking time to help me understand the design. -- 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
