* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
@ 2011-09-23 13:32 Nicolas Pitre
2011-09-29 15:59 ` Rob Herring
2011-10-04 18:49 ` Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
0 siblings, 2 replies; 14+ messages in thread
From: Nicolas Pitre @ 2011-09-23 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Russell, please pull
git://git.linaro.org/people/nico/linux vmalloc
This patch series removes all instances of mach/vmalloc.h in order to
have a more unified memory map across all ARM architectures. To do so,
the static mappings are moved inside the vmalloc area. And finally this
allows for a generic optimization to ioremap where static mappings are
reused whenever possible, using common code instead of having this
duplicated in a couple places.
This also provides a net reduction of more than 1200 lines of code.
One regression was discovered on shmobile during testing because that
platform asks for 158MB of consistent DMA memory while the documented
maximum is 14MB. Inspection of the code doesn't tell why this is
required, and listed maintainers did not respond yet after a couple
days. So a temporary exception to the definition of VMALLOC_END was
added for CONFIG_SHMOBILE and a noisy warning to get those maintainers'
attention.
Based on v3.1-rc4.
Nicolas Pitre (21):
ARM: mach-dove: remove inclusion of <mach/vmalloc.h>
ARM: mach-prima2: don't define SIRFSOC_VA in terms of VMALLOC_END
ARM: plat-mxc: remove inclusion of <mach/vmalloc.h>
ARM: plat-omap: don't define OMAP1_SRAM_VA in terms of VMALLOC_END
ARM: mach-at91: remove arch specific special handling for ioremap
ARM: mach-davinci: remove arch specific special handling for ioremap
ARM: mach-tegra: remove arch specific special handling for ioremap
ARM: plat-omap: remove arch specific special handling for ioremap
ARM: mach-bcmring: use proper constant to identify DMA memory area
ARM: mach-orion5x: remove arch specific special handling for ioremap
ARM: mach-kirkwood: remove arch specific special handling for ioremap
ARM: mach-ixp23xx: remove arch specific special handling for ioremap
ARM: plat-iop: remove arch specific special handling for ioremap
ARM: sort the meminfo array earlier
ARM: move initialization of the high_memory variable earlier
mm: add vm_area_add_early()
ARM: move iotable mappings within the vmalloc region
ARM: simplify __iounmap() when dealing with section based mapping
ARM: add generic ioremap optimization by reusing static mappings
ARM: big removal of now unused vmalloc.h files
ARM: move VMALLOC_END down temporarily for shmobile
Documentation/arm/memory.txt | 11 +-
arch/arm/include/asm/pgtable.h | 13 +-
arch/arm/kernel/setup.c | 8 +
arch/arm/mach-at91/include/mach/io.h | 8 -
arch/arm/mach-at91/include/mach/vmalloc.h | 26 ---
arch/arm/mach-at91/setup.c | 18 --
arch/arm/mach-bcmring/dma.c | 2 +-
arch/arm/mach-bcmring/include/mach/vmalloc.h | 25 ---
arch/arm/mach-clps711x/include/mach/vmalloc.h | 20 ---
arch/arm/mach-cns3xxx/include/mach/vmalloc.h | 11 --
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/include/mach/io.h | 8 -
arch/arm/mach-davinci/include/mach/vmalloc.h | 14 --
arch/arm/mach-davinci/io.c | 48 ------
arch/arm/mach-dove/include/mach/dove.h | 2 -
arch/arm/mach-dove/include/mach/vmalloc.h | 5 -
arch/arm/mach-ebsa110/include/mach/vmalloc.h | 10 --
arch/arm/mach-ep93xx/include/mach/vmalloc.h | 5 -
arch/arm/mach-exynos4/include/mach/vmalloc.h | 22 ---
arch/arm/mach-footbridge/include/mach/vmalloc.h | 10 --
arch/arm/mach-gemini/include/mach/vmalloc.h | 10 --
arch/arm/mach-h720x/include/mach/vmalloc.h | 10 --
arch/arm/mach-integrator/include/mach/vmalloc.h | 20 ---
arch/arm/mach-iop13xx/include/mach/vmalloc.h | 4 -
arch/arm/mach-iop32x/include/mach/io.h | 7 -
arch/arm/mach-iop32x/include/mach/vmalloc.h | 5 -
arch/arm/mach-iop33x/include/mach/io.h | 7 -
arch/arm/mach-iop33x/include/mach/vmalloc.h | 5 -
arch/arm/mach-ixp2000/include/mach/vmalloc.h | 20 ---
arch/arm/mach-ixp23xx/include/mach/io.h | 29 ----
arch/arm/mach-ixp23xx/include/mach/vmalloc.h | 10 --
arch/arm/mach-ixp4xx/include/mach/vmalloc.h | 5 -
arch/arm/mach-kirkwood/include/mach/io.h | 25 ---
arch/arm/mach-kirkwood/include/mach/vmalloc.h | 5 -
arch/arm/mach-ks8695/include/mach/vmalloc.h | 19 ---
arch/arm/mach-lpc32xx/include/mach/vmalloc.h | 24 ---
arch/arm/mach-mmp/include/mach/vmalloc.h | 5 -
arch/arm/mach-msm/include/mach/vmalloc.h | 22 ---
arch/arm/mach-mv78xx0/include/mach/vmalloc.h | 5 -
arch/arm/mach-mxs/include/mach/vmalloc.h | 22 ---
arch/arm/mach-netx/include/mach/vmalloc.h | 19 ---
arch/arm/mach-nomadik/include/mach/vmalloc.h | 2 -
arch/arm/mach-nuc93x/include/mach/vmalloc.h | 23 ---
arch/arm/mach-omap1/include/mach/vmalloc.h | 20 ---
arch/arm/mach-omap2/include/mach/vmalloc.h | 20 ---
arch/arm/mach-orion5x/include/mach/io.h | 25 ---
arch/arm/mach-orion5x/include/mach/vmalloc.h | 5 -
arch/arm/mach-pnx4008/include/mach/vmalloc.h | 20 ---
arch/arm/mach-prima2/include/mach/map.h | 6 +-
arch/arm/mach-prima2/include/mach/vmalloc.h | 16 --
arch/arm/mach-pxa/include/mach/vmalloc.h | 11 --
arch/arm/mach-realview/include/mach/vmalloc.h | 21 ---
arch/arm/mach-rpc/include/mach/vmalloc.h | 10 --
arch/arm/mach-s3c2410/include/mach/vmalloc.h | 20 ---
arch/arm/mach-s3c64xx/include/mach/vmalloc.h | 20 ---
arch/arm/mach-s5p64x0/include/mach/vmalloc.h | 20 ---
arch/arm/mach-s5pc100/include/mach/vmalloc.h | 17 --
arch/arm/mach-s5pv210/include/mach/vmalloc.h | 22 ---
arch/arm/mach-sa1100/include/mach/vmalloc.h | 4 -
arch/arm/mach-shark/include/mach/vmalloc.h | 4 -
arch/arm/mach-shmobile/include/mach/vmalloc.h | 7 -
arch/arm/mach-spear3xx/include/mach/vmalloc.h | 19 ---
arch/arm/mach-spear6xx/include/mach/vmalloc.h | 19 ---
arch/arm/mach-tegra/include/mach/io.h | 6 -
arch/arm/mach-tegra/include/mach/vmalloc.h | 28 ----
arch/arm/mach-tegra/io.c | 21 ---
arch/arm/mach-u300/include/mach/vmalloc.h | 12 --
arch/arm/mach-ux500/include/mach/vmalloc.h | 18 --
arch/arm/mach-versatile/include/mach/vmalloc.h | 21 ---
arch/arm/mach-vexpress/include/mach/vmalloc.h | 21 ---
arch/arm/mach-vt8500/include/mach/vmalloc.h | 20 ---
arch/arm/mach-w90x900/include/mach/vmalloc.h | 23 ---
arch/arm/mach-zynq/include/mach/vmalloc.h | 20 ---
arch/arm/mm/init.c | 40 +----
arch/arm/mm/ioremap.c | 70 ++++++---
arch/arm/mm/mm.h | 14 ++
arch/arm/mm/mmu.c | 48 ++++--
arch/arm/mm/nommu.c | 2 +
arch/arm/plat-iop/Makefile | 2 -
arch/arm/plat-iop/io.c | 59 -------
arch/arm/plat-mxc/include/mach/mx1.h | 2 -
arch/arm/plat-mxc/include/mach/vmalloc.h | 22 ---
arch/arm/plat-omap/Makefile | 2 +-
arch/arm/plat-omap/include/plat/io.h | 6 -
arch/arm/plat-omap/io.c | 141 -----------------
arch/arm/plat-omap/sram.c | 2 +-
arch/arm/plat-spear/include/plat/vmalloc.h | 19 ---
arch/arm/plat-tcc/include/mach/vmalloc.h | 10 --
include/linux/vmalloc.h | 1 +
mm/vmalloc.c | 28 +++-
90 files changed, 159 insertions(+), 1376 deletions(-)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-23 13:32 Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
@ 2011-09-29 15:59 ` Rob Herring
2011-09-29 17:19 ` Nicolas Pitre
2011-09-29 17:37 ` Russell King - ARM Linux
2011-10-04 18:49 ` Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
1 sibling, 2 replies; 14+ messages in thread
From: Rob Herring @ 2011-09-29 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Nicolas,
On 09/23/2011 08:32 AM, Nicolas Pitre wrote:
> Russell, please pull
>
> git://git.linaro.org/people/nico/linux vmalloc
>
> This patch series removes all instances of mach/vmalloc.h in order to
> have a more unified memory map across all ARM architectures. To do so,
> the static mappings are moved inside the vmalloc area. And finally this
> allows for a generic optimization to ioremap where static mappings are
> reused whenever possible, using common code instead of having this
> duplicated in a couple places.
>
> This also provides a net reduction of more than 1200 lines of code.
>
> One regression was discovered on shmobile during testing because that
> platform asks for 158MB of consistent DMA memory while the documented
> maximum is 14MB. Inspection of the code doesn't tell why this is
> required, and listed maintainers did not respond yet after a couple
> days. So a temporary exception to the definition of VMALLOC_END was
> added for CONFIG_SHMOBILE and a noisy warning to get those maintainers'
> attention.
>
> Based on v3.1-rc4.
>
> Nicolas Pitre (21):
> ARM: mach-dove: remove inclusion of <mach/vmalloc.h>
> ARM: mach-prima2: don't define SIRFSOC_VA in terms of VMALLOC_END
> ARM: plat-mxc: remove inclusion of <mach/vmalloc.h>
> ARM: plat-omap: don't define OMAP1_SRAM_VA in terms of VMALLOC_END
> ARM: mach-at91: remove arch specific special handling for ioremap
> ARM: mach-davinci: remove arch specific special handling for ioremap
> ARM: mach-tegra: remove arch specific special handling for ioremap
> ARM: plat-omap: remove arch specific special handling for ioremap
> ARM: mach-bcmring: use proper constant to identify DMA memory area
> ARM: mach-orion5x: remove arch specific special handling for ioremap
> ARM: mach-kirkwood: remove arch specific special handling for ioremap
> ARM: mach-ixp23xx: remove arch specific special handling for ioremap
> ARM: plat-iop: remove arch specific special handling for ioremap
> ARM: sort the meminfo array earlier
> ARM: move initialization of the high_memory variable earlier
> mm: add vm_area_add_early()
> ARM: move iotable mappings within the vmalloc region
> ARM: simplify __iounmap() when dealing with section based mapping
> ARM: add generic ioremap optimization by reusing static mappings
> ARM: big removal of now unused vmalloc.h files
> ARM: move VMALLOC_END down temporarily for shmobile
>
> Documentation/arm/memory.txt | 11 +-
> arch/arm/include/asm/pgtable.h | 13 +-
> arch/arm/kernel/setup.c | 8 +
> arch/arm/mach-at91/include/mach/io.h | 8 -
> arch/arm/mach-at91/include/mach/vmalloc.h | 26 ---
> arch/arm/mach-at91/setup.c | 18 --
> arch/arm/mach-bcmring/dma.c | 2 +-
> arch/arm/mach-bcmring/include/mach/vmalloc.h | 25 ---
> arch/arm/mach-clps711x/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-cns3xxx/include/mach/vmalloc.h | 11 --
> arch/arm/mach-davinci/Makefile | 2 +-
> arch/arm/mach-davinci/include/mach/io.h | 8 -
> arch/arm/mach-davinci/include/mach/vmalloc.h | 14 --
> arch/arm/mach-davinci/io.c | 48 ------
> arch/arm/mach-dove/include/mach/dove.h | 2 -
> arch/arm/mach-dove/include/mach/vmalloc.h | 5 -
> arch/arm/mach-ebsa110/include/mach/vmalloc.h | 10 --
> arch/arm/mach-ep93xx/include/mach/vmalloc.h | 5 -
> arch/arm/mach-exynos4/include/mach/vmalloc.h | 22 ---
> arch/arm/mach-footbridge/include/mach/vmalloc.h | 10 --
> arch/arm/mach-gemini/include/mach/vmalloc.h | 10 --
> arch/arm/mach-h720x/include/mach/vmalloc.h | 10 --
> arch/arm/mach-integrator/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-iop13xx/include/mach/vmalloc.h | 4 -
> arch/arm/mach-iop32x/include/mach/io.h | 7 -
> arch/arm/mach-iop32x/include/mach/vmalloc.h | 5 -
> arch/arm/mach-iop33x/include/mach/io.h | 7 -
> arch/arm/mach-iop33x/include/mach/vmalloc.h | 5 -
> arch/arm/mach-ixp2000/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-ixp23xx/include/mach/io.h | 29 ----
> arch/arm/mach-ixp23xx/include/mach/vmalloc.h | 10 --
> arch/arm/mach-ixp4xx/include/mach/vmalloc.h | 5 -
> arch/arm/mach-kirkwood/include/mach/io.h | 25 ---
> arch/arm/mach-kirkwood/include/mach/vmalloc.h | 5 -
> arch/arm/mach-ks8695/include/mach/vmalloc.h | 19 ---
> arch/arm/mach-lpc32xx/include/mach/vmalloc.h | 24 ---
> arch/arm/mach-mmp/include/mach/vmalloc.h | 5 -
> arch/arm/mach-msm/include/mach/vmalloc.h | 22 ---
> arch/arm/mach-mv78xx0/include/mach/vmalloc.h | 5 -
> arch/arm/mach-mxs/include/mach/vmalloc.h | 22 ---
> arch/arm/mach-netx/include/mach/vmalloc.h | 19 ---
> arch/arm/mach-nomadik/include/mach/vmalloc.h | 2 -
> arch/arm/mach-nuc93x/include/mach/vmalloc.h | 23 ---
> arch/arm/mach-omap1/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-omap2/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-orion5x/include/mach/io.h | 25 ---
> arch/arm/mach-orion5x/include/mach/vmalloc.h | 5 -
> arch/arm/mach-pnx4008/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-prima2/include/mach/map.h | 6 +-
> arch/arm/mach-prima2/include/mach/vmalloc.h | 16 --
> arch/arm/mach-pxa/include/mach/vmalloc.h | 11 --
> arch/arm/mach-realview/include/mach/vmalloc.h | 21 ---
> arch/arm/mach-rpc/include/mach/vmalloc.h | 10 --
> arch/arm/mach-s3c2410/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-s3c64xx/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-s5p64x0/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-s5pc100/include/mach/vmalloc.h | 17 --
> arch/arm/mach-s5pv210/include/mach/vmalloc.h | 22 ---
> arch/arm/mach-sa1100/include/mach/vmalloc.h | 4 -
> arch/arm/mach-shark/include/mach/vmalloc.h | 4 -
> arch/arm/mach-shmobile/include/mach/vmalloc.h | 7 -
> arch/arm/mach-spear3xx/include/mach/vmalloc.h | 19 ---
> arch/arm/mach-spear6xx/include/mach/vmalloc.h | 19 ---
> arch/arm/mach-tegra/include/mach/io.h | 6 -
> arch/arm/mach-tegra/include/mach/vmalloc.h | 28 ----
> arch/arm/mach-tegra/io.c | 21 ---
> arch/arm/mach-u300/include/mach/vmalloc.h | 12 --
> arch/arm/mach-ux500/include/mach/vmalloc.h | 18 --
> arch/arm/mach-versatile/include/mach/vmalloc.h | 21 ---
> arch/arm/mach-vexpress/include/mach/vmalloc.h | 21 ---
> arch/arm/mach-vt8500/include/mach/vmalloc.h | 20 ---
> arch/arm/mach-w90x900/include/mach/vmalloc.h | 23 ---
> arch/arm/mach-zynq/include/mach/vmalloc.h | 20 ---
> arch/arm/mm/init.c | 40 +----
> arch/arm/mm/ioremap.c | 70 ++++++---
> arch/arm/mm/mm.h | 14 ++
> arch/arm/mm/mmu.c | 48 ++++--
> arch/arm/mm/nommu.c | 2 +
> arch/arm/plat-iop/Makefile | 2 -
> arch/arm/plat-iop/io.c | 59 -------
> arch/arm/plat-mxc/include/mach/mx1.h | 2 -
> arch/arm/plat-mxc/include/mach/vmalloc.h | 22 ---
> arch/arm/plat-omap/Makefile | 2 +-
> arch/arm/plat-omap/include/plat/io.h | 6 -
> arch/arm/plat-omap/io.c | 141 -----------------
> arch/arm/plat-omap/sram.c | 2 +-
> arch/arm/plat-spear/include/plat/vmalloc.h | 19 ---
> arch/arm/plat-tcc/include/mach/vmalloc.h | 10 --
> include/linux/vmalloc.h | 1 +
> mm/vmalloc.c | 28 +++-
> 90 files changed, 159 insertions(+), 1376 deletions(-)
>
I've found that this breaks on versatile (ab and pb) under QEMU. The
commit causing it is:
commit e0438e2f333005c217a2f65aacab23a39261c64c
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Thu Aug 25 00:35:59 2011 -0400
ARM: move iotable mappings within the vmalloc region
In order to remove the build time variation between different SOCs with
regards to VMALLOC_END, the iotable mappings are now allocated inside
the vmalloc region. This allows for VMALLOC_END to be identical across
all machines.
The value for VMALLOC_END is now set to 0xff000000 which is right where
the consistent DMA area starts.
To accommodate all static mappings on machines with possible highmem
usage,
the default vmalloc area size is changed to 240 MB so that VMALLOC_START
is no higher than 0xf0000000 by default in that case.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
It dies after "Data cache writeback" with BUG at vmalloc.c:1139.
Rob
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 15:59 ` Rob Herring
@ 2011-09-29 17:19 ` Nicolas Pitre
2011-09-29 17:37 ` Russell King - ARM Linux
1 sibling, 0 replies; 14+ messages in thread
From: Nicolas Pitre @ 2011-09-29 17:19 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 29 Sep 2011, Rob Herring wrote:
> Nicolas,
>
> On 09/23/2011 08:32 AM, Nicolas Pitre wrote:
> > Russell, please pull
> >
> > git://git.linaro.org/people/nico/linux vmalloc
> >
> > This patch series removes all instances of mach/vmalloc.h in order to
> > have a more unified memory map across all ARM architectures. To do so,
> > the static mappings are moved inside the vmalloc area. And finally this
> > allows for a generic optimization to ioremap where static mappings are
> > reused whenever possible, using common code instead of having this
> > duplicated in a couple places.
>
> I've found that this breaks on versatile (ab and pb) under QEMU. The
> commit causing it is:
>
> commit e0438e2f333005c217a2f65aacab23a39261c64c
> Author: Nicolas Pitre <nicolas.pitre@linaro.org>
> Date: Thu Aug 25 00:35:59 2011 -0400
>
> ARM: move iotable mappings within the vmalloc region
>
> In order to remove the build time variation between different SOCs with
> regards to VMALLOC_END, the iotable mappings are now allocated inside
> the vmalloc region. This allows for VMALLOC_END to be identical across
> all machines.
>
> The value for VMALLOC_END is now set to 0xff000000 which is right where
> the consistent DMA area starts.
>
> To accommodate all static mappings on machines with possible highmem
> usage,
> the default vmalloc area size is changed to 240 MB so that VMALLOC_START
> is no higher than 0xf0000000 by default in that case.
>
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>
>
> It dies after "Data cache writeback" with BUG at vmalloc.c:1139.
Interesting. Looks like Versatile might have overlapping map_desc
entries.
Could you add the following line at the top of vm_area_add_early() in
mm/vmalloc.c to display the area being added:
printk("%s: called with addr=%p size=0x%lx\n", __func__, vm->addr, vm->size);
This should help determine which entry is wrong.
Nicolas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 15:59 ` Rob Herring
2011-09-29 17:19 ` Nicolas Pitre
@ 2011-09-29 17:37 ` Russell King - ARM Linux
2011-09-29 18:25 ` Rob Herring
1 sibling, 1 reply; 14+ messages in thread
From: Russell King - ARM Linux @ 2011-09-29 17:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 29, 2011 at 10:59:21AM -0500, Rob Herring wrote:
> commit e0438e2f333005c217a2f65aacab23a39261c64c
> Author: Nicolas Pitre <nicolas.pitre@linaro.org>
> Date: Thu Aug 25 00:35:59 2011 -0400
>
> ARM: move iotable mappings within the vmalloc region
>
> In order to remove the build time variation between different SOCs with
> regards to VMALLOC_END, the iotable mappings are now allocated inside
> the vmalloc region. This allows for VMALLOC_END to be identical across
> all machines.
>
> The value for VMALLOC_END is now set to 0xff000000 which is right where
> the consistent DMA area starts.
>
> To accommodate all static mappings on machines with possible highmem
> usage,
> the default vmalloc area size is changed to 240 MB so that VMALLOC_START
> is no higher than 0xf0000000 by default in that case.
>
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>
>
> It dies after "Data cache writeback" with BUG at vmalloc.c:1139.
My guess would be:
}, {
.virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
.pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
.length = SZ_4K * 9,
.type = MT_DEVICE
},
#ifdef CONFIG_MACH_VERSATILE_AB
{
.virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
.pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
.length = SZ_4K,
.type = MT_DEVICE
#define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
#define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
I don't see why GPIO0 is explicitly listed here.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 17:37 ` Russell King - ARM Linux
@ 2011-09-29 18:25 ` Rob Herring
2011-09-29 18:42 ` Nicolas Pitre
0 siblings, 1 reply; 14+ messages in thread
From: Rob Herring @ 2011-09-29 18:25 UTC (permalink / raw)
To: linux-arm-kernel
On 09/29/2011 12:37 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 29, 2011 at 10:59:21AM -0500, Rob Herring wrote:
>> commit e0438e2f333005c217a2f65aacab23a39261c64c
>> Author: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Date: Thu Aug 25 00:35:59 2011 -0400
>>
>> ARM: move iotable mappings within the vmalloc region
>>
>> In order to remove the build time variation between different SOCs with
>> regards to VMALLOC_END, the iotable mappings are now allocated inside
>> the vmalloc region. This allows for VMALLOC_END to be identical across
>> all machines.
>>
>> The value for VMALLOC_END is now set to 0xff000000 which is right where
>> the consistent DMA area starts.
>>
>> To accommodate all static mappings on machines with possible highmem
>> usage,
>> the default vmalloc area size is changed to 240 MB so that VMALLOC_START
>> is no higher than 0xf0000000 by default in that case.
>>
>> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>>
>>
>> It dies after "Data cache writeback" with BUG at vmalloc.c:1139.
>
> My guess would be:
>
> }, {
> .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
> .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
> .length = SZ_4K * 9,
> .type = MT_DEVICE
> },
> #ifdef CONFIG_MACH_VERSATILE_AB
> {
> .virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
> .pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
> .length = SZ_4K,
> .type = MT_DEVICE
>
> #define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
> #define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
>
> I don't see why GPIO0 is explicitly listed here.
It works for PB and AB with that removed. Here's a patch:
Author: Rob Herring <rob.herring@calxeda.com>
Date: Thu Sep 29 13:18:29 2011 -0500
ARM: versatile: remove overlapping map_desc entry
The map_desc for VERSATILE_GPIO0_BASE overlaps with VERSATILE_SCTL_BASE.
The overlapping entry can be removed.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index e340a54..4d8dfc1 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -141,11 +141,6 @@ static struct map_desc versatile_io_desc[]
__initdata = {
},
#ifdef CONFIG_MACH_VERSATILE_AB
{
- .virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
- .pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
.virtual = IO_ADDRESS(VERSATILE_IB2_BASE),
.pfn = __phys_to_pfn(VERSATILE_IB2_BASE),
.length = SZ_64M,
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 18:25 ` Rob Herring
@ 2011-09-29 18:42 ` Nicolas Pitre
2011-09-29 20:26 ` Rob Herring
0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Pitre @ 2011-09-29 18:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 29 Sep 2011, Rob Herring wrote:
> On 09/29/2011 12:37 PM, Russell King - ARM Linux wrote:
> > My guess would be:
> >
> > }, {
> > .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
> > .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
> > .length = SZ_4K * 9,
> > .type = MT_DEVICE
> > },
> > #ifdef CONFIG_MACH_VERSATILE_AB
> > {
> > .virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
> > .pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
> > .length = SZ_4K,
> > .type = MT_DEVICE
> >
> > #define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
> > #define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
> >
> > I don't see why GPIO0 is explicitly listed here.
>
> It works for PB and AB with that removed. Here's a patch:
[...]
Thanks for testing and the patch. I've inserted it in my patch series
and pushed the result out.
Nicolas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 18:42 ` Nicolas Pitre
@ 2011-09-29 20:26 ` Rob Herring
2011-09-29 20:47 ` Nicolas Pitre
0 siblings, 1 reply; 14+ messages in thread
From: Rob Herring @ 2011-09-29 20:26 UTC (permalink / raw)
To: linux-arm-kernel
On 09/29/2011 01:42 PM, Nicolas Pitre wrote:
> On Thu, 29 Sep 2011, Rob Herring wrote:
>
>> On 09/29/2011 12:37 PM, Russell King - ARM Linux wrote:
>>> My guess would be:
>>>
>>> }, {
>>> .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
>>> .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
>>> .length = SZ_4K * 9,
>>> .type = MT_DEVICE
>>> },
>>> #ifdef CONFIG_MACH_VERSATILE_AB
>>> {
>>> .virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
>>> .pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
>>> .length = SZ_4K,
>>> .type = MT_DEVICE
>>>
>>> #define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
>>> #define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
>>>
>>> I don't see why GPIO0 is explicitly listed here.
>>
>> It works for PB and AB with that removed. Here's a patch:
> [...]
>
> Thanks for testing and the patch. I've inserted it in my patch series
> and pushed the result out.
So it was really Realview PBX I wanted to test my GIC changes on. Well,
turns out it's got a similar problem, too.
However, the fix for it should perhaps be a bit different. The problem
is that the virtual address of REALVIEW_PBX_TILE_GIC_CPU_BASE is not
aligned. Then 0x100 + 4KB length overlaps into the DIST_BASE. So do we
fix it in the platform or should the core code mask out the lower bits
of the virt addr before doing any size calculations?
Rob
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 20:26 ` Rob Herring
@ 2011-09-29 20:47 ` Nicolas Pitre
2011-09-29 21:19 ` Rob Herring
0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Pitre @ 2011-09-29 20:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 29 Sep 2011, Rob Herring wrote:
> On 09/29/2011 01:42 PM, Nicolas Pitre wrote:
> > On Thu, 29 Sep 2011, Rob Herring wrote:
> >
> >> On 09/29/2011 12:37 PM, Russell King - ARM Linux wrote:
> >>> My guess would be:
> >>>
> >>> }, {
> >>> .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
> >>> .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
> >>> .length = SZ_4K * 9,
> >>> .type = MT_DEVICE
> >>> },
> >>> #ifdef CONFIG_MACH_VERSATILE_AB
> >>> {
> >>> .virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
> >>> .pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
> >>> .length = SZ_4K,
> >>> .type = MT_DEVICE
> >>>
> >>> #define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
> >>> #define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
> >>>
> >>> I don't see why GPIO0 is explicitly listed here.
> >>
> >> It works for PB and AB with that removed. Here's a patch:
> > [...]
> >
> > Thanks for testing and the patch. I've inserted it in my patch series
> > and pushed the result out.
>
> So it was really Realview PBX I wanted to test my GIC changes on. Well,
> turns out it's got a similar problem, too.
>
> However, the fix for it should perhaps be a bit different. The problem
> is that the virtual address of REALVIEW_PBX_TILE_GIC_CPU_BASE is not
> aligned. Then 0x100 + 4KB length overlaps into the DIST_BASE. So do we
> fix it in the platform or should the core code mask out the lower bits
> of the virt addr before doing any size calculations?
Please fix it in the platform static declaration. No need to put
run time code for something that can be fixed in the source.
Nicolas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 20:47 ` Nicolas Pitre
@ 2011-09-29 21:19 ` Rob Herring
2011-09-29 21:22 ` [PATCH] ARM: realview: fix map_desc alignment Rob Herring
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Rob Herring @ 2011-09-29 21:19 UTC (permalink / raw)
To: linux-arm-kernel
On 09/29/2011 03:47 PM, Nicolas Pitre wrote:
> On Thu, 29 Sep 2011, Rob Herring wrote:
>
>> On 09/29/2011 01:42 PM, Nicolas Pitre wrote:
>>> On Thu, 29 Sep 2011, Rob Herring wrote:
>>>
>>>> On 09/29/2011 12:37 PM, Russell King - ARM Linux wrote:
>>>>> My guess would be:
>>>>>
>>>>> }, {
>>>>> .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
>>>>> .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
>>>>> .length = SZ_4K * 9,
>>>>> .type = MT_DEVICE
>>>>> },
>>>>> #ifdef CONFIG_MACH_VERSATILE_AB
>>>>> {
>>>>> .virtual = IO_ADDRESS(VERSATILE_GPIO0_BASE),
>>>>> .pfn = __phys_to_pfn(VERSATILE_GPIO0_BASE),
>>>>> .length = SZ_4K,
>>>>> .type = MT_DEVICE
>>>>>
>>>>> #define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
>>>>> #define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
>>>>>
>>>>> I don't see why GPIO0 is explicitly listed here.
>>>>
>>>> It works for PB and AB with that removed. Here's a patch:
>>> [...]
>>>
>>> Thanks for testing and the patch. I've inserted it in my patch series
>>> and pushed the result out.
>>
>> So it was really Realview PBX I wanted to test my GIC changes on. Well,
>> turns out it's got a similar problem, too.
>>
>> However, the fix for it should perhaps be a bit different. The problem
>> is that the virtual address of REALVIEW_PBX_TILE_GIC_CPU_BASE is not
>> aligned. Then 0x100 + 4KB length overlaps into the DIST_BASE. So do we
>> fix it in the platform or should the core code mask out the lower bits
>> of the virt addr before doing any size calculations?
>
> Please fix it in the platform static declaration. No need to put
> run time code for something that can be fixed in the source.
>
Except that 2 out of 2 machines I've tried are broken. Anyway, patch is
coming.
Rob
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ARM: realview: fix map_desc alignment
2011-09-29 21:19 ` Rob Herring
@ 2011-09-29 21:22 ` Rob Herring
2011-09-29 23:57 ` Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
2011-09-30 0:46 ` [PATCH] ARM: realview-eb11mp: fix map_desc alignment Rob Herring
2 siblings, 0 replies; 14+ messages in thread
From: Rob Herring @ 2011-09-29 21:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
REALVIEW_PBX_TILE_GIC_CPU_BASE is not 4KB aligned which causes an
overlapping mapping. Use REALVIEW_PBX_TILE_SCU_BASE instead which is
aligned.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/mach-realview/realview_pbx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-realview/realview_pbx.c b/arch/arm/mach-realview/realview_pbx.c
index 363b0ab..5930a33 100644
--- a/arch/arm/mach-realview/realview_pbx.c
+++ b/arch/arm/mach-realview/realview_pbx.c
@@ -98,8 +98,8 @@ static struct map_desc realview_pbx_io_desc[] __initdata = {
static struct map_desc realview_local_io_desc[] __initdata = {
{
- .virtual = IO_ADDRESS(REALVIEW_PBX_TILE_GIC_CPU_BASE),
- .pfn = __phys_to_pfn(REALVIEW_PBX_TILE_GIC_CPU_BASE),
+ .virtual = IO_ADDRESS(REALVIEW_PBX_TILE_SCU_BASE),
+ .pfn = __phys_to_pfn(REALVIEW_PBX_TILE_SCU_BASE),
.length = SZ_4K,
.type = MT_DEVICE,
}, {
--
1.7.5.4
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-29 21:19 ` Rob Herring
2011-09-29 21:22 ` [PATCH] ARM: realview: fix map_desc alignment Rob Herring
@ 2011-09-29 23:57 ` Nicolas Pitre
2011-09-30 0:46 ` [PATCH] ARM: realview-eb11mp: fix map_desc alignment Rob Herring
2 siblings, 0 replies; 14+ messages in thread
From: Nicolas Pitre @ 2011-09-29 23:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 29 Sep 2011, Rob Herring wrote:
> On 09/29/2011 03:47 PM, Nicolas Pitre wrote:
> > On Thu, 29 Sep 2011, Rob Herring wrote:
> >
> >> So it was really Realview PBX I wanted to test my GIC changes on. Well,
> >> turns out it's got a similar problem, too.
> >>
> >> However, the fix for it should perhaps be a bit different. The problem
> >> is that the virtual address of REALVIEW_PBX_TILE_GIC_CPU_BASE is not
> >> aligned. Then 0x100 + 4KB length overlaps into the DIST_BASE. So do we
> >> fix it in the platform or should the core code mask out the lower bits
> >> of the virt addr before doing any size calculations?
> >
> > Please fix it in the platform static declaration. No need to put
> > run time code for something that can be fixed in the source.
> >
> Except that 2 out of 2 machines I've tried are broken.
You've been lucky... or maybe the authors of the versatile and realview
support shared the same ... habits.
In any case, it is plain wrong to use overlapping mappings anyway. If
you do have a mapping to start at 0xf0000100 with a size of 4096 bytes,
then the only way to satisfy this is to map two pages. If in practice
only one page was enough because only the first 32 bytes are accessed,
then you should really specify the size as 32. Or use a 4K aligned
start address if you want to stick with a 4K size.
But to simply mask out the low address bits _before_ determining the
mapping end is just lying to yourself. What if some day such a mapping
that ends up crossing a page boundary is legit? Better be more careful
and rigorous with the actual mapping parameters rather than forcing the
core code to guess what was meant.
And in this case, the map_desc entry order just hid the issue by having
a later mapping overwrite the extra page from the previous one. If the
map_desc entries were reversed then you'd have ended up with the wrong
mapping in place which is a bug. At least with my series this kind of
mapping mistake is now flagged which is a good thing.
> Anyway, patch is coming.
Applied, thanks.
Nicolas
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ARM: realview-eb11mp: fix map_desc alignment
2011-09-29 21:19 ` Rob Herring
2011-09-29 21:22 ` [PATCH] ARM: realview: fix map_desc alignment Rob Herring
2011-09-29 23:57 ` Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
@ 2011-09-30 0:46 ` Rob Herring
2011-09-30 1:34 ` Nicolas Pitre
2 siblings, 1 reply; 14+ messages in thread
From: Rob Herring @ 2011-09-30 0:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
REALVIEW_EB11MP_GIC_CPU_BASE is not 4KB aligned which causes an
overlapping mapping. Use REALVIEW_EB11MP_SCU_BASE instead which is
aligned.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
Nico,
Here's another one. I visually checked the remaining Realview platforms and
think they are fine.
Rob
arch/arm/mach-realview/realview_eb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-realview/realview_eb.c b/arch/arm/mach-realview/realview_eb.c
index 026c66a..a9874e1 100644
--- a/arch/arm/mach-realview/realview_eb.c
+++ b/arch/arm/mach-realview/realview_eb.c
@@ -91,8 +91,8 @@ static struct map_desc realview_eb_io_desc[] __initdata = {
static struct map_desc realview_eb11mp_io_desc[] __initdata = {
{
- .virtual = IO_ADDRESS(REALVIEW_EB11MP_GIC_CPU_BASE),
- .pfn = __phys_to_pfn(REALVIEW_EB11MP_GIC_CPU_BASE),
+ .virtual = IO_ADDRESS(REALVIEW_EB11MP_SCU_BASE),
+ .pfn = __phys_to_pfn(REALVIEW_EB11MP_SCU_BASE),
.length = SZ_4K,
.type = MT_DEVICE,
}, {
--
1.7.5.4
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH] ARM: realview-eb11mp: fix map_desc alignment
2011-09-30 0:46 ` [PATCH] ARM: realview-eb11mp: fix map_desc alignment Rob Herring
@ 2011-09-30 1:34 ` Nicolas Pitre
0 siblings, 0 replies; 14+ messages in thread
From: Nicolas Pitre @ 2011-09-30 1:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 29 Sep 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> REALVIEW_EB11MP_GIC_CPU_BASE is not 4KB aligned which causes an
> overlapping mapping. Use REALVIEW_EB11MP_SCU_BASE instead which is
> aligned.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> Nico,
>
> Here's another one. I visually checked the remaining Realview platforms and
> think they are fine.
Thanks.
Nicolas
^ permalink raw reply [flat|nested] 14+ messages in thread
* Git pull request: mach/vmalloc.h removal, and ioremap optimizations
2011-09-23 13:32 Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
2011-09-29 15:59 ` Rob Herring
@ 2011-10-04 18:49 ` Nicolas Pitre
1 sibling, 0 replies; 14+ messages in thread
From: Nicolas Pitre @ 2011-10-04 18:49 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 23 Sep 2011, Nicolas Pitre wrote:
> Russell, please pull
>
> git://git.linaro.org/people/nico/linux vmalloc
Given the problems that exist in the OMAP tree and their likely fixes
going into mainline only during the next merge window, I'm withdrawing
this request until the next cycle.
> One regression was discovered on shmobile during testing because that
> platform asks for 158MB of consistent DMA memory while the documented
> maximum is 14MB. Inspection of the code doesn't tell why this is
> required, and listed maintainers did not respond yet after a couple
> days. So a temporary exception to the definition of VMALLOC_END was
> added for CONFIG_SHMOBILE and a noisy warning to get those maintainers'
> attention.
For the record, those maintainers still didn't respond.
Nicolas
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-10-04 18:49 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-23 13:32 Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
2011-09-29 15:59 ` Rob Herring
2011-09-29 17:19 ` Nicolas Pitre
2011-09-29 17:37 ` Russell King - ARM Linux
2011-09-29 18:25 ` Rob Herring
2011-09-29 18:42 ` Nicolas Pitre
2011-09-29 20:26 ` Rob Herring
2011-09-29 20:47 ` Nicolas Pitre
2011-09-29 21:19 ` Rob Herring
2011-09-29 21:22 ` [PATCH] ARM: realview: fix map_desc alignment Rob Herring
2011-09-29 23:57 ` Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
2011-09-30 0:46 ` [PATCH] ARM: realview-eb11mp: fix map_desc alignment Rob Herring
2011-09-30 1:34 ` Nicolas Pitre
2011-10-04 18:49 ` Git pull request: mach/vmalloc.h removal, and ioremap optimizations Nicolas Pitre
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.