RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi Jean, -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Monday, September 06, 2010 9:53 PM To: Sripathy, Vishwanath Cc: Shilimkar, Santosh; Amit Kucheria; Kevin Hilman; linaro-...@lists.linaro.org; linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Sep 6, 2010 at 1:15 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: I did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst case it takes around 3.28ms and best case around 2.93ms for mpu off mode. Can you give a bit more details? Which measurement has been taken (ASM only, sleep, wake-up ...?) and what are the significant figures? Measurement has been done for save (as part of sleep sequence) and restore routine (part of wake up sequence) in assembly code. The above number indicates total time spent in save and restore of ARM context. For MPU INACTIVE/RET, it is less than 30us. Mmh that is the resolution of the 32kHz timer, so I guess you get either 0 or 1 timer cycle depending when you start the measurement. IMO the 32kHz timer is too slow to measure those fast events. Yes I agree. When we use trace events, I believe it would be more accurate as it is based on ARM perf counters. Vishwa However as Kevin mentioned in other email, it would be better to find out a way to trace inside assembly code as well. OK that could be done but first I would like to make sure such a complication is needed. Regards Vishwa Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3 startup memory map
Adding linux-omap to CC On 10 Sep 06, Peter Maydell wrote: Hi. I have a question about what the memory map of the TI OMAP3 (35xx) looks like on startup, which I'm hoping somebody here can answer. (Steve, Richard: you're on the CC: because Loic suggested that you would be good people to ask.) I'm currently looking at a bug in qemu: https://bugs.launchpad.net/qemu-maemo/+bug/628471 where we hang on bootup. That happens because the qemu implementation of NAND attached to the omap GPMC doesn't try to map anything into the memory space (it only does this for NOR devices). From reading the OMAP35xx TRM I believe that when a NAND device is mapped into GPMC space (by setting GPMC_CONFIG7_i appropriately) then reads and writes to any address in the mapped region behave like accesses to GPMC_NAND_DATA_i. I have a patch which implements this mapping for NAND devices; however this causes a conflict about what should be mapped at address zero on startup, because: (a) at reset GPMC_CONFIG7_i is 0xf40 for CS0 and 0xf00 for CS1..7, which maps CS0 to address 0. (On the Beagle board this is NAND.) (b) qemu also wants to map the boot ROM in at address 0 The TRM isn't terribly clear (to me :-)) about what happens at address zero on startup (it talks about a 1MB boot space but doesn't say what this is or what address it is at or when it stops being in effect...) It's also possible that qemu is wrong about mapping boot rom related things at address zero; we are emulating much of what the hardware's boot ROM does rather than actually executing it. However I would expect that there ought to be some real RAM/ROM there for the reset/exception vectors if nothing else... So can anybody tell me what happens on real hardware? -- Peter Maydell -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] ARM: l2x0: Optmise the range based operations
-Original Message-
From: Catalin Marinas [mailto:catalin.mari...@arm.com]
Sent: Monday, September 06, 2010 3:57 PM
To: Shilimkar, Santosh
Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 4/4] ARM: l2x0: Optmise the range based operations
On Sat, 2010-07-31 at 23:16 +0530, Santosh Shilimkar wrote:
For the big buffers which are in excess of cache size, the maintaince
operations by PA are very slow. For such buffers the maintainace
operations can be speeded up by using the WAY based method.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm/mm/cache-l2x0.c | 95 ---
---
1 files changed, 58 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b2938d4..c0d6108 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -116,6 +116,18 @@ static void l2x0_flush_all(void)
spin_unlock_irqrestore(l2x0_lock, flags);
}
+static void l2x0_clean_all(void)
+{
+ unsigned long flags;
+
+ /* clean all ways */
+ spin_lock_irqsave(l2x0_lock, flags);
+ writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_WAY);
+ cache_wait(l2x0_base + L2X0_CLEAN_WAY, l2x0_way_mask);
In case you'll base this on top of my PL310 optimisation, you should use
cache_wait_way() as the cache_wait() becomes a no-op.
Yep. Will fix that while rebasing.
Will post the full series with Thomas's two patches included
on top of your [PATCH 0/9] Various patches for 2.6.37-rc1 which
is already in the linux-next
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tracing, perf: add more power related events
Hi,
Here is a patch proposal for adding new trace events for power management.
Note: thread restarted after the initial discussions on LKML.
Jean
From 6768b88e8133129fa847dd7a95dc6dd17c0662d2 Mon Sep 17 00:00:00 2001
From: Jean Pihet jean.pi...@newoldbits.com
Date: Tue, 7 Sep 2010 09:12:48 +0200
Subject: [PATCH] [PATCH] tracing, perf: add more power related events
This patch adds new generic events for dynamic power management
tracing:
- clock events class: used for clock enable/disable and for
clock rate change,
- power_domain events class: used for power domains transitions.
The OMAP architecture is using the new events for PM debugging, however
the new events are made generic enough to be used by all platforms.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +
arch/arm/mach-omap2/pm34xx.c |4 ++
arch/arm/mach-omap2/powerdomain.c |3 +
arch/arm/plat-omap/clock.c| 13 -
arch/arm/plat-omap/cpu-omap.c |5 ++-
include/trace/events/power.h | 90 +++-
6 files changed, 110 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..6113bd9 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -24,6 +24,7 @@
#include linux/sched.h
#include linux/cpuidle.h
+#include trace/events/power.h
#include plat/prcm.h
#include plat/irqs.h
@@ -130,6 +131,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
local_fiq_disable();
+ trace_power_start(POWER_CSTATE, cx-type, smp_processor_id());
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f25bc3d..7bf8a87 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/delay.h
#include linux/slab.h
+#include trace/events/power.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -588,6 +589,7 @@ static void omap3_pm_idle(void)
if (omap_irq_pending() || need_resched())
goto out;
+ trace_power_start(POWER_CSTATE, 1, smp_processor_id());
omap_sram_idle();
out:
@@ -628,6 +630,8 @@ static int omap3_pm_suspend(void)
omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
wakeup_timer_milliseconds);
+ trace_power_start(POWER_SSTATE, 1, smp_processor_id());
+
/* Read current next_pwrsts */
list_for_each_entry(pwrst, pwrst_list, node)
pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 6527ec3..73cbe9a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -23,6 +23,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include trace/events/power.h
#include asm/atomic.h
@@ -440,6 +441,8 @@ int pwrdm_set_next_pwrst(struct powerdomain
*pwrdm, u8 pwrst)
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
+ trace_power_domain_target(pwrdm-name, pwrst, smp_processor_id());
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
(pwrst OMAP_POWERSTATE_SHIFT),
pwrdm-prcm_offs, pwrstctrl_reg_offs);
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 7190cbd..d6518f5 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -21,6 +21,7 @@
#include linux/cpufreq.h
#include linux/debugfs.h
#include linux/io.h
+#include trace/events/power.h
#include plat/clock.h
@@ -43,8 +44,10 @@ int clk_enable(struct clk *clk)
return -EINVAL;
spin_lock_irqsave(clockfw_lock, flags);
- if (arch_clock-clk_enable)
+ if (arch_clock-clk_enable) {
+ trace_clock_enable(clk-name, 1, smp_processor_id());
ret = arch_clock-clk_enable(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
@@ -66,8 +69,10 @@ void clk_disable(struct clk *clk)
goto out;
}
- if (arch_clock-clk_disable)
+ if (arch_clock-clk_disable) {
+ trace_clock_disable(clk-name, 0, smp_processor_id());
arch_clock-clk_disable(clk);
+ }
out:
spin_unlock_irqrestore(clockfw_lock, flags);
@@ -120,8 +125,10 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
return ret;
spin_lock_irqsave(clockfw_lock, flags);
- if (arch_clock-clk_set_rate)
+ if (arch_clock-clk_set_rate) {
+ trace_clock_set_rate(clk-name, rate, smp_processor_id());
ret = arch_clock-clk_set_rate(clk, rate);
+ }
if
[PATCH 6/6] ARM: l2x0: Optimise the range based operations
For the big buffers which are in excess of cache size, the maintaince
operations by PA are very slow. For such buffers the maintainace
operations can be speeded up by using the WAY based method.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Catalin Marinas catalin.mari...@arm.com
---
arch/arm/mm/cache-l2x0.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 87b487e..143a39f 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -125,6 +125,18 @@ static void l2x0_flush_all(void)
spin_unlock_irqrestore(l2x0_lock, flags);
}
+static void l2x0_clean_all(void)
+{
+ unsigned long flags;
+
+ /* clean all ways */
+ spin_lock_irqsave(l2x0_lock, flags);
+ writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_WAY);
+ cache_wait_way(l2x0_base + L2X0_CLEAN_WAY, l2x0_way_mask);
+ cache_sync();
+ spin_unlock_irqrestore(l2x0_lock, flags);
+}
+
static void l2x0_inv_all(void)
{
unsigned long flags;
@@ -183,6 +195,11 @@ static void l2x0_clean_range(unsigned long start, unsigned
long end)
void __iomem *base = l2x0_base;
unsigned long flags;
+ if ((end - start) = l2x0_size) {
+ l2x0_clean_all();
+ return;
+ }
+
spin_lock_irqsave(l2x0_lock, flags);
start = ~(CACHE_LINE_SIZE - 1);
while (start end) {
@@ -208,6 +225,11 @@ static void l2x0_flush_range(unsigned long start, unsigned
long end)
void __iomem *base = l2x0_base;
unsigned long flags;
+ if ((end - start) = l2x0_size) {
+ l2x0_flush_all();
+ return;
+ }
+
spin_lock_irqsave(l2x0_lock, flags);
start = ~(CACHE_LINE_SIZE - 1);
while (start end) {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] arm: Disable outer (L2) cache in kexec
From: Thomas Gleixner [t...@linutronix.de]
kexec does not disable the outer cache before disabling the inner
caches in cpu_proc_fin(). So L2 is enabled across the kexec jump. When
the new kernel enables chaches again, it randomly crashes.
Disabling L2 before calling cpu_proc_fin() cures the problem.
Disabling L2 requires the following new functions: flush_all(),
inv_all() and disable(). Add them to outer_cache_fns and call them
from the kexec code.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Acked-by: Catalin Marinas catalin.mari...@arm.com
---
arch/arm/include/asm/outercache.h | 24
arch/arm/kernel/machine_kexec.c |3 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 25f76ba..fc19009 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -25,6 +25,9 @@ struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
void (*flush_range)(unsigned long, unsigned long);
+ void (*flush_all)(void);
+ void (*inv_all)(void);
+ void (*disable)(void);
#ifdef CONFIG_OUTER_CACHE_SYNC
void (*sync)(void);
#endif
@@ -50,6 +53,24 @@ static inline void outer_flush_range(unsigned long start,
unsigned long end)
outer_cache.flush_range(start, end);
}
+static inline void outer_flush_all(void)
+{
+ if (outer_cache.flush_all)
+ outer_cache.flush_all();
+}
+
+static inline void outer_inv_all(void)
+{
+ if (outer_cache.inv_all)
+ outer_cache.inv_all();
+}
+
+static inline void outer_disable(void)
+{
+ if (outer_cache.disable)
+ outer_cache.disable();
+}
+
#else
static inline void outer_inv_range(unsigned long start, unsigned long end)
@@ -58,6 +79,9 @@ static inline void outer_clean_range(unsigned long start,
unsigned long end)
{ }
static inline void outer_flush_range(unsigned long start, unsigned long end)
{ }
+static inline void outer_flush_all(void) { }
+static inline void outer_inv_all(void) { }
+static inline void outer_disable(void) { }
#endif
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 1fc74cb..3a8fd51 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -78,7 +78,10 @@ void machine_kexec(struct kimage *image)
local_fiq_disable();
setup_mm_for_reboot(0); /* mode is not used, so just pass 0*/
flush_cache_all();
+ outer_flush_all();
+ outer_disable();
cpu_proc_fin();
+ outer_inv_all();
flush_cache_all();
cpu_reset(reboot_code_buffer_phys);
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: l2x0: Determine the cache size
The cache size is needed for to optimise range based
maintainance operations
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Catalin Marinas catalin.mari...@arm.com
---
arch/arm/include/asm/hardware/cache-l2x0.h |1 +
arch/arm/mm/cache-l2x0.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h
b/arch/arm/include/asm/hardware/cache-l2x0.h
index d833355..4633d2a 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -55,6 +55,7 @@
#define L2X0_CACHE_ID_PART_MASK(0xf 6)
#define L2X0_CACHE_ID_PART_L210(1 6)
#define L2X0_CACHE_ID_PART_L310(3 6)
+#define L2X0_AUX_CTRL_WAY_SIZE_MASK(0x3 17)
#ifndef __ASSEMBLY__
extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32
aux_mask);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 9310d61..87b487e 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -28,6 +28,7 @@
static void __iomem *l2x0_base;
static DEFINE_SPINLOCK(l2x0_lock);
static uint32_t l2x0_way_mask; /* Bitmask of active ways */
+static uint32_t l2x0_size;
static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
{
@@ -242,6 +243,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
{
__u32 aux;
__u32 cache_id;
+ __u32 way_size = 0;
int ways;
const char *type;
@@ -276,6 +278,13 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
l2x0_way_mask = (1 ways) - 1;
/*
+* L2 cache Size = Way size * Number of ways
+*/
+ way_size = (aux L2X0_AUX_CTRL_WAY_SIZE_MASK) 17;
+ way_size = 1 (way_size + 3);
+ l2x0_size = ways * way_size;
+
+ /*
* Check if l2x0 controller is already enabled.
* If you are booting from non-secure mode
* accessing the below registers will fault.
@@ -300,6 +309,6 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
outer_cache.disable = l2x0_disable;
printk(KERN_INFO %s cache controller enabled\n, type);
- printk(KERN_INFO l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n,
-ways, cache_id, aux);
+ printk(KERN_INFO l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x,
Cache size: %d KB\n,
+ ways, cache_id, aux, l2x0_size);
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: l2x0: Fix coding-style in the cache-l2x0.h
Replace tab with space after #define to be consisten with other define in the file. Also move the bit mask below the register offsets. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Catalin Marinas catalin.mari...@arm.com --- arch/arm/include/asm/hardware/cache-l2x0.h |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h index 6bcba48..d833355 100644 --- a/arch/arm/include/asm/hardware/cache-l2x0.h +++ b/arch/arm/include/asm/hardware/cache-l2x0.h @@ -21,9 +21,6 @@ #define __ASM_ARM_HARDWARE_L2X0_H #define L2X0_CACHE_ID 0x000 -#define L2X0_CACHE_ID_PART_MASK (0xf 6) -#define L2X0_CACHE_ID_PART_L210 (1 6) -#define L2X0_CACHE_ID_PART_L310 (3 6) #define L2X0_CACHE_TYPE0x004 #define L2X0_CTRL 0x100 #define L2X0_AUX_CTRL 0x104 @@ -54,6 +51,11 @@ #define L2X0_LINE_TAG 0xF30 #define L2X0_DEBUG_CTRL0xF40 +/* Registers shifts and masks */ +#define L2X0_CACHE_ID_PART_MASK(0xf 6) +#define L2X0_CACHE_ID_PART_L210(1 6) +#define L2X0_CACHE_ID_PART_L310(3 6) + #ifndef __ASSEMBLY__ extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask); #endif -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] omap4: l2x0: Override the default l2x0_disable
The machine_kexec() calls outer_disable which can crash on OMAP4
becasue of trustzone restrictions.
This patch overrides the default l2x0_disable with a OMAP4
specific implementation taking care of trustzone
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap4-common.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 13dc979..b557cc2 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -44,6 +44,13 @@ void __init gic_init_irq(void)
}
#ifdef CONFIG_CACHE_L2X0
+
+static void omap4_l2x0_disable(void)
+{
+ /* Disable PL310 L2 Cache controller */
+ omap_smc1(0x102, 0x0);
+}
+
static int __init omap_l2_cache_init(void)
{
/*
@@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
*/
l2x0_init(l2cache_base, 0x0e05, 0xcfff);
+ /*
+* Override default outer_cache.disable with a OMAP4
+* specific one
+ */
+ outer_cache.disable = omap4_l2x0_disable;
+
return 0;
}
early_initcall(omap_l2_cache_init);
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] arm: Implement l2x0 cache disable functions
From: Thomas Gleixner [t...@linutronix.de]
Add flush_all, inv_all and disable functions to the l2x0 code. These
functions are called from kexec code to prevent random crashes in the
new kernel.
Platforms like OMAP which control L2 enable/disable via SMI mode can
override the outer_cache.disable() function to implement their own.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Acked-by: Catalin Marinas catalin.mari...@arm.com
---
arch/arm/mm/cache-l2x0.c | 28 +++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index edb43ff..9310d61 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -112,12 +112,26 @@ static void l2x0_cache_sync(void)
spin_unlock_irqrestore(l2x0_lock, flags);
}
-static inline void l2x0_inv_all(void)
+static void l2x0_flush_all(void)
+{
+ unsigned long flags;
+
+ /* clean all ways */
+ spin_lock_irqsave(l2x0_lock, flags);
+ writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
+ cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
+ cache_sync();
+ spin_unlock_irqrestore(l2x0_lock, flags);
+}
+
+static void l2x0_inv_all(void)
{
unsigned long flags;
/* invalidate all ways */
spin_lock_irqsave(l2x0_lock, flags);
+ /* Invalidating when L2 is enabled is a nono */
+ BUG_ON(readl(l2x0_base + L2X0_CTRL) 1);
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_INV_WAY);
cache_wait_way(l2x0_base + L2X0_INV_WAY, l2x0_way_mask);
cache_sync();
@@ -215,6 +229,15 @@ static void l2x0_flush_range(unsigned long start, unsigned
long end)
spin_unlock_irqrestore(l2x0_lock, flags);
}
+static void l2x0_disable(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(l2x0_lock, flags);
+ writel(0, l2x0_base + L2X0_CTRL);
+ spin_unlock_irqrestore(l2x0_lock, flags);
+}
+
void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
{
__u32 aux;
@@ -272,6 +295,9 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val,
__u32 aux_mask)
outer_cache.clean_range = l2x0_clean_range;
outer_cache.flush_range = l2x0_flush_range;
outer_cache.sync = l2x0_cache_sync;
+ outer_cache.flush_all = l2x0_flush_all;
+ outer_cache.inv_all = l2x0_inv_all;
+ outer_cache.disable = l2x0_disable;
printk(KERN_INFO %s cache controller enabled\n, type);
printk(KERN_INFO l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n,
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
This series is just repost adding Catalin's ack to the patches and combining Thomas's two rebased kexec patches. It's generated against the mainline 2.6.36-rc3 + Catalin's [PATCH 0/9] Various patches for 2.6.37-rc1 series. Santosh Shilimkar (4): omap4: l2x0: Override the default l2x0_disable ARM: l2x0: Fix coding-style in the cache-l2x0.h ARM: l2x0: Determine the cache size ARM: l2x0: Optimise the range based operations Thomas Gleixner (2): arm: Disable outer (L2) cache in kexec arm: Implement l2x0 cache disable functions arch/arm/include/asm/hardware/cache-l2x0.h |9 +++- arch/arm/include/asm/outercache.h | 24 +++ arch/arm/kernel/machine_kexec.c|3 + arch/arm/mach-omap2/omap4-common.c | 13 ++ arch/arm/mm/cache-l2x0.c | 63 ++- 5 files changed, 106 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tracing, perf: add more power related events
Here is some more information about the patch: Initial discussion on LKML: cf. http://marc.info/?l=linux-kernelm=128195697205096w=4, PM debug and profiling wiki page with rationale, todo, patches, tools screenshots ...: http://omappedia.org/wiki/Power_Management_Debug_and_Profiling On Tue, Sep 7, 2010 at 9:21 AM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi, Here is a patch proposal for adding new trace events for power management. Note: thread restarted after the initial discussions on LKML. Sorry the thread did not get restarted because I am using the same e-mail subject. Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4
Hi Tomi, Can you please comment on the below patch series? Thanks and regards, Mythri. -Original Message- From: K, Mythri P Sent: Monday, August 23, 2010 2:48 PM To: linux-omap@vger.kernel.org Cc: tomi.valkei...@nokia.com; K, Mythri P Subject: [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4 From: Mythri P K mythr...@ti.com This patch is a outline of how the HDMI support is added to OMAP4. HDMI is a driver that is similar to the VENC or the DSI driver to support HDMI/DVI sink device. The current Design adheres to the DSS2 Architecture. It is split into the HDMI DSS driver and HDMI panel Driver. HDMI DSS driver Located in drivers/video/omap2/dss/hdmi.c is responsible for OMAP related configuration such as listening to the DSS_HDMI irq which signals changes such as Hot-plug detect , Physical attach/detach. This driver is responsible to calculate the PLL values based on the TV resolution that is selected. Yet another functionality is to call necessary configuration for the Mux/GPIO settings. HDMI Panel Driver is located in drivers/video/omap2/displays/hdmi_omap4_panel.c. This is a panel driver which acts as the HDMI source and is responsible for all the configuration of the HDMI, based on the parameters read from the EDID of the sink device. It registers hdmi driver to the omap_dss bus and calls the functionality of the HDMI DSS driver. This driver is responsible for configuration of the HDMI IP, which are: 1. Configuration of the PHY registers. 2. Configuration of the PLL registers and setting of the TMDS clock. 3. Configuration of the DDC to read the EDID data when available. 4. Configuration of the core reigsters to set: a. set the video registers to the timing and format that is selected. b. set the audio reigsters based on the EDID value read and user selected parameters. c. Set the AVI info frame reigsters to configure the auxilary info frame which are repeated. It is also provides the interface for users 1.To read the EDID contents and also confiure the timings based on EDID. 2.To configure AVI Inforframe Based on the the EDID(sink capability). Mythri P K (2): OMAP:DSS:Patch to add support for HDMI as panel driver OMAP:DSS:Patch to add HDMI DSS driver support drivers/video/omap2/displays/hdmi_omap4_panel.c | 1443 +++ drivers/video/omap2/displays/hdmi_omap4_panel.h | 672 +++ drivers/video/omap2/dss/hdmi.c | 292 + 3 files changed, 2407 insertions(+), 0 deletions(-) create mode 100644 drivers/video/omap2/displays/hdmi_omap4_panel.c create mode 100644 drivers/video/omap2/displays/hdmi_omap4_panel.h create mode 100644 drivers/video/omap2/dss/hdmi.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
Hi,
On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
Would a more static approach be cleaner? I mean something like this
(pseudo code):
static struct omap_dss_features omap3_dss_features = {
/* array of register definitions */
.registers = {
{
.register = FIRHINC,
.high = 12,
.low = 0,
},
{
.register = FIRVINC,
.high = 28,
.low = 16,
},
...
},
/* array of feature ids */
.features = {
GLOBAL_ALPHA,
GLOBAL_ALPHA_VIDEO1,
...
},
};
And then the code would select the omapX_dss_features struct to use
depending on the omap version.
Also, the feature/register defines should have some prefix, and perhaps
they could be inside an enum?
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
Hi,
On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
And some more comments inline
---
drivers/video/omap2/dss/dss_features.c | 197
drivers/video/omap2/dss/dss_features.h | 48
2 files changed, 245 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/dss_features.c
create mode 100644 drivers/video/omap2/dss/dss_features.h
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
new file mode 100644
index 000..0ac18d2
--- /dev/null
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -0,0 +1,197 @@
+/*
+ * linux/drivers/video/omap2/dss/dss_features.c
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Archit Taneja arc...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/display.h
+#include plat/cpu.h
+
+#include dss_features.h
+
+static struct list_head reg_field_list;
+static int num_reg_fields;
+
+/* Defines a generic omap register field */
+struct dss_reg_field {
+ struct list_head list;
+ int id;
+ u8 start, end;
+};
+
+/* This struct is divided into 2 sets: the first gives a value corresponding
+ * to a feature, the second tells if a dss feature exists or not */
+static struct
+{
+ int num_mgrs;
+ int num_ovls;
+ enum omap_display_type supported_displays[MAX_DSS_MANAGERS];
+ enum omap_color_mode supported_color_modes[MAX_DSS_OVERLAYS];
+
+ bool has_feature[MAX_DSS_FEATURES];
+} omap_dss_features;
+
+/* Functions to add/fetch the start and end bits of a DSS register field */
+static void dss_add_reg_field(int id, u8 start, u8 end)
+{
+ struct dss_reg_field *field;
+ field = kzalloc(sizeof(*field), GFP_KERNEL);
+
+ ++num_reg_fields;
+
+ field-id = id;
+ field-start = start;
+ field-end = end;
+
+ list_add_tail(field-list, reg_field_list);
+}
+
+void omap_dss_get_reg_field(int id, u8 *start, u8 *end)
+{
+ struct dss_reg_field *field;
+
+ list_for_each_entry(field, reg_field_list, list) {
+ if (field-id == id) {
+ *start = field-start;
+ *end = field-end;
+ return;
+ }
+ }
+ BUG();
+}
+EXPORT_SYMBOL(omap_dss_get_reg_field);
I don't think these need to be exported. The only users for these should
be inside DSS driver. And, as you've probably noticed, I've been using
(usually) omap_dss_* prefix for exported functions, and (usually) dss_*
prefix for non-exported, non-static functions.
Although the naming convention inside DSS is sadly quite inconsistent...
=)
+/* Functions returning values related to a DSS feature */
+int omap_dss_num_mgrs(void)
+{
+ return omap_dss_features.num_mgrs;
+}
+EXPORT_SYMBOL(omap_dss_num_mgrs);
Perhaps this should be dss_get_num_mgrs().
+
+int omap_dss_num_ovls(void)
+{
+ return omap_dss_features.num_ovls;
+}
+EXPORT_SYMBOL(omap_dss_num_ovls);
And get here too. And for the functions below.
+enum omap_display_type omap_dss_supported_displays(int id)
+{
+ return omap_dss_features.supported_displays[id];
+}
+EXPORT_SYMBOL(omap_dss_supported_displays);
+
+enum omap_color_mode omap_dss_supported_color_modes(int id)
+{
+ return omap_dss_features.supported_color_modes[id];
+}
+EXPORT_SYMBOL(omap_dss_supported_color_modes);
+
+/* DSS has_feature check */
+bool omap_dss_has_feature(int id)
+{
+ return omap_dss_features.has_feature[id];
+}
+EXPORT_SYMBOL(omap_dss_has_feature);
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4
Hi, On Thu, 2010-08-26 at 07:16 +0200, ext K, Mythri P wrote: From: Mythri P K mythr...@ti.com This patch is a outline of how the HDMI support is added to OMAP4. Please run checkpatch.pl for the patches before you send them. Checkpatch reported over 300 errors. HDMI is a driver that is similar to the VENC or the DSI driver to support HDMI/DVI sink device. When I made the VENC driver, I put both the core VENC and the venc panel into the same file, inside dss driver. The reason was that VENC is part of OMAP DSS, and not an external panel. I've been thinking about this a few times, but so far I haven't changed it. Did you have some reason to put the HDMI panel driver into displays/? The current Design adheres to the DSS2 Architecture. It is split into the HDMI DSS driver and HDMI panel Driver. HDMI DSS driver Located in drivers/video/omap2/dss/hdmi.c is responsible for OMAP related configuration such as listening to the DSS_HDMI irq which signals changes such as Hot-plug detect , Physical attach/detach. This driver is responsible to calculate the PLL values based on the TV resolution that is selected. Yet another functionality is to call necessary configuration for the Mux/GPIO settings. Why does HDMI need mux/GPIO changes? HDMI Panel Driver is located in drivers/video/omap2/displays/hdmi_omap4_panel.c. This is a panel driver which acts as the HDMI source and is responsible for all the configuration of the HDMI, based on the parameters read from the EDID of the sink device. It registers hdmi driver to the omap_dss bus and calls the functionality of the HDMI DSS driver. This driver is responsible for configuration of the HDMI IP, which are: 1. Configuration of the PHY registers. 2. Configuration of the PLL registers and setting of the TMDS clock. 3. Configuration of the DDC to read the EDID data when available. 4. Configuration of the core reigsters to set: a. set the video registers to the timing and format that is selected. b. set the audio reigsters based on the EDID value read and user selected parameters. c. Set the AVI info frame reigsters to configure the auxilary info frame which are repeated. It is also provides the interface for users 1.To read the EDID contents and also confiure the timings based on EDID. 2.To configure AVI Inforframe Based on the the EDID(sink capability). Mythri P K (2): OMAP:DSS:Patch to add support for HDMI as panel driver OMAP:DSS:Patch to add HDMI DSS driver support drivers/video/omap2/displays/hdmi_omap4_panel.c | 1443 +++ drivers/video/omap2/displays/hdmi_omap4_panel.h | 672 +++ drivers/video/omap2/dss/hdmi.c | 292 + 3 files changed, 2407 insertions(+), 0 deletions(-) create mode 100644 drivers/video/omap2/displays/hdmi_omap4_panel.c create mode 100644 drivers/video/omap2/displays/hdmi_omap4_panel.h create mode 100644 drivers/video/omap2/dss/hdmi.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
Hi,
Tomi Valkeinen wrote:
Hi,
On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
And some more comments inline
---
drivers/video/omap2/dss/dss_features.c | 197
drivers/video/omap2/dss/dss_features.h | 48
2 files changed, 245 insertions(+), 0 deletions(-) create mode
100644 drivers/video/omap2/dss/dss_features.c
create mode 100644 drivers/video/omap2/dss/dss_features.h
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
new file mode 100644
index 000..0ac18d2
--- /dev/null
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -0,0 +1,197 @@
+/*
+ * linux/drivers/video/omap2/dss/dss_features.c
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Archit Taneja arc...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or +modify it
+ * under the terms of the GNU General Public License version 2 as
+published by + * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, +but
WITHOUT + * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY +or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public +License for + * more details.
+ *
+ * You should have received a copy of the GNU General Public License +along
with + * this program. If not, see http://www.gnu.org/licenses/. + */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/display.h
+#include plat/cpu.h
+
+#include dss_features.h
+
+static struct list_head reg_field_list; static int num_reg_fields; +
+/* Defines a generic omap register field */ struct dss_reg_field { +
struct
list_head list; +int id;
+u8 start, end;
+};
+
+/* This struct is divided into 2 sets: the first gives a value
+corresponding + * to a feature, the second tells if a dss feature exists or
not */ +static struct { +int num_mgrs;
+int num_ovls;
+enum omap_display_type supported_displays[MAX_DSS_MANAGERS];
+enum omap_color_mode supported_color_modes[MAX_DSS_OVERLAYS]; +
+bool has_feature[MAX_DSS_FEATURES];
+} omap_dss_features;
+
+/* Functions to add/fetch the start and end bits of a DSS register
+field */ static void dss_add_reg_field(int id, u8 start, u8 end) {
+struct dss_reg_field *field;
+field = kzalloc(sizeof(*field), GFP_KERNEL);
+
+++num_reg_fields;
+
+field-id = id;
+field-start = start;
+field-end = end;
+
+list_add_tail(field-list, reg_field_list); }
+
+void omap_dss_get_reg_field(int id, u8 *start, u8 *end) {
+struct dss_reg_field *field;
+
+list_for_each_entry(field, reg_field_list, list) { + if
(field-id ==
id) { + *start = field-start;
+*end = field-end;
+return;
+}
+}
+BUG();
+}
+EXPORT_SYMBOL(omap_dss_get_reg_field);
I don't think these need to be exported. The only users for
these should be inside DSS driver. And, as you've probably noticed, I've been
using (usually) omap_dss_* prefix for exported functions, and
(usually) dss_* prefix for non-exported, non-static functions.
Although the naming convention inside DSS is sadly quite inconsistent...
=)
Yes, exporting them is unnecessary, I will correct this.
There are 2 functions in the present code:
omap_dss_get_num_overlays()
omap_dss_get_num_overlay_managers()
They look very similar to the dss_feature functions but are required.
I will need to come up with new names for them to avoid confusion.
We could probably give a naming like : dss_feat_get_num_mgrs() etc so
that it doesn't confuse things.
Archit
+/* Functions returning values related to a DSS feature */ int
+omap_dss_num_mgrs(void) { + return omap_dss_features.num_mgrs;
+}
+EXPORT_SYMBOL(omap_dss_num_mgrs);
Perhaps this should be dss_get_num_mgrs().
+
+int omap_dss_num_ovls(void)
+{
+return omap_dss_features.num_ovls;
+}
+EXPORT_SYMBOL(omap_dss_num_ovls);
And get here too. And for the functions below.
+enum omap_display_type omap_dss_supported_displays(int id) {
+return omap_dss_features.supported_displays[id];
+}
+EXPORT_SYMBOL(omap_dss_supported_displays);
+
+enum omap_color_mode omap_dss_supported_color_modes(int id) {
+return omap_dss_features.supported_color_modes[id]; +}
+EXPORT_SYMBOL(omap_dss_supported_color_modes);
+
+/* DSS has_feature check */
+bool omap_dss_has_feature(int id)
+{
+return omap_dss_features.has_feature[id];
+}
+EXPORT_SYMBOL(omap_dss_has_feature);
Tomi--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
On Tue, 2010-09-07 at 13:05 +0200, ext Taneja, Archit wrote: Hi, There are 2 functions in the present code: omap_dss_get_num_overlays() omap_dss_get_num_overlay_managers() They look very similar to the dss_feature functions but are required. I will need to come up with new names for them to avoid confusion. We could probably give a naming like : dss_feat_get_num_mgrs() etc so that it doesn't confuse things. Yes, that sounds good. And the defines/enums could be FEAT_xxx, perhaps? They are DSS internal defines anyway, so DSS_FEAT_xxx may not be needed, but it's good to have some common prefix. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
Hi,
Tomi Valkeinen wrote:
Hi,
On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
Would a more static approach be cleaner? I mean something like this (pseudo
code):
static struct omap_dss_features omap3_dss_features = {
/* array of register definitions */
.registers = {
{
.register = FIRHINC,
.high = 12,
.low = 0,
},
{
.register = FIRVINC,
.high = 28,
.low = 16,
},
...
},
/* array of feature ids */
.features = {
GLOBAL_ALPHA,
GLOBAL_ALPHA_VIDEO1,
...
},
};
And then the code would select the omapX_dss_features struct
to use depending on the omap version.
It looks way cleaner out here , not sure though what it would look
like once the whole file is filled up :)
One issue with having separate omapX_dss_features is something which might may
come later on : If there is a feature/value which is same in omap2 and omap3
but different in omap4, we will sill need to fill up all the structs completely.
We can get around this by filling one single struct on runtime :
all omap2 specific features filled up here
{
...
...
}
all common between omap2 and omap3 filled up here
{
...
...
}
all omap3 specific filled up here
{
...
...
}
And so on..
This will save up space, but won't give a very clean look ..
I think by the time all omap4(and 3630) features are added and remaining
omap2,3 checks are removed we will have atleast 20 or so register fields
and a dozen features. Initializing them statically for all omaps(including
the ES_REV's) will really stretch up the file. But it will still look clean :)
What's your call on this?
Archit
Also, the feature/register defines should have some prefix,
and perhaps they could be inside an enum?
Yes we can do this, I'll see while reworking what looks better(enum vs defines)
Archit
Tomi--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3: regulator_get() failure in ads7846
Hi all, While booting the latest kernel (from linux-omap) on omap3evm, I came across this error. [3.202575] ads7846 spi1.0: unable to get regulator: -19 [3.208190] [ cut here ] [3.212890] WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x114/0x140() [3.219940] Modules linked in: [3.223083] [c004e57c] (unwind_backtrace+0x0/0xec) from [c007e5d8] (warn_slowpath_common+0x4c/0x64) ... ... [3.342529] ---[ end trace 1b75b31a2719ed1f ]--- In drivers/input/touchscreen/ads7846.c, we attempt to get the regulator as: ts-reg = regulator_get(spi-dev, vcc); This regulator isn't defined for omap3evm. And I suspect - once defined - the name will be different than vcc. Looking at pointers on how this should be handled. Best regard, Sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver
-Original Message- From: Cousson, Benoit Sent: Friday, September 03, 2010 10:10 PM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; Kevin Hilman; Shilimkar, Santosh; Sawant, Anand Subject: Re: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver Hi Manjunath, On 9/3/2010 6:21 PM, G, Manjunath Kondaiah wrote: Kevin, If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? I just have few minor comments: Could you please keep the original credit for this patch: OMAP4: DMA: HWMOD: Add hwmod data structures You can change as well the subject as suggested by Kevin for all the hwmod data patches with: OMAPX: hwmod data: Add system DMA And quoting Kevin again hwmod should not be capitalized, as it's not an acronym. Ok. - Manjunath [...] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 04, 2010 2:09 AM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh Subject: Re: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver Manjunatha GK manj...@ti.com writes: This patch series has review comments incorporated which are received for v1 version. The review comments can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html These changes are tested on following boards: - Zoom3 (OMAP3630) - Beagle(OMAP3530) - OMAP4 SDP (OMAP4430) I don't have omap1 and omap2 boards and appreciate if some one can test these boards and provides feedback. Build tested for both omap1 and omap2 plus boards. Your team now has OMAP2 hardware, please test on OMAP2 as well as you're making significant changes that affect code in OMAP2, 3 and 4. Let me check omap2 board boot status. If it is working, I can test next version of patches on omap2 also. -Manjunath Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 10/11] OMAP: DMA: Use DMA device attributes
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 04, 2010 2:16 AM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh Subject: Re: [PATCH v2 10/11] OMAP: DMA: Use DMA device attributes Manjunatha GK manj...@ti.com writes: Existing DMA API's are using cpu_is_ checks for differenciating omap1 and omap2plus code. This patch replaces cpu_is_ checks with DMA device attributes and also moves API's which are OMAP1 and OMAP2plus specific into respective mach-omap dma driver files. Signed-off-by: Manjunatha GK manj...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com [...] int omap_request_dma(int dev_id, const char *dev_name, void (*callback)(int lch, u16 ch_status, void *data), void *data, int *dma_ch_out) @@ -754,14 +459,12 @@ int omap_request_dma(int dev_id, const char *dev_name, chan = dma_chan + free_ch; chan-dev_id = dev_id; - pm_runtime_get_sync(ddev-dev); - - if (cpu_class_is_omap1()) - clear_lch_regs(free_ch); - - if (cpu_class_is_omap2()) + if (p-clear_lch_regs) + p-clear_lch_regs(free_ch); + else omap_clear_dma(free_ch); You access HW registers here. + pm_runtime_get_sync(ddev-dev); But don't actually enable HW until here. IOW, you need to have the 'get' before you access the HW. Thanks for pointing out this. I will take care of it. -Manjunath-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 04, 2010 2:30 AM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device
registration
Manjunatha GK manj...@ti.com writes:
This patch converts omap2/3/4 dma driver into platform
devices through using omap hwmod, omap device and runtime pm
frameworks.
[..]
+
+#define dma_read(reg)
\
+({
\
+ u32 __val;
\
+ __val = __raw_readl(dma_base + OMAP_DMA4_##reg);
\
+ __val;
\
+})
+
+#define dma_write(val, reg)
\
+({
\
+ __raw_writel((val), dma_base + OMAP_DMA4_##reg);
\
+})
I know these are copy paste from the original code, but please convert
into static inline functions.
Ok.
Also, I don't see dma_write() used in this patch.
This is initial patch for splitting mach-omap1 and mach-omap2 contents.
dma_write is used in later patches. Please refer to Patch #11
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 08/11] OMAP: DMA: Convert DMA library into DMA platform Driver
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 04, 2010 4:04 AM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 08/11] OMAP: DMA: Convert DMA library
into DMA platform Driver
Manjunatha GK manj...@ti.com writes:
This patch converts DMA library into DMA platform driver
and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses
resource structures
for getting platform data.
Also, it enables and uses run time PM API's
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/include/mach/dma.h | 66 +
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/include/mach/dma.h | 83 +++
arch/arm/plat-omap/dma.c | 244
+---
arch/arm/plat-omap/include/plat/dma.h | 157 ++---
6 files changed, 290 insertions(+), 264 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile
b/arch/arm/mach-omap1/Makefile
index 9a304d8..b7dfc54 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o
devices.o dma.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/include/mach/dma.h
b/arch/arm/mach-omap1/include/mach/dma.h
index d446cdd..1eb0d31 100644
--- a/arch/arm/mach-omap1/include/mach/dma.h
+++ b/arch/arm/mach-omap1/include/mach/dma.h
@@ -77,4 +77,70 @@
#define OMAP1_DMA_CCR2(n) (0x40 * (n) + 0x24)
#define OMAP1_DMA_LCH_CTRL(n) (0x40 * (n) + 0x2a)
+/* Dummy defines to support multi omap code */
These should not be needed anymore as this is now an OMAP1-specific
header.
Because it is OMAP1 specific header, there are common API's used between
omap1 and omap2 plus in plat-omap/dma.c which needs these defines otherwise
build will break for omap1 since these defines exists omap2 specific header
Which is in respective mach directory.
+/* Channel specific registers */
+#define OMAP_DMA4_CCR(n) 0
+#define OMAP_DMA4_CSDP(n) 0
+#define OMAP_DMA4_CEN(n) 0
+#define OMAP_DMA4_CFN(n) 0
+#define OMAP_DMA4_COLOR(n) 0
+#define OMAP_DMA4_CSSA(n) 0
+#define OMAP_DMA4_CSEI(n) 0
+#define OMAP_DMA4_CSFI(n) 0
+#define OMAP_DMA4_CDSA(n) 0
+#define OMAP_DMA4_CDEI(n) 0
+#define OMAP_DMA4_CDFI(n) 0
+#define OMAP_DMA4_CSR(n) 0
+#define OMAP_DMA4_CICR(n) 0
+#define OMAP_DMA4_CLNK_CTRL(n) 0
+#define OMAP_DMA4_CH_BASE(n) 0
+#define OMAP_DMA4_CDAC(n) 0
+#define OMAP_DMA4_CSAC(n) 0
+
+/* Common registers */
+#define OMAP_DMA4_IRQENABLE_L0 0
+#define OMAP_DMA4_OCP_SYSCONFIG0
+#define OMAP_DMA4_GCR 0
+#define OMAP_DMA4_IRQSTATUS_L0 0
+#define OMAP_DMA4_CAPS_2 0
+#define OMAP_DMA4_CAPS_3 0
+#define OMAP_DMA4_CAPS_4 0
+#define OMAP_DMA4_REVISION 0
+
+#define OMAP_DMA4_CCR2(n) 0
+#define OMAP_DMA4_LCH_CTRL(n) 0
+#define OMAP_DMA4_COLOR_L(n) 0
+#define OMAP_DMA4_COLOR_U(n) 0
+#define OMAP1_DMA_COLOR(n) 0
+#define OMAP_DMA4_CSSA_U(n)0
+#define OMAP_DMA4_CSSA_L(n)0
+#define OMAP1_DMA_CSSA(n) 0
+#define OMAP_DMA4_CDSA_U(n)0
+#define OMAP_DMA4_CDSA_L(n)0
+#define OMAP1_DMA_CDSA(n) 0
+#define OMAP_DMA4_CPC(n) 0
+
+#define OMAP1_DMA_IRQENABLE_L0 0
+#define OMAP1_DMA_IRQENABLE_L0 0
+#define OMAP1_DMA_IRQSTATUS_L0 0
+#define OMAP1_DMA_OCP_SYSCONFIG0
+#define OMAP_DMA4_HW_ID0
+#define OMAP_DMA4_CAPS_0_U 0
+#define OMAP_DMA4_CAPS_0_L 0
+#define OMAP_DMA4_CAPS_1_U 0
+#define OMAP_DMA4_CAPS_1_L 0
+#define OMAP_DMA4_GSCR 0
+#define OMAP1_DMA_REVISION 0
+
+struct omap_dma_lch {
+ int next_lch;
+ int dev_id;
+ u16 saved_csr;
+ u16 enabled_irqs;
+ const char *dev_name;
+ void (*callback)(int lch, u16 ch_status, void *data);
+ void *data;
+ long flags;
+};
+
#endif /* __ASM_ARCH_OMAP1_DMA_H */
diff --git a/arch/arm/mach-omap2/Makefile
RE: [PATCH v2 09/11] OMAP: DMA: Implement generic errata handling
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 04, 2010 4:12 AM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 09/11] OMAP: DMA: Implement generic
errata handling
Manjunatha GK manj...@ti.com writes:
This patch introduces generic way of handling all OMAP DMA
errata's which are applicable for OMAP1 and OMAP2PLUS processors.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/dma.c |6
arch/arm/mach-omap2/dma.c | 34
+++
arch/arm/plat-omap/dma.c | 48
++--
arch/arm/plat-omap/include/plat/dma.h |9 ++
4 files changed, 76 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 26ab6e3..615c5f5 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -170,6 +170,12 @@ static int __init omap1_system_dma_init(void)
goto exit_device_put;
}
+ /* Errata handling for all omap1 plus processors */
+ pdata-errata = 0;
This isn't needed as you just kzalloc'd pdata.
ok
+ if (cpu_class_is_omap1() !cpu_is_omap15xx())
You don't need cpu_class_is_omap1() as this is OMAP1 specific code.
Ok. Looks like copy, paste issue from plat-omap dma.c. I will fix it.
+ pdata-errata |= OMAP3_3_ERRATUM;
+
d = pdata-dma_attr;
/* Valid attributes for omap1 plus processors */
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index f369bee..8832bd1 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -80,6 +80,40 @@ static int __init
omap2_system_dma_init_dev(struct omap_hwmod *oh, void *user)
pdata-dma_attr = (struct omap_dma_dev_attr
*)oh-dev_attr;
+ /* Handling Errata's for all OMAP2PLUS processors */
+ pdata-errata = 0;
not needed, see above
ok
+ if (cpu_is_omap242x() ||
+ (cpu_is_omap243x() omap_type() =
OMAP2430_REV_ES1_0))
+ pdata-errata = DMA_CHAINING_ERRATA;
+
+ /*
+* Errata: On ES2.0 BUFFERING disable must be set.
+* This will always fail on ES1.0
+*/
+ if (cpu_is_omap24xx())
+ pdata-errata |= DMA_BUFF_DISABLE_ERRATA;
+
+ /*
+* Errata: OMAP2: sDMA Channel is not disabled
+* after a transaction error. So we explicitely
+* disable the channel
+*/
+ if (cpu_class_is_omap2())
+ pdata-errata |= DMA_CH_DISABLE_ERRATA;
+
+ /* Errata: OMAP3 :
fix multi-line comment style
Ok.
+* A bug in ROM code leaves IRQ status for channels 0
and 1 uncleared
+* after secure sram context save and restore. Hence we need to
+* manually clear those IRQs to avoid spurious interrupts. This
+* affects only secure devices.
+*/
+ if (cpu_is_omap34xx() (omap_type() != OMAP2_DEVICE_TYPE_GP))
+ pdata-errata |= DMA_IRQ_STATUS_ERRATA;
+
+ /* Errata3.3: Applicable for all omap2 plus */
+ pdata-errata |= OMAP3_3_ERRATUM;
+
od = omap_device_build(name, 0, oh, pdata, sizeof(*pdata),
omap2_dma_latency,
ARRAY_SIZE(omap2_dma_latency), 0);
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 36c3dde..409586a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -187,6 +187,25 @@ static inline void set_gdma_dev(int
req, int dev)
#define set_gdma_dev(req, dev) do {} while (0)
#endif
+static void dma_ocpsysconfig_errata(u32 *sys_cf, bool flag)
Please use (or extend) hwmod layer for modifying device SYSCONFIG.
I will check this.
+{
+ u32 l;
+
+ /*
+* DMA Errata:
+* Special programming model needed to disable DMA
before end of block
+*/
Please reference Errata#
ok. Original code doesn't have errata number, I will check errata
document.
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 04, 2010 4:20 AM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh; Sawant, Anand Subject: Re: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver G, Manjunath Kondaiah manj...@ti.com writes: If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? Reviewed. Still a long ways to go..., also I didn't see you address the typo pointed out by Mika Westerberg on PATCH 03/11. Sorry. I fixed it in my internal version and forgot to take that change. Thanks for pointing this. Also, testing on omap3430/n900, I noticed an interesting failure during boot. During boot (in the middle of omap3_pm_init(), a DMA interrupt fires and the SPI RX callback is called which faults when accessing it's registers. Not sure about n900, I will check if I get N900. I did not debug this further, but is something that needs investigation. Also, in the next version, please report how it was tested on the various OMAPs. In particular, what peripherals using DMA were tested. Just a boot test is not sufficient when making major functional changes like this. Drivers using DMA need to be tested as well. This patch series has been tested with various use cases like: 1. Memory to Memory DMA test cases from test code: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=shortlog;h=refs/heads/master 2. SD/MMC test cases(on zoom3, omap4 SDP and beagle) 3. Ethernet testing (on omap4 SDP with McSPI interface for both Rx and Tx - Also used NFS file system) I will provide these details in next version patches. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: Keypad: Fix failure exit path in probe
The failure exit paths seems to be wrong in probe function.
This patch corrects exit failure paths for error handling
cases.
Boot warning incase of request irq failure:
[1.553985] twl4030_keypad twl4030_keypad: request_irq failed for irq no=369
[1.561157] [ cut here ]
[1.565795] WARNING: at kernel/irq/manage.c:899 __free_irq+0x88/0x164()
[1.572418] Trying to free already-free IRQ 369
[1.576965] Modules linked in:
[1.580047] [c00470ec] (unwind_backtrace+0x0/0xe4) from [c0078b5c]
(warn_slowpath_common+0x4c/0x64)
[1.589477] [c0078b5c] (warn_slowpath_common+0x4c/0x64) from [c0078bf4]
(warn_slowpath_fmt+0x2c/0x3c)
[1.599060] [c0078bf4] (warn_slowpath_fmt+0x2c/0x3c) from [c00adb90]
(__free_irq+0x88/0x164)
[1.607849] [c00adb90] (__free_irq+0x88/0x164) from [c00adca8]
(free_irq+0x3c/0x5c)
[1.615875] [c00adca8] (free_irq+0x3c/0x5c) from [c043ab2c]
(twl4030_kp_probe+0x308/0x374)
[1.624511] [c043ab2c] (twl4030_kp_probe+0x308/0x374) from [c023c338]
(platform_drv_probe+0x14/0x18)
[1.634033] [c023c338] (platform_drv_probe+0x14/0x18) from [c023b4dc]
(driver_probe_device+0xc8/0x184)
[1.643707] [c023b4dc] (driver_probe_device+0xc8/0x184) from [c023b600]
(__driver_attach+0x68/0x8c)
[1.653106] [c023b600] (__driver_attach+0x68/0x8c) from [c023ad34]
(bus_for_each_dev+0x48/0x74)
[1.662170] [c023ad34] (bus_for_each_dev+0x48/0x74) from [c023a690]
(bus_add_driver+0x9c/0x210)
[1.671234] [c023a690] (bus_add_driver+0x9c/0x210) from [c023b8f8]
(driver_register+0xa8/0x134)
[1.680297] [c023b8f8] (driver_register+0xa8/0x134) from [c0041340]
(do_one_initcall+0x58/0x1b4)
[1.689453] [c0041340] (do_one_initcall+0x58/0x1b4) from [c0008574]
(kernel_init+0x98/0x150)
[1.698272] [c0008574] (kernel_init+0x98/0x150) from [c0042970]
(kernel_thread_exit+0x0/0x8)
[1.707214] ---[ end trace 6559b322ad3cbdfe ]---
[1.718292] twl4030_keypad: probe of twl4030_keypad failed with error -16
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index fb16b5e..39a9f30 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -347,8 +347,7 @@ static int __devinit twl4030_kp_probe(struct
platform_device *pdev)
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
input = input_allocate_device();
if (!kp || !input) {
- error = -ENOMEM;
- goto err1;
+ return -ENOMEM;
}
/* Get the debug Device */
@@ -406,23 +405,22 @@ static int __devinit twl4030_kp_probe(struct
platform_device *pdev)
if (error) {
dev_info(kp-dbg_dev, request_irq failed for irq no=%d\n,
kp-irq);
- goto err3;
+ goto err2;
}
/* Enable KP and TO interrupts now. */
reg = (u8) ~(KEYP_IMR1_KP | KEYP_IMR1_TO);
if (twl4030_kpwrite_u8(kp, reg, KEYP_IMR1)) {
error = -EIO;
- goto err4;
+ goto err3;
}
platform_set_drvdata(pdev, kp);
return 0;
-err4:
+err3:
/* mask all events - we don't care about the result */
(void) twl4030_kpwrite_u8(kp, 0xff, KEYP_IMR1);
-err3:
free_irq(kp-irq, NULL);
err2:
input_unregister_device(input);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3: regulator_get() failure in ads7846
On Tue, Sep 07, 2010 at 05:16:44PM +0530, Premi, Sanjeev wrote: ts-reg = regulator_get(spi-dev, vcc); This regulator isn't defined for omap3evm. And I suspect - once defined - the name will be different than vcc. What makes you say this? The names for regulator supplies are defined in terms of the chip being supplied, not in terms of the board. Looking at pointers on how this should be handled. The best thing to do is to define the mapping for the regulator. You can work around it by enabling REGULATOR_DUMMY. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4
Hi Tomi, -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Tuesday, September 07, 2010 4:23 PM To: K, Mythri P Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4 Hi, On Thu, 2010-08-26 at 07:16 +0200, ext K, Mythri P wrote: From: Mythri P K mythr...@ti.com This patch is a outline of how the HDMI support is added to OMAP4. Please run checkpatch.pl for the patches before you send them. Checkpatch reported over 300 errors. I am not sure which of the 2 patches you are talking about , I have run checkpatch.pl for the patches and I see some over 80 lines warning which I have ignored but I see no errors. HDMI is a driver that is similar to the VENC or the DSI driver to support HDMI/DVI sink device. When I made the VENC driver, I put both the core VENC and the venc panel into the same file, inside dss driver. The reason was that VENC is part of OMAP DSS, and not an external panel. I've been thinking about this a few times, but so far I haven't changed it. Did you have some reason to put the HDMI panel driver into displays/? The reason why I separated out the DSS specific code and the panel driver with the HDMI core specific code is because, when the OMAP related code might change, the HDMI core related changes could be reusable and logically as it reads the EDID and configures the IP based on the TV i.e. connected to it. Also given that there are several user level configurations that are supported such as the YUV format conversion/AVI information based on the TV capability it would be cleaner to handle that in a panel driver. The current Design adheres to the DSS2 Architecture. It is split into the HDMI DSS driver and HDMI panel Driver. HDMI DSS driver Located in drivers/video/omap2/dss/hdmi.c is responsible for OMAP related configuration such as listening to the DSS_HDMI irq which signals changes such as Hot-plug detect , Physical attach/detach. This driver is responsible to calculate the PLL values based on the TV resolution that is selected. Yet another functionality is to call necessary configuration for the Mux/GPIO settings. Why does HDMI need mux/GPIO changes? Some of the HDMI functionality like hot-plug-detect which works on the level shifters(0/5v) and the DDC line to read the EDID from the TV needs GPIO configurations. HDMI Panel Driver is located in drivers/video/omap2/displays/hdmi_omap4_panel.c. This is a panel driver which acts as the HDMI source and is responsible for all the configuration of the HDMI, based on the parameters read from the EDID of the sink device. It registers hdmi driver to the omap_dss bus and calls the functionality of the HDMI DSS driver. This driver is responsible for configuration of the HDMI IP, which are: 1. Configuration of the PHY registers. 2. Configuration of the PLL registers and setting of the TMDS clock. 3. Configuration of the DDC to read the EDID data when available. 4. Configuration of the core reigsters to set: a. set the video registers to the timing and format that is selected. b. set the audio reigsters based on the EDID value read and user selected parameters. c. Set the AVI info frame reigsters to configure the auxilary info frame which are repeated. It is also provides the interface for users 1.To read the EDID contents and also confiure the timings based on EDID. 2.To configure AVI Inforframe Based on the the EDID(sink capability). Mythri P K (2): OMAP:DSS:Patch to add support for HDMI as panel driver OMAP:DSS:Patch to add HDMI DSS driver support drivers/video/omap2/displays/hdmi_omap4_panel.c | 1443 +++ drivers/video/omap2/displays/hdmi_omap4_panel.h | 672 +++ drivers/video/omap2/dss/hdmi.c | 292 + 3 files changed, 2407 insertions(+), 0 deletions(-) create mode 100644 drivers/video/omap2/displays/hdmi_omap4_panel.c create mode 100644 drivers/video/omap2/displays/hdmi_omap4_panel.h create mode 100644 drivers/video/omap2/dss/hdmi.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
On Tue, 2010-09-07 at 13:31 +0200, ext Taneja, Archit wrote:
Hi,
Tomi Valkeinen wrote:
Hi,
On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
Would a more static approach be cleaner? I mean something like this (pseudo
code):
static struct omap_dss_features omap3_dss_features = {
/* array of register definitions */
.registers = {
{
.register = FIRHINC,
.high = 12,
.low = 0,
},
{
.register = FIRVINC,
.high = 28,
.low = 16,
},
...
},
/* array of feature ids */
.features = {
GLOBAL_ALPHA,
GLOBAL_ALPHA_VIDEO1,
...
},
};
And then the code would select the omapX_dss_features struct
to use depending on the omap version.
It looks way cleaner out here , not sure though what it would look
like once the whole file is filled up :)
One issue with having separate omapX_dss_features is something which might may
come later on : If there is a feature/value which is same in omap2 and omap3
but different in omap4, we will sill need to fill up all the structs
completely.
We can get around this by filling one single struct on runtime :
all omap2 specific features filled up here
{
...
...
}
all common between omap2 and omap3 filled up here
{
...
...
}
all omap3 specific filled up here
{
...
...
}
And so on..
This will save up space, but won't give a very clean look ..
I think by the time all omap4(and 3630) features are added and remaining
omap2,3 checks are removed we will have atleast 20 or so register fields
and a dozen features. Initializing them statically for all omaps(including
the ES_REV's) will really stretch up the file. But it will still look clean :)
What's your call on this?
I'd try with static structs. I agree that if there are lots of
features/registers which are the same on multiple omaps, there's
redundant code needed. But it just needs to be written once, and having
lots of if(omap_()) lines will be a nightmare to maintain.
Or if things get really long, we could use multiple files, one for each
omap.
Also, we can make the definitions a bit shorter by using macros where
suitable. For example the registers could be defined with something like
FEAT_REG(FIRHINC, 12, 0), which will will the fields properly.
Or there could be a define for feature IDs, which could be appended.
Like:
#define FEAT_ID_OMAP2 AAA,\
BBB,\
CCC
#define FEAT_ID_OMAP3 FEAT_ID_OMAP2,\
DDD,\
EEE,\
But... That's getting a bit nasty, I wouldn't do things like that if not
absolutely needed =).
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP: DSS2: Introduce dss_features files
Hi,
Tomi Valkeinen wrote:
On Tue, 2010-09-07 at 13:31 +0200, ext Taneja, Archit wrote:
Hi,
Tomi Valkeinen wrote:
Hi,
On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
Would a more static approach be cleaner? I mean something like this (pseudo
code):
static struct omap_dss_features omap3_dss_features = {
/* array of register definitions */
.registers = {
{
.register = FIRHINC,
.high = 12,
.low = 0,
},
{
.register = FIRVINC,
.high = 28,
.low = 16,
},
...
},
/* array of feature ids */
.features = {
GLOBAL_ALPHA,
GLOBAL_ALPHA_VIDEO1,
...
},
};
And then the code would select the omapX_dss_features struct to use
depending on the omap version.
It looks way cleaner out here , not sure though what it would look
like once the whole file is filled up :)
One issue with having separate omapX_dss_features is something which
might may come later on : If there is a feature/value which is same in
omap2 and omap3 but different in omap4, we will sill need
to fill up all the structs completely.
We can get around this by filling one single struct on runtime :
all omap2 specific features filled up here { ...
...
}
all common between omap2 and omap3 filled up here { ... ...
}
all omap3 specific filled up here
{
...
...
}
And so on..
This will save up space, but won't give a very clean look ..
I think by the time all omap4(and 3630) features are added and remaining
omap2,3 checks are removed we will have atleast 20 or so register
fields and a dozen features. Initializing them statically for all
omaps(including the ES_REV's) will really stretch up the file. But it will
still look clean :)
What's your call on this?
I'd try with static structs. I agree that if there are lots
of features/registers which are the same on multiple omaps,
there's redundant code needed. But it just needs to be
written once, and having lots of if(omap_()) lines will
be a nightmare to maintain.
Or if things get really long, we could use multiple files,
one for each omap.
Also, we can make the definitions a bit shorter by using
macros where suitable. For example the registers could be
defined with something like FEAT_REG(FIRHINC, 12, 0), which
will will the fields properly.
Okay, I will try this out.
Archit
Or there could be a define for feature IDs, which could be appended. Like:
#define FEAT_ID_OMAP2 AAA,\
BBB,\
CCC
#define FEAT_ID_OMAP3 FEAT_ID_OMAP2,\
DDD,\
EEE,\
But... That's getting a bit nasty, I wouldn't do things like
that if not absolutely needed =).
Tomi--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3: regulator_get() failure in ads7846
Hi, I think, this can help: http://www.spinics.net/lists/arm-kernel/msg94759.html Seems like there were not enough interest and it is still floating. May be a little ping can help ;) On 09/07/10 14:46, Premi, Sanjeev wrote: Hi all, While booting the latest kernel (from linux-omap) on omap3evm, I came across this error. [3.202575] ads7846 spi1.0: unable to get regulator: -19 [3.208190] [ cut here ] [3.212890] WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x114/0x140() [3.219940] Modules linked in: [3.223083] [c004e57c] (unwind_backtrace+0x0/0xec) from [c007e5d8] (warn_slowpath_common+0x4c/0x64) ... ... [3.342529] ---[ end trace 1b75b31a2719ed1f ]--- In drivers/input/touchscreen/ads7846.c, we attempt to get the regulator as: ts-reg = regulator_get(spi-dev, vcc); This regulator isn't defined for omap3evm. And I suspect - once defined - the name will be different than vcc. Looking at pointers on how this should be handled. Best regard, Sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
Hi, On Tue, 7 Sep 2010 11:49:38 +0900, venki kaps venkiece2...@gmail.com wrote: let me see if I understand you right. The consumption is higher when the cable is kept plugged or the consumption is higher if you boot with usb cable pugged and remove it afterwards ? The consumption is higher if boot without usb cable.If boot when the cable is kept plugged and remove it afterwards, then normal. ok, so that's what I had observed and my original patch is the one you want. You probably _also_ want this one though due the WARN -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3: regulator_get() failure in ads7846
On Tue, Sep 07, 2010 at 03:16:21PM +0300, Igor Grinberg wrote: I think, this can help: http://www.spinics.net/lists/arm-kernel/msg94759.html Seems like there were not enough interest and it is still floating. May be a little ping can help ;) This is a really bad idea unless the supplies genuinely are optional - we shouldn't be doing this sort of bodge in the drivers, that's just going to lead to lots of repetitive code adding complexity every time the regulator API is used. It also makes the error handling rather more obscure since systems that genuinely need the regulator won't be reporting problems clearly. The regulator API has facilties on several levels to deal with systems that have problems here: it provides fixed voltage regulators, it provides the option to substitute in dummy regulators automatically and if the regulator API is disabled then the stub functions provided will report success. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap3: regulator_get() failure in ads7846
-Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Tuesday, September 07, 2010 5:46 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org Subject: Re: omap3: regulator_get() failure in ads7846 Hi, I think, this can help: http://www.spinics.net/lists/arm-kernel/msg94759.html Seems like there were not enough interest and it is still floating. May be a little ping can help ;) [sp] Will review this patch... [snip]...[snip] -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver support
On Thu, 2010-08-26 at 07:17 +0200, ext K, Mythri P wrote:
From: Mythri P K mythr...@ti.com
This is an RFC patch to add support for HDMI DSS driver in OMAP.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 292
1 files changed, 292 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.c
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
new file mode 100644
index 000..3d7acd2
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -0,0 +1,292 @@
+/*
+ * linux/drivers/video/omap2/dss/hdmi.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Author: Yong Zhi
+ *
+ * HDMI settings from TI's DSS driver
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ * History:
+ * Mythripk mythr...@ti.com-Redesigned on the driver to adhere to
DSS2 model.
+ * -GPIO calls for HDMI.
+ *
+ *
+ */
+
+#define DSS_SUBSYS_NAME HDMI
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include plat/display.h
+#include plat/cpu.h
+#include plat/gpio.h
+
+#include dss.h
+
+static struct {
+ struct mutex lock;
+} hdmi;
+
+#define FLD_GET(val, start, end) (((val) FLD_MASK(start, end)) (end))
+#define FLD_MOD(orig, val, start, end) \
+ (((orig) ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
These are already defined in dss.h
+
+
+#define CPF 2
+
+int hdmi_init_display(struct omap_dss_device *dssdev)
+{
+ DSSDBG(init_display\n);
+
+ return 0;
+}
+
+void compute_hdmi_pll(int clkin, int phy,
+ int n, struct hdmi_pll_info *pi)
This is a non-static function, and you don't introduce it in any header
file.
It is not exported, so it should be used only from inside DSS driver. I
see you call it in the next patch from the display driver, which is not
ok. Only exported functions should be used from the display drivers
(you'll notice the problem if you build DSS as a module...).
If the function is not static, it should have some meaningful prefix.
The same comments apply to some other functions in this file also.
+{
+ int refclk;
+ u32 temp, mf;
+
+ if (clkin 3200) /* 32 mHz */
+ refclk = clkin / (2 * (n + 1));
+ else
+ refclk = clkin / (n + 1);
+
+ temp = phy * 100/(CPF * refclk);
+
+ pi-regn = n;
+ pi-regm = temp/100;
+ pi-regm2 = 1;
+
+ mf = (phy - pi-regm * CPF * refclk) * 262144;
+ pi-regmf = mf/(CPF * refclk);
+
+ if (phy 1000 * 100) {
+ pi-regm4 = phy / 1;
+ pi-dcofreq = 1;
+ pi-regsd = ((pi-regm * 384)/((n + 1) * 250) + 5)/10;
+ } else {
+ pi-regm4 = 1;
+ pi-dcofreq = 0;
+ pi-regsd = 0;
+ }
+
+ DSSDBG(M = %d Mf = %d, m4= %d\n, pi-regm, pi-regmf, pi-regm4);
+ DSSDBG(range = %d sd = %d\n, pi-dcofreq, pi-regsd);
+}
+
+
+static void hdmi_enable_clocks(int enable)
+{
+ if (enable)
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M |
+ DSS_CLK_96M);
+ else
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M |
+ DSS_CLK_96M);
+}
+
+static irqreturn_t hdmi_irq_handler(int irq, void *arg)
+{
+ DSSDBG(Will be used in future to handle HPD);
+ return IRQ_HANDLED;
+}
+
+int hdmi_init(struct platform_device *pdev, int code, int mode)
+{
+ int r = 0;
+ DSSDBG(Enter hdmi_init()\n);
+
+ mutex_init(hdmi.lock);
+
+ r = request_irq(OMAP44XX_IRQ_DSS_HDMI, hdmi_irq_handler,
+ 0, OMAP HDMI, (void *)0);
+
+ return 0;
+
+}
+
+void hdmi_exit(void)
+{
+ free_irq(OMAP44XX_IRQ_DSS_HDMI, NULL);
+
+}
+
+static int hdmi_power_on(struct omap_dss_device *dssdev)
+{
+ hdmi_enable_clocks(1);
+
+ dispc_enable_digit_out(0);
+
+ printk(poweron returns);
+
+ return 0;
+}
+
+int hdmi_dispc_setting(struct omap_dss_device *dssdev)
+{
+
+
+ /* these settings are independent of overlays */
+
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
Venkii, On Tue, Sep 7, 2010 at 6:16 PM, Felipe Balbi m...@felipebalbi.com wrote: Hi, On Tue, 7 Sep 2010 11:49:38 +0900, venki kaps venkiece2...@gmail.com wrote: let me see if I understand you right. The consumption is higher when the cable is kept plugged or the consumption is higher if you boot with usb cable pugged and remove it afterwards ? The consumption is higher if boot without usb cable.If boot when the cable is kept plugged and remove it afterwards, then normal. ok, so that's what I had observed and my original patch is the one you want. You probably _also_ want this one though due the WARN Is WARN_ON created issue? or As you mentioned earlier, if (!regulator_is_enabled(twl-usb3v1) regulator_enable(twl-usb3v1); would be required? could you please provide more details? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] OMAP3: Keypad: Fix failure exit path in probe
From: ext G, Manjunath Kondaiah manj...@ti.com
The failure exit paths seems to be wrong in probe function.
This patch corrects exit failure paths for error handling
cases.
Boot warning incase of request irq failure:
[1.553985] twl4030_keypad twl4030_keypad: request_irq failed for irq no=369
[1.561157] [ cut here ]
[1.565795] WARNING: at kernel/irq/manage.c:899 __free_irq+0x88/0x164()
[1.572418] Trying to free already-free IRQ 369
[1.576965] Modules linked in:
[1.580047] [c00470ec] (unwind_backtrace+0x0/0xe4) from [c0078b5c]
(warn_slowpath_common+0x4c/0x64)
[1.589477] [c0078b5c] (warn_slowpath_common+0x4c/0x64) from [c0078bf4]
(warn_slowpath_fmt+0x2c/0x3c)
[1.599060] [c0078bf4] (warn_slowpath_fmt+0x2c/0x3c) from [c00adb90]
(__free_irq+0x88/0x164)
[1.607849] [c00adb90] (__free_irq+0x88/0x164) from [c00adca8]
(free_irq+0x3c/0x5c)
[1.615875] [c00adca8] (free_irq+0x3c/0x5c) from [c043ab2c]
(twl4030_kp_probe+0x308/0x374)
[1.624511] [c043ab2c] (twl4030_kp_probe+0x308/0x374) from [c023c338]
(platform_drv_probe+0x14/0x18)
[1.634033] [c023c338] (platform_drv_probe+0x14/0x18) from [c023b4dc]
(driver_probe_device+0xc8/0x184)
[1.643707] [c023b4dc] (driver_probe_device+0xc8/0x184) from [c023b600]
(__driver_attach+0x68/0x8c)
[1.653106] [c023b600] (__driver_attach+0x68/0x8c) from [c023ad34]
(bus_for_each_dev+0x48/0x74)
[1.662170] [c023ad34] (bus_for_each_dev+0x48/0x74) from [c023a690]
(bus_add_driver+0x9c/0x210)
[1.671234] [c023a690] (bus_add_driver+0x9c/0x210) from [c023b8f8]
(driver_register+0xa8/0x134)
[1.680297] [c023b8f8] (driver_register+0xa8/0x134) from [c0041340]
(do_one_initcall+0x58/0x1b4)
[1.689453] [c0041340] (do_one_initcall+0x58/0x1b4) from [c0008574]
(kernel_init+0x98/0x150)
[1.698272] [c0008574] (kernel_init+0x98/0x150) from [c0042970]
(kernel_thread_exit+0x0/0x8)
[1.707214] ---[ end trace 6559b322ad3cbdfe ]---
[1.718292] twl4030_keypad: probe of twl4030_keypad failed with error -16
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index fb16b5e..cf94850 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -345,10 +345,13 @@ static int __devinit twl4030_kp_probe(struct
platform_device *pdev)
}
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
+ if (!kp)
+ return -ENOMEM;
+
input = input_allocate_device();
- if (!kp || !input) {
- error = -ENOMEM;
- goto err1;
+ if (!input) {
+ kfree(kp);
+ return -ENOMEM;
}
/* Get the debug Device */
@@ -406,23 +409,22 @@ static int __devinit twl4030_kp_probe(struct
platform_device *pdev)
if (error) {
dev_info(kp-dbg_dev, request_irq failed for irq no=%d\n,
kp-irq);
- goto err3;
+ goto err2;
}
/* Enable KP and TO interrupts now. */
reg = (u8) ~(KEYP_IMR1_KP | KEYP_IMR1_TO);
if (twl4030_kpwrite_u8(kp, reg, KEYP_IMR1)) {
error = -EIO;
- goto err4;
+ goto err3;
}
platform_set_drvdata(pdev, kp);
return 0;
-err4:
+err3:
/* mask all events - we don't care about the result */
(void) twl4030_kpwrite_u8(kp, 0xff, KEYP_IMR1);
-err3:
free_irq(kp-irq, NULL);
err2:
input_unregister_device(input);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1
2010/9/7 Sergei Shtylyov sshtyl...@mvista.com: Hello. Ming Lei wrote: Which codebase is this patch meant for? I don't see the hb_mult in current mainline code? Are there any patches which this one depends on? This depends on the two iso for device mode patches: http://marc.info/?l=linux-usbm=128076716001885w=2 http://marc.info/?l=linux-usbm=128076716901924w=2 I plan to resend the two patches above and the double buffer patches later. I recommend that you change the ordering of patches so that fixes come first, and new features last. I.e. this patch should precede the second one of those two above. Good point, I will resend all the fix patches first, then the isochronous support patch. thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap3: regulator_get() failure in ads7846
-Original Message-
From: linux-input-ow...@vger.kernel.org
[mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Mark Brown
Sent: Tuesday, September 07, 2010 5:27 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org
Subject: Re: omap3: regulator_get() failure in ads7846
On Tue, Sep 07, 2010 at 05:16:44PM +0530, Premi, Sanjeev wrote:
ts-reg = regulator_get(spi-dev, vcc);
This regulator isn't defined for omap3evm. And I suspect - once
defined - the name will be different than vcc.
What makes you say this? The names for regulator supplies are defined
in terms of the chip being supplied, not in terms of the board.
[sp] The name vcc is too generic name for the regulator supply. If
there were more than one supplies as in case of the omap3evm, it
would be difficult to name the supply as vcc.
Assuming there is another (different) driver which uses vcc
(as ads7846 uses currently) but uses different supply, what is
expected behavior?
If, however, the name here was something like vcc_ts, then
the supplies could be defined for any board as:
static struct regulator_consumer_supply my_board_ts_supply = {
.supply = vcc_ts,
};
This would be more portable for other boards as well.
OR
Does regulator_get() searches by device_name-supply_id pair?
Then, my comments above don't hold... And I would try the
mapping you mentioned below.
Looking at pointers on how this should be handled.
The best thing to do is to define the mapping for the regulator. You
can work around it by enabling REGULATOR_DUMMY.
[sp] Yes, this would be a workaround; but it comes with another
warning on console.
Best regards,
Sanjeev
--
To unsubscribe from this list: send the line unsubscribe
linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. If i use __twl4030_phy_power(twl, 0) at the end of USB LDO initialization, If you apply this patch against 2.6.36-rc3, you will find __twl4030_phy_power(twl, 0) is always called from .probe if you don't connect musb with PC via cable when powering on. then able to hit proper values but USB ADC values are getting in correct with Travel adapter (Charger power supply) which means temperature shows 84 instead of 26~30 degrees. Queries, --- - Is Errata 1.164 fix : OTG idle will work on 3430? No such errata found in ti wetsite, could you give a link? - USBOTG_SUSPEND is enabled in Kernel 32, will it give any impact? Kernel does not have USBOTG_SUSPEND config option. Do you mean USB_SUSPEND? If so, it is nothing to do with your issue since it is only valid for host driver. Also for your case, musb works at b-idle state. - Is there anything missed from Power management idle path (or) USB OTG controller/Transreceiver driver part? Maybe with transreceiver part, musb doesn't support runtime pm now. Could you please provide the best approach to solve my issue? Sorry, this patch is not for your issue, as said above. -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver support
Hi Tomi,
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Tuesday, September 07, 2010 6:47 PM
To: K, Mythri P
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver
support
On Thu, 2010-08-26 at 07:17 +0200, ext K, Mythri P wrote:
From: Mythri P K mythr...@ti.com
This is an RFC patch to add support for HDMI DSS driver in OMAP.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 292
1 files changed, 292 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.c
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
new file mode 100644
index 000..3d7acd2
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -0,0 +1,292 @@
+/*
+ * linux/drivers/video/omap2/dss/hdmi.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Author: Yong Zhi
+ *
+ * HDMI settings from TI's DSS driver
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public
License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ * History:
+ * Mythripk mythr...@ti.com -Redesigned on the driver to
adhere to DSS2 model.
+ * -GPIO calls for HDMI.
+ *
+ *
+ */
+
+#define DSS_SUBSYS_NAME HDMI
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include plat/display.h
+#include plat/cpu.h
+#include plat/gpio.h
+
+#include dss.h
+
+static struct {
+ struct mutex lock;
+} hdmi;
+
+#define FLD_GET(val, start, end) (((val) FLD_MASK(start, end))
(end))
+#define FLD_MOD(orig, val, start, end) \
+ (((orig) ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
These are already defined in dss.h
+
+
+#define CPF2
+
+int hdmi_init_display(struct omap_dss_device *dssdev)
+{
+ DSSDBG(init_display\n);
+
+ return 0;
+}
+
+void compute_hdmi_pll(int clkin, int phy,
+ int n, struct hdmi_pll_info *pi)
This is a non-static function, and you don't introduce it in any
header
file.
It is not exported, so it should be used only from inside DSS driver.
I
see you call it in the next patch from the display driver, which is
not
ok. Only exported functions should be used from the display drivers
(you'll notice the problem if you build DSS as a module...).
If the function is not static, it should have some meaningful prefix.
The same comments apply to some other functions in this file also.
I have introduced these in the display.h , do you suggest adding prefix like
omapdss_hdmi* for all these functions ?
+{
+ int refclk;
+ u32 temp, mf;
+
+ if (clkin 3200) /* 32 mHz */
+ refclk = clkin / (2 * (n + 1));
+ else
+ refclk = clkin / (n + 1);
+
+ temp = phy * 100/(CPF * refclk);
+
+ pi-regn = n;
+ pi-regm = temp/100;
+ pi-regm2 = 1;
+
+ mf = (phy - pi-regm * CPF * refclk) * 262144;
+ pi-regmf = mf/(CPF * refclk);
+
+ if (phy 1000 * 100) {
+ pi-regm4 = phy / 1;
+ pi-dcofreq = 1;
+ pi-regsd = ((pi-regm * 384)/((n + 1) * 250) + 5)/10;
+ } else {
+ pi-regm4 = 1;
+ pi-dcofreq = 0;
+ pi-regsd = 0;
+ }
+
+ DSSDBG(M = %d Mf = %d, m4= %d\n, pi-regm, pi-regmf, pi-
regm4);
+ DSSDBG(range = %d sd = %d\n, pi-dcofreq, pi-regsd);
+}
+
+
+static void hdmi_enable_clocks(int enable)
+{
+ if (enable)
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M
|
+ DSS_CLK_96M);
+ else
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M
|
+ DSS_CLK_96M);
+}
+
+static irqreturn_t hdmi_irq_handler(int irq, void *arg)
+{
+ DSSDBG(Will be used in future to handle HPD);
+ return IRQ_HANDLED;
+}
+
+int hdmi_init(struct platform_device *pdev, int code, int mode)
+{
+ int r = 0;
+ DSSDBG(Enter hdmi_init()\n);
+
+ mutex_init(hdmi.lock);
+
+ r = request_irq(OMAP44XX_IRQ_DSS_HDMI, hdmi_irq_handler,
+
RE: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver support
On Tue, 2010-09-07 at 15:37 +0200, ext K, Mythri P wrote:
Hi Tomi,
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Tuesday, September 07, 2010 6:47 PM
To: K, Mythri P
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver
support
On Thu, 2010-08-26 at 07:17 +0200, ext K, Mythri P wrote:
From: Mythri P K mythr...@ti.com
This is an RFC patch to add support for HDMI DSS driver in OMAP.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 292
1 files changed, 292 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.c
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
new file mode 100644
index 000..3d7acd2
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -0,0 +1,292 @@
+/*
+ * linux/drivers/video/omap2/dss/hdmi.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Author: Yong Zhi
+ *
+ * HDMI settings from TI's DSS driver
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public
License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ * History:
+ * Mythripk mythr...@ti.com-Redesigned on the driver to
adhere to DSS2 model.
+ * -GPIO calls for HDMI.
+ *
+ *
+ */
+
+#define DSS_SUBSYS_NAME HDMI
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include plat/display.h
+#include plat/cpu.h
+#include plat/gpio.h
+
+#include dss.h
+
+static struct {
+ struct mutex lock;
+} hdmi;
+
+#define FLD_GET(val, start, end) (((val) FLD_MASK(start, end))
(end))
+#define FLD_MOD(orig, val, start, end) \
+ (((orig) ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
These are already defined in dss.h
+
+
+#define CPF 2
+
+int hdmi_init_display(struct omap_dss_device *dssdev)
+{
+ DSSDBG(init_display\n);
+
+ return 0;
+}
+
+void compute_hdmi_pll(int clkin, int phy,
+ int n, struct hdmi_pll_info *pi)
This is a non-static function, and you don't introduce it in any
header
file.
It is not exported, so it should be used only from inside DSS driver.
I
see you call it in the next patch from the display driver, which is
not
ok. Only exported functions should be used from the display drivers
(you'll notice the problem if you build DSS as a module...).
If the function is not static, it should have some meaningful prefix.
The same comments apply to some other functions in this file also.
I have introduced these in the display.h , do you suggest adding prefix like
omapdss_hdmi* for all these functions ?
Neither of the two HDMI patches you sent modify display.h...
Yes, if you export functions from DSS they should be prefixed, as they
are global functions.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
thanks for your good response. Venkii, On Tue, Sep 7, 2010 at 6:54 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. Yes, this patch i have applied. If i use __twl4030_phy_power(twl, 0) at the end of USB LDO initialization, If you apply this patch against 2.6.36-rc3, you will find __twl4030_phy_power(twl, 0) is always called from .probe if you don't connect musb with PC via cable when powering on. then able to hit proper values but USB ADC values are getting in correct with Travel adapter (Charger power supply) which means temperature shows 84 instead of 26~30 degrees. Queries, --- - Is Errata 1.164 fix : OTG idle will work on 3430? No such errata found in ti wetsite, could you give a link? In Zoom3 git,pm34xx.c file /* * Errata 1.164 fix : OTG autoidle can prevent * sleep. enable/disable iclk over OFF. */ cm_rmw_mod_reg_bits(OMAP3430_EN_HSOTGUSB, 0x0, CORE_MOD, CM_ICLKEN1); - USBOTG_SUSPEND is enabled in Kernel 32, will it give any impact? Kernel does not have USBOTG_SUSPEND config option. Do you mean USB_SUSPEND? If so, it is nothing to do with your issue since it is only valid for host driver. Also for your case, musb works at b-idle state. Yes,CONFIG_USB_SUSPEND. - Is there anything missed from Power management idle path (or) USB OTG controller/Transreceiver driver part? Maybe with transreceiver part, musb doesn't support runtime pm now. Could you please provide the best approach to solve my issue? Sorry, this patch is not for your issue, as said above. -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3: regulator_get() failure in ads7846
On Tue, Sep 07, 2010 at 06:56:47PM +0530, Premi, Sanjeev wrote:
From: linux-input-ow...@vger.kernel.org
[mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Mark Brown
What makes you say this? The names for regulator supplies are defined
in terms of the chip being supplied, not in terms of the board.
[sp] The name vcc is too generic name for the regulator supply. If
there were more than one supplies as in case of the omap3evm, it
would be difficult to name the supply as vcc.
As I said above: these are defined in terms of the *chip* being
supplied. The name of the pin on the device does not change depending
on which board they're soldered down on and is orthogonal to both the
name of the supply on the regulator and both are orthogonal to the name
the rail is given on a given board.
Assuming there is another (different) driver which uses vcc
(as ads7846 uses currently) but uses different supply, what is
expected behavior?
The expected behaviour is that both devices request the supplies under
the names that they are given by the chip.
If, however, the name here was something like vcc_ts, then
the supplies could be defined for any board as:
static struct regulator_consumer_supply my_board_ts_supply = {
.supply = vcc_ts,
};
This would be more portable for other boards as well.
Using strings like this doesn't scale - you may have two devices of a
given type with different supply arrangements on a board, for example.
Does regulator_get() searches by device_name-supply_id pair?
Then, my comments above don't hold... And I would try the
mapping you mentioned below.
Yes, this is the reason why we require the struct device in get().
Looking at pointers on how this should be handled.
The best thing to do is to define the mapping for the regulator. You
can work around it by enabling REGULATOR_DUMMY.
[sp] Yes, this would be a workaround; but it comes with another
warning on console.
Yes, you're not really supposed to use it in production.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] split out emac cpdma and mdio for reuse
David Miller da...@davemloft.net writes: From: Cyril Chemparathy cy...@ti.com Date: Fri, 03 Sep 2010 14:20:47 -0400 Hi Kevin, [...] Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Just to clarify... did EMAC work on AM3517 before this series? No. It didn't work before this series. To get AM3517 EMAC working, the driver needs another patch to enable the interface clock in addition to the functional clock. Since this has dependencies on davinci board files and whatnot, why don't you merge this via the davinci tree and add my: Acked-by: David S. Miller da...@davemloft.net Ok? OK, will do. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] split out emac cpdma and mdio for reuse
Cyril Chemparathy cy...@ti.com writes: Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine. These hardware modules are not restricted to EMAC device alone. For example, CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules internally. This patch series separates out EMAC's MDIO and CPDMA functionality, allowing these individual pieces to be reused across TI hardware. Tony, The AM3517 also uses this davinci EMAC driver and is modified by this series. With your ack, I'll merge the OMAP changes along with this series via the davinci tree. OK with you? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCH 0/6] USB: musb-gadget: bug fix
This patch set fixes two kinds of musb-gadget bug: -fix kernel panic if using out ep with FIFO_TXRX style -make double buffer mode usable, fix infinate hangs and buffer corrupt bug when using double buffer mode to do data transfer; now we can use musb double buffer reliably, so bootst performance about 30% compared with single buffer mode. [RESEND/PATCH 1/6] USB: musb-gadget: fix kernel panic if using out ep with FIFO_TXRX style(v1) [RESEND/PATCH 2/6] USB: musb-gadget: fix bulk IN infinite hangs in double buffer case [RESEND/PATCH 3/6] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1 [RESEND/PATCH 4/6] USB: musb-gadget: fix DMA length for OUT transfer [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over [RESEND/PATCH 6/6] USB: musb-gadget: fix dma length in txstate thanks, Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCH 1/6] USB: musb-gadget: fix kernel panic if using out ep with FIFO_TXRX style(v1)
From: Ming Lei tom.leim...@gmail.com For shared fifo hw endpoint(with FIFO_TXRX style), only ep_in field of musb_hw_ep is intialized in musb_g_init_endpoints, and ep_out is not initialized, but musb_g_rx and rxstate may access ep_out field of musb_hw_ep by the method below: musb_ep = musb-endpoints[epnum].ep_out which can cause the kernel panic[1] below, this patch fixes the issue by getting 'musb_ep' from 'musb-endpoints[epnum].ep_in' for shared fifo endpoint. [1], kernel panic [r...@omap3evm /]# musb_interrupt 1583: ** IRQ peripheral usb0008 tx rx4000 musb_stage0_irq 460: == Power=f0, DevCtl=99, int_usb=0x8 musb_g_rx 772: == (null), rxcsr 4007 ffe8 musb_g_rx 786: iso overrun on ffe8 Unable to handle kernel NULL pointer dereference at virtual address 0008 pgd = c0004000 [0008] *pgd= Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/platform/musb_hdrc/usb1/usb_device/usbdev1.1/dev Modules linked in: g_zero CPU: 0Tainted: GW(2.6.35-rc6-gkh-wl+ #92) PC is at musb_g_rx+0xfc/0x2ec LR is at vprintk+0x3f4/0x458 pc : [c02c07a4]lr : [c006ccb0]psr: 2193 sp : c760bd78 ip : c03c9d70 fp : c760bdbc r10: r9 : fa0ab1e0 r8 : 000e r7 : c7e80158 r6 : ffe8 r5 : 0001 r4 : 4003 r3 : 00010003 r2 : c760bcd8 r1 : c03cd030 r0 : 002e Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8778c019 DAC: 0017 Process kmemleak (pid: 421, stack limit = 0xc760a2e8) Stack: (0xc760bd78 to 0xc760c000) bd60: ffe8 c04b1b58 bd80: ffe8 c7c01ac0 c7e80d24 c0084238 0001 0001 c7e80158 bda0: 000e 0008 0099 00f0 c760be04 c760bdc0 c02bcd68 c02c06b4 bdc0: 0099 0008 4000 c760bdd8 c03cc4f8 0002 c7e80158 bde0: c7d2e300 6193 c760a000 005c c760be24 c760be08 be00: c02bcecc c02bc1ac c7d2e300 c7d2e300 005c c760a000 c760be54 c760be28 be20: c00ad698 c02bce6c c7d2e300 c067c258 005c c067c294 0001 be40: c760a000 c760be74 c760be58 c00af984 c00ad5fc 005c be60: 0002 c760be8c c760be78 c0039080 c00af8d0 fa20 be80: c760beec c760be90 c0039b6c c003900c 0001 c7d1e240 bea0: c068bae8 6013 0001 c760beec bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 6013 c068bae8 bee0: c760bf24 c760bef0 c00ff7d0 c0064ec4 0001 c00ff700 bf00: c0087f00 6013 c0d76a70 c0e23795 0001 c760bf4c c760bf28 bf20: c00ffdd8 c00ff70c c068bb08 c068bae8 6013 c0100938 c068bb30 bf40: c760bf84 c760bf50 c010014c c00ffd84 0001 c01c 00012c00 bf60: c7c33f04 00012c00 c7c33f04 c0100938 c760bf9c c760bf88 bf80: c01009a8 c0100018 c760bfa8 c7c33f04 c760bff4 c760bfa0 c0088000 c0100944 bfa0: c760bf98 0001 dead4ead c08ba2bc bfc0: c049e7fa c0087f70 c760bfd0 c760bfd0 c7c33f04 c0087f70 bfe0: c006f5e8 0013 c760bff8 c006f5e8 c0087f7c 7f0004ff df2000ff Backtrace: [c02c06a8] (musb_g_rx+0x0/0x2ec) from [c02bcd68] (musb_interrupt+0xbc8/0xcc0) [c02bc1a0] (musb_interrupt+0x0/0xcc0) from [c02bcecc] (generic_interrupt+0x6c/0x84) [c02bce60] (generic_interrupt+0x0/0x84) from [c00ad698] (handle_IRQ_event+0xa8/0x1ec) r7:c760a000 r6:005c r5:c7d2e300 r4:c7d2e300 [c00ad5f0] (handle_IRQ_event+0x0/0x1ec) from [c00af984] (handle_level_irq+0xc0/0x13c) [c00af8c4] (handle_level_irq+0x0/0x13c) from [c0039080] (asm_do_IRQ+0x80/0xa0) r7:0002 r6: r5: r4:005c [c0039000] (asm_do_IRQ+0x0/0xa0) from [c0039b6c] (__irq_svc+0x4c/0xb4) Exception stack(0xc760be90 to 0xc760bed8) be80: 0001 c7d1e240 bea0: c068bae8 6013 0001 c760beec bec0: c0064ecc c760bed8 c00ff7d0 c003a0a8 6013 r5:fa20 r4: [c0064eb8] (sub_preempt_count+0x0/0x100) from [c00ff7d0] (find_and_get_object+0xd0/0x110) r5:c068bae8 r4: [c00ff700] (find_and_get_object+0x0/0x110) from [c00ffdd8] (scan_block+0x60/0x104) r8:0001 r7:c0e23795 r6:c0d76a70 r5:6013 r4: [c00ffd78] (scan_block+0x0/0x104) from [c010014c] (kmemleak_scan+0x140/0x484) [c01c] (kmemleak_scan+0x0/0x484) from [c01009a8] (kmemleak_scan_thread+0x70/0xcc) r8: r7:c0100938 r6: r5:c7c33f04 r4:00012c00 [c0100938] (kmemleak_scan_thread+0x0/0xcc) from [c0088000] (kthread+0x90/0x98) r5:c7c33f04 r4:c760bfa8 [c0087f70] (kthread+0x0/0x98) from [c006f5e8] (do_exit+0x0/0x684) r7:0013 r6:c006f5e8 r5:c0087f70 r4:c7c33f04 Code: e3002312 e58d6000 e2833e16 eb0422d5 (e5963020) ---[ end trace f3d5e96f75c297b7 ]--- Signed-off-by: Ming Lei tom.leim...@gmail.com Reviewed-by: Sergei Shtylyov sshtyl...@mvista.com Cc: David Brownell
[RESEND/PATCH 2/6] USB: musb-gadget: fix bulk IN infinite hangs in double buffer case
From: Ming Lei tom.leim...@gmail.com
This patch fixes one infinite hang of bulk IN transfer in double buffer
case, the hang can be observed easily by test #6 of usbtest if musb is
configured as g_zero and fifo mode 3 is taken to enable double fifo.
In fact, the patch only removes the check for non-empty fifo before
loading data from new request into fifo since the check is not correct:
-in double buffer case, fifo may accommodate more than one packet,
even though it has contained one packet already and is non-empty
-since last DMA is completed before calling musb_g_tx, it is sure
that fifo may accommodate at least one packet
Without applying the patch, new requst enqueued from .complte may not
have a chance to be loaded into fifo, then will never be completed and
cause infinite hangs.
With the patch, on my beagle B5, test#6(queued bulk in) can be passed and
test result may go beyond 33Mbyte/s if musb is configured as g_zero and
fifo mode 3 is taken, follows the test command:
#testusb -D DEV_NAME -c 1024 -t 6 -s 32768 -g 8 [1]
[1],
-source of testusb : tools/usb/testusb.c under linux kernel;
Signed-off-by: Ming Lei tom.leim...@gmail.com
Acked-by: Anand Gadiyar gadi...@ti.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
drivers/usb/musb/musb_gadget.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index de0ca90..f206c94 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -504,18 +504,6 @@ void musb_g_tx(struct musb *musb, u8 epnum)
/* ... or if not, then complete it. */
musb_g_giveback(musb_ep, request, 0);
- /*
-* Kickstart next transfer if appropriate;
-* the packet that just completed might not
-* be transmitted for hours or days.
-* REVISIT for double buffering...
-* FIXME revisit for stalls too...
-*/
- musb_ep_select(mbase, epnum);
- csr = musb_readw(epio, MUSB_TXCSR);
- if (csr MUSB_TXCSR_FIFONOTEMPTY)
- return;
-
request = musb_ep-desc ? next_request(musb_ep) : NULL;
if (!request) {
DBG(4, %s idle now\n,
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCH 3/6] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1
From: Ming Lei tom.leim...@gmail.com This patch fixes one bugs of OUT transfer in double buffer case: -the current code only enable autoclear for dma mode 1, and not for dma mode 0 Without this patch, test #5 of usbtest can't be passed if we configure musb as g_zero and use fifo mode 3 to enable double buffer mode. With this patch and the following patch(fix dma length), on my beagle B5, test#5(queued bulk out) may go beyond 18Mbyte/s(seems dma mode 0 is quicker in double buffer case) if musb is configured as g_zero and fifo mode 3 is taken, follows the test command: #./testusb -D DEV_NAME -c 1024 -t 5 -s 32768 -g 8 [1] Also I have tested this patch can't make g_ether broken. [1],source of testusb : tools/usb/testusb.c under linux kernel; Signed-off-by: Ming Lei tom.leim...@gmail.com Cc: David Brownell dbrown...@users.sourceforge.net Cc: Felipe Balbi m...@felipebalbi.com Cc: Anand Gadiyar gadi...@ti.com Cc: Mike Frysinger vap...@gentoo.org Cc: Sergei Shtylyov sshtyl...@ru.mvista.com --- drivers/usb/musb/musb_gadget.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index f206c94..176e127 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -643,8 +643,8 @@ static void rxstate(struct musb *musb, struct musb_request *req) */ csr |= MUSB_RXCSR_DMAENAB; -#ifdef USE_MODE1 csr |= MUSB_RXCSR_AUTOCLEAR; +#ifdef USE_MODE1 /* csr |= MUSB_RXCSR_DMAMODE; */ /* this special sequence (enabling and then -- 1.6.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCH 4/6] USB: musb-gadget: fix DMA length for OUT transfer
From: Ming Lei tom.leim...@gmail.com
DMA length should not go beyond the availabe space of request buffer,
so fix it.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Acked-by: Anand Gadiyar gadi...@ti.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
drivers/usb/musb/musb_gadget.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 176e127..f3ee04f 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -659,10 +659,11 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (request-actual request-length) {
int transfer_size = 0;
#ifdef USE_MODE1
- transfer_size = min(request-length,
+ transfer_size = min(request-length -
request-actual,
channel-max_len);
#else
- transfer_size = len;
+ transfer_size = min(request-length -
request-actual,
+ (unsigned)len);
#endif
if (transfer_size = musb_ep-packet_sz)
musb_ep-dma-desired_mode = 0;
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over
From: Ming Lei tom.leim...@gmail.com
Complete the current request only if the data transfer is over.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
drivers/usb/musb/musb_gadget.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f3ee04f..fa826f9 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -501,14 +501,14 @@ void musb_g_tx(struct musb *musb, u8 epnum)
request-zero = 0;
}
- /* ... or if not, then complete it. */
- musb_g_giveback(musb_ep, request, 0);
-
- request = musb_ep-desc ? next_request(musb_ep) : NULL;
- if (!request) {
- DBG(4, %s idle now\n,
- musb_ep-end_point.name);
- return;
+ if (request-actual == request-length) {
+ musb_g_giveback(musb_ep, request, 0);
+ request = musb_ep-desc ? next_request(musb_ep)
: NULL;
+ if (!request) {
+ DBG(4, %s idle now\n,
+ musb_ep-end_point.name);
+ return;
+ }
}
}
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND/PATCH 6/6] USB: musb-gadget: fix dma length in txstate
From: Ming Lei tom.leim...@gmail.com
DMA length should not go beyond the availabe space of request buffer,
so fix it.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
drivers/usb/musb/musb_gadget.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index fa826f9..cacae96 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -300,6 +300,11 @@ static void txstate(struct musb *musb, struct musb_request
*req)
#ifndefCONFIG_MUSB_PIO_ONLY
if (is_dma_capable() musb_ep-dma) {
struct dma_controller *c = musb-dma_controller;
+ size_t request_size;
+
+ /* setup DMA, then program endpoint CSR */
+ request_size = min_t(size_t, request-length - request-actual,
+ musb_ep-dma-max_len);
use_dma = (request-dma != DMA_ADDR_INVALID);
@@ -307,11 +312,6 @@ static void txstate(struct musb *musb, struct musb_request
*req)
#ifdef CONFIG_USB_INVENTRA_DMA
{
- size_t request_size;
-
- /* setup DMA, then program endpoint CSR */
- request_size = min_t(size_t, request-length,
- musb_ep-dma-max_len);
if (request_size musb_ep-packet_sz)
musb_ep-dma-desired_mode = 0;
else
@@ -373,8 +373,8 @@ static void txstate(struct musb *musb, struct musb_request
*req)
use_dma = use_dma c-channel_program(
musb_ep-dma, musb_ep-packet_sz,
0,
- request-dma,
- request-length);
+ request-dma + request-actual,
+ request_size);
if (!use_dma) {
c-channel_release(musb_ep-dma);
musb_ep-dma = NULL;
@@ -386,8 +386,8 @@ static void txstate(struct musb *musb, struct musb_request
*req)
use_dma = use_dma c-channel_program(
musb_ep-dma, musb_ep-packet_sz,
request-zero,
- request-dma,
- request-length);
+ request-dma + request-actual,
+ request_size);
#endif
}
#endif
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
2010/9/7 venki kaps venkiece2...@gmail.com: thanks for your good response. Venkii, On Tue, Sep 7, 2010 at 6:54 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. Yes, this patch i have applied. If you applied the patch, I guess you may see __twl4030_phy_power(twl, 0) is called from .probe. If called, seems your description a little contradictory since you observed __twl4030_phy_power(twl, 0) may hit proper values, right? If not called, could you trace the return value of twl4030_usb_linkstat in twl4030_usb_phy_init? thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
Venkii, On Tue, Sep 7, 2010 at 9:10 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: thanks for your good response. Venkii, On Tue, Sep 7, 2010 at 6:54 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. Yes, this patch i have applied. If you applied the patch, I guess you may see __twl4030_phy_power(twl, 0) is called from .probe. If called, seems your description a little contradictory since you observed __twl4030_phy_power(twl, 0) may hit proper values, right? Yes, __twl4030_phy_power(twl, 0) - the current values are getting proper with or without cable. If not called, could you trace the return value of twl4030_usb_linkstat in twl4030_usb_phy_init? ok, i can do that and update. thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
Venkii, On Tue, Sep 7, 2010 at 9:18 PM, venki kaps venkiece2...@gmail.com wrote: Venkii, On Tue, Sep 7, 2010 at 9:10 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: thanks for your good response. Venkii, On Tue, Sep 7, 2010 at 6:54 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. Yes, this patch i have applied. If you applied the patch, I guess you may see __twl4030_phy_power(twl, 0) is called from .probe. If called, seems your description a little contradictory since you observed __twl4030_phy_power(twl, 0) may hit proper values, right? Yes, __twl4030_phy_power(twl, 0) - the current values are getting proper with or without cable. If not called, could you trace the return value of twl4030_usb_linkstat in twl4030_usb_phy_init? ok, i can do that and update. twl4030_usb_linkstat return value is zero (0) in both twl4030_usb_phy_init/twl4030_usb_irq. thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
2010/9/7 Santosh Shilimkar santosh.shilim...@ti.com: This series is just repost adding Catalin's ack to the patches and combining Thomas's two rebased kexec patches. It's generated against the mainline 2.6.36-rc3 + Catalin's [PATCH 0/9] Various patches for 2.6.37-rc1 series. Santosh Shilimkar (4): omap4: l2x0: Override the default l2x0_disable ARM: l2x0: Fix coding-style in the cache-l2x0.h ARM: l2x0: Determine the cache size ARM: l2x0: Optimise the range based operations Thomas Gleixner (2): arm: Disable outer (L2) cache in kexec arm: Implement l2x0 cache disable functions FWIW: Acked-by: Linus Walleij linus.wall...@stericsson.com Can you also include the patch by Per Fransson I sent off to Thomas and the list just a few days ago with the subject [PATCH] ARM: ux500 specific L2 cache code in this patch series? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
Venkii, On Tue, Sep 7, 2010 at 11:45 PM, venki kaps venkiece2...@gmail.com wrote: Venkii, On Tue, Sep 7, 2010 at 9:18 PM, venki kaps venkiece2...@gmail.com wrote: Venkii, On Tue, Sep 7, 2010 at 9:10 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: thanks for your good response. Venkii, On Tue, Sep 7, 2010 at 6:54 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. Yes, this patch i have applied. If you applied the patch, I guess you may see __twl4030_phy_power(twl, 0) is called from .probe. If called, seems your description a little contradictory since you observed __twl4030_phy_power(twl, 0) may hit proper values, right? Yes, __twl4030_phy_power(twl, 0) - the current values are getting proper with or without cable. If not called, could you trace the return value of twl4030_usb_linkstat in twl4030_usb_phy_init? ok, i can do that and update. twl4030_usb_linkstat return value is zero (0) in both twl4030_usb_phy_init/twl4030_usb_irq. WIth twl4030_usb_phy_init, Everything is fine except battery temperature but surprisingly the temperature is fine with PC based usb cable charger and the problem is with travel adapter only. thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
This patch exports some of the gpmc driver functions in OMAP3. The purpose
behind this patch
is to allow device drivers compiled as loadable modules to be interfaced to the
GPMC. I am
hoping that Tony is the correct maintainer and willing to ACK this change.
Please let me know
if there are any issues or concerns with this patch.
Thanks,
David
Signed-off-by: David Cross david.cr...@cypress.com
diff -uprN -X linux-next-vanilla/Documentation/dontdiff
linux-next-vanilla/arch/arm/mach-omap2/gpmc.c
linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
--- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31
19:32:51.0 -0700
+++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01
16:10:21.0 -0700
@@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_write_reg);
u32 gpmc_cs_read_reg(int cs, int idx)
{
@@ -141,6 +142,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_read_reg);
/* TODO: Add support for gpmc_fck to clock framework and use it */
unsigned long gpmc_get_fclk_period(void)
@@ -294,6 +296,7 @@ int gpmc_cs_set_timings(int cs, const st
return 0;
}
+EXPORT_SYMBOL(gpmc_cs_set_timings);
static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
{
---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/10] split out emac cpdma and mdio for reuse
Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine. These hardware modules are not restricted to EMAC device alone. For example, CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules internally. This patch series separates out EMAC's MDIO and CPDMA functionality, allowing these individual pieces to be reused across TI hardware. This patch series has been broadly organized as follows: MDIO: - Add new functionality netdev: separate out davinci mdio controller code - Hookup new functionality davinci: add mdio platform devices omap: add mdio platform devices netdev: switch davinci emac to new mdio driver - Cleanup left over cruft davinci: cleanup unused davinci mdio arch code omap: cleanup unused davinci mdio arch code netdev: cleanup unused davinci mdio emac code CPDMA: - Add new functionality netdev: separate out davinci cpdma controller code - Hookup new functionality netdev: switch davinci emac to new cpdma layer - Cleanup left over cruft netdev: cleanup unused davinci emac cpdma code This series has been tested on dm365 and tnetv107x (with additional cpsw patches) hardware. Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Changes from v1: 1. Fixed memory leak in cpdma_chan_create() failure case 2. Included new omap patches for am3517, avoids build breakage Changes from v2: 1. Updated series to include mityomapl138 board 2. Minor white-space fixes Cyril Chemparathy (10): net: davinci_emac: separate out davinci mdio davinci: add mdio platform devices omap: add mdio platform devices net: davinci_emac: switch to new mdio davinci: cleanup unused davinci mdio arch code omap: cleanup unused davinci mdio arch code net: davinci_emac: cleanup unused mdio emac code net: davinci_emac: separate out cpdma code net: davinci_emac: switch to new cpdma layer net: davinci_emac: cleanup unused cpdma code arch/arm/mach-davinci/board-da830-evm.c |5 - arch/arm/mach-davinci/board-da850-evm.c |6 - arch/arm/mach-davinci/board-dm365-evm.c |7 - arch/arm/mach-davinci/board-dm644x-evm.c|7 - arch/arm/mach-davinci/board-dm646x-evm.c|8 - arch/arm/mach-davinci/board-mityomapl138.c |7 - arch/arm/mach-davinci/board-neuros-osd2.c |7 - arch/arm/mach-davinci/board-sffsdr.c|7 - arch/arm/mach-davinci/devices-da8xx.c | 31 +- arch/arm/mach-davinci/dm365.c | 23 +- arch/arm/mach-davinci/dm644x.c | 23 +- arch/arm/mach-davinci/dm646x.c | 22 +- arch/arm/mach-davinci/include/mach/dm365.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- arch/arm/mach-davinci/include/mach/dm646x.h |2 +- arch/arm/mach-omap2/board-am3517evm.c | 31 +- drivers/net/Kconfig | 21 + drivers/net/Makefile|2 + drivers/net/davinci_cpdma.c | 837 + drivers/net/davinci_cpdma.h | 105 +++ drivers/net/davinci_emac.c | 1325 --- drivers/net/davinci_mdio.c | 386 include/linux/davinci_emac.h|8 +- 23 files changed, 1635 insertions(+), 1239 deletions(-) create mode 100644 drivers/net/davinci_cpdma.c create mode 100644 drivers/net/davinci_cpdma.h create mode 100644 drivers/net/davinci_mdio.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/10] omap: add mdio platform devices
This patch adds mdio platform devices on SoCs that have the necessary
hardware. Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock. Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
arch/arm/mach-omap2/board-am3517evm.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 4d0f585..5dd1b73 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
+#include linux/clk.h
#include linux/platform_device.h
#include linux/gpio.h
#include linux/i2c/pca953x.h
@@ -41,6 +42,27 @@
#define AM35XX_EVM_PHY_MASK(0xF)
#define AM35XX_EVM_MDIO_FREQUENCY (100)
+static struct mdio_platform_data am3517_evm_mdio_pdata = {
+ .bus_freq = AM35XX_EVM_MDIO_FREQUENCY,
+};
+
+static struct resource am3517_mdio_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+ .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device am3517_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(am3517_mdio_resources),
+ .resource = am3517_mdio_resources,
+ .dev.platform_data = am3517_evm_mdio_pdata,
+};
+
static struct emac_platform_data am3517_evm_emac_pdata = {
.phy_mask = AM35XX_EVM_PHY_MASK,
.mdio_max_freq = AM35XX_EVM_MDIO_FREQUENCY,
@@ -50,7 +72,7 @@ static struct emac_platform_data am3517_evm_emac_pdata = {
static struct resource am3517_emac_resources[] = {
{
.start = AM35XX_IPSS_EMAC_BASE,
- .end= AM35XX_IPSS_EMAC_BASE + 0x3,
+ .end= AM35XX_IPSS_EMAC_BASE + 0x2,
.flags = IORESOURCE_MEM,
},
{
@@ -121,6 +143,9 @@ void am3517_evm_ethernet_init(struct emac_platform_data
*pdata)
pdata-interrupt_disable= am3517_disable_ethernet_int;
am3517_emac_device.dev.platform_data= pdata;
platform_device_register(am3517_emac_device);
+ platform_device_register(am3517_mdio_device);
+ clk_add_alias(NULL, dev_name(am3517_mdio_device.dev),
+ NULL, am3517_emac_device.dev);
regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
regval = regval (~(AM35XX_CPGMACSS_SW_RST));
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/10] omap: cleanup unused davinci mdio arch code
This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
arch/arm/mach-omap2/board-am3517evm.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 5dd1b73..5225df6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -39,7 +39,6 @@
#include mux.h
-#define AM35XX_EVM_PHY_MASK(0xF)
#define AM35XX_EVM_MDIO_FREQUENCY (100)
static struct mdio_platform_data am3517_evm_mdio_pdata = {
@@ -64,8 +63,6 @@ static struct platform_device am3517_mdio_device = {
};
static struct emac_platform_data am3517_evm_emac_pdata = {
- .phy_mask = AM35XX_EVM_PHY_MASK,
- .mdio_max_freq = AM35XX_EVM_MDIO_FREQUENCY,
.rmii_en= 1,
};
@@ -135,7 +132,6 @@ void am3517_evm_ethernet_init(struct emac_platform_data
*pdata)
pdata-ctrl_reg_offset = AM35XX_EMAC_CNTRL_OFFSET;
pdata-ctrl_mod_reg_offset = AM35XX_EMAC_CNTRL_MOD_OFFSET;
pdata-ctrl_ram_offset = AM35XX_EMAC_CNTRL_RAM_OFFSET;
- pdata-mdio_reg_offset = AM35XX_EMAC_MDIO_OFFSET;
pdata-ctrl_ram_size= AM35XX_EMAC_CNTRL_RAM_SIZE;
pdata-version = EMAC_VERSION_2;
pdata-hw_ram_addr = AM35XX_EMAC_HW_RAM_ADDR;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/10] davinci: add mdio platform devices
This patch adds mdio platform devices on SoCs that have the necessary
hardware. Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock. Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
arch/arm/mach-davinci/devices-da8xx.c | 29 +-
arch/arm/mach-davinci/dm365.c | 22 +++-
arch/arm/mach-davinci/dm644x.c | 22 +++-
arch/arm/mach-davinci/dm646x.c | 21 ++-
arch/arm/mach-davinci/include/mach/dm365.h |1 +
arch/arm/mach-davinci/include/mach/dm644x.h |1 +
arch/arm/mach-davinci/include/mach/dm646x.h |1 +
7 files changed, 92 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index caeb7f4..9039221 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -352,7 +352,7 @@ int __init da8xx_register_watchdog(void)
static struct resource da8xx_emac_resources[] = {
{
.start = DA8XX_EMAC_CPPI_PORT_BASE,
- .end= DA8XX_EMAC_CPPI_PORT_BASE + 0x5000 - 1,
+ .end= DA8XX_EMAC_CPPI_PORT_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -396,9 +396,34 @@ static struct platform_device da8xx_emac_device = {
.resource = da8xx_emac_resources,
};
+static struct resource da8xx_mdio_resources[] = {
+ {
+ .start = DA8XX_EMAC_MDIO_BASE,
+ .end= DA8XX_EMAC_MDIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device da8xx_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(da8xx_mdio_resources),
+ .resource = da8xx_mdio_resources,
+};
+
int __init da8xx_register_emac(void)
{
- return platform_device_register(da8xx_emac_device);
+ int ret;
+
+ ret = platform_device_register(da8xx_mdio_device);
+ if (ret 0)
+ return ret;
+ ret = platform_device_register(da8xx_emac_device);
+ if (ret 0)
+ return ret;
+ ret = clk_add_alias(NULL, dev_name(da8xx_mdio_device.dev),
+ NULL, da8xx_emac_device.dev);
+ return ret;
}
static struct resource da830_mcasp1_resources[] = {
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 7781e35..0add1ca 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -699,7 +699,7 @@ static struct emac_platform_data dm365_emac_pdata = {
static struct resource dm365_emac_resources[] = {
{
.start = DM365_EMAC_BASE,
- .end= DM365_EMAC_BASE + 0x47ff,
+ .end= DM365_EMAC_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -734,6 +734,21 @@ static struct platform_device dm365_emac_device = {
.resource = dm365_emac_resources,
};
+static struct resource dm365_mdio_resources[] = {
+ {
+ .start = DM365_EMAC_MDIO_BASE,
+ .end= DM365_EMAC_MDIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_mdio_device = {
+ .name = davinci_mdio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_mdio_resources),
+ .resource = dm365_mdio_resources,
+};
+
static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_VDINT0]= 2,
[IRQ_VDINT1]= 6,
@@ -1219,7 +1234,12 @@ static int __init dm365_init_devices(void)
davinci_cfg_reg(DM365_INT_EDMA_CC);
platform_device_register(dm365_edma_device);
+
+ platform_device_register(dm365_mdio_device);
platform_device_register(dm365_emac_device);
+ clk_add_alias(NULL, dev_name(dm365_mdio_device.dev),
+ NULL, dm365_emac_device.dev);
+
/* Add isif clock alias */
clk_add_alias(master, dm365_isif_dev.name, vpss_master, NULL);
platform_device_register(dm365_vpss_device);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5e5b0a7..22166a5 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -330,7 +330,7 @@ static struct emac_platform_data dm644x_emac_pdata = {
static struct resource dm644x_emac_resources[] = {
{
.start = DM644X_EMAC_BASE,
- .end= DM644X_EMAC_BASE + 0x47ff,
+ .end= DM644X_EMAC_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -350,6 +350,21
[PATCH v3 09/10] net: davinci_emac: switch to new cpdma layer
This patch hooks up the emac driver with the newly separated cpdma driver.
Key differences introduced here:
- The old buffer list scheme is no longer required
- The original code maintained mac address per rx channel, even if only one
rx channel was being used. With this change, mac address is maintained
device wide. If support for multiple rx channels is added in future, this
will need to be reworked a bit.
- The new CPDMA code handles short packets better than before. The
earlier code was adjusting the length up, without ensuring that the tail
end of the padding was cleared - a possible security issue. This has been
fixed to use skb_padto().
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
drivers/net/davinci_emac.c | 232
1 files changed, 147 insertions(+), 85 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 036681a..4147d32 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -63,6 +63,8 @@
#include asm/irq.h
#include asm/page.h
+#include davinci_cpdma.h
+
static int debug_level;
module_param(debug_level, int, 0);
MODULE_PARM_DESC(debug_level, DaVinci EMAC debug level (NETIF_MSG bits));
@@ -113,6 +115,7 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_DEF_MAX_FRAME_SIZE(1500 + 14 + 4 + 4)
#define EMAC_DEF_TX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_CH (0) /* Default 0th channel */
+#define EMAC_DEF_RX_NUM_DESC (128)
#define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
#define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
#define EMAC_POLL_WEIGHT (64) /* Default NAPI poll weight */
@@ -460,6 +463,9 @@ struct emac_priv {
u32 hw_ram_addr;
struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
+ struct cpdma_ctlr *dma;
+ struct cpdma_chan *txchan;
+ struct cpdma_chan *rxchan;
u32 link; /* 1=link on, 0=link off */
u32 speed; /* 0=Auto Neg, 1=No PHY, 10,100, 1000 - mbps */
u32 duplex; /* Link duplex: 0=Half, 1=Full */
@@ -1151,6 +1157,57 @@ static irqreturn_t emac_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static struct sk_buff *emac_rx_alloc(struct emac_priv *priv)
+{
+ struct sk_buff *skb = dev_alloc_skb(priv-rx_buf_size);
+ if (WARN_ON(!skb))
+ return NULL;
+ skb-dev = priv-ndev;
+ skb_reserve(skb, NET_IP_ALIGN);
+ return skb;
+}
+
+static void emac_rx_handler(void *token, int len, int status)
+{
+ struct sk_buff *skb = token;
+ struct net_device *ndev = skb-dev;
+ struct emac_priv*priv = netdev_priv(ndev);
+ int ret;
+
+ if (status 0) {
+ /* error */
+ goto recycle;
+ }
+
+ skb_put(skb, len);
+ skb-protocol = eth_type_trans(skb, ndev);
+ netif_receive_skb(skb);
+ ndev-stats.rx_bytes += len;
+ ndev-stats.rx_packets++;
+
+ /* alloc a new packet for receive */
+ skb = emac_rx_alloc(priv);
+
+recycle:
+ if (skb) {
+ ret = cpdma_chan_submit(priv-rxchan, skb, skb-data,
+ skb_tailroom(skb), GFP_KERNEL);
+ WARN_ON(ret 0);
+ }
+}
+
+static void emac_tx_handler(void *token, int len, int status)
+{
+ struct sk_buff *skb = token;
+ struct net_device *ndev = skb-dev;
+
+ if (unlikely(netif_queue_stopped(ndev)))
+ netif_start_queue(ndev);
+ ndev-stats.tx_packets++;
+ ndev-stats.tx_bytes += len;
+ dev_kfree_skb_any(skb);
+}
+
/** EMAC on-chip buffer descriptor memory
*
* WARNING: Please note that the on chip memory is used for both TX and RX
@@ -1532,42 +1589,36 @@ static int emac_dev_xmit(struct sk_buff *skb, struct
net_device *ndev)
{
struct device *emac_dev = ndev-dev;
int ret_code;
- struct emac_netbufobj tx_buf; /* buffer obj-only single frame support */
- struct emac_netpktobj tx_packet; /* packet object */
struct emac_priv *priv = netdev_priv(ndev);
/* If no link, return */
if (unlikely(!priv-link)) {
if (netif_msg_tx_err(priv) net_ratelimit())
dev_err(emac_dev, DaVinci EMAC: No link to transmit);
- return NETDEV_TX_BUSY;
+ goto fail_tx;
}
- /* Build the buffer and packet objects - Since only single fragment is
-* supported, need not set length and token in both packet object.
-* Doing so for completeness sake to show that this needs to be done
-* in multifragment case
-*/
- tx_packet.buf_list = tx_buf;
-
[PATCH v3 10/10] net: davinci_emac: cleanup unused cpdma code
Having switched over to the newly introduced cpdma layer, this patch now
removes a whole bunch of code that is now unused. This patch has been
maintained separate strictly for reasons of readability.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
drivers/net/davinci_emac.c | 930
1 files changed, 0 insertions(+), 930 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 4147d32..525b84c 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -127,7 +127,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
/* EMAC register related defines */
#define EMAC_ALL_MULTI_REG_VALUE (0x)
#define EMAC_NUM_MULTICAST_BITS(64)
-#define EMAC_TEARDOWN_VALUE(0xFFFC)
#define EMAC_TX_CONTROL_TX_ENABLE_VAL (0x1)
#define EMAC_RX_CONTROL_RX_ENABLE_VAL (0x1)
#define EMAC_MAC_HOST_ERR_INTMASK_VAL (0x2)
@@ -214,24 +213,10 @@ static const char emac_version_string[] = TI DaVinci
EMAC Linux v6.1;
#define EMAC_DEF_MAX_MULTICAST_ADDRESSES (64) /* Max mcast addr's */
/* EMAC Peripheral Device Register Memory Layout structure */
-#define EMAC_TXIDVER 0x0
-#define EMAC_TXCONTROL 0x4
-#define EMAC_TXTEARDOWN0x8
-#define EMAC_RXIDVER 0x10
-#define EMAC_RXCONTROL 0x14
-#define EMAC_RXTEARDOWN0x18
-#define EMAC_TXINTSTATRAW 0x80
-#define EMAC_TXINTSTATMASKED 0x84
-#define EMAC_TXINTMASKSET 0x88
-#define EMAC_TXINTMASKCLEAR0x8C
#define EMAC_MACINVECTOR 0x90
#define EMAC_DM646X_MACEOIVECTOR 0x94
-#define EMAC_RXINTSTATRAW 0xA0
-#define EMAC_RXINTSTATMASKED 0xA4
-#define EMAC_RXINTMASKSET 0xA8
-#define EMAC_RXINTMASKCLEAR0xAC
#define EMAC_MACINTSTATRAW 0xB0
#define EMAC_MACINTSTATMASKED 0xB4
#define EMAC_MACINTMASKSET 0xB8
@@ -258,12 +243,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_MACADDRHI 0x504
#define EMAC_MACINDEX 0x508
-/* EMAC HDP and Completion registors */
-#define EMAC_TXHDP(ch) (0x600 + (ch * 4))
-#define EMAC_RXHDP(ch) (0x620 + (ch * 4))
-#define EMAC_TXCP(ch) (0x640 + (ch * 4))
-#define EMAC_RXCP(ch) (0x660 + (ch * 4))
-
/* EMAC statistics registers */
#define EMAC_RXGOODFRAMES 0x200
#define EMAC_RXBCASTFRAMES 0x204
@@ -328,120 +307,6 @@ static const char emac_version_string[] = TI DaVinci
EMAC Linux v6.1;
/* EMAC Stats Clear Mask */
#define EMAC_STATS_CLR_MASK(0x)
-/** net_buf_obj: EMAC network bufferdata structure
- *
- * EMAC network buffer data structure
- */
-struct emac_netbufobj {
- void *buf_token;
- char *data_ptr;
- int length;
-};
-
-/** net_pkt_obj: EMAC network packet data structure
- *
- * EMAC network packet data structure - supports buffer list (for future)
- */
-struct emac_netpktobj {
- void *pkt_token; /* data token may hold tx/rx chan id */
- struct emac_netbufobj *buf_list; /* array of network buffer objects */
- int num_bufs;
- int pkt_length;
-};
-
-/** emac_tx_bd: EMAC TX Buffer descriptor data structure
- *
- * EMAC TX Buffer descriptor data structure
- */
-struct emac_tx_bd {
- int h_next;
- int buff_ptr;
- int off_b_len;
- int mode; /* SOP, EOP, ownership, EOQ, teardown,Qstarv, length */
- struct emac_tx_bd __iomem *next;
- void *buf_token;
-};
-
-/** emac_txch: EMAC TX Channel data structure
- *
- * EMAC TX Channel data structure
- */
-struct emac_txch {
- /* Config related */
- u32 num_bd;
- u32 service_max;
-
- /* CPPI specific */
- u32 alloc_size;
- void __iomem *bd_mem;
- struct emac_tx_bd __iomem *bd_pool_head;
- struct emac_tx_bd __iomem *active_queue_head;
- struct emac_tx_bd __iomem *active_queue_tail;
- struct emac_tx_bd __iomem *last_hw_bdprocessed;
- u32 queue_active;
- u32 teardown_pending;
- u32 *tx_complete;
-
- /** statistics */
- u32 proc_count; /* TX: # of times emac_tx_bdproc is called */
- u32 mis_queued_packets;
- u32 queue_reinit;
- u32 end_of_queue_add;
- u32 out_of_tx_bd;
- u32 no_active_pkts; /* IRQ when there were no packets to process */
- u32 active_queue_count;
-};
-
-/** emac_rx_bd: EMAC RX Buffer descriptor data structure
- *
- * EMAC RX Buffer descriptor data structure
- */
-struct emac_rx_bd {
- int h_next;
- int buff_ptr;
- int off_b_len;
- int mode;
- struct emac_rx_bd __iomem *next;
- void *data_ptr;
- void *buf_token;
-};
-
-/** emac_rxch: EMAC RX Channel data structure
- *
- * EMAC RX Channel data structure
- */
-struct emac_rxch {
- /* configuration info */
- u32 num_bd;
- u32 service_max;
- u32 buf_size;
-
[PATCH v3 08/10] net: davinci_emac: separate out cpdma code
In addition to being embedded into the EMAC controller, the CPDMA hardware
block is used in TI's CPSW switch controller. Fortunately, the programming
interface to this hardware block remains pretty nicely consistent across these
devices.
This patch adds a new CPDMA services layer, which can then be reused across
EMAC and CPSW drivers.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
drivers/net/Kconfig | 10 +
drivers/net/Makefile|1 +
drivers/net/davinci_cpdma.c | 837 +++
drivers/net/davinci_cpdma.h | 105 ++
4 files changed, 953 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/davinci_cpdma.c
create mode 100644 drivers/net/davinci_cpdma.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 911e7f1..775fd87 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -952,6 +952,7 @@ config TI_DAVINCI_EMAC
tristate TI DaVinci EMAC Support
depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
select TI_DAVINCI_MDIO
+ select TI_DAVINCI_CPDMA
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
@@ -969,6 +970,15 @@ config TI_DAVINCI_MDIO
To compile this driver as a module, choose M here: the module
will be called davinci_mdio. This is recommended.
+config TI_DAVINCI_CPDMA
+ tristate TI DaVinci CPDMA Support
+ depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
+ help
+ This driver supports TI's DaVinci CPDMA dma engine.
+
+ To compile this driver as a module, choose M here: the module
+ will be called davinci_cpdma. This is recommended.
+
config DM9000
tristate DM9000 support
depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d38a7ab..65da885 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
+obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
new file mode 100644
index 000..ab7ecd7
--- /dev/null
+++ b/drivers/net/davinci_cpdma.c
@@ -0,0 +1,837 @@
+/*
+ * Texas Instruments CPDMA Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * 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.
+ */
+#include linux/kernel.h
+#include linux/spinlock.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/dma-mapping.h
+#include linux/io.h
+
+#include davinci_cpdma.h
+
+/* DMA Registers */
+#define CPDMA_TXIDVER 0x00
+#define CPDMA_TXCONTROL0x04
+#define CPDMA_TXTEARDOWN 0x08
+#define CPDMA_RXIDVER 0x10
+#define CPDMA_RXCONTROL0x14
+#define CPDMA_SOFTRESET0x1c
+#define CPDMA_RXTEARDOWN 0x18
+#define CPDMA_TXINTSTATRAW 0x80
+#define CPDMA_TXINTSTATMASKED 0x84
+#define CPDMA_TXINTMASKSET 0x88
+#define CPDMA_TXINTMASKCLEAR 0x8c
+#define CPDMA_MACINVECTOR 0x90
+#define CPDMA_MACEOIVECTOR 0x94
+#define CPDMA_RXINTSTATRAW 0xa0
+#define CPDMA_RXINTSTATMASKED 0xa4
+#define CPDMA_RXINTMASKSET 0xa8
+#define CPDMA_RXINTMASKCLEAR 0xac
+#define CPDMA_DMAINTSTATRAW0xb0
+#define CPDMA_DMAINTSTATMASKED 0xb4
+#define CPDMA_DMAINTMASKSET0xb8
+#define CPDMA_DMAINTMASKCLEAR 0xbc
+#define CPDMA_DMAINT_HOSTERR BIT(1)
+
+/* the following exist only if has_ext_regs is set */
+#define CPDMA_DMACONTROL 0x20
+#define CPDMA_DMASTATUS0x24
+#define CPDMA_RXBUFFOFS0x28
+#define CPDMA_EM_CONTROL 0x2c
+
+/* Descriptor mode bits */
+#define CPDMA_DESC_SOP BIT(31)
+#define CPDMA_DESC_EOP BIT(30)
+#define CPDMA_DESC_OWNER BIT(29)
+#define CPDMA_DESC_EOQ BIT(28)
+#define CPDMA_DESC_TD_COMPLETE BIT(27)
+#define CPDMA_DESC_PASS_CRCBIT(26)
+
+#define CPDMA_TEARDOWN_VALUE 0xfffc
+
+struct cpdma_desc {
+ /* hardware fields */
+ u32 hw_next;
+ u32 hw_buffer;
+ u32 hw_len;
+ u32 hw_mode;
+ /* software fields */
+ void*sw_token;
+ u32 sw_buffer;
+ u32 sw_len;
+};
+
+struct cpdma_desc_pool {
+ u32 phys;
+
[PATCH v3 07/10] net: davinci_emac: cleanup unused mdio emac code
This patch removes code that has been rendered useless by the previous patches
in this series.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
drivers/net/davinci_emac.c | 107 --
include/linux/davinci_emac.h |3 -
2 files changed, 0 insertions(+), 110 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 6ed779d..036681a 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -113,7 +113,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_DEF_MAX_FRAME_SIZE(1500 + 14 + 4 + 4)
#define EMAC_DEF_TX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_CH (0) /* Default 0th channel */
-#define EMAC_DEF_MDIO_TICK_MS (10) /* typically 1 tick=1 ms) */
#define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
#define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
#define EMAC_POLL_WEIGHT (64) /* Default NAPI poll weight */
@@ -303,25 +302,6 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.1;
#define EMAC_DM644X_INTMIN_INTVL 0x1
#define EMAC_DM644X_INTMAX_INTVL (EMAC_DM644X_EWINTCNT_MASK)
-/* EMAC MDIO related */
-/* Mask Control defines */
-#define MDIO_CONTROL_CLKDIV(0xFF)
-#define MDIO_CONTROL_ENABLEBIT(30)
-#define MDIO_USERACCESS_GO BIT(31)
-#define MDIO_USERACCESS_WRITE BIT(30)
-#define MDIO_USERACCESS_READ (0)
-#define MDIO_USERACCESS_REGADR (0x1F 21)
-#define MDIO_USERACCESS_PHYADR (0x1F 16)
-#define MDIO_USERACCESS_DATA (0x)
-#define MDIO_USERPHYSEL_LINKSELBIT(7)
-#define MDIO_VER_MODID (0x 16)
-#define MDIO_VER_REVMAJ(0xFF8)
-#define MDIO_VER_REVMIN(0xFF)
-
-#define MDIO_USERACCESS(inst) (0x80 + (inst * 8))
-#define MDIO_USERPHYSEL(inst) (0x84 + (inst * 8))
-#define MDIO_CONTROL (0x04)
-
/* EMAC DM646X control module registers */
#define EMAC_DM646X_CMINTCTRL 0x0C
#define EMAC_DM646X_CMRXINTEN 0x14
@@ -493,13 +473,6 @@ struct emac_priv {
u32 mac_hash2;
u32 multicast_hash_cnt[EMAC_NUM_MULTICAST_BITS];
u32 rx_addr_type;
- /* periodic timer required for MDIO polling */
- struct timer_list periodic_timer;
- u32 periodic_ticks;
- u32 timer_active;
- u32 phy_mask;
- /* mii_bus,phy members */
- struct mii_bus *mii_bus;
const char *phy_id;
struct phy_device *phydev;
spinlock_t lock;
@@ -511,7 +484,6 @@ struct emac_priv {
/* clock frequency for EMAC */
static struct clk *emac_clk;
static unsigned long emac_bus_frequency;
-static unsigned long mdio_max_freq;
#define emac_virt_to_phys(addr, priv) \
(((u32 __force)(addr) - (u32 __force)(priv-emac_ctrl_ram)) \
@@ -549,9 +521,6 @@ static char *emac_rxhost_errcodes[16] = {
#define emac_ctrl_read(reg) ioread32((priv-ctrl_base + (reg)))
#define emac_ctrl_write(reg, val) iowrite32(val, (priv-ctrl_base + (reg)))
-#define emac_mdio_read(reg) ioread32(bus-priv + (reg))
-#define emac_mdio_write(reg, val) iowrite32(val, (bus-priv + (reg)))
-
/**
* emac_dump_regs: Dump important EMAC registers to debug terminal
* @priv: The DaVinci EMAC private adapter structure
@@ -657,9 +626,6 @@ static void emac_dump_regs(struct emac_priv *priv)
emac_read(EMAC_RXDMAOVERRUNS));
}
-/*
- * EMAC MDIO/Phy Functionality
- */
/**
* emac_get_drvinfo: Get EMAC driver information
* @ndev: The DaVinci EMAC network adapter
@@ -2349,79 +2315,6 @@ void emac_poll_controller(struct net_device *ndev)
}
#endif
-/* PHY/MII bus related */
-
-/* Wait until mdio is ready for next command */
-#define MDIO_WAIT_FOR_USER_ACCESS\
- while ((emac_mdio_read((MDIO_USERACCESS(0))) \
- MDIO_USERACCESS_GO) != 0)
-
-static int emac_mii_read(struct mii_bus *bus, int phy_id, int phy_reg)
-{
- unsigned int phy_data = 0;
- unsigned int phy_control;
-
- /* Wait until mdio is ready for next command */
- MDIO_WAIT_FOR_USER_ACCESS;
-
- phy_control = (MDIO_USERACCESS_GO |
- MDIO_USERACCESS_READ |
- ((phy_reg 21) MDIO_USERACCESS_REGADR) |
- ((phy_id 16) MDIO_USERACCESS_PHYADR) |
- (phy_data MDIO_USERACCESS_DATA));
- emac_mdio_write(MDIO_USERACCESS(0), phy_control);
-
- /* Wait until mdio is ready for next command */
- MDIO_WAIT_FOR_USER_ACCESS;
-
- return emac_mdio_read(MDIO_USERACCESS(0)) MDIO_USERACCESS_DATA;
-
-}
-
-static int emac_mii_write(struct mii_bus *bus, int phy_id,
- int phy_reg, u16 phy_data)
-{
-
-
[PATCH v3 04/10] net: davinci_emac: switch to new mdio
This patch switches the emac implementation over to the newly separated
MDIO driver.
With this, the mdio bus frequency defaults to a safe 2.2MHz. Boards may
optionally specify a bus frequency via platform data.
The phy identification scheme has been modified to use a phy bus id instead
of a mask. This largely serves to eliminate the phy search code in emac
init.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
drivers/net/Kconfig |1 +
drivers/net/davinci_emac.c | 88 ++---
include/linux/davinci_emac.h |1 +
3 files changed, 32 insertions(+), 58 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c5c86e0..911e7f1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -951,6 +951,7 @@ config NET_NETX
config TI_DAVINCI_EMAC
tristate TI DaVinci EMAC Support
depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
+ select TI_DAVINCI_MDIO
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 7fbd052..6ed779d 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -500,6 +500,7 @@ struct emac_priv {
u32 phy_mask;
/* mii_bus,phy members */
struct mii_bus *mii_bus;
+ const char *phy_id;
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -686,7 +687,7 @@ static int emac_get_settings(struct net_device *ndev,
struct ethtool_cmd *ecmd)
{
struct emac_priv *priv = netdev_priv(ndev);
- if (priv-phy_mask)
+ if (priv-phydev)
return phy_ethtool_gset(priv-phydev, ecmd);
else
return -EOPNOTSUPP;
@@ -704,7 +705,7 @@ static int emac_get_settings(struct net_device *ndev,
static int emac_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
{
struct emac_priv *priv = netdev_priv(ndev);
- if (priv-phy_mask)
+ if (priv-phydev)
return phy_ethtool_sset(priv-phydev, ecmd);
else
return -EOPNOTSUPP;
@@ -841,7 +842,7 @@ static void emac_update_phystatus(struct emac_priv *priv)
mac_control = emac_read(EMAC_MACCONTROL);
cur_duplex = (mac_control EMAC_MACCONTROL_FULLDUPLEXEN) ?
DUPLEX_FULL : DUPLEX_HALF;
- if (priv-phy_mask)
+ if (priv-phydev)
new_duplex = priv-phydev-duplex;
else
new_duplex = DUPLEX_FULL;
@@ -2485,6 +2486,11 @@ static int emac_devioctl(struct net_device *ndev, struct
ifreq *ifrq, int cmd)
return -EOPNOTSUPP;
}
+static int match_first_device(struct device *dev, void *data)
+{
+ return 1;
+}
+
/**
* emac_dev_open: EMAC device open
* @ndev: The DaVinci EMAC network adapter
@@ -2499,7 +2505,6 @@ static int emac_dev_open(struct net_device *ndev)
{
struct device *emac_dev = ndev-dev;
u32 rc, cnt, ch;
- int phy_addr;
struct resource *res;
int q, m;
int i = 0;
@@ -2560,28 +2565,26 @@ static int emac_dev_open(struct net_device *ndev)
emac_set_coalesce(ndev, coal);
}
- /* find the first phy */
priv-phydev = NULL;
- if (priv-phy_mask) {
- emac_mii_reset(priv-mii_bus);
- for (phy_addr = 0; phy_addr PHY_MAX_ADDR; phy_addr++) {
- if (priv-mii_bus-phy_map[phy_addr]) {
- priv-phydev = priv-mii_bus-phy_map[phy_addr];
- break;
- }
- }
+ /* use the first phy on the bus if pdata did not give us a phy id */
+ if (!priv-phy_id) {
+ struct device *phy;
- if (!priv-phydev) {
- printk(KERN_ERR %s: no PHY found\n, ndev-name);
- return -1;
- }
+ phy = bus_find_device(mdio_bus_type, NULL, NULL,
+ match_first_device);
+ if (phy)
+ priv-phy_id = dev_name(phy);
+ }
- priv-phydev = phy_connect(ndev, dev_name(priv-phydev-dev),
- emac_adjust_link, 0, PHY_INTERFACE_MODE_MII);
+ if (priv-phy_id) {
+ priv-phydev = phy_connect(ndev, priv-phy_id,
+ emac_adjust_link, 0,
+ PHY_INTERFACE_MODE_MII);
if (IS_ERR(priv-phydev)) {
- printk(KERN_ERR %s: Could not attach to PHY\n,
- ndev-name);
+ dev_err(emac_dev, could not connect to phy %s\n,
+ priv-phy_id);
+ priv-phydev = NULL;
[PATCH v3 05/10] davinci: cleanup unused davinci mdio arch code
This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/board-da830-evm.c |5 -
arch/arm/mach-davinci/board-da850-evm.c |6 --
arch/arm/mach-davinci/board-dm365-evm.c |7 ---
arch/arm/mach-davinci/board-dm644x-evm.c|7 ---
arch/arm/mach-davinci/board-dm646x-evm.c|8
arch/arm/mach-davinci/board-mityomapl138.c |7 ---
arch/arm/mach-davinci/board-neuros-osd2.c |7 ---
arch/arm/mach-davinci/board-sffsdr.c|7 ---
arch/arm/mach-davinci/devices-da8xx.c |2 --
arch/arm/mach-davinci/dm365.c |1 -
arch/arm/mach-davinci/dm644x.c |1 -
arch/arm/mach-davinci/dm646x.c |1 -
arch/arm/mach-davinci/include/mach/dm365.h |1 -
arch/arm/mach-davinci/include/mach/dm644x.h |1 -
arch/arm/mach-davinci/include/mach/dm646x.h |1 -
15 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index ef1ab0b..2613324 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,9 +31,6 @@
#include mach/usb.h
#include mach/aemif.h
-#define DA830_EVM_PHY_MASK 0x0
-#define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
-
/*
* USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
*/
@@ -558,8 +555,6 @@ static __init void da830_evm_init(void)
da830_evm_usb_init();
- soc_info-emac_pdata-phy_mask = DA830_EVM_PHY_MASK;
- soc_info-emac_pdata-mdio_max_freq = DA830_EVM_MDIO_FREQUENCY;
soc_info-emac_pdata-rmii_en = 1;
ret = davinci_cfg_reg_list(da830_cpgmac_pins);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index ac2297c..9d4dfcb 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,9 +38,6 @@
#include mach/mux.h
#include mach/aemif.h
-#define DA850_EVM_PHY_MASK 0x1
-#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
-
#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
#define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15)
@@ -678,9 +675,6 @@ static int __init da850_evm_config_emac(void)
/* Enable/Disable MII MDIO clock */
gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
- soc_info-emac_pdata-phy_mask = DA850_EVM_PHY_MASK;
- soc_info-emac_pdata-mdio_max_freq = DA850_EVM_MDIO_FREQUENCY;
-
ret = da8xx_register_emac();
if (ret)
pr_warning(da850_evm_init: emac registration failed: %d\n,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 60c59dd..f697914 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -54,9 +54,6 @@ static inline int have_tvp7002(void)
return 0;
}
-#define DM365_EVM_PHY_MASK (0x2)
-#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
-
/*
* A MAX-II CPLD is used for various board control functions.
*/
@@ -530,16 +527,12 @@ fail:
/* externally mux MMC1/ENET/AIC33 to imager */
mux |= BIT(6) | BIT(5) | BIT(3);
} else {
- struct davinci_soc_info *soc_info = davinci_soc_info;
-
/* we can use MMC1 ... */
dm365evm_mmc_configure();
davinci_setup_mmc(1, dm365evm_mmc_config);
/* ... and ENET ... */
dm365evm_emac_configure();
- soc_info-emac_pdata-phy_mask = DM365_EVM_PHY_MASK;
- soc_info-emac_pdata-mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
resets = ~BIT(3);
/* ... and AIC33 */
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 65bb940..c86bf23 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -39,9 +39,6 @@
#include mach/usb.h
#include mach/aemif.h
-#define DM644X_EVM_PHY_MASK(0x2)
-#define DM644X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
-
#define LXT971_PHY_ID (0x001378e2)
#define LXT971_PHY_MASK(0xfff0)
@@ -672,7 +669,6 @@ static int davinci_phy_fixup(struct phy_device *phydev)
static __init void davinci_evm_init(void)
{
struct clk *aemif_clk;
- struct davinci_soc_info *soc_info = davinci_soc_info;
aemif_clk = clk_get(NULL, aemif);
clk_enable(aemif_clk);
@@ -707,9 +703,6 @@ static __init void davinci_evm_init(void)
davinci_serial_init(uart_config);
dm644x_init_asp(dm644x_evm_snd_data);
- soc_info-emac_pdata-phy_mask =
[PATCH v3 01/10] net: davinci_emac: separate out davinci mdio
Davinci's MDIO controller is present on other TI devices, without an
accompanying EMAC. For example, on tnetv107x, the same MDIO module is used in
conjunction with a 3-port switch hardware.
By separating the MDIO controller code into its own platform driver, this
patch allows common logic to be reused on such platforms.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
---
drivers/net/Kconfig | 10 +
drivers/net/Makefile |1 +
drivers/net/davinci_mdio.c | 386 ++
include/linux/davinci_emac.h |4 +
4 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/davinci_mdio.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2cc81a5..c5c86e0 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -958,6 +958,16 @@ config TI_DAVINCI_EMAC
To compile this driver as a module, choose M here: the module
will be called davinci_emac_driver. This is recommended.
+config TI_DAVINCI_MDIO
+ tristate TI DaVinci MDIO Support
+ depends on ARM ( ARCH_DAVINCI || ARCH_OMAP3 )
+ select PHYLIB
+ help
+ This driver supports TI's DaVinci MDIO module.
+
+ To compile this driver as a module, choose M here: the module
+ will be called davinci_mdio. This is recommended.
+
config DM9000
tristate DM9000 support
depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3e8f150..d38a7ab 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_MDIO) += mdio.o
obj-$(CONFIG_PHYLIB) += phy/
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
+obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
new file mode 100644
index 000..d34a53a
--- /dev/null
+++ b/drivers/net/davinci_mdio.c
@@ -0,0 +1,386 @@
+/*
+ * DaVinci MDIO Module driver
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Shamelessly ripped out of davinci_emac.c, original copyrights follow:
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * ---
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * ---
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/phy.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/davinci_emac.h
+
+#define PHY_REG_MASK 0x1f
+#define PHY_ID_MASK0x1f
+
+#define DEF_OUT_FREQ 220 /* 2.2 MHz */
+
+struct davinci_mdio_regs {
+ u32 version;
+ u32 control;
+#define CONTROL_IDLE BIT(31)
+#define CONTROL_ENABLE BIT(30)
+#define CONTROL_MAX_DIV(0xff)
+
+ u32 alive;
+ u32 link;
+ u32 linkintraw;
+ u32 linkintmasked;
+ u32 __reserved_0[2];
+ u32 userintraw;
+ u32 userintmasked;
+ u32 userintmaskset;
+ u32 userintmaskclr;
+ u32 __reserved_1[20];
+
+ struct {
+ u32 access;
+#define USERACCESS_GO BIT(31)
+#define USERACCESS_WRITE BIT(30)
+#define USERACCESS_ACK BIT(29)
+#define USERACCESS_READ(0)
+#define USERACCESS_DATA(0x)
+
+ u32 physel;
+ } user[0];
+};
+
+struct mdio_platform_data default_pdata = {
+ .bus_freq = DEF_OUT_FREQ,
+};
+
+struct davinci_mdio_data {
+ struct mdio_platform_data pdata;
+ struct davinci_mdio_regs __iomem *regs;
+ spinlock_t lock;
+ struct clk *clk;
+ struct device *dev;
+ struct mii_bus *bus;
+ boolsuspended;
+};
+
+/* wait until hardware is ready for another user access */
+static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
+{
+ struct davinci_mdio_regs __iomem *regs = data-regs;
+ u32 reg;
+
+ while ((reg =
Re: [PATCH v2 08/11] OMAP: DMA: Convert DMA library into DMA platform Driver
G, Manjunath Kondaiah manj...@ti.com writes: [...] diff --git a/arch/arm/mach-omap1/include/mach/dma.h b/arch/arm/mach-omap1/include/mach/dma.h index d446cdd..1eb0d31 100644 --- a/arch/arm/mach-omap1/include/mach/dma.h +++ b/arch/arm/mach-omap1/include/mach/dma.h @@ -77,4 +77,70 @@ #define OMAP1_DMA_CCR2(n) (0x40 * (n) + 0x24) #define OMAP1_DMA_LCH_CTRL(n) (0x40 * (n) + 0x2a) +/* Dummy defines to support multi omap code */ These should not be needed anymore as this is now an OMAP1-specific header. Because it is OMAP1 specific header, there are common API's used between omap1 and omap2 plus in plat-omap/dma.c which needs these defines otherwise build will break for omap1 since these defines exists omap2 specific header Which is in respective mach directory. OK, then the split you are proposing is not the right thing to do, or more likely, the split was not taken far enough. defines that are used in common code should be defined in a common header, rather than duplicating them in both omap1 and omap2+ code. When you find yourself putting OMAP1 defines in OMAP2+ code and vice versa, it should be an indication that there is still some abstraction missing in the split Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cpufreq for s3c2440 FriendlyArm
On 06/09/10 04:40, Marek Vasut wrote: Dne Ne 5. září 2010 22:30:00 tarek attia napsal(a): Hi all, Did anyone try the cpufreq on the mini2440 ? and did anyone get it working on the board ? Each time I do the configuration in the kernel I found nothing on the board ,however after the compilation I found the cpufreq.o pll.o but no file concerning that on the board . Any help will be appreciated. I believe you have the wrong mailing list here. LAK CCed. linux-arm-kernel is the right one. I've not tried on the mini2440, but it did work on other s3c2440 based machines. it may be there is a small bit of init missing for the mini2440 to get the cpufreq running. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote: This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know if there are any issues or concerns with this patch. Thanks, David Signed-off-by: David Cross david.cr...@cypress.com diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.0 -0700 +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c2010-09-01 16:10:21.0 -0700 @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx; __raw_writel(val, reg_addr); } +EXPORT_SYMBOL(gpmc_cs_write_reg); EXPORT_SYMBOL_GPL() perhaps? What about platforms that don't have this symbol, how will the driver build properly then? Shouldn't something like this be in a arch-neutral place in the kernel tree? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP2+: PM: initial runtime PM core support
From: Kevin Hilman khil...@ti.com
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.
In order to determine if a device is an omap_device, its parent device
is checked. All omap_devices have a new 'omap_bus' device as their
parent device, so checking for this parent is used to check for valid
omap_devices. If a device is an omap_device, then the appropriate
omap_device functions are called for it. If not, only the generic
runtime PM functions are called.
Device driver's -runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device. Driver's -runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver -runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)
OMAP4 build support from Rajendra Nayak rna...@ti.com.
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
NOTE: this depends on the driver core patch from me:
[PATCH v2] driver core: platform_bus: allow runtime override of dev_pm_ops
which Greg KH has queued now for 2.6.37:
http://marc.info/?l=linux-kernelm=128276582108006w=2
arch/arm/mach-omap2/Makefile |8 +++-
arch/arm/mach-omap2/pm_bus.c | 82 ++
2 files changed, 88 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..ba644c2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -50,13 +50,17 @@ obj-$(CONFIG_ARCH_OMAP2)+= sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
pm_bus.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o+= -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..e85aced
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,82 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, 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.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/mutex.h
+
+#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#ifdef CONFIG_PM_RUNTIME
+int omap_pm_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ int r, ret = 0;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ if (!ret dev-parent == omap_bus) {
+ r = omap_device_idle(pdev);
+ WARN_ON(r);
+ }
+
+ return ret;
+};
+
+int omap_pm_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ int r;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ if (dev-parent == omap_bus) {
+ r = omap_device_enable(pdev);
+ WARN_ON(r);
+ }
+
+ return pm_generic_runtime_resume(dev);
+};
+#endif /* CONFIG_PM_RUNTIME */
+
+static int __init omap_pm_runtime_init(void)
+{
+ const struct dev_pm_ops *pm;
+ struct dev_pm_ops *omap_pm;
+
+ pm = platform_bus_get_pm_ops();
+ if (!pm) {
+ pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+ if (!omap_pm) {
+ pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ omap_pm-runtime_suspend = omap_pm_runtime_suspend;
+ omap_pm-runtime_resume = omap_pm_runtime_resume;
+
+ platform_bus_set_pm_ops(omap_pm);
+
+ return 0;
+}
+core_initcall(omap_pm_runtime_init);
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 2/2] OMAP1: PM: add simple runtime PM layer to manage clocks
From: Kevin Hilman khil...@ti.com
On OMAP1, we do not have omap_device + omap_hwmod to manage the
device-specific idle, enable and shutdown. Instead, just
enable/disable device clocks automatically at the runtime PM level.
This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the runtime PM API to manage clocks.
OMAP1 compile fixes Manjunatha GK manj...@ti.com
Cc: Manjunatha GK manj...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/pm_bus.c | 98 ++
2 files changed, 99 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap1/pm_bus.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index facfaeb..9a304d8 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_OMAP_MPU_TIMER) += time.o
obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
# Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o
+obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
# DSP
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
new file mode 100644
index 000..c831348
--- /dev/null
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -0,0 +1,98 @@
+/*
+ * Runtime PM support code for OMAP1
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, 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.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/mutex.h
+#include linux/clk.h
+#include linux/err.h
+
+#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#ifdef CONFIG_PM_RUNTIME
+static int omap1_pm_runtime_suspend(struct device *dev)
+{
+ struct clk *iclk, *fclk;
+ int ret = 0;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ fclk = clk_get(dev, fck);
+ if (!IS_ERR(fclk)) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+
+ iclk = clk_get(dev, ick);
+ if (!IS_ERR(iclk)) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+
+ return 0;
+};
+
+static int omap1_pm_runtime_resume(struct device *dev)
+{
+ int ret = 0;
+ struct clk *iclk, *fclk;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ iclk = clk_get(dev, ick);
+ if (!IS_ERR(iclk)) {
+ clk_enable(iclk);
+ clk_put(iclk);
+ }
+
+ fclk = clk_get(dev, fck);
+ if (!IS_ERR(fclk)) {
+ clk_enable(fclk);
+ clk_put(fclk);
+ }
+
+ return pm_generic_runtime_resume(dev);
+};
+
+static int __init omap1_pm_runtime_init(void)
+{
+ const struct dev_pm_ops *pm;
+ struct dev_pm_ops *omap_pm;
+
+ pm = platform_bus_get_pm_ops();
+ if (!pm) {
+ pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+ if (!omap_pm) {
+ pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ omap_pm-runtime_suspend = omap1_pm_runtime_suspend;
+ omap_pm-runtime_resume = omap1_pm_runtime_resume;
+
+ platform_bus_set_pm_ops(omap_pm);
+
+ return 0;
+}
+core_initcall(omap1_pm_runtime_init);
+#endif /* CONFIG_PM_RUNTIME */
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] omap: add mdio platform devices
* Cyril Chemparathy cy...@ti.com [100907 13:17]: This patch adds mdio platform devices on SoCs that have the necessary hardware. Clock lookup entries (aliases) have also been added, so that the MDIO and EMAC drivers can independently enable/disable a shared underlying clock. Further, the EMAC MMR region has been split down into separate MDIO and EMAC regions. Signed-off-by: Cyril Chemparathy cy...@ti.com Acked-by: David S. Miller da...@davemloft.net Looks good to me from omap point of view: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/10] omap: cleanup unused davinci mdio arch code
* Cyril Chemparathy cy...@ti.com [100907 13:17]: This patch removes davinci architecture code that has now been rendered useless by the previous patches in the MDIO separation series. Signed-off-by: Cyril Chemparathy cy...@ti.com Acked-by: David S. Miller da...@davemloft.net This one too: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
Cyril Chemparathy cy...@ti.com writes: Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine. These hardware modules are not restricted to EMAC device alone. For example, CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules internally. This patch series separates out EMAC's MDIO and CPDMA functionality, allowing these individual pieces to be reused across TI hardware. OK, queuing this series for 2.6.37 in davinci-next. Kevin This patch series has been broadly organized as follows: MDIO: - Add new functionality netdev: separate out davinci mdio controller code - Hookup new functionality davinci: add mdio platform devices omap: add mdio platform devices netdev: switch davinci emac to new mdio driver - Cleanup left over cruft davinci: cleanup unused davinci mdio arch code omap: cleanup unused davinci mdio arch code netdev: cleanup unused davinci mdio emac code CPDMA: - Add new functionality netdev: separate out davinci cpdma controller code - Hookup new functionality netdev: switch davinci emac to new cpdma layer - Cleanup left over cruft netdev: cleanup unused davinci emac cpdma code This series has been tested on dm365 and tnetv107x (with additional cpsw patches) hardware. Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Changes from v1: 1. Fixed memory leak in cpdma_chan_create() failure case 2. Included new omap patches for am3517, avoids build breakage Changes from v2: 1. Updated series to include mityomapl138 board 2. Minor white-space fixes Cyril Chemparathy (10): net: davinci_emac: separate out davinci mdio davinci: add mdio platform devices omap: add mdio platform devices net: davinci_emac: switch to new mdio davinci: cleanup unused davinci mdio arch code omap: cleanup unused davinci mdio arch code net: davinci_emac: cleanup unused mdio emac code net: davinci_emac: separate out cpdma code net: davinci_emac: switch to new cpdma layer net: davinci_emac: cleanup unused cpdma code arch/arm/mach-davinci/board-da830-evm.c |5 - arch/arm/mach-davinci/board-da850-evm.c |6 - arch/arm/mach-davinci/board-dm365-evm.c |7 - arch/arm/mach-davinci/board-dm644x-evm.c|7 - arch/arm/mach-davinci/board-dm646x-evm.c|8 - arch/arm/mach-davinci/board-mityomapl138.c |7 - arch/arm/mach-davinci/board-neuros-osd2.c |7 - arch/arm/mach-davinci/board-sffsdr.c|7 - arch/arm/mach-davinci/devices-da8xx.c | 31 +- arch/arm/mach-davinci/dm365.c | 23 +- arch/arm/mach-davinci/dm644x.c | 23 +- arch/arm/mach-davinci/dm646x.c | 22 +- arch/arm/mach-davinci/include/mach/dm365.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- arch/arm/mach-davinci/include/mach/dm646x.h |2 +- arch/arm/mach-omap2/board-am3517evm.c | 31 +- drivers/net/Kconfig | 21 + drivers/net/Makefile|2 + drivers/net/davinci_cpdma.c | 837 + drivers/net/davinci_cpdma.h | 105 +++ drivers/net/davinci_emac.c | 1325 --- drivers/net/davinci_mdio.c | 386 include/linux/davinci_emac.h|8 +- 23 files changed, 1635 insertions(+), 1239 deletions(-) create mode 100644 drivers/net/davinci_cpdma.c create mode 100644 drivers/net/davinci_cpdma.h create mode 100644 drivers/net/davinci_mdio.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 08/11] OMAP: DMA: Convert DMA library into DMA platform Driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, September 08, 2010 4:15 AM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh Subject: Re: [PATCH v2 08/11] OMAP: DMA: Convert DMA library into DMA platform Driver G, Manjunath Kondaiah manj...@ti.com writes: [...] diff --git a/arch/arm/mach-omap1/include/mach/dma.h b/arch/arm/mach-omap1/include/mach/dma.h index d446cdd..1eb0d31 100644 --- a/arch/arm/mach-omap1/include/mach/dma.h +++ b/arch/arm/mach-omap1/include/mach/dma.h @@ -77,4 +77,70 @@ #define OMAP1_DMA_CCR2(n) (0x40 * (n) + 0x24) #define OMAP1_DMA_LCH_CTRL(n) (0x40 * (n) + 0x2a) +/* Dummy defines to support multi omap code */ These should not be needed anymore as this is now an OMAP1-specific header. Because it is OMAP1 specific header, there are common API's used between omap1 and omap2 plus in plat-omap/dma.c which needs these defines otherwise build will break for omap1 since these defines exists omap2 specific header Which is in respective mach directory. OK, then the split you are proposing is not the right thing to do, or more likely, the split was not taken far enough. defines that are used in common code should be defined in a common header, rather than duplicating them in both omap1 and omap2+ code. It cannot be moved to common header since it will have duplicated #defines (one from mach header and other one from common header. When you find yourself putting OMAP1 defines in OMAP2+ code and vice versa, it should be an indication that there is still some abstraction missing in the split These common API's use device attributes to differentiate between omap1 and omap2 plus code. If we want to eliminate this, we should move these api's to respective mach directory. In that case, both omap1 and omap2plus dma drivers will become separate drivers. The rationale behind spilit is, tried to common API's as for as possible in plat-oma dma and move omap1 and omap2plus specific code respectivem mach dma. -Manjunath-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 04/11] OMAP3: DMA: HWMOD: Add hwmod data structures
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, September 04, 2010 2:22 AM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 04/11] OMAP3: DMA: HWMOD: Add hwmod
data structures
Manjunatha GK manj...@ti.com writes:
This patch adds OMAP3 DMA hwmod structures.
[..]
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+ .name = dma,
+ .class = omap3xxx_dma_hwmod_class,
+ .mpu_irqs = omap3xxx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap3xxx_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+ .masters= omap3xxx_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
hmm, I see an ST_DMA bit in CM_IDLEST1_CORE for DMA.
Having this also masks the fact that you haven't filled out the
.prcm.omap2 fields of the hwmod, at least the idlest ones are needed
here.
Ok. I will introduce .prcm entries as:
.prcm = {
.omap2 = {
.prcm_reg_id= 1,
.module_bit = OMAP3430_ST_SDMA_SHIFT,
.module_offs= CORE_MOD,
.idlest_reg_id = 1,
.idlest_idle_bit= OMAP3430_ST_SDMA_SHIFT,
},
}
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
On 09/07/2010 09:18 PM, Kevin Hilman wrote: Cyril Chemparathy cy...@ti.com writes: Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine. These hardware modules are not restricted to EMAC device alone. For example, CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules internally. This patch series separates out EMAC's MDIO and CPDMA functionality, allowing these individual pieces to be reused across TI hardware. OK, queuing this series for 2.6.37 in davinci-next. So I just pulled this to test it out on a da850 based board (mitydspl138), and I'm having some problems. I'm hoping it's just operator error. I have a TI TLK100PHP PHY at address 0x3. The boot log shows: [snip] davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 davinci_mdio davinci_mdio.0: detected phy mask fff7 davinci_mdio.0: probed davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown [snip] and then in the init scripts, following udev population I get a Configuring network interfaces... and the boot process just hangs. I went back and did a menuconfig, I didn't see an option for TI PHY support, but shouldn't there be a generic PHY driver that defaults if one isn't matched? I do have TI DaVinci EMAC/MDIO/CPDMA support enabled under the Ethernet (10 or 100 Mbit). Anyway, I've only looked at this for about 15 minutes, and I was hoping anyone might point out something obvious. If there are hints anyone might have for debugging, I'd appreciate them as well. Or, if anyone has tested this with a da850 evm, that would point me to a problem in the board file. Thanks for any insight. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND/PATCH 0/6] USB: musb-gadget: bug fix
On Tue, Sep 07, 2010 at 11:23:28PM +0800, tom.leim...@gmail.com wrote: This patch set fixes two kinds of musb-gadget bug: -fix kernel panic if using out ep with FIFO_TXRX style -make double buffer mode usable, fix infinate hangs and buffer corrupt bug when using double buffer mode to do data transfer; now we can use musb double buffer reliably, so bootst performance about 30% compared with single buffer mode. [RESEND/PATCH 1/6] USB: musb-gadget: fix kernel panic if using out ep with FIFO_TXRX style(v1) [RESEND/PATCH 2/6] USB: musb-gadget: fix bulk IN infinite hangs in double buffer case [RESEND/PATCH 3/6] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1 [RESEND/PATCH 4/6] USB: musb-gadget: fix DMA length for OUT transfer [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over [RESEND/PATCH 6/6] USB: musb-gadget: fix dma length in txstate I seem to not have 1/6 here, did it get stuck somewhere? Anyway, I need Felipe's ack before I can accept these. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Tony Lindgren t...@atomide.com [100906 10:56]:
* Russell King - ARM Linux li...@arm.linux.org.uk [100906 03:36]:
Here's my latest patch (which is combined from two patches.)
Tony, could you follow up with patches for anything which is still
required - I think there's two things you've addressed which this
currently misses:
1. not initializing twd_base (I'm not convinced this is safe - rather
making smp_prepare_cpus() return early is probably a better idea.)
Looks like the omap spefific fix needed now is for the localtimer, and
that can be now checked with cpu_is_omap44xx() as Santosh suggested
earlier. Will post that shortly.
2. __flush_icache_all()
Note that (2) seems to be complicated by the instruction only being
available on ARMv7 and later.
This is still open and needs to be fixed somehow..
Then the following patch is needed to fix compile if CONFIG_SMP is not set.
Other than that, things are actually quite close to working. Will post
three more patches as a reply to this mail that allow me to boot to
shell with the same SMP kernel binary on omap2, 3 4 more or less.
Need to track down some .config file strangeness though tomorrow to
figure out what is causing the WARNING: at mm/percpu-vm.c:320 pcpu_alloc
messages again.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Tue, 7 Sep 2010 19:09:57 -0700
Subject: [PATCH] ARM: Fix smp_on_up compile when CONFIG_SMP is not set
Fix undefined reference to smp_init_cpus()
and error for the discarded section:
ld:arch/arm/kernel/vmlinux.lds:517: syntax error
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index fe94467..5a82c39 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -825,8 +825,10 @@ void __init setup_arch(char **cmdline_p)
paging_init(mdesc);
request_standard_resources(meminfo, mdesc);
+#ifdef CONFIG_SMP
if (is_smp())
smp_init_cpus();
+#endif
reserve_crashkernel();
cpu_init();
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 53cb57e..b721e8b 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -244,7 +244,7 @@ SECTIONS
DISCARDS
#ifndef CONFIG_SMP_ON_UP
- /DISCARD/ {
+ /DISCARD/ : {
*(.smpalt.init)
}
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: Check for is_smp for tlb_ops and cache_ops boardcast
This should not be needed when running on UP systems.
Additionally we will also get an undefined instruction on ARM cores
without the extended CPUID registers with CONFIG_SMP_ON_UP.
Also, we can now remove the is_smp() test from mmu.c.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 7de5aa5..7f4e663 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -7,17 +7,6 @@
#include asm/cputype.h
-/* all SMP configurations have the extended CPUID registers */
-static inline int tlb_ops_need_broadcast(void)
-{
- return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 2;
-}
-
-static inline int cache_ops_need_broadcast(void)
-{
- return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 1;
-}
-
/*
* Return true if we are running on a SMP platform
*/
@@ -33,4 +22,21 @@ static inline bool is_smp(void)
#endif
}
+/* all SMP configurations have the extended CPUID registers */
+static inline int tlb_ops_need_broadcast(void)
+{
+ if (!is_smp())
+ return 0;
+
+ return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 2;
+}
+
+static inline int cache_ops_need_broadcast(void)
+{
+ if (!is_smp())
+ return 0;
+
+ return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 1;
+}
+
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index a789320..34df905 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -800,7 +800,7 @@ static void __init sanity_check_meminfo(void)
* rather difficult.
*/
reason = with VIPT aliasing cache;
- } else if (is_smp() tlb_ops_need_broadcast()) {
+ } else if (tlb_ops_need_broadcast()) {
/*
* kmap_high needs to occasionally flush TLB entries,
* however, if the TLB entries need to be broadcast
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: Don't try to send IPI on UP systems with CONFIG_SMP
This is not needed on UP. Additionally with will cause issues when
booting CONFIG_SMP_ON_UP kernel on earlier ARM cores.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 401e38b..5facdbe 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -207,9 +207,7 @@ __setup(reboot=, reboot_setup);
void machine_shutdown(void)
{
-#ifdef CONFIG_SMP
smp_send_stop();
-#endif
}
void machine_halt(void)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 40dc74f..16ca27b 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -560,12 +560,17 @@ asmlinkage void __exception do_IPI(struct pt_regs *regs)
void smp_send_reschedule(int cpu)
{
- send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
+ if (is_smp())
+ send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
}
void smp_send_stop(void)
{
cpumask_t mask = cpu_online_map;
+
+ if (!is_smp())
+ return;
+
cpu_clear(smp_processor_id(), mask);
send_ipi_message(mask, IPI_CPU_STOP);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Fix CONFIG_LOCAL_TIMERS initialization for multi-omap
Fix CONFIG_LOCAL_TIMERS initialization for multi-omap
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 74fbed8..5a3e606 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -228,8 +228,10 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
#ifdef CONFIG_LOCAL_TIMERS
- twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
- BUG_ON(!twd_base);
+ if (cpu_is_omap44xx()) {
+ twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
+ BUG_ON(!twd_base);
+ }
#endif
omap_dm_timer_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: McBSP: Fix static function warning
This patch fixes sparse warning due non declaration of static function
sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol 'omap_mcbsp_st_info_volsw'
was not declared. Should it be static?
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: alsa-de...@alsa-project.org
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
sound/soc/omap/omap-mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 86f2139..5768381 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -780,7 +780,7 @@ struct snd_soc_dai omap_mcbsp_dai[] = {
EXPORT_SYMBOL_GPL(omap_mcbsp_dai);
-int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
+static int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
struct soc_mixer_control *mc =
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init testing
* Bryan Wu bryan...@canonical.com [100906 03:09]: Tony, I tried your latest branch: devel-smp-on-unicore, kernel boots up but got lots of WARN_ON fired: --- [ cut here ] [1.149719] WARNING: at mm/percpu-vm.c:320 pcpu_alloc+0x2fc/0x888() [1.149780] Modules linked in: [1.149841] [c01b34c8] (unwind_backtrace+0x0/0xe4) from [c01e939c] (warn_slowpath_common+0x4c/0x64) [1.149902] [c01e939c] (warn_slowpath_common+0x4c/0x64) from [c01e93cc] (warn_slowpath_null+0x18/0x1c) [1.149993] [c01e93cc] (warn_slowpath_null+0x18/0x1c) from [c0274730] (pcpu_alloc+0x2fc/0x888) [1.150085] [c0274730] (pcpu_alloc+0x2fc/0x888) from [c0279578] (sget+0x198/0x43c) [1.150146] [c0279578] (sget+0x198/0x43c) from [c0279adc] (get_sb_ns+0x20/0x90) [1.150238] [c0279adc] (get_sb_ns+0x20/0x90) from [c02791a4] (vfs_kern_mount+0x9c/0x18c) [1.150299] [c02791a4] (vfs_kern_mount+0x9c/0x18c) from [c0022280] (init_mqueue_fs+0x68/0xc8) [1.150390] [c0022280] (init_mqueue_fs+0x68/0xc8) from [c01ac5d0] (do_one_initcall+0xcc/0x1a4) [1.150451] [c01ac5d0] (do_one_initcall+0xcc/0x1a4) from [c0008760] (kernel_init+0x148/0x210) [1.150543] [c0008760] (kernel_init+0x148/0x210) from [c01adcf8] (kernel_thread_exit+0x0/0x8) [1.150604] ---[ end trace 1b75b31a2719ed74 ]--- --- It looks like we still missed to set some flag for chuck. Yeah I think there's some .config option that needs to be handled properly to fix this. Looks like the following .config does not produce it, but fails to boot to shell on omap2. Doing yes | make oldconfig and enabling CONFIG_SMP etc on makes the warning to happen. Also, disabling CONFIG_USB_MUSB_HDRC is needed as that driver is still broken for multi-omap.. Regards, Tony # # Automatically generated make config: don't edit # Linux kernel version: 2.6.36-rc3 # Tue Sep 7 18:42:21 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set #
Re: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi-omap
* Shilimkar, Santosh santosh.shilim...@ti.com [100903 05:07]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, September 03, 2010 1:00 AM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Bryan Wu; Will Deacon Subject: Re: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi- omap * Tony Lindgren t...@atomide.com [100902 09:16]: From c04a57fc3b41d886f56ccdc27cf9758de0c95202 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Tue, 17 Aug 2010 13:33:23 +0300 Subject: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi- omap Fix SMP on UP interrupt handling for multi-omap Here's this one updated to use !smp_cpu() instead of smp_on_up(). Looks like the description and subject needed some refreshing too. As I commented on other patch we should just avoid doing anything When the CPU is not OMAP4. Looks like the only fix needed now is the localtimer fix. Posted a patch that uses cpu_is_omap44xx() to test for that. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND/PATCH 0/6] USB: musb-gadget: bug fix
CC Felipe / David / Gadiyar / Mike / Sergei 2010/9/8 Greg KH g...@kroah.com: I seem to not have 1/6 here, did it get stuck somewhere? Here is 1/6: http://marc.info/?l=linux-usbm=128387307419605w=2 If you need, I can send the 1/6 to you directly. Anyway, I need Felipe's ack before I can accept these. Felipe, expect your comments on the patch set... BTW: The mailbox of felipe.ba...@nokia.com in MAINTAINERS has been obsolete now, and his current box is m...@felipebalbi.com, seems MAINTAINERS should be updated for it. -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver support
Hi Tomi,
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Tuesday, September 07, 2010 7:15 PM
To: K, Mythri P
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver
support
On Tue, 2010-09-07 at 15:37 +0200, ext K, Mythri P wrote:
Hi Tomi,
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Tuesday, September 07, 2010 6:47 PM
To: K, Mythri P
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] OMAP:DSS: RFC Patch to add HDMI DSS
driver
support
On Thu, 2010-08-26 at 07:17 +0200, ext K, Mythri P wrote:
From: Mythri P K mythr...@ti.com
This is an RFC patch to add support for HDMI DSS driver in
OMAP.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 292
1 files changed, 292 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.c
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
new file mode 100644
index 000..3d7acd2
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -0,0 +1,292 @@
+/*
+ * linux/drivers/video/omap2/dss/hdmi.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Author: Yong Zhi
+ *
+ * HDMI settings from TI's DSS driver
+ *
+ * This program is free software; you can redistribute it
and/or
modify it
+ * under the terms of the GNU General Public License version
2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be
useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public
License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ * History:
+ * Mythripk mythr...@ti.com -Redesigned on the driver
to
adhere to DSS2 model.
+ * -GPIO calls for HDMI.
+ *
+ *
+ */
+
+#define DSS_SUBSYS_NAME HDMI
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/string.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include plat/display.h
+#include plat/cpu.h
+#include plat/gpio.h
+
+#include dss.h
+
+static struct {
+ struct mutex lock;
+} hdmi;
+
+#define FLD_GET(val, start, end) (((val) FLD_MASK(start,
end))
(end))
+#define FLD_MOD(orig, val, start, end) \
+ (((orig) ~FLD_MASK(start, end)) | FLD_VAL(val, start,
end))
These are already defined in dss.h
+
+
+#define CPF2
+
+int hdmi_init_display(struct omap_dss_device *dssdev)
+{
+ DSSDBG(init_display\n);
+
+ return 0;
+}
+
+void compute_hdmi_pll(int clkin, int phy,
+ int n, struct hdmi_pll_info *pi)
This is a non-static function, and you don't introduce it in any
header
file.
It is not exported, so it should be used only from inside DSS
driver.
I
see you call it in the next patch from the display driver, which
is
not
ok. Only exported functions should be used from the display
drivers
(you'll notice the problem if you build DSS as a module...).
If the function is not static, it should have some meaningful
prefix.
The same comments apply to some other functions in this file
also.
I have introduced these in the display.h , do you suggest adding
prefix like omapdss_hdmi* for all these functions ?
Neither of the two HDMI patches you sent modify display.h...
Yes, if you export functions from DSS they should be prefixed, as
they
are global functions.
I shall correct the function names.
Yes this is just a RFC patch to introduce the HDMI driver and panel as such, if
you have no other comments on these 2 patch set I shall incorporate these
comments and send out the complete patch series with all the relevant changes
in display.h and some overlay.c and manager.c changes.
Tomi
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
