On Tue, Mar 06, 2012 at 04:44:13, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia@xxxxxx> [120213 07:36]:
> > On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
> > > >>>>> "Afzal" == Afzal Mohammed <afzal@xxxxxx> writes:
> > >
> > > Afzal> From: Vaibhav Bedia <vaibhav.bedia@xxxxxx>
> > > Afzal> Update SRAM start & size for am33xx SoC's.
> > >
> >
> > This is a really awkward quoting style :|
> >
> > >
> > > I don't particular know the omap sram stuff, but doesn't the 33xx have
> > > 2x 64K blocks of SRAM?
> > >
> >
> > Yes, but since the lower 64KB will not be available on non-GP device and
> > only A8 can access it, for now we make use of the higher 64KB which is referred
> > to as the OCMC RAM in the TRM. This will also enable SRAM usage by other drivers
> > like PRU and McASP.
> >
> > >
> > > Afzal> +static inline int am33xx_sram_init(void)
> > > Afzal> +{
> > > Afzal> + return 0;
> > >
> > >
> > > I know you mentioned it in the commit message, but it might be good with
> > > a comment here as well that this dummy function is needed to not get the 34xx
> > > init function called for 33xx, so it doesn't get removed when somebody
> > > decides to cleanup.
> >
> > You are right in saying that the dummy function is needed to avoid 34xx SRAM init.
> > We'll have some PM related code coming in soon and hopefully the SRAM code won't change
> > Without us noticing ;)
>
> OK, applying into fixes-non-critical-part2. Our sram.c should get turned
> into a device driver, there's been already similar sram driver posted
> to LAKML. So that should allow us to remove the cpu_is_xxxx checks.
>
I think I missed this, let me check the post.
Thanks,
Vaibhav
> Regards,
>
> Tony
>
--
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
