Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

* Tony Lindgren [091218 19:44]: > Hi all, > > Here are some v7 fixes, mostly to make kexec work. > > Using 2.6.33-rc1, these fixes, and kexec from kexec-tools > git repo, I can reboot my n900 in a loop reliably. > > To clarify, this works booting 2.6.33-rc1 in a loop, booting > the Maemo kernel

[PATCH 5/5] arm: Fix typo in cacheflush.h and remove unnecessary comments

While dealing with the kexec fixes, I noticed these. Signed-off-by: Tony Lindgren --- arch/arm/include/asm/cacheflush.h |2 +- arch/arm/mm/proc-v6.S |2 -- arch/arm/mm/proc-v7.S |2 -- 3 files changed, 1 insertions(+), 5 deletions(-) diff --git a/arch/arm/inc

[PATCH 4/5] arm: Fix init_atags_procfs() to check tag->hdr.size

The tag->hdr.size cannot be larger than XXX. Otherwise we can getsomething similar during boot: Unable to handle kernel paging request at virtual address 61a05020 ... Signed-off-by: Tony Lindgren --- arch/arm/include/asm/setup.h | 12 +--- arch/arm/kernel/atags.c|2 +- a

[PATCH 3/5] arm: Flush TLB entries in setup_mm_for_reboot()

We need to do that if we tinker with the MMU entries. This fixes the occasional bug with kexec where the new fails to uncompress with "crc error". Most likely at least kexec on v6 and v7 need this fix. Signed-off-by: Tony Lindgren --- arch/arm/mm/mmu.c |3 +++ 1 files changed, 3 insertions(

[PATCH 2/5] arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work

The comments in arm_machine_restart() suggest that cpu_proc_fin() will clean and disable cache and turn off interrupts. This does not seem to be implemented for proc-v7.S, implement it the same way as for proc-v6.S. This also makes kexec work for v7. Note that a related TLB and branch traget flush

[PATCH 1/5] arm: Fix DCC console for v7

Without this patch arch/arm/compressed/head.S defaults to generic DCC code that does not work for v7. For more information on the v7 DCC, see Cortex-A8 TRM "12.11.1 Debug communications channel". To use it with post 2.6.33-rc1 or later, you need to have: CONFIG_DEBUG_LL=y ONFIG_DEBUG_ICEDCC=y CO

[PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

Hi all, Here are some v7 fixes, mostly to make kexec work. Using 2.6.33-rc1, these fixes, and kexec from kexec-tools git repo, I can reboot my n900 in a loop reliably. To clarify, this works booting 2.6.33-rc1 in a loop, booting the Maemo kernel with kexec does not seem to boot very far at all f

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

Nishanth Menon writes: > SmartReflex implements a get_opp to search through the opp table, > replace it with the accessor function as it is a duplicate of > freq_to_opp SmartReflex is not quite working with this version which is in pm-wip-opp. My (untested) theory below... [...] > --- a/arch/

[PATCH v2 3/4] OMAP SR/SRF: use OPP API for OPP ID, remove direct access

SR and SRF currenly direclty access OPP struct internals. Use new accessor function to get OPP ID. Also SRF was doing doing direct access of the OPP struct array using a convoluted conversion from a 'level' to an OPP ID, when they're actually the same thing. Signed-off-by: Kevin Hilman --- arc

[PATCH v2 4/4] OMAP OPP: hide struct omap_opp internals in OPP layer implementation

Now that we have accessor/helper functions for all the OPP layer details, move 'struct omap_opp' into the OPP layer so no direct accesses to OPP internals can be done. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/include/plat/opp.h | 19 +-- arch/arm/plat-omap/opp.c

[PATCH v2 2/4] OMAP SRF: adjust OPP array access

With the initial terminators removed from the OPP struct arrarys, the direct indexing of the array needs to be adjusted by one. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/resource34xx.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/resou

[PATCH v2 1/4] OMAP OPP: Add accessor function for getting OPP ID.

Add new function opp_get_opp_id() for finding the OPP ID of a given OPP. This allows us to further hide OPP layer details. NOTE: OPP IDs are deprecated, and this function will eventually be removed after all users of OPP IDs are removed. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap

[PATCH v2 0/4] OPP layer: hide OPP implementation details

This series continues on top of Paul's OPP cleanup series and aims to completly hide the OPP layer implementation details. To do this, a couple more another accessor functions have been added so current SR/SRF code can still function. The goal here is to allow continued OPP layer cleanup and p

RE: [PATCHv2 18/18] DSPBRIDGE: Compilation fixes 2.6.31

Hi, >-Original Message- >From: Felipe Contreras [mailto:felipe.contre...@gmail.com] >Sent: Friday, December 18, 2009 11:49 AM >To: Ramirez Luna, Omar >Cc: linux-omap; Hiroshi Doyu; Ameya Palande; Felipe Contreras; Guzman Lugo, >Fernando; Ramos Falcon, >Ernesto >Subject: Re: [PATCHv2 18/18

Re: OMAP4 clock code needs some modifying now that clockdomains are present

Hi Abhijit, On Fri, 18 Dec 2009, Paul Walmsley wrote: > going through the clock code, I noticed that it still has several > > #ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */ Just noticed this also in clock44xx_data.c: /* TODO

Sergey Nikitin si Vás přidal do přátel na s tránce VK.com

linux omap(at)vger.kernel.org, Sergey Nikitin si Vás přidal do přátel na stránce VK.com Pomocí své e-mailové adresy a automaticky vytvořeného hesla: PJ2uDN34, můžete zajít na stránku a prohlédnout si profily Vašich přátel. VK.com je stránka, která každý den umožňuje desítkám milionů lidí najít

Re: "Flush the D-cache during copy_user_highpage" breaks compile for v7 on -rc1

On Fri, 18 Dec 2009, Russell King - ARM Linux wrote: > On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: > > Hi Catalin, > > > > You may have already run into this, but if not, looks like commit > > 115b22474eb1905da2f606a057da345583d3 breaks compile for v7: > > > > arch/arm/mm/

[PATCH] omap: zoom3: enable ehci support

Zoom3 board has omap3630 EHCI port2 connected to a ULPI phy. GPIO_64 is connected to the PHY reset pin. Signed-off-by: Vikram Pandita Cc: Gadiyar, Anand --- arch/arm/mach-omap2/board-zoom3.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-o

RE: Anyone using an ISP1505?

>-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bill >Gatliff >Sent: Friday, December 18, 2009 1:11 PM >To: Gadiyar, Anand >Cc: linux-omap@vger.kernel.org; beaglebo...@googlegroups.com >Subject: Re: Anyone using an ISP150

Re: Anyone using an ISP1505?

Felipe Balbi wrote: > > is this with musb ? if it's musb, you need the nop transceiver. Do you > have any boot logs which you could share ? Without information on the > board, is a bit difficult :-( Of course. Here is an excerpt from my dmesg output: Linux version 2.6.33-rc1-06888-g7fa9fb6-dir

Re: Anyone using an ISP1505?

Gadiyar, Anand wrote: >> I'm working on an OMAP3530CUS board that uses an ISP1505 USB PHY, and I >> haven't gotten much luck getting the kernel to recognize any USB >> devices. No luck, actually. :) My oscilloscope and the schematic say >> that the hardware is wired up properly, I'm just wonderi

Re: [PATCH 10/12] OMAP OPP: remove "initial terminators" from OPP lists

Paul Walmsley writes: > Now that the SRF and Smartreflex code uses accessor functions to interact > with OPPs, the "initial terminators" can be removed. Nice. With the initial terminators gone, some assumptions in SRF have to be changed too where SRF is directly indexing into the OPP table. I'

[RESEND][PATCH 1/2] DSPBRIDGE: return right error codes services directory

Fixed typo in description. >From c69aeb206fe38e2ca8a5d3f019672963f262b180 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Thu, 17 Dec 2009 11:53:30 -0600 Subject: [PATCH] DSPBRIDGE: return right error codes services directory This patch fixes the bad error codes returned by some func

Re: [PATCH 1/2] DSPBRIDGE: return right error codes services directory

On Fri, Dec 18, 2009 at 8:15 PM, Guzman Lugo, Fernando wrote: > From c69aeb206fe38e2ca8a5d3f019672963f262b180 Mon Sep 17 00:00:00 2001 > From: Fernando Guzman Lugo > Date: Thu, 17 Dec 2009 11:53:30 -0600 > Subject: [PATCH] DSPBRIDGE: return right error codes services directory > > This patch fixe

OMAP4 clock code needs some modifying now that clockdomains are present

Hi Abhijit, going through the clock code, I noticed that it still has several #ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */ Could you please put together a patch to remove these, test it on 4430ES1 SDP, and send it to the list? I'd suggest basing the patches on

[PATCH 2/2] DSPBRIDGE: remove unused things in clk.c and mem.c

>From 70a2d5a2c8e59679f90e7e4fce084a7ea02ce0da Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Thu, 17 Dec 2009 11:57:11 -0600 Subject: [PATCH] DSPBRIDGE: remove unused things in clk.c and mem.c This patch removes unused define from mem.c and unused struct in clk.c. Signed-off-by: Fern

[PATCH 1/2] DSPBRIDGE: return right error codes services directory

>From c69aeb206fe38e2ca8a5d3f019672963f262b180 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Thu, 17 Dec 2009 11:53:30 -0600 Subject: [PATCH] DSPBRIDGE: return right error codes services directory This patch fixes the bad error codes returned by some functions, also it is taking cafe

Re: [PATCHv2 18/18] DSPBRIDGE: Compilation fixes 2.6.31

On Thu, Dec 17, 2009 at 4:16 AM, Omar Ramirez Luna wrote: > Compilation fixes 2.6.31 > >        board-sdp3430.h not found >        clk_handle undefined because of DVFS flag In fact, these are not specific to 2.6.31. The changes are good to have even on 2.6.28; they would get rid of warnings on ce

[PATCH 4/4] OMAP OPP: hide struct omap_opp internals in OPP layer implementation

Now that we have accessor/helper functions for all the OPP layer details, move 'struct omap_opp' into the OPP layer so no direct accesses to OPP internals can be done. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/include/plat/opp.h | 19 +-- arch/arm/plat-omap/opp.c

[PATCH 3/4] OMAP SR/SRF: use OPP API for OPP ID, find by index

SR and SRF currenly direclty access OPP struct internals. Use new accessor functions so OPP layer details can be further hidden. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/resource34xx.c | 14 +++--- arch/arm/mach-omap2/smartreflex.c |4 ++-- 2 files changed, 13 insertio

[PATCH 1/4] OMAP OPP: Add accessor function for getting OPP ID.

Add new function opp_get_opp_id() for finding the OPP ID of a given OPP. This allows us to further hide OPP layer details. NOTE: OPP IDs are deprecated, and this function will eventually be removed after all users of OPP IDs are removed. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap

[PATCH 2/4] OMAP OPP: add helper function to find OPP by index

Current SRF code indexes directly into OPP array, add opp_find_by_index() to do equivalent so OPP layer details can be further hidden. NOTE: This is temporary patch until SRF removal can be completed. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/include/plat/opp.h |3 +++ arch/arm/pla

[PATCH 0/4] OPP layer: hide OPP implementation details

This series continues on top of Paul's OPP cleanup series and aims to completly hide the OPP layer implementation details. To do this, a couple more temporary (a.k.a already deprecated) helper functions have been added so current SR/SRF code can still function. The goal here is to allow continu

[PATCH 2/2] dsp-bridge: remove unused includes

Signed-off-by: Felipe Contreras --- drivers/dsp/bridge/rmgr/drv_interface.c |3 --- drivers/dsp/bridge/rmgr/proc.c |1 - drivers/dsp/bridge/wmd/tiomap3430_pwr.c |1 - 3 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/dri

[PATCH 1/2] dsp-bridge: improve PM conditional code

Signed-off-by: Felipe Contreras --- arch/arm/mach-omap2/dspbridge.c |2 ++ drivers/dsp/bridge/rmgr/drv_interface.c |5 - drivers/dsp/bridge/wmd/tiomap3430_pwr.c |2 +- 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm

[PATCH 0/2] dsp-bridge: PM cleanups

From: Felipe Contreras These patches apply on top of a commit in Omar's wip dspbridge-baseline: cd0c004e5c6bc9da58d03931766115ec1e8bcaaf They are supposed to replace "Compilation fixes 2.6.31". Felipe Contreras (2): dsp-bridge: improve PM conditional code dsp-bridge: remove unused includes

Re: [PATCH 01/12] OMAP OPP: remove some unnecessary variables

Paul Walmsley writes: > No need to allocate new variables; the passed-in OPP list pointers do nicely > as iterators. Thanks Paul for this series. I totally agree with the cleanups you've done. I've rebased this on top of my current pm-wip-opp branch and will include it in the next push of that

RE: [PATCH 2/3] ASoC: OMAP4: Add support for McPDM

Felipe Balbi wrote: > Hi, > > On Fri, Dec 18, 2009 at 03:23:14AM +0100, ext Candelaria > Villareal, Jorge wrote: > >Is this because if two interrupts were set, my approach would > >not recognize it as one of the cases and exit without processing > >the interrupt? > > you don't have a break in yo

Re: [PATCH] Fix double-linking of drivers/usb/otg when ULPI is selected

On Fri, 2009-12-18 at 09:57 -0600, Bill Gatliff wrote: > This patch corrects a problem where drivers/usb/otg is linked twice > if CONFIG_USB_ULPI is selected, resulting in a build error (symbol > conflict). The files in that directory are properly linked already > as part of CONFIG_USB, and need no

Re: [PATCH 00/10 V5] omap3: pm: introduce support for 3630 OPPs

Romit Dasgupta writes: [...] > To facilitate the ongoing discussions on OPP rework, and to have a > common base, this series is available as a branch in my linux-omap-pm > repo[1]. > > >> >> Yes, I'm in the process cleaning that up. >> >> Once I get some of th

[PATCH] Fix double-linking of drivers/usb/otg when ULPI is selected

This patch corrects a problem where drivers/usb/otg is linked twice if CONFIG_USB_ULPI is selected, resulting in a build error (symbol conflict). The files in that directory are properly linked already as part of CONFIG_USB, and need not be indicated specifically for CONFIG_USB_ULPI. Signed-off-by

[PATCH] OMAP: remove duplicated #include

Remove duplicated #include('s) in drivers/video/omap/lcd_omap3beagle.c Signed-off-by: Huang Weiyi --- drivers/video/omap/lcd_omap3beagle.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap/lcd_omap3beagle.c b/drivers/video/omap/lcd_omap3beagle.c index

Re: "Flush the D-cache during copy_user_highpage" breaks compile for v7 on -rc1

On Fri, Dec 18, 2009 at 09:35:12AM -0600, Olof Johansson wrote: > Hi, > > On Fri, Dec 18, 2009 at 08:18:52AM +, Russell King - ARM Linux wrote: > > On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: > > > Hi Catalin, > > > > > > You may have already run into this, but if not, look

Re: "Flush the D-cache during copy_user_highpage" breaks compile for v7 on -rc1

Hi, On Fri, Dec 18, 2009 at 08:18:52AM +, Russell King - ARM Linux wrote: > On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: > > Hi Catalin, > > > > You may have already run into this, but if not, looks like commit > > 115b22474eb1905da2f606a057da345583d3 breaks compile for

No device for DAI omap-eac-dai error

Hi, I'm writing new omap dai (for EAC codec base omap's). My code is based on existing omap-mcbsp.c code basically. After loadingof module I got error which appear in init function when call snd_soc_register_dai(). I browse for code but can't figure out where dai->dev should be set to don't get

Re: [PATCH 2/2] omap i2c: add a timeout to the busy waiting

Hi, Sonasath, Moiz wrote: From: Menon, Nishanth Alexander Shishkin said the following on 12/17/2009 07:01 PM: Well, I could calculate the timeout value based on current operating speed, I guess. Or a delay. Perhaps OMAP_I2C_TIMEOUT can be used here? it might be an overkill trying to generat

Re: Strange boot messages on mainline + omap3_defconfig

Gadiyar, Anand wrote: > I get some "mux: Unknown ball ..." messages booting > v2.6.33-rc1 from Linux' tree (built with the omap3_defconfig). > > This was on a 3630 SDP. > > Won't be looking at this for a while, so just reporting it. > > - Anand > > 0x588 > [0.00] mux: Unknown ball offse

Re: Strange boot messages on mainline + omap3_defconfig

> This was on a 3630 SDP. > > Won't be looking at this for a while, so just reporting it. > > - Anand > > 0x588 > [0.00] mux: Unknown ball offset 0x58a > [0.00] mux: Unknown ball offset 0x0 > [0.00] mux: Unknown ball offset 0x2 CONFIG_OMAP_PACKAGE_CBP is undefined for you

Strange boot messages on mainline + omap3_defconfig

I get some "mux: Unknown ball ..." messages booting v2.6.33-rc1 from Linux' tree (built with the omap3_defconfig). This was on a 3630 SDP. Won't be looking at this for a while, so just reporting it. - Anand 0x588 [0.00] mux: Unknown ball offset 0x58a [0.00] mux: Unknown ball off

RE: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype

> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Tuesday, December 15, 2009 12:38 PM > To: Cousson, Benoit > Cc: Sripathy, Vishwanath; Nayak, Rajendra; ext-ari.kau...@nokia.com; linux- > o...@vger.kernel.org; Woodruff, Richard; Menon, Nishanth > Subject: RE: [PAT

Re: [PATCH 3/4 v4] musb: Add context save and restore support

On Tue, Dec 15, 2009 at 02:31:48PM +0100, ext Ajay Kumar Gupta wrote: Adding support for MUSB register save and restore during system suspend and resume. Changes: - Added musb_save/restore_context() functions - Added platform specific musb_platform_save/restore_context() t

Re: [alsa-devel] [PATCH 2/3] ASoC: OMAP4: Add support for McPDM

On Fri, Dec 18, 2009 at 11:51:30AM +0100, ext Mark Brown wrote: On Thu, Dec 17, 2009 at 10:28:21PM +0200, Felipe Balbi wrote: On Thu, Dec 17, 2009 at 08:40:32PM +0100, ext Candelaria Villareal, Jorge wrote: >+config SND_OMAP_SOC_MCPDM >+ tristate look at how SND_OMAP_SOC_N810 is done

Re: [PATCHv2 1/1] OMAP3: PM: Fix OTG autoidle workaround

Hi, On Fri, Dec 18, 2009 at 11:39:23AM +0100, Valentin Eduardo (Nokia-D/Helsinki) wrote: From: Eduardo Valentin This patch fix the OTG autoidle workaround so now usb gadget modules can be properly loaded. Besides it also adds a cpu check, because this hardware but is present only in OMAP34xx

Re: [alsa-devel] [PATCH 2/3] ASoC: OMAP4: Add support for McPDM

On Fri, Dec 18, 2009 at 11:33:38AM +0200, Felipe Balbi wrote: > On Fri, Dec 18, 2009 at 03:23:14AM +0100, ext Candelaria Villareal, Jorge > wrote: > >So, it would be better if I had declared a platform_device structure > >in .../arch/arm/plat-omap/devices.c, and register its resources (irq > >and

Re: [alsa-devel] [PATCH 2/3] ASoC: OMAP4: Add support for McPDM

On Thu, Dec 17, 2009 at 10:28:21PM +0200, Felipe Balbi wrote: > On Thu, Dec 17, 2009 at 08:40:32PM +0100, ext Candelaria Villareal, Jorge > wrote: > >+config SND_OMAP_SOC_MCPDM > >+ tristate > look at how SND_OMAP_SOC_N810 is done, can't you follow that ? put some > description ad help ?

[PATCHv2 1/1] OMAP3: PM: Fix OTG autoidle workaround

From: Eduardo Valentin This patch fix the OTG autoidle workaround so now usb gadget modules can be properly loaded. Besides it also adds a cpu check, because this hardware but is present only in OMAP34xx chips. Signed-off-by: Eduardo Valentin --- arch/arm/mach-omap2/pm34xx.c |3 ++- arc

Re: [PATCH] AM35xx: Add clock support for new modules on AM35xx

Hello Paul, Thanks for the review comments. My replies below. On Fri, 18-Dec-09 7:12 AM +0530, Paul Walmsley wrote: >> +/* Clocks for AM35XX */ >> +static struct clk emac_ick = { >> +.name = "emac_ick", >> +.ops= &clkops_omap2_dflt, > > Shouldn't this clock use &clkops_omap

Re: [PATCH 00/10 V5] omap3: pm: introduce support for 3630 OPPs

>>> [...] >>> >>> To facilitate the ongoing discussions on OPP rework, and to have a common base, this series is available as a branch in my linux-omap-pm repo[1]. > > Yes, I'm in the process cleaning that up. > > Once I get some of that cleanup done, I plan to rebase your

RE: [PATCH 1/1] OMAP3: PM: Fix OTG autoidle workaround

> From: Eduardo Valentin > > This patch fix the OTG autoidle workaround so now > usb gadget modules can be properly loaded. > > Besides it also adds a cpu check, because this hardware > but is present only in OMAP34xx chips. > > Signed-off-by: Eduardo Valentin > --- > arch/arm/mach-omap2/pm34

Re: [PATCH 2/3] ASoC: OMAP4: Add support for McPDM

Hi, On Fri, Dec 18, 2009 at 03:23:14AM +0100, ext Candelaria Villareal, Jorge wrote: Is this because if two interrupts were set, my approach would not recognize it as one of the cases and exit without processing the interrupt? you don't have a break in your switch. your approach would go throu

[PATCH 1/1] OMAP3: PM: Fix OTG autoidle workaround

From: Eduardo Valentin This patch fix the OTG autoidle workaround so now usb gadget modules can be properly loaded. Besides it also adds a cpu check, because this hardware but is present only in OMAP34xx chips. Signed-off-by: Eduardo Valentin --- arch/arm/mach-omap2/pm34xx.c |3 ++- arc

Re: "Flush the D-cache during copy_user_highpage" breaks compile for v7 on -rc1

On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: > Hi Catalin, > > You may have already run into this, but if not, looks like commit > 115b22474eb1905da2f606a057da345583d3 breaks compile for v7: > > arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing': > ar

Re: [PATCH 5/5] OMAP3: PM: Disable OTG autoidle when waking up from off-mode

Hello All, On Thu, Nov 12, 2009 at 04:40:56PM +0100, ext Gadiyar, Anand wrote: > > Tero Kristo writes: > > > > > From: Tero Kristo > > > > > > OMAP3 sleep can be prevented in some cases where OTG autoidle is enabled. > > > This patch force disables autoidle during wakeup from off-mode. See omap