Add headset jack detection for SDP3430 boards using SoC jack
reporting interface. Headset detection on SDP3430 board is
achieved through TWL4030 GPIO_2 pin.
Signed-off-by: Misael Lopez Cruz
---
sound/soc/omap/sdp3430.c | 31 ++-
1 files changed, 30 insertions(+), 1
Add DAPM machine domain widgets to SDP3430 machine driver.
Current interconection:
* Ext Mic: MAINMIC, SUBMIC
* Ext Spk: HFL, HFR
* Headset Jack: HSMIC, HSOL, HSOR
Signed-off-by: Misael Lopez Cruz
---
sound/soc/omap/sdp3430.c | 61 ++
1 files changed
Add GPIO support for jack reporting framework in ASoC, by using
gpiolib calls. It's only required to append GPIO information (gpio
number, irq handler and flags) to standard jack_pin declaration.
GPIO request, data direction configuration and irq request are
handled by the utility.
The minimal GPI
The following patch set implements GPIO support for SoC jack reporting
interface and uses it in SDP3430 machine driver.
The jack detection interface is used in SDP3430 driver to handle headset
events. That requires DAPM machine widgets to be added to the machine
driver before the actual use of the
On Wednesday 25 February 2009 22:25:59 ext George G. Davis wrote:
> Hi,
>
> On Tue, Nov 25, 2008 at 02:52:58PM +, Mark Brown wrote:
> > On Tue, Nov 25, 2008 at 01:21:20PM +0200, Jarkko Nikula wrote:
> > > Or if those EVM's & SDP's can route TWL4030 audio connections more
> > > flexible than Bea
> -Original Message-
> From: Kim Kyuwon [mailto:chamm...@gmail.com]
> Sent: Thursday, February 26, 2009 12:28 PM
> To: Gadiyar, Anand
> Cc: m...@felipebalbi.com; linux-...@vger.kernel.org; OMAP;
> David Brownell; q1@samsung.com; Minkyu Kang
> Subject: Re: [PATCH 1/2] usb: musb: fix th
On Wed, 25 Feb 2009 21:27:44 +0100
ext Mark Brown wrote:
> On Wed, Feb 25, 2009 at 03:25:59PM -0500, George G. Davis wrote:
>
> > Is someone working on updating ASoC drivers for OMAP TWL4030 based
> > boards as recommended above? Just curious since I already made the
> > mistake of creating my
Hi,
On Thu, Feb 26, 2009 at 3:37 PM, Gadiyar, Anand wrote:
>
>
>> Now I know that, in addition to HSUSB_MC_NINT disabled by the previous
>> patch [ARM: OMAP: Disable USB interrupt in the musb_resume()
>> function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up
>> source events to PRMC m
> Now I know that, in addition to HSUSB_MC_NINT disabled by the previous
> patch [ARM: OMAP: Disable USB interrupt in the musb_resume()
> function], USBTLL_SWAKEUP and USBHOST_SWAKEUP can be also wake-up
> source events to PRMC module. Sorry I didn't know that time. The
> remote wake uses these t
On Thu, Feb 26, 2009 at 9:13 AM, Felipe Balbi wrote:
> On Wed, Feb 25, 2009 at 08:53:00PM +0900, Kim Kyuwon wrote:
>> From: Kim Kyuwon
>>
>> While waking up, musb can cause a kernel panic. This patch is fixing
>> it by enabling the clock in the resume_early method.
>>
>> Signed-off-by: Kim Kyuwon
Hi,
I have updated the patch base on Felipe's patches.
>From db89674b7316d7490e71c131091758eb7ef0eca2 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo
Date: Wed, 25 Feb 2009 19:27:41 -0600
Subject: [PATCH] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull function
This
> I mean, what you're doing here is that you would allow twl4030 to enter
> low power mode even though we're connected to host side, meaning we
> would never get awaken by the host side, right ?
Yes, right.
If usb is connected to host side, our system never sleep because of usb
interrupts by host.
On Wednesday 25 February 2009, Mark Brown wrote:
> > Fixable in an update. I still think it's better to require less
> > manual configuration, not more ... manual configuration is by
> > definition error prone; requiring more manual configuration makes
>
> This whole interface is structured aroun
On Thu, Feb 26, 2009 at 1:58 AM, Guzman Lugo, Fernando wrote:
>
> Hi,
>
> This patch removes unncessary checks in HW_MBOX_IsFull this patch is
> base on the previous patch that Felipe Contreras sent.
>
> Regards,
> Fernando.
>
> From: Fernando Guzman Lugo
> Date: Wed, 25 Feb 2009 17:48:01
On Wed, Feb 25, 2009 at 08:53:00PM +0900, Kim Kyuwon wrote:
> From: Kim Kyuwon
>
> While waking up, musb can cause a kernel panic. This patch is fixing
> it by enabling the clock in the resume_early method.
>
> Signed-off-by: Kim Kyuwon
> ---
> drivers/usb/musb/musb_core.c | 21 +++--
On Thu, Feb 26, 2009 at 08:54:38AM +0900, Minkyu Kang wrote:
> The MPU module can be waked up by the unexpected USB
> interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
> peripheral mode and connected to a host PC, it can never enter the low
> power mode due to interrupts from the ho
Fernando,
I think you are missing the CHNLSM_InterruptDSP() function changes from Felipe
patch; ie. To wait less.
Thank you,
Best regards,
Hari
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando
Hi,
This patch removes unncessary checks in HW_MBOX_IsFull this patch is
base on the previous patch that Felipe Contreras sent.
Regards,
Fernando.
From: Fernando Guzman Lugo
Date: Wed, 25 Feb 2009 17:48:01 -0600
Subject: [PATCH] DSPBRIDGE: Remove unnecessary checks in HW_MBOX_IsFull
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board specific file can de
On Wednesday 25 February 2009, Mark Brown wrote:
> > get_voltage() {
> > read selector from hardware
> > map selector to voltage
> > return that voltage
> > }
>
> > So it's trivial for similar code to take the selector as
> > a function paramet
On Wed, Feb 25, 2009 at 02:12:26PM -0800, David Brownell wrote:
> On Wednesday 25 February 2009, Mark Brown wrote:
> > This whole interface is structured around the idea that the consequences
> > of getting this wrong include things like lasting hardware damage. This
> > hardware damage may not b
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
> Sent: Wednesday, February 25, 2009 4:03 PM
> To: linux-omap@vger.kernel.org
> Cc: Syed Mohammed, Khasim
> Subject: [PATCH 2/2] OMAP34
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
> Sent: Wednesday, February 25, 2009 4:03 PM
> To: linux-omap@vger.kernel.org
> Cc: Syed Mohammed, Khasim
> Subject: [PATCH 1/2] OMAP34
On Wednesday 25 February 2009, Mark Brown wrote:
> On Tue, Feb 24, 2009 at 04:17:22PM -0800, David Brownell wrote:
>
> > Fixable in an update. I still think it's better to require less
> > manual configuration, not more ... manual configuration is by
> > definition error prone; requiring more man
>From bd4df7db454add3f679456a1e7f4c814f297cc71 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Wed, 25 Feb 2009 15:55:56 -0600
Subject: [PATCH 2/2] OMAP3430SDP: Get rid of checkpatch.pl warnings with
includes
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-3430sdp.c |3 +--
>From bd4df7db454add3f679456a1e7f4c814f297cc71 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Wed, 25 Feb 2009 16:01:04 -0600
Subject: [PATCH 0/2] OMAP3430SDP: Fix checkpatch.pl warnings
This 2 small patches fixes 3 warnings seen when running
checkpatch.pl script on latest 3430sdp boardfile.
>From 9ec9fef55a7fbfc9f813a521bed6158db1aad46f Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Wed, 25 Feb 2009 15:26:35 -0600
Subject: [PATCH 1/2] OMAP3430SDP: Remove unneded extern line
This patch removes a duplicate extern on board-3430sdp.c
file, as it is present already on
arch/arm/plat
On Thu, Jan 22, 2009 at 03:46:28PM -0600, david.hag...@gmail.com wrote:
> I've spend the day tracking down a weird behavior on a Beagleboard with
> 2.6.29-rc2-omap1.
>
> If you select the mode for the musb to operate in OnTheGo mode
> (CONFIG_USB_MUSB_OTG), and if you compile the gadget drivers as
On Thu, Feb 19, 2009 at 10:30:30PM +0200, Felipe Balbi wrote:
> On Thu, Feb 19, 2009 at 12:08:45PM -0800, David Brownell wrote:
> > On Thursday 19 February 2009, Felipe Balbi wrote:
> > > Take it out of drivers/i2c/chips as requested by Jean Delvare
> > > that all drivers move out of there.
> > >
On Wed, Feb 25, 2009 at 03:25:59PM -0500, George G. Davis wrote:
> Is someone working on updating ASoC drivers for OMAP TWL4030 based
> boards as recommended above? Just curious since I already made the
> mistake of creating my own OMAP3 EVM ASoC driver w/o checking the
> list first. : /
Not to
Hi,
On Tue, Nov 25, 2008 at 02:52:58PM +, Mark Brown wrote:
> On Tue, Nov 25, 2008 at 01:21:20PM +0200, Jarkko Nikula wrote:
>
> > Or if those EVM's & SDP's can route TWL4030 audio connections more
> > flexible than Beagle but somewhat similar manner, then probably have one
> > single machine
Thanks Soren!
I would have never figured this out, if you hadn't explained
it!! :-)
Best regards,
Elvis
On Feb 25, 2009, at 10:46 PM, Søren Steen Christensen wrote:
Hi,
Can someone tell me why gpmc_a11 to gpmc_a26 signals are
missing from
initial pages for the CBB package speci
> Hi,
> Can someone tell me why gpmc_a11 to gpmc_a26 signals are
> missing from
> initial pages for the CBB package specification, in the OMAP3515/03
> Applications Processor document (Rev. C)?
>
> If you go down to page 91 of the same document, it lists gpmc_a11 to
> gpmc_a26.
>
> Are the
Hi,
Can someone tell me why gpmc_a11 to gpmc_a26 signals are missing from
initial pages for the CBB package specification, in the OMAP3515/03
Applications Processor document (Rev. C)?
If you go down to page 91 of the same document, it lists gpmc_a11 to
gpmc_a26.
Are the address lines mu
>From d3aeedc4677ebe6fdfb7f9f68b72ad5dc96463f0 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo
Date: Wed, 25 Feb 2009 10:19:12 -0600
Subject: [PATCH] DSPBRIDGE: Remove variables not used in cfgdefs.h
This patch removes some variable that are not used.
Signed-off-by: Guzman Lugo Fernando
---
On Feb 23, 2009, at 4:08 PM, David Brownell wrote:
On Monday 23 February 2009, David Brownell wrote:
Perhaps something broke with Tony's RC1 merge?
The LEDs are broken for me as well.
Still works for me. Did you maybe not enable the twl4030
GPIO support in Kconfig?
Oh, and if you did *n
On Tue, Feb 24, 2009 at 04:17:22PM -0800, David Brownell wrote:
> On Tuesday 24 February 2009, Mark Brown wrote:
> > > + /* maybe force machine-wide voltage constraints to match the
> > > + * voltages supported by this regulator. use the regulator's
> > > + * entire range for boards with no par
>> Actually, this happens and is happening!
I got OT. I just needed to vent!
Sorry for the spam.
For the sensor mounting, I think the cam knows how the sensor is mounted
and therefor the driver knows (driver -> first abstraction layer between
software and hardware). Therefor the drive has to
with while (i++ < MAX_CLOCK_ENABLE_WAIT); i can reach MAX_CLOCK_ENABLE_WAIT + 1
after the loop, so if (i == MAX_CLOCK_ENABLE_WAIT) that's still success.
Signed-off-by: Roel Kluin
---
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/mach-omap2/powerdomain.c |2 +-
2 files changed, 2 inse
On Wed, Feb 25, 2009 at 12:55:41PM +0100, ext Kim Kyuwon wrote:
> +int twl4030_usb_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> + struct twl4030_usb *twl = platform_get_drvdata(pdev);
> +
> + if (!twl->suspend_enabled)
> + return 0;
> +
> + twl->o
From: Minkyu Kang
The MPU module can be waked up by the unexpected USB
interrupt(HSUSB_MC_NINT). For instance, if the MUSB is working as
peripheral mode and connected to a host PC, it can never enter the low
power mode due to interrupts from the host PC. This patch added the
feature that a board
From: Kim Kyuwon
While waking up, musb can cause a kernel panic. This patch is fixing
it by enabling the clock in the resume_early method.
Signed-off-by: Kim Kyuwon
---
drivers/usb/musb/musb_core.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/dr
Hi,
These fixes are the replacement of [ARM: OMAP: Disable USB interrupt
in the musb_resume() function] and trying to following David
Brownell's recommendation.
Thanks, especially David.
--
Kyuwon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message
> >> Looks fine to me, but I wonder if you know why the regulator is
> >> turned on (DEV_GRP) and then the voltage is selected (DEDICATED).
> >
> > History, I'd guess. I seem to remember some sequencing
> > constraint, but couldn't find it when last I sought it
> > out in the reference manual.
>
David Brownell wrote:
On Tuesday 24 February 2009, Adrian Hunter wrote:
David Brownell wrote:
From: David Brownell
Resolve longstanding issue noted by Adrian Hunter: confusion
between settting VSEL=0 (which is 1.8V on MMC1) and poweroff.
Also, leave VSEL alone if we're just powering the reg
Hello Russell,
On Sat, 14 Feb 2009, Russell King - ARM Linux wrote:
> On Sat, Feb 14, 2009 at 11:23:25AM +, Russell King - ARM Linux wrote:
> > There's also a second issue - the comments before omap2_divisor_to_clksel()
> > indicate that this function returns 0x on error. Unfortunate
46 matches
Mail list logo
