RE: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
On Tue, Mar 06, 2012 at 04:44:13, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [120213 07:36]:
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@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_ 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
* Bedia, Vaibhav vaibhav.be...@ti.com [120213 07:36]:
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@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_ checks.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@ti.com
Afzal Update SRAM start size for am33xx SoC's.
Afzal Note: cpu_is_34xx() is true for am33xx also. Doing
Afzal cpu_is_am33xx() check after cpu_is_34xx() will not
Afzal achieve what we want due to the above reason.
Afzal Hence cpu_is_am33xx() is done before cpu_is_34xx()
Afzal } else {
Afzal - if (cpu_is_omap34xx()) {
Afzal + if (cpu_is_am33xx()) {
Afzal + omap_sram_start = AM33XX_SRAM_PA;
Afzal + omap_sram_size = 0x1; /* 64K */
Afzal + } else if (cpu_is_omap34xx()) {
Afzal omap_sram_start = OMAP3_SRAM_PA;
Afzal omap_sram_size = 0x1; /* 64K */
I don't particular know the omap sram stuff, but doesn't the 33xx have
2x 64K blocks of SRAM?
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.
Afzal +}
Afzal +
Afzal int __init omap_sram_init(void)
Afzal {
Afzal omap_detect_sram();
Afzal @@ -379,6 +387,8 @@ int __init omap_sram_init(void)
Afzal omap242x_sram_init();
Afzal else if (cpu_is_omap2430())
Afzal omap243x_sram_init();
Afzal + else if (cpu_is_am33xx())
Afzal + am33xx_sram_init();
Afzal else if (cpu_is_omap34xx())
Afzal omap34xx_sram_init();
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@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 ;)
Regards,
Vaibhav B.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
