[PATCH] ARM: shmobile: Include all 2 GiB of memory on APE6EVM

[Simon Horman]

On Fri, Nov 08, 2013 at 03:26:23PM +0900, Simon Horman wrote:
> On Wed, Nov 06, 2013 at 06:48:45PM +0900, Magnus Damm wrote:
> > Hi Simon,
> > 
> > On Wed, Nov 6, 2013 at 10:48 AM, Simon Horman <horms at verge.net.au> wrote:
> > > On Thu, Oct 31, 2013 at 05:02:13PM +0900, Magnus Damm wrote:
> > >> Hi Simon,
> > >>
> > >> On Thu, Oct 31, 2013 at 1:20 PM, Simon Horman <horms at verge.net.au> wrote:
> > >> > On Thu, Oct 31, 2013 at 12:15:49PM +0900, Magnus Damm wrote:
> > >> >> From: Takashi Yoshii <takasi-y at ops.dti.ne.jp>
> > >> >>
> > >> >> Add 1GiB of DRAM at 0x2_0000_0000 to support the full 2GiB
> > >> >> of APE6EVM system memory.
> > >> >>
> > >> >> Signed-off-by: Takashi Yoshii <takasi-y at ops.dti.ne.jp>
> > >> >> Signed-off-by: Magnus Damm <damm at opensource.se>
> > >> >> ---
> > >> >>
> > >> >>  For correct run time operation regardless of kernel configuration
> > >> >>  ARM patches 7863/1 and 7864/1 are needed.
> > >> >
> > >> > I take it that I should wait for those patches before applying this one.
> > >>
> > >> That's probably a good idea. RMK has applied them to "git-curr", so I
> > >> suppose they are queued up for something at least:
> > >>
> > >> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7863/1
> > >
> > > I have also sighted them in linux-next.
> > > So I expect they will show up in v3.13-rc1 or thereabouts.

v3.13-rc1 is released and I have rebased the branches in the renesas tree
on top of it. Should I go ahead and queue up this patch and its 3 friends:

	ARM: shmobile: Include all 2 GiB of memory on APE6EVM DT Ref
	ARM: shmobile: Include all 4 GiB of memory on Lager
	ARM: shmobile: Include all 4 GiB of memory on Lager DT Ref

> > >
> > >> > With those two patches and this one applied on top of
> > >> > renesas-devel-v3.12-rc7-20131030 I was able to successfully
> > >> > boot an ape6evm board. But /proc/meminfo still indicates only 1Gb of
> > >> > memory. What am I missing.
> > >>
> > >> You probably need to enable HIGHMEM and LPAE to be able to access to
> > >> all memory. Same thing on Lager, to get the full 4GiB you need to
> > >> select those in your kernel configuration too.
> > >
> > > Thanks, I have been able to successfully test all 4 patches in this
> > > series with those settings enabled.
> > >
> > > Tested-by: Simon Horman <horms+renesas at verge.net.au>
> > >
> > >> Please note that having memory located on 64-bit addresses may break
> > >> some drivers doing bus mastering or using the DMAC. These drivers need
> > >> to be fixed both with short term DMA zone workarounds and proper
> > >> 64-bit address support whenever possible.
> > >>
> > >> So if I could suggest a policy then having LPAE=n in defconfig for the
> > >> C board code for default stable operation. This together with LPAE=y
> > >> in the case of DT reference and/or Multiplatform where we can be a bit
> > >> more experimental. I don't care enough to send defconfig patches, but
> > >> if some issue comes up then perhaps adjusting the defconfig to disable
> > >> LPAE may work well as a workaround.
> > >
> > > Thanks.
> > >
> > > As it stands the defconfig for both APE6EVM and Lager lead to a
> > > configuration with LPAE disabled, although neither explicitly disable LPAE.
> > > I think it is best to leave things as-is in this regards and explicitly
> > > disable LPAE in the defconfigs if the need arises.
> > >
> > > While looking over this I noticed that the APE6EVM defconfig selects
> > > HIGHMEM while the Lager defconfig does not and it is not selected in the
> > > resulting config. Would it be worth updating the Lager defconfig to enable
> > > HIGHMEM? If so, I'll make a patch.
> > 
> > Thanks. I think it mainly makes sense to enable LPAE and HIGHMEM
> > together, so easiest is probably just to wait with both Lager and
> > APE6EVM.
> 
> Sure. I will immediately do nothing :)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>