| Message ID | 1348861072-14507-5-git-send-email-mporter@ti.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
Hi Matt, On 9/29/2012 1:07 AM, Matt Porter wrote: > L3RAM (shared SRAM) is needed for use by several drivers. > This creates a genalloc pool and a hook for the platform code > to provide the struct gen_pool * in platform data. > > Signed-off-by: Matt Porter <mporter@ti.com> I am not sure if any of the DaVinci devices have a need to allocate from *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure if there is much point in trying to allocate from there. Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM allocation on DA850 makes sense for your case? If yes, can you repost with Ben's patch included in your series instead of this patch? I would prefer that over creating a new pool for shared RAM. Thanks, Sekhar [1] https://patchwork.kernel.org/patch/840552/ Thanks, Sekhar
On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: > Hi Matt, > > On 9/29/2012 1:07 AM, Matt Porter wrote: > > L3RAM (shared SRAM) is needed for use by several drivers. > > This creates a genalloc pool and a hook for the platform code > > to provide the struct gen_pool * in platform data. > > > > Signed-off-by: Matt Porter <mporter@ti.com> > > I am not sure if any of the DaVinci devices have a need to allocate from > *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci > devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure > if there is much point in trying to allocate from there. > > Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM > allocation on DA850 makes sense for your case? If yes, can you repost > with Ben's patch included in your series instead of this patch? I would > prefer that over creating a new pool for shared RAM. Hrm, I did look at Ben's earlier patch. The reason I added a separate pool mostly was so I didn't have to touch the PM code at all. That can continue using the private SRAM API with the ARM RAM as it is now. The idea here was to allow that to be separate since no other bus masters can access the ARM RAM anyway and do something that didn't require regression testing PM. Also, I figured there's really no reason to use even a tiny bit of the shared SRAM on PM if we have that ARM RAM there and working fine for that use case. The other thing is that Ben's patch needs to be rewritten to at least have the hook I added so we can provide the gen_pool in platform data. If you prefer this path still, I can add the needed hook on top of his original patch. Ultimately, I only *need* genalloc support for the shared sram so I can remove the private SRAM API from uio_pruss...so I'm happy with any way to get at it. Oh, and to be honest...it's not just for uio_pruss, but also to cleanly remove the private SRAM API usage from the davinci ASoC driver too. Thanks, Matt
On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote: > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: >> Hi Matt, >> >> On 9/29/2012 1:07 AM, Matt Porter wrote: >> > L3RAM (shared SRAM) is needed for use by several drivers. >> > This creates a genalloc pool and a hook for the platform code >> > to provide the struct gen_pool * in platform data. >> > >> > Signed-off-by: Matt Porter <mporter@ti.com> >> >> I am not sure if any of the DaVinci devices have a need to allocate from >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure >> if there is much point in trying to allocate from there. >> >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM >> allocation on DA850 makes sense for your case? If yes, can you repost >> with Ben's patch included in your series instead of this patch? I would >> prefer that over creating a new pool for shared RAM. > > Hrm, I did look at Ben's earlier patch. The reason I added a separate > pool mostly was so I didn't have to touch the PM code at all. That can > continue using the private SRAM API with the ARM RAM as it is now. The > idea here was to allow that to be separate since no other bus masters > can access the ARM RAM anyway and do something that didn't require > regression testing PM. Also, I figured there's really no reason to use > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there > and working fine for that use case. > [...] I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as you said, Sekhar) in any fashion is preferable to moving suspend support into shared RAM. There is more of it (128K on L138) but also more pressure on allocations there since there are more clients. I appreciate that you are trying to preserve prior efforts in attempted merging of SRAM support -- thank you for that; however, that patch [1] was just an import of Subashish Ghosh's patch [2] -- I chose _that_ implementation option then mainly because I imagined it would be the least risky to get accepted upstream and not because of any particular technical merits. Best Regards, Ben Gardiner [1] https://patchwork.kernel.org/patch/840552/ [2] https://patchwork.kernel.org/patch/549351/ --- Nanometrics Inc. http://www.nanometrics.ca
On Mon, Oct 01, 2012 at 08:32:42AM -0400, Matt Porter wrote: > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: > > Hi Matt, > > > > On 9/29/2012 1:07 AM, Matt Porter wrote: > > > L3RAM (shared SRAM) is needed for use by several drivers. > > > This creates a genalloc pool and a hook for the platform code > > > to provide the struct gen_pool * in platform data. > > > > > > Signed-off-by: Matt Porter <mporter@ti.com> > > > > I am not sure if any of the DaVinci devices have a need to allocate from > > *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci > > devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure > > if there is much point in trying to allocate from there. > > > > Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM > > allocation on DA850 makes sense for your case? If yes, can you repost > > with Ben's patch included in your series instead of this patch? I would > > prefer that over creating a new pool for shared RAM. > > Hrm, I did look at Ben's earlier patch. The reason I added a separate > pool mostly was so I didn't have to touch the PM code at all. That can > continue using the private SRAM API with the ARM RAM as it is now. The > idea here was to allow that to be separate since no other bus masters > can access the ARM RAM anyway and do something that didn't require > regression testing PM. Also, I figured there's really no reason to use > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there > and working fine for that use case. > > The other thing is that Ben's patch needs to be rewritten to at least > have the hook I added so we can provide the gen_pool in platform data. > If you prefer this path still, I can add the needed hook on top of his > original patch. Ultimately, I only *need* genalloc support for the > shared sram so I can remove the private SRAM API from uio_pruss...so I'm > happy with any way to get at it. > > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly > remove the private SRAM API usage from the davinci ASoC driver too. [and replying to myself :)] Looking at the older parts (DM355/365/DM64xx) in more detail now, I see that to get rid of SRAM API in davinci ASoC, we'll have a similar hook to get the local ARM RAM gen_pool pointer necessary to support ping-pong to that pool since that's able to be accessed from EDMA on those parts. Ultimately, the approach is the same, it's just a matter of if we want to fully leverage both SRAM pools on DA850 and friends. -Matt
On 10/1/2012 6:02 PM, Matt Porter wrote: > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: >> Hi Matt, >> >> On 9/29/2012 1:07 AM, Matt Porter wrote: >>> L3RAM (shared SRAM) is needed for use by several drivers. >>> This creates a genalloc pool and a hook for the platform code >>> to provide the struct gen_pool * in platform data. >>> >>> Signed-off-by: Matt Porter <mporter@ti.com> >> >> I am not sure if any of the DaVinci devices have a need to allocate from >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure >> if there is much point in trying to allocate from there. >> >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM >> allocation on DA850 makes sense for your case? If yes, can you repost >> with Ben's patch included in your series instead of this patch? I would >> prefer that over creating a new pool for shared RAM. > > Hrm, I did look at Ben's earlier patch. The reason I added a separate > pool mostly was so I didn't have to touch the PM code at all. That can > continue using the private SRAM API with the ARM RAM as it is now. The But you dont have to touch the PM code. PM code can continue using SRAM API. I have verified in the past that PM can work using shared RAM. > idea here was to allow that to be separate since no other bus masters > can access the ARM RAM anyway and do something that didn't require > regression testing PM. Also, I figured there's really no reason to use > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there > and working fine for that use case. I see no reason why PM would break with shared RAM. I have not even seen reports of shared RAM being short of size so we need to save space by having PM code in ARM RAM. I can test the changes before the code is committed and it will get tested in linux-next as well. > The other thing is that Ben's patch needs to be rewritten to at least > have the hook I added so we can provide the gen_pool in platform data. > If you prefer this path still, I can add the needed hook on top of his > original patch. Ultimately, I only *need* genalloc support for the > shared sram so I can remove the private SRAM API from uio_pruss...so I'm > happy with any way to get at it. Right, I prefer just adding the hook so that genalloc can be used along with SRAM API. > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly > remove the private SRAM API usage from the davinci ASoC driver too. Audio can use the shared RAM too. And once all users of the SRAM API are gone, only the hook to help pass the gen_pool as platform data needs to remain. Thanks, Sekhar
On 10/1/2012 7:20 PM, Ben Gardiner wrote: > On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote: >> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: >>> Hi Matt, >>> >>> On 9/29/2012 1:07 AM, Matt Porter wrote: >>>> L3RAM (shared SRAM) is needed for use by several drivers. >>>> This creates a genalloc pool and a hook for the platform code >>>> to provide the struct gen_pool * in platform data. >>>> >>>> Signed-off-by: Matt Porter <mporter@ti.com> >>> >>> I am not sure if any of the DaVinci devices have a need to allocate from >>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci >>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure >>> if there is much point in trying to allocate from there. >>> >>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM >>> allocation on DA850 makes sense for your case? If yes, can you repost >>> with Ben's patch included in your series instead of this patch? I would >>> prefer that over creating a new pool for shared RAM. >> >> Hrm, I did look at Ben's earlier patch. The reason I added a separate >> pool mostly was so I didn't have to touch the PM code at all. That can >> continue using the private SRAM API with the ARM RAM as it is now. The >> idea here was to allow that to be separate since no other bus masters >> can access the ARM RAM anyway and do something that didn't require >> regression testing PM. Also, I figured there's really no reason to use >> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there >> and working fine for that use case. >> [...] > > I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as > you said, Sekhar) in any fashion is preferable to moving suspend > support into shared RAM. There is more of it (128K on L138) but also > more pressure on allocations there since there are more clients. There is where I would like to see more information on who the potential clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138, there should be more than enough for PM, Audio and PRU. I haven't checked the PM code size lately but it should be fairly small and I can check the actual number if that helps. So, adding a new pool just to save on those bytes doesn't sound like helping a lot. > I appreciate that you are trying to preserve prior efforts in > attempted merging of SRAM support -- thank you for that; however, that > patch [1] was just an import of Subashish Ghosh's patch [2] -- I > chose _that_ implementation option then mainly because I imagined it > would be the least risky to get accepted upstream and not because of > any particular technical merits. Its not a question of prior effort since Matt has already put in the effort too. I am yet unconvinced that we need to add support to manage two blocks of SoC internal RAM on DA850 in the kernel today. That's all. Thanks, Sekhar
On Tue, Oct 2, 2012 at 7:13 AM, Sekhar Nori <nsekhar@ti.com> wrote: > On 10/1/2012 7:20 PM, Ben Gardiner wrote: >> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote: >>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: >>>> Hi Matt, >>>> >>>> On 9/29/2012 1:07 AM, Matt Porter wrote: >>>>> L3RAM (shared SRAM) is needed for use by several drivers. >>>>> This creates a genalloc pool and a hook for the platform code >>>>> to provide the struct gen_pool * in platform data. >>>>> >>>>> Signed-off-by: Matt Porter <mporter@ti.com> >>>> >>>> I am not sure if any of the DaVinci devices have a need to allocate from >>>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci >>>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure >>>> if there is much point in trying to allocate from there. >>>> >>>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM >>>> allocation on DA850 makes sense for your case? If yes, can you repost >>>> with Ben's patch included in your series instead of this patch? I would >>>> prefer that over creating a new pool for shared RAM. >>> >>> Hrm, I did look at Ben's earlier patch. The reason I added a separate >>> pool mostly was so I didn't have to touch the PM code at all. That can >>> continue using the private SRAM API with the ARM RAM as it is now. The >>> idea here was to allow that to be separate since no other bus masters >>> can access the ARM RAM anyway and do something that didn't require >>> regression testing PM. Also, I figured there's really no reason to use >>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there >>> and working fine for that use case. >>> [...] >> >> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as >> you said, Sekhar) in any fashion is preferable to moving suspend >> support into shared RAM. There is more of it (128K on L138) but also >> more pressure on allocations there since there are more clients. > > There is where I would like to see more information on who the potential > clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138, > there should be more than enough for PM, Audio and PRU. I haven't > checked the PM code size lately but it should be fairly small and I can > check the actual number if that helps. So, adding a new pool just to > save on those bytes doesn't sound like helping a lot. Good points. I suppose that the list would decrease also on L138 if davinci-pcm ping-pong buffers were removed from SRAM. >> I appreciate that you are trying to preserve prior efforts in >> attempted merging of SRAM support -- thank you for that; however, that >> patch [1] was just an import of Subashish Ghosh's patch [2] -- I >> chose _that_ implementation option then mainly because I imagined it >> would be the least risky to get accepted upstream and not because of >> any particular technical merits. > > Its not a question of prior effort since Matt has already put in the > effort too. I am yet unconvinced that we need to add support to manage > two blocks of SoC internal RAM on DA850 in the kernel today. That's all. Understood. Thank you, Sekhar. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca
On Tue, Oct 02, 2012 at 03:32:55PM +0530, Sekhar Nori wrote: > On 10/1/2012 6:02 PM, Matt Porter wrote: > > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: > >> Hi Matt, > >> > >> On 9/29/2012 1:07 AM, Matt Porter wrote: > >>> L3RAM (shared SRAM) is needed for use by several drivers. > >>> This creates a genalloc pool and a hook for the platform code > >>> to provide the struct gen_pool * in platform data. > >>> > >>> Signed-off-by: Matt Porter <mporter@ti.com> > >> > >> I am not sure if any of the DaVinci devices have a need to allocate from > >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci > >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure > >> if there is much point in trying to allocate from there. > >> > >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM > >> allocation on DA850 makes sense for your case? If yes, can you repost > >> with Ben's patch included in your series instead of this patch? I would > >> prefer that over creating a new pool for shared RAM. > > > > Hrm, I did look at Ben's earlier patch. The reason I added a separate > > pool mostly was so I didn't have to touch the PM code at all. That can > > continue using the private SRAM API with the ARM RAM as it is now. The > > But you dont have to touch the PM code. PM code can continue using SRAM > API. I have verified in the past that PM can work using shared RAM. > > > idea here was to allow that to be separate since no other bus masters > > can access the ARM RAM anyway and do something that didn't require > > regression testing PM. Also, I figured there's really no reason to use > > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there > > and working fine for that use case. > > I see no reason why PM would break with shared RAM. I have not even seen > reports of shared RAM being short of size so we need to save space by > having PM code in ARM RAM. I can test the changes before the code is > committed and it will get tested in linux-next as well. Ok, sounds good to me. > > The other thing is that Ben's patch needs to be rewritten to at least > > have the hook I added so we can provide the gen_pool in platform data. > > If you prefer this path still, I can add the needed hook on top of his > > original patch. Ultimately, I only *need* genalloc support for the > > shared sram so I can remove the private SRAM API from uio_pruss...so I'm > > happy with any way to get at it. > > Right, I prefer just adding the hook so that genalloc can be used along > with SRAM API. Ok. > > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly > > remove the private SRAM API usage from the davinci ASoC driver too. > > Audio can use the shared RAM too. And once all users of the SRAM API are > gone, only the hook to help pass the gen_pool as platform data needs to > remain. Right, I think we are on the same page now. I'll post an update to Ben's original patch with required gen_pool hook for pdata use. I noticed the beginning of DT support for davinci and the DT-based genalloc driver, https://patchwork.kernel.org/patch/1421961/, fits into that well. -Matt
On Tue, Oct 02, 2012 at 04:43:59PM +0530, Sekhar Nori wrote: > On 10/1/2012 7:20 PM, Ben Gardiner wrote: > > On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote: > >> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: > >>> Hi Matt, > >>> > >>> On 9/29/2012 1:07 AM, Matt Porter wrote: > >>>> L3RAM (shared SRAM) is needed for use by several drivers. > >>>> This creates a genalloc pool and a hook for the platform code > >>>> to provide the struct gen_pool * in platform data. > >>>> > >>>> Signed-off-by: Matt Porter <mporter@ti.com> > >>> > >>> I am not sure if any of the DaVinci devices have a need to allocate from > >>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci > >>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure > >>> if there is much point in trying to allocate from there. > >>> > >>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM > >>> allocation on DA850 makes sense for your case? If yes, can you repost > >>> with Ben's patch included in your series instead of this patch? I would > >>> prefer that over creating a new pool for shared RAM. > >> > >> Hrm, I did look at Ben's earlier patch. The reason I added a separate > >> pool mostly was so I didn't have to touch the PM code at all. That can > >> continue using the private SRAM API with the ARM RAM as it is now. The > >> idea here was to allow that to be separate since no other bus masters > >> can access the ARM RAM anyway and do something that didn't require > >> regression testing PM. Also, I figured there's really no reason to use > >> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there > >> and working fine for that use case. > >> [...] > > > > I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as > > you said, Sekhar) in any fashion is preferable to moving suspend > > support into shared RAM. There is more of it (128K on L138) but also > > more pressure on allocations there since there are more clients. > > There is where I would like to see more information on who the potential > clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138, > there should be more than enough for PM, Audio and PRU. I haven't > checked the PM code size lately but it should be fairly small and I can > check the actual number if that helps. So, adding a new pool just to > save on those bytes doesn't sound like helping a lot. The only wildcard is PRU usage due to the small per-PRU memory on PRUss v1...though no sense in speculating further until somebody demonstrates a need. > > I appreciate that you are trying to preserve prior efforts in > > attempted merging of SRAM support -- thank you for that; however, that > > patch [1] was just an import of Subashish Ghosh's patch [2] -- I > > chose _that_ implementation option then mainly because I imagined it > > would be the least risky to get accepted upstream and not because of > > any particular technical merits. > > Its not a question of prior effort since Matt has already put in the > effort too. I am yet unconvinced that we need to add support to manage > two blocks of SoC internal RAM on DA850 in the kernel today. That's all. Yeah, I've come to agree with that. If somebody ends up needing that extra 8K of local ram on L138 then they can add support. -Matt
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h index bdc4aa8..5a2ea37 100644 --- a/arch/arm/mach-davinci/include/mach/common.h +++ b/arch/arm/mach-davinci/include/mach/common.h @@ -77,6 +77,8 @@ struct davinci_soc_info { struct emac_platform_data *emac_pdata; dma_addr_t sram_dma; unsigned sram_len; + dma_addr_t l3ram_dma; + unsigned l3ram_len; }; extern struct davinci_soc_info davinci_soc_info; diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h index 111f7cc..1a81e5b 100644 --- a/arch/arm/mach-davinci/include/mach/sram.h +++ b/arch/arm/mach-davinci/include/mach/sram.h @@ -24,4 +24,7 @@ extern void *sram_alloc(size_t len, dma_addr_t *dma); extern void sram_free(void *addr, size_t len); +/* Get the l3ram struct gen_pool * for use in platform data */ +extern struct gen_pool *sram_get_l3ram_pool(void); + #endif /* __MACH_SRAM_H */ diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c index db0f778..e609fa3 100644 --- a/arch/arm/mach-davinci/sram.c +++ b/arch/arm/mach-davinci/sram.c @@ -15,7 +15,12 @@ #include <mach/common.h> #include <mach/sram.h> -static struct gen_pool *sram_pool; +static struct gen_pool *sram_pool, *l3ram_pool; + +struct gen_pool *sram_get_l3ram_pool(void) +{ + return l3ram_pool; +} void *sram_alloc(size_t len, dma_addr_t *dma) { @@ -54,6 +59,9 @@ EXPORT_SYMBOL(sram_free); static int __init sram_init(void) { unsigned len = davinci_soc_info.sram_len; + unsigned l3ram_dma = davinci_soc_info.l3ram_dma; + unsigned l3ram_len = davinci_soc_info.l3ram_len; + void *l3ram_virt; int status = 0; if (len) { @@ -65,6 +73,24 @@ static int __init sram_init(void) if (sram_pool) status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1); WARN_ON(status < 0); + + if (l3ram_dma) { + l3ram_pool = + gen_pool_create(ilog2(SRAM_GRANULARITY), -1); + if (!l3ram_pool) + status = -ENOMEM; + } + + if (l3ram_pool) { + l3ram_virt = ioremap(l3ram_dma, l3ram_len); + if (l3ram_virt) + status = gen_pool_add_virt(l3ram_pool, + (unsigned long)l3ram_virt, + l3ram_dma, l3ram_len, -1); + else + status = -ENOMEM; + } + return status; } core_initcall(sram_init);
L3RAM (shared SRAM) is needed for use by several drivers. This creates a genalloc pool and a hook for the platform code to provide the struct gen_pool * in platform data. Signed-off-by: Matt Porter <mporter@ti.com> --- arch/arm/mach-davinci/include/mach/common.h | 2 ++ arch/arm/mach-davinci/include/mach/sram.h | 3 +++ arch/arm/mach-davinci/sram.c | 28 ++++++++++++++++++++++++++- 3 files changed, 32 insertions(+), 1 deletion(-)