On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav <vaibhav.bedia@xxxxxx> wrote: > On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote: >> On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav <vaibhav.bedia@xxxxxx> wrote: >> > >> > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: >> > [...] >> > >> > > >> How ? >> > > >> SRAM is sower memory than DDR so I don't see how it >> > > >> will reduce latency. >> > > >> >> > > > >> > > > I am just guessing if that's indeed the case ;) >> > > > Haven't done any measurements to really check if that's indeed the >> > > > case though. >> > > > >> > > You don't have to do any real measurements at least on OMAP. >> > > OCMC RAM is interfaced over L4 and MPU has to cross two interconnect >> > > bridges to reach to SRAM. DDR is more of direct path and much faster. >> > > >> > >> > Hmm, I was under the impression that OCMC RAM was on L3, at least for >> > OMAP4. >> > Maybe there's a extra low latency path for DDR that I am missing. >> have you folks considered the possibility that SRAM may be >> reprogrammed by Security code to almost nothing if PA/PPA size needs >> to be increased? it would be rather dumb not to support HS devices on >> which real products are made, no? rule of thumb has been to avoid >> usage of SRAM as it constraints security folks as well (yep, I know >> they should share code with all of us etc.. but they have a different >> sets of challenges that may deny them such luxury). >> > > Even I would like to avoid the usage of MPUSS SRAM for this very reason. > But AFAIK the whole PPA stuff isn't applicable for OCMC RAM (not SRAM inside MPUSS). On OMAP, even OCMC RAM can be used by security middle-ware apart from reserved SRAM for HS/EMU devices. That's what Nishant meant. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
