On Thu, Mar 05, 2009 at 11:32:31AM -0600, Lopez Cruz, Misael wrote:
Add headset jack detection for SDP3430 boards using SoC jack
reporting interface. Headset detection on SDP3430 board is
achieved through TWL4030 GPIO_2 pin.
Applied, thanks. One comment:
+/* Headset jack detection gpios */
Hi,
These two patches add fixes to GPIO off-mode handling. First patch is more
important as it fixes a HW bug, second one just optimizes off-mode code
a bit by removing a couple of unnecessary registers from the context save.
--Tero
--
To unsubscribe from this list: send the line unsubscribe
Output GPIOs will lose their context during wakeup from off-mode, causing
a short glitch in the output level until the GPIO context can be restored.
Pad configuration must be used to set corresponding pins into safe_mode
and pull-up / pull-down control is used to select the level of the signal.
setwkuena and setdataout are covered already by wake_en and dataout fields.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/plat-omap/gpio.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
On Tuesday 03 March 2009 11:06:50 Sakari Ailus wrote:
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
arch/arm/plat-omap/include/mach/isp_user.h | 676
1 files changed, 676 insertions(+), 0 deletions(-)
create mode 100644
TWL4030 and TWL5030 support 3.0V on VAUX3.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
According to TI:
http://community.ti.com/forums/t/3777.aspx
drivers/regulator/twl4030-regulator.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On Thu, Mar 05, 2009 at 05:33:55PM +0530, Aggarwal, Anuj wrote:
[Please fix your mail client to wrap lines at ~80 columns - not doing so
makes your mails much harder to read and reply to.]
But still when I call regulator_disable() after doing a _get() on it,
the call fails saying unbalanced
Two patches for i2c-omap driver.
Ari Kauppi (1):
i2c: i2c-omap: Call request_irq with IRQF_DISABLED
Eero Nurkkala (1):
i2c: i2c-omap: Fix BUFSTAT_REG reading
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
--
To unsubscribe from this
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
The number of bytes to be received is read from wrong
place with all OMAPs with highspeed I2C support,
which involves a FIFO and BUFSTAT_REG. It is the 6
bits starting from the bit 8 in the BUFSTAT_REG
that indicate this amount of bytes to be read.
I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
(and thus LOCKDEP) are disabled.
Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
but IRQF_DISABLED is needed for proper behaviour.
Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com
Acked-by:
On Thu, 2009-03-05 at 13:54 +0100, ext Menon, Nishanth wrote:
me? I am just a code junkie ;).. They wont let me write the TRM :(.. :D...
I was referring you in plural, meaning TI, not you personally =)
- Eero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
Eero Nurkkala said the following on 03/06/2009 03:41 PM:
On Thu, 2009-03-05 at 13:54 +0100, ext Menon, Nishanth wrote:
me? I am just a code junkie ;).. They wont let me write the TRM :(.. :D...
I was referring you in plural, meaning TI, not you personally =)
Aaaah.. for a
I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
(and thus LOCKDEP) are disabled.
Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
but IRQF_DISABLED is needed for proper behaviour.
I only submitted on l-o list for information and comment.
* Jarkko Nikula jarkko.nik...@nokia.com [090305 23:12]:
On Thu, 5 Mar 2009 17:20:43 +0100
ext Tony Lindgren t...@atomide.com wrote:
Jarkko, this should also be in Documentation/kernel-parameters.txt.
Can you please reply with a patch for that, and I'll fold it into this
patch?
Ah,
While working with cpuidle, I have come across these problems.
I am also working on the solutions, but would be good to hear
more thoughts.
1) The flag 'enable_dyn_sleep' is honoured only in omap3_idle_bm_check()
but in the C1 state, omap3_enter_idle() is invoked directly.
So, the system
On Fri, 2009-03-06 at 15:01 +0200, Adrian Hunter wrote:
TWL4030 and TWL5030 support 3.0V on VAUX3.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
Applied.
Thanks
Liam
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Friday 06 March 2009, Adrian Hunter wrote:
TWL4030 and TWL5030 support 3.0V on VAUX3.
I double checked several technical reference manuals, and they
say otherwise. The 3.0V settings in VAUX3_DEDICATED are very
consistently labeled as TI cannot support these values, for
all current versions
Hi David
On Thu, 5 Mar 2009, david.hag...@gmail.com wrote:
I am trying to build the OMAP3 graphics kernel module against
2.6.29-rc7-omap1 (from GIT), and have been running into problems getting
it to build.
Two problems were pretty easy: the TI code was including asm/resource.h
and
On Fri, Mar 06, 2009 at 11:16:20AM -0800, David Brownell wrote:
Do you really need 3.0V out of that regulator? If so,
then I'd rather see a patch exposing that CONFIG_*
setting to enable all the unsupported/out-of-range
values, rather than just selectively hacking those
tables to permit
On Friday 06 March 2009, Mark Brown wrote:
Would it make sense to make this platform data so that if a given board
requires running the chip like this it can be enabled for those boards
but it's not something people might turn on because it seems useful?
Let's hear if it's actually needed,
Hi,
Here's the patch I promised few days ago to sort the GPIO pins,
sorry for the delay.
Tony
From 362769b996c7514c4bc92eee815ed7ca9aa1544f Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Thu, 5 Mar 2009 17:09:20 -0800
Subject: [PATCH] ARM: OMAP: Sort 34xx GPIO pins, add few
21 matches
Mail list logo
