openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/arch/arm/mach-davinci/include/mach/debug-macro.S

89 lines
2.2 KiB
ArmAsm
Raw Normal View History

[ARM] 4303/3: base kernel support for TI DaVinci Add base kernel support for the TI DaVinci platform. This patch only includes interrupts, timers, CPU identification, serial support and basic power and sleep controller init. More drivers to come. Signed-off-by: Kevin Hilman <khilman@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-01 02:37:19 +08:00
/*
* Debugging macro for DaVinci
*
* Author: Kevin Hilman, MontaVista Software, Inc. <source@mvista.com>
*
* 2007 (c) MontaVista Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
* is licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
davinci: use 32-bit accesses for low-level debug macros This patch defines debug macros for low-level debugging for Davinci based platforms Tested on : - DM644x DaVinci EVM - DM646X DaVinciHD EVM - DM355 EVM This patch attempts to solve the low-level debug issue in DM646x. The UART on DM646x SoC allows only 32-bit access. The existing debug-macro.S uses the macros from debug-8250.S file. This led to garbage serial out in the case of DM646x. The inclusion of debug-8250.S does not allow for run time fix for this issue. There are compile time errors due to multiple definitions of the macros. Also when building a single image for multiple DaVinci Platforms, the ifdefs cannot be relied upon. The solution below does not include the debug-8250.S file and defines the necessary macros. This solution was arrived at after observing that word access does not affect the low-level debug messages on DM644x/DM355. The other approach to this issue is to use the UART module information available in the peripheral registers to decide the access mechanism. But this will have to be done for every access of UART specifically for DM646x. Also this calls for a modification of the debug-8250.S file. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-01-19 16:43:05 +08:00
/* Modifications
* Jan 2009 Chaithrika U S Added senduart, busyuart, waituart
* macros, based on debug-8250.S file
* but using 32-bit accesses required for
* some davinci devices.
*/
#include <linux/serial_reg.h>
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
#include <asm/memory.h>
#include <mach/serial.h>
davinci: use 32-bit accesses for low-level debug macros This patch defines debug macros for low-level debugging for Davinci based platforms Tested on : - DM644x DaVinci EVM - DM646X DaVinciHD EVM - DM355 EVM This patch attempts to solve the low-level debug issue in DM646x. The UART on DM646x SoC allows only 32-bit access. The existing debug-macro.S uses the macros from debug-8250.S file. This led to garbage serial out in the case of DM646x. The inclusion of debug-8250.S does not allow for run time fix for this issue. There are compile time errors due to multiple definitions of the macros. Also when building a single image for multiple DaVinci Platforms, the ifdefs cannot be relied upon. The solution below does not include the debug-8250.S file and defines the necessary macros. This solution was arrived at after observing that word access does not affect the low-level debug messages on DM644x/DM355. The other approach to this issue is to use the UART module information available in the peripheral registers to decide the access mechanism. But this will have to be done for every access of UART specifically for DM646x. Also this calls for a modification of the debug-8250.S file. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-01-19 16:43:05 +08:00
#define UART_SHIFT 2
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
.pushsection .data
davinci_uart_phys: .word 0
davinci_uart_virt: .word 0
.popsection
arm: return both physical and virtual addresses from addruart 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 return both physical and virtual addresses. The main debug code can then select the appropriate address to use. This will also allow us to retreive the address of a uart for the MMU state that we're not current in. Updated with fixes for OMAP from Jason Wang <jason77.wang@gmail.com> and Tony Lindgren <tony@atomide.com>, and fix for versatile express from Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jason Wang <jason77.wang@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-06 18:30:06 +08:00
.macro addruart, rp, rv
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
/* Use davinci_uart_phys/virt if already configured */
arm: return both physical and virtual addresses from addruart 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 return both physical and virtual addresses. The main debug code can then select the appropriate address to use. This will also allow us to retreive the address of a uart for the MMU state that we're not current in. Updated with fixes for OMAP from Jason Wang <jason77.wang@gmail.com> and Tony Lindgren <tony@atomide.com>, and fix for versatile express from Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jason Wang <jason77.wang@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-06 18:30:06 +08:00
10: mrc p15, 0, \rp, c1, c0
tst \rp, #1 @ MMU enabled?
ldreq \rp, =__virt_to_phys(davinci_uart_phys)
ldrne \rp, =davinci_uart_phys
add \rv, \rp, #4 @ davinci_uart_virt
ldr \rp, [\rp, #0]
ldr \rv, [\rv, #0]
cmp \rp, #0 @ is port configured?
cmpne \rv, #0
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
bne 99f @ already configured
arm: return both physical and virtual addresses from addruart 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 return both physical and virtual addresses. The main debug code can then select the appropriate address to use. This will also allow us to retreive the address of a uart for the MMU state that we're not current in. Updated with fixes for OMAP from Jason Wang <jason77.wang@gmail.com> and Tony Lindgren <tony@atomide.com>, and fix for versatile express from Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jason Wang <jason77.wang@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-06 18:30:06 +08:00
/* Check the debug UART address set in uncompress.h */
mrc p15, 0, \rp, c1, c0
tst \rp, #1 @ MMU enabled?
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
/* Copy uart phys address from decompressor uart info */
arm: return both physical and virtual addresses from addruart 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 return both physical and virtual addresses. The main debug code can then select the appropriate address to use. This will also allow us to retreive the address of a uart for the MMU state that we're not current in. Updated with fixes for OMAP from Jason Wang <jason77.wang@gmail.com> and Tony Lindgren <tony@atomide.com>, and fix for versatile express from Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jason Wang <jason77.wang@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-06 18:30:06 +08:00
ldreq \rv, =__virt_to_phys(davinci_uart_phys)
ldrne \rv, =davinci_uart_phys
ldreq \rp, =DAVINCI_UART_INFO
ldrne \rp, =__phys_to_virt(DAVINCI_UART_INFO)
ldr \rp, [\rp, #0]
str \rp, [\rv]
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
/* Copy uart virt address from decompressor uart info */
arm: return both physical and virtual addresses from addruart 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 return both physical and virtual addresses. The main debug code can then select the appropriate address to use. This will also allow us to retreive the address of a uart for the MMU state that we're not current in. Updated with fixes for OMAP from Jason Wang <jason77.wang@gmail.com> and Tony Lindgren <tony@atomide.com>, and fix for versatile express from Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>. Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jason Wang <jason77.wang@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-06 18:30:06 +08:00
ldreq \rv, =__virt_to_phys(davinci_uart_virt)
ldrne \rv, =davinci_uart_virt
ldreq \rp, =DAVINCI_UART_INFO
ldrne \rp, =__phys_to_virt(DAVINCI_UART_INFO)
ldr \rp, [\rp, #4]
str \rp, [\rv]
Davinci: generalized debug macros This patch adopts a debug uart selection similar to the OMAP model. During the boot process, the uncompress code determines the physical and virtual base addresses of the board-specific debug uart. These addresses are then passed on to the in-kernel debug macros through a small chunk of memory placed just below the page tables (@0x80003ff8). Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-19 00:51:17 +08:00
b 10b
99:
[ARM] 4303/3: base kernel support for TI DaVinci Add base kernel support for the TI DaVinci platform. This patch only includes interrupts, timers, CPU identification, serial support and basic power and sleep controller init. More drivers to come. Signed-off-by: Kevin Hilman <khilman@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-01 02:37:19 +08:00
.endm
davinci: use 32-bit accesses for low-level debug macros This patch defines debug macros for low-level debugging for Davinci based platforms Tested on : - DM644x DaVinci EVM - DM646X DaVinciHD EVM - DM355 EVM This patch attempts to solve the low-level debug issue in DM646x. The UART on DM646x SoC allows only 32-bit access. The existing debug-macro.S uses the macros from debug-8250.S file. This led to garbage serial out in the case of DM646x. The inclusion of debug-8250.S does not allow for run time fix for this issue. There are compile time errors due to multiple definitions of the macros. Also when building a single image for multiple DaVinci Platforms, the ifdefs cannot be relied upon. The solution below does not include the debug-8250.S file and defines the necessary macros. This solution was arrived at after observing that word access does not affect the low-level debug messages on DM644x/DM355. The other approach to this issue is to use the UART module information available in the peripheral registers to decide the access mechanism. But this will have to be done for every access of UART specifically for DM646x. Also this calls for a modification of the debug-8250.S file. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-01-19 16:43:05 +08:00
.macro senduart,rd,rx
str \rd, [\rx, #UART_TX << UART_SHIFT]
.endm
.macro busyuart,rd,rx
1002: ldr \rd, [\rx, #UART_LSR << UART_SHIFT]
and \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
teq \rd, #UART_LSR_TEMT | UART_LSR_THRE
bne 1002b
.endm
.macro waituart,rd,rx
#ifdef FLOW_CONTROL
1001: ldr \rd, [\rx, #UART_MSR << UART_SHIFT]
tst \rd, #UART_MSR_CTS
beq 1001b
#endif
.endm