lkml.org 
[lkml]   [2017]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: n900 in next-20170901
* Tony Lindgren <tony@atomide.com> [171110 03:28]:
> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171110 00:10]:
> > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote:
> > > Hmm OK. Does your first patch above now have the initcall issue too?
> > > It boots if I make that also subsys_initcall and then I get:
> >
> > > [ 2.078094] vmalloc_pool_init: DMA: get vmalloc area: d0010000
> >
> > Yes, first patch has the initcall issue and it's intentional in order
> > to check the theory. I checked following log for this.
> >
> > - Boot failure
> > SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
> > SRAM_ADDR: omap_map_sram: V: 0xd0050000 - 0xd0057000
> >
> > - Boot success
> > SRAM_ADDR: omap_map_sram: P: 0x40208000 - 0x4020f000
> > SRAM_ADDR: omap_map_sram: V: 0xd0008000 - 0xd000f000
> >
> > When failure, virtual address for sram is higher than normal one due
> > to vmalloc area allocation in __dma_alloc_remap(). If it is deferred,
> > virtual address is the same with success case and then the system work.
> >
> > So, my next theory is that there is n900 specific assumption that sram
> > should have that address. Could you check if any working tree for n900
> > which doesn't have my CMA series work or not with adding
> > "arm/dma: vmalloc area allocation"?
>
> Oh I see, sorry I was not following you earlier. So you mean that
> by adding the vmalloc_pool_init() initcall the va mapping for SRAM
> changes.
>
> And yes, save_secure_ram_context seems to be doing some sketchy
> virt to phys calculation with sram_phy_addr_mask. Here's a small
> patch to fix that for your CMA series, maybe you can merge it
> with your series to avoid breaking booting for git bisect.
>
> Then I'll follow up on cleaning up save_secure_ram_context later.

Here's a better version, the static mapping did not get used.. It
just moved the area so it happened to work. It needs to be set
up as MT_MEMORY_RWX_NONCACHED instead.

Regards,

Tony

8< -------------------
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 9 Nov 2017 17:05:34 -0800
Subject: [PATCH] ARM: OMAP2+: Add static SRAM mapping for
save_secure_ram_context

With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it
was noticed that n900 stopped booting. After investigating it turned
out that n900 save_secure_ram_context does some whacky virtual to
physical address translation for the SRAM data address.

Let's fix this for CMA changes by adding a static mapping for SRAM
on omap3. Then we can follow up with a patch to clean up the address
translation in save_secure_ram_context later on.

Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/io.c | 6 ++++++
arch/arm/mach-omap2/iomap.h | 4 ++++
2 files changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -139,6 +139,12 @@ static struct map_desc omap243x_io_desc[] __initdata = {

#ifdef CONFIG_ARCH_OMAP3
static struct map_desc omap34xx_io_desc[] __initdata = {
+ {
+ .virtual = OMAP34XX_SRAM_VIRT,
+ .pfn = __phys_to_pfn(OMAP34XX_SRAM_PHYS),
+ .length = OMAP34XX_SRAM_SIZE,
+ .type = MT_MEMORY_RWX_NONCACHED
+ },
{
.virtual = L3_34XX_VIRT,
.pfn = __phys_to_pfn(L3_34XX_PHYS),
diff --git a/arch/arm/mach-omap2/iomap.h b/arch/arm/mach-omap2/iomap.h
--- a/arch/arm/mach-omap2/iomap.h
+++ b/arch/arm/mach-omap2/iomap.h
@@ -123,6 +123,10 @@
* VPOM3430 was not working for Int controller
*/

+#define OMAP34XX_SRAM_PHYS 0x40200000
+#define OMAP34XX_SRAM_VIRT 0xd0010000
+#define OMAP34XX_SRAM_SIZE 0x10000
+
#define L4_PER_34XX_PHYS L4_PER_34XX_BASE
/* 0x49000000 --> 0xfb000000 */
#define L4_PER_34XX_VIRT (L4_PER_34XX_PHYS + OMAP2_L4_IO_OFFSET)
--
2.15.0
\
 
 \ /
  Last update: 2017-11-10 07:20    [W:0.122 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site