* 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.