[PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode

Bedia, Vaibhav vaibhav.bedia at ti.com
Wed May 2 07:55:26 EDT 2012


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 at ti.com> 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).



More information about the linux-arm-kernel mailing list