Quoting Sibi Sankar (2020-05-07 12:21:57) > The modem remote processor has two modes of access to the DDR, a direct > mode and through a SMMU which requires direct mapping. The configuration > of the modem SIDs is handled in TrustZone. Is it "The configuration of the modem SIDs is typically handled by code running in the ARM CPU's secure mode, i.e. secure EL1"? And is that even true? I though it was programmed by EL2. > On platforms where TrustZone TrustZone is always there. > is absent this needs to be explicitly done from kernel. Add compatibles > for modem to opt in for direct mapping on such platforms. > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> Is Sai the author? Or does this need a co-developed-by tag? > Signed-off-by: Sibi Sankar <sibis@xxxxxxxxxxxxxx> > --- > > V5 > * Reword commit message and drop unnecessary details I don't see any improvement! Probably because I don't understand _why_ the modem needs a direct mapping. The commit text basically says "we need to do it because it isn't done in secure world sometimes". This is probably wrong what I wrote below, but I'd like to clarify to confirm my understanding. Maybe the commit text should say: The modem remote processor has two access paths to DDR. One path is directly connected to DDR and another path goes through an SMMU. The SMMU path is configured to be a direct mapping because it's used by various peripherals in the modem subsystem. Typically this direct mapping is configured by programming modem SIDs into the SMMU when EL2 responds to a hyp call from the code that loads the modem binary in the secure world. In certain firmware configurations, especially when the kernel is entered at EL2, we don't want secure mode to make hyp calls to program the SMMU because the kernel is in full control of the SMMU. Let's add compatibles here so that we can have the kernel program the SIDs for the modem in these cases.
