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

["Bedia, Vaibhav" <vaibhav.bedia@xxxxxx>]

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