From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal) Date: Mon, 5 Mar 2012 15:14:13 -0800 Message-ID: <20120305231413.GP12083@atomide.com> References: <1329113715-7634-1-git-send-email-afzal@ti.com> <87fweeyfp6.fsf@macbook.be.48ers.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:24434 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757410Ab2CEXOS (ORCPT ); Mon, 5 Mar 2012 18:14:18 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Bedia, Vaibhav" Cc: Peter Korsgaard , "Mohammed, Afzal" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "Nori, Sekhar" , "Hiremath, Vaibhav" * Bedia, Vaibhav [120213 07:36]: > On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote: > > >>>>> "Afzal" == Afzal Mohammed writes: > > > > Afzal> From: Vaibhav Bedia > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Mon, 5 Mar 2012 15:14:13 -0800 Subject: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal) In-Reply-To: References: <1329113715-7634-1-git-send-email-afzal@ti.com> <87fweeyfp6.fsf@macbook.be.48ers.dk> Message-ID: <20120305231413.GP12083@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Bedia, Vaibhav [120213 07:36]: > On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote: > > >>>>> "Afzal" == Afzal Mohammed writes: > > > > Afzal> From: Vaibhav Bedia > > 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