Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On Wed, May 12, 2010 at 11:15:11AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Arce,
Abraham
Sent: Wednesday, May 12, 2010 11:10 AM
To: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Dmitry,
2 comments + one question before sending next version...
[...]
+static irqreturn_t omap_keypad_threaded(int irq, void *dev_id)
+{
Why is iti threaded? I fo not see anything that will sleep.
It was implemented based on previous comments...
Would you point me to that comment? Like I said, I do not see anything
that would possibly sleep in this routine so you don't need to use
threaded interrupt.
Using now request_irq based on your comments. In same omap_keypad_interrupt
disable/clear/enable
interrupts will be executed
[...]
Sorry for jumping into the comments late. Thought this was sorted out. Key
scanning
and debounce timeouts etc still there. Having all these things in ISR itself
isn't good
idea.
Dmitry,
Don't you think its optimal to push the key-scanning and debounce timeout code
part of bottom half ??
If you need debounce then you need to fire a timer and keep doing this
until interrupt (or key state) settles. It really depends on the device.
--
Dmitry
--
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: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 11:33 AM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On Wed, May 12, 2010 at 11:15:11AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Arce,
Abraham
Sent: Wednesday, May 12, 2010 11:10 AM
To: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Dmitry,
2 comments + one question before sending next version...
[...]
+static irqreturn_t omap_keypad_threaded(int irq, void *dev_id)
+{
Why is iti threaded? I fo not see anything that will sleep.
It was implemented based on previous comments...
Would you point me to that comment? Like I said, I do not see anything
that would possibly sleep in this routine so you don't need to use
threaded interrupt.
Using now request_irq based on your comments. In same
omap_keypad_interrupt disable/clear/enable
interrupts will be executed
[...]
Sorry for jumping into the comments late. Thought this was sorted out. Key
scanning
and debounce timeouts etc still there. Having all these things in ISR
itself isn't good
idea.
Dmitry,
Don't you think its optimal to push the key-scanning and debounce timeout
code
part of bottom half ??
If you need debounce then you need to fire a timer and keep doing this
until interrupt (or key state) settles. It really depends on the device.
The OMAP4 keypad controller has internal timeout mechanism and doesn't need any
external timer for this.
--
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: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Sorry for jumping into the comments late. Thought this was sorted out. Key scanning and debounce timeouts etc still there. Having all these things in ISR itself isn't good idea. Dmitry, Don't you think its optimal to push the key-scanning and debounce timeout code part of bottom half ?? If you need debounce then you need to fire a timer and keep doing this until interrupt (or key state) settles. It really depends on the device. Controller includes a debouncing feature... -- 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] OMAP3: Registering sgx device and it's platform data
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, May 11, 2010 8:27 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Agarwal, Preshit; Tony
Lindgren; Turquette, Mike; V, Hemanth
Subject: Re: [PATCH v3] OMAP3: Registering sgx device and
it's platform data
Manjunatha GK manj...@ti.com writes:
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Signed-off-by: Preshit Agarwal preshit.agar...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@ti.com
Cc: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/devices.c | 26
++-
arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 ++
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 20fa76e..aabbf7b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,7 +26,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
-
+#include mach/omap_sgxdef.h
#include mux.h
#if defined(CONFIG_VIDEO_OMAP2) ||
defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -791,6 +791,28 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+struct sgx_platform_data omap_sgx_data = {
+#ifdef CONFIG_PM
+ .set_min_bus_tput = omap_pm_set_min_bus_tput,
+#else
+ .set_min_bus_tput = NULL,
+#endif
Please explain why this should be dependent on CONFIG_PM?
I suspect you should be making these kinds of decisions in the driver
itself, not in device init.
Not sure in which context the SGX driver uses this platform data.
But, as you mentioned, we can leave it to SGX driver for handling it in
driver itself. I will make this as NULL in device init.
+};
+
+static struct platform_device powervr_device = {
+ .name= pvrsrvkm,
+ .id = -1,
+ .dev= {
+ .platform_data = omap_sgx_data,
+ }
+};
+
+static void omap_init_sgx(void)
+{
+ (void) platform_device_register(powervr_device);
+}
+
+
/*
-*/
static int __init omap2_init_devices(void)
@@ -805,7 +827,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
-
+ omap_init_sgx();
return 0;
}
arch_initcall(omap2_init_devices);
diff --git a/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
new file mode 100644
index 000..5d90a6a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
@@ -0,0 +1,11 @@
+#ifndef OMAP_SGXDEF_H
+#define OMAP_SGXDEF_H
+
+#include plat/omap-pm.h
+
+struct sgx_platform_data {
+ void(*set_min_bus_tput)(struct device *dev, u8 agent_id,
need a space after 'void' and before '('
Ok.
+
unsigned long r);
minor nit: you could drop a tab of 3 for nicer looking alignment
Ok. Thanks
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On Wed, May 12, 2010 at 11:49:45AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 11:33 AM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On Wed, May 12, 2010 at 11:15:11AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Arce,
Abraham
Sent: Wednesday, May 12, 2010 11:10 AM
To: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Dmitry,
2 comments + one question before sending next version...
[...]
+static irqreturn_t omap_keypad_threaded(int irq, void
*dev_id)
+{
Why is iti threaded? I fo not see anything that will sleep.
It was implemented based on previous comments...
Would you point me to that comment? Like I said, I do not see anything
that would possibly sleep in this routine so you don't need to use
threaded interrupt.
Using now request_irq based on your comments. In same
omap_keypad_interrupt disable/clear/enable
interrupts will be executed
[...]
Sorry for jumping into the comments late. Thought this was sorted out.
Key scanning
and debounce timeouts etc still there. Having all these things in ISR
itself isn't good
idea.
Dmitry,
Don't you think its optimal to push the key-scanning and debounce timeout
code
part of bottom half ??
If you need debounce then you need to fire a timer and keep doing this
until interrupt (or key state) settles. It really depends on the device.
The OMAP4 keypad controller has internal timeout mechanism and doesn't need
any
external timer for this.
Then I do not understand the question... If hardware takes care of
debouncing then just read the state and report the data.
--
Dmitry
--
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: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 12:05 PM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On Wed, May 12, 2010 at 11:49:45AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, May 12, 2010 11:33 AM
To: Shilimkar, Santosh
Cc: Arce, Abraham; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
On Wed, May 12, 2010 at 11:15:11AM +0530, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Arce,
Abraham
Sent: Wednesday, May 12, 2010 11:10 AM
To: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Dmitry,
2 comments + one question before sending next version...
[...]
+static irqreturn_t omap_keypad_threaded(int irq, void
*dev_id)
+{
Why is iti threaded? I fo not see anything that will sleep.
It was implemented based on previous comments...
Would you point me to that comment? Like I said, I do not see
anything
that would possibly sleep in this routine so you don't need to use
threaded interrupt.
Using now request_irq based on your comments. In same
omap_keypad_interrupt
disable/clear/enable
interrupts will be executed
[...]
Sorry for jumping into the comments late. Thought this was sorted out.
Key scanning
and debounce timeouts etc still there. Having all these things in ISR
itself isn't good
idea.
Dmitry,
Don't you think its optimal to push the key-scanning and debounce
timeout code
part of bottom half ??
If you need debounce then you need to fire a timer and keep doing this
until interrupt (or key state) settles. It really depends on the device.
The OMAP4 keypad controller has internal timeout mechanism and doesn't need
any
external timer for this.
Then I do not understand the question... If hardware takes care of
debouncing then just read the state and report the data.
You have point. Debounce shouldn't be an issue. If the key scan isn't taking
Much time then I agree with your suggestion.
Abraham, Can you please how much time you are spending in the key scan loops ?
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap_hsmmc: improve interrupt synchronisation
From ad2e1cd024ccf9144b6620cfe808893719db738f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 14 Apr 2010 16:26:45 +0300
Subject: [PATCH] omap_hsmmc: improve interrupt synchronisation
The following changes were needed:
- do not use in_interrupt() because it will not work
with threaded interrupts
In addition, the following improvements were made:
- ensure DMA is unmapped only after the final DMA interrupt
- ensure a request is completed only after the final DMA interrupt
- disable controller interrupts when a request is not in progress
- remove the spin-lock protecting the start of a new request from
an unexpected interrupt because the locking was complicated and
a 'req_in_progress' flag suffices (since the spin-lock only defers
the unexpected interrupts anyway)
- instead use the spin-lock to protect the MMC interrupt handler
from the DMA interrupt handler
- remove the semaphore preventing DMA from being started while
the previous DMA is still in progress - the other changes make that
impossible, so it is now a BUG_ON condition
- ensure the controller interrupt status is clear before exiting
the interrrupt handler
In general, these changes make the code safer but do not fix any specific
bugs so backporting is not necessary.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
Tested-by: Venkatraman S svenk...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/mmc/host/omap_hsmmc.c | 262 +
1 files changed, 134 insertions(+), 128 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c0b5021..cc0272d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -157,12 +157,10 @@ struct omap_hsmmc_host {
*/
struct regulator *vcc;
struct regulator *vcc_aux;
- struct semaphore sem;
struct work_struct mmc_carddetect_work;
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
- unsigned long flags;
unsigned intid;
unsigned intdma_len;
unsigned intdma_sg_idx;
@@ -183,6 +181,7 @@ struct omap_hsmmc_host {
int protect_card;
int reqs_blocked;
int use_reg;
+ int req_in_progress;
struct omap_mmc_platform_data *pdata;
};
@@ -480,6 +479,27 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
dev_dbg(mmc_dev(host-mmc), MMC Clock is not stoped\n);
}
+static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host)
+{
+ unsigned int irq_mask;
+
+ if (host-use_dma)
+ irq_mask = INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE);
+ else
+ irq_mask = INT_EN_MASK;
+
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+}
+
+static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
+{
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+}
+
#ifdef CONFIG_PM
/*
@@ -548,9 +568,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout))
;
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ omap_hsmmc_disable_irq(host);
/* Do not initialize card-specific things if the power is off */
if (host-power_mode == MMC_POWER_OFF)
@@ -653,6 +671,8 @@ static void send_init_stream(struct omap_hsmmc_host *host)
return;
disable_irq(host-irq);
+
+ OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
OMAP_HSMMC_WRITE(host-base, CON,
OMAP_HSMMC_READ(host-base, CON) | INIT_STREAM);
OMAP_HSMMC_WRITE(host-base, CMD, INIT_STREAM_CMD);
@@ -718,17 +738,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
- /*
-* Clear status bits and enable interrupts
-*/
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
-
- if (host-use_dma)
- OMAP_HSMMC_WRITE(host-base, IE,
-INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
- else
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+
Re: [PATCH v2 1/2] ARM: McBSP: Fix request for irq in OMAP4
On Wed, 5 May 2010 20:15:45 -0500 Jorge Eduardo Candelaria jorge.candela...@ti.com wrote: In OMAP4, there is only one irq line for TX and RX paths. Use the correct irq line to avoid errors at runtime. Also, request irq line only once (instead of requesting for TX and RX). Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com --- arch/arm/mach-omap2/mcbsp.c | 12 arch/arm/plat-omap/mcbsp.c | 20 2 files changed, 16 insertions(+), 16 deletions(-) Acked-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: McBSP: Add support for omap4 in McBSP driver
On Wed, 5 May 2010 20:15:46 -0500
Jorge Eduardo Candelaria jorge.candela...@ti.com wrote:
McBSP module in OMAP4 needs to be able to set its tx/rx threshold
and enable the transmitter/receiver when starting an audio stream.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
...
@@ -899,7 +899,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
/* Reset receiver */
rx = 1;
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx) {
Parentheses missing here from cpu_is_omap44xx. Otherwise looks good.
--
Jarkko
--
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] omap4 i2c board support
Tony, This series contains remaining patches from ealier series and is is rebased against the current omap for-next branch Balaji T K (2): omap4: add i2c1 peripherals data omap4: Enable RTC and regulator support Santosh Shilimkar (1): omap4: Add i2c board support on omap4430 sdp platform arch/arm/configs/omap_4430sdp_defconfig | 376 --- arch/arm/mach-omap2/board-4430sdp.c | 187 +++ arch/arm/plat-omap/i2c.c| 21 ++- 3 files changed, 553 insertions(+), 31 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
[PATCH 2/3] omap4: add i2c1 peripherals data
From: Balaji T K balaj...@ti.com
This patch adds i2c1 peripherals data to
omap4430 sdp board file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 177 ++-
1 files changed, 176 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 41fed92..921cde3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -19,6 +19,8 @@
#include linux/gpio.h
#include linux/usb/otg.h
#include linux/spi/spi.h
+#include linux/i2c/twl.h
+#include linux/regulator/machine.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -135,13 +137,186 @@ static struct omap_musb_board_data musb_board_data = {
.mode = MUSB_PERIPHERAL,
.power = 100,
};
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+ {
+ .supply = vmmc,
+ },
+ {
+ .supply = vmmc,
+ },
+ {
+ .supply = vmmc,
+ },
+ {
+ .supply = vmmc,
+ },
+ {
+ .supply = vmmc,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux1 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux2 = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vaux3 = {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VMMC1 for MMC1 card */
+static struct regulator_init_data sdp4430_vmmc = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 5,
+ .consumer_supplies = sdp4430_vmmc_supply,
+};
+
+static struct regulator_init_data sdp4430_vpp = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 250,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vusim = {
+ .constraints = {
+ .min_uV = 120,
+ .max_uV = 290,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data sdp4430_vana = {
+ .constraints = {
+ .min_uV = 210,
+ .max_uV = 210,
+ .apply_uV = true,
+
[PATCH 3/3] omap4: Enable RTC and regulator support
From: Balaji T K balaj...@ti.com This patch enables RTC and regulator support on omap4430 sdp platform. Also sync up the defconfig with latest kernel Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 330 --- 1 files changed, 302 insertions(+), 28 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a555305..25e8d04 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32 -# Sun Dec 6 23:37:45 2009 +# Linux kernel version: 2.6.34-rc7 +# Wed May 12 12:26:05 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -9,6 +9,7 @@ CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y @@ -20,6 +21,7 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config @@ -33,28 +35,33 @@ CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_KERNEL_GZIP=y +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set +# CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 -CONFIG_GROUP_SCHED=y -CONFIG_FAIR_GROUP_SCHED=y -# CONFIG_RT_GROUP_SCHED is not set -CONFIG_USER_SCHED=y -# CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -64,6 +71,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set +# CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -85,10 +93,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +# CONFIG_PERF_EVENTS is not set +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y @@ -127,14 +139,41 @@ CONFIG_LBDAF=y # IO Schedulers # CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set -# CONFIG_DEFAULT_CFQ is not set +CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not set +# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set +# CONFIG_INLINE_WRITE_UNLOCK is not set +# CONFIG_INLINE_WRITE_UNLOCK_BH is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set +# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set +CONFIG_MUTEX_SPIN_ON_OWNER=y # CONFIG_FREEZER is not set # @@ -146,6 +185,7 @@ CONFIG_MMU=y # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_BCMRING is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set @@ -155,7 +195,6 @@ CONFIG_MMU=y # CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set #
Re: [PATCH 3/3] omap3 nand: fix issue in board file to detect the nand
[Sukumar Ghorai wrote:
From: Sukumar Ghorai s-gho...@ti.com
Board file modified to pass the GMPC phys_base address to nand driver. This is
required to adopt the _prob function as in omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 10 ++
arch/arm/mach-omap2/board-devkit8000.c |9 +
arch/arm/mach-omap2/board-omap3beagle.c|9 +
arch/arm/mach-omap2/board-omap3touchbook.c |9 +
arch/arm/mach-omap2/board-overo.c |8
5 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index fb23122..73a32bd
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -240,6 +240,16 @@ static struct platform_device cm_t35_nand_device = {
static void __init cm_t35_init_nand(void)
{
+ struct device *dev = cm_t35_nand_device.dev;
+ int err = 0;
+
+ err = gpmc_cs_request(cm_t35_nand_data.cs,
+ NAND_IO_SIZE,
cm_t35_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
+
if (platform_device_register(cm_t35_nand_device) 0)
pr_err(CM-T35: Unable to register NAND device\n);
Why won't you use gpmc_nand_init instead of platform_device_register?
With gpmc_nand_init there would be no need to request NAND CS in the
board files. Besides, if you convert the boards to use gpmc_nand_init at
the first place, it would simplify further patches.
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index be50d18..86358e3
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -578,6 +578,9 @@ static void __init devkit8000_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
+ struct device *dev = devkit8000_nand_device.dev;
+ int err = 0;
+
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -599,6 +602,12 @@ static void __init devkit8000_flash_init(void)
if (nandcs GPMC_CS_NUM) {
devkit8000_nand_data.cs = nandcs;
+ err = gpmc_cs_request(devkit8000_nand_data.cs,
+ NAND_IO_SIZE,
devkit8000_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if (platform_device_register(devkit8000_nand_device) 0)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index becaebe..d54719d
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -374,6 +374,9 @@ static void __init omap3beagle_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
+ struct device *dev = omap3beagle_nand_device.dev;
+ int err = 0;
+
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -395,6 +398,12 @@ static void __init omap3beagle_flash_init(void)
if (nandcs GPMC_CS_NUM) {
omap3beagle_nand_data.cs = nandcs;
+ err = gpmc_cs_request(omap3beagle_nand_data.cs,
+ NAND_IO_SIZE,
omap3beagle_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if (platform_device_register(omap3beagle_nand_device) 0)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index d6f1b12..088a704
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -456,6 +456,9 @@ static void __init omap3touchbook_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
+ struct device *dev = omap3touchbook_nand_device.dev;
+ int err = 0;
+
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -477,6 +480,12 @@ static void __init omap3touchbook_flash_init(void)
if (nandcs GPMC_CS_NUM) {
omap3touchbook_nand_data.cs = nandcs;
+ err = gpmc_cs_request(omap3touchbook_nand_data.cs,
+ NAND_IO_SIZE,
omap3touchbook_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if
Re: [PATCH v2 0/0] McBSP changes for OMAP4 platform
On Wed, May 12, 2010 at 11:39:26AM +0300, Peter Ujfalusi wrote: Looks good with Jarkko's comment. However, I'd like to ask Tony, Liam, Jarkko, and Mark the following: Would it make sense to use the alsa tree for OMAP McBSP related patches, while keeping l-o in CC off course. We've had to do this a few times in the past due to the way the code is split between the two areas. If it makes everyone's life easier I've got no problem with it, though I'll say my standard thing about it being better to keep them on a branch by themselves which can be pulled into both trees in case of any merge issues. -- 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
[RFC][PATCHv2 1/2] SFH7741: proximity sensor driver support
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256 +
include/linux/input/sfh7741.h | 16 +++
4 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/sfh7741.c
create mode 100644 include/linux/input/sfh7741.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23140a3..925dca3 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,13 @@ config INPUT_PCAP
To compile this driver as a module, choose M here: the
module will be called pcap_keys.
+config SENSORS_SFH7741
+ tristate Proximity sensor
+ default y
+ help
+ Say Y here if you want to use proximity sensor sfh7741.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sfh7741.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 7e95a5d..5fea200 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
+obj-$(CONFIG_SENSORS_SFH7741) += sfh7741.o
diff --git a/drivers/input/misc/sfh7741.c b/drivers/input/misc/sfh7741.c
new file mode 100644
index 000..cde4d1b
--- /dev/null
+++ b/drivers/input/misc/sfh7741.c
@@ -0,0 +1,256 @@
+/*
+ * sfh7741.c
+ *
+ * SFH7741 Proximity Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Shubhrajyoti Datta shubhrajy...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/interrupt.h
+#include linux/pm.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/input/sfh7741.h
+#include linux/slab.h
+
+struct sfh7741_drvdata {
+ struct input_dev *input;
+ int irq;
+ int prox_enable;
+ /* mutex for sysfs operations */
+ struct mutex lock;
+ void (*activate_func)(int state);
+ int (*read_prox)(void);
+};
+
+static irqreturn_t sfh7741_isr(int irq, void *dev_id)
+{
+ struct sfh7741_drvdata *ddata = dev_id;
+ int proximity;
+
+ proximity = ddata-read_prox();
+ input_report_abs(ddata-input, ABS_DISTANCE, proximity);
+ input_sync(ddata-input);
+
+ return IRQ_HANDLED;
+}
+
+static ssize_t set_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int state;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+
+ if (sscanf(buf, %u, state) != 1)
+ return -EINVAL;
+
+ if ((state != 1) (state != 0))
+ return -EINVAL;
+
+ ddata-activate_func(state);
+
+ mutex_lock(ddata-lock);
+ if (state != ddata-prox_enable) {
+ if (state)
+ enable_irq(ddata-irq);
+ else
+ disable_irq(ddata-irq);
+ ddata-prox_enable = state;
+ }
+ mutex_unlock(ddata-lock);
+ return strnlen(buf, count);
+}
+
+static ssize_t show_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ return sprintf(buf, %u\n, ddata-prox_enable);
+}
+static DEVICE_ATTR(state, S_IWUSR | S_IRUGO, show_prox_state, set_prox_state);
+
+static ssize_t show_proximity(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int proximity;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ proximity = ddata-read_prox();
+ return sprintf(buf, %u\n, proximity);
+}
+static DEVICE_ATTR(proximity, S_IRUGO, show_proximity, NULL);
+
+static struct attribute
[RFC] [PATCHv2 2/2] SFH7741: Proximity sensor board support.
Adding board support for the proximity sensor.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 71 +++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index b88f28c..beb3059 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -18,6 +18,7 @@
#include linux/io.h
#include linux/gpio.h
#include linux/usb/otg.h
+#include linux/input/sfh7741.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -31,7 +32,25 @@
#include plat/usb.h
#include asm/hardware/gic.h
#include asm/hardware/cache-l2x0.h
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO 188
+static void omap_prox_activate(int state);
+static int omap_prox_read(void);
+
+static struct sfh7741_platform_data omap_sfh7741_data = {
+ .irq = OMAP_GPIO_IRQ(OMAP4_SFH7741_SENSOR_OUTPUT_GPIO),
+ .prox_enable = 1,
+ .activate_func = omap_prox_activate,
+ .read_prox = omap_prox_read,
+};
+static struct platform_device sdp4430_proximity_device = {
+ .name = sfh7741,
+ .id = 1,
+ .dev= {
+ .platform_data = omap_sfh7741_data,
+ },
+};
static struct platform_device sdp4430_lcd_device = {
.name = sdp4430_lcd,
.id = -1,
@@ -39,6 +58,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_proximity_device,
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
@@ -111,6 +131,56 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static void omap_prox_activate(int state)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , state);
+}
+
+static int omap_prox_read(void)
+{
+ int proximity;
+ proximity = gpio_get_value(OMAP4_SFH7741_SENSOR_OUTPUT_GPIO);
+ return proximity;
+}
+
+static void omap_sfh7741prox_init(void)
+{
+ char *desc = sfh7741;
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_SENSOR_OUTPUT_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d, error %d\n
+ , __func__, OMAP4_SFH7741_SENSOR_OUTPUT_GPIO, error);
+ return ;
+ }
+
+ error = gpio_direction_input(OMAP4_SFH7741_SENSOR_OUTPUT_GPIO);
+ if (error 0) {
+ pr_err(Proximity GPIO input configuration failed\n);
+ goto fail1;
+ }
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(failed to request GPIO %d, error %d\n,
+ OMAP4_SFH7741_ENABLE_GPIO, error);
+ goto fail1;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,\
+ error %d\n,__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ goto fail3;
+ }
+ return;
+
+fail3:
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+fail1:
+ gpio_free(OMAP4_SFH7741_SENSOR_OUTPUT_GPIO);
+}
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
@@ -120,6 +190,7 @@ static void __init omap_4430sdp_init(void)
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
+ omap_sfh7741prox_init();
}
static void __init omap_4430sdp_map_io(void)
--
1.5.4.7
--
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: linux-next: manual merge of the omap_dss2 tree with the omap tree
Hi, On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote: * Stephen Rothwell s...@canb.auug.org.au [100506 22:05]: Hi Tomi, Today's linux-next merge of the omap_dss2 tree got a conflict in arch/arm/mach-omap2/board-rx51-peripherals.c between commit e87da74e34ad151e6ae75ebb7a7bf447f02c0004 (omap: rx51: Add supplies for the tlv320aic3x codec driver) from the omap tree and commit a693839eab0292aa234d7a6f48d40389389baebb (OMAP: RX51: Add vdds_sdi supply voltage for SDI) from the omap_dss2 tree. Just overlapping additions. I fixed it up (see below) and can carry the fix as necessary. Thanks again Stephen. We will move the conflicting DSS board-*.c file changes over to omap for next. Tomi, do you want to do a branch of board-*.c patches for me to pull, or do you want me to just pick this one? I think it's ok to pick just this one. It's just adds a regulator supply, and doesn't interfere with anything. I just need to make sure linux-omap's for-next is merged first, before I send my pull request. I made a branch for it, based on linux-omap/for-next: git://gitorious.org/linux-omap-dss2/linux.git for-tony And I dropped the patch from my for-next branch. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/0] McBSP changes for OMAP4 platform
On Wed, 2010-05-12 at 11:39 +0300, Peter Ujfalusi wrote: Hi, On Thursday 06 May 2010 04:15:44 ext Jorge Eduardo Candelaria wrote: The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Changes from v1: - Changed to correct IRQ lines. - Check if rx_irq is defined, instead of checking if cpu is omap4 Jorge Eduardo Candelaria (2): ARM: McBSP: Fix request for irq in OMAP4 ARM: OMAP4: Add support for omap4 in McBSP driver arch/arm/mach-omap2/mcbsp.c | 12 arch/arm/plat-omap/mcbsp.c | 34 +++--- 2 files changed, 23 insertions(+), 23 deletions(-) Looks good with Jarkko's comment. However, I'd like to ask Tony, Liam, Jarkko, and Mark the following: Would it make sense to use the alsa tree for OMAP McBSP related patches, while keeping l-o in CC off course. If we have patches for mcbsp pending in l-o and in alsa tree, than we are going to have hard times to sort things out when they need to be merged. I'm asking this, because I will also have some patches for mcbsp, which will need change in arch/ and in sound/ as well. I know that taking patches to alsa tree for the arch/ is unorthodox, but it will ease up our life in a long run... What do you think? I tend to agree here since afaik audio is the primary upstream user of mcbsp on OMAP. We do have queue of audio related mcbsp patches pending atm and merging would be simpler in the ALSA tree atm. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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] omap3: GPMC register definition at common location
GPMC register definition move to common place in gpmc.h.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 38 +--
arch/arm/plat-omap/include/plat/gpmc.h | 36 +++--
drivers/mtd/nand/omap2.c | 14 ---
3 files changed, 40 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..9c77af0
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -28,40 +28,6 @@
#include plat/sdrc.h
-/* GPMC register offsets */
-#define GPMC_REVISION 0x00
-#define GPMC_SYSCONFIG 0x10
-#define GPMC_SYSSTATUS 0x14
-#define GPMC_IRQSTATUS 0x18
-#define GPMC_IRQENABLE 0x1c
-#define GPMC_TIMEOUT_CONTROL 0x40
-#define GPMC_ERR_ADDRESS 0x44
-#define GPMC_ERR_TYPE 0x48
-#define GPMC_CONFIG0x50
-#define GPMC_STATUS0x54
-#define GPMC_PREFETCH_CONFIG1 0x1e0
-#define GPMC_PREFETCH_CONFIG2 0x1e4
-#define GPMC_PREFETCH_CONTROL 0x1ec
-#define GPMC_PREFETCH_STATUS 0x1f0
-#define GPMC_ECC_CONFIG0x1f4
-#define GPMC_ECC_CONTROL 0x1f8
-#define GPMC_ECC_SIZE_CONFIG 0x1fc
-
-#define GPMC_CS0 0x60
-#define GPMC_CS_SIZE 0x30
-
-#define GPMC_MEM_START 0x
-#define GPMC_MEM_END 0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
-
-#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
-
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -112,7 +78,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
@@ -120,7 +86,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 145838a..347d212 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -25,10 +25,40 @@
#define GPMC_CS_NAND_ADDRESS 0x20
#define GPMC_CS_NAND_DATA 0x24
-#define GPMC_CONFIG0x50
-#define GPMC_STATUS0x54
+/* GPMC register offsets */
+#define GPMC_REVISION 0x00
+#define GPMC_SYSCONFIG 0x10
+#define GPMC_SYSSTATUS 0x14
+#define GPMC_IRQSTATUS 0x18
+#define GPMC_IRQENABLE 0x1c
+#define GPMC_TIMEOUT_CONTROL0x40
+#define GPMC_ERR_ADDRESS0x44
+#define GPMC_ERR_TYPE 0x48
+#define GPMC_CONFIG 0x50
+#define GPMC_STATUS 0x54
+#define GPMC_PREFETCH_CONFIG1 0x1e0
+#define GPMC_PREFETCH_CONFIG2 0x1e4
+#define GPMC_PREFETCH_CONTROL 0x1ec
+#define GPMC_PREFETCH_STATUS0x1f0
+#define GPMC_ECC_CONFIG 0x1f4
+#define GPMC_ECC_CONTROL0x1f8
+#define GPMC_ECC_SIZE_CONFIG0x1fc
+#define GPMC_ECC1_RESULT0x200
+
#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
+#define GPMC_CS_SIZE0x30
+
+#define GPMC_MEM_START 0x
+#define GPMC_MEM_END0x3FFF
+#define BOOT_ROM_SPACE 0x10/* 1MB */
+
+#define GPMC_CHUNK_SHIFT24 /* 16 MB */
+#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+
+#define PREFETCH_FIFOTHRESHOLD (0x40 8)
+#define CS_NUM_SHIFT24
+#define ENABLE_PREFETCH (0x1 7)
+#define DMA_MPU_MODE2
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 30)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7545568..258bf06
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -23,12 +23,6 @@
#include plat/gpmc.h
#include plat/nand.h
-#define GPMC_IRQ_STATUS0x18
-#define GPMC_ECC_CONFIG0x1F4
-#define GPMC_ECC_CONTROL 0x1F8
-#define GPMC_ECC_SIZE_CONFIG 0x1FC
-#define GPMC_ECC1_RESULT 0x200
-
#defineDRIVER_NAME omap2-nand
#defineNAND_WP_OFF 0
@@ -37,6 +31,7 @@
#defineGPMC_BUF_FULL 0x0001
#defineGPMC_BUF_EMPTY 0x
+#ifdef CONFIG_MTD_NAND_OMAP_HWECC
#define NAND_Ecc_P1e (1 0)
#define NAND_Ecc_P2e (1 1)
#define NAND_Ecc_P4e (1 2)
@@ -103,6 +98,7 @@
#define P4e_s(a) (TF(a NAND_Ecc_P4e)
[PATCH 3/3] omap3 nand: fix issue in board file to detect the nand
Board file modified to pass the GMPC phys_base address to nand driver. This is
required to adopt the _prob function as in omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 16 +---
arch/arm/mach-omap2/board-devkit8000.c | 16 +---
arch/arm/mach-omap2/board-omap3beagle.c| 16 +---
arch/arm/mach-omap2/board-omap3touchbook.c | 16 +---
arch/arm/mach-omap2/board-overo.c | 17 +
5 files changed, 5 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index fb23122..0544294
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -224,23 +224,9 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
};
-static struct resource cm_t35_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device cm_t35_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .num_resources = 1,
- .resource = cm_t35_nand_resource,
- .dev= {
- .platform_data = cm_t35_nand_data,
- },
-};
-
static void __init cm_t35_init_nand(void)
{
- if (platform_device_register(cm_t35_nand_device) 0)
+ if (gpmc_nand_init(cm_t35_nand_data) 0)
pr_err(CM-T35: Unable to register NAND device\n);
}
#else
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index be50d18..a6fcb48
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -101,20 +101,6 @@ static struct omap_nand_platform_data devkit8000_nand_data
= {
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
};
-static struct resource devkit8000_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device devkit8000_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .dev= {
- .platform_data = devkit8000_nand_data,
- },
- .num_resources = 1,
- .resource = devkit8000_nand_resource,
-};
-
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -601,7 +587,7 @@ static void __init devkit8000_flash_init(void)
devkit8000_nand_data.cs = nandcs;
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
- if (platform_device_register(devkit8000_nand_device) 0)
+ if (gpmc_nand_init(devkit8000_nand_data) 0)
printk(KERN_ERR Unable to register NAND device\n);
}
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index becaebe..bf31b7c
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -89,20 +89,6 @@ static struct omap_nand_platform_data omap3beagle_nand_data
= {
.dev_ready = NULL,
};
-static struct resource omap3beagle_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device omap3beagle_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .dev= {
- .platform_data = omap3beagle_nand_data,
- },
- .num_resources = 1,
- .resource = omap3beagle_nand_resource,
-};
-
#include sdram-micron-mt46h32m32lf-6.h
static struct omap2_hsmmc_info mmc[] = {
@@ -397,7 +383,7 @@ static void __init omap3beagle_flash_init(void)
omap3beagle_nand_data.cs = nandcs;
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
- if (platform_device_register(omap3beagle_nand_device) 0)
+ if (gpmc_nand_init(omap3beagle_nand_data) 0)
printk(KERN_ERR Unable to register NAND device\n);
}
}
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index d6f1b12..e8ad30c
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -103,20 +103,6 @@ static struct omap_nand_platform_data
omap3touchbook_nand_data = {
.dev_ready = NULL,
};
-static struct resource omap3touchbook_nand_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device omap3touchbook_nand_device = {
- .name = omap2-nand,
- .id = -1,
- .dev= {
- .platform_data = omap3touchbook_nand_data,
- },
- .num_resources = 1,
- .resource = omap3touchbook_nand_resource,
-};
-
#include sdram-micron-mt46h32m32lf-6.h
static struct omap2_hsmmc_info mmc[] = {
@@ -479,7 +465,7 @@ static void __init omap3touchbook_flash_init(void)
omap3touchbook_nand_data.cs = nandcs;
[PATCH 0/3] omap3 nand: cleanup exiting platform related code
The following set of patches applies on top of master branch. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board And these are the patches required to address the following input - 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. Sukumar Ghorai (3): omap3: GPMC register definition at common location omap3 nand: cleanup for not to use GPMC virtual address omap3 nand: fix issue in board file to detect the nand arch/arm/mach-omap2/board-cm-t35.c | 20 + arch/arm/mach-omap2/board-devkit8000.c | 25 +-- arch/arm/mach-omap2/board-omap3beagle.c| 24 +- arch/arm/mach-omap2/board-omap3touchbook.c | 25 +-- arch/arm/mach-omap2/board-overo.c | 24 +- arch/arm/mach-omap2/gpmc.c | 67 +--- arch/arm/plat-omap/include/plat/gpmc.h | 41 - arch/arm/plat-omap/include/plat/nand.h |6 +- drivers/mtd/nand/omap2.c | 125 ++-- 9 files changed, 109 insertions(+), 248 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
[PATCH 2/3] omap3 nand: cleanup for not to use GPMC virtual address
Necessary function added in GPMC module and used by nand driver. This is for
not to use GPMC address directly from nand driver. Also it was passing GPMC
base address from board files and that is removed.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c |4 -
arch/arm/mach-omap2/board-devkit8000.c |9 --
arch/arm/mach-omap2/board-omap3beagle.c|8 --
arch/arm/mach-omap2/board-omap3touchbook.c |9 --
arch/arm/mach-omap2/board-overo.c |7 --
arch/arm/mach-omap2/gpmc.c | 29 ---
arch/arm/plat-omap/include/plat/gpmc.h |5 +-
arch/arm/plat-omap/include/plat/nand.h |6 +-
drivers/mtd/nand/omap2.c | 117 ++-
9 files changed, 67 insertions(+), 127 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e679a2c..fb23122
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -61,8 +61,6 @@
#define SB_T35_SMSC911X_GPIO 65
#define NAND_BLOCK_SIZESZ_128K
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS0_BASE_ADDR (OMAP34XX_GPMC_VIRT + GPMC_CS0_BASE)
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include linux/smsc911x.h
@@ -223,8 +221,6 @@ static struct omap_nand_platform_data cm_t35_nand_data = {
.nr_parts = ARRAY_SIZE(cm_t35_nand_partitions),
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
.cs = 0,
- .gpmc_cs_baseaddr = (void __iomem *)GPMC_CS0_BASE_ADDR,
- .gpmc_baseaddr = (void __iomem *)OMAP34XX_GPMC_VIRT,
};
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 47e3af2..be50d18
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -58,9 +58,6 @@
#include mux.h
#include hsmmc.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
#define OMAP_DM9000_GPIO_IRQ 25
@@ -581,8 +578,6 @@ static void __init devkit8000_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -604,10 +599,6 @@ static void __init devkit8000_flash_init(void)
if (nandcs GPMC_CS_NUM) {
devkit8000_nand_data.cs = nandcs;
- devkit8000_nand_data.gpmc_cs_baseaddr = (void *)
- (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
- devkit8000_nand_data.gpmc_baseaddr = (void *)
- (gpmc_base_add);
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if (platform_device_register(devkit8000_nand_device) 0)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 962d377..becaebe
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -47,9 +47,6 @@
#include mux.h
#include hsmmc.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
static struct mtd_partition omap3beagle_nand_partitions[] = {
@@ -377,8 +374,6 @@ static void __init omap3beagle_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -400,9 +395,6 @@ static void __init omap3beagle_flash_init(void)
if (nandcs GPMC_CS_NUM) {
omap3beagle_nand_data.cs = nandcs;
- omap3beagle_nand_data.gpmc_cs_baseaddr = (void *)
- (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
- omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if (platform_device_register(omap3beagle_nand_device) 0)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 2504d41..d6f1b12
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -54,9 +54,6 @@
#include asm/setup.h
-#define GPMC_CS0_BASE 0x60
-#define GPMC_CS_SIZE 0x30
-
#define NAND_BLOCK_SIZESZ_128K
#define OMAP3_AC_GPIO 136
@@ -459,8 +456,6 @@ static void __init omap3touchbook_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
- u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
-
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -482,10 +477,6 @@ static void
Re: Possible bug in onenand_base ?
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit - device id: 0x58 - bit 3 is
1 - dual-die
- Muxed OneNAND 256MB 1.8V 16-bit - device id: 0x40 - bit 3 is 0 -single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra eballe...@gmail.com:
Hi,
2010/5/6 Kyungmin Park kmp...@infradead.org:
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Is a 4-Gbit DDP OneNAND device from Numonyx composed of two 2-Gbit 2KB
page dice stacked together, the device is equipped with two DataRAMs,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Hi,
2010/5/6 Kyungmin Park kyungmin.p...@samsung.com:
Hi,
Can you add this statement at below the code?
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr this-page_shift)
this-page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr this-page_shift); */
page = (int) (addr - onenand_addr(this, block))
this-page_shift;
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr
this-page_shift)
this-page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block = ~1;
/* Is it the odd plane? */
if (addr this-writesize)
block++;
page = 1;
}
page = this-page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Byte 0x5 is 21 should be b7
--- end log nandtest fail ---
With this other code nandtest pass
onenand_base.c
377: default:
block = onenand_block(this, addr);
page = (int) (addr this-page_shift);
/* (line disabled) page = (int) (addr - onenand_addr(this, block))
[PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.
Use system DMA for all RX channels as a workaround of this issue as this
will have minimal throughput overhead based on the fact that Rx transfers
are done in DMA mode-0 on OMAP34x/35x platforms.
Another approach to use PIO mode in opposite direction would increase the
cpu loading and thus using system DMA is preferred workaround.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Original version of this patch can be found at,
http://marc.info/?l=linux-usbm=121861118320955w=2
drivers/usb/musb/Kconfig |9
drivers/usb/musb/musbhsdma.c | 101 ++
drivers/usb/musb/musbhsdma.h | 10
3 files changed, 120 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 07fe490..f847fe2 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -157,6 +157,15 @@ config USB_INVENTRA_DMA
help
Enable DMA transfers using Mentor's engine.
+config MUSB_USE_SYSTEM_DMA_WORKAROUND
+ bool 'Use System DMA for Mentor DMA workaround'
+ depends on USB_MUSB_HDRC USB_INVENTRA_DMA
+ default y
+ help
+ MUSB RTL version 1.4 (OMAP34x/35x) has a hardware issue when TX and
RX
+ DMA channels are simultaneously enabled. To work around this issue,
+ you can choose to use System DMA for RX channels.
+
config USB_TI_CPPI_DMA
bool
depends on USB_MUSB_HDRC !MUSB_PIO_ONLY
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 1008044..70342eb 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -36,12 +36,47 @@
#include linux/slab.h
#include musb_core.h
#include musbhsdma.h
+#include plat/dma.h
static int dma_controller_start(struct dma_controller *c)
{
/* nothing to do */
return 0;
}
+static void musb_sysdma_completion(int lch, u16 ch_status, void *data)
+{
+ u32 addr;
+ unsigned long flags;
+
+ struct dma_channel *channel;
+
+ struct musb_dma_channel *musb_channel =
+ (struct musb_dma_channel *) data;
+ struct musb_dma_controller *controller = musb_channel-controller;
+ struct musb *musb = controller-private_data;
+ channel = musb_channel-channel;
+
+ DBG(2, lch = 0x%d, ch_status = 0x%x\n, lch, ch_status);
+ spin_lock_irqsave(musb-lock, flags);
+
+ addr = (u32) omap_get_dma_dst_pos(musb_channel-sysdma_channel);
+ if (musb_channel-len == 0)
+ channel-actual_len = 0;
+ else
+ channel-actual_len = addr - musb_channel-start_addr;
+
+ DBG(2, ch %p, 0x%x - 0x%x (%d / %d) %s\n,
+ channel, musb_channel-start_addr, addr,
+ channel-actual_len, musb_channel-len,
+ (channel-actual_len musb_channel-len) ?
+ = reconfig 0 : = complete);
+
+ channel-status = MUSB_DMA_STATUS_FREE;
+ musb_dma_completion(musb, musb_channel-epnum, musb_channel-transmit);
+
+ spin_unlock_irqrestore(musb-lock, flags);
+ return;
+}
static void dma_channel_release(struct dma_channel *channel);
@@ -77,6 +112,7 @@ static struct dma_channel *dma_channel_allocate(struct
dma_controller *c,
struct musb_dma_controller *controller = container_of(c,
struct musb_dma_controller, controller);
struct musb_dma_channel *musb_channel = NULL;
+ struct musb *musb = controller-private_data;
struct dma_channel *channel = NULL;
u8 bit;
@@ -95,6 +131,33 @@ static struct dma_channel *dma_channel_allocate(struct
dma_controller *c,
/* Tx = mode 1; Rx = mode 0 */
channel-desired_mode = transmit;
channel-actual_len = 0;
+ musb_channel-sysdma_channel = -1;
+
+ /*
+* MUSB RTL version 1.4 (OMAP34x/35x) has a hardware
+* issue when TX and RX DMA channels are simultaneously
+* enabled. To work around this issue, use system DMA
+* for all RX channels.
+*/
+ if (((musb-hwvers == MUSB_HWVERS_1400) !transmit)
+use_sdma_workaround()) {
+ int ret;
+ ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
+ MUSB SysDMA, musb_sysdma_completion,
+ (void *) musb_channel,
+ (musb_channel-sysdma_channel));
+
+ if (ret) {
+ printk(KERN_ERR request_dma failed:
+
[PATCH 5/5] musb: dma: use optimal transfer element for sdma
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musbhsdma.c | 39 +--
1 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 6118d5f..a0da178 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -230,6 +230,8 @@ static void configure_channel(struct dma_channel *channel,
u8 buffer_is_aligned = (dma_addr 0x3) ? 0 : 1;
u8 use_sdma = (musb_channel-sysdma_channel == -1) ? 0 : 1;
u16 csr = 0;
+ u16 frame = len;
+ int data_type = OMAP_DMA_DATA_TYPE_S8;
DBG(4, %p, pkt_sz %d, addr 0x%x, len %d, mode %d\n,
channel, packet_sz, dma_addr, len, mode);
@@ -238,13 +240,38 @@ static void configure_channel(struct dma_channel *channel,
(musb-hwvers = MUSB_HWVERS_1800))
use_sdma = 0;
+ if (use_sdma) {
+ switch (dma_addr 0x3) {
+ case 0:
+ if ((len % 4) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S32;
+ frame = len / 4;
+ break;
+ }
+ /* FALLTHROUGH */
+ case 2:
+ if ((len % 2) == 0) {
+ data_type = OMAP_DMA_DATA_TYPE_S16;
+ frame = len / 2;
+ break;
+ }
+ /* FALLTHROUGH */
+ case 1:
+ case 3:
+ default:
+ data_type = OMAP_DMA_DATA_TYPE_S8;
+ frame = len;
+ break;
+ }
+ }
+
if (use_sdma !musb_channel-transmit) {
/* System DMA */
/* RX: set src = FIFO */
omap_set_dma_transfer_params(musb_channel-sysdma_channel,
- OMAP_DMA_DATA_TYPE_S8,
- len ? len : 1, 1, /* One frame */
- OMAP_DMA_SYNC_ELEMENT,
+ data_type,
+ len ? frame : 1, 1, /* One frame */
+ OMAP_DMA_SYNC_FRAME,
OMAP24XX_DMA_NO_DEVICE,
0); /* Src Sync */
@@ -268,9 +295,9 @@ static void configure_channel(struct dma_channel *channel,
/* System DMA */
/* TX: set dst = FIFO */
omap_set_dma_transfer_params(musb_channel-sysdma_channel,
- OMAP_DMA_DATA_TYPE_S8,
- len ? len : 1, 1, /* One frame */
- OMAP_DMA_SYNC_ELEMENT,
+ data_type,
+ len ? frame : 1, 1, /* One frame */
+ OMAP_DMA_SYNC_FRAME,
OMAP24XX_DMA_NO_DEVICE,
0); /* Src Sync */
--
1.6.2.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] musb: use system DMA for unaligned buffers on RTL = 1.8
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch supports device side CDC/RNDIS. Host side would require
change in Tx programming path for mode-0 operation when transfer length
is more than packet size.
Also fixed an issue in device Tx completion path where 'is_dma' is getting
set unconditionally. This would fail the io if Tx transfer is done in
mode-0. Fixed it by updating it based on 'request-actual' length.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/Kconfig |6 +++
drivers/usb/musb/musb_gadget.c | 21 +++-
drivers/usb/musb/musbhsdma.c | 75 ++--
3 files changed, 98 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index f847fe2..05db0ff 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND
DMA channels are simultaneously enabled. To work around this issue,
you can choose to use System DMA for RX channels.
+ Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x)
+ requires buffers to be aligned on a four byte boundary. This affects
+ USB CDC/RNDIS class application where buffers are always unaligned.
+ To work around this issue, you can choose to use System DMA for
+ unaligned buffers.
+
config USB_TI_CPPI_DMA
bool
depends on USB_MUSB_HDRC !MUSB_PIO_ONLY
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6fca870..9ac45e4 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -317,6 +317,22 @@ static void txstate(struct musb *musb, struct musb_request
*req)
else
musb_ep-dma-desired_mode = 1;
+ /*
+* Use system dma for unaligned buffers on RTL = 1.8
+* for Inventra DMA. As system DMA can work only in
+* mode-0 so update the desired_mode and request_size.
+*/
+ if (is_inventra_dma_enabled()
+ ((request-dma + request-actual) 0x3)
+ (musb-hwvers = MUSB_HWVERS_1800)) {
+
+ request_size = min_t(size_t,
+ musb_ep-hw_ep-max_packet_sz_tx,
+ request-length - request-actual);
+
+ musb_ep-dma-desired_mode = 0;
+ }
+
use_dma = use_dma c-channel_program(
musb_ep-dma, musb_ep-packet_sz,
musb_ep-dma-desired_mode,
@@ -463,7 +479,6 @@ void musb_g_tx(struct musb *musb, u8 epnum)
u8 is_dma = 0;
if (dma (csr MUSB_TXCSR_DMAENAB)) {
- is_dma = 1;
csr |= MUSB_TXCSR_P_WZC_BITS;
csr = ~(MUSB_TXCSR_DMAENAB | MUSB_TXCSR_P_UNDERRUN |
MUSB_TXCSR_TXPKTRDY);
@@ -471,6 +486,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
/* Ensure writebuffer is empty. */
csr = musb_readw(epio, MUSB_TXCSR);
request-actual += musb_ep-dma-actual_len;
+
+ if (request-actual == request-length)
+ is_dma = 1;
+
DBG(4, TXCSR%d %04x, DMA off, len %zu, req %p\n,
epnum, csr, musb_ep-dma-actual_len, request);
}
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 70342eb..6118d5f 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -54,12 +54,18 @@ static void musb_sysdma_completion(int lch, u16 ch_status,
void *data)
(struct musb_dma_channel *) data;
struct musb_dma_controller *controller = musb_channel-controller;
struct musb *musb = controller-private_data;
+ void __iomem *mbase = controller-base;
+
channel = musb_channel-channel;
DBG(2, lch = 0x%d, ch_status = 0x%x\n, lch, ch_status);
spin_lock_irqsave(musb-lock, flags);
- addr = (u32) omap_get_dma_dst_pos(musb_channel-sysdma_channel);
+ if (musb_channel-transmit)
+ addr = (u32) omap_get_dma_src_pos(musb_channel-sysdma_channel);
+ else
+ addr = (u32) omap_get_dma_dst_pos(musb_channel-sysdma_channel);
+
if (musb_channel-len == 0)
channel-actual_len = 0;
RE: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, May 01, 2010 5:34 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
t...@atomide.com
Subject: Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device
[...]
+static int init_gpio_info(void)
+{
+ gpio_bank_bits = 32;
+
+ if (cpu_is_omap15xx()) {
+ gpio_bank_count = 2;
+ gpio_bank_bits = 16;
+ } else if (cpu_is_omap16xx()) {
+ gpio_bank_count = 5;
+ gpio_bank_bits = 16;
+ } else if (cpu_is_omap7xx())
+ gpio_bank_count = 7;
+ else if (cpu_is_omap242x())
+ gpio_bank_count = 4;
+ else if (cpu_is_omap243x())
+ gpio_bank_count = 5;
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ gpio_bank_count = OMAP34XX_NR_GPIOS;
Both the bank count and bank bits could be part of platform_data
and set in the SoC specific init. This is the GPIO driver part
and we're trying to make this as SoC independent as possible. Anytime
you need to add a cpu_is* or #ifdef in this code indicates something
that should be part of SoC specific init and passed in.
bank count and bank bits are not specific to each device, but SoC specific.
Hence I did not consider passing it as part of platform_data, because this
information would be duplicated across all devices in that SoC.
It would be good if we have a way to pass the SoC specific data which is
common for all the devices rather than duplicating them by sending them via
platform_data.
Anyways, I can move it to platform_data if there is no other way.
Probably the right place for the SoC specifics is attached to the SoC
specific hwmod using the dev_attr pointer. That struct can then
be passed in via platform_data.
You can see how Thara did this for SmartReflex as an example.
Using dev_attr for OMAP2PLUS is fine. How about OMAP1?
1. To be implemented in a uniform way, may I get this info as
part of platform_data?
2. Use dev_attr for OMAP2PLUS and use platform_data for OMAP1?
Any other way? Please suggest.
--
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/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip specific GPIO
Tony/Kevin,
+{
+ if (cpu_is_omap242x())
+ gpio_bank_count = 4;
+ else if (cpu_is_omap243x())
+ gpio_bank_count = 5;
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ gpio_bank_count = OMAP34XX_NR_GPIOS;
+
+ if (gpio_init())
+ return -EINVAL;
+
+ early_platform_driver_register_all(earlygpio);
+ early_platform_driver_probe(earlygpio, gpio_bank_count, 0);
+ return 0;
+}
Then please replace this init with something like:
Okay.
#ifdef CONFIG_ARCH_OMAP2
int __init omap242x_gpio_init(void)
{
if (!cpu_is_omap2420())
return -EINVAL;
gpio_bank_count = 4;
return gpio_init(METHOD_GPIO_24XX);
}
subsys_initcall(omap242x_gpio_init);
int __init omap243x_gpio_init(void)
{
if (!cpu_is_omap2430())
return -EINVAL;
gpio_bank_count = 5;
return gpio_init(METHOD_GPIO_24XX);
}
subsys_initcall(omap243x_gpio_init);
#endif
#ifdef CONFIG_ARCH_OMAP3
int __init omap34xx_gpio_init(void)
{
if (!cpu_is_omap34xx())
return -EINVAL;
gpio_bank_count = OMAP34X_NR_GPIOS;
return gpio_init(METHOD_GPIO_34XX);
}
subsys_initcall(omap34xx_gpio_init);
#endif
...
This way it will be more future proof when new omaps get added
and the if else stuff disappears. Also then you'll have an omap
specific function to initialize the gpio stuff.
Note that then early_platform_driver_register_all and
early_platform_driver_probe can be moved to gpio_init.
With multi-omap build the subsys_initcall runs for all of the
selected platforms, but returns early except for the machine
we're running on. All the code is optimized out for omap
specific product kernels.
Okay. Will do the needful and send new patch series in 2 weeks.
subsys_initcall is not sufficient for SoC specific gpio_init as it needs
to be done before machine_init functions access gpio APIs. Hence I am
making SoC specific gpio_init as postcore_initcall.
--
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: [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo
Hello, On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: Hello Nishanth, On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote: Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following: From: Eduardo Valentin eduardo.valen...@nokia.com Export OMAP name and rev under /proc/socinfo node. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/Kconfig |1 + arch/arm/mach-omap1/id.c | 31 --- arch/arm/mach-omap2/id.c | 32 ++-- 3 files changed, 51 insertions(+), 13 deletions(-) [..] diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 37b8a1a..b67486b 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c [..] @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void) } /* Print verbose information */ - pr_info(%s ES%s (, cpu_name, cpu_rev); + snprintf(socinfo, SOCINFO_SZ, %s ES%s, cpu_name, cpu_rev); + pr_info(%s (, socinfo); OMAP3_SHOW_FEATURE(l2cache); OMAP3_SHOW_FEATURE(iva); Just a minor comment - is it a good idea to pushin the features to SOC info as well? currently this is being displayed at bootlog and not beyond.. might be a better approach to move it into socinfo.. Yeah. I would expect that someone would ask this. When I was writing this part I also thought that would be nice to just duplicate all info which is printed into kernel log buffer. But then I decided to proceed with only the info we are needing from userspace. If you think that would be useful to know those as well, then why not adding them. As discussed in #linux-omap IRC channel, we agreed that it would be nice and useful to export the OMAP FEATURES under this interface. But as the code to detect omap features is under re-work currently, for now we are going to leave it out of this patch set. [..] -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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: [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo
Eduardo Valentin had written, on 05/12/2010 07:34 AM, the following: Hello, On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: Hello Nishanth, On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote: Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following: From: Eduardo Valentin eduardo.valen...@nokia.com Export OMAP name and rev under /proc/socinfo node. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/Kconfig |1 + arch/arm/mach-omap1/id.c | 31 --- arch/arm/mach-omap2/id.c | 32 ++-- 3 files changed, 51 insertions(+), 13 deletions(-) [..] diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 37b8a1a..b67486b 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c [..] @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void) } /* Print verbose information */ - pr_info(%s ES%s (, cpu_name, cpu_rev); + snprintf(socinfo, SOCINFO_SZ, %s ES%s, cpu_name, cpu_rev); + pr_info(%s (, socinfo); OMAP3_SHOW_FEATURE(l2cache); OMAP3_SHOW_FEATURE(iva); Just a minor comment - is it a good idea to pushin the features to SOC info as well? currently this is being displayed at bootlog and not beyond.. might be a better approach to move it into socinfo.. Yeah. I would expect that someone would ask this. When I was writing this part I also thought that would be nice to just duplicate all info which is printed into kernel log buffer. But then I decided to proceed with only the info we are needing from userspace. If you think that would be useful to know those as well, then why not adding them. As discussed in #linux-omap IRC channel, we agreed that it would be nice and useful to export the OMAP FEATURES under this interface. But as the code to detect omap features is under re-work currently, for now we are going to leave it out of this patch set. Agreed. other than this, I dont see an issue :) thanks for the work.. Acked-by: Nishanth Menon n...@ti.com [..] -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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: Possible bug in onenand_base ?
I answer to myself.
DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
a single die can also have '2 planes'. I'm right ?
Sorry for these newbie questions, I'm just introducing to OneNAND devices.
Cheers,
Enric
2010/5/12 Enric Balletbò i Serra eballe...@gmail.com:
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit - device id: 0x58 - bit 3 is
1 - dual-die
- Muxed OneNAND 256MB 1.8V 16-bit - device id: 0x40 - bit 3 is 0
-single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra eballe...@gmail.com:
Hi,
2010/5/6 Kyungmin Park kmp...@infradead.org:
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Is a 4-Gbit DDP OneNAND device from Numonyx composed of two 2-Gbit 2KB
page dice stacked together, the device is equipped with two DataRAMs,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Hi,
2010/5/6 Kyungmin Park kyungmin.p...@samsung.com:
Hi,
Can you add this statement at below the code?
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr this-page_shift)
this-page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr this-page_shift); */
page = (int) (addr - onenand_addr(this, block))
this-page_shift;
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr
this-page_shift)
this-page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block = ~1;
/* Is it the odd plane? */
if (addr this-writesize)
block++;
page = 1;
}
page = this-page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8
Hello.
Ajay Kumar Gupta wrote:
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch supports device side CDC/RNDIS. Host side would require
change in Tx programming path for mode-0 operation when transfer length
is more than packet size.
Also fixed an issue in device Tx completion path where 'is_dma' is getting
set unconditionally. This would fail the io if Tx transfer is done in
mode-0. Fixed it by updating it based on 'request-actual' length.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[...]
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 70342eb..6118d5f 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -54,12 +54,18 @@ static void musb_sysdma_completion(int lch, u16 ch_status,
void *data)
(struct musb_dma_channel *) data;
struct musb_dma_controller *controller = musb_channel-controller;
struct musb *musb = controller-private_data;
+ void __iomem *mbase = controller-base;
+
channel = musb_channel-channel;
DBG(2, lch = 0x%d, ch_status = 0x%x\n, lch, ch_status);
spin_lock_irqsave(musb-lock, flags);
- addr = (u32) omap_get_dma_dst_pos(musb_channel-sysdma_channel);
+ if (musb_channel-transmit)
+ addr = (u32) omap_get_dma_src_pos(musb_channel-sysdma_channel);
+ else
+ addr = (u32) omap_get_dma_dst_pos(musb_channel-sysdma_channel);
+
if (musb_channel-len == 0)
channel-actual_len = 0;
else
@@ -72,6 +78,26 @@ static void musb_sysdma_completion(int lch, u16 ch_status,
void *data)
= reconfig 0 : = complete);
channel-status = MUSB_DMA_STATUS_FREE;
+
+ /* completed */
+ if ((musb_channel-transmit) (channel-desired_mode == 0)
+(channel-actual_len == musb_channel-max_packet_sz)) {
+
+ u8 epnum = musb_channel-epnum;
+ int offset = MUSB_EP_OFFSET(epnum,
+ MUSB_TXCSR);
+ u16 txcsr;
+
+ /*
+* The programming guide says that we
+* must clear DMAENAB before DMAMODE.
+*/
+ musb_ep_select(mbase, epnum);
+ txcsr = musb_readw(mbase, offset);
+ txcsr |= MUSB_TXCSR_TXPKTRDY;
+ musb_writew(mbase, offset, txcsr);
+ }
+
musb_dma_completion(musb, musb_channel-epnum, musb_channel-transmit);
spin_unlock_irqrestore(musb-lock, flags);
@@ -138,8 +164,15 @@ static struct dma_channel *dma_channel_allocate(struct
dma_controller *c,
* issue when TX and RX DMA channels are simultaneously
* enabled. To work around this issue, use system DMA
* for all RX channels.
+* Also on MUSB RTL version 1.8 onward (OMAP3630, OMAP4
+* and AM/DM37x) DMA requires buffers to be aligned on
+* a four byte boundary. This affects USB CDC/RNDIS
+* class application where buffers are always unaligned.
+* Using system DMA for unaligned buffers as a
+* workaround for this issue.
*/
- if (((musb-hwvers == MUSB_HWVERS_1400) !transmit)
+ if musb-hwvers == MUSB_HWVERS_1400) !transmit)
+ || (musb-hwvers = MUSB_HWVERS_1800))
use_sdma_workaround()) {
int ret;
ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE,
@@ -194,11 +227,18 @@ static void configure_channel(struct dma_channel *channel,
struct musb *musb = controller-private_data;
void __iomem *mbase = controller-base;
u8 bchannel = musb_channel-idx;
+ u8 buffer_is_aligned = (dma_addr 0x3) ? 0 : 1;
+ u8 use_sdma = (musb_channel-sysdma_channel == -1) ? 0 : 1;
u16 csr = 0;
DBG(4, %p, pkt_sz %d, addr 0x%x, len %d, mode %d\n,
channel, packet_sz, dma_addr, len, mode);
- if (musb_channel-sysdma_channel != -1) {
+
+ if (buffer_is_aligned (packet_sz = 512)
+ (musb-hwvers = MUSB_HWVERS_1800))
+ use_sdma = 0;
+
+ if (use_sdma !musb_channel-transmit) {
/* System DMA */
/* RX: set src = FIFO */
omap_set_dma_transfer_params(musb_channel-sysdma_channel,
@@ -224,6 +264,32 @@ static void configure_channel(struct dma_channel *channel,
omap_start_dma(musb_channel-sysdma_channel);
+ } else if (use_sdma
Re: [RFC][PATCHv2 1/2] SFH7741: proximity sensor driver support
very minor comments follow:
Datta, Shubhrajyoti had written, on 05/12/2010 03:52 AM, the following:
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256 +
include/linux/input/sfh7741.h | 16 +++
4 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/sfh7741.c
create mode 100644 include/linux/input/sfh7741.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23140a3..925dca3 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,13 @@ config INPUT_PCAP
To compile this driver as a module, choose M here: the
module will be called pcap_keys.
+config SENSORS_SFH7741
+ tristate Proximity sensor
+ default y
default n?
+ help
+ Say Y here if you want to use proximity sensor sfh7741.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sfh7741.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 7e95a5d..5fea200 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
+obj-$(CONFIG_SENSORS_SFH7741) += sfh7741.o
diff --git a/drivers/input/misc/sfh7741.c b/drivers/input/misc/sfh7741.c
new file mode 100644
index 000..cde4d1b
--- /dev/null
+++ b/drivers/input/misc/sfh7741.c
@@ -0,0 +1,256 @@
+/*
+ * sfh7741.c
+ *
+ * SFH7741 Proximity Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Shubhrajyoti Datta shubhrajy...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/interrupt.h
+#include linux/pm.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/input/sfh7741.h
+#include linux/slab.h
+
+struct sfh7741_drvdata {
+ struct input_dev *input;
+ int irq;
+ int prox_enable;
+ /* mutex for sysfs operations */
+ struct mutex lock;
+ void (*activate_func)(int state);
+ int (*read_prox)(void);
+};
+
+static irqreturn_t sfh7741_isr(int irq, void *dev_id)
+{
+ struct sfh7741_drvdata *ddata = dev_id;
+ int proximity;
+
+ proximity = ddata-read_prox();
+ input_report_abs(ddata-input, ABS_DISTANCE, proximity);
+ input_sync(ddata-input);
+
+ return IRQ_HANDLED;
+}
+
+static ssize_t set_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int state;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+
+ if (sscanf(buf, %u, state) != 1)
+ return -EINVAL;
+
+ if ((state != 1) (state != 0))
+ return -EINVAL;
+
+ ddata-activate_func(state);
+
+ mutex_lock(ddata-lock);
+ if (state != ddata-prox_enable) {
+ if (state)
+ enable_irq(ddata-irq);
+ else
+ disable_irq(ddata-irq);
+ ddata-prox_enable = state;
+ }
+ mutex_unlock(ddata-lock);
+ return strnlen(buf, count);
+}
+
+static ssize_t show_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ return sprintf(buf, %u\n, ddata-prox_enable);
+}
+static DEVICE_ATTR(state, S_IWUSR | S_IRUGO, show_prox_state, set_prox_state);
+
+static ssize_t show_proximity(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int proximity;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ proximity = ddata-read_prox();
+ return
Re: Bug in omap3evm.c?
On Tue, 11-May-10 4:38 AM +0530, Rick Ball wrote:
I think I've found a small problem in the board-omap3evm.c file under
arch/arm/mach-omap2 (support for the TI/Mistral OMAP35x EVM board).
What I noticed is that the declaration for the array gpio_leds is initialized
with one element (at line 380):
static struct gpio_led gpio_leds[] = {
{
.name = omap3evm::ledb,
/* normally not visible (board underside) */
.default_trigger= default-on,
.gpio = -EINVAL, /* gets replaced */
.active_low = true,
},
};
But then down at line 430 element 2 is set:
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
How did the array end up with 3 elements so that 2 would be a valid index?
It looks to me like it wouldn't flag an error, but would corrupt memory. I'd
submit a patch, but I'm not sure what this code was attempting to do...
This appears to be like a bug. Possibly there would have been some
entries earlier which got removed, but the indexing done in the code
never got updated.
- Ranjith
--
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/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip specific GPIO
Varadarajan, Charulatha ch...@ti.com writes:
Tony/Kevin,
+{
+if (cpu_is_omap242x())
+gpio_bank_count = 4;
+else if (cpu_is_omap243x())
+gpio_bank_count = 5;
+else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+gpio_bank_count = OMAP34XX_NR_GPIOS;
+
+if (gpio_init())
+return -EINVAL;
+
+early_platform_driver_register_all(earlygpio);
+early_platform_driver_probe(earlygpio, gpio_bank_count, 0);
+return 0;
+}
Then please replace this init with something like:
Okay.
#ifdef CONFIG_ARCH_OMAP2
int __init omap242x_gpio_init(void)
{
if (!cpu_is_omap2420())
return -EINVAL;
gpio_bank_count = 4;
return gpio_init(METHOD_GPIO_24XX);
}
subsys_initcall(omap242x_gpio_init);
int __init omap243x_gpio_init(void)
{
if (!cpu_is_omap2430())
return -EINVAL;
gpio_bank_count = 5;
return gpio_init(METHOD_GPIO_24XX);
}
subsys_initcall(omap243x_gpio_init);
#endif
#ifdef CONFIG_ARCH_OMAP3
int __init omap34xx_gpio_init(void)
{
if (!cpu_is_omap34xx())
return -EINVAL;
gpio_bank_count = OMAP34X_NR_GPIOS;
return gpio_init(METHOD_GPIO_34XX);
}
subsys_initcall(omap34xx_gpio_init);
#endif
...
This way it will be more future proof when new omaps get added
and the if else stuff disappears. Also then you'll have an omap
specific function to initialize the gpio stuff.
Note that then early_platform_driver_register_all and
early_platform_driver_probe can be moved to gpio_init.
With multi-omap build the subsys_initcall runs for all of the
selected platforms, but returns early except for the machine
we're running on. All the code is optimized out for omap
specific product kernels.
Okay. Will do the needful and send new patch series in 2 weeks.
subsys_initcall is not sufficient for SoC specific gpio_init as it needs
to be done before machine_init functions access gpio APIs. Hence I am
making SoC specific gpio_init as postcore_initcall.
OK. Please add a comment at the postcore_initcall() location with the
details as to why it is needed and what it needs to go before etc.
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 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8
Hello.
Gupta, Ajay Kumar wrote:
Hi,
if (channel-status == MUSB_DMA_STATUS_BUSY) {
if (musb_channel-transmit) {
+ if (musb_channel-sysdma_channel != -1)
+ omap_stop_dma(musb_channel-sysdma_channel);
+
Have you thought about e.g. Blackfin? How this is going to compile
there, without omap_*() functions even existing? Or did you think that
OMAP is the only user of this driver?
Thanks for pointing this. It would require adding wrapper functions for
Blckfin's.
Better wrap your stuff into #ifdef OMAP, I think...
-Ajay
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
[RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256 +
include/linux/input/sfh7741.h | 39 ++
4 files changed, 305 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/sfh7741.c
create mode 100644 include/linux/input/sfh7741.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23140a3..ff30196 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,13 @@ config INPUT_PCAP
To compile this driver as a module, choose M here: the
module will be called pcap_keys.
+config SENSORS_SFH7741
+ tristate Proximity sensor
+ default n
+ help
+ Say Y here if you want to use proximity sensor sfh7741.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sfh7741.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 7e95a5d..5fea200 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
+obj-$(CONFIG_SENSORS_SFH7741) += sfh7741.o
diff --git a/drivers/input/misc/sfh7741.c b/drivers/input/misc/sfh7741.c
new file mode 100644
index 000..3f54e98
--- /dev/null
+++ b/drivers/input/misc/sfh7741.c
@@ -0,0 +1,256 @@
+/*
+ * sfh7741.c
+ *
+ * SFH7741 Proximity Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Shubhrajyoti Datta shubhrajy...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/interrupt.h
+#include linux/pm.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/input/sfh7741.h
+#include linux/slab.h
+
+struct sfh7741_drvdata {
+ struct input_dev *input;
+ int irq;
+ int prox_enable;
+ /* mutex for sysfs operations */
+ struct mutex lock;
+ void (*activate_func)(int state);
+ int (*read_prox)(void);
+};
+
+static irqreturn_t sfh7741_isr(int irq, void *dev_id)
+{
+ struct sfh7741_drvdata *ddata = dev_id;
+ int proximity;
+
+ proximity = ddata-read_prox();
+ input_report_abs(ddata-input, ABS_DISTANCE, proximity);
+ input_sync(ddata-input);
+
+ return IRQ_HANDLED;
+}
+
+static ssize_t set_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int state;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+
+ if (sscanf(buf, %u, state) != 1)
+ return -EINVAL;
+
+ if ((state != 1) (state != 0))
+ return -EINVAL;
+
+ ddata-activate_func(state);
+
+ mutex_lock(ddata-lock);
+ if (state != ddata-prox_enable) {
+ if (state)
+ enable_irq(ddata-irq);
+ else
+ disable_irq(ddata-irq);
+ ddata-prox_enable = state;
+ }
+ mutex_unlock(ddata-lock);
+ return strnlen(buf, count);
+}
+
+static ssize_t show_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ return sprintf(buf, %u\n, ddata-prox_enable);
+}
+static DEVICE_ATTR(state, S_IWUSR | S_IRUGO, show_prox_state, set_prox_state);
+
+static ssize_t show_proximity(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int proximity;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ proximity = ddata-read_prox();
+ return sprintf(buf, %u\n, proximity);
+}
+static DEVICE_ATTR(proximity, S_IRUGO, show_proximity, NULL);
+
+static struct attribute
[RFC] [PATCH] OMAP: Remove compilation warnings
Against for-next branch
---
Add __attribute__ ((unused))
arch/arm/mach-omap2/clockdomains.h:58
warning: 'gfx_sgx_wkdeps' defined but not used
arch/arm/mach-omap2/mux.c:52
warning: 'mux_phys' defined but not used
Initialize to 0
arch/arm/plat-omap/gpio.c
In function 'omap2_gpio_resume_after_retention':
2131: warning: 'l' may be used uninitialized in this function
arch/arm/plat-omap/gpio.c
In function 'omap2_gpio_prepare_for_retention':
2074: warning: 'l2' may be used uninitialized in this function
arch/arm/plat-omap/gpio.c:2074
warning: 'l1' may be used uninitialized in this function
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/clockdomains.h |2 +-
arch/arm/mach-omap2/mux.c |2 +-
arch/arm/plat-omap/gpio.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 8fc19ff..cf23547 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -55,7 +55,7 @@
* These can share data since they will never be present simultaneously
* on the same device.
*/
-static struct clkdm_dep gfx_sgx_wkdeps[] = {
+static __attribute__ ((unused)) struct clkdm_dep gfx_sgx_wkdeps[] = {
{
.clkdm_name = core_l3_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 8b3d269..269449a 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -49,7 +49,7 @@ struct omap_mux_entry {
struct list_headnode;
};
-static unsigned long mux_phys;
+static __attribute__ ((unused)) unsigned long mux_phys;
static void __iomem *mux_base;
u16 omap_mux_read(u16 reg)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index dddc9d6..fffc7f2 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2071,7 +2071,7 @@ void omap2_gpio_prepare_for_retention(void)
* IRQs will be generated. See OMAP2420 Errata item 1.101. */
for (i = 0; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
if (!(bank-enabled_non_wakeup_gpios))
continue;
@@ -2128,7 +2128,7 @@ void omap2_gpio_resume_after_retention(void)
return;
for (i = 0; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
if (!(bank-enabled_non_wakeup_gpios))
continue;
--
1.5.4.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 v2 0/6] OMAP: hwmod: Full data set for OMAP4430 ES1.0
Hi, Here is the OMAP4430 ES1.0 hwmod data serie v2. It is based on the OMAP: HWMOD fixes and cleanup serie: http://marc.info/?l=linux-omapm=127324706012621w=2 It was only tested on OMAP4430 ES1.0 GP device using PAB board for the moment. Please note, that the two temporary fixes are pure hacks that are just there to allow the OMAP4 hwmod to boot properly and work corretly with the debug uart. There are not intented to go upstream. The second part of the data set OMAP4: hwmod: Add remaining hwmod support for OMAP4430 ES1.0 is commented out for the moment. The idea being that each time a driver is validated with this hwmod data, the comment can (and must) be removed. I'd like to thanks Rajendra and Santosh for their help during the debug. Comments are welcome. Thanks, Benoit v1 http://marc.info/?l=linux-omapm=127324843814741w=2 v2 - [PATCH 3/6] OMAP4: hwmod: Enable omap_device build for OMAP4 Removed some old defines for OMAP_32KSYNCT_BASE that has nothing to do in that file and was already removed by Tony. Benoit Cousson (3): OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0 OMAP4: hwmod: Enable omap_hwmod build for OMAP4 OMAP4: hwmod: Add remaining hwmod support for OMAP4430 ES1.0 Rajendra Nayak (3): OMAP4: hwmod: Enable omap_device build for OMAP4 OMAP: hwmod: Temporary disable dependency OMAP: hwmod: Temp fixes to get hwmod registers work arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/io.c |6 +- arch/arm/mach-omap2/omap_hwmod.c | 12 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4900 ++ arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 6 files changed, 4920 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] OMAP4: hwmod: Enable omap_hwmod build for OMAP4
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile |3 ++-
arch/arm/mach-omap2/io.c |6 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..5acdba2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -15,7 +15,7 @@ clock-common = clock.o
clock_common_data.o \
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
-obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common)
+obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
@@ -82,6 +82,7 @@ obj-$(CONFIG_ARCH_OMAP2430) += opp2430_data.o
obj-$(CONFIG_ARCH_OMAP2420)+= omap_hwmod_2420_data.o
obj-$(CONFIG_ARCH_OMAP2430)+= omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3cfb425..687c629 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -324,6 +324,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
+ else if (cpu_is_omap44xx())
+ omap44xx_hwmod_init();
+
omap2_mux_init();
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
@@ -340,8 +343,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
pr_err(Could not init clock framework - unknown CPU\n);
omap_serial_early_init();
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
- omap_hwmod_late_init();
+ omap_hwmod_late_init();
omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0eccc09..d0daa97 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -530,5 +530,6 @@ int omap_hwmod_for_each_by_class(const char *classname,
extern int omap2420_hwmod_init(void);
extern int omap2430_hwmod_init(void);
extern int omap3xxx_hwmod_init(void);
+extern int omap44xx_hwmod_init(void);
#endif
--
1.6.1.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 v2 6/6] OMAP: hwmod: Temp fixes to get hwmod registers work
From: Rajendra Nayak rna...@ti.com Do not disable any clocks yet since not all drivers are adapted and rely on bootloader to enable clocks Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 302f2c8..9f7cb9f 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -524,6 +524,8 @@ static int _disable_clocks(struct omap_hwmod *oh) pr_debug(omap_hwmod: %s: disabling clocks\n, oh-name); + return 0; + if (oh-_clk) clk_disable(oh-_clk); -- 1.6.1.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 v2 3/6] OMAP4: hwmod: Enable omap_device build for OMAP4
From: Rajendra Nayak rna...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 98f0191..9405831 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o # omap_device support (OMAP2+ only at the moment) obj-$(CONFIG_ARCH_OMAP2) += omap_device.o obj-$(CONFIG_ARCH_OMAP3) += omap_device.o +obj-$(CONFIG_ARCH_OMAP4) += omap_device.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o -- 1.6.1.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 v2 4/6] OMAP: hwmod: Temporary disable dependency
From: Rajendra Nayak rna...@ti.com
Dependency not supported yet, hence comment all dependency handling
code in hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2fff39f..302f2c8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -908,7 +908,9 @@ static int _enable(struct omap_hwmod *oh)
/* XXX mux balls */
+#if 0
_add_initiator_dep(oh, mpu_oh);
+#endif
_enable_clocks(oh);
r = _wait_target_ready(oh);
@@ -949,7 +951,9 @@ static int _idle(struct omap_hwmod *oh)
if (oh-class-sysc)
_sysc_idle(oh);
+#if 0
_del_initiator_dep(oh, mpu_oh);
+#endif
_disable_clocks(oh);
oh-_state = _HWMOD_STATE_IDLE;
@@ -1544,7 +1548,10 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
int omap_hwmod_add_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh)
{
+#if 0
return _add_initiator_dep(oh, init_oh);
+#endif
+ return 0;
}
/*
@@ -1569,7 +1576,10 @@ int omap_hwmod_add_initiator_dep(struct omap_hwmod *oh,
int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh)
{
+#if 0
return _del_initiator_dep(oh, init_oh);
+#endif
+ return 0;
}
/**
--
1.6.1.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 v3 2/2] ARM: McBSP: Add support for omap4 in McBSP driver
McBSP module in OMAP4 needs to be able to set its tx/rx threshold
and enable the transmitter/receiver when starting an audio stream.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
arch/arm/plat-omap/mcbsp.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 6696eb6..6dbe669 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -489,7 +489,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold)
{
struct omap_mcbsp *mcbsp;
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx() !cpu_is_omap44xx())
return;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -511,7 +511,7 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
{
struct omap_mcbsp *mcbsp;
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx() !cpu_is_omap44xx())
return;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -587,7 +587,7 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp
*mcbsp)
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
u16 syscon;
syscon = MCBSP_READ(mcbsp, SYSCON);
@@ -610,7 +610,7 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp
*mcbsp)
/*
* Disable wakup behavior, smart idle and all wakeups
*/
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
u16 syscon;
syscon = MCBSP_READ(mcbsp, SYSCON);
@@ -859,7 +859,7 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
MCBSP_WRITE(mcbsp, SPCR2, w | (1 7));
}
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
/* Release the transmitter and receiver */
w = MCBSP_READ_CACHE(mcbsp, XCCR);
w = ~(tx ? XDISABLE : 0);
@@ -889,7 +889,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
/* Reset transmitter */
tx = 1;
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
w = MCBSP_READ_CACHE(mcbsp, XCCR);
w |= (tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
@@ -899,7 +899,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
/* Reset receiver */
rx = 1;
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
w = MCBSP_READ_CACHE(mcbsp, RCCR);
w |= (rx ? RDISABLE : 0);
MCBSP_WRITE(mcbsp, RCCR, w);
--
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 v3 0/2] McBSP changes for OMAP4 platform
The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Changes from v2: - Fixed missing parentheses. - Added Acked-by tag to patch #1. - Sending to alsa-devel list also, as suggested by Peter Ujfalusi and Liam Girdwood Jorge Eduardo Candelaria (2): ARM: McBSP: Fix request for irq in OMAP4 ARM: OMAP4: Add support for omap4 in McBSP driver arch/arm/mach-omap2/mcbsp.c | 12 arch/arm/plat-omap/mcbsp.c | 34 +++--- 2 files changed, 23 insertions(+), 23 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
[PATCH v3 1/2] ARM: McBSP: Fix request for irq in OMAP4
In OMAP4, there is only one irq line for TX and RX paths. Use
the correct irq line to avoid errors at runtime.
Also, request irq line only once (instead of requesting for TX
and RX).
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/mcbsp.c | 12
arch/arm/plat-omap/mcbsp.c | 20
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 2f3cad6..c293370 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -187,32 +187,28 @@ static struct omap_mcbsp_platform_data
omap44xx_mcbsp_pdata[] = {
.phys_base = OMAP44XX_MCBSP1_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP1_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP1_TX,
- .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
+ .tx_irq = OMAP44XX_IRQ_MCBSP1,
.ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP44XX_MCBSP2_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP2_TX,
- .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .tx_irq = OMAP44XX_IRQ_MCBSP2,
.ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP44XX_MCBSP3_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP3_TX,
- .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP3_IRQ_TX,
+ .tx_irq = OMAP44XX_IRQ_MCBSP3,
.ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP44XX_MCBSP4_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP4_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP4_TX,
- .rx_irq = INT_24XX_MCBSP4_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP4_IRQ_TX,
+ .tx_irq = OMAP44XX_IRQ_MCBSP4,
.ops= omap2_mcbsp_ops,
},
};
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e1d0440..6696eb6 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -724,14 +724,17 @@ int omap_mcbsp_request(unsigned int id)
goto err_clk_disable;
}
- init_completion(mcbsp-rx_irq_completion);
- err = request_irq(mcbsp-rx_irq, omap_mcbsp_rx_irq_handler,
+ if (mcbsp-rx_irq) {
+ init_completion(mcbsp-rx_irq_completion);
+ err = request_irq(mcbsp-rx_irq,
+ omap_mcbsp_rx_irq_handler,
0, McBSP, (void *)mcbsp);
- if (err != 0) {
- dev_err(mcbsp-dev, Unable to request RX IRQ %d
- for McBSP%d\n, mcbsp-rx_irq,
- mcbsp-id);
- goto err_free_irq;
+ if (err != 0) {
+ dev_err(mcbsp-dev, Unable to request RX IRQ
%d
+ for McBSP%d\n, mcbsp-rx_irq,
+ mcbsp-id);
+ goto err_free_irq;
+ }
}
}
@@ -781,7 +784,8 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp-io_type == OMAP_MCBSP_IRQ_IO) {
/* Free IRQs */
- free_irq(mcbsp-rx_irq, (void *)mcbsp);
+ if (mcbsp-rx_irq)
+ free_irq(mcbsp-rx_irq, (void *)mcbsp);
free_irq(mcbsp-tx_irq, (void *)mcbsp);
}
--
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
Re: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4
On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote: MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are simultaneously enabled which results in DMA lockup. I've seen it on rtl1.8 also if I remember correctly. Use system DMA for all RX channels as a workaround of this issue as this will have minimal throughput overhead based on the fact that Rx transfers are done in DMA mode-0 on OMAP34x/35x platforms. Another approach to use PIO mode in opposite direction would increase the cpu loading and thus using system DMA is preferred workaround. Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com I think falling back to pio is better than this patch. It will most likely be only one transfer. Another approach is to allocate dma channels on a transfer basis. This is way too big of a problem. -- 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 3/5] musb: add function to check if Inventra DMA used
On Wed, May 12, 2010 at 05:19:37PM +0530, Ajay Kumar Gupta wrote: Added is_inventra_dma_enabled() funtion which would be required for adding workaround for Inventra DMA issues. It can also be used at other places instead of #ifdefs. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com [..] +#ifdef CONFIG_USB_INVENTRA_DMA +#define is_inventra_dma_enabled() 1 +#else +#define is_inventra_dma_enabled() 0 +#endif actually I wanted to get rid of those... -- 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 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8
On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch supports device side CDC/RNDIS. Host side would require
change in Tx programming path for mode-0 operation when transfer length
is more than packet size.
Also fixed an issue in device Tx completion path where 'is_dma' is getting
set unconditionally. This would fail the io if Tx transfer is done in
mode-0. Fixed it by updating it based on 'request-actual' length.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[..]
@@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND
DMA channels are simultaneously enabled. To work around this issue,
you can choose to use System DMA for RX channels.
+ Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x)
+ requires buffers to be aligned on a four byte boundary. This affects
+ USB CDC/RNDIS class application where buffers are always unaligned.
+ To work around this issue, you can choose to use System DMA for
+ unaligned buffers.
instead of this patch, it's a whole lot easier to simply use a bounce
buffer:
if (unaligned) {
bounce = dma_alloc_coherent(..);
memcpy(request-buf, bounce, request-length);
}
and use that buffer on channel_program();
--
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
Problems with A/D Converter (twl4030-madc driver?)
I have been having some issues with the A/D converter on the OMAP3530
platform, using the TWL4030. The hardware I am using is the Logic
OMAP3530 LV SOM Zoom2 Development Kit. I created a driver which uses
the twl4030-madc driver to obtain the A/D values for ADCIN3 and
ADCIN4. I am not getting valid values back from the MADC driver. For
instance, I am getting 0 for ADCIN3 and 24496 for ADCIN4. (24496 is
obviously wrong as it is out of the range of the 10-bit A/D...) Even
if I vary the voltage on these inputs, I get the same results. Here
is the structure that I am sending into the twl4030_conversion()
function:
// ** start code
struct twl4030_madc_request req;
int tempX, tempY;
req.channels = 0x | TWL4030_MADC_ADCIN3 | TWL4030_MADC_ADCIN4;
req.do_avg = 0;
req.method = TWL4030_MADC_SW1;
req.active = 0;
req.type = TWL4030_MADC_WAIT;
req.func_cb = NULL;
twl4030_madc_conversion(req);
if(req == NULL)
{
printk(req is NULL after conversion request!\n);
}
else if(req.rbuf == NULL)
{
printk(req.rbuf is NULL after conversion request!\n);
}
else
{
tempX = (u16)req.rbuf[4];
tempY = (u16)req.rbuf[3];
printk(Received A/D values, tempX = %d, tempY = %d\n, tempX, tempY);
}
// ** end code
I also tried implementing two other versions using 'req.channels =
TWL4030_MADC_ADCIN3' or 'req.channels = TWL4030_MADC_ADCIN4' instead
of the combined version shown above and I am getting the same bogus
results.
Is there some issue with what I am doing here?
Has anyone successfully utilized this driver?
I looked into the issue further by sending/receiving i2c commands
straight to the TWL4030 using i2cset and i2cget in a shell script.
Here is the sequence of commands that I used:
# ** start shell script
i2cset -f -y 1 0x49 0x91 0x90
i2cset -f -y 1 0x4a 0x00 0x01
i2cset -f -y 1 0x4a 0x06 0xff
i2cset -f -y 1 0x4a 0x07 0xff
i2cset -f -y 1 0x4a 0x97 0x02
i2cset -f -y 1 0x4a 0x12 0x20
sleep 1
GPCH3_LSB=`i2cget -f -y 1 0x4a 0x3d`
GPCH3_MSB=`i2cget -f -y 1 0x4a 0x3e`
GPCH4_LSB=`i2cget -f -y 1 0x4a 0x3f`
GPCH4_MSB=`i2cget -f -y 1 0x4a 0x40`
let ADC3=`printf %d $GPCH3_LSB`/64+`printf %d $GPCH3_MSB`*4
let ADC4=`printf %d $GPCH4_LSB`/64+`printf %d $GPCH4_MSB`*4
let VAL3=($ADC3*2444)/1000
let VAL4=($ADC4*2444)/1000
echo ADC3 value is $ADC3 , $VAL3 millivolts GP analog input
echo ADC4 value is $ADC4 , $VAL4 millivolts GP analog input
# ** end shell script
From this script, I am getting 6 for both ADC outputs, even with
varying voltages.
Is there something I am doing wrong here?
Any help would be greatly appreciated. Thanks in advance.
-Steve Ziegler
--
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] musb: use system DMA to fix Inventra DMA issue on RTL-1.4
Felipe Balbi wrote: On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote: MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are simultaneously enabled which results in DMA lockup. I've seen it on rtl1.8 also if I remember correctly. I'm fairly certain that this is not the case with RTL1.8, and if it is I'm very much interested in getting to the bottom of it. Do you have a test case that reproduces the lockup? Or a description of your use-case, or a register dump at failure, or any other clues? Use system DMA for all RX channels as a workaround of this issue as this will have minimal throughput overhead based on the fact that Rx transfers are done in DMA mode-0 on OMAP34x/35x platforms. Another approach to use PIO mode in opposite direction would increase the cpu loading and thus using system DMA is preferred workaround. Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com I think falling back to pio is better than this patch. It will most likely be only one transfer. Another approach is to allocate dma channels on a transfer basis. This is way too big of a problem. Which one is better depends on how many endpoints are doing, transfers in parallel, I suppose. I did post the a patch for the other approach (to fall back to PIO). I haven't received a response to that yet. I'm okay with either approach. - Anand-- 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: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
Hi,
I was wondering if you could provide a bit more detail on what this
driver is actually doing? My appologies if I have missed a
previous explanation. If so, please add a Documentation file
to explain what is going on.
The driver you have here does virtually nothing itself. It takes
both its source of interrupt and read function from platform
data. Given the value is always 0 or 1, I'm guessing you are
simply reading a gpio pin. That makes this effectively a button
and doesn't require any specific code. The fact it is a
proximity sensor isn't relevant to anything other than perhaps
the name.
One or two other points inline below.
Jonathan
On 05/12/10 16:26, Datta, Shubhrajyoti wrote:
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256
+
include/linux/input/sfh7741.h | 39 ++
4 files changed, 305 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/sfh7741.c
create mode 100644 include/linux/input/sfh7741.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23140a3..ff30196 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,13 @@ config INPUT_PCAP
To compile this driver as a module, choose M here: the
module will be called pcap_keys.
Why call the symbol SENSORS? Guessing this is a left over from
this being in hwmon at some point?
+config SENSORS_SFH7741
+ tristate Proximity sensor
+ default n
+ help
+ Say Y here if you want to use proximity sensor sfh7741.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sfh7741.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 7e95a5d..5fea200 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON)+= wm831x-on.o
obj-$(CONFIG_INPUT_YEALINK) += yealink.o
+obj-$(CONFIG_SENSORS_SFH7741)+= sfh7741.o
diff --git a/drivers/input/misc/sfh7741.c b/drivers/input/misc/sfh7741.c
new file mode 100644
index 000..3f54e98
--- /dev/null
+++ b/drivers/input/misc/sfh7741.c
@@ -0,0 +1,256 @@
+/*
+ * sfh7741.c
+ *
+ * SFH7741 Proximity Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Shubhrajyoti Datta shubhrajy...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/interrupt.h
+#include linux/pm.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/input/sfh7741.h
+#include linux/slab.h
+
+struct sfh7741_drvdata {
+ struct input_dev *input;
+ int irq;
+ int prox_enable;
+ /* mutex for sysfs operations */
+ struct mutex lock;
+ void (*activate_func)(int state);
+ int (*read_prox)(void);
+};
+
+static irqreturn_t sfh7741_isr(int irq, void *dev_id)
+{
+ struct sfh7741_drvdata *ddata = dev_id;
+ int proximity;
+
+ proximity = ddata-read_prox();
+ input_report_abs(ddata-input, ABS_DISTANCE, proximity);
+ input_sync(ddata-input);
+
+ return IRQ_HANDLED;
+}
+
+static ssize_t set_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int state;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+
+ if (sscanf(buf, %u, state) != 1)
+ return -EINVAL;
+
+ if ((state != 1) (state != 0))
+ return -EINVAL;
+
+ ddata-activate_func(state);
+
+ mutex_lock(ddata-lock);
+ if (state != ddata-prox_enable) {
+ if (state)
+ enable_irq(ddata-irq);
+ else
+ disable_irq(ddata-irq);
+ ddata-prox_enable = state;
+ }
+ mutex_unlock(ddata-lock);
+ return strnlen(buf, count);
+}
+
+static ssize_t
Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
On Wed, May 12, 2010 at 08:56:19PM +0530, Datta, Shubhrajyoti wrote:
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/input/misc/Kconfig|9 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/sfh7741.c | 256
+
include/linux/input/sfh7741.h | 39 ++
4 files changed, 305 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/sfh7741.c
create mode 100644 include/linux/input/sfh7741.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23140a3..ff30196 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -340,4 +340,13 @@ config INPUT_PCAP
To compile this driver as a module, choose M here: the
module will be called pcap_keys.
+config SENSORS_SFH7741
+ tristate Proximity sensor
Better name for the user: SFH7741 Proximity sensor
+ default n
Just drop default altogether - it will be the same as default n
+ help
+ Say Y here if you want to use proximity sensor sfh7741.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sfh7741.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 7e95a5d..5fea200 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON)+= wm831x-on.o
obj-$(CONFIG_INPUT_YEALINK) += yealink.o
+obj-$(CONFIG_SENSORS_SFH7741)+= sfh7741.o
diff --git a/drivers/input/misc/sfh7741.c b/drivers/input/misc/sfh7741.c
new file mode 100644
index 000..3f54e98
--- /dev/null
+++ b/drivers/input/misc/sfh7741.c
@@ -0,0 +1,256 @@
+/*
+ * sfh7741.c
No file names in the sources please - they tend to get renamed and moved
around.
+ *
+ * SFH7741 Proximity Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Shubhrajyoti Datta shubhrajy...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/interrupt.h
+#include linux/pm.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/input/sfh7741.h
+#include linux/slab.h
+
+struct sfh7741_drvdata {
+ struct input_dev *input;
+ int irq;
+ int prox_enable;
+ /* mutex for sysfs operations */
+ struct mutex lock;
+ void (*activate_func)(int state);
+ int (*read_prox)(void);
+};
+
+static irqreturn_t sfh7741_isr(int irq, void *dev_id)
+{
+ struct sfh7741_drvdata *ddata = dev_id;
+ int proximity;
+
+ proximity = ddata-read_prox();
+ input_report_abs(ddata-input, ABS_DISTANCE, proximity);
+ input_sync(ddata-input);
+
+ return IRQ_HANDLED;
+}
+
+static ssize_t set_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int state;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+
+ if (sscanf(buf, %u, state) != 1)
+ return -EINVAL;
+
+ if ((state != 1) (state != 0))
+ return -EINVAL;
+
+ ddata-activate_func(state);
+
+ mutex_lock(ddata-lock);
+ if (state != ddata-prox_enable) {
+ if (state)
+ enable_irq(ddata-irq);
+ else
+ disable_irq(ddata-irq);
+ ddata-prox_enable = state;
+ }
+ mutex_unlock(ddata-lock);
+ return strnlen(buf, count);
+}
+
+static ssize_t show_prox_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sfh7741_drvdata *ddata = platform_get_drvdata(pdev);
+ return sprintf(buf, %u\n, ddata-prox_enable);
+}
+static DEVICE_ATTR(state, S_IWUSR | S_IRUGO, show_prox_state,
set_prox_state);
+
Why is this needed in sysfs? Implement open and close methods for input
device and be done with it.
+static ssize_t show_proximity(struct device
Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi, I didn't touch this issue in the hopes that it would be fixed, but seems it hasn't. On Mon, Apr 19, 2010 at 9:25 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: To sum up: - DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT is only hidden the problem, we don't need aligned memory in this point, that patch should be removed if it is already apply. - There is no need to create a patch for the issue because it is already indirectly fix with DSPBRIDGE: MMU-Fault debugging enhancements. If you are referring to this patch: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 I tried to backport it to minimize the changes to a reproducible test-case. I guess in the l-o branch the commit would be dd1fd0b. Unfortunately that didn't fix the corruption. So I don't by that GPT8 theory. - we don't need allocate memory for dummy_va_addr, if some patch should be created should be the patch to remove dummy_va_addr allocation and deletion. I tried that, and that actually fixes the corruption for me (passing 0 to hw_mmu_tlb_add). -- Felipe Contreras -- 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_hsmmc: improve interrupt synchronisation
On Wed, 12 May 2010 10:50:45 +0300
Adrian Hunter adrian.hun...@nokia.com wrote:
From ad2e1cd024ccf9144b6620cfe808893719db738f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 14 Apr 2010 16:26:45 +0300
Subject: [PATCH] omap_hsmmc: improve interrupt synchronisation
The following changes were needed:
- do not use in_interrupt() because it will not work
with threaded interrupts
In addition, the following improvements were made:
- ensure DMA is unmapped only after the final DMA interrupt
- ensure a request is completed only after the final DMA interrupt
- disable controller interrupts when a request is not in progress
- remove the spin-lock protecting the start of a new request from
an unexpected interrupt because the locking was complicated and
a 'req_in_progress' flag suffices (since the spin-lock only defers
the unexpected interrupts anyway)
- instead use the spin-lock to protect the MMC interrupt handler
from the DMA interrupt handler
- remove the semaphore preventing DMA from being started while
the previous DMA is still in progress - the other changes make that
impossible, so it is now a BUG_ON condition
- ensure the controller interrupt status is clear before exiting
the interrrupt handler
In general, these changes make the code safer but do not fix any specific
bugs so backporting is not necessary.
...
+static void omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct
mmc_request *mrq)
+{
+ int dma_ch;
+
+ spin_lock(host-irq_lock);
+ host-req_in_progress = 0;
+ dma_ch = host-dma_ch;
+ spin_unlock(host-irq_lock);
+
+ omap_hsmmc_disable_irq(host);
+ /* Do not complete the request if DMA is still in progress */
+ if (mrq-data host-use_dma dma_ch != -1)
+ return;
+ host-mrq = NULL;
+ mmc_request_done(host-mmc, mrq);
+}
Are we sure that irq_lock doesn't need to be taken in an irq-safe fashion?
send_init_stream() doesn't report an error if its busywait times out.
--
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: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote: On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote: Hi, I was wondering if you could provide a bit more detail on what this driver is actually doing? My appologies if I have missed a previous explanation. If so, please add a Documentation file to explain what is going on. The driver you have here does virtually nothing itself. It takes both its source of interrupt and read function from platform data. Given the value is always 0 or 1, I'm guessing you are simply reading a gpio pin. That makes this effectively a button and doesn't require any specific code. The fact it is a proximity sensor isn't relevant to anything other than perhaps the name. Excellent point. Maybe it should simply use gpio_keys driver with SW_FRONT_PROXIMITY code. I had a look into the datasheet, this SFH 7741 has one Schmitt trigger output: So yes, it's a key even without chatter. -- 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 RFC 4/5] omap: 3430sdp: add ohci platform init
Anand,
-Original Message-
From: Gadiyar, Anand
Sent: Friday, April 02, 2010 10:04 AM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: David Brownell; Gregory Clement; Felipe Balbi; Aguirre, Sergio;
Gadiyar, Anand
Subject: [PATCH RFC 4/5] omap: 3430sdp: add ohci platform init
Add platform initialization code for OHCI on the 3430SDP.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-3430sdp.c
@@ -675,6 +675,12 @@ static const struct ehci_hcd_omap_platfo
.reset_gpio_port[2] = -EINVAL
};
+static const struct ohci_hcd_omap_platform_data ohci_pdata __initconst =
{
+ .port_mode[0] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[1] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[2] = OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
+};
I just noticed that this patch broke the 3430sdp build for me.
I see following error:
arch/arm/mach-omap2/board-3430sdp.c: In function 'omap_3430sdp_init':
arch/arm/mach-omap2/board-3430sdp.c:840: error: ohci_pdata causes a section
type conflict
Removing the const, to make it similar to ehci struct above it, solves the
problem.
Regards,
Sergio
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -817,6 +823,7 @@ static void __init omap_3430sdp_init(voi
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
+ usb_ohci_init(ohci_pdata);
}
static void __init omap_3430sdp_map_io(void)
--
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] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
Hi, -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Wednesday, May 12, 2010 2:39 PM To: Guzman Lugo, Fernando Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth Subject: Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT Hi, I didn't touch this issue in the hopes that it would be fixed, but seems it hasn't. On Mon, Apr 19, 2010 at 9:25 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: To sum up: - DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT is only hidden the problem, we don't need aligned memory in this point, that patch should be removed if it is already apply. - There is no need to create a patch for the issue because it is already indirectly fix with DSPBRIDGE: MMU-Fault debugging enhancements. If you are referring to this patch: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 Yes, that's the patch. Could you make sure that the GPT8 interrupt is generated before acking MMU fault interrupt? I tried to backport it to minimize the changes to a reproducible test-case. I guess in the l-o branch the commit would be dd1fd0b. Unfortunately that didn't fix the corruption. So I don't by that GPT8 theory. - we don't need allocate memory for dummy_va_addr, if some patch should be created should be the patch to remove dummy_va_addr allocation and deletion. I tried that, and that actually fixes the corruption for me (passing 0 to hw_mmu_tlb_add). I think first page DSP side memory is never mapped to MPU side, so even if the DSP corrupts that page it does not affect MPU side. However the right solution is the one explained before: avoid DSP continues executing after MMUfault. Regards, Fernando. -- Felipe Contreras -- 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
Buildfailure for omap3_defconfig due to patch OMAP: RX51: Add LCD Panel support
Hi Roger, I just wanted to inform you that your Patch OMAP: RX51: Add LCD Panel support (b499d77834ae292465f8d06bb0a88f1a647dfa1a) introduces a build failure for the omap3_defconfig. You can see the error message here: http://kisskb.ellerman.id.au/kisskb/buildresult/2601981/ This is due to the fact that omap3_defconfig has CONFIG_MACH_NOKIA_RX51=y set which enables the compilation of arch/arm/mach-omap2/board-rx51.c board-rx51.c calls rx51_video_mem_init in arch/arm/mach-omap2/board-rx51- video.c which is guarded by #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) Unfortunately none if them is set in the omap3_defconfig. Would be nice if you could fix this :) Thanks, Peter Reported-by: Peter Huewe peterhu...@gmx.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: Buildfailure for omap3_defconfig due to patch OMAP: RX51: Add LCD Panel support
Unfortunately I can't get through the nokia mailfilter: Message_contained_possible_malicious_content_and_will_not_be_accepted._If_you_consider_this_to_be_due_to_an_error_please_inform_the_intended_recipients_by_sending_a_simple_e- mail_or_through_other_means/ I get this reply even with a simple hello your mail filter does not like me message :/ Can somebody else please try to forward the message to Roger and Tomi? Thanks, Peter Am Mittwoch 12 Mai 2010 23:31:51 schrieb Peter Hüwe: Hi Roger, I just wanted to inform you that your Patch OMAP: RX51: Add LCD Panel support (b499d77834ae292465f8d06bb0a88f1a647dfa1a) introduces a build failure for the omap3_defconfig. You can see the error message here: http://kisskb.ellerman.id.au/kisskb/buildresult/2601981/ -- 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: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
On Tue, 11 May 2010 17:15:28 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: Here is the version 5 of the change to export OMAP data to userspace (name, revision, id code, production id and die id). Basically, this version is still attempting to create a new file under /proc. It is the /proc/socinfo, which should be used to export bits which are SoC specific (not CPU related, nor machine related). So, differences between previous version are: - merged patch 02/04 with 03/04 to avoid compilation breakages. - simplified the seq_file usage by using the single_open and single_release functions - exported a function to register a seq_operation .show callback - adapted the changes accordingly As usual, comments are welcome. This changelog would be rather more useful if it was to show us some sample output from /proc/socinfo, perhaps accompanied with an explanation for people who aren't familar with this area of the kernel. I'd have thought that sysfs was an appropriate place for this info. Perhaps under /sys/devices/platform? Or /sys/devices/system? Peter's original patch didn't tell us where in the hierarchy the file was placed, nor why it was placed there, not what its contents look like. But crappy changelogs are the norm :( The objections stated in this email: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17630.html appear to still apply to this version of the patches? Kevin didn't explain why he said Please export these via debugfs. Tony didn't clearly explain why he said I don't think we want to export unique chip identifiers by default. So apart from having certain opinions regarding communication skills and wondering why people cc me on stuff without vaguely providing enough info for me to understand what they're thinking, I don't know what to make of it all :( -- 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: Issue with SCHED_FIFO app
On 05/11/2010 08:46 PM, Xianghua Xiao wrote: On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara suresh.raj+linuxo...@gmail.com wrote: Hi All, I had a couple of application (with real time priority SCHED_FIFO) which were working fine on 2.6.16. They have started behaving differently on 2.6.29. I will explain my problem briefly. Application A (my main application) is scheduled with SCHED_FIFO and priority 5. Application B (watchdog application) is also scheduled with SCHED_FIFO but with priority 54. A keeps putting the OMAP to sleep and wake up every 4 seconds and again puts it to sleep. B is supposed to be running every 1.25 seconds to kick watchdog, but since A keeps OMAP in sleep for 4 seconds, it should run as soon as OMAP wakes up. Since B is of a higher priority, its supposed to run whenever the OMAP wakes up and then A should again put it back to sleep. This happens perfectly on 2.6.16 On 2.6.29, B fails to run when OMAP wakes up and before A puts it back to sleep. B only runs if there is atleast 1.5 seconds of delay between the awake-sleep cycle. On searching the internet, I figured out that CFS (completely fair scheduler) was introduced in 2.6.23, which makes some changes to the RT bandwidth (and many users started facing issues with they applications with SCHED_FIFO). Somewhere on the web I found that issuing echo -1 /proc/sys/kernel/sched_rt_runtime_us should disable the changes which affects the RT bandwidth. It actually did help to an extent in solving some other problem (not described above. A's IOCTL call return was getting delayed), but this problem still persists. Any pointers to where I should look for the solution. Is there a way I can revert back to the scheduler behavior as it was on 2.6.16? I have disabled CONFIG_GROUP_SCHED and also CONFIG_CGROUPS. I am using 2.6.29 on an OMAP1 platform. Thanks in advance, Suresh -- 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 I have seen similar things while upgrading a 2.6.18 RT kernel to 2.6.33 RT, actually exactly when CFS was introduced we found performance issues, in that, our main application(a multi-thread SCHED_FIFO / SCHED_RR mixed) runs with much higher overhead under CFS. In 2.6.18RT, the cpu usage is close to 0% and on newer kernel with CFS, the cpu usage is 12% when the application runs idle(i.e. sleeping and waiting for input, WCHAN shows sched_timeout or futex_wait). When the main application runs with real load, cpu usage gets much worse with CFS. I tried various methods, including the one you described above, and made sure no sched_yield is used, etc, still the main application spends 6% cpu in user space and 6% in kernel space while at idle. I tried BFS schedule and it's actually better, about 8% in user space and 0.6% in kernel space while the application runs idle. Again with 2.6.18 RT it's nearly 0% cpu usage. If it's using 6% of CPU in userspace, then it sounds to me like it's not really idle. Could be some kind of timing issue that the scheduler change exposes? -- 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: Issue with SCHED_FIFO app
On Wed, 12 May 2010 12:46:20 Xianghua Xiao wrote: On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara suresh.raj+linuxo...@gmail.com wrote: Hi All, I had a couple of application (with real time priority SCHED_FIFO) which were working fine on 2.6.16. They have started behaving differently on 2.6.29. I will explain my problem briefly. Application A (my main application) is scheduled with SCHED_FIFO and priority 5. Application B (watchdog application) is also scheduled with SCHED_FIFO but with priority 54. A keeps putting the OMAP to sleep and wake up every 4 seconds and again puts it to sleep. B is supposed to be running every 1.25 seconds to kick watchdog, but since A keeps OMAP in sleep for 4 seconds, it should run as soon as OMAP wakes up. Since B is of a higher priority, its supposed to run whenever the OMAP wakes up and then A should again put it back to sleep. This happens perfectly on 2.6.16 On 2.6.29, B fails to run when OMAP wakes up and before A puts it back to sleep. B only runs if there is atleast 1.5 seconds of delay between the awake-sleep cycle. On searching the internet, I figured out that CFS (completely fair scheduler) was introduced in 2.6.23, which makes some changes to the RT bandwidth (and many users started facing issues with they applications with SCHED_FIFO). Somewhere on the web I found that issuing echo -1 /proc/sys/kernel/sched_rt_runtime_us should disable the changes which affects the RT bandwidth. It actually did help to an extent in solving some other problem (not described above. A's IOCTL call return was getting delayed), but this problem still persists. Any pointers to where I should look for the solution. Is there a way I can revert back to the scheduler behavior as it was on 2.6.16? I have disabled CONFIG_GROUP_SCHED and also CONFIG_CGROUPS. I am using 2.6.29 on an OMAP1 platform. Thanks in advance, Suresh -- 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 I have seen similar things while upgrading a 2.6.18 RT kernel to 2.6.33 RT, actually exactly when CFS was introduced we found performance issues, in that, our main application(a multi-thread SCHED_FIFO / SCHED_RR mixed) runs with much higher overhead under CFS. In 2.6.18RT, the cpu usage is close to 0% and on newer kernel with CFS, the cpu usage is 12% when the application runs idle(i.e. sleeping and waiting for input, WCHAN shows sched_timeout or futex_wait). When the main application runs with real load, cpu usage gets much worse with CFS. I tried various methods, including the one you described above, and made sure no sched_yield is used, etc, still the main application spends 6% cpu in user space and 6% in kernel space while at idle. I tried BFS schedule and it's actually better, about 8% in user space and 0.6% in kernel space while the application runs idle. Again with 2.6.18 RT it's nearly 0% cpu usage. It's distinctly possible that there is no change in the CPU usage at all and this is purely representing the change in how CPU accounting is done in CFS, and now BFS since the older mainline scheduler. The old mainline scheduler was potentially very inaccurate at representing CPU usage, particularly when tasks were very short lived. In fact it was possible to write a carefully crafted application that would use 99.9% CPU and register as zero CPU usage, by ensuring it slept just before the accounting tick would be hit. CFS changed dramatically how CPU accounting was done, and on BFS I changed it yet again, trying to make it more accurate. The only way to see if there is a real issue with a change in CPU usage is to measure CPU usage through other means, which can be incredibly difficult to do, such as the power consumed by the CPU, the maximum throughput of the applications, and so on. I do not think this is related to the original issue reported with SCHED_FIFO apps on this email thread though. -- -ck -- 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: Issue with SCHED_FIFO app
On Wed, May 12, 2010 at 9:49 PM, Con Kolivas ker...@kolivas.org wrote: On Wed, 12 May 2010 12:46:20 Xianghua Xiao wrote: On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara suresh.raj+linuxo...@gmail.com wrote: Hi All, I had a couple of application (with real time priority SCHED_FIFO) which were working fine on 2.6.16. They have started behaving differently on 2.6.29. I will explain my problem briefly. Application A (my main application) is scheduled with SCHED_FIFO and priority 5. Application B (watchdog application) is also scheduled with SCHED_FIFO but with priority 54. A keeps putting the OMAP to sleep and wake up every 4 seconds and again puts it to sleep. B is supposed to be running every 1.25 seconds to kick watchdog, but since A keeps OMAP in sleep for 4 seconds, it should run as soon as OMAP wakes up. Since B is of a higher priority, its supposed to run whenever the OMAP wakes up and then A should again put it back to sleep. This happens perfectly on 2.6.16 On 2.6.29, B fails to run when OMAP wakes up and before A puts it back to sleep. B only runs if there is atleast 1.5 seconds of delay between the awake-sleep cycle. On searching the internet, I figured out that CFS (completely fair scheduler) was introduced in 2.6.23, which makes some changes to the RT bandwidth (and many users started facing issues with they applications with SCHED_FIFO). Somewhere on the web I found that issuing echo -1 /proc/sys/kernel/sched_rt_runtime_us should disable the changes which affects the RT bandwidth. It actually did help to an extent in solving some other problem (not described above. A's IOCTL call return was getting delayed), but this problem still persists. Any pointers to where I should look for the solution. Is there a way I can revert back to the scheduler behavior as it was on 2.6.16? I have disabled CONFIG_GROUP_SCHED and also CONFIG_CGROUPS. I am using 2.6.29 on an OMAP1 platform. Thanks in advance, Suresh -- 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 I have seen similar things while upgrading a 2.6.18 RT kernel to 2.6.33 RT, actually exactly when CFS was introduced we found performance issues, in that, our main application(a multi-thread SCHED_FIFO / SCHED_RR mixed) runs with much higher overhead under CFS. In 2.6.18RT, the cpu usage is close to 0% and on newer kernel with CFS, the cpu usage is 12% when the application runs idle(i.e. sleeping and waiting for input, WCHAN shows sched_timeout or futex_wait). When the main application runs with real load, cpu usage gets much worse with CFS. I tried various methods, including the one you described above, and made sure no sched_yield is used, etc, still the main application spends 6% cpu in user space and 6% in kernel space while at idle. I tried BFS schedule and it's actually better, about 8% in user space and 0.6% in kernel space while the application runs idle. Again with 2.6.18 RT it's nearly 0% cpu usage. It's distinctly possible that there is no change in the CPU usage at all and this is purely representing the change in how CPU accounting is done in CFS, and now BFS since the older mainline scheduler. The old mainline scheduler was potentially very inaccurate at representing CPU usage, particularly when tasks were very short lived. In fact it was possible to write a carefully crafted application that would use 99.9% CPU and register as zero CPU usage, by ensuring it slept just before the accounting tick would be hit. CFS changed dramatically how CPU accounting was done, and on BFS I changed it yet again, trying to make it more accurate. The only way to see if there is a real issue with a change in CPU usage is to measure CPU usage through other means, which can be incredibly difficult to do, such as the power consumed by the CPU, the maximum throughput of the applications, and so on. I do not think this is related to the original issue reported with SCHED_FIFO apps on this email thread though. -- -ck The pthread that has most cpu usage(2.6%) is a simple SCHED_RR task waiting on select(), another two top cpu usage SCHED_RR pthreads are our own timers, these three are supposedly idle tasks before a user activates inputs. lmbench was done and the results are close, though 2.6.33rt wins on latency but overall 2.6.18rt has better performance(esp on fork, exec, context switch performance). I'm unsure if the newest top (or /proc/PID/stat) reports the correct cpu usage when CFS/BFS is used, as you mentioned it seems failed to do that. I will try to stress the system and see who fails first under same workload, maybe that's the only way to compare cpu usage between 2.6.18rt vs 2.6.33rt, for now. Thanks a lot, Xianghua -- To unsubscribe from this list: send the
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Hello, Some general comments on the suspend blockers/wakelock/opportunistic suspend v6 patch series, posted here: https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html The comments below are somewhat telegraphic in the interests of readability - more specific comments to follow in later E-mails. I am indebted to those of us who discussed these issues at LPC last year and ELC this year for several stimulating discussions. There are several general problems with the design of opportunistic suspend and suspend-blocks. 1. The opportunistic suspend code bypasses existing Linux kernel code, such as timers and the scheduler, that indicates when code needs to run, and when the system is idle. This causes two problems: a. When opportunistic suspend is enabled, the default mode is to break all timers and scheduling on the system. This isn't right: the default mode should be to preserve standard Linux behavior. Exceptions can then be added for process groups that should run with the non-standard timer and scheduler behavior. b. The series introduces a de novo kernel API and userspace API that are unrelated to timers and the scheduler, but if the point is to modify the behavior of timers or the scheduler, the existing timer or scheduler APIs should be extended. Any new APIs will need to be widely spread throughout the kernel and userspace. 2. The suspend-block kernel API tells the kernel _how_ to accomplish a goal, rather than telling the kernel _what_ the goal is. This results in layering violations, unstated assumptions, and is too coarse-grained. These problems in turn will cause fragile kernel code, kernel code with userspace dependencies, and power management problems on modern hardware. Code should ask for what it wants. For example, if a driver needs to place an upper bound on its device wakeup latency, or if it needs to place an upper bound on interrupt response latency, that is what it should request. Driver and subsystem code should not care how the kernel implements those requests, since the implementation can differ on different hardware and even on different use-cases with the same hardware. 3. Similarly, the suspend-block userspace API tells the kernel how to accomplish a goal, rather than telling the kernel what the goal is. Userspace processes should ask the kernel for what they really want. If a process' timers should be disabled upon entering suspend, or the timer durations should have a lower bound, that's what the API should request. Merging this series as currently designed and implemented will cause problems. Suspend-blocks introduce a second, separate idle management approach in the Linux kernel. The existing approach is the familiar timer and scheduler based approach. The new approach is one where timers and runqueues no longer matter: the system is always at risk of entering suspend at any moment, with only suspend-blocks to stop it. Driver authors will effectively have to implement both approaches in their code. Once merged, it will be nearly impossible to remove this code in favor of a cleaner approach. Suspend-block calls are likely to spread throughout the kernel and drivers. Patches 6, 7, and 8 are the leading edge of this - a quick grep through the Android common kernel at git://android.git.kernel.org/kernel/common.git shows wakelocks in the following drivers: drivers/input/evdev.c drivers/input/misc/gpio_input.c drivers/input/misc/gpio_matrix.c drivers/mmc/core/core.c drivers/rtc/alarm.c drivers/usb/gadget/f_mass_storage.c Suspend-blocks will be difficult to convert to a finer-grained approach later. The API design problems, mentioned above in points 2 and 3, will make it very difficult to determine what a driver author's or modifier's intention was when adding the suspend-block. Also, patches 2 and 7 introduce userspace APIs. We will undoubtedly wish to avoid removing a userspace API once it is merged. It will be quite difficult to implement such a general directive (block system suspend) on a future kernel that may have a much finer-grained notion of low-power system modes, indeed that may have no useful notion of system suspend. ... The opportunistic suspend patches try to solve at least two real problems, that should be resolved in some way. First, some types of userspace processes can unintentionally block system power management. Second, the kernel is missing a system-wide form of CPUIdle. This patch series, though, isn't the right way to solve either of these problems. Let's figure out a different approach. Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices,
RE: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8
Hi,
On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote:
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch supports device side CDC/RNDIS. Host side would require
change in Tx programming path for mode-0 operation when transfer length
is more than packet size.
Also fixed an issue in device Tx completion path where 'is_dma' is
getting
set unconditionally. This would fail the io if Tx transfer is done in
mode-0. Fixed it by updating it based on 'request-actual' length.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[..]
@@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND
DMA channels are simultaneously enabled. To work around this
issue,
you can choose to use System DMA for RX channels.
+ Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x)
+ requires buffers to be aligned on a four byte boundary. This
affects
+ USB CDC/RNDIS class application where buffers are always
unaligned.
+ To work around this issue, you can choose to use System DMA for
+ unaligned buffers.
instead of this patch, it's a whole lot easier to simply use a bounce
buffer:
if (unaligned) {
bounce = dma_alloc_coherent(..);
memcpy(request-buf, bounce, request-length);
}
How about this 'memcpy', this would affect both cpu loading
and performance. That's why using system dma would be a better
approach.
-Ajay
and use that buffer on channel_program();
--
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 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8
Hi, -Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Wednesday, May 12, 2010 11:26 PM To: Sergei Shtylyov Cc: Gupta, Ajay Kumar; linux-...@vger.kernel.org; linux- o...@vger.kernel.org Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8 On Wed, May 12, 2010 at 06:59:52PM +0400, Sergei Shtylyov wrote: Better wrap your stuff into #ifdef OMAP, I think... please don't, better to use the bounce buffer... It would work on blackfin, davinci and omap... Just working is not enough. We need to think of performance and cpu loading as well. -Ajay -- 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/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4
Hi, Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4 Felipe Balbi wrote: On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote: MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are simultaneously enabled which results in DMA lockup. I've seen it on rtl1.8 also if I remember correctly. I'm fairly certain that this is not the case with RTL1.8, and if it is I'm very much interested in getting to the bottom of it. Do you have a test case that reproduces the lockup? Or a description of your use-case, or a register dump at failure, or any other clues? Felipe, I have also not seen lockup issue on rtl1.8. Can you provide more detail on your test case as Anand asked? Use system DMA for all RX channels as a workaround of this issue as this will have minimal throughput overhead based on the fact that Rx transfers are done in DMA mode-0 on OMAP34x/35x platforms. Another approach to use PIO mode in opposite direction would increase the cpu loading and thus using system DMA is preferred workaround. Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com I think falling back to pio is better than this patch. At the cost of cpu, which certainly is not preferred. It will most likely be only one transfer. How about host mode with multiple devices connected and doing transfers? Falling back to PIO would kill the cpu. Another approach is to allocate dma channels on a transfer basis. Can you elaborate this? This is way too big of a problem. If we think of the scenarios in host mode then certainly using system DMA is best approach. -Ajay Which one is better depends on how many endpoints are doing, transfers in parallel, I suppose. I did post the a patch for the other approach (to fall back to PIO). I haven't received a response to that yet. I'm okay with either approach. - Anand -- 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 v4] OMAP3: Registering sgx device and it's platform data
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Signed-off-by: Preshit Agarwal preshit.agar...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@ti.com
Cc: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/devices.c | 21 +++--
arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 +++
2 files changed, 30 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..6349ee5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,7 +26,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
-
+#include mach/omap_sgxdef.h
#include mux.h
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -786,6 +786,23 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+struct sgx_platform_data omap_sgx_data = {
+ .set_min_bus_tput = NULL,
+};
+
+static struct platform_device powervr_device = {
+ .name= pvrsrvkm,
+ .id = -1,
+ .dev= {
+ .platform_data = omap_sgx_data,
+ }
+};
+
+static void omap_init_sgx(void)
+{
+ (void) platform_device_register(powervr_device);
+}
+
/*-*/
static int __init omap2_init_devices(void)
@@ -800,7 +817,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
-
+ omap_init_sgx();
return 0;
}
arch_initcall(omap2_init_devices);
diff --git a/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
new file mode 100644
index 000..e03ad8b
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
@@ -0,0 +1,11 @@
+#ifndef OMAP_SGXDEF_H
+#define OMAP_SGXDEF_H
+
+#include plat/omap-pm.h
+
+struct sgx_platform_data {
+ void (*set_min_bus_tput)(struct device *dev, u8 agent_id,
+ unsigned long r);
+};
+
+#endif
--
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] omap3: update omap3_defconfig
- Update the omap3_defconfig to sync up with the generated .config - Increase CONFIG_LOG_BUF_SHIFT to 16 to allow the entire boot log to be captured (useful when using boot time tracer, for example) Signed-off-by: Anand Gadiyar gadi...@ti.com --- arch/arm/configs/omap3_defconfig | 116 ++- 1 file changed, 79 insertions(+), 37 deletions(-) Index: linux-omap-2.6/arch/arm/configs/omap3_defconfig === --- linux-omap-2.6.orig/arch/arm/configs/omap3_defconfig +++ linux-omap-2.6/arch/arm/configs/omap3_defconfig @@ -1,13 +1,14 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.33-rc5 -# Tue Jan 26 11:05:31 2010 +# Linux kernel version: 2.6.34-rc7 +# Thu May 13 10:54:43 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -19,7 +20,9 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_OPROFILE_ARMV6=y CONFIG_OPROFILE_ARM11_CORE=y CONFIG_OPROFILE_ARMV7=y @@ -63,12 +66,7 @@ CONFIG_RCU_FANOUT=32 # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=14 -CONFIG_GROUP_SCHED=y -CONFIG_FAIR_GROUP_SCHED=y -# CONFIG_RT_GROUP_SCHED is not set -CONFIG_USER_SCHED=y -# CONFIG_CGROUP_SCHED is not set +CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -100,17 +98,21 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +CONFIG_PERF_EVENTS=y +# CONFIG_PERF_COUNTERS is not set +# CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y -CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y @@ -189,6 +191,7 @@ CONFIG_MMU=y # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_BCMRING is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set @@ -198,7 +201,6 @@ CONFIG_MMU=y # CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -215,21 +217,26 @@ CONFIG_MMU=y # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_W90X900 is not set +# CONFIG_ARCH_NUC93X is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_MSM is not set +# CONFIG_ARCH_SHMOBILE is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5P6440 is not set +# CONFIG_ARCH_S5P6442 is not set # CONFIG_ARCH_S5PC1XX is not set +# CONFIG_ARCH_S5PV210 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_U300 is not set +# CONFIG_ARCH_U8500 is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y -# CONFIG_ARCH_BCMRING is not set -# CONFIG_ARCH_U8500 is not set # # TI OMAP Implementations @@ -254,6 +261,7 @@ CONFIG_OMAP_MCBSP=y # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y +# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_PM_NONE is not set @@ -331,11 +339,16 @@ CONFIG_ARM_THUMBEE=y # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_HAS_TLS_REG=y +CONFIG_OUTER_CACHE=y +CONFIG_OUTER_CACHE_SYNC=y +CONFIG_CACHE_L2X0=y CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_CPU_HAS_PMU=y # CONFIG_ARM_ERRATA_411920 is not set # CONFIG_ARM_ERRATA_430973 is not set # CONFIG_ARM_ERRATA_458693 is not set # CONFIG_ARM_ERRATA_460075 is not set +# CONFIG_PL310_ERRATA_588369 is not set CONFIG_ARM_GIC=y CONFIG_COMMON_CLKDEV=y @@ -369,6 +382,7 @@ CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set # CONFIG_HIGHMEM is not set +CONFIG_HW_PERF_EVENTS=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set @@ -444,6 +458,7 @@ CONFIG_BINFMT_MISC=y # CONFIG_PM=y CONFIG_PM_DEBUG=y +# CONFIG_PM_ADVANCED_DEBUG is not set # CONFIG_PM_VERBOSE is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP=y @@ -452,6 +467,7 @@
Re: [PATCH 6/7] omap: init the gpio pinmux for mmc
Tony Lindgren wrote:
* Stanley.Miao stanley.m...@windriver.com [100419 23:20]:
There is two gpio for mmc use, one is for card detecting, another is
used for checking write protect. Intialize its pinmux in case the bootloader
doesn't set it.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/devices.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 23e4d77..df9c62a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -591,6 +591,13 @@ static inline void omap_hsmmc_reset(void) {}
static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
int controller_nr)
{
+ if (mmc_controller-slots[0].switch_pin 0)
+ omap_mux_init_gpio(mmc_controller-slots[0].switch_pin,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].gpio_wp 0)
+ omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
+ OMAP_PIN_INPUT_PULLUP);
+
if (cpu_is_omap2420() controller_nr == 0) {
omap_cfg_reg(H18_24XX_MMC_CMD);
omap_cfg_reg(H15_24XX_MMC_CLKI);
The problem I see with this patch is that it attempts to mux
even for the GPIO pins on the companion chips, such as twl4030.
Got any ideas on how to prevent that?
Hi, Tony,
The gpios on companion chips are greater than OMAP_MAX_GPIO_LINES, they
are not defined
in mux34xx.c, so omap_mux_init_gpio will do nothing.
However, I will add if(gpio_wp OMAP_MAX_GPIO_LINES) to prevent from
invoking omap_mux_init_gpio().
Stanley.
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 3/7] AM3517: rename the i2c boardinfo to make it more readable
Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [100420 00:03]: snip There are three i2c buses on am3517, now rename these three boardinfo structure name to am3517evm_i2c1_boardinfo, am3517evm_i2c2_boardinfo, and am3517evm_i2c3_boardinfo, to make it more readable. [Hiremath, Vaibhav] Since we haven't had any objection/suggestion to follow naming convention based on i2C indexes, I think we can merge this patch. Acked-By: Vaibhav Hiremath hvaib...@ti.com Looks like this needs to be refreshed against the current omap-for-linus branch to apply. OK, I will re-send it soon. Stanley. 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
