From: Sekhar Nori <nsekhar@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: tony@atomide.com, linux-omap@vger.kernel.org,
bcousson@baylibre.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT
Date: Tue, 27 Aug 2013 16:53:51 +0530 [thread overview]
Message-ID: <521C8C47.2000502@ti.com> (raw)
In-Reply-To: <1377598305-15539-3-git-send-email-rnayak@ti.com>
On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak wrote:
> Use drivers/misc/sram.c driver to manage SRAM on all DT only
> OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
> the existing private implementation.
>
> Address and size related data is removed from mach-omap2/sram.c
> and now passed to drivers/misc/sram.c from DT.
>
> Users can hence use general purpose allocator apis instead of
> OMAP private ones to manage and use SRAM.
>
> Currently there are no users on SRAM on these platfoms.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Nice getting rid of code.
> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
> index ca7277c..3f83b80 100644
> --- a/arch/arm/mach-omap2/sram.h
> +++ b/arch/arm/mach-omap2/sram.h
> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
> #else
> #define OMAP4_SRAM_PA 0x40300000
> #endif
> -#define AM33XX_SRAM_PA 0x40300000
I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
How about removing the iotable entry for SRAM on OMAP4 and converting
omap_barriers_init() to use the gen_pool API instead of passing an
incremented address to DT?
SRAM driver is a postcore initcall so I think you it will be ready
before first WFI hits (which is when the errata triggers).
Thanks,
Sekhar
WARNING: multiple messages have this Message-ID (diff)
From: nsekhar@ti.com (Sekhar Nori)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT
Date: Tue, 27 Aug 2013 16:53:51 +0530 [thread overview]
Message-ID: <521C8C47.2000502@ti.com> (raw)
In-Reply-To: <1377598305-15539-3-git-send-email-rnayak@ti.com>
On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak wrote:
> Use drivers/misc/sram.c driver to manage SRAM on all DT only
> OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
> the existing private implementation.
>
> Address and size related data is removed from mach-omap2/sram.c
> and now passed to drivers/misc/sram.c from DT.
>
> Users can hence use general purpose allocator apis instead of
> OMAP private ones to manage and use SRAM.
>
> Currently there are no users on SRAM on these platfoms.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Nice getting rid of code.
> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
> index ca7277c..3f83b80 100644
> --- a/arch/arm/mach-omap2/sram.h
> +++ b/arch/arm/mach-omap2/sram.h
> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
> #else
> #define OMAP4_SRAM_PA 0x40300000
> #endif
> -#define AM33XX_SRAM_PA 0x40300000
I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
How about removing the iotable entry for SRAM on OMAP4 and converting
omap_barriers_init() to use the gen_pool API instead of passing an
incremented address to DT?
SRAM driver is a postcore initcall so I think you it will be ready
before first WFI hits (which is when the errata triggers).
Thanks,
Sekhar
next prev parent reply other threads:[~2013-08-27 11:23 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 10:11 [PATCH 0/2] OMAP4+: Get rid of internal SRAM handling Rajendra Nayak
2013-08-27 10:11 ` Rajendra Nayak
2013-08-27 10:11 ` [PATCH 1/2] ARM: AM335x: Get rid of unused sram init function Rajendra Nayak
2013-08-27 10:11 ` Rajendra Nayak
2013-08-27 16:06 ` Dave Gerlach
2013-08-27 16:06 ` Dave Gerlach
2013-08-28 6:17 ` Rajendra Nayak
2013-08-28 6:17 ` Rajendra Nayak
2013-08-27 10:11 ` [PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT Rajendra Nayak
2013-08-27 10:11 ` Rajendra Nayak
2013-08-27 11:23 ` Sekhar Nori [this message]
2013-08-27 11:23 ` Sekhar Nori
2013-08-28 6:23 ` Rajendra Nayak
2013-08-28 6:23 ` Rajendra Nayak
2013-08-28 10:24 ` Sekhar Nori
2013-08-28 10:24 ` Sekhar Nori
2013-08-29 11:02 ` Rajendra Nayak
2013-08-29 11:02 ` Rajendra Nayak
2013-09-03 13:56 ` Russ Dill
2013-09-03 13:56 ` Russ Dill
2013-09-03 14:35 ` Lucas Stach
2013-09-03 14:35 ` Lucas Stach
2013-09-03 15:07 ` Russ Dill
2013-09-03 15:07 ` Russ Dill
2013-08-27 13:25 ` [PATCH 0/2] OMAP4+: Get rid of internal SRAM handling Santosh Shilimkar
2013-08-27 13:25 ` Santosh Shilimkar
2013-08-28 6:29 ` Rajendra Nayak
2013-08-28 6:29 ` Rajendra Nayak
2013-08-28 13:38 ` Santosh Shilimkar
2013-08-28 13:38 ` Santosh Shilimkar
2013-08-28 13:42 ` Rajendra Nayak
2013-08-28 13:42 ` Rajendra Nayak
2013-08-28 14:46 ` Santosh Shilimkar
2013-08-28 14:46 ` Santosh Shilimkar
2013-10-08 18:34 ` Tony Lindgren
2013-10-08 18:34 ` Tony Lindgren
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=521C8C47.2000502@ti.com \
--to=nsekhar@ti.com \
--cc=bcousson@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=rnayak@ti.com \
--cc=tony@atomide.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.