* [PATCH RESEND v6 2/4] TI816X: Update common OMAP machine specific sources
From: Hemant Pedanekar @ 2011-02-14 15:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch updates the common machine specific source files with support for
TI816X.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
---
arch/arm/mach-omap2/clock3xxx_data.c | 5 +++-
arch/arm/mach-omap2/common.c | 21 +++++++++++++++
arch/arm/mach-omap2/control.h | 6 ++++
arch/arm/mach-omap2/id.c | 33 ++++++++++++++++++++++-
arch/arm/mach-omap2/include/mach/entry-macro.S | 13 +++++++++
arch/arm/mach-omap2/io.c | 22 +++++++++++++++-
arch/arm/mach-omap2/irq.c | 5 +++-
arch/arm/mach-omap2/serial.c | 8 +++---
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/io.h | 8 ++++++
arch/arm/plat-omap/include/plat/ti816x.h | 27 +++++++++++++++++++
arch/arm/plat-omap/io.c | 5 +++-
12 files changed, 144 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/ti816x.h
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 403a4a1..f14d986 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3471,6 +3471,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_omap3630()) {
cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
cpu_clkflg = CK_36XX;
+ } else if (cpu_is_ti816x()) {
+ cpu_mask = RATE_IN_TI816X;
+ cpu_clkflg = CK_TI816X;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
@@ -3550,7 +3553,7 @@ int __init omap3xxx_clk_init(void)
/*
* Lock DPLL5 and put it in autoidle.
*/
- if (omap_rev() >= OMAP3430_REV_ES2_0)
+ if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
omap3_clk_lock_dpll5();
/* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index d5eaee3..48de451 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -108,6 +108,27 @@ void __init omap3_map_io(void)
omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
+
+/*
+ * Adjust TAP register base such that omap3_check_revision accesses the correct
+ * TI816X register for checking device ID (it adds 0x204 to tap base while
+ * TI816X DEVICE ID register is at offset 0x600 from control base).
+ */
+#define TI816X_TAP_BASE (TI816X_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals ti816x_globals = {
+ .class = OMAP343X_CLASS,
+ .tap = OMAP2_L4_IO_ADDRESS(TI816X_TAP_BASE),
+ .ctrl = TI816X_CTRL_BASE,
+ .prm = TI816X_PRCM_BASE,
+ .cm = TI816X_PRCM_BASE,
+};
+
+void __init omap2_set_globals_ti816x(void)
+{
+ __omap2_set_globals(&ti816x_globals);
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..c2804c1 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -52,6 +52,9 @@
#define OMAP343X_CONTROL_PADCONFS_WKUP 0xa00
#define OMAP343X_CONTROL_GENERAL_WKUP 0xa60
+/* TI816X spefic control submodules */
+#define TI816X_CONTROL_DEVCONF 0x600
+
/* Control register offsets - read/write with omap_ctrl_{read,write}{bwl}() */
#define OMAP2_CONTROL_SYSCONFIG (OMAP2_CONTROL_INTERFACE + 0x10)
@@ -241,6 +244,9 @@
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK 0x254
+/* TI816X CONTROL_DEVCONF register offsets */
+#define TI816X_CONTROL_DEVICE_ID (TI816X_CONTROL_DEVCONF + 0x000)
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..5c25f1b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -191,12 +191,19 @@ static void __init omap3_check_features(void)
if (!cpu_is_omap3505() && !cpu_is_omap3517())
omap3_features |= OMAP3_HAS_IO_WAKEUP;
+ omap3_features |= OMAP3_HAS_SDRC;
+
/*
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
}
+static void __init ti816x_check_features(void)
+{
+ omap3_features = OMAP3_HAS_NEON;
+}
+
static void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
@@ -287,6 +294,20 @@ static void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
}
break;
+ case 0xb81e:
+ omap_chip.oc = CHIP_IS_TI816X;
+
+ switch (rev) {
+ case 0:
+ omap_revision = TI8168_REV_ES1_0;
+ break;
+ case 1:
+ omap_revision = TI8168_REV_ES1_1;
+ break;
+ default:
+ omap_revision = TI8168_REV_ES1_1;
+ }
+ break;
default:
/* Unknown default to latest silicon rev as default*/
omap_revision = OMAP3630_REV_ES1_2;
@@ -372,6 +393,8 @@ static void __init omap3_cpuinfo(void)
/* Already set in omap3_check_revision() */
strcpy(cpu_name, "AM3505");
}
+ } else if (cpu_is_ti816x()) {
+ strcpy(cpu_name, "TI816X");
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, "OMAP3430/3530");
@@ -386,7 +409,7 @@ static void __init omap3_cpuinfo(void)
strcpy(cpu_name, "OMAP3503");
}
- if (cpu_is_omap3630()) {
+ if (cpu_is_omap3630() || cpu_is_ti816x()) {
switch (rev) {
case OMAP_REVBITS_00:
strcpy(cpu_rev, "1.0");
@@ -462,7 +485,13 @@ void __init omap2_check_revision(void)
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
- omap3_check_features();
+
+ /* TI816X doesn't have feature register */
+ if (!cpu_is_ti816x())
+ omap3_check_features();
+ else
+ ti816x_check_features();
+
omap3_cpuinfo();
return;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S
index 81985a6..a48690b 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -61,6 +61,14 @@
bne 9998f
ldr \irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
cmp \irqnr, #0x0
+ bne 9998f
+
+ /*
+ * ti816x has additional IRQ pending register. Checking this
+ * register on omap2 & omap3 has no effect (read as 0).
+ */
+ ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */
+ cmp \irqnr, #0x0
9998:
ldrne \irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
and \irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
@@ -133,6 +141,11 @@
bne 9999f
ldr \irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
cmp \irqnr, #0x0
+#ifdef CONFIG_SOC_OMAPTI816X
+ bne 9999f
+ ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */
+ cmp \irqnr, #0x0
+#endif
9999:
ldrne \irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
and \irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 11decd8..87b13ab 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -175,6 +175,18 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
#endif
};
#endif
+
+#ifdef CONFIG_SOC_OMAPTI816X
+static struct map_desc omapti816x_io_desc[] __initdata = {
+ {
+ .virtual = L4_34XX_VIRT,
+ .pfn = __phys_to_pfn(L4_34XX_PHYS),
+ .length = L4_34XX_SIZE,
+ .type = MT_DEVICE
+ },
+};
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static struct map_desc omap44xx_io_desc[] __initdata = {
{
@@ -267,6 +279,14 @@ void __init omap34xx_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPTI816X
+void __init omapti816x_map_common_io(void)
+{
+ iotable_init(omapti816x_io_desc, ARRAY_SIZE(omapti816x_io_desc));
+ _omap2_map_common_io();
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
void __init omap44xx_map_common_io(void)
{
@@ -402,7 +422,7 @@ void __init omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
omap_hwmod_late_init();
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ if (omap3_has_sdrc()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
}
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index d151aac..bc524b9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -108,7 +108,7 @@ static void omap_mask_irq(struct irq_data *d)
unsigned int irq = d->irq;
int offset = irq & (~(IRQ_BITS_PER_REG - 1));
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
int spurious = 0;
/*
@@ -203,6 +203,9 @@ void __init omap_init_irq(void)
BUG_ON(!base);
+ if (cpu_is_ti816x())
+ bank->nr_irqs = 128;
+
/* Static mapping, never released */
bank->base_reg = ioremap(base, SZ_4K);
if (!bank->base_reg) {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 32e91a9..36a2828 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -486,7 +486,7 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
mod_timer(&uart->timer, jiffies + uart->timeout);
omap_uart_smart_idle_enable(uart, 0);
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
@@ -759,13 +759,13 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
p->private_data = uart;
/*
- * omap44xx: Never read empty UART fifo
+ * omap44xx, ti816x: Never read empty UART fifo
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev >=0x52
*/
uart->regshift = p->regshift;
uart->membase = p->membase;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx() || cpu_is_ti816x())
uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
>= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
@@ -847,7 +847,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
}
/* Enable the MDR1 errata for OMAP3 */
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() && !cpu_is_ti816x())
uart->errata |= UART_ERRATA_i202_MDR1_ACCESS;
}
diff --git a/arch/arm/plat-omap/include/plat/hardware.h b/arch/arm/plat-omap/include/plat/hardware.h
index d5b26ad..e87efe1 100644
--- a/arch/arm/plat-omap/include/plat/hardware.h
+++ b/arch/arm/plat-omap/include/plat/hardware.h
@@ -286,5 +286,6 @@
#include <plat/omap24xx.h>
#include <plat/omap34xx.h>
#include <plat/omap44xx.h>
+#include <plat/ti816x.h>
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
index 478c5d9..d72ec85 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -283,6 +283,14 @@ static inline void omap34xx_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPTI816X
+extern void omapti816x_map_common_io(void);
+#else
+static inline void omapti816x_map_common_io(void)
+{
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
extern void omap44xx_map_common_io(void);
#else
diff --git a/arch/arm/plat-omap/include/plat/ti816x.h b/arch/arm/plat-omap/include/plat/ti816x.h
new file mode 100644
index 0000000..50510f5
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/ti816x.h
@@ -0,0 +1,27 @@
+/*
+ * This file contains the address data for various TI816X modules.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARCH_TI816X_H
+#define __ASM_ARCH_TI816X_H
+
+#define L4_SLOW_TI816X_BASE 0x48000000
+
+#define TI816X_SCM_BASE 0x48140000
+#define TI816X_CTRL_BASE TI816X_SCM_BASE
+#define TI816X_PRCM_BASE 0x48180000
+
+#define TI816X_ARM_INTC_BASE 0x48200000
+
+#endif /* __ASM_ARCH_TI816X_H */
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index f1295fa..f1ecfa9 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -85,7 +85,10 @@ void __iomem *omap_ioremap(unsigned long p, size_t size, unsigned int type)
}
#endif
#ifdef CONFIG_ARCH_OMAP3
- if (cpu_is_omap34xx()) {
+ if (cpu_is_ti816x()) {
+ if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
+ return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
+ } else if (cpu_is_omap34xx()) {
if (BETWEEN(p, L3_34XX_PHYS, L3_34XX_SIZE))
return XLATE(p, L3_34XX_PHYS, L3_34XX_VIRT);
if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
--
1.7.3.5
^ permalink raw reply related
* [PATCH RESEND v6 1/4] TI816X: Update common omap platform files
From: Hemant Pedanekar @ 2011-02-14 15:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch updates the common platform files with TI816X support.
The approach taken in this patch is to add TI816X as part of OMAP3 variant where
the cpu class is considered as OMAP34XX and the type is TI816X. This means, both
cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X.
A kernel config option CONFIG_SOC_OMAPTI816X is added under OMAP3 to include
support for TI816X build.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
---
arch/arm/mach-omap2/Kconfig | 5 +++++
arch/arm/plat-omap/include/plat/clkdev_omap.h | 1 +
arch/arm/plat-omap/include/plat/clock.h | 1 +
arch/arm/plat-omap/include/plat/common.h | 1 +
arch/arm/plat-omap/include/plat/cpu.h | 18 ++++++++++++++++++
5 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ae7f47d..6a4cfc2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -72,6 +72,11 @@ config SOC_OMAP3430
default y
select ARCH_OMAP_OTG
+config SOC_OMAPTI816X
+ bool "TI816X support"
+ depends on ARCH_OMAP3
+ default y
+
config OMAP_PACKAGE_ZAF
bool
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index 256ab3f..f1899a3 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -38,6 +38,7 @@ struct omap_clk {
#define CK_3517 (1 << 9)
#define CK_36XX (1 << 10) /* 36xx/37xx-specific clocks */
#define CK_443X (1 << 11)
+#define CK_TI816X (1 << 12)
#define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS)
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index 8eb0ada..d43e623 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -53,6 +53,7 @@ struct clkops {
#define RATE_IN_3430ES2PLUS (1 << 3) /* 3430 ES >= 2 rates only */
#define RATE_IN_36XX (1 << 4)
#define RATE_IN_4430 (1 << 5)
+#define RATE_IN_TI816X (1 << 6)
#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
#define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index 29b2afb..1dd97e7 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -66,6 +66,7 @@ void omap2_set_globals_242x(void);
void omap2_set_globals_243x(void);
void omap2_set_globals_3xxx(void);
void omap2_set_globals_443x(void);
+void omap2_set_globals_ti816x(void);
/* These get called from omap2_set_globals_xxxx(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 73d91ee..864f1ec 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -105,6 +105,12 @@ static inline int is_omap ##subclass (void) \
return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
}
+#define IS_TI_SUBCLASS(subclass, id) \
+static inline int is_ti ##subclass (void) \
+{ \
+ return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
+}
+
IS_OMAP_CLASS(7xx, 0x07)
IS_OMAP_CLASS(15xx, 0x15)
IS_OMAP_CLASS(16xx, 0x16)
@@ -118,6 +124,8 @@ IS_OMAP_SUBCLASS(343x, 0x343)
IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
+IS_TI_SUBCLASS(816x, 0x816)
+
#define cpu_is_omap7xx() 0
#define cpu_is_omap15xx() 0
#define cpu_is_omap16xx() 0
@@ -126,6 +134,7 @@ IS_OMAP_SUBCLASS(443x, 0x443)
#define cpu_is_omap243x() 0
#define cpu_is_omap34xx() 0
#define cpu_is_omap343x() 0
+#define cpu_is_ti816x() 0
#define cpu_is_omap44xx() 0
#define cpu_is_omap443x() 0
@@ -330,6 +339,7 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3530
# undef cpu_is_omap3505
# undef cpu_is_omap3517
+# undef cpu_is_ti816x
# define cpu_is_omap3430() is_omap3430()
# define cpu_is_omap3503() (cpu_is_omap3430() && \
(!omap3_has_iva()) && \
@@ -345,6 +355,7 @@ IS_OMAP_TYPE(3517, 0x3517)
# define cpu_is_omap3517() is_omap3517()
# undef cpu_is_omap3630
# define cpu_is_omap3630() is_omap363x()
+# define cpu_is_ti816x() is_ti816x()
#endif
# if defined(CONFIG_ARCH_OMAP4)
@@ -389,6 +400,10 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 << 16) | (v << 8))
#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 << 16) | (v << 8))
+#define TI816X_CLASS 0x81600034
+#define TI8168_REV_ES1_0 TI816X_CLASS
+#define TI8168_REV_ES1_1 (TI816X_CLASS | (OMAP_REVBITS_01 << 8))
+
#define OMAP443X_CLASS 0x44300044
#define OMAP4430_REV_ES1_0 OMAP443X_CLASS
#define OMAP4430_REV_ES2_0 0x44301044
@@ -419,6 +434,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define CHIP_IS_OMAP3630ES1_1 (1 << 9)
#define CHIP_IS_OMAP3630ES1_2 (1 << 10)
#define CHIP_IS_OMAP4430ES2 (1 << 11)
+#define CHIP_IS_TI816X (1 << 12)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
@@ -455,6 +471,7 @@ extern u32 omap3_features;
#define OMAP3_HAS_ISP BIT(4)
#define OMAP3_HAS_192MHZ_CLK BIT(5)
#define OMAP3_HAS_IO_WAKEUP BIT(6)
+#define OMAP3_HAS_SDRC BIT(7)
#define OMAP3_HAS_FEATURE(feat,flag) \
static inline unsigned int omap3_has_ ##feat(void) \
@@ -469,5 +486,6 @@ OMAP3_HAS_FEATURE(neon, NEON)
OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
+OMAP3_HAS_FEATURE(sdrc, SDRC)
#endif
--
1.7.3.5
^ permalink raw reply related
* [PATCH RESEND v6 0/4] Introduce support for TI816X processor series
From: Hemant Pedanekar @ 2011-02-14 15:03 UTC (permalink / raw)
To: linux-arm-kernel
(Resending v6 with cc: linux-arm-kernel)
This patch set adds support for TI816X processor series. This series includes
DM8168, C6A816x and AM389x devices.
The details can be found at following links:
http://focus.ti.com/general/docs/gencontent.tsp?contentId=77960
http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml
This series is architecturally closer to the OMAP devices. Hence, these patches
are being submitted on linux-omap.
These patches are tested on OMAP3 EVM with multi-omap build.
Note that, additional patches consisting of TI816X specific hwmods, clock data
and DMTIMER changes, are required to enable successful booting on TI816X EVM.
These patches will follow shortly.
The TI816X support is added as part of OMAP3 variant. The approach taken is in
accordance to the discussions in thread related to following post:
http://www.spinics.net/lists/linux-omap/msg41505.html
In addition, TI816X specific customizations/optimizations are handled as a part
of build configuration CONFIG_SOC_OMAPTI816X. Discussed here:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41927.html
Hemant Pedanekar (4):
TI816X: Update common omap platform files
TI816X: Update common OMAP machine specific sources
TI816X: Create board support and enable build for TI816X EVM
TI816X: Add low level debug support
arch/arm/mach-omap2/Kconfig | 10 ++++
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-ti8168evm.c | 57 ++++++++++++++++++++++++
arch/arm/mach-omap2/clock3xxx_data.c | 5 ++-
arch/arm/mach-omap2/common.c | 21 +++++++++
arch/arm/mach-omap2/control.h | 6 +++
arch/arm/mach-omap2/id.c | 33 +++++++++++++-
arch/arm/mach-omap2/include/mach/debug-macro.S | 12 +++++
arch/arm/mach-omap2/include/mach/entry-macro.S | 13 +++++
arch/arm/mach-omap2/io.c | 22 +++++++++-
arch/arm/mach-omap2/irq.c | 5 ++-
arch/arm/mach-omap2/serial.c | 8 ++--
arch/arm/plat-omap/include/plat/clkdev_omap.h | 1 +
arch/arm/plat-omap/include/plat/clock.h | 1 +
arch/arm/plat-omap/include/plat/common.h | 1 +
arch/arm/plat-omap/include/plat/cpu.h | 18 +++++++
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/io.h | 8 +++
arch/arm/plat-omap/include/plat/serial.h | 8 +++
arch/arm/plat-omap/include/plat/ti816x.h | 27 +++++++++++
arch/arm/plat-omap/include/plat/uncompress.h | 7 +++
arch/arm/plat-omap/io.c | 5 ++-
22 files changed, 260 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-ti8168evm.c
create mode 100644 arch/arm/plat-omap/include/plat/ti816x.h
--
1.7.3.5
^ permalink raw reply
* [PATCH v5 3/5] OMAP4: hwmod data: add mailbox data
From: Cousson, Benoit @ 2011-02-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296674843-12718-4-git-send-email-omar.ramirez@ti.com>
Hi Omar,
I found one minor change wrt to the original that I'd like to understand
better.
On 2/2/2011 8:27 PM, Ramirez Luna, Omar wrote:
> From: Benoit Cousson<b-cousson@ti.com>
>
> Mailbox hwmod data for omap4.
>
> Signed-off-by: Benoit Cousson<b-cousson@ti.com>
> Signed-off-by: Omar Ramirez Luna<omar.ramirez@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 67 ++++++++++++++++++++++++++++
> 1 files changed, 67 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index c2806bd..c495669 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2001,6 +2001,70 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> };
>
> +/*
> + * 'mailbox' class
> + * mailbox module allowing communication between the on-chip processors
> + * using a queued mailbox-interrupt mechanism.
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap44xx_mailbox_sysc = {
> + .rev_offs = 0x0000,
> + .sysc_offs = 0x0010,
> + .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
> + SYSC_HAS_SOFTRESET),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields =&omap_hwmod_sysc_type2,
> +};
> +
> +static struct omap_hwmod_class omap44xx_mailbox_hwmod_class = {
> + .name = "mailbox",
> + .sysc =&omap44xx_mailbox_sysc,
> +};
> +
> +/* mailbox */
> +static struct omap_hwmod omap44xx_mailbox_hwmod;
> +static struct omap_hwmod_irq_info omap44xx_mailbox_irqs[] = {
> + { .name = "mbox", .irq = 26 + OMAP44XX_IRQ_GIC_START, },
The original entry was unnamed since it is an unique entry and thus does
not need to be differentiate on this platform.
{ .irq = 26 + OMAP44XX_IRQ_GIC_START },
Do you really need to have a name here? The strategy being to provide a
name only if more than one entry exist.
It is perfectibility doable, I'm just trying to understand your rational.
Thanks,
Benoit
^ permalink raw reply
* [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
From: Nicolas Pitre @ 2011-02-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110214131750.GA2869@arm.com>
On Mon, 14 Feb 2011, Dave Martin wrote:
> @@ -289,8 +297,20 @@ clean_l2:
> * - should be faster and will change with kernel
> * - 'might' have to copy address, load and jump to it
> */
> +#ifdef CONFIG_THUMB2_KERNEL
> + /* kernel is non-interworking : must do this from Thumb */
> + adr r1, . + 1
> + bx r1
> + .thumb
> +#endif
> ldr r1, kernel_flush
Didn't you mean this instead:
/* kernel is non-interworking : must do this from Thumb */
adr r1, 1f + 1
bx r1
.thumb
1: ldr r1, kernel_flush
...
?
> blx r1
> +#ifdef CONFIG_THUMB2_KERNEL
> + .align
> + bx pc
> + nop
> + .arm
Also here, the .align has the potential to introduce a zero halfword in
the instruction stream before the bx. What about:
adr r3, 1f
bx r3
.align
.arm
1: ...
Nicolas
^ permalink raw reply
* [PATCH 2/2] P2V: Thumb2 support
From: Dave Martin @ 2011-02-14 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102140935300.14920@xanadu.home>
Hi,
On Mon, Feb 14, 2011 at 2:48 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 14 Feb 2011, Dave Martin wrote:
>
>> On Sat, Feb 12, 2011 at 6:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > ?__fixup_a_pv_table:
>> > +#ifdef CONFIG_THUMB2_KERNEL
>> > +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
>> > + ? ? ? lsls ? ?r0, r6, #24
>> > + ? ? ? lsr ? ? r6, #8
>> > + ? ? ? beq ? ? 1f
>> > + ? ? ? clz ? ? r7, r0
>> > + ? ? ? lsrs ? ?r0, #24
>> > + ? ? ? lsls ? ?r0, r7
>> > + ? ? ? bic ? ? r0, 0x0080
>> > + ? ? ? lsrs ? ?r7, #1
>> > + ? ? ? orrcs ? r0, #0x0080
>> > + ? ? ? orr ? ? r0, r0, r7, lsl #12
>> > +#endif
>> > +1: ? ? lsls ? ?r6, #24
>> > + ? ? ? beq ? ? 4f
>> > + ? ? ? clz ? ? r7, r6
>> > + ? ? ? lsrs ? ?r6, #24
>> > + ? ? ? lsls ? ?r6, r7
>> > + ? ? ? bic ? ? r6, #0x0080
>> > + ? ? ? lsrs ? ?r7, #1
>> > + ? ? ? orrcs ? r6, #0x0080
>> > + ? ? ? orr ? ? r6, r6, r7, lsl #12
>> > + ? ? ? orr ? ? r6, #0x4000
>> > + ? ? ? b ? ? ? 4f
>>
>> We do almost the same, complex, operation twice here ... can it be
>> factorised with a macro or something? ?This may also help readability.
>> ?Not essential though.
>
> I'm not sure. ?There is potentially only 7 instructions which are common
> to both cases which would form a logical group. ?Hiding that behind a
> macro doesn't save much here.
I was thinking more of avoiding mis-maintanance by ensuring there's
only one copy of the code to edit. It wouldn't be a saving as such.
Either way, I agree that it's not that important, since it's not a lot
of code.
>> > +2: ? ? add ? ? r7, r3
>> > +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
>> > + ? ? ? ldrh ? ?ip, [r7]
>> > + ? ? ? tst ? ? ip, 0x0400 ? ? ?@ the i bit tells us LS or MS byte
>>
>> Might be helpful to comment that we rely on TST resetting the C flag?
>
> The tst instruction doesn't touch the C flag. ?It is already cleared by
> the loop condition. ?But yes, a comment to that effect might be good.
You're right ... the comment would have helped me, then :)
>
>> > + ? ? ? beq ? ? 3f
>> > + ? ? ? cmp ? ? r0, #0 ? ? ? ? ?@ set C flag, and ...
>> > + ? ? ? biceq ? ip, 0x0400 ? ? ?@ immediate zero value has a special encoding
>> > + ? ? ? streqh ?ip, [r7] ? ? ? ?@ that requires the i bit cleared
>> > +#endif
>> > +3: ? ? ldrh ? ?ip, [r7, #2]
>> > + ? ? ? and ? ? ip, 0x8f00
>> > + ? ? ? orrcc ? ip, r6 ?@ mask in offset bits 31-24
>> > + ? ? ? orrcs ? ip, r0 ?@ mask in offset bits 23-16
>> > + ? ? ? strh ? ?ip, [r7, #2]
>> > +4: ? ? cmp ? ? r4, r5
>> > + ? ? ? ?ldrcc ? r7, [r4], #4 ? @ use branch for delay slot
>> > + ? ? ? ?bcc ? ?2b
>> > + ? ? ? ?bx ? ? lr
>> > +#else
>> > ?#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
>> > ? ? ? ?and ? ? r0, r6, #255 ? ?@ offset bits 23-16
>> > ? ? ? ?mov ? ? r6, r6, lsr #8 ?@ offset bits 31-24
>> > @@ -513,6 +558,7 @@ __fixup_a_pv_table:
>> > ? ? ? ?ldrcc ? r7, [r4], #4 ? ?@ use branch for delay slot
>> > ? ? ? ?bcc ? ? 2b
>> > ? ? ? ?mov ? ? pc, lr
>> > +#endif
>> > ?ENDPROC(__fixup_a_pv_table)
>> >
>> > ?ENTRY(fixup_pv_table)
>> > --
>> > 1.7.4
>> >
>>
>> Not sure I entirely all the implications of this code, and I haven't
>> tested it yet, but it looks sound if I've understood it correctly.
>>
>> Reviewed-by: Dave Martin <dave.martin@linaro.org>
>
> Thanks. ?I'll also remove the s flag to those insns that don't need it
> for clarity.
OK, sounds fine.
---Dave
^ permalink raw reply
* [PATCH 2/2] P2V: Thumb2 support
From: Nicolas Pitre @ 2011-02-14 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinK9JkCMJ4B1vZVMpCmROJK4NyEcFCL5+tNP0mW@mail.gmail.com>
On Mon, 14 Feb 2011, Dave Martin wrote:
> On Sat, Feb 12, 2011 at 6:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > ?__fixup_a_pv_table:
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> > + ? ? ? lsls ? ?r0, r6, #24
> > + ? ? ? lsr ? ? r6, #8
> > + ? ? ? beq ? ? 1f
> > + ? ? ? clz ? ? r7, r0
> > + ? ? ? lsrs ? ?r0, #24
> > + ? ? ? lsls ? ?r0, r7
> > + ? ? ? bic ? ? r0, 0x0080
> > + ? ? ? lsrs ? ?r7, #1
> > + ? ? ? orrcs ? r0, #0x0080
> > + ? ? ? orr ? ? r0, r0, r7, lsl #12
> > +#endif
> > +1: ? ? lsls ? ?r6, #24
> > + ? ? ? beq ? ? 4f
> > + ? ? ? clz ? ? r7, r6
> > + ? ? ? lsrs ? ?r6, #24
> > + ? ? ? lsls ? ?r6, r7
> > + ? ? ? bic ? ? r6, #0x0080
> > + ? ? ? lsrs ? ?r7, #1
> > + ? ? ? orrcs ? r6, #0x0080
> > + ? ? ? orr ? ? r6, r6, r7, lsl #12
> > + ? ? ? orr ? ? r6, #0x4000
> > + ? ? ? b ? ? ? 4f
>
> We do almost the same, complex, operation twice here ... can it be
> factorised with a macro or something? This may also help readability.
> Not essential though.
I'm not sure. There is potentially only 7 instructions which are common
to both cases which would form a logical group. Hiding that behind a
macro doesn't save much here.
> > +2: ? ? add ? ? r7, r3
> > +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> > + ? ? ? ldrh ? ?ip, [r7]
> > + ? ? ? tst ? ? ip, 0x0400 ? ? ?@ the i bit tells us LS or MS byte
>
> Might be helpful to comment that we rely on TST resetting the C flag?
The tst instruction doesn't touch the C flag. It is already cleared by
the loop condition. But yes, a comment to that effect might be good.
> > + ? ? ? beq ? ? 3f
> > + ? ? ? cmp ? ? r0, #0 ? ? ? ? ?@ set C flag, and ...
> > + ? ? ? biceq ? ip, 0x0400 ? ? ?@ immediate zero value has a special encoding
> > + ? ? ? streqh ?ip, [r7] ? ? ? ?@ that requires the i bit cleared
> > +#endif
> > +3: ? ? ldrh ? ?ip, [r7, #2]
> > + ? ? ? and ? ? ip, 0x8f00
> > + ? ? ? orrcc ? ip, r6 ?@ mask in offset bits 31-24
> > + ? ? ? orrcs ? ip, r0 ?@ mask in offset bits 23-16
> > + ? ? ? strh ? ?ip, [r7, #2]
> > +4: ? ? cmp ? ? r4, r5
> > + ? ? ? ?ldrcc ? r7, [r4], #4 ? @ use branch for delay slot
> > + ? ? ? ?bcc ? ?2b
> > + ? ? ? ?bx ? ? lr
> > +#else
> > ?#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> > ? ? ? ?and ? ? r0, r6, #255 ? ?@ offset bits 23-16
> > ? ? ? ?mov ? ? r6, r6, lsr #8 ?@ offset bits 31-24
> > @@ -513,6 +558,7 @@ __fixup_a_pv_table:
> > ? ? ? ?ldrcc ? r7, [r4], #4 ? ?@ use branch for delay slot
> > ? ? ? ?bcc ? ? 2b
> > ? ? ? ?mov ? ? pc, lr
> > +#endif
> > ?ENDPROC(__fixup_a_pv_table)
> >
> > ?ENTRY(fixup_pv_table)
> > --
> > 1.7.4
> >
>
> Not sure I entirely all the implications of this code, and I haven't
> tested it yet, but it looks sound if I've understood it correctly.
>
> Reviewed-by: Dave Martin <dave.martin@linaro.org>
Thanks. I'll also remove the s flag to those insns that don't need it
for clarity.
Nicolas
^ permalink raw reply
* Machine ID question
From: John Linn @ 2011-02-14 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210082915.GV27982@pengutronix.de>
> -----Original Message-----
> From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
> Sent: Thursday, February 10, 2011 1:29 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: Re: Machine ID question
>
> On Wed, Feb 09, 2011 at 02:23:07PM -0700, John Linn wrote:
> > I used the form to create a new machine ID for the new Xilinx platform
> > in anticipation of
> > the code making it into the mainline sometime in the future.
> >
> > The proposed patches are using ARCH_XILINX in the Kconfig.
> You should use MACH_XILINX in the patches. There are some ARCH_... in
> the machine db, but I think nowadays you cannot (and should not) create
> them there.
Russell, should I change from ARCH_XILINX to MACH_XILINX in the V3 of my patchset?
>
> >
> > Below is the line that it created when I clicked on this link:
> > http://www.arm.linux.org.uk/developer/machines/download.php
> >
> > xilinx MACH_XILINX XILINX
> > 3343
> >
> > Did I hose it up as the form wasn't completely clear to me (if I needed
> > to enter ARCH_XILINX)?
> >
> > Thanks,
> > John
> >
> >
> >
> > This email and any attachments are intended for the sole use of the
> > named recipient(s) and contain(s) confidential information that may be
> hmm, I'm at least not named explicitly, still I think the intention of
> your mail was to get an answer. IMHO it's not very sensible to add this
> footer on postings to public mailing lists.
Agreed. Not my choice and will discuss more with others to see if I can
get around it and still use corporate email.
>
> > proprietary, privileged or copyrighted under applicable law. If you
> > are not the intended recipient, do not read, copy, or forward this
> > email message or any attachments. Delete this email message and any
> > attachments immediately.
>
> Best regards
> Uwe
Thanks Uwe,
-- John
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH V2 3/4] ARM: Xilinx: base header files and assemblymacros
From: John Linn @ 2011-02-14 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212121609.GI15616@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Saturday, February 12, 2011 5:16 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; catalin.marinas at arm.com;
> glikely at secretlab.ca
> Subject: Re: [PATCH V2 3/4] ARM: Xilinx: base header files and
assemblymacros
>
> On Wed, Feb 09, 2011 at 10:00:44AM -0700, John Linn wrote:
> > +#ifndef __MACH_VMALLOC_H__
> > +#define __MACH_VMALLOC_H__
> > +
> > +#define VMALLOC_END 0xE0000000
>
> Should have a UL suffix on this.
OK, easy to fix.
Thanks for another review Russell, appreciate your time and help.
-- John
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH V2 1/4] ARM: Xilinx: Adding Xilinx board support
From: John Linn @ 2011-02-14 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212121320.GH15616@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Saturday, February 12, 2011 5:13 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; catalin.marinas at arm.com;
> glikely at secretlab.ca
> Subject: Re: [PATCH V2 1/4] ARM: Xilinx: Adding Xilinx board support
>
> On Wed, Feb 09, 2011 at 10:00:42AM -0700, John Linn wrote:
> > +/* arch/arm/mach-xilinx/board_ep107.c
> > + *
> > + * This file contains code specific to the Xilinx EP107 board.
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * based on /arch/arm/mach-realview/core.c
> > + *
> > + * Copyright (C) 1999 - 2003 ARM Limited
> > + * Copyright (C) 2000 Deep Blue Solutions Ltd
> > + *
> > + * This program is free software; you can redistribute it and/or
modify
> > + * it under the terms of the GNU General Public License as
published by
> > + * the Free Software Foundation; either version 2 of the License,
or
> > + * (at your option) any later version.
> > + *
> > + * You should have received a copy of the GNU General Public
License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
>
> You probably don't want to include this paragraph - their address
keeps
> changing, so will require files to be constantly updated.
Makes sense. Easy to fix.
>
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <asm/mach-types.h>
> > +#include <asm/mach/arch.h>
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/irqs.h>
> > +#include <linux/clkdev.h>
>
> Please group linux/ includes together, then asm/ includes, lastly
mach/
> includes.
>
> > @@ -0,0 +1,113 @@
> > +/* arch/arm/mach-xilinx/common.c
> ...
> > +/**
> > + * system_init - System specific initialization, intended to be
called from
> > + * board specific initialization.
> > + *
> > + **/
> > +void __init system_init(void)
>
> Is there a better name for this - maybe prefixing it with xilinx_ ?
Sure, that's easy.
>
> > +{
> > +#ifdef CONFIG_CACHE_L2X0
> > + /*
> > + * 64KB way size, 8-way associativity, parity disabled
> > + */
> > + l2x0_init(PL310_L2CC_BASE, 0x02060000, 0xF0F0FFFF);
> > +#endif
> > +}
> > +
> > +/**
> > + * irq_init - Interrupt controller initialization for the GIC.
> > + *
> > + **/
> > +void __init irq_init(void)
>
> Ditto.
Same thing, easy.
>
> > +/**
> > + * map_io - Create memory mappings needed for early I/O.
> > + *
> > + **/
> > +void __init map_io(void)
>
> Ditto.
Yep.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* mc13xxx-core, support for i2c, V4
From: Mark Brown @ 2011-02-14 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102141121.34676.philippe.retornaz@epfl.ch>
On Mon, Feb 14, 2011 at 11:21:34AM +0100, Philippe R?tornaz wrote:
> AFAIK the audio part of the mc13783 has still not been merged.
No, it hasn't. Sacha posted something ages ago but it had a lot of
problems and I've not seen any subsequent spins.
^ permalink raw reply
* [PATCH 5/5] arm: mach-mmp: brownstone.c support multiple sd slots
From: Arnd Bergmann @ 2011-02-14 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23C25DE3-86A5-4115-8539-D9837268F63F@marvell.com>
On Monday 14 February 2011, Philip Rakity wrote:
> +
> + gpio_direction_output(poweron, 1);
> + mdelay (20);
> + gpio_direction_output(reset, 0);
> + mdelay (20);
> + gpio_direction_output(reset, 1);
> + gpio_free(reset);
> + gpio_free(poweron);
mdelay is not nice, especially in boot code, because a lot of people
are interested in reducing boot times, and 40 miliseconds is definitely
in the range that people notice.
At the very least, change it from mdelay() to msleep(), to allow other
processes to continue.
Ideally, you can run the function in the background using schedule_work(),
but there may be better ways to do that for the entire platform code.
Arnd
^ permalink raw reply
* [PATCH v10 18/18] OMAP2,3: DSS2: Get DSS IRQ from platform device
From: Tomi Valkeinen @ 2011-02-14 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295850125-21405-19-git-send-email-sumit.semwal@ti.com>
Hi,
On Mon, 2011-01-24 at 11:52 +0530, ext Sumit Semwal wrote:
> From: Senthilvadivu Guruswamy <svadivu@ti.com>
>
> DSS IRQ number can be obtained from platform_get_irq(). This API in turn
> picks the right IRQ number belonging to HW IP from the hwmod database.
> So hardcoding of IRQ number could be removed.
>
> Reviewed-by: Paul Walmsley <paul@pwsan.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
> ---
> drivers/video/omap2/dss/dss.c | 21 ++++++++++++++-------
> 1 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> index 4d7a816..f9390b4 100644
> --- a/drivers/video/omap2/dss/dss.c
> +++ b/drivers/video/omap2/dss/dss.c
> @@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
>
> static int dss_init(bool skip_init)
> {
> - int r;
> + int r, dss_irq;
> u32 rev;
> struct resource *dss_mem;
>
> @@ -609,11 +609,18 @@ static int dss_init(bool skip_init)
> REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
> #endif
>
> - r = request_irq(INT_24XX_DSS_IRQ,
> - cpu_is_omap24xx()
> - ? dss_irq_handler_omap2
> - : dss_irq_handler_omap3,
> - 0, "OMAP DSS", NULL);
> + dss_irq = platform_get_irq(dss.pdev, 0);
> + if (dss_irq < 0) {
> + DSSERR("omap2 dss: platform_get_irq failed\n");
> + r = -ENODEV;
> + goto fail1;
> + }
> +
> + r = request_irq(dss_irq,
> + cpu_is_omap24xx()
> + ? dss_irq_handler_omap2
> + : dss_irq_handler_omap3,
> + 0, "OMAP DSS", NULL);
>
> if (r < 0) {
> DSSERR("omap2 dss: request_irq failed\n");
> @@ -641,7 +648,7 @@ static int dss_init(bool skip_init)
> return 0;
>
> fail2:
> - free_irq(INT_24XX_DSS_IRQ, NULL);
> + free_irq(dss_irq, NULL);
You change this free_irq, as you should, but you missed another a few
lines later.
Archit fixes it in his "OMAP: DSS2: Common IRQ handler for all OMAPs"
patch silently, but I think it should be fixed here already, as the
patches haven't been pulled to anywhere yet.
Perhaps you could use the same method as Archit used, create a new field
"irq" in the dss struct which can be used in the dss_exit's free_irq
call.
Tomi
^ permalink raw reply
* [PATCH 2/4] arm: configs: update mmp2 defconfig for brownstone and SoC Selection
From: Arnd Bergmann @ 2011-02-14 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04A50A49-CBBC-4E5D-B19E-391B4DF77DF3@marvell.com>
On Monday 14 February 2011, Philip Rakity wrote:
> took old mmp2_defconfig --
> did make menuconfig
> changed to CPU_MMP2
> added brownstone as supported board
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
You should not use full .config files as defconfig any more these days.
Please use 'make defconfig' as a final step to create the minimum
list of config symbols. This applies to the other two as well.
Arnd
^ permalink raw reply
* [[PATCH 1/4] arm: mach-mmp: Fix Kconfig to allow correct PXA Selections
From: Arnd Bergmann @ 2011-02-14 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CEFFF7FE-F2F8-47EB-948A-C79301FEB82A@marvell.com>
On Monday 14 February 2011, Philip Rakity wrote:
> The following items are fixed:
>
> a) inconsistent behavior when board is selected and if
> menu item is reselected board has disappeard
>
> b) Ability to select options that will not build
> MMP2 and say PXA168
>
> The behavior maps what is done by the mach-omap
> (thanks to Anrd Bergmann for his help and suggestions)
>
> Mach-MMP is (as now) the sytem type. Once selected
> the user can then select the SoC on the board and
> only the boards that support that SoC are shown.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] omap iommu: print module name on error messages
From: Hiroshi DOYU @ 2011-02-14 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297504949-26233-1-git-send-email-dacohen@gmail.com>
From: ext David Cohen <dacohen@gmail.com>
Subject: [PATCH] omap iommu: print module name on error messages
Date: Sat, 12 Feb 2011 12:02:29 +0200
> OMAP IOMMU generic layer doesn't need ot print function name during
> error messages. Print module name instead which is more useful.
Agree. This makes more sense.
> Signed-off-by: David Cohen <dacohen@gmail.com>
> ---
> arch/arm/plat-omap/iommu.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v4 12/19] ARM: LPAE: Add context switching support
From: Catalin Marinas @ 2011-02-14 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212104400.GF15616@n2100.arm.linux.org.uk>
On Sat, 2011-02-12 at 10:44 +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 05:55:54PM +0000, Catalin Marinas wrote:
> > +#ifdef CONFIG_ARM_LPAE
> > +#define cpu_set_asid(asid) { \
> > + unsigned long ttbl, ttbh; \
> > + asm(" mrrc p15, 0, %0, %1, c2 @ read TTBR0\n" \
> > + " mov %1, %1, lsl #(48 - 32) @ set ASID\n" \
> > + " mcrr p15, 0, %0, %1, c2 @ set TTBR0\n" \
> > + : "=r" (ttbl), "=r" (ttbh) \
> > + : "r" (asid & ~ASID_MASK)); \
>
> This is wrong:
> 1. It does nothing with %2 (the new asid)
> 2. it shifts the high address bits of TTBR0 left 16 places each time its
> called.
It was worse actually, not even compiled in because it had output
arguments but it wasn't volatile. Some early clobber is also needed.
What about this:
#define cpu_set_asid(asid) { \
unsigned long ttbl, ttbh; \
asm volatile( \
" mrrc p15, 0, %0, %1, c2 @ read TTBR0\n" \
" mov %1, %2, lsl #(48 - 32) @ set ASID\n" \
" mcrr p15, 0, %0, %1, c2 @ set TTBR0\n" \
: "=&r" (ttbl), "=&r" (ttbh) \
: "r" (asid & ~ASID_MASK)); \
}
--
Catalin
^ permalink raw reply
* [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
From: Dave Martin @ 2011-02-14 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87pqqy6tdj.fsf@ti.com>
On Fri, Feb 11, 2011 at 03:31:20PM -0800, Kevin Hilman wrote:
> Hi Dave,
>
> Dave Martin <dave.martin@linaro.org> writes:
>
> > This set of patches, along with some other patches under
> > discussion on alkml, should enable omap3 and omap4 kernels to be
> > built with CONFIG_THUMB2_KERNEL.
>
> OK, I tried some more testing with your 'dirty' branch merged with my PM
> branch.
>
> Compiled in ARM mode, everything worked as expected on my 3530/omap3evm,
> including off-mode (in suspend and idle). My 3630 (Zoom3) also can't do
> CORE off due to i583, but MPU, PER etc. all can hit off.
>
> To rebuild in Thumb-2 mode, I disabled OMAP2 support and added Thumb-2
> mode:
>
> CONFIG_ARCH_OMAP2=n
> CONFIG_THUMB2_KERNEL=y
>
> then tested on 3530/omap3evm. Testing suspend/resume to retention
> seemed to work fine. However, enabling retention during idle[1] hung
> someplace (didn't debug further.)
>
> I also tried off-mode, and suspend/resume to off didn't even work.
>
> I didn't have time to debug this any further, so this is just to report
> raw test results.
Thanks, that's a useful step forward anyhow.
A possibility is that the Secure firmware can't cope with
interoperating with Thumb-2 code in the kernel, so that wakeup
entry points the SMC call sites may need to be ARM code.
If you get a moment, if would be interesting to see if this
patch makes a difference ... in the meantime, I'll see if
I can get my hands on an EVM from somewhere.
Cheers
---Dave
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index a204c78..ee1edb1 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -32,6 +32,14 @@
#include "sdrc.h"
#include "control.h"
+#undef ARM
+#undef THUMB
+#undef BSYM
+#define ARM(x...) x
+#define THUMB(x...)
+#define BSYM(x) (x)
+ .arm
+
/*
* Registers access definitions
*/
@@ -289,8 +297,20 @@ clean_l2:
* - should be faster and will change with kernel
* - 'might' have to copy address, load and jump to it
*/
+#ifdef CONFIG_THUMB2_KERNEL
+ /* kernel is non-interworking : must do this from Thumb */
+ adr r1, . + 1
+ bx r1
+ .thumb
+#endif
ldr r1, kernel_flush
blx r1
+#ifdef CONFIG_THUMB2_KERNEL
+ .align
+ bx pc
+ nop
+ .arm
+#endif
omap3_do_wfi:
ldr r4, sdrc_power @ read the SDRC_POWER register
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 829d235..64faab8 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -34,6 +34,14 @@
#include "sdrc.h"
#include "cm2xxx_3xxx.h"
+#undef ARM
+#undef THUMB
+#undef BSYM
+#define ARM(x...) x
+#define THUMB(x...)
+#define BSYM(x) (x)
+ .arm
+
.text
/* r1 parameters */
--
1.7.1
^ permalink raw reply related
* [PATCH v2 09/13] can: pruss CAN driver.
From: Subhasish Ghosh @ 2011-02-14 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D58F77B.9080005@pengutronix.de>
Hello,
The problem with the "all" implementation is that it hogs the ARM/DSP
heavily and that's the reason why we specifically avoided this in our
firmware design.
Hence, implementing this condition spoils the whole purpose of the PRU!!
--------------------------------------------------
From: "Marc Kleine-Budde" <mkl@pengutronix.de>
Sent: Monday, February 14, 2011 3:05 PM
To: "Subhasish Ghosh" <subhasish@mistralsolutions.com>
Cc: "Wolfgang Grandegger" <wg@grandegger.com>; "Kurt Van Dijck"
<kurt.van.dijck@eia.be>; <davinci-linux-open-source@linux.davincidsp.com>;
<linux-arm-kernel@lists.infradead.org>; <m-watkins@ti.com>;
<nsekhar@ti.com>; <sachi@mistralsolutions.com>; "open list:CAN NETWORK
DRIVERS" <socketcan-core@lists.berlios.de>; "open list:CAN NETWORK DRIVERS"
<netdev@vger.kernel.org>; "open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.
Hello,
On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
> That is correct, we receive only pre-programmed CAN ids and "all" or
> "range" implementation is not there in the PRU firmware.
I'd really like to see that you add a "all" implementation to the
firmware. Or even better use the standard id/mask approach.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* [PATCH v4 16/19] ARM: LPAE: Use generic dma_addr_t type definition
From: Catalin Marinas @ 2011-02-14 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212103413.GD15616@n2100.arm.linux.org.uk>
On Sat, 2011-02-12 at 10:34 +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 05:55:58PM +0000, Catalin Marinas wrote:
> > From: Will Deacon <will.deacon@arm.com>
> >
> > This patch uses the types.h implementation in asm-generic to define the
> > dma_addr_t type as the same width as phys_addr_t.
> >
> > NOTE: this is a temporary patch until the corresponding patches unifying
> > the dma_addr_t and removing the dma64_addr_t are merged into mainline.
>
> I'm not too sure about this patch. All of the DMA devices we have only
> take 32-bit addresses for their DMA, so making dma_addr_t 64-bit seems
> wrong as we'll implicitly truncate these addresses.
If we don't enable LPAE, the dma_addr_t is 32-bit, so existing platforms
are not affected. With Cortex-A15, new platforms may have PCIe and be
able to access memory beyond 32-bit (if they don't support >32-bit DMA
at least for some critical devices, I'm not sure why they would use
A15).
For things like hard drives for example, it becomes problematic as pages
are allocated by the VFS layer from highmem and passed to the driver for
DMA. If we keep dma_addr_t to 32-bit you would need to use DMA bounce
even if the PCIe device supports >32-bit physical addresses.
> As ARM platforms don't (sanely) support DMA, I think dropping this patch
> for the time being would be a good idea, and stick with 32-bit dma_addr_t,
> especially as we need to first do a sweep for dma_addr_t usage in device
> driver structures (such as dma engine scatter lists.) These really should
> use __le32/__be32/u32 depending on whether they're little endian, big
> endian or native endian.
Maybe we could make the dma_addr_t size configurable (and disabled by
default) since I expect there'll be platforms capable of >32-bit DMA.
--
Catalin
^ permalink raw reply
* [PATCH 2/2] P2V: Thumb2 support
From: Dave Martin @ 2011-02-14 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102121331220.14920@xanadu.home>
On Sat, Feb 12, 2011 at 6:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> Adding Thumb2 support to the runtime patching of the virt_to_phys and
> phys_to_virt opcodes.
>
> Tested both the 8-bit and the 16-bit fixups, using different placements
> in memory to exercize all code paths.
>
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> ---
> ?arch/arm/Kconfig ? ? ? | ? ?4 ++--
> ?arch/arm/kernel/head.S | ? 48 +++++++++++++++++++++++++++++++++++++++++++++++-
> ?2 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d5eb308..8d5643d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -194,13 +194,13 @@ config VECTORS_BASE
> ?config ARM_PATCH_PHYS_VIRT
> ? ? ? ?bool "Patch physical to virtual translations at runtime (EXPERIMENTAL)"
> ? ? ? ?depends on EXPERIMENTAL
> - ? ? ? depends on !XIP_KERNEL && !THUMB2_KERNEL && MMU
> + ? ? ? depends on !XIP_KERNEL && MMU
> ? ? ? ?depends on !ARCH_REALVIEW || !SPARSEMEM
> ? ? ? ?help
> ? ? ? ? ?Patch phys-to-virt translation functions at runtime according to
> ? ? ? ? ?the position of the kernel in system memory.
>
> - ? ? ? ? This can only be used with non-XIP, non-Thumb2, MMU kernels where
> + ? ? ? ? This can only be used with non-XIP with MMU kernels where
> ? ? ? ? ?the base of physical memory is at a 16MB boundary.
>
> ?config ARM_PATCH_PHYS_VIRT_16BIT
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 8f96ca0..575bb3e 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -475,7 +475,8 @@ __fixup_pv_table:
> ? ? ? ?sub ? ? r3, r0, r3 ? ? ?@ PHYS_OFFSET - PAGE_OFFSET
> ? ? ? ?add ? ? r4, r4, r3 ? ? ?@ adjust table start address
> ? ? ? ?add ? ? r5, r5, r3 ? ? ?@ adjust table end address
> - ? ? ? str ? ? r8, [r7, r3]! ? @ save computed PHYS_OFFSET to __pv_phys_offset
> + ? ? ? add ? ? r7, r7, r3 ? ? ?@ adjust __pv_phys_offset address
> + ? ? ? str ? ? r8, [r7] ? ? ? ?@ save computed PHYS_OFFSET to __pv_phys_offset
> ?#ifndef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> ? ? ? ?mov ? ? r6, r3, lsr #24 @ constant for add/sub instructions
> ? ? ? ?teq ? ? r3, r6, lsl #24 @ must be 16MiB aligned
> @@ -483,6 +484,7 @@ __fixup_pv_table:
> ? ? ? ?mov ? ? r6, r3, lsr #16 @ constant for add/sub instructions
> ? ? ? ?teq ? ? r3, r6, lsl #16 @ must be 64kiB aligned
> ?#endif
> +THUMB( it ? ? ?ne ? ? ? ? ? ? ?@ cross section branch )
> ? ? ? ?bne ? ? __error
> ? ? ? ?str ? ? r6, [r7, #4] ? ?@ save to __pv_offset
> ? ? ? ?b ? ? ? __fixup_a_pv_table
> @@ -496,6 +498,49 @@ ENDPROC(__fixup_pv_table)
>
> ? ? ? ?.text
> ?__fixup_a_pv_table:
> +#ifdef CONFIG_THUMB2_KERNEL
> +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> + ? ? ? lsls ? ?r0, r6, #24
> + ? ? ? lsr ? ? r6, #8
> + ? ? ? beq ? ? 1f
> + ? ? ? clz ? ? r7, r0
> + ? ? ? lsrs ? ?r0, #24
> + ? ? ? lsls ? ?r0, r7
> + ? ? ? bic ? ? r0, 0x0080
> + ? ? ? lsrs ? ?r7, #1
> + ? ? ? orrcs ? r0, #0x0080
> + ? ? ? orr ? ? r0, r0, r7, lsl #12
> +#endif
> +1: ? ? lsls ? ?r6, #24
> + ? ? ? beq ? ? 4f
> + ? ? ? clz ? ? r7, r6
> + ? ? ? lsrs ? ?r6, #24
> + ? ? ? lsls ? ?r6, r7
> + ? ? ? bic ? ? r6, #0x0080
> + ? ? ? lsrs ? ?r7, #1
> + ? ? ? orrcs ? r6, #0x0080
> + ? ? ? orr ? ? r6, r6, r7, lsl #12
> + ? ? ? orr ? ? r6, #0x4000
> + ? ? ? b ? ? ? 4f
We do almost the same, complex, operation twice here ... can it be
factorised with a macro or something? This may also help readability.
Not essential though.
> +2: ? ? add ? ? r7, r3
> +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> + ? ? ? ldrh ? ?ip, [r7]
> + ? ? ? tst ? ? ip, 0x0400 ? ? ?@ the i bit tells us LS or MS byte
Might be helpful to comment that we rely on TST resetting the C flag?
> + ? ? ? beq ? ? 3f
> + ? ? ? cmp ? ? r0, #0 ? ? ? ? ?@ set C flag, and ...
> + ? ? ? biceq ? ip, 0x0400 ? ? ?@ immediate zero value has a special encoding
> + ? ? ? streqh ?ip, [r7] ? ? ? ?@ that requires the i bit cleared
> +#endif
> +3: ? ? ldrh ? ?ip, [r7, #2]
> + ? ? ? and ? ? ip, 0x8f00
> + ? ? ? orrcc ? ip, r6 ?@ mask in offset bits 31-24
> + ? ? ? orrcs ? ip, r0 ?@ mask in offset bits 23-16
> + ? ? ? strh ? ?ip, [r7, #2]
> +4: ? ? cmp ? ? r4, r5
> + ? ? ? ?ldrcc ? r7, [r4], #4 ? @ use branch for delay slot
> + ? ? ? ?bcc ? ?2b
> + ? ? ? ?bx ? ? lr
> +#else
> ?#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> ? ? ? ?and ? ? r0, r6, #255 ? ?@ offset bits 23-16
> ? ? ? ?mov ? ? r6, r6, lsr #8 ?@ offset bits 31-24
> @@ -513,6 +558,7 @@ __fixup_a_pv_table:
> ? ? ? ?ldrcc ? r7, [r4], #4 ? ?@ use branch for delay slot
> ? ? ? ?bcc ? ? 2b
> ? ? ? ?mov ? ? pc, lr
> +#endif
> ?ENDPROC(__fixup_a_pv_table)
>
> ?ENTRY(fixup_pv_table)
> --
> 1.7.4
>
Not sure I entirely all the implications of this code, and I haven't
tested it yet, but it looks sound if I've understood it correctly.
Reviewed-by: Dave Martin <dave.martin@linaro.org>
Cheers
---Dave
^ permalink raw reply
* [PATCH 2/2] P2V: Thumb2 support
From: Dave Martin @ 2011-02-14 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102130841240.14920@xanadu.home>
On Sun, Feb 13, 2011 at 1:56 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sun, 13 Feb 2011, Russell King - ARM Linux wrote:
>
>> On Sat, Feb 12, 2011 at 01:33:42PM -0500, Nicolas Pitre wrote:
>> > ?__fixup_a_pv_table:
>> > +#ifdef CONFIG_THUMB2_KERNEL
>> > +#ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
>> > + ? lsls ? ?r0, r6, #24
>> > + ? lsr ? ? r6, #8
>> > + ? beq ? ? 1f
>> > + ? clz ? ? r7, r0
>> > + ? lsrs ? ?r0, #24
>> > + ? lsls ? ?r0, r7
>>
>> Why do these instructions need to update the PSR?
>
> Strictly speaking they don't. ?It's just a size optimization. ?There is
> a 16-bit encoding for them while their non-PSR-updating counterparts
> have only a 32-bit encoding.
More optimisations are available, but in general I'd advise against
this kind of optimisation for hand-written assembler -- it's unlikely
to help performance and impacts readability.
Using a low register in place of ip would shrink most of the loads and
stores to 16 bits for free though, if a suitable register is available
(r0?).
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 7/7] omap4: dpll: Enable auto gate control for all MX postdividers
From: Rajendra Nayak @ 2011-02-14 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1102121809360.21991@utopia.booyaka.com>
Hi Paul,
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Sunday, February 13, 2011 6:41 AM
> To: Rajendra Nayak
> Cc: linux-omap at vger.kernel.org; b-cousson at ti.com; khilman at ti.com;
santosh.shilimkar at ti.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v2 7/7] omap4: dpll: Enable auto gate control for
all MX postdividers
>
> On Thu, 10 Feb 2011, Rajendra Nayak wrote:
>
> > Enable hardware gate control for all dpll MX and X2 postdividers.
> > This requires the allow_idle/deny_idle functions to be
> > populated for all clock nodes (mx/x2 post dividers) in
> > clkops.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>
> Thanks, queued for 2.6.39 in the 'clk_autoidle_a_2.6.39' branch. Has
the
> OMAP4 clock data autogenerator script been updated?
Yes, the autogen scripts are updated. Will merge the changes
in master.
Regards,
Rajendra
>
>
> - Paul
^ permalink raw reply
* [PATCH 5/5] pxa2xx: drop gpio_vbus field from info struct
From: Dmitry Eremin-Solenikov @ 2011-02-14 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297686800-27599-1-git-send-email-dbaryshkov@gmail.com>
Neither pxa25x_udc, nor pxa27x_udc use gpio_vbus/gpio_vbus_inverted
anymore. Drop those two fields from udc info completely.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/include/asm/mach/udc_pxa2xx.h | 2 --
arch/arm/mach-pxa/corgi.c | 1 -
arch/arm/mach-pxa/devices.c | 1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/mach/udc_pxa2xx.h b/arch/arm/include/asm/mach/udc_pxa2xx.h
index 833306e..ea297ac 100644
--- a/arch/arm/include/asm/mach/udc_pxa2xx.h
+++ b/arch/arm/include/asm/mach/udc_pxa2xx.h
@@ -20,8 +20,6 @@ struct pxa2xx_udc_mach_info {
* VBUS IRQ and omit the methods above. Store the GPIO number
* here. Note that sometimes the signals go through inverters...
*/
- bool gpio_vbus_inverted;
- int gpio_vbus; /* high == vbus present */
bool gpio_pullup_inverted;
int gpio_pullup; /* high == pullup activated */
};
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index a5452a3..002be00 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -462,7 +462,6 @@ static struct pxaficp_platform_data corgi_ficp_platform_data = {
* USB Device Controller
*/
static struct pxa2xx_udc_mach_info udc_info __initdata = {
- .gpio_vbus = -1,
/* no connect GPIO; corgi can't tell connection status */
.gpio_pullup = CORGI_GPIO_USB_PULLUP,
};
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 4c766e3..9e10841 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -90,7 +90,6 @@ void __init pxa_set_mci_info(struct pxamci_platform_data *info)
static struct pxa2xx_udc_mach_info pxa_udc_info = {
.gpio_pullup = -1,
- .gpio_vbus = -1,
};
void __init pxa_set_udc_info(struct pxa2xx_udc_mach_info *info)
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/5] pxa25x_udc: stop handling gpio-vbus internally
From: Dmitry Eremin-Solenikov @ 2011-02-14 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297686800-27599-1-git-send-email-dbaryshkov@gmail.com>
Stop handling gpio-vbus internally. All boards that depended on this
functionality have been converted to use gpio-vbus tranceiver. All
new boards can use it right from the start. Drop unused code.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/usb/gadget/pxa25x_udc.c | 76 ++++-----------------------------------
1 files changed, 7 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
index b37f92c..444b60a 100644
--- a/drivers/usb/gadget/pxa25x_udc.c
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -139,24 +139,6 @@ static const char ep0name [] = "ep0";
static void pxa25x_ep_fifo_flush (struct usb_ep *ep);
static void nuke (struct pxa25x_ep *, int status);
-/* one GPIO should be used to detect VBUS from the host */
-static int is_vbus_present(void)
-{
- struct pxa2xx_udc_mach_info *mach = the_controller->mach;
-
- if (gpio_is_valid(mach->gpio_vbus)) {
- int value = gpio_get_value(mach->gpio_vbus);
-
- if (mach->gpio_vbus_inverted)
- return !value;
- else
- return !!value;
- }
- if (mach->udc_is_connected)
- return mach->udc_is_connected();
- return 1;
-}
-
/* one GPIO should control a D+ pullup, so host sees this device (or not) */
static void pullup_off(void)
{
@@ -1055,7 +1037,7 @@ udc_seq_show(struct seq_file *m, void *_d)
"%s version: %s\nGadget driver: %s\nHost %s\n\n",
driver_name, DRIVER_VERSION SIZE_STR "(pio)",
dev->driver ? dev->driver->driver.name : "(none)",
- is_vbus_present() ? "full speed" : "disconnected");
+ dev->gadget.speed == USB_SPEED_FULL ? "full speed" : "disconnected");
/* registers for device and ep0 */
seq_printf(m,
@@ -1094,7 +1076,7 @@ udc_seq_show(struct seq_file *m, void *_d)
(tmp & UDCCFR_ACM) ? " acm" : "");
}
- if (!is_vbus_present() || !dev->driver)
+ if (dev->gadget.speed != USB_SPEED_FULL || !dev->driver)
goto done;
seq_printf(m, "ep0 IN %lu/%lu, OUT %lu/%lu\nirqs %lu\n\n",
@@ -1435,14 +1417,6 @@ lubbock_vbus_irq(int irq, void *_dev)
#endif
-static irqreturn_t udc_vbus_irq(int irq, void *_dev)
-{
- struct pxa25x_udc *dev = _dev;
-
- pxa25x_udc_vbus_session(&dev->gadget, is_vbus_present());
- return IRQ_HANDLED;
-}
-
/*-------------------------------------------------------------------------*/
@@ -1766,12 +1740,9 @@ pxa25x_udc_irq(int irq, void *_dev)
if (unlikely(udccr & UDCCR_SUSIR)) {
udc_ack_int_UDCCR(UDCCR_SUSIR);
handled = 1;
- DBG(DBG_VERBOSE, "USB suspend%s\n", is_vbus_present()
- ? "" : "+disconnect");
+ DBG(DBG_VERBOSE, "USB suspend\n");
- if (!is_vbus_present())
- stop_activity(dev, dev->driver);
- else if (dev->gadget.speed != USB_SPEED_UNKNOWN
+ if (dev->gadget.speed != USB_SPEED_UNKNOWN
&& dev->driver
&& dev->driver->suspend)
dev->driver->suspend(&dev->gadget);
@@ -1786,8 +1757,7 @@ pxa25x_udc_irq(int irq, void *_dev)
if (dev->gadget.speed != USB_SPEED_UNKNOWN
&& dev->driver
- && dev->driver->resume
- && is_vbus_present())
+ && dev->driver->resume)
dev->driver->resume(&dev->gadget);
}
@@ -2137,7 +2107,7 @@ static struct pxa25x_udc memory = {
static int __init pxa25x_udc_probe(struct platform_device *pdev)
{
struct pxa25x_udc *dev = &memory;
- int retval, vbus_irq, irq;
+ int retval, irq;
u32 chiprev;
/* insist on Intel/ARM/XScale */
@@ -2199,19 +2169,6 @@ static int __init pxa25x_udc_probe(struct platform_device *pdev)
dev->transceiver = otg_get_transceiver();
- if (gpio_is_valid(dev->mach->gpio_vbus)) {
- if ((retval = gpio_request(dev->mach->gpio_vbus,
- "pxa25x_udc GPIO VBUS"))) {
- dev_dbg(&pdev->dev,
- "can't get vbus gpio %d, err: %d\n",
- dev->mach->gpio_vbus, retval);
- goto err_gpio_vbus;
- }
- gpio_direction_input(dev->mach->gpio_vbus);
- vbus_irq = gpio_to_irq(dev->mach->gpio_vbus);
- } else
- vbus_irq = 0;
-
if (gpio_is_valid(dev->mach->gpio_pullup)) {
if ((retval = gpio_request(dev->mach->gpio_pullup,
"pca25x_udc GPIO PULLUP"))) {
@@ -2237,7 +2194,7 @@ static int __init pxa25x_udc_probe(struct platform_device *pdev)
udc_disable(dev);
udc_reinit(dev);
- dev->vbus = !!is_vbus_present();
+ dev->vbus = 0;
/* irq setup after old hardware state is cleaned up */
retval = request_irq(irq, pxa25x_udc_irq,
@@ -2273,22 +2230,10 @@ lubbock_fail0:
}
} else
#endif
- if (vbus_irq) {
- retval = request_irq(vbus_irq, udc_vbus_irq,
- IRQF_DISABLED | IRQF_SAMPLE_RANDOM |
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
- driver_name, dev);
- if (retval != 0) {
- pr_err("%s: can't get irq %i, err %d\n",
- driver_name, vbus_irq, retval);
- goto err_vbus_irq;
- }
- }
create_debug_files(dev);
return 0;
- err_vbus_irq:
#ifdef CONFIG_ARCH_LUBBOCK
free_irq(LUBBOCK_USB_DISC_IRQ, dev);
err_irq_lub:
@@ -2298,9 +2243,6 @@ lubbock_fail0:
if (gpio_is_valid(dev->mach->gpio_pullup))
gpio_free(dev->mach->gpio_pullup);
err_gpio_pullup:
- if (gpio_is_valid(dev->mach->gpio_vbus))
- gpio_free(dev->mach->gpio_vbus);
- err_gpio_vbus:
if (dev->transceiver) {
otg_put_transceiver(dev->transceiver);
dev->transceiver = NULL;
@@ -2337,10 +2279,6 @@ static int __exit pxa25x_udc_remove(struct platform_device *pdev)
free_irq(LUBBOCK_USB_IRQ, dev);
}
#endif
- if (gpio_is_valid(dev->mach->gpio_vbus)) {
- free_irq(gpio_to_irq(dev->mach->gpio_vbus), dev);
- gpio_free(dev->mach->gpio_vbus);
- }
if (gpio_is_valid(dev->mach->gpio_pullup))
gpio_free(dev->mach->gpio_pullup);
--
1.7.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox