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