Re: I2C Touchscreen OMAP OOPS
- Original Message - From: David Lynch Jr. dh...@dlasys.net To: Linux OMAP Mailing List linux-omap@vger.kernel.org Cc: linux-in...@vger.kernel.org; linux-...@vger.kernel.org Sent: Tuesday, January 04, 2011 12:26 PM Subject: I2C Touchscreen OMAP OOPS I am trying to get a vendor provided I2C touchscreen driver working with android froyo with a 2.6.32 linux kernel for a client. I have fixed alot of things and I am down to one serious problem remaining. The driver is oops'ing reading the touchscreen data in omap_i2c_xfer. I tried to figure out what was going on by printk tracing omap_i2c_xfer, but the problem goes away - mostly with a few judiciously inserted printk's I tried backporting the 2.6.37 i2c-omap code, but that does nto change behavior. What is scheduling while atomic ? and what am I trying to look for ? Is the root of this problem in the touchscreen driver ? omap_i2c or should I be looking elsewhere ? Looks like your touchscreen driver is trying to do i2c transfer in IRQ context, hence the error. r...@beagleboard:~# evtest /dev/input/event1 Input driver version is 1.0.0evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output to 64 bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html Input device ID: bus 0x18 vendor 0xdead product 0x534 version 0x1 Input device name: sitronix_ts Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 330 (Touch) Event type 3 (Absolute) Event code 0 (X) Value 0 Min0 Max 480 Event code 1 (Y) Value 0 Min0 Max 256 Testing ... (interrupt to exit) BUG: scheduling while atomic: swapper/0/0x00010003 Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 8007 [#1] PREEMPT last sysfs file: /sys/devices/platform/mmci-omap-hs.0/mmc_host/mmc0/mmc0:/block/mmcblk0/size Modules linked in: CPU: 0Not tainted (2.6.32 #98) PC is at 0x0 LR is at enqueue_task+0x28/0x34 pc : []lr : [c005aaac]psr: 2193 sp : c04dbc30 ip : 0016 fp : c04dbc44 r10: r9 : r8 : 0002 r7 : r6 : r5 : c04e8cc8 r4 : c04dcfa8 r3 : r2 : 0001 r1 : c04dcfa8 r0 : c04e8cc8 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8c8c8019 DAC: 0017 LR: 0xc005aa2c: aa2c e8bd8800 e92d4800 e59100c4 e28db004 e352 03ac 13a0 e8bd8800 aa4c e92d48f0 e1c040d0 e1a06002 e1a07003 e0566004 e0c77005 e28db014 e1a021a6 aa6c e1a031c7 e1822e87 e0944002 e0a55003 e1c040f0 e8bd88f0 e352 e92d48d8 aa8c e1a04001 e28db014 11c165d8 11c168f8 e5943028 e1a01004 e5933004 e12fff33 aaac e3a03001 e584304c e8bd88d8 e92d4b78 e2525000 e28db01c e1a06000 e1a04001 aacc 0a10 e1c127d0 e1921003 0a08 e1c485d8 e2840078 e0582002 e0c93003 aaec ebd6 e3a02000 e3a03000 e1c427f0 ea04 e59f3030 e2840090 e5932000 ab0c e3a03000 ebcd e5943028 e1a6 e1a01004 e1a02005 e5933008 e12fff33 SP: 0xc04dbbb0: bbb0 000f 0010 30303033 0031 bbd0 c04dbc1c c0034bf0 c04e8cc8 c04dcfa8 bbf0 0001 c04dcfa8 c04e8cc8 0002 bc10 c04dbc44 0016 c04dbc30 c005aaac 2193 bc30 c04e8cc8 c04da000 c04dbc54 c005ab70 c04dcfa8 bc50 c04dbc7c c005e9b8 c044d812 8193 c05257f0 cf91e010 0001 cf91e01c bc70 0001 0003 c04dbca4 c005aef0 0113 1004 bc90 0039 0001 601f c04e92d4 c04dbcbc c005cf14 35303135 FP: 0xc04dbbc4: bbc4 c04dbc1c bbe4 c0034bf0 c04e8cc8 c04dcfa8 0001 c04dcfa8 c04e8cc8 bc04 0002 c04dbc44 0016 c04dbc30 c005aaac bc24 2193 c04e8cc8 c04da000 c04dbc54 bc44 c005ab70 c04dcfa8 c04dbc7c c005e9b8 c044d812 8193 c05257f0 bc64 cf91e010 0001 cf91e01c 0001 0003 c04dbca4 c005aef0 bc84 0113 1004 0039 0001 601f c04e92d4 c04dbcbc bca4 c005cf14 35303135 63303536 cf91e000 c04dbdec c024626c cf85bb00 R0: 0xc04e8c48: 8c48 8c68 000f4240 000f4240 000f4240 004c4b40 8c88 004c4b40 000f4240 0003d090 0003d090 0001 c04e8c9c c04e8c9c 000f4240 8ca8 000e7ef0 0001 c04e8cb0 c04e8cb0 cc901b18 c0525278 0004 0001 8cc8 0070 0176 018b 013b 8ce8 268a 9fd5 8d08 cd9c987c 0008 c04e8d20 c04e8d20 8d28 c04e8cc8 R1:
RE: [PATCH v7 4/7] omap3: nand: prefetch in irq mode support
[..snip...]
+ if (info-buf_len (info-buf_len bytes))
Meant to use logical AND here?
[Ghorai] thanks, you are right.
[..snip..]
+ init_completion(info-comp);
You can use INIT_COMPLETION to reset the completion variable.
Same change can be done in write below.
[..snip..]
s/methode/method
[Ghorai] yes. I will do this
[..snip..]
+ /* waiting for write to complete */
+ wait_for_completion(info-comp);
+ /* wait for data to flushed-out before reset the prefetch */
+ do {
+ ret = gpmc_read_status(GPMC_PREFETCH_COUNT);
+ } while (ret);
Please have a timeout for this while loop in case hardware does
not become ready. Also, consider using cpu_relax() inside the
tight loop.
[Ghorai] Thanks. I will send again.
--
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 v1 09/10] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG
On Tue, Jan 4, 2011 at 1:05 PM, Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Hi,
On 12/21/10 09:40, ext Kishon Vijay Abraham I wrote:
McBSP2/3 in OMAP3 has sidetone feature which requires autoidle
to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, omap_device APIs are used to modify SYSCONFIG
register.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
{
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
/*
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- u16 syscon;
-
- syscon = MCBSP_READ(mcbsp, SYSCON);
- syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) |
CLOCKACTIVITY(0x03));
-
- if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
- syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
- CLOCKACTIVITY(0x02));
- MCBSP_WRITE(mcbsp, WAKEUPEN, XRDYEN | RRDYEN);
- } else {
- syscon |= SIDLEMODE(0x01);
- }
-
- MCBSP_WRITE(mcbsp, SYSCON, syscon);
+ if (mcbsp-dma_op_mode != MCBSP_DMA_MODE_THRESHOLD)
+ omap_device_noidle(od);
Should you configure McBSP to SMART_IDLE, when the THRESHOLD mode is
selected?
While we are here:
1. How we select the WAKE events from McBSP?
We need XRDYEN, and RRDYEN bits for wake (in WAKEUPEN register),
Ahh.. Ok. This setting still need to be present. Will add it in
my next patch version.
Thanks.
and
also we need to enable the WAKEUP in SYSCON register.
Setting of WAKEUPEN will be taken care by pm_runtime_get_sync()
2. How we are configuring the CLOCKACTIVITY field in SYSCON register?
It's been set in the hwmod database. In [1], there is a field
.clockact in
omap_hwmod_class_sysconfig where we set the clock activity to 2. Whenever
we do a get_sync, CLOCKACTIVITY field in SYSCON register will be set
to the value present in .clockact field.
[1] https://patchwork.kernel.org/patch/423731/
--
Péter
--
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
--
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/2] IRQ-related changes
Hi, The following two patches are enabling SPARSE_IRQ numbering scheme on OMAP. I lightly tested on a pandaboard and seems to be working fine so far: # cat /proc/interrupts CPU0 CPU1 39: 1 0 GIC TWL6030-PIH 44: 1758 0 GIC DMA 69: 7615 0 GIC gp timer 88:195 0 GIC i2c_omap 89: 0 0 GIC i2c_omap 93: 0 0 GIC i2c_omap 94: 0 0 GIC i2c_omap 102: 0 0 GIC serial idle 104: 0 0 GIC serial idle 105: 0 0 GIC serial idle 106:743 0 GIC serial idle, OMAP UART2 115: 2356 0 GIC mmc0 160: 0 0GPIO mmc0 376: 0 0 twl6030 twl4030_pwrbutton 379: 0 0 twl6030 rtc0 IPI: 9537 LOC: 0 0 Err: 0 The first patch just removes the direct access to irq_desc array and converts it to irq_to_desc(). Second patch simply selects HAVE_GENERIC_HARDIRQS and HAVE_SPARSE_IRQ. I boot tested with and without enabling: - General setup - IRQ subsystem - SPARSE_IRQ and both kernels boot fine. Felipe Balbi (2): arm: omap: gpio: don't access irq_desc array directly arm: omap: select HAVE_SPARSE_IRQ arch/arm/Kconfig |2 ++ arch/arm/plat-omap/gpio.c | 10 +++--- 2 files changed, 9 insertions(+), 3 deletions(-) -- 1.7.3.4.598.g85356 -- 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] arm: omap: gpio: don't access irq_desc array directly
Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/gpio.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..c351758 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
if (retval == 0) {
- irq_desc[irq].status = ~IRQ_TYPE_SENSE_MASK;
- irq_desc[irq].status |= type;
+ struct irq_desc *d = irq_to_desc(irq);
+
+ d-status = ~IRQ_TYPE_SENSE_MASK;
+ d-status |= type;
}
spin_unlock_irqrestore(bank-lock, flags);
@@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
for (j = bank-virtual_irq_start;
j bank-virtual_irq_start + gpio_count; j++) {
- lockdep_set_class(irq_desc[j].lock, gpio_lock_class);
+ struct irq_desc *d = irq_to_desc(j);
+
+ lockdep_set_class(d-lock, gpio_lock_class);
set_irq_chip_data(j, bank);
if (bank_is_mpuio(bank))
set_irq_chip(j, mpuio_irq_chip);
--
1.7.3.4.598.g85356
--
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/2] arm: omap: select HAVE_SPARSE_IRQ
select HAVE_SPARSE_IRQ and irq_descs can be added to a radix tree instead of an array. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d56d21c0..c4ffe2e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -826,6 +826,8 @@ config ARCH_DAVINCI config ARCH_OMAP bool TI OMAP select HAVE_CLK + select HAVE_GENERIC_HARDIRQS + select HAVE_SPARSE_IRQ select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ select GENERIC_CLOCKEVENTS -- 1.7.3.4.598.g85356 -- 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 v1 09/10] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG
On 01/04/11 11:26, ext ABRAHAM, KISHON VIJAY wrote: 1. How we select the WAKE events from McBSP? We need XRDYEN, and RRDYEN bits for wake (in WAKEUPEN register), Ahh.. Ok. This setting still need to be present. Will add it in my next patch version. Thanks. Thanks. and also we need to enable the WAKEUP in SYSCON register. Setting of WAKEUPEN will be taken care by pm_runtime_get_sync() I need to get more familiar with the hwmod things ;) 2. How we are configuring the CLOCKACTIVITY field in SYSCON register? It's been set in the hwmod database. In [1], there is a field .clockact in omap_hwmod_class_sysconfig where we set the clock activity to 2. Whenever we do a get_sync, CLOCKACTIVITY field in SYSCON register will be set to the value present in .clockact field. [1] https://patchwork.kernel.org/patch/423731/ I see. Is there a way to change the CLOCKACTIVITY field in certain cases? What I mean is: the 0x2 means that ICLK can be switched off, PRCM FCLK must kept on I have a setup, where I can switch off the FCLK for a period of time (so PER domain can hit retention). For this I'll need to have 0x0 in CLOCKACTIVITY. I'm not sure what are the side effects if we always use 0x0, but IMHO that shall be fine as well. -- Péter -- 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] arm: omap: select HAVE_SPARSE_IRQ
On Tue, Jan 04, 2011 at 11:39:26AM +0200, Felipe Balbi wrote: select HAVE_SPARSE_IRQ and irq_descs can be added to a radix tree instead of an array. Please move HAVE_GENERIC_HARDIRQS to the config ARM entry, and remove these: config GENERIC_HARDIRQS bool default y config GENERIC_HARDIRQS_NO__DO_IRQ def_bool y as they're in kernel/irq/Kconfig, and are visible if HAVE_GENERIC_HARDIRQS is enabled. -- 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] arm: omap: select HAVE_SPARSE_IRQ
On Tue, Jan 04, 2011 at 09:54:10AM +, Russell King - ARM Linux wrote: On Tue, Jan 04, 2011 at 11:39:26AM +0200, Felipe Balbi wrote: select HAVE_SPARSE_IRQ and irq_descs can be added to a radix tree instead of an array. Please move HAVE_GENERIC_HARDIRQS to the config ARM entry, and remove these: config GENERIC_HARDIRQS bool default y config GENERIC_HARDIRQS_NO__DO_IRQ def_bool y as they're in kernel/irq/Kconfig, and are visible if HAVE_GENERIC_HARDIRQS is enabled. Note also that should be a separate patch from adding HAVE_SPARSE_IRQ to OMAP, as it's an independent but necessary change. -- 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/3] perf, tools: new power trace API
From: Jean Pihet j-pi...@ti.com Provides: . calls to machine_suspend trace point, . OMAP support, . API Documentation Applies on top of Thomas's 8 latest power trace API patches, cf. http://marc.info/?l=linux-kernelm=129130827309354w=2 Jean Pihet (3): perf: add calls to suspend trace point perf: add OMAP support for the new power events tools, perf: Documentation for the power events API Documentation/trace/events-power.txt | 90 ++ arch/arm/mach-omap2/pm34xx.c |7 +++ arch/arm/mach-omap2/powerdomain.c|3 + arch/arm/plat-omap/clock.c | 13 - kernel/power/suspend.c |3 + 5 files changed, 113 insertions(+), 3 deletions(-) create mode 100644 Documentation/trace/events-power.txt -- 1.7.2.3 -- 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/3] perf: add calls to suspend trace point
From: Jean Pihet j-pi...@ti.com
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
kernel/power/suspend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ecf7705..0650596 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include linux/mm.h
#include linux/slab.h
#include linux/suspend.h
+#include trace/events/power.h
#include power.h
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops-enter(state);
+ trace_machine_suspend(PWR_EVENT_EXIT);
events_check_enabled = false;
}
sysdev_resume();
--
1.7.2.3
--
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/3] perf: add OMAP support for the new power events
From: Jean Pihet j-pi...@ti.com
The patch adds the new power management trace points for
the OMAP architecture.
The trace points are for:
- default idle handler. Since the cpuidle framework is
instrumented in the generic way there is no need to
add trace points in the OMAP specific cpuidle handler;
- cpufreq (DVFS),
- clocks changes (enable, disable, set_rate),
- change of power domains next power states.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |7 +++
arch/arm/mach-omap2/powerdomain.c |3 +++
arch/arm/plat-omap/clock.c| 13 ++---
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..0ee0b0e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include linux/delay.h
#include linux/slab.h
#include linux/console.h
+#include trace/events/power.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -506,8 +507,14 @@ static void omap3_pm_idle(void)
if (omap_irq_pending() || need_resched())
goto out;
+ trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+ trace_cpu_idle(1, smp_processor_id());
+
omap_sram_idle();
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+
out:
local_fiq_enable();
local_irq_enable();
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 fc62fb5..7cbb09b 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 (ret == 0) {
if (clk-recalc)
clk-rate = clk-recalc(clk);
--
1.7.2.3
--
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/3] tools, perf: Documentation for the power events API
From: Jean Pihet j-pi...@ti.com Provides documentation for the following: - the new power trace API, - the old (legacy) power trace API, - the DEPRECATED Kconfig option usage. Signed-off-by: Jean Pihet j-pi...@ti.com --- Documentation/trace/events-power.txt | 90 ++ 1 files changed, 90 insertions(+), 0 deletions(-) create mode 100644 Documentation/trace/events-power.txt diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt new file mode 100644 index 000..8a50653 --- /dev/null +++ b/Documentation/trace/events-power.txt @@ -0,0 +1,90 @@ + + Subsystem Trace Points: power + +The power tracing system captures events related to power transitions +within the kernel. Broadly speaking there are three major subheadings: + + o Power state switch which reports events related to suspend (S-states), + cpuidle (C-states) and cpufreq (P-states) + o System clock related changes + o Power domains related changes and transitions + +This document describes what each of the tracepoints is and why they +might be useful. + +Cf. include/trace/events/power.h for the events definitions. + +1. Power state switch events + + +1.1 New trace API +- + +A 'cpu' event class gathers the CPU-related events: cpuidle and +cpufreq. + +cpu_idle state=%lu cpu_id=%lu +cpu_frequency state=%lu cpu_id=%lu + +A suspend event is used to indicate the system going in and out of the +suspend mode: + +machine_suspendstate=%lu + + +Note: the value of '-1' or '4294967295' for state means an exit from the current state, +i.e. trace_cpu_idle(4, smp_processor_id()) means that the system +enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()) +means that the system exits the previous idle state. + +The event which has 'state=4294967295' in the trace is very important to the user +space tools which are using it to detect the end of the current state, and so to +correctly draw the states diagrams and to calculate accurate statistics etc. + +1.2 DEPRECATED trace API + + +A new Kconfig option CONFIG_EVENT_POWER_TRACING_DEPRECATED with the default value of +'y' has been created. This allows the legacy trace power API to be used conjointly +with the new trace API. +The Kconfig option, the old trace API (in include/trace/events/power.h) and the +old trace points will disappear in a future release (namely 2.6.41). + +power_starttype=%lu state=%lu cpu_id=%lu +power_frequencytype=%lu state=%lu cpu_id=%lu +power_end cpu_id=%lu + +The 'type' parameter takes one of those macros: + . POWER_NONE = 0, + . POWER_CSTATE= 1,/* C-State */ + . POWER_PSTATE= 2,/* Fequency change or DVFS */ + +The 'state' parameter is set depending on the type: + . Target C-state for type=POWER_CSTATE, + . Target frequency for type=POWER_PSTATE, + +power_end is used to indicate the exit of a state, corresponding to the latest +power_start event. + +2. Clocks events + +The clock events are used for clock enable/disable and for +clock rate change. + +clock_enable %s state=%lu cpu_id=%lu +clock_disable %s state=%lu cpu_id=%lu +clock_set_rate %s state=%lu cpu_id=%lu + +The first parameter gives the clock name (e.g. gpio1_iclk). +The second parameter is '1' for enable, '0' for disable, the target +clock rate for set_rate. + +3. Power domains events +=== +The power domain events are used for power domains transitions + +power_domain_target%s state=%lu cpu_id=%lu + +The first parameter gives the power domain name (e.g. mpu_pwrdm). +The second parameter is the power domain target state. + -- 1.7.2.3 -- 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] arm: omap: select HAVE_SPARSE_IRQ
Hi, On Tue, Jan 04, 2011 at 09:54:10AM +, Russell King - ARM Linux wrote: On Tue, Jan 04, 2011 at 11:39:26AM +0200, Felipe Balbi wrote: select HAVE_SPARSE_IRQ and irq_descs can be added to a radix tree instead of an array. Please move HAVE_GENERIC_HARDIRQS to the config ARM entry, and remove these: config GENERIC_HARDIRQS bool default y config GENERIC_HARDIRQS_NO__DO_IRQ def_bool y as they're in kernel/irq/Kconfig, and are visible if HAVE_GENERIC_HARDIRQS is enabled. do you mean: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d56d21c0..70ff78a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -14,6 +14,7 @@ config ARM select HAVE_FUNCTION_TRACER if (!XIP_KERNEL) select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) + select HAVE_GENERIC_HARDIRQS select HAVE_GENERIC_DMA_COHERENT select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZO @@ -88,10 +89,6 @@ config MCA file:Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. -config GENERIC_HARDIRQS - bool - default y - config STACKTRACE_SUPPORT bool default y @@ -171,9 +168,6 @@ config FIQ config ARCH_MTD_XIP bool -config GENERIC_HARDIRQS_NO__DO_IRQ - def_bool y - config ARM_L1_CACHE_SHIFT_6 bool help @@ -510,7 +504,7 @@ config ARCH_MMP select GENERIC_CLOCKEVENTS select TICK_ONESHOT select PLAT_PXA - select SPARSE_IRQ + select HAVE_SPARSE_IRQ help Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line. @@ -589,7 +583,7 @@ config ARCH_PXA select GENERIC_CLOCKEVENTS select TICK_ONESHOT select PLAT_PXA - select SPARSE_IRQ + select HAVE_SPARSE_IRQ help Support for Intel/Marvell's PXA2xx/PXA3xx processor line. @@ -1398,15 +1392,6 @@ config HW_PERF_EVENTS Enable hardware performance counter support for perf events. If disabled, perf events will use software events only. -config SPARSE_IRQ - def_bool n - help - This enables support for sparse irqs. This is useful in general - as most CPUs have a fairly sparse array of IRQ vectors, which - the irq_desc then maps directly on to. Systems with a high - number of off-chip IRQs will want to treat this as - experimental until they have been independently verified. - source mm/Kconfig config FORCE_MAX_ZONEORDER -- 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: [PATCH 1/3] perf: add calls to suspend trace point
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Uses the machine_suspend trace point, called from the generic kernel suspend_enter function. Signed-off-by: Jean Pihet j-pi...@ti.com CC: Thomas Renninger tr...@suse.de --- kernel/power/suspend.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Please use the scripts/get_maintainer.pl to construct a proper Cc: list and to gather the necessary Acked-by: scripts/get_maintainer.pl -f kernel/power/suspend.c Thanks, Ingo -- 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/3] perf: add calls to suspend trace point
Hi!
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
kernel/power/suspend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ecf7705..0650596 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include linux/mm.h
#include linux/slab.h
#include linux/suspend.h
+#include trace/events/power.h
#include power.h
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops-enter(state);
+ trace_machine_suspend(PWR_EVENT_EXIT);
events_check_enabled = false;
}
sysdev_resume();
Ok... why this place? I mean, perhaps suspend time should include
device suspend?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly
Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/gpio.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..c351758 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
if (retval == 0) {
- irq_desc[irq].status = ~IRQ_TYPE_SENSE_MASK;
- irq_desc[irq].status |= type;
+ struct irq_desc *d = irq_to_desc(irq);
+
+ d-status = ~IRQ_TYPE_SENSE_MASK;
+ d-status |= type;
}
spin_unlock_irqrestore(bank-lock, flags);
@@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
for (j = bank-virtual_irq_start;
j bank-virtual_irq_start + gpio_count; j++) {
- lockdep_set_class(irq_desc[j].lock, gpio_lock_class);
+ struct irq_desc *d = irq_to_desc(j);
+
+ lockdep_set_class(d-lock, gpio_lock_class);
set_irq_chip_data(j, bank);
if (bank_is_mpuio(bank))
set_irq_chip(j, mpuio_irq_chip);
--
1.7.3.4.598.g85356
--
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 0/4] Introduce hardware spinlock framework
Hi Andrew, On Sat, Dec 18, 2010 at 2:53 AM, Tony Lindgren t...@atomide.com wrote: * Ohad Ben-Cohen o...@wizery.com [101216 13:34]: Tony, Andrew, can you please have a look ? Any comment or suggestion is appreciated. Looks sane to me from omap point of view and it seems the locks are now all timeout based: Acked-by: Tony Lindgren t...@atomide.com Can you please have a look at this patch set (see link no. [1] below) ? Short summary: This hwspinlock framework adds support for hardware-based locking devices, needed to accomplish synchronization and mutual exclusion operations between remote processors that have no alternative mechanism to do so. This patch set adds a framework and an OMAP implementation. It had circulated several times in the relevant mailing lists, and all comments were addressed. The third version of this patch set [1] was submitted about a month ago and so far there is no outstanding comment. Users for this framework that we are aware of: 1. OMAP4 and Davinci Netra (DM8168): both of these SoC have the same hwspinlock module and will share the same host implementation. 2. Other platforms (such as omap3530 and omapl1xx) that have no such hardware support, but would still need to achieve synchronization (to communicate with their DSP). The only way to achieve mutual exclusion on those platforms is by using a shared-memory synchronization algorithm called Peterson's Algorithm [2]. We would still need the same hwspinlock framework for that - the busy looping, the timeout, the various locking schemes, the lock resource allocation - are all still valid. The only difference would be the actual lock implementation, therefore we will add another host implementation for these platforms. 3. The C6474, a multi-core DSP device [3], have Linux running on one of its cores, and hardware support for synchronization (btw the C6474 has a richer hardware module that would need more than the hwspinlock framework offer today - it also supports queuing, owner semantics and interrupt notification to let a processor know when it acquires a lock, so it wouldn't have to spin..). Disclaimer: it will probably take some time until c6x support is merged upstream, but this is something that is being actively worked on [4]. Any comment or suggestion is appreciated. Thanks, Ohad. [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39833.html [2] http://en.wikipedia.org/wiki/Peterson's_algorithm [3] http://focus.ti.com/docs/prod/folders/print/tms320c6474.html [4] http://www.linux-c6x.org/wiki/index.php/Main_Page -- 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 07/17] OMAP2,3: DSS2: Build omap_device for each DSS HWIP
Hi Tony,
On Tue, Jan 4, 2011 at 7:26 AM, Tony Lindgren t...@atomide.com wrote:
* Guruswamy Senthilvadivu svad...@ti.com [110103 04:51]:
+ char *omap2_oh_name[] = { dss_dss, dss_dispc, dss_rfbi,
+ dss_venc };
+ char *omap3_oh_name[] = { dss_dss, dss_dispc, dss_rfbi,
+ dss_venc, dss_dsi1 };
+ char *omap2_dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc };
+ char *omap3_dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
+ omap_venc, omap_dsi1 };
+ char *(*oh_name)[];
+ char *(*dev_name)[];
+ int oh_count;
+
+ if (cpu_is_omap24xx()) {
+ oh_name = omap2_oh_name;
+ dev_name = omap2_dev_name;
+ oh_count = ARRAY_SIZE(omap2_oh_name);
+ } else {
+ oh_name = omap3_oh_name;
+ dev_name = omap3_dev_name;
+ oh_count = ARRAY_SIZE(omap3_oh_name);
+ }
Here it looks like you don't need to repeat the common names
dss_dss, dss_dispc, dss_rfbi. Instead you can have a
common char *omap_oh_name[5] then set oh_count smaller based
on the omap type.
Thanks, yes, that's a good suggestion. Senthil is going to be out for
sometime, so I will update this and send an updated patch series by
tomorrow, after waiting for any more comments.
Best regards,
~Sumit.
Regards,
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
--
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 v5 1/3] ARM: add CPPI 4.1 DMA support
Hello. On 03-01-2011 23:44, Felipe Balbi wrote: Moreover, even Felipe also seems to move other musb DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma. Frankly speaking, I doubt that drivers/dma/ will have place for the purely MUSB specific DMA engines such as the named ones (there's no TUSB DMA BTW it uses OMAP DMA). I think we will get more clarity once we start on this activity. I agree, but I personally don't see that many limiting factors. dmaengine is just a generic API for doing DMA transfers. If it's not enough for us currently, we extend it. Putting MUSB DMA enignes into drivers/dma/ is the same as taking *any* chip capable of bus-mastering DMA, separating its bus mastering related code from its driver and putting this code into drivers/dma/. This doesn't make sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which can *optionally* serve the slave devices). WBR, Sergei -- 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 v8 2/7] omap3: nand: configurable transfer type per board
nand transfer type (sDMA, Polled, prefetch) can be select from board file,
enabling all transfer type in driver, by default.
this helps in multi-omap build and to select different transfer type for
different board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |7 +++
drivers/mtd/nand/Kconfig | 17 --
drivers/mtd/nand/omap2.c | 94
3 files changed, 41 insertions(+), 77 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..78c0bdb 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -10,6 +10,12 @@
#include linux/mtd/partitions.h
+enum nand_io {
+ NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
+ NAND_OMAP_POLLED, /* polled mode, without prefetch */
+ NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+};
+
struct omap_nand_platform_data {
unsigned intoptions;
int cs;
@@ -20,6 +26,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8229802..89bb297 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -105,23 +105,6 @@ config MTD_NAND_OMAP2
help
Support for NAND flash on Texas Instruments OMAP2 and OMAP3
platforms.
-config MTD_NAND_OMAP_PREFETCH
- bool GPMC prefetch support for NAND Flash device
- depends on MTD_NAND_OMAP2
- default y
- help
-The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
-to improve the performance.
-
-config MTD_NAND_OMAP_PREFETCH_DMA
- depends on MTD_NAND_OMAP_PREFETCH
- bool DMA mode
- default n
- help
-The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
-or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
-
config MTD_NAND_IDS
tristate
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7c04cd6..60bac8e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -96,27 +96,6 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
-static int use_prefetch = 1;
-
-/* modprobe ... use_prefetch=0 etc */
-module_param(use_prefetch, bool, 0);
-MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
-
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
-static int use_dma = 1;
-
-/* modprobe ... use_dma=0 etc */
-module_param(use_dma, bool, 0);
-MODULE_PARM_DESC(use_dma, enable/disable use of DMA);
-#else
-static const int use_dma;
-#endif
-#else
-const int use_prefetch;
-static const int use_dma;
-#endif
-
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -324,7 +303,6 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
/*
* omap_nand_dma_cb: callback on the completion of dma transfer
* @lch: logical channel
@@ -426,14 +404,6 @@ out_copy:
: omap_write_buf8(mtd, (u_char *) addr, len);
return 0;
}
-#else
-static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
-static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
- unsigned int len, int is_write)
-{
- return 0;
-}
-#endif
/**
* omap_read_buf_dma_pref - read data from NAND controller into buffer
@@ -842,28 +812,13 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.chip_delay = 50;
}
- if (use_prefetch) {
-
+ switch (pdata-xfer_type) {
+ case NAND_OMAP_PREFETCH_POLLED:
info-nand.read_buf = omap_read_buf_pref;
info-nand.write_buf = omap_write_buf_pref;
- if (use_dma) {
- err = omap_request_dma(OMAP24XX_DMA_GPMC, NAND,
- omap_nand_dma_cb, info-comp, info-dma_ch);
- if (err 0) {
- info-dma_ch = -1;
- printk(KERN_WARNING DMA request failed.
-Non-dma data transfer mode\n);
- } else {
- omap_set_dma_dest_burst_mode(info-dma_ch,
- OMAP_DMA_DATA_BURST_16);
-
[PATCH v8 1/7] omap3630: nand: fix device size to work in polled mode
zoom3 and 3630-sdp having the x16 nand device.
This patch configure gpmc as x16 and select the currect function in driver
for polled mode (without prefetch enable) transfer.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-3630sdp.c |3 ++-
arch/arm/mach-omap2/board-flash.c | 10 ++
arch/arm/mach-omap2/board-flash.h |4 ++--
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-zoom2.c |5 +++--
arch/arm/mach-omap2/board-zoom3.c |5 +++--
arch/arm/mach-omap2/gpmc-nand.c |7 +--
drivers/mtd/nand/omap2.c|2 +-
9 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..470872e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -809,7 +809,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_3430);
+ board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index bbcf580..0a74141 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -11,6 +11,7 @@
#include linux/platform_device.h
#include linux/input.h
#include linux/gpio.h
+#include linux/mtd/nand.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -210,7 +211,7 @@ static void __init omap_sdp_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_sdp);
+ board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
}
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index fd38c05..f6b7253 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -139,11 +139,13 @@ static struct omap_nand_platform_data board_nand_data = {
};
void
-__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs)
+__init board_nand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs, int nand_type)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.devsize = nand_type;
gpmc_nand_init(board_nand_data);
}
@@ -194,7 +196,7 @@ unmap:
* @return - void.
*/
void board_flash_init(struct flash_partitions partition_info[],
- char chip_sel_board[][GPMC_CS_NUM])
+ char chip_sel_board[][GPMC_CS_NUM], int nand_type)
{
u8 cs = 0;
u8 norcs = GPMC_CS_NUM + 1;
@@ -250,5 +252,5 @@ void board_flash_init(struct flash_partitions
partition_info[],
in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs);
+ partition_info[2].nr_parts, nandcs, nand_type);
}
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index 69befe0..c240a3f 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -25,6 +25,6 @@ struct flash_partitions {
};
extern void board_flash_init(struct flash_partitions [],
- char chip_sel[][GPMC_CS_NUM]);
+ char chip_sel[][GPMC_CS_NUM], int nand_type);
extern void board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs);
+ u8 nr_parts, u8 cs, int nand_type);
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 001fd97..b088b1d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -436,7 +436,7 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init(musb_board_data);
board_nand_init(ldp_nand_partitions,
- ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS);
+ ARRAY_SIZE(ldp_nand_partitions), ZOOM_NAND_CS, 0);
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 2992a9f..994d286 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -15,6
[PATCH v8 4/7] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for nand transfer(read, write)
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |2 +
arch/arm/plat-omap/include/plat/nand.h |4 +-
drivers/mtd/nand/omap2.c | 198 ++--
3 files changed, 194 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index f6b7253..1964509 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/mtd/physmap.h
#include linux/io.h
+#include plat/irqs.h
#include plat/gpmc.h
#include plat/nand.h
@@ -147,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
#else
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 78c0bdb..ae5e053 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -13,7 +13,8 @@
enum nand_io {
NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default */
NAND_OMAP_POLLED, /* polled mode, without prefetch */
- NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+ NAND_OMAP_PREFETCH_DMA, /* prefetch enabled sDMA mode */
+ NAND_OMAP_PREFETCH_IRQ /* prefetch enabled irq mode */
};
struct omap_nand_platform_data {
@@ -26,6 +27,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 60bac8e..fbe8414 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -11,6 +11,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/delay.h
+#include linux/interrupt.h
#include linux/jiffies.h
#include linux/sched.h
#include linux/mtd/mtd.h
@@ -24,6 +25,7 @@
#include plat/nand.h
#defineDRIVER_NAME omap2-nand
+#defineOMAP_NAND_TIMEOUT_MS5000
#define NAND_Ecc_P1e (1 0)
#define NAND_Ecc_P2e (1 1)
@@ -108,6 +110,13 @@ struct omap_nand_info {
unsigned long phys_base;
struct completion comp;
int dma_ch;
+ int gpmc_irq;
+ enum {
+ OMAP_NAND_IO_READ = 0, /* read */
+ OMAP_NAND_IO_WRITE, /* write */
+ } iomode;
+ u_char *buf;
+ int buf_len;
};
/**
@@ -267,9 +276,10 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
- uint32_t pref_count = 0, w_count = 0;
+ uint32_t w_count = 0;
int i = 0, ret = 0;
u16 *p;
+ unsigned long tim, limit;
/* take care of subpage writes */
if (len % 2 != 0) {
@@ -295,9 +305,12 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
iowrite16(*p++, info-nand.IO_ADDR_W);
}
/* wait for data to flushed-out before reset the prefetch */
- do {
- pref_count = gpmc_read_status(GPMC_PREFETCH_COUNT);
- } while (pref_count);
+ tim = 0;
+ limit = (loops_per_jiffy *
+ msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
+ while (gpmc_read_status(GPMC_PREFETCH_COUNT) (tim++ limit))
+ cpu_relax();
+
/* disable and stop the PFPW engine */
gpmc_prefetch_reset(info-gpmc_cs);
}
@@ -326,11 +339,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
- uint32_t prefetch_status = 0;
enum dma_data_direction dir = is_write ? DMA_TO_DEVICE :
DMA_FROM_DEVICE;
dma_addr_t dma_addr;
int ret;
+ unsigned long tim, limit;
/* The fifo depth is 64 bytes. We have a sync at each frame and frame
* length is 64 bytes.
@@ -376,7 +389,7 @@ static
[PATCH v8 6/7] omap3: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/plat-omap/include/plat/gpmc.h |6 ++
arch/arm/plat-omap/include/plat/nand.h |2 ++
drivers/mtd/nand/omap2.c | 26 +++---
4 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 1964509..a768198 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -148,6 +148,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(board_nand_data);
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 9e4dc7a..bc325c5 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -86,6 +86,12 @@
#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+enum omap_ecc {
+ /* 1-bit ecc: stored at end of spare area */
+ OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
+ OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+};
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index ae5e053..d86d1ec 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include plat/gpmc.h
#include linux/mtd/partitions.h
enum nand_io {
@@ -31,6 +32,7 @@ struct omap_nand_platform_data {
enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
+ enum omap_ecc ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f1648fd..6d4a42e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -626,8 +626,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -847,8 +845,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1038,17 +1034,17 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info-nand.ecc.bytes= 3;
- info-nand.ecc.size = 512;
- info-nand.ecc.calculate= omap_calculate_ecc;
- info-nand.ecc.hwctl= omap_enable_hwecc;
- info-nand.ecc.correct = omap_correct_data;
- info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
+ info-nand.ecc.mode = NAND_ECC_SOFT;
+ else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+ info-nand.ecc.bytes= 3;
+ info-nand.ecc.size = 512;
+ info-nand.ecc.calculate= omap_calculate_ecc;
+ info-nand.ecc.hwctl= omap_enable_hwecc;
+ info-nand.ecc.correct = omap_correct_data;
+ info-nand.ecc.mode = NAND_ECC_HW;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
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 v8 7/7] omap3: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
This patch does not enables this feature by default and need to pass from
board file to enable for any board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/plat-omap/include/plat/gpmc.h |2 +
drivers/mtd/nand/omap2.c | 37 +++-
2 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index bc325c5..c07f3f2 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -90,6 +90,8 @@ enum omap_ecc {
/* 1-bit ecc: stored at end of spare area */
OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
+ /* 1-bit ecc: stored at begining of spare area as romcode */
+ OMAP_ECC_HAMMING_CODE_HW_ROMCODE, /* gpmc method romcode layout */
};
/*
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 6d4a42e..4e33972 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -98,6 +98,20 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -914,6 +928,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1037,7 +1052,8 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* selsect the ecc type */
if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
info-nand.ecc.mode = NAND_ECC_SOFT;
- else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) {
+ else if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
+ (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
info-nand.ecc.bytes= 3;
info-nand.ecc.size = 512;
info-nand.ecc.calculate= omap_calculate_ecc;
@@ -1057,6 +1073,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+
+ if (info-nand.options NAND_BUSWIDTH_16)
+ offset = 2;
+ else {
+ offset = 1;
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ }
+ omap_oobinfo.eccbytes = 3 * (info-mtd.oobsize/16);
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
--
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 v8 3/7] omap: gpmc: enable irq mode in gpmc
add support the irq mode in GPMC. gpmc_init() function move after omap_init_irq() as it has dependecy on irq. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 39 ++- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h |4 +++ arch/arm/plat-omap/include/plat/irqs.h |9 +- 27 files changed, 81 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index b527f8d..11c89dc 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void) omap_board_config_size = ARRAY_SIZE(sdp2430_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 470872e..690fecd 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index 0a74141..46c1755 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -77,6 +77,7 @@ static void __init omap_sdp_init_irq(void) omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params, h8mbx00u0mer0em_sdrc_params); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index df5a425..8d15604 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -34,6 +34,7 @@ #include plat/common.h #include plat/usb.h #include plat/mmc.h +#include plat/gpmc.h #include hsmmc.h #include timer-gp.h @@ -222,6 +223,7 @@ static void __init omap_4430sdp_init_irq(void) omap2_gp_clockevent_set_gptimer(1); #endif gic_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index 0739950..460e3d1 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -35,6 +35,7 @@ #include plat/common.h #include plat/usb.h #include plat/display.h +#include plat/gpmc.h #include mux.h #include control.h @@ -392,6 +393,7 @@ static void __init am3517_evm_init_irq(void) omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index 2c6db1a..8264e7a 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -280,6 +280,7 @@ static void __init omap_apollon_init_irq(void) omap_board_config_size = ARRAY_SIZE(apollon_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); apollon_init_smc91x(); } diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index 63f764e..7c9a834 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -686,6 +686,7 @@ static void __init cm_t35_init_irq(void) omap2_init_common_hw(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params);
[PATCH v8 5/7] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 22 ++
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a2df8b1..117ab29 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -59,7 +59,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -595,15 +594,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
/**
* gpmc_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
* @dma_mode: dma mode enable (1) or disable (0)
* @u32_count: number of bytes to be transferred
* @is_write: prefetch read(0) or write post(1) mode
*/
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ pr_err(gpmc: fifo threshold is not supported\n);
+ return -1;
+ } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
@@ -611,7 +614,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..9e4dc7a 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fbe8414..f1648fd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -244,7 +244,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -289,7 +290,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -345,8 +347,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
int ret;
unsigned long tim, limit;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+* and frame
[PATCH] arm: omap4: panda: remove usb_nop_xceiv_register
From: Ming Lei tom.leim...@gmail.com Panda uses twl6030 otg phy instead of internal phy, so removes usb_nop_xceiv_register to make musb working. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/board-omap4panda.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 1ecd0a6..802ae20 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -374,8 +374,6 @@ static void __init omap4_panda_init(void) platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices)); omap_serial_init(); omap4_twl6030_hsmmc_init(mmc); - /* OMAP4 Panda uses internal transceiver so register nop transceiver */ - usb_nop_xceiv_register(); omap4_ehci_init(); /* FIXME: allow multi-omap to boot until musb is updated for omap4 */ if (!cpu_is_omap44xx()) -- 1.7.3 -- 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/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote: GENERIC_HARDIRQS is defined under kernel/irq/Kconfig, so it's safe to drop the duplicated entry and simply select HAVE_GENERIC_HARDIRQS. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/Kconfig |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d56d21c0..e6f0f8b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -15,6 +15,7 @@ config ARM select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) select HAVE_GENERIC_DMA_COHERENT + select HAVE_GENERIC_HARDIRQS select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA @@ -88,10 +89,6 @@ config MCA file:Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. -config GENERIC_HARDIRQS - bool - default y - config STACKTRACE_SUPPORT bool default y @@ -171,9 +168,6 @@ config FIQ config ARCH_MTD_XIP bool -config GENERIC_HARDIRQS_NO__DO_IRQ - def_bool y - You didn't mention this change in the commit log. Is this duplicated, too or did it just slip through? Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 v5 1/3] ARM: add CPPI 4.1 DMA support
Hi, (using personal email, left the office) On Tue, 2011-01-04 at 16:06 +0300, Sergei Shtylyov wrote: I think we will get more clarity once we start on this activity. I agree, but I personally don't see that many limiting factors. dmaengine is just a generic API for doing DMA transfers. If it's not enough for us currently, we extend it. Putting MUSB DMA enignes into drivers/dma/ is the same as taking *any* chip capable of bus-mastering DMA, separating its bus mastering related code from its driver and putting this code into drivers/dma/. This doesn't make sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which can *optionally* serve the slave devices). Do I really have to spell it out ? Really ? You don't need to physically move the part of the code to drivers/dma, but it has to use the API. The mentor DMA is internal to MUSB. tusb6010_omap.c isn't. Where it makes sense to move the code under drivers/dma, it will be done, where it doesn't, it won't be done, but it will use the same API. That's all. The end goal is just to drop all these ad-hoc APIs for accessing DMA on musb code. -- 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: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
On Tue, 2011-01-04 at 15:00 +0100, Uwe Kleine-König wrote: On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote: GENERIC_HARDIRQS is defined under kernel/irq/Kconfig, so it's safe to drop the duplicated entry and simply select HAVE_GENERIC_HARDIRQS. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/Kconfig |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d56d21c0..e6f0f8b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -15,6 +15,7 @@ config ARM select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) select HAVE_GENERIC_DMA_COHERENT + select HAVE_GENERIC_HARDIRQS select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA @@ -88,10 +89,6 @@ config MCA file:Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. -config GENERIC_HARDIRQS - bool - default y - config STACKTRACE_SUPPORT bool default y @@ -171,9 +168,6 @@ config FIQ config ARCH_MTD_XIP bool -config GENERIC_HARDIRQS_NO__DO_IRQ - def_bool y - You didn't mention this change in the commit log. Is this duplicated, too or did it just slip through? Yes it is. My bad. Do I need to update the patch ? I can do it tomorrow. -- 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: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
Hi, 2011/1/4 Felipe Balbi m...@felipebalbi.com: The end goal is just to drop all these ad-hoc APIs for accessing DMA on musb code. If this kind of DMA controllers are only used by MUSB, seems not necessary to convert to dmaengine API. Any benefit we can get from the convert? MUSB is cross-platform already after all. 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 v5 1/3] ARM: add CPPI 4.1 DMA support
Hi, On Tue, 2011-01-04 at 22:40 +0800, Ming Lei wrote: The end goal is just to drop all these ad-hoc APIs for accessing DMA on musb code. If this kind of DMA controllers are only used by MUSB, seems not necessary to convert to dmaengine API. Any benefit we can get from the convert? MUSB is cross-platform already after all. irony correct, OMAP GPIO controller is only used on OMAPs, so why do we even bother having gpiolib, right ? /irony -- 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: [PATCH 1/3] perf: add calls to suspend trace point
Hi,
On Tue, Jan 4, 2011 at 12:29 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
kernel/power/suspend.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ecf7705..0650596 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include linux/mm.h
#include linux/slab.h
#include linux/suspend.h
+#include trace/events/power.h
#include power.h
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops-enter(state);
+ trace_machine_suspend(PWR_EVENT_EXIT);
events_check_enabled = false;
}
sysdev_resume();
Ok... why this place?
This trace has been placed here because it traces the machine low
level mode enter.
I mean, perhaps suspend time should include
device suspend?
That makes sense. We have a few options here:
1) keep the traces as proposed to trace the low level machine code only,
2) move the traces to the entry and exit of suspend_enter so that it
includes the prepare and late_prepare (+ the associated wake-up)
callbacks as well,
3) move the traces to suspend_devices_and_enter so that it includes 2)
and the handling of the console and the devices,
4) move the traces to enter_state do that it includes 3), the call to
sys_sync and the user space freeze.
Note that the the SNAPSHOT_2RAM ioctl code also calls
suspend_devices_and_enter, so if only 4) is used no trace will be
generated in that case.
I am in favor of 3) of 4).
What do you think?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Thanks,
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 v5 1/3] ARM: add CPPI 4.1 DMA support
Hi, 2011/1/4 Felipe Balbi m...@felipebalbi.com: Hi, On Tue, 2011-01-04 at 22:40 +0800, Ming Lei wrote: The end goal is just to drop all these ad-hoc APIs for accessing DMA on musb code. If this kind of DMA controllers are only used by MUSB, seems not necessary to convert to dmaengine API. Any benefit we can get from the convert? MUSB is cross-platform already after all. irony correct, OMAP GPIO controller is only used on OMAPs, so why do we even bother having gpiolib, right ? OMAP GPIOs have many usages or use cases, so we can use gpiolib to simplify access to GPIOs. If GPIOs has only one usage or use case, it is not necessary to access GPIOs by gpiolib. Now this kind of DMA controllers are only used by MUSB or only for MUSB, so it doesn't matter to access them by dmaengine or not. 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: I2C Touchscreen OMAP OOPS
Thank you; That makes sense. For reference the mcs5000 driver as well as an st1232 driver that was in the linux input patch stream perform I2C xfers in an interrupt context. On Tue, 2011-01-04 at 14:00 +0530, Hemanth V wrote: - Original Message - From: David Lynch Jr. dh...@dlasys.net To: Linux OMAP Mailing List linux-omap@vger.kernel.org Cc: linux-in...@vger.kernel.org; linux-...@vger.kernel.org Sent: Tuesday, January 04, 2011 12:26 PM Subject: I2C Touchscreen OMAP OOPS I am trying to get a vendor provided I2C touchscreen driver working with android froyo with a 2.6.32 linux kernel for a client. I have fixed alot of things and I am down to one serious problem remaining. The driver is oops'ing reading the touchscreen data in omap_i2c_xfer. I tried to figure out what was going on by printk tracing omap_i2c_xfer, but the problem goes away - mostly with a few judiciously inserted printk's I tried backporting the 2.6.37 i2c-omap code, but that does nto change behavior. What is scheduling while atomic ? and what am I trying to look for ? Is the root of this problem in the touchscreen driver ? omap_i2c or should I be looking elsewhere ? Looks like your touchscreen driver is trying to do i2c transfer in IRQ context, hence the error. r...@beagleboard:~# evtest /dev/input/event1 Input driver version is 1.0.0evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output to 64 bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html Input device ID: bus 0x18 vendor 0xdead product 0x534 version 0x1 Input device name: sitronix_ts Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 330 (Touch) Event type 3 (Absolute) Event code 0 (X) Value 0 Min0 Max 480 Event code 1 (Y) Value 0 Min0 Max 256 Testing ... (interrupt to exit) BUG: scheduling while atomic: swapper/0/0x00010003 Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 8007 [#1] PREEMPT last sysfs file: /sys/devices/platform/mmci-omap-hs.0/mmc_host/mmc0/mmc0:/block/mmcblk0/size Modules linked in: CPU: 0Not tainted (2.6.32 #98) PC is at 0x0 LR is at enqueue_task+0x28/0x34 pc : []lr : [c005aaac]psr: 2193 sp : c04dbc30 ip : 0016 fp : c04dbc44 r10: r9 : r8 : 0002 r7 : r6 : r5 : c04e8cc8 r4 : c04dcfa8 r3 : r2 : 0001 r1 : c04dcfa8 r0 : c04e8cc8 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 8c8c8019 DAC: 0017 LR: 0xc005aa2c: aa2c e8bd8800 e92d4800 e59100c4 e28db004 e352 03ac 13a0 e8bd8800 aa4c e92d48f0 e1c040d0 e1a06002 e1a07003 e0566004 e0c77005 e28db014 e1a021a6 aa6c e1a031c7 e1822e87 e0944002 e0a55003 e1c040f0 e8bd88f0 e352 e92d48d8 aa8c e1a04001 e28db014 11c165d8 11c168f8 e5943028 e1a01004 e5933004 e12fff33 aaac e3a03001 e584304c e8bd88d8 e92d4b78 e2525000 e28db01c e1a06000 e1a04001 aacc 0a10 e1c127d0 e1921003 0a08 e1c485d8 e2840078 e0582002 e0c93003 aaec ebd6 e3a02000 e3a03000 e1c427f0 ea04 e59f3030 e2840090 e5932000 ab0c e3a03000 ebcd e5943028 e1a6 e1a01004 e1a02005 e5933008 e12fff33 SP: 0xc04dbbb0: bbb0 000f 0010 30303033 0031 bbd0 c04dbc1c c0034bf0 c04e8cc8 c04dcfa8 bbf0 0001 c04dcfa8 c04e8cc8 0002 bc10 c04dbc44 0016 c04dbc30 c005aaac 2193 bc30 c04e8cc8 c04da000 c04dbc54 c005ab70 c04dcfa8 bc50 c04dbc7c c005e9b8 c044d812 8193 c05257f0 cf91e010 0001 cf91e01c bc70 0001 0003 c04dbca4 c005aef0 0113 1004 bc90 0039 0001 601f c04e92d4 c04dbcbc c005cf14 35303135 FP: 0xc04dbbc4: bbc4 c04dbc1c bbe4 c0034bf0 c04e8cc8 c04dcfa8 0001 c04dcfa8 c04e8cc8 bc04 0002 c04dbc44 0016 c04dbc30 c005aaac bc24 2193 c04e8cc8 c04da000 c04dbc54 bc44 c005ab70 c04dcfa8 c04dbc7c c005e9b8 c044d812 8193 c05257f0 bc64 cf91e010 0001 cf91e01c 0001 0003 c04dbca4 c005aef0 bc84 0113 1004 0039 0001 601f c04e92d4 c04dbcbc bca4 c005cf14 35303135 63303536 cf91e000 c04dbdec c024626c cf85bb00 R0: 0xc04e8c48: 8c48 8c68 000f4240 000f4240 000f4240
Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
Hello. Felipe Balbi wrote: I think we will get more clarity once we start on this activity. I agree, but I personally don't see that many limiting factors. dmaengine is just a generic API for doing DMA transfers. If it's not enough for us currently, we extend it. Putting MUSB DMA enignes into drivers/dma/ is the same as taking *any* chip capable of bus-mastering DMA, separating its bus mastering related code from its driver and putting this code into drivers/dma/. This doesn't make sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which can *optionally* serve the slave devices). Do I really have to spell it out ? Really ? Yes, I'm dense. :-) Especially after Ajay claiming that Mentor and CPPI 3.0 DMA will be moved to drivers/dma/... You don't need to physically move the part of the code to drivers/dma, but it has to use the API. The mentor DMA is internal to MUSB. tusb6010_omap.c isn't. Yes, that's what I've already noted in this thread. Where it makes sense to move the code under drivers/dma, it will be Surely OMAP DMA needs to be moved under drivers/dma/, not the TUSB code interfacing it. done, where it doesn't, it won't be done, but it will use the same API. That's all. I don't quite see how DMA engine API is beneficial to what we currently have... The end goal is just to drop all these ad-hoc APIs for accessing DMA on musb code. The ad-hoc API is well suited for use with MUSB, while DMA engine API is more abstract, I think. The ad-hoc API takes into account some things that the DMA engine API just can't -- like the transfer mode and packet size... WBR, Sergei -- 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: I2C Touchscreen OMAP OOPS
Hi, On Tue, 4 Jan 2011, David Lynch Jr. wrote: For reference the mcs5000 driver as well as an st1232 driver that was in the linux input patch stream perform I2C xfers in an interrupt context. They are using threaded IRQ handlers, which might be the solution you are looking for. A. -- 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/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-König wrote: On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote: GENERIC_HARDIRQS is defined under kernel/irq/Kconfig, so it's safe to drop the duplicated entry and simply select HAVE_GENERIC_HARDIRQS. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/Kconfig |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d56d21c0..e6f0f8b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -15,6 +15,7 @@ config ARM select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) select HAVE_GENERIC_DMA_COHERENT + select HAVE_GENERIC_HARDIRQS select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA @@ -88,10 +89,6 @@ config MCA file:Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. -config GENERIC_HARDIRQS - bool - default y - config STACKTRACE_SUPPORT bool default y @@ -171,9 +168,6 @@ config FIQ config ARCH_MTD_XIP bool -config GENERIC_HARDIRQS_NO__DO_IRQ - def_bool y - You didn't mention this change in the commit log. Is this duplicated, too or did it just slip through? If you look at kernel/irq/Kconfig (as I did with the original patch) you'd notice kernel/irq/Kconfig defines both of these symbols being removed when HAVE_GENERIC_HARDIRQS is enabled. If you read the discussion in the previous version of this patch set, you'd notice that the removal of this was specifically requested. It's very tiresome to have to re-explain these things. Please take some more time to research the points you bring up, rather than impulse-replying. -- 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 1/4] TI816X: Update common omap platform files
Tony Lindgren wrote on Tuesday, January 04, 2011 7:20 AM: * Paul Walmsley p...@pwsan.com [110103 15:06]: Hello Hemant On Mon, 3 Jan 2011, Hemant Pedanekar wrote: This patch updates the common platform files with TI816X support. Also adds new files for TI816X modules base addresseses and irq definitions. The approach taken in this patch is to add TI816X as part of OMAP3 variant where the cpu class is considered as OMAP34XX and the type is TI816X. This means, both cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X. Looks like you should add a CONFIG_ARCH_OMAPTI816X Kconfig option for this chip. I suspect that many handheld device manufacturers won't want to include TI816X-specific code/data in their builds, and vice versa. Please use CONFIG_SOC_OMAPTI816X instead, eventually we should use CONFIG_ARCH_OMAPX only for something that requires different compiler options. Regards, Tony Thanks Tony and Paul for comments. This means following cases need to handle: 1) Multi-OMAP build. 2) OMAP3 build for OMAP3xxx as well as TI816X SoCs - have precedence to default OMAP3 only build at most of the places. Note that this build will not really be optimized for either of them - some areas being irq macro, clock data handling with various run time checks being executed, few cpu_is_ti816x checks being executed etc. 3) OMAP3 build for OMAP3xxx SoCs only - This should be same as having CONFIG_ARCH_OMAP3 alone as earlier without TI816X patches. Thus, CONFIG_SOC_OMAPTI816X should be disabled in this case. 4) OMAP3 build for TI816X only - CONFIG_SOC_OMAPTI816X should be enabled here, which should lead to apply TI816X specific changes to OMAP3 code. Am I getting this correct? Looking at above, it seems another config option like CONFIG_SOC_OMAP3XXX is also needed in addition to CONFIG_SOC_OMAPTI816X. Please let me know your comments about this. Thanks - Hemant-- 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/3] perf: add OMAP support for the new power events
jean.pi...@newoldbits.com had written, on 01/04/2011 04:17 AM, the following: [..] diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 0ec8a04..0ee0b0e 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -29,6 +29,7 @@ #include linux/delay.h #include linux/slab.h #include linux/console.h +#include trace/events/power.h #include plat/sram.h #include plat/clockdomain.h @@ -506,8 +507,14 @@ static void omap3_pm_idle(void) if (omap_irq_pending() || need_resched()) goto out; + trace_power_start(POWER_CSTATE, 1, smp_processor_id()); + trace_cpu_idle(1, smp_processor_id()); + omap_sram_idle(); + trace_power_end(smp_processor_id()); + trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()); Dumb question: it just tells me which C state was attempted - not if actually succeeded in hitting it rt? Does'nt this give us a false data? [..] diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index fc62fb5..7cbb09b 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c (from an offline discussion on a related topic): Would it also be nice to hook on mach-omap2/clock.c points as well to hook on indirect changes? [..] -- Regards, Nishanth Menon -- 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] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen o...@wizery.com wrote: Power to the wl12xx wlan device is controlled by a fixed regulator. Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so users will not be baffled. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Hi Tony, Gentle reminder, Thanks, Ohad. arch/arm/mach-omap2/Kconfig | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index fc3a181..cc386da 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -190,6 +190,7 @@ config MACH_OMAP3_PANDORA depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select REGULATOR_FIXED_VOLTAGE config MACH_OMAP3_TOUCHBOOK bool OMAP3 Touch Book @@ -235,6 +236,7 @@ config MACH_OMAP_ZOOM2 select SERIAL_8250 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE + select REGULATOR_FIXED_VOLTAGE config MACH_OMAP_ZOOM3 bool OMAP3630 Zoom3 board @@ -244,6 +246,7 @@ config MACH_OMAP_ZOOM3 select SERIAL_8250 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE + select REGULATOR_FIXED_VOLTAGE config MACH_CM_T35 bool CompuLab CM-T35 module -- 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 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
struct clockdomain member clktrctrl_mask is available for only for OMAP2
and OMAP3 architectures. Technially it is also used only for these archs
but this breaks the build with custom OMAP4 configuration.
CC arch/arm/mach-omap2/clockdomain.o
arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_sleep':
arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_wakeup':
arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable':
arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable':
arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Fix the build break with use of ARCH_OMAP2PLUS instead of OMAP2 or OMAP3
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index de3faa2..6fa82f5 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -103,7 +103,7 @@ struct clockdomain {
const char *name;
struct powerdomain *ptr;
} pwrdm;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_ARCH_OMAP2PLUS
const u16 clktrctrl_mask;
#endif
const u8 flags;
--
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/5] omap2plus: voltage: Trivial warning fix 'no return statement'
Fix below build warnings
CC arch/arm/mach-omap2/common.o
CC arch/arm/mach-omap2/gpio.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/gpio.c:25:
arch/arm/plat-omap/include/plat/voltage.h: In function
'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
CC arch/arm/mach-omap2/dma.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/dma.c:32:
arch/arm/plat-omap/include/plat/voltage.h: In function
'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
CC arch/arm/mach-omap2/wd_timer.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/wd_timer.c:15:
arch/arm/plat-omap/include/plat/voltage.h: In function
'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
CC arch/arm/mach-omap2/prm44xx.o
CC arch/arm/mach-omap2/omap_hwmod.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/omap_hwmod.c:145:
arch/arm/plat-omap/include/plat/voltage.h: In function
'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
CC arch/arm/mach-omap2/omap_hwmod_common_data.o
In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
from arch/arm/mach-omap2/omap_hwmod_common_data.c:20:
arch/arm/plat-omap/include/plat/voltage.h: In function
'omap_voltage_register_pmic':
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in
function returning non-void
The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/voltage.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/plat-omap/include/plat/voltage.h
index 0ff1233..710f4ea 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -134,7 +134,10 @@ void omap_change_voltscale_method(struct voltagedomain
*voltdm,
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
- struct omap_volt_pmic_info *pmic_info) {}
+ struct omap_volt_pmic_info *pmic_info)
+{
+ return 0;
+}
static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method) {}
static inline int omap_voltage_late_init(void)
--
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/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
LD init/built-in.o
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage':
arch/arm/mach-omap2/pm.c:181: undefined reference to
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/built-in.o: In function `omap4_twl_init':
arch/arm/mach-omap2/omap_twl.c:244: undefined reference to
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/omap_twl.c:247: undefined reference to
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/omap_twl.c:250: undefined reference to
`omap_voltage_domain_lookup'
make: *** [.tmp_vmlinux1] Error 1
The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/voltage.h | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/plat-omap/include/plat/voltage.h
index 710f4ea..c095351 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -65,9 +65,6 @@ struct voltagedomain {
char *name;
};
-/* API to get the voltagedomain pointer */
-struct voltagedomain *omap_voltage_domain_lookup(char *name);
-
/**
* struct omap_volt_data - Omap voltage specific data.
* @voltage_nominal: The possible voltage value in uV
@@ -131,6 +128,9 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info);
void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method);
+/* API to get the voltagedomain pointer */
+struct voltagedomain *omap_voltage_domain_lookup(char *name);
+
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
@@ -144,6 +144,10 @@ static inline int omap_voltage_late_init(void)
{
return -EINVAL;
}
+static inline struct voltagedomain *omap_voltage_domain_lookup(char *name)
+{
+ return NULL;
+}
#endif
#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 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
CC arch/arm/mach-omap2/omap_hwmod_common_data.o In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38, from arch/arm/mach-omap2/omap_hwmod_common_data.c:20: arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init': arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function) arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.) make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 The error is reported when omap2plus_defconfig built with CONFIG_PM disabled Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/plat/voltage.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h index c095351..2b776f0 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -14,6 +14,8 @@ #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H +#include linux/err.h + #define VOLTSCALE_VPFORCEUPDATE1 #define VOLTSCALE_VCBYPASS 2 -- 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
Re: [PATCH 3/5] omap2plus: voltage: Trivial warning fix 'no return statement'
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following:
[..]
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/plat-omap/include/plat/voltage.h
index 0ff1233..710f4ea 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -134,7 +134,10 @@ void omap_change_voltscale_method(struct voltagedomain
*voltdm,
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
- struct omap_volt_pmic_info *pmic_info) {}
+ struct omap_volt_pmic_info *pmic_info)
+{
+ return 0;
since we dont really succeed registering the pmic to voltage layer,
return -EINVAL?
[..]
--
Regards,
Nishanth Menon
--
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/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, January 05, 2011 12:11 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg' Hi Santosh, On Tue, 4 Jan 2011, Santosh Shilimkar wrote: omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4 selected. This is because common files make references to the functions which are defined only for omap2xxx and omap3xxx. LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store': arch/arm/mach-omap2/pm-debug.c:335: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump': arch/arm/mach-omap2/pm-debug.c:121: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/pm-debug.c:123: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/pm-debug.c:124: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/pm-debug.c:125: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `omap_prcm_arch_reset': arch/arm/mach-omap2/prcm.c:106: undefined reference to `omap2_prm_set_mod_reg_bits' arch/arm/mach-omap2/prcm.c:108: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `omap_prcm_get_reset_sources': arch/arm/mach-omap2/prcm.c:53: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `clkdm_clear_all_wkdeps': arch/arm/mach-omap2/clockdomain.c:545: undefined reference to `omap2_prm_clear_mod_reg_bits' arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep': arch/arm/mach-omap2/clockdomain.c:475: undefined reference to `omap2_prm_clear_mod_reg_bits' arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep': arch/arm/mach-omap2/clockdomain.c:511: undefined reference to `omap2_prm_read_mod_bits_shift' arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep': arch/arm/mach-omap2/clockdomain.c:440: undefined reference to `omap2_prm_set_mod_reg_bits' make: *** [.tmp_vmlinux1] Error 1 This patch adds stubs for these functions so that build continues to work. Probably alternately the build can be fixed as below but that not seems to be the right way. Since these functions now return 0, maybe it would be better to call WARN() or BUG() in these functions for OMAP4. Otherwise, they are going to silently do the wrong thing, and someone needs to fix any usage of these functions where they shouldn't be used. e.g., in mach- omap2/prcm.c or mach-omap2/pm-debug.c ... Good point. Will update the patch accordingly and repost. 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
RE: [PATCH 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, January 05, 2011 12:13 AM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/5] omap2plus: clockdomain: Trivial fix for
build break because of clktrctrl_mask
Hi Santosh
On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
struct clockdomain member clktrctrl_mask is available for only for
OMAP2
and OMAP3 architectures. Technially it is also used only for these
archs
but this breaks the build with custom OMAP4 configuration.
CC arch/arm/mach-omap2/clockdomain.o
arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function
'omap2_clkdm_sleep':
arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function
'omap2_clkdm_wakeup':
arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function
'omap2_clkdm_clk_enable':
arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function
'omap2_clkdm_clk_disable':
arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain'
has no member named 'clktrctrl_mask'
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Fix the build break with use of ARCH_OMAP2PLUS instead of OMAP2 or
OMAP3
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-
omap2/clockdomain.h
index de3faa2..6fa82f5 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -103,7 +103,7 @@ struct clockdomain {
const char *name;
struct powerdomain *ptr;
} pwrdm;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_ARCH_OMAP2PLUS
No need for this, just drop the #ifdef...
Perfect. Will fix this in v2
const u16 clktrctrl_mask;
- Paul
--
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/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following:
[..]
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/plat-omap/include/plat/voltage.h
index 710f4ea..c095351 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -65,9 +65,6 @@ struct voltagedomain {
char *name;
};
-/* API to get the voltagedomain pointer */
-struct voltagedomain *omap_voltage_domain_lookup(char *name);
-
/**
* struct omap_volt_data - Omap voltage specific data.
* @voltage_nominal: The possible voltage value in uV
@@ -131,6 +128,9 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info);
void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method);
+/* API to get the voltagedomain pointer */
+struct voltagedomain *omap_voltage_domain_lookup(char *name);
+
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
@@ -144,6 +144,10 @@ static inline int omap_voltage_late_init(void)
{
return -EINVAL;
}
+static inline struct voltagedomain *omap_voltage_domain_lookup(char *name)
+{
+ return NULL;
the omap_voltage_domain_lookup uses ERR_PTR() for all return values
which are handled by the callers with IS_ERR()
I think you should return ERR_PTR(-EINVAL)
--
Regards,
Nishanth Menon
--
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/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Wednesday, January 05, 2011 12:16 AM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Thara Gopinath; Kevin Hilman
Subject: Re: [PATCH 4/5] omap2plus: voltage: Trivial linking fix
'undefined reference'
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
following:
[..]
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/plat-omap/include/plat/voltage.h
index 710f4ea..c095351 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -65,9 +65,6 @@ struct voltagedomain {
char *name;
};
-/* API to get the voltagedomain pointer */
-struct voltagedomain *omap_voltage_domain_lookup(char *name);
-
/**
* struct omap_volt_data - Omap voltage specific data.
* @voltage_nominal: The possible voltage value in uV
@@ -131,6 +128,9 @@ int omap_voltage_register_pmic(struct
voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info);
void omap_change_voltscale_method(struct voltagedomain *voltdm,
int voltscale_method);
+/* API to get the voltagedomain pointer */
+struct voltagedomain *omap_voltage_domain_lookup(char *name);
+
int omap_voltage_late_init(void);
#else
static inline int omap_voltage_register_pmic(struct voltagedomain
*voltdm,
@@ -144,6 +144,10 @@ static inline int
omap_voltage_late_init(void)
{
return -EINVAL;
}
+static inline struct voltagedomain
*omap_voltage_domain_lookup(char *name)
+{
+ return NULL;
the omap_voltage_domain_lookup uses ERR_PTR() for all return values
which are handled by the callers with IS_ERR()
I think you should return ERR_PTR(-EINVAL)
The expected return value is pointer type and hence used
NULL.
--
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/3] perf: add OMAP support for the new power events
Hello Jean,
On Tue, 4 Jan 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The patch adds the new power management trace points for
the OMAP architecture.
The trace points are for:
- default idle handler. Since the cpuidle framework is
instrumented in the generic way there is no need to
add trace points in the OMAP specific cpuidle handler;
- cpufreq (DVFS),
- clocks changes (enable, disable, set_rate),
A question about these. Are these only meant to track calls to these
functions from outside the clock code? Or meant to track actual hardware
clock changes? If the latter, then it might make sense to put these
trace points into the functions that actually change the hardware
registers, e.g., omap2_dflt_clk_{enable,disable}(), etc., since a
clk_enable() on a leaf clock may result in many internal system clocks
being enabled up the clock tree.
- Paul
- change of power domains next power states.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |7 +++
arch/arm/mach-omap2/powerdomain.c |3 +++
arch/arm/plat-omap/clock.c| 13 ++---
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..0ee0b0e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include linux/delay.h
#include linux/slab.h
#include linux/console.h
+#include trace/events/power.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -506,8 +507,14 @@ static void omap3_pm_idle(void)
if (omap_irq_pending() || need_resched())
goto out;
+ trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+ trace_cpu_idle(1, smp_processor_id());
+
omap_sram_idle();
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+
out:
local_fiq_enable();
local_irq_enable();
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 fc62fb5..7cbb09b 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 (ret == 0) {
if (clk-recalc)
clk-rate = clk-recalc(clk);
--
1.7.2.3
- Paul
--
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 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following: CC arch/arm/mach-omap2/omap_hwmod_common_data.o In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38, from arch/arm/mach-omap2/omap_hwmod_common_data.c:20: arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init': arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function) arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.) make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 The error is reported when omap2plus_defconfig built with CONFIG_PM disabled Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/plat/voltage.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h index c095351..2b776f0 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -14,6 +14,8 @@ #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H +#include linux/err.h + Not sure if this is better OR including the err.h in c files is better, since the c file is the location where the error code is actually used.. but no strong feelings about either personally. [..] -- Regards, Nishanth Menon -- 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/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Wednesday, January 05, 2011 12:18 AM
To: Nishanth Menon
Cc: linux-omap@vger.kernel.org; Kevin Hilman; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Thara Gopinath; Kevin Hilman
Subject: RE: [PATCH 4/5] omap2plus: voltage: Trivial linking fix
'undefined reference'
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Wednesday, January 05, 2011 12:16 AM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Thara Gopinath; Kevin Hilman
Subject: Re: [PATCH 4/5] omap2plus: voltage: Trivial linking fix
'undefined reference'
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
following:
[..]
[..]
+static inline struct voltagedomain
*omap_voltage_domain_lookup(char *name)
+{
+ return NULL;
the omap_voltage_domain_lookup uses ERR_PTR() for all return
values
which are handled by the callers with IS_ERR()
I think you should return ERR_PTR(-EINVAL)
The expected return value is pointer type and hence used
NULL.
'ERR_PTR(-EINVAL)' is also ok.
--
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 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
-Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, January 05, 2011 12:19 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Thara Gopinath; Kevin Hilman Subject: Re: [PATCH 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following: CC arch/arm/mach-omap2/omap_hwmod_common_data.o In file included from arch/arm/plat- omap/include/plat/omap_hwmod.h:38, from arch/arm/mach- omap2/omap_hwmod_common_data.c:20: arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init': arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function) arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.) make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 The error is reported when omap2plus_defconfig built with CONFIG_PM disabled Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/plat/voltage.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h index c095351..2b776f0 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -14,6 +14,8 @@ #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H +#include linux/err.h + Not sure if this is better OR including the err.h in c files is better, since the c file is the location where the error code is actually used.. but no strong feelings about either personally. The error is because of 'EINVAL' usage in header file. How Will this error get fixed by including err.h is C file ? -- 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 v5 1/3] ARM: add CPPI 4.1 DMA support
Hello. Felipe Balbi wrote: On Tue, Jan 04, 2011 at 11:41:05PM +0800, Ming Lei wrote: OMAP GPIOs have many usages or use cases, so we can use gpiolib to simplify access to GPIOs. If GPIOs has only one usage or use case, it is not necessary to access GPIOs by gpiolib. Now this kind of DMA controllers are only used by MUSB or only for MUSB, so it doesn't matter to access them by dmaengine or not. Not entirely true. TUSB uses OMAP system DMA and AFAICT CPPI is used also for ethernet. Yes, but the CPPI registers are not compatible between MUSB and EMAC, only the descriptors are, AFAIK. WBR, Sergei -- 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/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
Santosh Shilimkar had written, on 01/04/2011 12:50 PM, the following:
[..]
+static inline struct voltagedomain
*omap_voltage_domain_lookup(char *name)
+{
+ return NULL;
the omap_voltage_domain_lookup uses ERR_PTR() for all return
values
which are handled by the callers with IS_ERR()
I think you should return ERR_PTR(-EINVAL)
The expected return value is pointer type and hence used
NULL.
'ERR_PTR(-EINVAL)' is also ok.
looking at the implementation (when CONFIG_PM is enabled),
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/voltage.c;h=ed6079c94c57bae30f599bbad5e25a38fc676fa8;hb=refs/heads/omap-for-linus#l1487
ERR_PTR(-EINVAL) looks more appropriate to me.
--
Regards,
Nishanth Menon
--
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 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
Santosh Shilimkar had written, on 01/04/2011 12:51 PM, the following: -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, January 05, 2011 12:19 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Thara Gopinath; Kevin Hilman Subject: Re: [PATCH 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following: CC arch/arm/mach-omap2/omap_hwmod_common_data.o In file included from arch/arm/plat- omap/include/plat/omap_hwmod.h:38, from arch/arm/mach- omap2/omap_hwmod_common_data.c:20: arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init': arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function) arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.) make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 The error is reported when omap2plus_defconfig built with CONFIG_PM disabled Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/plat/voltage.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h index c095351..2b776f0 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -14,6 +14,8 @@ #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H +#include linux/err.h + Not sure if this is better OR including the err.h in c files is better, since the c file is the location where the error code is actually used.. but no strong feelings about either personally. The error is because of 'EINVAL' usage in header file. How Will this error get fixed by including err.h is C file ? --- a/arch/arm/mach-omap2/omap_hwmod_common_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c @@ -16,6 +16,7 @@ * data and their integration with other OMAP modules and Linux. */ +#include linux/err.h #include plat/omap_hwmod.h #include omap_hwmod_common_data.h no? Basically, this points that omap_hwmod_common_data.c does not use the error return values, which probably gets hidden by including err.h in the header itself.. in this particular case, maynot be important, and probably apis which should have return values checked should be marked so.. anyways, just my 2 cents - no hard opinions about either as far as I am concerned. -- Regards, Nishanth Menon -- 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: [RFT/PATCH 05/10] cbus: retu: move to threaded IRQ and GENIRQ
* Felipe Balbi ba...@ti.com [110103 23:47]:
On Tue, Jan 04, 2011 at 09:46:15AM +0200, Felipe Balbi wrote:
@@ -593,6 +594,14 @@ static struct twl4030_platform_data sdp3430_twldata = {
.vpll2 = sdp3430_vpll2,
};
+static void __init sdp3430_twl_init(void)
+{
+ int irq_base = omap_irq_get_base();
+
+ sdp3430_twldata.irq_base = irq_base;
+ sdp3430_twldata.irq_end = irq_base + TWL4030_BASE_NR_IRQS;
+}
+
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl4030, 0x48),
this hunk should be:
@@ -593,6 +594,16 @@ static struct twl4030_platform_data sdp3430_twldata = {
.vpll2 = sdp3430_vpll2,
};
+static void __init sdp3430_twl_init(void)
+{
+ int irq_base = omap_irq_get_base();
+
+ sdp3430_twldata.irq_base = irq_base;
+ sdp3430_twldata.irq_end = irq_base + TWL4030_BASE_NR_IRQS;
+
+ omap_irq_add(TWL4030_BASE_NR_IRQS);
+}
+
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl4030, 0x48),
otherwise it won't work for other irq_chips
I think there's been some patches related to this to get rid
of NR_IRQS? Might be worth taking a look at those first as it's
a generic solution.
Regards,
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: [PATCH] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
* Ohad Ben-Cohen o...@wizery.com [110104 10:04]: On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen o...@wizery.com wrote: Power to the wl12xx wlan device is controlled by a fixed regulator. Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so users will not be baffled. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Hi Tony, Gentle reminder, This is queued for 2.6.38 in omap-for-linus as commit 7c50152f0851e44ef7491546a29fddbbea47735b? 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: [PATCH] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
On Tue, Jan 4, 2011 at 9:17 PM, Tony Lindgren t...@atomide.com wrote: * Ohad Ben-Cohen o...@wizery.com [110104 10:04]: On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen o...@wizery.com wrote: Power to the wl12xx wlan device is controlled by a fixed regulator. Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so users will not be baffled. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Hi Tony, Gentle reminder, This is queued for 2.6.38 in omap-for-linus as commit 7c50152f0851e44ef7491546a29fddbbea47735b? Thanks! 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
[PATCH 1/5] omap3|4: mux: make local structures static
Mux data is passed by pointers to mux.c from the SoC specific
mux file, these variables dont really need to be global scope.
This fixes the following sparse warnings:
arch/arm/mach-omap2/mux44xx.c:547:29: warning: symbol 'omap4_core_cbl_ball' was
not declared. Should it be static?
arch/arm/mach-omap2/mux44xx.c:1265:29: warning: symbol 'omap4_core_cbs_ball'
was not declared. Should it be static?
arch/arm/mach-omap2/mux44xx.c:1549:29: warning: symbol
'omap4_wkup_cbl_cbs_ball' was not declared. Should it be static?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/mux34xx.c |4 ++--
arch/arm/mach-omap2/mux44xx.c |6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index 440c98e..17f80e4 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -703,7 +703,7 @@ static struct omap_mux __initdata omap3_muxmodes[] = {
* Signals different on CBC package compared to the superset
*/
#if defined(CONFIG_OMAP_MUX) defined(CONFIG_OMAP_PACKAGE_CBC)
-struct omap_mux __initdata omap3_cbc_subset[] = {
+static struct omap_mux __initdata omap3_cbc_subset[] = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -721,7 +721,7 @@ struct omap_mux __initdata omap3_cbc_subset[] = {
*/
#if defined(CONFIG_OMAP_MUX) defined(CONFIG_DEBUG_FS) \
defined(CONFIG_OMAP_PACKAGE_CBC)
-struct omap_ball __initdata omap3_cbc_ball[] = {
+static struct omap_ball __initdata omap3_cbc_ball[] = {
_OMAP3_BALLENTRY(CAM_D0, ae16, NULL),
_OMAP3_BALLENTRY(CAM_D1, ae15, NULL),
_OMAP3_BALLENTRY(CAM_D10, d25, NULL),
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index 980f11d..c322e7b 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -544,7 +544,7 @@ static struct omap_mux __initdata omap4_core_muxmodes[] = {
*/
#if defined(CONFIG_OMAP_MUX) defined(CONFIG_DEBUG_FS) \
defined(CONFIG_OMAP_PACKAGE_CBL)
-struct omap_ball __initdata omap4_core_cbl_ball[] = {
+static struct omap_ball __initdata omap4_core_cbl_ball[] = {
_OMAP4_BALLENTRY(GPMC_AD0, c12, NULL),
_OMAP4_BALLENTRY(GPMC_AD1, d12, NULL),
_OMAP4_BALLENTRY(GPMC_AD2, c13, NULL),
@@ -1262,7 +1262,7 @@ static struct omap_mux __initdata
omap4_es2_core_muxmodes[] = {
*/
#if defined(CONFIG_OMAP_MUX) defined(CONFIG_DEBUG_FS) \
defined(CONFIG_OMAP_PACKAGE_CBS)
-struct omap_ball __initdata omap4_core_cbs_ball[] = {
+static struct omap_ball __initdata omap4_core_cbs_ball[] = {
_OMAP4_BALLENTRY(GPMC_AD0, c12, NULL),
_OMAP4_BALLENTRY(GPMC_AD1, d12, NULL),
_OMAP4_BALLENTRY(GPMC_AD2, c13, NULL),
@@ -1546,7 +1546,7 @@ static struct omap_mux __initdata omap4_wkup_muxmodes[] =
{
*/
#if defined(CONFIG_OMAP_MUX) defined(CONFIG_DEBUG_FS) \
defined(CONFIG_OMAP_PACKAGE_CBL)
-struct omap_ball __initdata omap4_wkup_cbl_cbs_ball[] = {
+static struct omap_ball __initdata omap4_wkup_cbl_cbs_ball[] = {
_OMAP4_BALLENTRY(SIM_IO, h4, NULL),
_OMAP4_BALLENTRY(SIM_CLK, j2, NULL),
_OMAP4_BALLENTRY(SIM_RESET, g2, NULL),
--
1.6.3.3
--
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/5] omap2+: wdt: trivial sparse fixes
omap2_wd_timer_disable is declared in wdtimer.h and used by hwmod
function pointers for usage, the header inclusion is necessary
to ensure that the prototype and function remains consistent.
omap_wdt_latency is passed as a pointer and does not need global scope
Fixes sparse warnings:
arch/arm/mach-omap2/devices.c:981:31: warning: symbol 'omap_wdt_latency' was
not declared. Should it be static?
arch/arm/mach-omap2/wd_timer.c:27:5: warning: symbol 'omap2_wd_timer_disable'
was not declared. Should it be static?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/wd_timer.c |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 381f4eb..2c9c912 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -978,7 +978,7 @@ static int __init omap2_init_devices(void)
arch_initcall(omap2_init_devices);
#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-struct omap_device_pm_latency omap_wdt_latency[] = {
+static struct omap_device_pm_latency omap_wdt_latency[] = {
[0] = {
.deactivate_func = omap_device_idle_hwmods,
.activate_func = omap_device_enable_hwmods,
diff --git a/arch/arm/mach-omap2/wd_timer.c b/arch/arm/mach-omap2/wd_timer.c
index b0c4907..4067669 100644
--- a/arch/arm/mach-omap2/wd_timer.c
+++ b/arch/arm/mach-omap2/wd_timer.c
@@ -13,6 +13,8 @@
#include plat/omap_hwmod.h
+#include wd_timer.h
+
/*
* In order to avoid any assumptions from bootloader regarding WDT
* settings, WDT module is reset during init. This enables the watchdog
--
1.6.3.3
--
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/5] omap2+: pm_bus: make functions used as pointers as static
omap_pm_runtime_suspend and omap_pm_runtime_resume are used
as function pointers and does not really need to be exposed
to the world.
Fixes sparse warnings:
arch/arm/mach-omap2/pm_bus.c:23:5: warning: symbol 'omap_pm_runtime_suspend'
was not declared. Should it be static?
arch/arm/mach-omap2/pm_bus.c:40:5: warning: symbol 'omap_pm_runtime_resume' was
not declared. Should it be static?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm_bus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
index 784989f..5acd2ab 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -20,7 +20,7 @@
#include plat/omap-pm.h
#ifdef CONFIG_PM_RUNTIME
-int omap_pm_runtime_suspend(struct device *dev)
+static int omap_pm_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
int r, ret = 0;
@@ -37,7 +37,7 @@ int omap_pm_runtime_suspend(struct device *dev)
return ret;
};
-int omap_pm_runtime_resume(struct device *dev)
+static int omap_pm_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
int r;
--
1.6.3.3
--
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/5] OMAP2+: trivial sparse fixes
Source: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch: omap-for-linus (dc69d1a omap2: Make OMAP2PLUS select OMAP_DM_TIMER) Building for sparse warnings result in the following warnings: http://pastebin.mozilla.org/907954 This is series 2 of the sparse fixes (series 1: http://marc.info/?t=12940811803r=1w=2 and http://marc.info/?t=12940835272r=1w=2) Nishanth Menon (5): omap3|4: mux: make local structures static omap3: zoom: use static for pointer passing omap3: igep3: make igep3_flash_init static omap2+: wdt: trivial sparse fixes omap2+: pm_bus: make functions used as pointers as static arch/arm/mach-omap2/board-igep0030.c |4 ++-- arch/arm/mach-omap2/board-zoom-peripherals.c |4 ++-- arch/arm/mach-omap2/devices.c|2 +- arch/arm/mach-omap2/mux34xx.c|4 ++-- arch/arm/mach-omap2/mux44xx.c|6 +++--- arch/arm/mach-omap2/pm_bus.c |4 ++-- arch/arm/mach-omap2/wd_timer.c |2 ++ 7 files changed, 14 insertions(+), 12 deletions(-) --- Regards, Nishanth Menon -- 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 0/4] Introduce hardware spinlock framework
On Tue, 4 Jan 2011 14:23:20 +0200 Ohad Ben-Cohen o...@wizery.com wrote: Hi Andrew, On Sat, Dec 18, 2010 at 2:53 AM, Tony Lindgren t...@atomide.com wrote: * Ohad Ben-Cohen o...@wizery.com [101216 13:34]: Tony, Andrew, can you please have a look ? Any comment or suggestion is appreciated. Looks sane to me from omap point of view and it seems the locks are now all timeout based: Acked-by: Tony Lindgren t...@atomide.com Can you please have a look at this patch set (see link no. [1] below) ? I looked - it looks reasonable. This is exactly the wrong time to be looking at large new patchsets - please refresh, retest and resend after -rc1 is released? -- 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: TWL: sparse fixes
Nishanth Menon had written, on 01/03/2011 04:39 PM, the following: Russell King - ARM Linux had written, on 01/03/2011 04:36 PM, the following: On Mon, Jan 03, 2011 at 12:58:28PM -0600, Nishanth Menon wrote: Source: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch: omap-for-linus Doing a rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/ resulted in the following sparse warnings: http://pastebin.mozilla.org/907954 FYI, you may like to try: make C=2 arch/arm/mach-omap2/ instead of the two-step process: | Do a kernel make with make C=1 to run sparse on all the C files that get | recompiled, or use make C=2 to run sparse on the files whether they need to | be recompiled or not. The latter is a fast way to check the whole tree if you | have already built it. Gee thanks. /me should update my old bash aliases :D hmm.. minor nit (with codesourcery 2010.09-50 - 4.5.1): rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/ 2Kerr;make C=2 arch/arm/mach-omap2/ 2Kerr1;diff Kerr Kerr1 [..] 1,4d0 arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_by_name': arch/arm/mach-omap2/mux.c:163:17: warning: 'found_mode' may be used uninitialized in this function arch/arm/mach-omap2/clkt_clksel.c: In function 'omap2_clksel_set_parent': arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be used uninitialized in this function Kinda interesting to note that C=2 does'nt list all potential gcc warnings :( if one wanted a collated list of all warnings, rm .../*.o helps I guess. -- Regards, Nishanth Menon -- 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 0/4] Introduce hardware spinlock framework
On Tue, Jan 4, 2011 at 10:19 PM, Andrew Morton a...@linux-foundation.org wrote: Acked-by: Tony Lindgren t...@atomide.com Can you please have a look at this patch set (see link no. [1] below) ? I looked - it looks reasonable. This is exactly the wrong time to be looking at large new patchsets - please refresh, retest and resend after -rc1 is released? Sure, thanks ! -- 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/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
Hi Russell, On Tue, Jan 04, 2011 at 05:33:01PM +, Russell King - ARM Linux wrote: On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-König wrote: On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote: @@ -171,9 +168,6 @@ config FIQ config ARCH_MTD_XIP bool -config GENERIC_HARDIRQS_NO__DO_IRQ - def_bool y - You didn't mention this change in the commit log. Is this duplicated, too or did it just slip through? If you look at kernel/irq/Kconfig (as I did with the original patch) you'd notice kernel/irq/Kconfig defines both of these symbols being removed when HAVE_GENERIC_HARDIRQS is enabled. If you read the discussion in the previous version of this patch set, you'd notice that the removal of this was specifically requested. It's very tiresome to have to re-explain these things. Please take some more time to research the points you bring up, rather than I don't agree here 100%. IMHO the commit log was not good enough for the change introduced by the patch (and Felipe's reply suggests that he agrees). I could still research it, but: - it was not obvious for me there was a previous version (no v2 or similar in the patch subject); - for me it would take say 5 minutes to check, the author knows the answer to my question immediately (at least he should); - after a research I could suggest a better wording, but I don't care much if it's me or Felipe who comes up with a better text. So all in all I'm still confident that my mail was OK. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: TWL: sparse fixes
On Tue, 2011-01-04 at 10:00 -0800, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: Source: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git branch: omap-for-linus Doing a rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/ resulted in the following sparse warnings: http://pastebin.mozilla.org/907954 This series fixes the twl warnings Nishanth Menon (2): OMAP2+: TWL: make conversion routines static OMAP2+: TWL: include pm header for init protos arch/arm/mach-omap2/omap_twl.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) Acked-by: Kevin Hilman khil...@ti.com Tony, these should probably queue for .38 if it's not too late. On second thought, it's too late for the main 2.6.38 merge window for these. I'll queue these in my pm-fixes branch for the 2.6.38-rc cycle. 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] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
On Tue, 2011-01-04 at 09:52 -0800, Kevin Hilman wrote: Mika Westerberg ext-mika.1.westerb...@nokia.com writes: In case on OMAP2+ we call set_24xx_gpio_triggering() instead of updating reg and l values. However, at the end of the function we perform a write: __raw_writel(l, reg); So on OMAP2+ we end up writing 0 to the bank-base which is not correct (typically this points to GPIO_REVISION register). Fix this by returning immediately after call to set_24xx_gpio_triggering(). Signed-off-by: Mika Westerberg ext-mika.1.westerb...@nokia.com Acked-by: Kevin Hilman khil...@ti.com Tony, this should be added to omap-for-linus as it fixes a problem in the recently merged GPIO omap_device/hwmod conversion. On second thought, it's a bit late for the main 2.6.38 window, so will queue this in my pm-fixes branch for the .38-rc cycle. 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] OMAP3: PM: Adding T2 enabling of smartreflex
Thara Gopinath th...@ti.com writes:
The smartreflex bit on twl4030 needs to be enabled by default irrespective
of whether smartreflex module is enabled on the OMAP side or not.
This is because without this bit enabled the voltage scaling through
vp forceupdate does not function properly on OMAP3.
Based on Nishanth's comments, the abofe statements need a little more
justification.
What is probably needed is some default setting (possibly this one) but
with the possibility of board code to disable this if needed.
Kevin
Signed-off-by: Thara Gopinath th...@ti.com
---
This patch is against LO master and has been
tested on OMAP3430 SDP and OMAP2430 SDP.
arch/arm/mach-omap2/omap_twl.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 15f8c6c..a59f36b 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -58,7 +58,9 @@
static bool is_offset_valid;
static u8 smps_offset;
+#define TWL4030_DCDC_GLOBAL_CFG 0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -256,6 +258,7 @@ int __init omap4_twl_init(void)
int __init omap3_twl_init(void)
{
struct voltagedomain *voltdm;
+ u8 temp;
if (!cpu_is_omap34xx())
return -ENODEV;
@@ -267,6 +270,19 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
+ /*
+ * The smartreflex bit on twl4030 needs to be enabled by
+ * default irrespective of whether smartreflex module is
+ * enabled on the OMAP side or not. This is because without
+ * this bit enabled the voltage scaling through
+ * vp forceupdate does not function properly on OMAP3.
+ */
+ twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ temp |= SMARTREFLEX_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
--
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/3] perf: add calls to suspend trace point
On Tuesday, January 04, 2011, Jean Pihet wrote:
Hi,
On Tue, Jan 4, 2011 at 12:29 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
---
kernel/power/suspend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ecf7705..0650596 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include linux/mm.h
#include linux/slab.h
#include linux/suspend.h
+#include trace/events/power.h
#include power.h
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops-enter(state);
+ trace_machine_suspend(PWR_EVENT_EXIT);
events_check_enabled = false;
}
sysdev_resume();
Ok... why this place?
This trace has been placed here because it traces the machine low
level mode enter.
I mean, perhaps suspend time should include
device suspend?
That makes sense. We have a few options here:
1) keep the traces as proposed to trace the low level machine code only,
2) move the traces to the entry and exit of suspend_enter so that it
includes the prepare and late_prepare (+ the associated wake-up)
callbacks as well,
3) move the traces to suspend_devices_and_enter so that it includes 2)
and the handling of the console and the devices,
4) move the traces to enter_state do that it includes 3), the call to
sys_sync and the user space freeze.
Note that the the SNAPSHOT_2RAM ioctl code also calls
suspend_devices_and_enter, so if only 4) is used no trace will be
generated in that case.
I am in favor of 3) of 4).
What do you think?
Why don't we keep the tracepoints as proposed _and_ add two additional
tracepoints around device suspend-resume?
Rafael
--
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] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
* Kevin Hilman khil...@ti.com [110104 14:45]: On Tue, 2011-01-04 at 09:52 -0800, Kevin Hilman wrote: Mika Westerberg ext-mika.1.westerb...@nokia.com writes: In case on OMAP2+ we call set_24xx_gpio_triggering() instead of updating reg and l values. However, at the end of the function we perform a write: __raw_writel(l, reg); So on OMAP2+ we end up writing 0 to the bank-base which is not correct (typically this points to GPIO_REVISION register). Fix this by returning immediately after call to set_24xx_gpio_triggering(). Signed-off-by: Mika Westerberg ext-mika.1.westerb...@nokia.com Acked-by: Kevin Hilman khil...@ti.com Tony, this should be added to omap-for-linus as it fixes a problem in the recently merged GPIO omap_device/hwmod conversion. On second thought, it's a bit late for the main 2.6.38 window, so will queue this in my pm-fixes branch for the .38-rc cycle. Yeah let's not mess with omap-for-linus right now, but instead start queueing up fixes for -rc1. 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: [PATCH v3 1/4] TI816X: Update common omap platform files
* Paul Walmsley p...@pwsan.com [110104 09:48]: On Tue, 4 Jan 2011, Pedanekar, Hemant wrote: Looking at above, it seems another config option like CONFIG_SOC_OMAP3XXX is also needed in addition to CONFIG_SOC_OMAPTI816X. We already have CONFIG_ARCH_OMAP3430, CONFIG_ARCH_OMAP2430, and CONFIG_ARCH_OMAP2420. I guess at some point those need to be renamed to CONFIG_SOC_*. Yes that's what I was thinking too. Keep CONFIG_ARCH_OMAP2, 3, and 4, and rename CONFIG_ARCH_OMAP3430 etc to CONFIG_SO_COMAP3430 and so on. Regards, 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
[PATCH] omap: Start using CONFIG_SOC_OMAP (Re: [PATCH v3 1/4] TI816X: Update common omap platform files)
* Tony Lindgren t...@atomide.com [110104 15:25]: * Paul Walmsley p...@pwsan.com [110104 09:48]: On Tue, 4 Jan 2011, Pedanekar, Hemant wrote: Looking at above, it seems another config option like CONFIG_SOC_OMAP3XXX is also needed in addition to CONFIG_SOC_OMAPTI816X. We already have CONFIG_ARCH_OMAP3430, CONFIG_ARCH_OMAP2430, and CONFIG_ARCH_OMAP2420. I guess at some point those need to be renamed to CONFIG_SOC_*. Yes that's what I was thinking too. Keep CONFIG_ARCH_OMAP2, 3, and 4, and rename CONFIG_ARCH_OMAP3430 etc to CONFIG_SO_COMAP3430 and so on. Here's a patch to do that for 2.6.39, will update this after the merge window is over. Note that we should keep this separate from adding CONFIG_SOC_OMAPTI816X, that can be already done even without this patch. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Tue, 4 Jan 2011 15:32:32 -0800 Subject: [PATCH] omap: Start using CONFIG_SOC_OMAP We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest are nowadays just subcategories of these. Search and replace the following: ARCH_OMAP2420 SOC_OMAP2420 ARCH_OMAP2430 SOC_OMAP2430 ARCH_OMAP3430 SOC_OMAP3430 No functional changes. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3e8c9e8..fe9f079 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -52,20 +52,20 @@ config ARCH_OMAP4 comment OMAP Core Type depends on ARCH_OMAP2 -config ARCH_OMAP2420 +config SOC_OMAP2420 bool OMAP2420 support depends on ARCH_OMAP2 default y select OMAP_DM_TIMER select ARCH_OMAP_OTG -config ARCH_OMAP2430 +config SOC_OMAP2430 bool OMAP2430 support depends on ARCH_OMAP2 default y select ARCH_OMAP_OTG -config ARCH_OMAP3430 +config SOC_OMAP3430 bool OMAP3430 support depends on ARCH_OMAP3 default y @@ -105,25 +105,25 @@ config MACH_OMAP_GENERIC config MACH_OMAP2_TUSB6010 bool - depends on ARCH_OMAP2 ARCH_OMAP2420 + depends on ARCH_OMAP2 SOC_OMAP2420 default y if MACH_NOKIA_N8X0 config MACH_OMAP_H4 bool OMAP 2420 H4 board - depends on ARCH_OMAP2420 + depends on SOC_OMAP2420 default y select OMAP_PACKAGE_ZAF select OMAP_DEBUG_DEVICES config MACH_OMAP_APOLLON bool OMAP 2420 Apollon board - depends on ARCH_OMAP2420 + depends on SOC_OMAP2420 default y select OMAP_PACKAGE_ZAC config MACH_OMAP_2430SDP bool OMAP 2430 SDP board - depends on ARCH_OMAP2430 + depends on SOC_OMAP2430 default y select OMAP_PACKAGE_ZAC @@ -218,7 +218,7 @@ config MACH_NOKIA_N810_WIMAX config MACH_NOKIA_N8X0 bool Nokia N800/N810 - depends on ARCH_OMAP2420 + depends on SOC_OMAP2420 default y select OMAP_PACKAGE_ZAC select MACH_NOKIA_N800 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 4ab82f6..0cbdf30 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -31,8 +31,8 @@ AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a$(plus_sec) # Functions loaded to SRAM -obj-$(CONFIG_ARCH_OMAP2420)+= sram242x.o -obj-$(CONFIG_ARCH_OMAP2430)+= sram243x.o +obj-$(CONFIG_SOC_OMAP2420) += sram242x.o +obj-$(CONFIG_SOC_OMAP2430) += sram243x.o obj-$(CONFIG_ARCH_OMAP3) += sram34xx.o AFLAGS_sram242x.o :=-Wa,-march=armv6 @@ -40,8 +40,8 @@ AFLAGS_sram243x.o :=-Wa,-march=armv6 AFLAGS_sram34xx.o :=-Wa,-march=armv7-a # Pin multiplexing -obj-$(CONFIG_ARCH_OMAP2420)+= mux2420.o -obj-$(CONFIG_ARCH_OMAP2430)+= mux2430.o +obj-$(CONFIG_SOC_OMAP2420) += mux2420.o +obj-$(CONFIG_SOC_OMAP2430) += mux2430.o obj-$(CONFIG_ARCH_OMAP3) += mux34xx.o obj-$(CONFIG_ARCH_OMAP4) += mux44xx.o @@ -113,8 +113,8 @@ obj-$(CONFIG_ARCH_OMAP2)+= $(clock-common) clock2xxx.o \ clkt2xxx_dpllcore.o \ clkt2xxx_virt_prcm_set.o \ clkt2xxx_apll.o clkt2xxx_osc.o -obj-$(CONFIG_ARCH_OMAP2420)+= clock2420_data.o -obj-$(CONFIG_ARCH_OMAP2430)+= clock2430.o clock2430_data.o +obj-$(CONFIG_SOC_OMAP2420) += clock2420_data.o +obj-$(CONFIG_SOC_OMAP2430) += clock2430.o clock2430_data.o obj-$(CONFIG_ARCH_OMAP3) += $(clock-common) clock3xxx.o \ clock34xx.o clkt34xx_dpll3m2.o \ clock3517.o clock36xx.o \ @@ -123,12 +123,12 @@
Re: [PATCH v3 06/17] OMAP2,3 DSS2 Move DSS driver register from board file to devices.c
Guruswamy Senthilvadivu svad...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
omap_display_init function is introduced in devices.c to do the DSS driver
registration. So replace platform_device_register or platform_add_devices of
DSS with omap_display_init().
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Minor nit: rather than continuing to grow devices.c, how about creating
a new display.c that handles this.
Kevin
---
arch/arm/mach-omap2/board-3430sdp.c | 14 +---
arch/arm/mach-omap2/board-am3517evm.c | 16 +-
arch/arm/mach-omap2/board-cm-t35.c| 10 +
arch/arm/mach-omap2/board-devkit8000.c| 10 +
arch/arm/mach-omap2/board-igep0020.c | 10 +
arch/arm/mach-omap2/board-omap3beagle.c | 10 +
arch/arm/mach-omap2/board-omap3evm.c | 14 +---
arch/arm/mach-omap2/board-omap3pandora.c | 10 +
arch/arm/mach-omap2/board-omap3stalker.c | 10 +
arch/arm/mach-omap2/board-rx51-video.c| 15 +
arch/arm/mach-omap2/devices.c | 32
+
arch/arm/plat-omap/include/plat/display.h |4 +++
12 files changed, 46 insertions(+), 109 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 29e56a2..e1a3318 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -301,21 +301,9 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = sdp3430_lcd_device,
};
-static struct platform_device sdp3430_dss_device = {
- .name = omap_display,
- .id = -1,
- .dev= {
- .platform_data = sdp3430_dss_data,
- },
-};
-
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
REGULATOR_SUPPLY(vdda_dac, omap_display);
-static struct platform_device *sdp3430_devices[] __initdata = {
- sdp3430_dss_device,
-};
-
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
@@ -790,7 +778,7 @@ static void __init omap_3430sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
- platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ omap_display_init(sdp3430_dss_data);
if (omap_rev() OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 2b37dcf..782d270 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -367,24 +367,12 @@ static struct omap_dss_board_info am3517_evm_dss_data =
{
.default_device = am3517_evm_lcd_device,
};
-static struct platform_device am3517_evm_dss_device = {
- .name = omap_display,
- .id = -1,
- .dev= {
- .platform_data = am3517_evm_dss_data,
- },
-};
-
/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
};
-static struct platform_device *am3517_evm_devices[] __initdata = {
- am3517_evm_dss_device,
-};
-
static void __init am3517_evm_init_irq(void)
{
omap_board_config = am3517_evm_config;
@@ -484,9 +472,7 @@ static void __init am3517_evm_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
am3517_evm_i2c_init();
- platform_add_devices(am3517_evm_devices,
- ARRAY_SIZE(am3517_evm_devices));
-
+ omap_display_init(am3517_evm_dss_data);
omap_serial_init();
/* Configure GPIO for EHCI port */
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 307e93a..c5e80ad 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -390,14 +390,6 @@ static struct omap_dss_board_info cm_t35_dss_data = {
.default_device = cm_t35_dvi_device,
};
-static struct platform_device cm_t35_dss_device = {
- .name = omap_display,
- .id = -1,
- .dev= {
- .platform_data = cm_t35_dss_data,
- },
-};
-
static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,/* 0: slave, 1: master */
@@ -457,7 +449,7 @@ static void __init cm_t35_init_display(void)
msleep(50);
gpio_set_value(lcd_en_gpio, 1);
- err = platform_device_register(cm_t35_dss_device);
+ err = omap_display_init(cm_t35_dss_data);
if (err) {
pr_err(CM-T35: failed to register DSS device\n);
goto err_dev_reg;
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index f948435..78f2951 100644
---
Re: [PATCH v3 08/17] OMAP2,3: DSS2: Create platform_driver for each DSS HW IP
Guruswamy Senthilvadivu svad...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform
driver.
Platform driver of dsshw has to be registered before of dispc, rfbi, dsi1,
venc and omapdisplay driver should be after all the HW IPs. Sequence it with
arch_initcall and device_initcall_sync.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Rather than creating a bunch of empty/dummy driver here to be populated
later, I'd prefer them to be created as needed in the subsequent
patches.
For example, the dispc parts of this patch should be added in PATCH 9
where you populate the functions. The RFBI parts of this patch should
be added in PATCH 12, etc. etc.
Kevin
---
drivers/video/omap2/dss/core.c |2 +-
drivers/video/omap2/dss/dispc.c | 28
drivers/video/omap2/dss/dsi.c | 29 -
drivers/video/omap2/dss/dss.c | 27 +++
drivers/video/omap2/dss/rfbi.c | 28
drivers/video/omap2/dss/venc.c | 28
6 files changed, 140 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..d165434 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -989,7 +989,7 @@ static int __init omap_dss_init2(void)
}
core_initcall(omap_dss_init);
-device_initcall(omap_dss_init2);
+device_initcall_sync(omap_dss_init2);
#endif
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com);
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fa40fa5..942dea5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3167,3 +3167,31 @@ int dispc_setup_plane(enum omap_plane plane,
return r;
}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = omap_dispc,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dispc_init(void)
+{
+ return platform_driver_register(omap_dispchw_driver);
+}
+
+device_initcall(omap_dispc_init);
+
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index aa4f7a5..037d366 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -292,7 +292,6 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
return __raw_readl(dsi.base + idx.idx);
}
-
void dsi_save_context(void)
{
}
@@ -3304,3 +3303,31 @@ void dsi_exit(void)
DSSDBG(omap_dsi_exit\n);
}
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsi1hw_driver = {
+ .probe = omap_dsi1hw_probe,
+ .remove = omap_dsi1hw_remove,
+ .driver = {
+ .name = omap_dsi1,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dsi1_init(void)
+{
+ return platform_driver_register(omap_dsi1hw_driver);
+}
+
+device_initcall(omap_dsi1_init);
+
+
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..6d0bd89 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -639,3 +639,30 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .driver = {
+ .name = omap_dss,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dss_init1(void)
+{
+ return platform_driver_register(omap_dsshw_driver);
+}
+
+arch_initcall(omap_dss_init1);
+
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index bbe6246..a086233 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1054,3 +1054,31 @@ int rfbi_init_display(struct omap_dss_device *dssdev)
dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
return 0;
}
+
+/* RFBI HW IP initialisation */
+static int omap_rfbihw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int
Re: [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly
Felipe Balbi ba...@ti.com writes:
Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.
Signed-off-by: Felipe Balbi ba...@ti.com
Can you refresh this one against Tony's omap-for-linus branch. The GPIO
omap_device/hwmod conversion changed things around a bit and this patch
doesn't apply.
After that, you can send separately, and I'll queue this one along with
some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
out.
Kevin
---
arch/arm/plat-omap/gpio.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..c351758 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
if (retval == 0) {
- irq_desc[irq].status = ~IRQ_TYPE_SENSE_MASK;
- irq_desc[irq].status |= type;
+ struct irq_desc *d = irq_to_desc(irq);
+
+ d-status = ~IRQ_TYPE_SENSE_MASK;
+ d-status |= type;
}
spin_unlock_irqrestore(bank-lock, flags);
@@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
for (j = bank-virtual_irq_start;
j bank-virtual_irq_start + gpio_count; j++) {
- lockdep_set_class(irq_desc[j].lock, gpio_lock_class);
+ struct irq_desc *d = irq_to_desc(j);
+
+ lockdep_set_class(d-lock, gpio_lock_class);
set_irq_chip_data(j, bank);
if (bank_is_mpuio(bank))
set_irq_chip(j, mpuio_irq_chip);
--
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: TWL: sparse fixes
On Tue, Jan 04, 2011 at 02:37:23PM -0600, Nishanth Menon wrote: hmm.. minor nit (with codesourcery 2010.09-50 - 4.5.1): rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/ 2Kerr;make C=2 arch/arm/mach-omap2/ 2Kerr1;diff Kerr Kerr1 [..] 1,4d0 arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_by_name': arch/arm/mach-omap2/mux.c:163:17: warning: 'found_mode' may be used uninitialized in this function arch/arm/mach-omap2/clkt_clksel.c: In function 'omap2_clksel_set_parent': arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be used uninitialized in this function Kinda interesting to note that C=2 does'nt list all potential gcc warnings :( if one wanted a collated list of all warnings, rm .../*.o helps I guess. C=2 only runs sparse - so if you're committing patches to fix sparse warnings, that's what you should be interested in. I'd suggest that fixing sparse warnings and GCC warnings in a single patch is probably not the best thing to do - GCC warnings are less subjective than sparse warnings. -- 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] arm: omap4: panda: remove usb_nop_xceiv_register
tom.leim...@gmail.com writes: From: Ming Lei tom.leim...@gmail.com Panda uses twl6030 otg phy instead of internal phy, so removes usb_nop_xceiv_register to make musb working. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Ming Lei tom.leim...@gmail.com Please Cc the linux-arm-kernel list for OMAP kernel patches targetted for upstream. Also, would be nice to get some Reviewed-by and/or Tested-by tags from Panda users on this one as well. Kevin --- arch/arm/mach-omap2/board-omap4panda.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 1ecd0a6..802ae20 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -374,8 +374,6 @@ static void __init omap4_panda_init(void) platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices)); omap_serial_init(); omap4_twl6030_hsmmc_init(mmc); - /* OMAP4 Panda uses internal transceiver so register nop transceiver */ - usb_nop_xceiv_register(); omap4_ehci_init(); /* FIXME: allow multi-omap to boot until musb is updated for omap4 */ if (!cpu_is_omap44xx()) -- 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/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
Santosh Shilimkar santosh.shilim...@ti.com writes: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, January 05, 2011 12:11 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; khil...@ti.com; t...@atomide.com; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg' Hi Santosh, On Tue, 4 Jan 2011, Santosh Shilimkar wrote: omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4 selected. This is because common files make references to the functions which are defined only for omap2xxx and omap3xxx. LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store': arch/arm/mach-omap2/pm-debug.c:335: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump': arch/arm/mach-omap2/pm-debug.c:121: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/pm-debug.c:123: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/pm-debug.c:124: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/pm-debug.c:125: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `omap_prcm_arch_reset': arch/arm/mach-omap2/prcm.c:106: undefined reference to `omap2_prm_set_mod_reg_bits' arch/arm/mach-omap2/prcm.c:108: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `omap_prcm_get_reset_sources': arch/arm/mach-omap2/prcm.c:53: undefined reference to `omap2_prm_read_mod_reg' arch/arm/mach-omap2/built-in.o: In function `clkdm_clear_all_wkdeps': arch/arm/mach-omap2/clockdomain.c:545: undefined reference to `omap2_prm_clear_mod_reg_bits' arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep': arch/arm/mach-omap2/clockdomain.c:475: undefined reference to `omap2_prm_clear_mod_reg_bits' arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep': arch/arm/mach-omap2/clockdomain.c:511: undefined reference to `omap2_prm_read_mod_bits_shift' arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep': arch/arm/mach-omap2/clockdomain.c:440: undefined reference to `omap2_prm_set_mod_reg_bits' make: *** [.tmp_vmlinux1] Error 1 This patch adds stubs for these functions so that build continues to work. Probably alternately the build can be fixed as below but that not seems to be the right way. Since these functions now return 0, maybe it would be better to call WARN() or BUG() in these functions for OMAP4. Otherwise, they are going to silently do the wrong thing, and someone needs to fix any usage of these functions where they shouldn't be used. e.g., in mach- omap2/prcm.c or mach-omap2/pm-debug.c ... Good point. Will update the patch accordingly and repost. Please use WARN() instead of BUG() as this is not worthy of causing a panic() for the whole kernel. 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 0/5] omap2plus: Trivial build break fixes
Santosh Shilimkar santosh.shilim...@ti.com writes: These are trivial build fixes which I found while doing some testing 'omap-for-linus' branch. The series is generated against the linux-omap 'omap-for-linus' branch and boot tested on OMAP4430 SDP and OMAP3630 ZOOM. Minor nit in your git-send-email config. Can you add the following to your ~/.gitconfig, or update to newer git where this is now the default: [sendemail] chainreplyto = false This will make all patches a reply to PATCH 0 instead of to the previous patch. Thanks, Kevin The following changes since commit dc69d1af9e8d9cbbabff88bb35a6782187a9: Ben Gamari (1): omap2: Make OMAP2PLUS select OMAP_DM_TIMER Santosh Shilimkar (5): omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg' omap2plus: voltage: Trivial warning fix 'no return statement' omap2plus: voltage: Trivial linking fix 'undefined reference' omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/clockdomain.h |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h| 45 - arch/arm/plat-omap/include/plat/voltage.h | 17 -- 4 files changed, 59 insertions(+), 7 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 5/5] omap2+: pm_bus: make functions used as pointers as static
Nishanth Menon n...@ti.com writes:
omap_pm_runtime_suspend and omap_pm_runtime_resume are used
as function pointers and does not really need to be exposed
to the world.
Fixes sparse warnings:
arch/arm/mach-omap2/pm_bus.c:23:5: warning: symbol 'omap_pm_runtime_suspend'
was not declared. Should it be static?
arch/arm/mach-omap2/pm_bus.c:40:5: warning: symbol 'omap_pm_runtime_resume'
was not declared. Should it be static?
Signed-off-by: Nishanth Menon n...@ti.com
Thanks, will queue this one in my pm-fixes branch for 2.6.38-rc.
Kevin
---
arch/arm/mach-omap2/pm_bus.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
index 784989f..5acd2ab 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -20,7 +20,7 @@
#include plat/omap-pm.h
#ifdef CONFIG_PM_RUNTIME
-int omap_pm_runtime_suspend(struct device *dev)
+static int omap_pm_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
int r, ret = 0;
@@ -37,7 +37,7 @@ int omap_pm_runtime_suspend(struct device *dev)
return ret;
};
-int omap_pm_runtime_resume(struct device *dev)
+static int omap_pm_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
int r;
--
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 08/17] OMAP2,3: DSS2: Create platform_driver for each DSS HW IP
Hi Kevin,
On Wed, Jan 5, 2011 at 5:37 AM, Kevin Hilman khil...@ti.com wrote:
Guruswamy Senthilvadivu svad...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Hwmod adaptation design requires each of the DSS HW IP to be a platform
driver.
Platform driver of dsshw has to be registered before of dispc, rfbi, dsi1,
venc and omapdisplay driver should be after all the HW IPs. Sequence it with
arch_initcall and device_initcall_sync.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Rather than creating a bunch of empty/dummy driver here to be populated
later, I'd prefer them to be created as needed in the subsequent
patches.
For example, the dispc parts of this patch should be added in PATCH 9
where you populate the functions. The RFBI parts of this patch should
be added in PATCH 12, etc. etc.
Thanks for your comments; since Senthil is going to be out for
sometime, I would make these changes and push as the next version;
will wait a bit for other comments too.
Best regards,
~Sumit.
Kevin
---
drivers/video/omap2/dss/core.c | 2 +-
drivers/video/omap2/dss/dispc.c | 28
drivers/video/omap2/dss/dsi.c | 29 -
drivers/video/omap2/dss/dss.c | 27 +++
drivers/video/omap2/dss/rfbi.c | 28
drivers/video/omap2/dss/venc.c | 28
6 files changed, 140 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 48d20d8..d165434 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -989,7 +989,7 @@ static int __init omap_dss_init2(void)
}
core_initcall(omap_dss_init);
-device_initcall(omap_dss_init2);
+device_initcall_sync(omap_dss_init2);
#endif
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com);
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index fa40fa5..942dea5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3167,3 +3167,31 @@ int dispc_setup_plane(enum omap_plane plane,
return r;
}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = omap_dispc,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dispc_init(void)
+{
+ return platform_driver_register(omap_dispchw_driver);
+}
+
+device_initcall(omap_dispc_init);
+
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index aa4f7a5..037d366 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -292,7 +292,6 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
return __raw_readl(dsi.base + idx.idx);
}
-
void dsi_save_context(void)
{
}
@@ -3304,3 +3303,31 @@ void dsi_exit(void)
DSSDBG(omap_dsi_exit\n);
}
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsi1hw_driver = {
+ .probe = omap_dsi1hw_probe,
+ .remove = omap_dsi1hw_remove,
+ .driver = {
+ .name = omap_dsi1,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dsi1_init(void)
+{
+ return platform_driver_register(omap_dsi1hw_driver);
+}
+
+device_initcall(omap_dsi1_init);
+
+
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..6d0bd89 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -639,3 +639,30 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .driver = {
+ .name = omap_dss,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_dss_init1(void)
+{
+ return platform_driver_register(omap_dsshw_driver);
+}
+
+arch_initcall(omap_dss_init1);
+
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index bbe6246..a086233 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1054,3 +1054,31 @@ int
[PATCH] staging: tidspbridge - configure full L1 MMU range
Otherwise a virtual address beyond of the L1 size is used,
the MMU hardware will look into a memory that does not belong to
L1 translation tables. IOW; the MMU would allow to access any
memory, configured or not.
Reported-by: Felipe Contreras felipe.contre...@nokia.com
Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/staging/tidspbridge/core/tiomap3430.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 1be081f..ec96d1e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -70,6 +70,7 @@
#define MMU_LARGE_PAGE_MASK 0x
#define MMU_SMALL_PAGE_MASK 0xF000
#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
+#define MMU_L1_SIZE 0x4000
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
@@ -786,10 +787,7 @@ static int bridge_dev_create(struct bridge_dev_context
pt_attrs = kzalloc(sizeof(struct pg_table_attrs), GFP_KERNEL);
if (pt_attrs != NULL) {
- /* Assuming that we use only DSP's memory map
-* until 0x4000: , we would need only 1024
-* L1 enties i.e L1 size = 4K */
- pt_attrs-l1_size = 0x1000;
+ pt_attrs-l1_size = MMU_L1_SIZE;
align_size = pt_attrs-l1_size;
/* Align sizes are expected to be power of 2 */
/* we like to get aligned on L1 table size */
--
1.7.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: [RFT/PATCH 05/10] cbus: retu: move to threaded IRQ and GENIRQ
Hi, On Tue, Jan 04, 2011 at 11:14:00AM -0800, Tony Lindgren wrote: I think there's been some patches related to this to get rid of NR_IRQS? Might be worth taking a look at those first as it's a generic solution. Yeah, one way would be to use Sparse IRQ numbering scheme and define different bases for different IRQ chips. We could use for example, something like: IRQ | Chip = 0-299 | INTC 300-499 | TWL4030 500-599 | MENELAUS 600-799 | RETU 800-999 | TAHVO and so on. But I'm not sure that's good enough (numbers are just from the top of my head, didn't really check how many IRQs each one have). The only problem I see is with INTC, what happens if we give it an interval which ends up not being big enough for next OMAP versions ? -- 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: [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly
On Tue, Jan 04, 2011 at 04:24:58PM -0800, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.
Signed-off-by: Felipe Balbi ba...@ti.com
Can you refresh this one against Tony's omap-for-linus branch. The GPIO
omap_device/hwmod conversion changed things around a bit and this patch
doesn't apply.
After that, you can send separately, and I'll queue this one along with
some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
out.
Sure, it's attached to this mail.
--
balbi
From 8d216ccac14e4eebf259d5b40ed2d239248710e1 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Wed, 5 Jan 2011 08:46:18 +0200
Subject: [PATCH] arm: omap: gpio: don't access irq_desc array directly
Organization: Texas Instruments\n
Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/gpio.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 1f98e0b..197a6c0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -756,8 +756,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
spin_lock_irqsave(bank-lock, flags);
retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
if (retval == 0) {
- irq_desc[irq].status = ~IRQ_TYPE_SENSE_MASK;
- irq_desc[irq].status |= type;
+ struct irq_desc *d = irq_to_desc(irq);
+
+ d-status = ~IRQ_TYPE_SENSE_MASK;
+ d-status |= type;
}
spin_unlock_irqrestore(bank-lock, flags);
@@ -1671,7 +1673,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank *bank)
for (j = bank-virtual_irq_start;
j bank-virtual_irq_start + bank_width; j++) {
- lockdep_set_class(irq_desc[j].lock, gpio_lock_class);
+ struct irq_desc *d = irq_to_desc(j);
+
+ lockdep_set_class(d-lock, gpio_lock_class);
set_irq_chip_data(j, bank);
if (bank_is_mpuio(bank))
set_irq_chip(j, mpuio_irq_chip);
--
1.7.3.4.598.g85356
Re: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
Hi, On Tue, Jan 04, 2011 at 09:54:45PM +0100, Uwe Kleine-König wrote: If you look at kernel/irq/Kconfig (as I did with the original patch) you'd notice kernel/irq/Kconfig defines both of these symbols being removed when HAVE_GENERIC_HARDIRQS is enabled. If you read the discussion in the previous version of this patch set, you'd notice that the removal of this was specifically requested. It's very tiresome to have to re-explain these things. Please take some more time to research the points you bring up, rather than I don't agree here 100%. IMHO the commit log was not good enough for the change introduced by the patch (and Felipe's reply suggests that he agrees). I could still research it, but: - it was not obvious for me there was a previous version (no v2 or similar in the patch subject); - for me it would take say 5 minutes to check, the author knows the answer to my question immediately (at least he should); - after a research I could suggest a better wording, but I don't care much if it's me or Felipe who comes up with a better text. So all in all I'm still confident that my mail was OK. No need to fight over a simple change, here it is updated. -- balbi From cf332402a5476d7aaa9bada6b895430ba7bfa3fe Mon Sep 17 00:00:00 2001 From: Felipe Balbi ba...@ti.com Date: Tue, 4 Jan 2011 12:38:24 +0200 Subject: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry Organization: Texas Instruments\n GENERIC_HARDIRQS is defined under kernel/irq/Kconfig, so it's safe to drop the duplicated entry and simply select HAVE_GENERIC_HARDIRQS. While at that, also remove GENERIC_HARDIRQS_NO__DO_IRQ because it's also defined under kernel/irq/Kconfig when HAVE_GENERIC_HARDIRQS is selected. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/Kconfig |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d56d21c0..e6f0f8b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -15,6 +15,7 @@ config ARM select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL) select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) select HAVE_GENERIC_DMA_COHERENT + select HAVE_GENERIC_HARDIRQS select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZO select HAVE_KERNEL_LZMA @@ -88,10 +89,6 @@ config MCA file:Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. -config GENERIC_HARDIRQS - bool - default y - config STACKTRACE_SUPPORT bool default y @@ -171,9 +168,6 @@ config FIQ config ARCH_MTD_XIP bool -config GENERIC_HARDIRQS_NO__DO_IRQ - def_bool y - config ARM_L1_CACHE_SHIFT_6 bool help -- 1.7.3.4.598.g85356
Re: [PATCH] arm: omap4: panda: remove usb_nop_xceiv_register
On Tue, Jan 04, 2011 at 04:29:04PM -0800, Kevin Hilman wrote: tom.leim...@gmail.com writes: From: Ming Lei tom.leim...@gmail.com Panda uses twl6030 otg phy instead of internal phy, This is wrong, it uses both. TWL6030 handles VBUS and ID pin and the internal PHY handles Data Lines. I know it's a bit crazy but this kind of design is becoming more and more usual on different boards. What truly needs to happen is that we allow for multiple PHYs to be added to otg_transceiver (BTW, that's a mis-naming as transceiver aren't only for OTG use-cases). Anyway, change this phrasing. so removes usb_nop_xceiv_register to make musb working. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Ming Lei tom.leim...@gmail.com Considering you change the commit log above: Reviewed-by: Felipe Balbi ba...@ti.com This is ok, but can only go after 2.6.38 merge window. There are patches to add support for internal PHY. Ideally we would actually register both PHYs and it would work. They would have different capabilities, though. -- 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
