From: Tony Lindgren <tony@atomide.com>
To: "Bedia, Vaibhav" <vaibhav.bedia@ti.com>
Cc: Peter Korsgaard <jacmet@sunsite.dk>,
"Mohammed, Afzal" <afzal@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Nori, Sekhar" <nsekhar@ti.com>,
"Hiremath, Vaibhav" <hvaibhav@ti.com>
Subject: Re: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
Date: Mon, 5 Mar 2012 15:14:13 -0800 [thread overview]
Message-ID: <20120305231413.GP12083@atomide.com> (raw)
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433179FC35@DBDE01.ent.ti.com>
* Bedia, Vaibhav <vaibhav.bedia@ti.com> [120213 07:36]:
> On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
> > >>>>> "Afzal" == Afzal Mohammed <afzal@ti.com> writes:
> >
> > Afzal> From: Vaibhav Bedia <vaibhav.bedia@ti.com>
> > 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.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
Date: Mon, 5 Mar 2012 15:14:13 -0800 [thread overview]
Message-ID: <20120305231413.GP12083@atomide.com> (raw)
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433179FC35@DBDE01.ent.ti.com>
* Bedia, Vaibhav <vaibhav.bedia@ti.com> [120213 07:36]:
> On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
> > >>>>> "Afzal" == Afzal Mohammed <afzal@ti.com> writes:
> >
> > Afzal> From: Vaibhav Bedia <vaibhav.bedia@ti.com>
> > 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.
Regards,
Tony
next prev parent reply other threads:[~2012-03-05 23:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 6:15 [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal) Afzal Mohammed
2012-02-13 6:15 ` Afzal Mohammed
2012-02-13 14:24 ` Peter Korsgaard
2012-02-13 14:24 ` Peter Korsgaard
2012-02-13 16:07 ` Bedia, Vaibhav
2012-02-13 16:07 ` Bedia, Vaibhav
2012-03-05 23:14 ` Tony Lindgren [this message]
2012-03-05 23:14 ` Tony Lindgren
2012-03-07 9:56 ` Hiremath, Vaibhav
2012-03-07 9:56 ` Hiremath, Vaibhav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120305231413.GP12083@atomide.com \
--to=tony@atomide.com \
--cc=afzal@ti.com \
--cc=hvaibhav@ti.com \
--cc=jacmet@sunsite.dk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=vaibhav.bedia@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.