* [RFC,PATCH 0/2] Allow late mdesc detection @ 2010-07-12 3:03 Jeremy Kerr 2010-07-12 3:03 ` [RFC,PATCH 1/2] arm: don't check MMU status in every addruart macro Jeremy Kerr ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Jeremy Kerr @ 2010-07-12 3:03 UTC (permalink / raw) To: linux-arm-kernel Hi all, Currently, we probe for a mdesc early in boot. At this early stage, the only thing we use the mdesc for is to determine the debug page mapping. However, the debug addresses (phys and virt) need to be coded into the addruart macro anyway; the dynamic probing is only going to tell us what we already know. These (experimental!) changes allow us to use the addruart macros to find the debug mapping addresses, rather than pulling them out of the mdesc. This means that the addresses are only kept in the one place, and that we don't need the mdesc nearly as early. The first change updates all of the addruart macros to take an argument in the first macro register, indicating whether we want a physical or virtual address returned. This argument replaces the check present in the existing macro implementations. The second change updates the debug setup routine to use the addruart macro to establish the debug mapping, now that we invoke the macro to find the phyical and virtual addresses. This allows us to delay the requirement to have a mdesc available until much later. For example, we can parse one from the device tree once we've reached C code. Tested on versatile only. May break OMAP1/2, as the addruart macros are more complex on these platforms. I'd appreciate input from OMAP folks who may well tell me that this isn't possible. These patches are not suitable for merging yet (no documentation updates for the new format of addruart, very little testing, no handling of DEBUG_ICEDCC). More of a request for you folks to tell me whether or not this is a stupid idea :) Cheers, Jeremy --- Jeremy Kerr (2): arm: don't check MMU status in every addruart macro arm: use addruart macro to establish debug mappings ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 1/2] arm: don't check MMU status in every addruart macro 2010-07-12 3:03 [RFC,PATCH 0/2] Allow late mdesc detection Jeremy Kerr @ 2010-07-12 3:03 ` Jeremy Kerr 2010-07-12 13:32 ` [RFC, PATCH " Nicolas Pitre 2010-07-12 3:03 ` [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings Jeremy Kerr 2010-07-12 3:39 ` [RFC,PATCH 0/2] Allow late mdesc detection Nicolas Pitre 2 siblings, 1 reply; 19+ messages in thread From: Jeremy Kerr @ 2010-07-12 3:03 UTC (permalink / raw) To: linux-arm-kernel Rather than checking the MMU status in every instance of addruart, do it once in kernel/debug.S, and change the existing addruart macros to expect the uart status in the macro argument register. This will also allow us to retreive the address of a uart for the MMU state that we're not current in. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> --- arch/arm/kernel/debug.S | 9 +++++++-- arch/arm/mach-aaec2000/include/mach/debug-macro.S | 1 - arch/arm/mach-at91/include/mach/debug-macro.S | 1 - arch/arm/mach-clps711x/include/mach/debug-macro.S | 1 - arch/arm/mach-cns3xxx/include/mach/debug-macro.S | 1 - arch/arm/mach-davinci/include/mach/debug-macro.S | 1 - arch/arm/mach-dove/include/mach/debug-macro.S | 1 - arch/arm/mach-ep93xx/include/mach/debug-macro.S | 1 - arch/arm/mach-footbridge/include/mach/debug-macro.S | 2 -- arch/arm/mach-gemini/include/mach/debug-macro.S | 1 - arch/arm/mach-h720x/include/mach/debug-macro.S | 1 - arch/arm/mach-integrator/include/mach/debug-macro.S | 1 - arch/arm/mach-iop13xx/include/mach/debug-macro.S | 1 - arch/arm/mach-iop33x/include/mach/debug-macro.S | 1 - arch/arm/mach-ixp2000/include/mach/debug-macro.S | 1 - arch/arm/mach-ixp23xx/include/mach/debug-macro.S | 1 - arch/arm/mach-ixp4xx/include/mach/debug-macro.S | 1 - arch/arm/mach-kirkwood/include/mach/debug-macro.S | 1 - arch/arm/mach-ks8695/include/mach/debug-macro.S | 1 - arch/arm/mach-l7200/include/mach/debug-macro.S | 1 - arch/arm/mach-lh7a40x/include/mach/debug-macro.S | 1 - arch/arm/mach-loki/include/mach/debug-macro.S | 1 - arch/arm/mach-mmp/include/mach/debug-macro.S | 1 - arch/arm/mach-msm/include/mach/debug-macro.S | 1 - arch/arm/mach-mv78xx0/include/mach/debug-macro.S | 1 - arch/arm/mach-netx/include/mach/debug-macro.S | 1 - arch/arm/mach-nomadik/include/mach/debug-macro.S | 1 - arch/arm/mach-ns9xxx/include/mach/debug-macro.S | 1 - arch/arm/mach-omap1/include/mach/debug-macro.S | 7 +++---- arch/arm/mach-omap2/include/mach/debug-macro.S | 7 +++---- arch/arm/mach-orion5x/include/mach/debug-macro.S | 1 - arch/arm/mach-pnx4008/include/mach/debug-macro.S | 1 - arch/arm/mach-pxa/include/mach/debug-macro.S | 1 - arch/arm/mach-realview/include/mach/debug-macro.S | 1 - arch/arm/mach-rpc/include/mach/debug-macro.S | 1 - arch/arm/mach-s3c2410/include/mach/debug-macro.S | 1 - arch/arm/mach-s3c24a0/include/mach/debug-macro.S | 1 - arch/arm/mach-s3c64xx/include/mach/debug-macro.S | 1 - arch/arm/mach-s5p6440/include/mach/debug-macro.S | 1 - arch/arm/mach-s5p6442/include/mach/debug-macro.S | 1 - arch/arm/mach-s5pc100/include/mach/debug-macro.S | 1 - arch/arm/mach-s5pv210/include/mach/debug-macro.S | 1 - arch/arm/mach-sa1100/include/mach/debug-macro.S | 1 - arch/arm/mach-u300/include/mach/debug-macro.S | 1 - arch/arm/mach-ux500/include/mach/debug-macro.S | 1 - arch/arm/mach-versatile/include/mach/debug-macro.S | 1 - arch/arm/mach-vexpress/include/mach/debug-macro.S | 1 - arch/arm/plat-mxc/include/mach/debug-macro.S | 1 - arch/arm/plat-spear/include/plat/debug-macro.S | 1 - arch/arm/plat-stmp3xxx/include/mach/debug-macro.S | 1 - 50 files changed, 13 insertions(+), 58 deletions(-) diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S index a38b487..e1d0ab9 100644 --- a/arch/arm/kernel/debug.S +++ b/arch/arm/kernel/debug.S @@ -130,6 +130,11 @@ wait: mrc p14, 0, pc, c0, c1, 0 #include <mach/debug-macro.S> #endif /* CONFIG_DEBUG_ICEDCC */ + .macro __addruart, rx, tmp + mrc p15, 0, \rx, c1, c0 + addruart \rx,\tmp + .endm + /* * Useful debugging routines */ @@ -164,7 +169,7 @@ ENDPROC(printhex2) .ltorg ENTRY(printascii) - addruart r3, r1 + __addruart r3, r1 b 2f 1: waituart r2, r3 senduart r1, r3 @@ -180,7 +185,7 @@ ENTRY(printascii) ENDPROC(printascii) ENTRY(printch) - addruart r3, r1 + __addruart r3, r1 mov r1, r0 mov r0, #0 b 1b diff --git a/arch/arm/mach-aaec2000/include/mach/debug-macro.S b/arch/arm/mach-aaec2000/include/mach/debug-macro.S index a9cac36..7a8f904 100644 --- a/arch/arm/mach-aaec2000/include/mach/debug-macro.S +++ b/arch/arm/mach-aaec2000/include/mach/debug-macro.S @@ -11,7 +11,6 @@ #include "hardware.h" .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x80000000 @ physical movne \rx, #io_p2v(0x80000000) @ virtual diff --git a/arch/arm/mach-at91/include/mach/debug-macro.S b/arch/arm/mach-at91/include/mach/debug-macro.S index 9e750a1..0a7c233 100644 --- a/arch/arm/mach-at91/include/mach/debug-macro.S +++ b/arch/arm/mach-at91/include/mach/debug-macro.S @@ -15,7 +15,6 @@ #include <mach/at91_dbgu.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =(AT91_BASE_SYS + AT91_DBGU) @ System peripherals (phys address) ldrne \rx, =(AT91_VA_BASE_SYS + AT91_DBGU) @ System peripherals (virt address) diff --git a/arch/arm/mach-clps711x/include/mach/debug-macro.S b/arch/arm/mach-clps711x/include/mach/debug-macro.S index fedd807..7e7d996 100644 --- a/arch/arm/mach-clps711x/include/mach/debug-macro.S +++ b/arch/arm/mach-clps711x/include/mach/debug-macro.S @@ -14,7 +14,6 @@ #include <asm/hardware/clps7111.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #CLPS7111_PHYS_BASE movne \rx, #CLPS7111_VIRT_BASE diff --git a/arch/arm/mach-cns3xxx/include/mach/debug-macro.S b/arch/arm/mach-cns3xxx/include/mach/debug-macro.S index d16ce7e..02501e8 100644 --- a/arch/arm/mach-cns3xxx/include/mach/debug-macro.S +++ b/arch/arm/mach-cns3xxx/include/mach/debug-macro.S @@ -11,7 +11,6 @@ */ .macro addruart,rx - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xf0000000 @ virtual base diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S index 3cd93a8..56ae184 100644 --- a/arch/arm/mach-davinci/include/mach/debug-macro.S +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S @@ -20,7 +20,6 @@ #define UART_SHIFT 2 .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x01000000 @ physical base address movne \rx, #0xfe000000 @ virtual base diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S index 1521d13..2ab3f88 100644 --- a/arch/arm/mach-dove/include/mach/debug-macro.S +++ b/arch/arm/mach-dove/include/mach/debug-macro.S @@ -9,7 +9,6 @@ #include <mach/bridge-regs.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =DOVE_SB_REGS_PHYS_BASE ldrne \rx, =DOVE_SB_REGS_VIRT_BASE diff --git a/arch/arm/mach-ep93xx/include/mach/debug-macro.S b/arch/arm/mach-ep93xx/include/mach/debug-macro.S index 5cd2244..0b774f7 100644 --- a/arch/arm/mach-ep93xx/include/mach/debug-macro.S +++ b/arch/arm/mach-ep93xx/include/mach/debug-macro.S @@ -12,7 +12,6 @@ #include <mach/ep93xx-regs.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =EP93XX_APB_PHYS_BASE @ Physical base ldrne \rx, =EP93XX_APB_VIRT_BASE @ virtual base diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S index 60dda13..3bc7b4c 100644 --- a/arch/arm/mach-footbridge/include/mach/debug-macro.S +++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S @@ -16,7 +16,6 @@ #ifndef CONFIG_DEBUG_DC21285_PORT /* For NetWinder debugging */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x7c000000 @ physical movne \rx, #0xff000000 @ virtual @@ -33,7 +32,6 @@ .equ dc21285_low, ARMCSR_BASE & 0x00ffffff .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x42000000 movne \rx, #dc21285_high diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S index ad47704..a232a6c 100644 --- a/arch/arm/mach-gemini/include/mach/debug-macro.S +++ b/arch/arm/mach-gemini/include/mach/debug-macro.S @@ -12,7 +12,6 @@ #include <mach/hardware.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =GEMINI_UART_BASE @ physical ldrne \rx, =IO_ADDRESS(GEMINI_UART_BASE) @ virtual diff --git a/arch/arm/mach-h720x/include/mach/debug-macro.S b/arch/arm/mach-h720x/include/mach/debug-macro.S index a9ee8f0..229c7dc 100644 --- a/arch/arm/mach-h720x/include/mach/debug-macro.S +++ b/arch/arm/mach-h720x/include/mach/debug-macro.S @@ -15,7 +15,6 @@ .equ io_phys, IO_START .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #io_phys @ physical base address movne \rx, #io_virt @ virtual address diff --git a/arch/arm/mach-integrator/include/mach/debug-macro.S b/arch/arm/mach-integrator/include/mach/debug-macro.S index 87a6888..79ae58e 100644 --- a/arch/arm/mach-integrator/include/mach/debug-macro.S +++ b/arch/arm/mach-integrator/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x16000000 @ physical base address movne \rx, #0xf0000000 @ virtual base diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S index c9d6ba4..0430c46 100644 --- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S +++ b/arch/arm/mach-iop13xx/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ mmu enabled? moveq \rx, #0xff000000 @ physical orreq \rx, \rx, #0x00d80000 diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S index addb2da..91f9a0a 100644 --- a/arch/arm/mach-iop33x/include/mach/debug-macro.S +++ b/arch/arm/mach-iop33x/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ mmu enabled? moveq \rx, #0xff000000 @ physical movne \rx, #0xfe000000 @ virtual diff --git a/arch/arm/mach-ixp2000/include/mach/debug-macro.S b/arch/arm/mach-ixp2000/include/mach/debug-macro.S index 6a82768..d355129 100644 --- a/arch/arm/mach-ixp2000/include/mach/debug-macro.S +++ b/arch/arm/mach-ixp2000/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0xc0000000 @ Physical base movne \rx, #0xfe000000 @ virtual base diff --git a/arch/arm/mach-ixp23xx/include/mach/debug-macro.S b/arch/arm/mach-ixp23xx/include/mach/debug-macro.S index a82e375..c24d1bd 100644 --- a/arch/arm/mach-ixp23xx/include/mach/debug-macro.S +++ b/arch/arm/mach-ixp23xx/include/mach/debug-macro.S @@ -13,7 +13,6 @@ #include <mach/ixp23xx.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ mmu enabled? ldreq \rx, =IXP23XX_PERIPHERAL_PHYS @ physical ldrne \rx, =IXP23XX_PERIPHERAL_VIRT @ virtual diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S index 893873e..245685b 100644 --- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S +++ b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S @@ -11,7 +11,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0xc8000000 movne \rx, #0xff000000 diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S index d060677..fbda2e6 100644 --- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S +++ b/arch/arm/mach-kirkwood/include/mach/debug-macro.S @@ -9,7 +9,6 @@ #include <mach/bridge-regs.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =KIRKWOOD_REGS_PHYS_BASE ldrne \rx, =KIRKWOOD_REGS_VIRT_BASE diff --git a/arch/arm/mach-ks8695/include/mach/debug-macro.S b/arch/arm/mach-ks8695/include/mach/debug-macro.S index cf2095d..8587635 100644 --- a/arch/arm/mach-ks8695/include/mach/debug-macro.S +++ b/arch/arm/mach-ks8695/include/mach/debug-macro.S @@ -15,7 +15,6 @@ #include <mach/regs-uart.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =KS8695_UART_PA @ physical base address ldrne \rx, =KS8695_UART_VA @ virtual base address diff --git a/arch/arm/mach-l7200/include/mach/debug-macro.S b/arch/arm/mach-l7200/include/mach/debug-macro.S index b69ed34..912e924 100644 --- a/arch/arm/mach-l7200/include/mach/debug-macro.S +++ b/arch/arm/mach-l7200/include/mach/debug-macro.S @@ -15,7 +15,6 @@ .equ io_phys, IO_START .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #io_phys @ physical base address movne \rx, #io_virt @ virtual address diff --git a/arch/arm/mach-lh7a40x/include/mach/debug-macro.S b/arch/arm/mach-lh7a40x/include/mach/debug-macro.S index c0dcbbb..60d7d70 100644 --- a/arch/arm/mach-lh7a40x/include/mach/debug-macro.S +++ b/arch/arm/mach-lh7a40x/include/mach/debug-macro.S @@ -15,7 +15,6 @@ @ board. .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? mov \rx, #0x00000700 @ offset from base orreq \rx, \rx, #0x80000000 @ physical base diff --git a/arch/arm/mach-loki/include/mach/debug-macro.S b/arch/arm/mach-loki/include/mach/debug-macro.S index 3136c91..2cbbdec 100644 --- a/arch/arm/mach-loki/include/mach/debug-macro.S +++ b/arch/arm/mach-loki/include/mach/debug-macro.S @@ -9,7 +9,6 @@ #include <mach/loki.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =LOKI_REGS_PHYS_BASE ldrne \rx, =LOKI_REGS_VIRT_BASE diff --git a/arch/arm/mach-mmp/include/mach/debug-macro.S b/arch/arm/mach-mmp/include/mach/debug-macro.S index 76deff2..6d57a05 100644 --- a/arch/arm/mach-mmp/include/mach/debug-macro.S +++ b/arch/arm/mach-mmp/include/mach/debug-macro.S @@ -12,7 +12,6 @@ #include <mach/addr-map.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =APB_PHYS_BASE @ physical ldrne \rx, =APB_VIRT_BASE @ virtual diff --git a/arch/arm/mach-msm/include/mach/debug-macro.S b/arch/arm/mach-msm/include/mach/debug-macro.S index 528750f..121d803 100644 --- a/arch/arm/mach-msm/include/mach/debug-macro.S +++ b/arch/arm/mach-msm/include/mach/debug-macro.S @@ -22,7 +22,6 @@ #ifdef CONFIG_MSM_DEBUG_UART .macro addruart, rx, tmp @ see if the MMU is enabled and select appropriate base address - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, =MSM_DEBUG_UART_PHYS ldrne \rx, =MSM_DEBUG_UART_BASE diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S index cd81689..96c04ea 100644 --- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S +++ b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S @@ -9,7 +9,6 @@ #include <mach/mv78xx0.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =MV78XX0_REGS_PHYS_BASE ldrne \rx, =MV78XX0_REGS_VIRT_BASE diff --git a/arch/arm/mach-netx/include/mach/debug-macro.S b/arch/arm/mach-netx/include/mach/debug-macro.S index e96339e..c7d2a9e 100644 --- a/arch/arm/mach-netx/include/mach/debug-macro.S +++ b/arch/arm/mach-netx/include/mach/debug-macro.S @@ -14,7 +14,6 @@ #include "hardware.h" .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x00100000 @ physical movne \rx, #io_p2v(0x00100000) @ virtual diff --git a/arch/arm/mach-nomadik/include/mach/debug-macro.S b/arch/arm/mach-nomadik/include/mach/debug-macro.S index 4f92acf..04ae6e3 100644 --- a/arch/arm/mach-nomadik/include/mach/debug-macro.S +++ b/arch/arm/mach-nomadik/include/mach/debug-macro.S @@ -11,7 +11,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 @ physical base address movne \rx, #0xf0000000 @ virtual base diff --git a/arch/arm/mach-ns9xxx/include/mach/debug-macro.S b/arch/arm/mach-ns9xxx/include/mach/debug-macro.S index 0859336..864de81 100644 --- a/arch/arm/mach-ns9xxx/include/mach/debug-macro.S +++ b/arch/arm/mach-ns9xxx/include/mach/debug-macro.S @@ -12,7 +12,6 @@ #include <mach/regs-board-a9m9750dev.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, =NS9XXX_CSxSTAT_PHYS(0) ldrne \rx, =io_p2v(NS9XXX_CSxSTAT_PHYS(0)) diff --git a/arch/arm/mach-omap1/include/mach/debug-macro.S b/arch/arm/mach-omap1/include/mach/debug-macro.S index e8a8cf3..4b9371c 100644 --- a/arch/arm/mach-omap1/include/mach/debug-macro.S +++ b/arch/arm/mach-omap1/include/mach/debug-macro.S @@ -31,8 +31,8 @@ omap_uart_virt: .word 0x0 .macro addruart, rx, tmp /* Use omap_uart_phys/virt if already configured */ -9: mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? +9: mov \tmp,\rx + tst \tmp, #1 @ MMU enabled? ldreq \rx, =omap_uart_phys @ physical base address ldrne \rx, =omap_uart_virt @ virtual base ldr \rx, [\rx, #0] @@ -40,8 +40,7 @@ omap_uart_virt: .word 0x0 bne 99f @ already configured /* Check the debug UART configuration set in uncompress.h */ - mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? + tst \tmp, #1 @ MMU enabled? ldreq \rx, =OMAP_UART_INFO ldrne \rx, =__phys_to_virt(OMAP_UART_INFO) ldr \rx, [\rx, #0] diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S index 35b2440..d483f08 100644 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -34,8 +34,8 @@ omap_uart_lsr: .word 0 .macro addruart, rx, tmp /* Use omap_uart_phys/virt if already configured */ -10: mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? +10: mov \tmp, \rx + tst \tmp, #1 @ MMU enabled? ldreq \rx, =omap_uart_phys @ physical base address ldrne \rx, =omap_uart_virt @ virtual base address ldr \rx, [\rx, #0] @@ -43,8 +43,7 @@ omap_uart_lsr: .word 0 bne 99f @ already configured /* Check the debug UART configuration set in uncompress.h */ - mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? + tst \tmp, #1 @ MMU enabled? ldreq \rx, =OMAP_UART_INFO ldrne \rx, =__phys_to_virt(OMAP_UART_INFO) ldr \rx, [\rx, #0] diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S index 91e0e39..6ba020c 100644 --- a/arch/arm/mach-orion5x/include/mach/debug-macro.S +++ b/arch/arm/mach-orion5x/include/mach/debug-macro.S @@ -11,7 +11,6 @@ #include <mach/orion5x.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =ORION5X_REGS_PHYS_BASE ldrne \rx, =ORION5X_REGS_VIRT_BASE diff --git a/arch/arm/mach-pnx4008/include/mach/debug-macro.S b/arch/arm/mach-pnx4008/include/mach/debug-macro.S index 6ca8bd3..7596b02 100644 --- a/arch/arm/mach-pnx4008/include/mach/debug-macro.S +++ b/arch/arm/mach-pnx4008/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? mov \rx, #0x00090000 addeq \rx, \rx, #0x40000000 diff --git a/arch/arm/mach-pxa/include/mach/debug-macro.S b/arch/arm/mach-pxa/include/mach/debug-macro.S index 01cf813..645f927 100644 --- a/arch/arm/mach-pxa/include/mach/debug-macro.S +++ b/arch/arm/mach-pxa/include/mach/debug-macro.S @@ -14,7 +14,6 @@ #include "hardware.h" .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x40000000 @ physical movne \rx, #io_p2v(0x40000000) @ virtual diff --git a/arch/arm/mach-realview/include/mach/debug-macro.S b/arch/arm/mach-realview/include/mach/debug-macro.S index 8662228..801f68b 100644 --- a/arch/arm/mach-realview/include/mach/debug-macro.S +++ b/arch/arm/mach-realview/include/mach/debug-macro.S @@ -34,7 +34,6 @@ #endif .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xfb000000 @ virtual base diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S index 6fc8d66..088335c 100644 --- a/arch/arm/mach-rpc/include/mach/debug-macro.S +++ b/arch/arm/mach-rpc/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x03000000 movne \rx, #0xe0000000 diff --git a/arch/arm/mach-s3c2410/include/mach/debug-macro.S b/arch/arm/mach-s3c2410/include/mach/debug-macro.S index 0eef78b..6db8f51 100644 --- a/arch/arm/mach-s3c2410/include/mach/debug-macro.S +++ b/arch/arm/mach-s3c2410/include/mach/debug-macro.S @@ -20,7 +20,6 @@ #define SHIFT_2440TXF (14-9) .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C24XX_PA_UART ldrne \rx, = S3C24XX_VA_UART diff --git a/arch/arm/mach-s3c24a0/include/mach/debug-macro.S b/arch/arm/mach-s3c24a0/include/mach/debug-macro.S index 239476b..bcc7875 100644 --- a/arch/arm/mach-s3c24a0/include/mach/debug-macro.S +++ b/arch/arm/mach-s3c24a0/include/mach/debug-macro.S @@ -11,7 +11,6 @@ #include <plat/regs-serial.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C24XX_PA_UART ldrne \rx, = S3C24XX_VA_UART diff --git a/arch/arm/mach-s3c64xx/include/mach/debug-macro.S b/arch/arm/mach-s3c64xx/include/mach/debug-macro.S index f9ab5d2..4dbe876 100644 --- a/arch/arm/mach-s3c64xx/include/mach/debug-macro.S +++ b/arch/arm/mach-s3c64xx/include/mach/debug-macro.S @@ -22,7 +22,6 @@ */ .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = (S3C_VA_UART + S3C_PA_UART & 0xfffff) diff --git a/arch/arm/mach-s5p6440/include/mach/debug-macro.S b/arch/arm/mach-s5p6440/include/mach/debug-macro.S index 1347d7f..88e5b94 100644 --- a/arch/arm/mach-s5p6440/include/mach/debug-macro.S +++ b/arch/arm/mach-s5p6440/include/mach/debug-macro.S @@ -20,7 +20,6 @@ */ .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART diff --git a/arch/arm/mach-s5p6442/include/mach/debug-macro.S b/arch/arm/mach-s5p6442/include/mach/debug-macro.S index bb65361..6877b67 100644 --- a/arch/arm/mach-s5p6442/include/mach/debug-macro.S +++ b/arch/arm/mach-s5p6442/include/mach/debug-macro.S @@ -16,7 +16,6 @@ #include <plat/regs-serial.h> .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART diff --git a/arch/arm/mach-s5pc100/include/mach/debug-macro.S b/arch/arm/mach-s5pc100/include/mach/debug-macro.S index 70e02e9..9be36b2 100644 --- a/arch/arm/mach-s5pc100/include/mach/debug-macro.S +++ b/arch/arm/mach-s5pc100/include/mach/debug-macro.S @@ -23,7 +23,6 @@ */ .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART diff --git a/arch/arm/mach-s5pv210/include/mach/debug-macro.S b/arch/arm/mach-s5pv210/include/mach/debug-macro.S index 7872f5c..53c18de 100644 --- a/arch/arm/mach-s5pv210/include/mach/debug-macro.S +++ b/arch/arm/mach-s5pv210/include/mach/debug-macro.S @@ -22,7 +22,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART diff --git a/arch/arm/mach-sa1100/include/mach/debug-macro.S b/arch/arm/mach-sa1100/include/mach/debug-macro.S index 336adcc..c8426cc 100644 --- a/arch/arm/mach-sa1100/include/mach/debug-macro.S +++ b/arch/arm/mach-sa1100/include/mach/debug-macro.S @@ -13,7 +13,6 @@ #include <mach/hardware.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x80000000 @ physical base address movne \rx, #0xf8000000 @ virtual address diff --git a/arch/arm/mach-u300/include/mach/debug-macro.S b/arch/arm/mach-u300/include/mach/debug-macro.S index 92c1242..fb17f1e 100644 --- a/arch/arm/mach-u300/include/mach/debug-macro.S +++ b/arch/arm/mach-u300/include/mach/debug-macro.S @@ -12,7 +12,6 @@ .macro addruart, rx, tmp /* If we move the address using MMU, use this. */ - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, = U300_SLOW_PER_PHYS_BASE @ MMU off, physical address ldrne \rx, = U300_SLOW_PER_VIRT_BASE @ MMU on, virtual address diff --git a/arch/arm/mach-ux500/include/mach/debug-macro.S b/arch/arm/mach-ux500/include/mach/debug-macro.S index c5203b7..c17a27f 100644 --- a/arch/arm/mach-ux500/include/mach/debug-macro.S +++ b/arch/arm/mach-ux500/include/mach/debug-macro.S @@ -19,7 +19,6 @@ #define UART_BASE UX500_UART(CONFIG_UX500_DEBUG_UART) .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =UART_BASE @ no, physical address ldrne \rx, =IO_ADDRESS(UART_BASE) @ yes, virtual address diff --git a/arch/arm/mach-versatile/include/mach/debug-macro.S b/arch/arm/mach-versatile/include/mach/debug-macro.S index 6fea719..1a500ff 100644 --- a/arch/arm/mach-versatile/include/mach/debug-macro.S +++ b/arch/arm/mach-versatile/include/mach/debug-macro.S @@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xf1000000 @ virtual base diff --git a/arch/arm/mach-vexpress/include/mach/debug-macro.S b/arch/arm/mach-vexpress/include/mach/debug-macro.S index 5167e2a..b67863b 100644 --- a/arch/arm/mach-vexpress/include/mach/debug-macro.S +++ b/arch/arm/mach-vexpress/include/mach/debug-macro.S @@ -13,7 +13,6 @@ #define DEBUG_LL_UART_OFFSET 0x00009000 .macro addruart,rx,tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xf8000000 @ virtual base diff --git a/arch/arm/plat-mxc/include/mach/debug-macro.S b/arch/arm/plat-mxc/include/mach/debug-macro.S index 0b6e11e..30a57b9 100644 --- a/arch/arm/plat-mxc/include/mach/debug-macro.S +++ b/arch/arm/plat-mxc/include/mach/debug-macro.S @@ -63,7 +63,6 @@ #define UART_VADDR MXC91231_IO_ADDRESS(MXC91231_UART2_BASE_ADDR) #endif .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =UART_PADDR @ physical ldrne \rx, =UART_VADDR @ virtual diff --git a/arch/arm/plat-spear/include/plat/debug-macro.S b/arch/arm/plat-spear/include/plat/debug-macro.S index 1670734..2fa1522 100644 --- a/arch/arm/plat-spear/include/plat/debug-macro.S +++ b/arch/arm/plat-spear/include/plat/debug-macro.S @@ -15,7 +15,6 @@ #include <mach/spear.h> .macro addruart, rx - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, =SPEAR_DBG_UART_BASE @ Physical base movne \rx, =VA_SPEAR_DBG_UART_BASE @ Virtual base diff --git a/arch/arm/plat-stmp3xxx/include/mach/debug-macro.S b/arch/arm/plat-stmp3xxx/include/mach/debug-macro.S index 1b9348b..2a3ebca 100644 --- a/arch/arm/plat-stmp3xxx/include/mach/debug-macro.S +++ b/arch/arm/plat-stmp3xxx/include/mach/debug-macro.S @@ -17,7 +17,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x80000000 @ physical base address addeq \rx, \rx, #0x00070000 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC, PATCH 1/2] arm: don't check MMU status in every addruart macro 2010-07-12 3:03 ` [RFC,PATCH 1/2] arm: don't check MMU status in every addruart macro Jeremy Kerr @ 2010-07-12 13:32 ` Nicolas Pitre 2010-07-13 1:39 ` Jeremy Kerr 0 siblings, 1 reply; 19+ messages in thread From: Nicolas Pitre @ 2010-07-12 13:32 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Jeremy Kerr wrote: > Rather than checking the MMU status in every instance of addruart, do it > once in kernel/debug.S, and change the existing addruart macros to > expect the uart status in the macro argument register. > > This will also allow us to retreive the address of a uart for the MMU > state that we're not current in. > > Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Many issues with this: - __addruart vs addruart is rather confusing. Normally the __xyz form is used by the higher level xyz which is opposite to what is done here. - While at it, this should be replaced altogether by a macro that simply returns both the physical address and the virtual address for the debugging IO peripheral to use. This would make your patch #2 much straight forward too. - The test to determine whether the MMU is active and select the appropriate address to use should remain close together and actually can be moved to a common place instead of being duplicated everywhere. The code is really testing a specific bit in a hardware register, and with this patch that now looks as if this was a simple boolean argument which is not a good thing. Nicolas ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC, PATCH 1/2] arm: don't check MMU status in every addruart macro 2010-07-12 13:32 ` [RFC, PATCH " Nicolas Pitre @ 2010-07-13 1:39 ` Jeremy Kerr 0 siblings, 0 replies; 19+ messages in thread From: Jeremy Kerr @ 2010-07-13 1:39 UTC (permalink / raw) To: linux-arm-kernel Hi Nicolas, > - __addruart vs addruart is rather confusing. Normally the __xyz form > is used by the higher level xyz which is opposite to what is done > here. Yes, but since __addruart is private to the one file, I decided that this was better than renaming all of the platform addruart macros. Either way is fine with me. However, we may not need this with the suggested return-both-addresses approach. > - While at it, this should be replaced altogether by a macro that simply > returns both the physical address and the virtual address for the > debugging IO peripheral to use. This would make your patch #2 much > straight forward too. OK, I'll try this out. Cheers, Jeremy ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings 2010-07-12 3:03 [RFC,PATCH 0/2] Allow late mdesc detection Jeremy Kerr 2010-07-12 3:03 ` [RFC,PATCH 1/2] arm: don't check MMU status in every addruart macro Jeremy Kerr @ 2010-07-12 3:03 ` Jeremy Kerr 2010-07-12 13:42 ` [RFC, PATCH " Nicolas Pitre 2010-07-12 13:52 ` [RFC,PATCH " Russell King - ARM Linux 2010-07-12 3:39 ` [RFC,PATCH 0/2] Allow late mdesc detection Nicolas Pitre 2 siblings, 2 replies; 19+ messages in thread From: Jeremy Kerr @ 2010-07-12 3:03 UTC (permalink / raw) To: linux-arm-kernel Since we can call addruart with an argument to specify that we want a physical or virtual address, use addruart in the debug mapping code to find these addresses. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> --- arch/arm/Kconfig.debug | 1 - arch/arm/kernel/head.S | 15 ++++++++++++--- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index fbb094a..91344af 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -65,7 +65,6 @@ config DEBUG_STACK_USAGE # These options are only for real kernel hackers who want to get their hands dirty. config DEBUG_LL bool "Kernel low-level debugging functions" - depends on !OF depends on DEBUG_KERNEL help Say Y here to include definitions of printascii, printch, printhex diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 8bfc4bb..9571996 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -22,6 +22,10 @@ #include <asm/thread_info.h> #include <asm/system.h> +#ifdef CONFIG_DEBUG_LL +#include <mach/debug-macro.S> +#endif + #if (PHYS_OFFSET & 0x001fffff) #error "PHYS_OFFSET must be at an even 2MiB boundary!" #endif @@ -305,19 +309,24 @@ __create_page_tables: str r6, [r0] #ifdef CONFIG_DEBUG_LL - ldr r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags /* * Map in IO space for serial debugging. * This allows debug messages to be output * via a serial console before paging_init. */ - ldr r3, [r8, #MACHINFO_PGOFFIO] + mov r3, #1 + addruart r3, r0 + lsr r3, r3, #20 + lsl r3, r3, #2 + add r0, r4, r3 rsb r3, r3, #0x4000 @ PTRS_PER_PGD*sizeof(long) cmp r3, #0x0800 @ limit to 512MB movhi r3, #0x0800 add r6, r0, r3 - ldr r3, [r8, #MACHINFO_PHYSIO] + mov r3, #0 + addruart r3, r7 + ldr r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags orr r3, r3, r7 1: str r3, [r0], #4 add r3, r3, #1 << 20 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC, PATCH 2/2] arm: use addruart macro to establish debug mappings 2010-07-12 3:03 ` [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings Jeremy Kerr @ 2010-07-12 13:42 ` Nicolas Pitre 2010-07-12 13:52 ` [RFC,PATCH " Russell King - ARM Linux 1 sibling, 0 replies; 19+ messages in thread From: Nicolas Pitre @ 2010-07-12 13:42 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Jeremy Kerr wrote: > Since we can call addruart with an argument to specify that we want a > physical or virtual address, use addruart in the debug mapping code to > find these addresses. > > Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> > > --- > arch/arm/Kconfig.debug | 1 - > arch/arm/kernel/head.S | 15 ++++++++++++--- > 2 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index fbb094a..91344af 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -65,7 +65,6 @@ config DEBUG_STACK_USAGE > # These options are only for real kernel hackers who want to get their hands dirty. > config DEBUG_LL > bool "Kernel low-level debugging functions" > - depends on !OF Make sure you start a new topic branch for such features so to be sure it applies on top of a vanilla kernel independently. BTW I'd like to see patch #3 of this series removing the now unused phys_io and io_pg_offst from struct machine_desc, and all corresponding initializations. Nicolas ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings 2010-07-12 3:03 ` [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings Jeremy Kerr 2010-07-12 13:42 ` [RFC, PATCH " Nicolas Pitre @ 2010-07-12 13:52 ` Russell King - ARM Linux 2010-07-13 1:42 ` Jeremy Kerr 1 sibling, 1 reply; 19+ messages in thread From: Russell King - ARM Linux @ 2010-07-12 13:52 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 11:03:12AM +0800, Jeremy Kerr wrote: > - ldr r3, [r8, #MACHINFO_PGOFFIO] > + mov r3, #1 > + addruart r3, r0 > + lsr r3, r3, #20 > + lsl r3, r3, #2 > + > add r0, r4, r3 > rsb r3, r3, #0x4000 @ PTRS_PER_PGD*sizeof(long) > cmp r3, #0x0800 @ limit to 512MB > movhi r3, #0x0800 > add r6, r0, r3 > - ldr r3, [r8, #MACHINFO_PHYSIO] > + mov r3, #0 > + addruart r3, r7 This is insufficient. We are setting up section mappings here, which must have both the physical and virtual addresses aligned to a megabyte boundary. You're aligning the virtual address but doing nothing with the physical one. I also agree with Nicolas - if we're going to do this, we want addruart to return the virtual and physical addresses in two separate registers, and then have the debug code select the appropriate one itself. That will simply this code. So I suggest: Patch #1 - re-jig addruart to return both virtual and physical addresses. Patch #2 - implement setup of debug mapping using addruart. Patch #3 - remove phys_io and pgoffio from machine_desc. I'd also suggest that the patches are against a recent kernel, esp. patch #3 as there's been some changes recently in some of the initializers. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings 2010-07-12 13:52 ` [RFC,PATCH " Russell King - ARM Linux @ 2010-07-13 1:42 ` Jeremy Kerr 0 siblings, 0 replies; 19+ messages in thread From: Jeremy Kerr @ 2010-07-13 1:42 UTC (permalink / raw) To: linux-arm-kernel Hi Russell, > This is insufficient. We are setting up section mappings here, which > must have both the physical and virtual addresses aligned to a megabyte > boundary. You're aligning the virtual address but doing nothing with > the physical one. Ah, I didn't look at the descriptor setup code closely enough. Will do the proper masking in the next series. > I also agree with Nicolas - if we're going to do this, we want addruart > to return the virtual and physical addresses in two separate registers, > and then have the debug code select the appropriate one itself. That > will simply this code. > > So I suggest: > > Patch #1 - re-jig addruart to return both virtual and physical addresses. > Patch #2 - implement setup of debug mapping using addruart. > Patch #3 - remove phys_io and pgoffio from machine_desc. > > I'd also suggest that the patches are against a recent kernel, esp. > patch #3 as there's been some changes recently in some of the > initializers. Yep, sounds like a good approach. Patches coming... Cheers, Jeremy ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-12 3:03 [RFC,PATCH 0/2] Allow late mdesc detection Jeremy Kerr 2010-07-12 3:03 ` [RFC,PATCH 1/2] arm: don't check MMU status in every addruart macro Jeremy Kerr 2010-07-12 3:03 ` [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings Jeremy Kerr @ 2010-07-12 3:39 ` Nicolas Pitre 2010-07-12 8:05 ` Jeremy Kerr 2 siblings, 1 reply; 19+ messages in thread From: Nicolas Pitre @ 2010-07-12 3:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Jeremy Kerr wrote: > Hi all, > > Currently, we probe for a mdesc early in boot. At this early stage, the > only thing we use the mdesc for is to determine the debug page mapping. > > However, the debug addresses (phys and virt) need to be coded into the > addruart macro anyway; the dynamic probing is only going to tell us what > we already know. The fundamental problem with those patches is that we actually want to move in the opposite direction for the eventual support of multiple SOCs in the same kernel, i.e. rely on the machine ID -> mdesc to determine the right debug addresses at run time and eventually make the addruart into something that is not hardcoded at compile time. Nicolas ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-12 3:39 ` [RFC,PATCH 0/2] Allow late mdesc detection Nicolas Pitre @ 2010-07-12 8:05 ` Jeremy Kerr 2010-07-12 8:39 ` Eric Miao 2010-07-12 13:11 ` Nicolas Pitre 0 siblings, 2 replies; 19+ messages in thread From: Jeremy Kerr @ 2010-07-12 8:05 UTC (permalink / raw) To: linux-arm-kernel Hi Nicolas, > The fundamental problem with those patches is that we actually want to > move in the opposite direction for the eventual support of multiple SOCs > in the same kernel, i.e. rely on the machine ID -> mdesc to determine > the right debug addresses at run time and eventually make the addruart > into something that is not hardcoded at compile time. Sure, I think that's where we're going in general, but I think the debug stuff is an exception - we want that up as early as possible, and with as few dependencies on other bits of code as possible. At present we can only ever select one implementation of addruart in a kernel build, so we just can't have a multiplatform kernel with debug support. We *could* add other trickery to select a debug implementation at runtime, but I think adding complexity to the debug path is a bad idea. I think allowing a hard-coded debug system is fine; it can be enabled when we're debugging a specific problem, and removed to enable the true multiplatform support. This is also what is done on powerpc - you can select a "udbg" output method suitable for your platform at compile time, but this doesn't affect the other parts of the kernel. I also think it's good to only specify the debug parameters in one place (addruart), rather than have to provide them in adduart *and* the mdesc. Thoughts? Cheers, Jeremy ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-12 8:05 ` Jeremy Kerr @ 2010-07-12 8:39 ` Eric Miao 2010-07-12 13:11 ` Nicolas Pitre 1 sibling, 0 replies; 19+ messages in thread From: Eric Miao @ 2010-07-12 8:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 4:05 PM, Jeremy Kerr <jeremy.kerr@canonical.com> wrote: > Hi Nicolas, > >> The fundamental problem with those patches is that we actually want to >> move in the opposite direction for the eventual support of multiple SOCs >> in the same kernel, i.e. rely on the machine ID -> mdesc to determine >> the right debug addresses at run time and eventually make the addruart >> into something that is not hardcoded at compile time. > > Sure, I think that's where we're going in general, but I think the debug > stuff is an exception - we want that up as early as possible, and with > as few dependencies on other bits of code as possible. > The debug stuff differs really much from platforms to platforms. My idea maybe we can leave the early debug part alone, so that when debugging on a specific platforms, people have to use a non-multi-platform kernel, and when building a multi-platform kernel, we have to disable the early debugging mess? > At present we can only ever select one implementation of addruart in a > kernel build, so we just can't have a multiplatform kernel with debug > support. We *could* add other trickery to select a debug implementation > at runtime, but I think adding complexity to the debug path is a bad > idea. > > I think allowing a hard-coded debug system is fine; it can be enabled > when we're debugging a specific problem, and removed to enable the true > multiplatform support. This is also what is done on powerpc - you can > select a "udbg" output method suitable for your platform at compile > time, but this doesn't affect the other parts of the kernel. > > I also think it's good to only specify the debug parameters in one place > (addruart), rather than have to provide them in adduart *and* the mdesc. > > Thoughts? > > Cheers, > > > Jeremy > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-12 8:05 ` Jeremy Kerr 2010-07-12 8:39 ` Eric Miao @ 2010-07-12 13:11 ` Nicolas Pitre 2010-07-13 5:44 ` Eric Miao 1 sibling, 1 reply; 19+ messages in thread From: Nicolas Pitre @ 2010-07-12 13:11 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Jul 2010, Jeremy Kerr wrote: > Hi Nicolas, > > > The fundamental problem with those patches is that we actually want to > > move in the opposite direction for the eventual support of multiple SOCs > > in the same kernel, i.e. rely on the machine ID -> mdesc to determine > > the right debug addresses at run time and eventually make the addruart > > into something that is not hardcoded at compile time. > > Sure, I think that's where we're going in general, but I think the debug > stuff is an exception - we want that up as early as possible, and with > as few dependencies on other bits of code as possible. [...] > I also think it's good to only specify the debug parameters in one place > (addruart), rather than have to provide them in adduart *and* the mdesc. OK I'm convinced. I'll comment on the actual implementation separately. PS: I still believe in a per SOC machine ID for DT despite of this, at least for now. If we end up not needing it eventually then it could be ignored which is a far easier thing to do (start to ignore stuff) than bite our fingers because we prematurely ditched it. Nicolas ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-12 13:11 ` Nicolas Pitre @ 2010-07-13 5:44 ` Eric Miao 2010-07-13 7:28 ` Russell King - ARM Linux 0 siblings, 1 reply; 19+ messages in thread From: Eric Miao @ 2010-07-13 5:44 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 12, 2010 at 9:11 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > On Mon, 12 Jul 2010, Jeremy Kerr wrote: > >> Hi Nicolas, >> >> > The fundamental problem with those patches is that we actually want to >> > move in the opposite direction for the eventual support of multiple SOCs >> > in the same kernel, i.e. rely on the machine ID -> mdesc to determine >> > the right debug addresses at run time and eventually make the addruart >> > into something that is not hardcoded at compile time. >> >> Sure, I think that's where we're going in general, but I think the debug >> stuff is an exception - we want that up as early as possible, and with >> as few dependencies on other bits of code as possible. > [...] >> I also think it's good to only specify the debug parameters in one place >> (addruart), rather than have to provide them in adduart *and* the mdesc. > > OK I'm convinced. > > I'll comment on the actual implementation separately. > > PS: I still believe in a per SOC machine ID for DT despite of this, at > ? ?least for now. ?If we end up not needing it eventually then it could > ? ?be ignored which is a far easier thing to do (start to ignore stuff) > ? ?than bite our fingers because we prematurely ditched it. > With the introduction of 'struct machine_class', I guess this is especially true for 1 SoC for one DT machine ID :-) Finally, if we can decide the 'struct machine_class' by something else, then we can merge all DT machine IDs into one or completely ignore it. > > Nicolas > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-13 5:44 ` Eric Miao @ 2010-07-13 7:28 ` Russell King - ARM Linux 2010-07-13 9:02 ` Jeremy Kerr 0 siblings, 1 reply; 19+ messages in thread From: Russell King - ARM Linux @ 2010-07-13 7:28 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 13, 2010 at 01:44:59PM +0800, Eric Miao wrote: > With the introduction of 'struct machine_class', I guess this is especially > true for 1 SoC for one DT machine ID :-) > > Finally, if we can decide the 'struct machine_class' by something else, > then we can merge all DT machine IDs into one or completely ignore it. As far as I can see, DT isn't getting anywhere - certainly my request to see it on a real platform rather than the ARM Ltd hardware seems to have been "forgotten" about. As it's taking soo long (it's getting to be a couple of years) to come up with a DT implementation for a real machine, I can only think that there must be some massive problem(s) with DT which makes it completely unsuitable for use on ARM. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-13 7:28 ` Russell King - ARM Linux @ 2010-07-13 9:02 ` Jeremy Kerr 2010-07-13 9:33 ` Russell King - ARM Linux 0 siblings, 1 reply; 19+ messages in thread From: Jeremy Kerr @ 2010-07-13 9:02 UTC (permalink / raw) To: linux-arm-kernel Hi Russell, > As far as I can see, DT isn't getting anywhere - certainly my request > to see it on a real platform rather than the ARM Ltd hardware seems to > have been "forgotten" about. No, definitely not forgotten. In addition to versatile, I have mx51 booting with a device tree at the moment. The patches are still a little hackish (and a little behind mainline now), but the basic support is there. If you'd like a solid demo of mx51, I can get these patches updated to my most recent arm-dt branch. > As it's taking soo long (it's getting to be a couple of years) to come > up with a DT implementation for a real machine, It's been about 5 months since I started work on DT on ARM; I'm not sure who's been working on it previously, if anyone. So far, most of the time has been preparation work - things like the clk infrastructure, and smaller bits like these addruart patches. We're (me, gcl and nico) also working carefully to specify the interfaces and standards correctly, for example getting the boot interface right, and standard formats for ARM device representation in the DT. So no, there are no massive problems, it's coming along. Cheers, Jeremy ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-13 9:02 ` Jeremy Kerr @ 2010-07-13 9:33 ` Russell King - ARM Linux 2010-07-14 3:25 ` Nicolas Pitre 2010-07-14 4:11 ` Jeremy Kerr 0 siblings, 2 replies; 19+ messages in thread From: Russell King - ARM Linux @ 2010-07-13 9:33 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 13, 2010 at 05:02:26PM +0800, Jeremy Kerr wrote: > It's been about 5 months since I started work on DT on ARM; I'm not sure > who's been working on it previously, if anyone. Grant promised me a DT implementation on a 'real platform' quite some time ago. > So far, most of the time has been preparation work - things like the clk > infrastructure, and smaller bits like these addruart patches. We're (me, > gcl and nico) also working carefully to specify the interfaces and > standards correctly, for example getting the boot interface right, and > standard formats for ARM device representation in the DT. Things like a grand unification of the clk infrastructure, addruart, and boot interface all seem to be relatively minor things compared to determining whether platform support really benefits from DT, which is whole point of my statement on wanting to see a real implementation of it. What I'm interested in its impact on the numerous board support files that we currently have - some 348 of them at the present time. For example, currently these are used to provide small fragments of code to drivers to support what are effectively board quirks. What I'm particularly interested in is how these quirks get attached to their relevant drivers - and whether this becomes easier with DT or harder with it. If it makes this stuff simpler, then all well and good - it's a net benefit. If it makes this a lot more complicated - eg, because we need to declare every bit of quirk code into some kind of table for DT to pick up and bind in some manner to a driver - then moving to DT will be a disaster for maintainability and readability, and we lose type checking on these quirk functions. It's this area, and related areas to it that I'm really interested in, rather than these grand unification schemes which seem to be top priority at the moment. What really concerns me at the moment is that there's soo much work being put into the peripheral DT issues without first answering the question about whether DT on ARM is viable by providing a working real complex platform implementation. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-13 9:33 ` Russell King - ARM Linux @ 2010-07-14 3:25 ` Nicolas Pitre 2010-07-14 4:11 ` Jeremy Kerr 1 sibling, 0 replies; 19+ messages in thread From: Nicolas Pitre @ 2010-07-14 3:25 UTC (permalink / raw) To: linux-arm-kernel On Tue, 13 Jul 2010, Russell King - ARM Linux wrote: > Things like a grand unification of the clk infrastructure, addruart, > and boot interface all seem to be relatively minor things compared > to determining whether platform support really benefits from DT, > which is whole point of my statement on wanting to see a real > implementation of it. Well, I'm afraid we simply won't be able to see benefits until we have a full implementation. But to have a full implementation, we still need to perform some preliminary work. And that preliminary work is beneficial to the code whether or not DT is actually used in the end. So this will be incremental. > What I'm interested in its impact on the numerous board support files > that we currently have - some 348 of them at the present time. For > example, currently these are used to provide small fragments of code > to drivers to support what are effectively board quirks. What I'm > particularly interested in is how these quirks get attached to their > relevant drivers - and whether this becomes easier with DT or harder > with it. My wish for all this DT work is actually _not_ to touch any of those existing 348 board support files. I don't want DT to become a _replacement_ hardware config framework for ARM, but rather an _alternative_ method along with the existing one. So the idea is actually to consider DT support just as another board with its own machine ID. And to make things even more straight forward, I want to have a different machine ID for each SOC family to which DT support is added. This way both the DT way and the traditional way can coexist and allow for easy testing, comparison, validation, and possibly transition for new targets in a non intrusive and disturbing way. > If it makes this stuff simpler, then all well and good - it's a net > benefit. If it makes this a lot more complicated - eg, because we > need to declare every bit of quirk code into some kind of table for > DT to pick up and bind in some manner to a driver - then moving to > DT will be a disaster for maintainability and readability, and we > lose type checking on these quirk functions. By keeping the traditional method around we'll be able to see whether or not DT is actually simpler. I don't think anyone wants to maintain an ugly quirk table, and if DT ends up being so then people will simply continue using the current method. > It's this area, and related areas to it that I'm really interested > in, rather than these grand unification schemes which seem to be top > priority at the moment. Those grand unification schemes are due to an orthogonal issue which is to be able to support more than one SOC family with a single kernel binary, whether or not DT is used. Of course DT support will benefit from that work too. > What really concerns me at the moment is that there's soo much work > being put into the peripheral DT issues without first answering the > question about whether DT on ARM is viable by providing a working > real complex platform implementation. That might only happen incrementally with time. Until then, as I said, the current work may only improve the kernel even without DT. Nicolas ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-13 9:33 ` Russell King - ARM Linux 2010-07-14 3:25 ` Nicolas Pitre @ 2010-07-14 4:11 ` Jeremy Kerr 2010-07-14 15:36 ` Bryan Huntsman 1 sibling, 1 reply; 19+ messages in thread From: Jeremy Kerr @ 2010-07-14 4:11 UTC (permalink / raw) To: linux-arm-kernel Hi Russell, > What I'm interested in its impact on the numerous board support files > that we currently have - some 348 of them at the present time. For > example, currently these are used to provide small fragments of code > to drivers to support what are effectively board quirks. What I'm > particularly interested in is how these quirks get attached to their > relevant drivers - and whether this becomes easier with DT or harder > with it. > > If it makes this stuff simpler, then all well and good - it's a net > benefit. If it makes this a lot more complicated - eg, because we > need to declare every bit of quirk code into some kind of table for > DT to pick up and bind in some manner to a driver - then moving to > DT will be a disaster for maintainability and readability, and we > lose type checking on these quirk functions. OK, I'll do some work to get the mx51 port improved, with a particular focus on demonstrating how the board-specific stuff can be handled. However, we still have a bit of a chicken-and-egg problem here - in order to properly demonstrate what the DT will mean for board support (ie, years down the line), we'd need a larger base of machines ported to DT. I don't see people committing to that work if it may be thrown away if we don't end up using the DT approach. Perhaps we could provide information in two different ways - first, the mx51 and versatile ports as an example of how specific things are done with the DT, and we can chat separately about what you'd like to know about the overall architectural stuff, which can't really be covered in the single-board ports. > It's this area, and related areas to it that I'm really interested > in, rather than these grand unification schemes which seem to be top > priority at the moment. A lot of the unification work is separate from the DT - Nicolas and Eric are working on general kernel consolidation stuff, which is intended to be useful without the DT. At present (and as far as I know), Grant and I are the only ones doing DT-specific infrastructure changes for ARM. > What really concerns me at the moment is that there's soo much work > being put into the peripheral DT issues without first answering the > question about whether DT on ARM is viable by providing a working > real complex platform implementation. They're not all peripheral DT issues, more "core design" of DT on ARM. For example, if there's no way to have a common clk, the DT stuff gets a lot harder. I'm trying to get some of those issues sorted (in a way that is useful even without the DT work) in the process of my overall porting. But yeah, I understand that these don't really help you with evaluating DT on ARM, they're more for my own benefit to work out the issues we'll face doing the work. As these are being resolved, I'm getting closer to demonstratable stuff without gross hacks :) Cheers, Jeremy ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC,PATCH 0/2] Allow late mdesc detection 2010-07-14 4:11 ` Jeremy Kerr @ 2010-07-14 15:36 ` Bryan Huntsman 0 siblings, 0 replies; 19+ messages in thread From: Bryan Huntsman @ 2010-07-14 15:36 UTC (permalink / raw) To: linux-arm-kernel > be useful without the DT. At present (and as far as I know), Grant and I > are the only ones doing DT-specific infrastructure changes for ARM. We did an evaluation of it a few months ago for MSM chips. IIRC, there were a lot of work-arounds needed to accommodate platform data and function pointers. The net result was not a decrease in board file size or complexity. I'll try to find the tree we used and host it somewhere for public review. - Bryan ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-07-14 15:36 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-12 3:03 [RFC,PATCH 0/2] Allow late mdesc detection Jeremy Kerr 2010-07-12 3:03 ` [RFC,PATCH 1/2] arm: don't check MMU status in every addruart macro Jeremy Kerr 2010-07-12 13:32 ` [RFC, PATCH " Nicolas Pitre 2010-07-13 1:39 ` Jeremy Kerr 2010-07-12 3:03 ` [RFC,PATCH 2/2] arm: use addruart macro to establish debug mappings Jeremy Kerr 2010-07-12 13:42 ` [RFC, PATCH " Nicolas Pitre 2010-07-12 13:52 ` [RFC,PATCH " Russell King - ARM Linux 2010-07-13 1:42 ` Jeremy Kerr 2010-07-12 3:39 ` [RFC,PATCH 0/2] Allow late mdesc detection Nicolas Pitre 2010-07-12 8:05 ` Jeremy Kerr 2010-07-12 8:39 ` Eric Miao 2010-07-12 13:11 ` Nicolas Pitre 2010-07-13 5:44 ` Eric Miao 2010-07-13 7:28 ` Russell King - ARM Linux 2010-07-13 9:02 ` Jeremy Kerr 2010-07-13 9:33 ` Russell King - ARM Linux 2010-07-14 3:25 ` Nicolas Pitre 2010-07-14 4:11 ` Jeremy Kerr 2010-07-14 15:36 ` Bryan Huntsman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).