Shubhrajyoti D writes:
> From: Felipe Balbi
>
> this helps us reduce unnecessary pm transitions
> in case we have another i2c message starting soon.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Shubhrajyoti D
I tracked the PM regression down to this patch.
> ---
> drivers/i2c/busses/i2c
Wolfram Sang writes:
> On Wed, Sep 12, 2012 at 04:27:54PM +0530, Shubhrajyoti D wrote:
[...]
>> This is the cleanup only series.
>>
>> Tested on omap4sdp and 3430sdp.
>>
>> The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
>>
>> Linux 3.6-rc5 (2012-09-08 16:43:
Shubhrajyoti D writes:
[...]
>
> This is the cleanup only series.
>
> Tested on omap4sdp and 3430sdp.
It would be extremely helpful if you would describe how this was tested.
And for me, it would be a source of extreme joy if you described any PM
testing.
I gave this some additional PM test
power
> states]
> Reviewed-by: Santosh Shilimkar
Acked-by: Kevin Hilman
Paul, go ahead and queue this one with the others.
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
)
Updates for omap_device layer for v3.7.
Allows omap_device layer to keep track of driver bound status in order
to make more intelligent decisions about idling unused devices.
Kevin Hilman (3):
ARM
"Shilimkar, Santosh" writes:
> On Wed, Sep 12, 2012 at 6:02 AM, Paul Walmsley wrote:
>>
>> Remove some unnecessary plat/ includes that are interfering with
>> multi-subarch
>> ARM kernels.
>>
>> Signed-off-by: Paul Walmsley
>> Cc: Kev
fbc5e
> gpio/omap: remove suspend_wakeup field from struct gpio_bank
>
> and makes some minor changes so that we have separate flags for "GPIO
> should wake from deep idle" and "GPIO should wake from suspend".
>
> With this patch, the GPIO from my touch s
"Shilimkar, Santosh" writes:
> On Sat, Sep 8, 2012 at 3:07 AM, Kevin Hilman
> wrote:
>> Hi Neil,
>>
>> NeilBrown writes:
>>
>>> On Thu, 6 Sep 2012 11:18:09 +0530 "Shilimkar, Santosh"
>>> wrote:
>>>
>>>> O
Roger Quadros writes:
> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>
> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
> [ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/1763
> [ 28.841491] caller is pwrdm_set_next_pwrst+0
Tony Lindgren writes:
> * Kevin Hilman [120907 15:07]:
>> Wei Yongjun writes:
>>
>> > From: Wei Yongjun
>> >
>> > pdata and pdata->regs have been allocated in this function and
>> > should be freed before leaving it, and in the other
inelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun
Acked-by: Kevin Hilman
Tony, can you pick this one up for fixes?
Thanks,
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
Venkatraman S writes:
> omap hsmmc controller IP has a built in timer that can be programmed to
> guard against unresponsive operations. But its range is very narrow,
> and the maximum countable time is a few seconds.
>
> Card maintenance operations like BKOPS and MMC_ERASE and long
> stream writ
Roger Quadros writes:
> Hi Jean,
>
> My bad, I didn't follow up with this. My guess is that it has not been
> picked up. Tony, Kevin?
>
Wasn't picked up by me (but should've been, sorry.) Care to refresh
against v3.6-rc4 and resend?
Thanks,
Kevin
>
> On 09/06/2012 09:59 PM, Jean Pihet wrote
Tero Kristo writes:
> On Mon, 2012-08-06 at 12:14 +0200, Jean Pihet wrote:
>> Hi Tero,
>>
>> On Mon, Jul 30, 2012 at 10:40 AM, Tero Kristo wrote:
>> > On Fri, 2012-07-27 at 12:36 -0700, Kevin Hilman wrote:
>> >> Tero Kristo writes:
>> >
78225021413022c164cb99fbc5e
> gpio/omap: remove suspend_wakeup field from struct gpio_bank
>
> and makes some minor changes so that we have separate flags for "GPIO
> should wake from deep idle" and "GPIO should wake from suspend".
>
> With this patch, the GPIO
"AnilKumar, Chimata" writes:
> Hi Kevin,
>
> On Fri, Sep 07, 2012 at 05:07:56, Kevin Hilman wrote:
>> AnilKumar Ch writes:
>>
>> > Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
>> > APIs control clocks for C_CAN/D_CAN IP and p
Felipe Balbi writes:
> Hi,
>
> On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote:
>> Felipe Balbi writes:
>>
>> > Hi guys,
>> >
>> > here's v4 of the omap uart patchset. No changes other than a rebase on top
>> > of
&g
AnilKumar Ch writes:
> Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
> APIs control clocks for C_CAN/D_CAN IP and prevent access to the
> register of C_CAN/D_CAN IP when clock is turned off.
>
> Signed-off-by: AnilKumar Ch
I'm not familar with the CAN specifics here, but some
Felipe Balbi writes:
> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be igno
Felipe Balbi writes:
> nobody needs to access the uart_omap_port structure
> other than omap-serial.c file. Let's move that
> structure definition to the C source file in order
> to prevent anyone from accessing our structure.
>
> Tested-by: Shubhrajyoti D
> Acked-by: Tony Lindgren
> Signed-off
NeilBrown writes:
> On Fri, 10 Aug 2012 11:49:27 -0700 Kevin Hilman wrote:
>
>> Hello,
>>
>> In doing some automated testing of suspend/resume I noticed that
>> repeated attempts to suspend and resume via RTC wakeup fail on
>> 3530/Beagle and 3730/Beagle-
Hello,
In doing some automated testing of suspend/resume I noticed that
repeated attempts to suspend and resume via RTC wakeup fail on
3530/Beagle and 3730/Beagle-xM, but work fine on 3430/n900, 3530/Overo,
3730/OveroSTORM and 4430/Panda.
When RTC wakeup fails, a UART wakeup will work, and in the
Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 14 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/omap_device.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 150112e..0693260 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/omap_device.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 1d1b5ff..150112e 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/p
, the omap_device layer implements PM domains for all
omap_devices, and knowing whether or not a driver is bound is needed
to know whether or not a drivers callbacks are valid, especially in
cases of failed driver probe.
Kevin Hilman (3):
ARM: OMAP: omap_device: keep track of driver bound status
ARM: OMAP4: Register the OPP table only for 4430 device (2012-08-09 08:07:54
-0700)
Kevin Hilman (2):
ARM: OMAP3: TWL4030: ensure sys_nirq1 is mux'd and wakeup enabled
Revert "ARM: OMAP3: PM: call pre/post
"Rafael J. Wysocki" writes:
> On Thursday, August 09, 2012, Kevin Hilman wrote:
>> "Rafael J. Wysocki" writes:
>>
>> > On Thursday, August 09, 2012, Rajendra Nayak wrote:
>> >> On OMAP4, if the first CPU fails to get a valid frequency
Rajendra Nayak writes:
> Hi Kevin,
>
> On Wednesday 08 August 2012 10:48 PM, Kevin Hilman wrote:
>>> The 4430 OPP table was being registered for all other OMAP4 variants
>>> > too, like 4460 and 4470 causing issues with cpufreq driver
>>> > enabled. 44
"Rafael J. Wysocki" writes:
> On Thursday, August 09, 2012, Rajendra Nayak wrote:
>> On OMAP4, if the first CPU fails to get a valid frequency table (this
>> could happen if the platform does not register any OPP table), the
>> subsequent CPU instances end up dealing with a NULL freq_table and
>>
"DebBarma, Tarun Kanti" writes:
> On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote:
>> Tarun Kanti DebBarma writes:
>>
>>> Add *remove* callback so that necessary cleanup operations are
>>> performed when device is unregistered. The device is del
"Shilimkar, Santosh" writes:
> On Wed, Aug 8, 2012 at 4:24 PM, Rajendra Nayak wrote:
>>
>> On OMAP4, if the first CPU fails to get a valid frequency table (this
>> could happen if the platform does not register any OPP table), the
>> subsequent CPU instances end up dealing with a NULL freq_table
Rajendra Nayak writes:
> The 4430 OPP table was being registered for all other OMAP4 variants
> too, like 4460 and 4470 causing issues with cpufreq driver
> enabled. 4460 and 4470 devices have different OPPs as compared to
> 4430, and they should be populated seperately. As long as that
> happens
erwise it will lead to corrupted stack frame.
>
> Fix it by saving used registers.
>
> Reported-by: Grygorii Strashko
> Signed-off-by: Santosh Shilimkar
> Cc: Kevin Hilman
Please add a brief comment in the code as well explaining why the
additional registers are saved/restored.
After
; irq_free_desc() api.
>
> Signed-off-by: Tarun Kanti DebBarma
> Reported-by: Paul Walmsley
> Reviewed-by: Jon Hunter
> Cc: Kevin Hilman
> Cc: Rajendra Nayak
> Cc: Santosh Shilimkar
> Cc: Cousson, Benoit
> Cc: Paul Walmsley
> ---
> v2:
> Baseline: git://git
Grazvydas Ignotas writes:
> On Wed, Aug 8, 2012 at 1:47 AM, Kevin Hilman wrote:
>> This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89.
>>
>> Converstion to per-pwrdm per/post transition calls was a bit
>> premature. Only tracking MPU, PER & CORE in the
Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..05bd8f0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch
Kevin Hilman writes:
> This reverts commit 58f0829b7186150318c79515f0e0850c5e7a9c89.
>
> Converstion to per-pwrdm per/post transition calls was a bit
> premature. Only tracking MPU, PER & CORE in the idle path means we
> lose the accounting for all the other powerdom
Paul Walmsley writes:
> Hi Kevin
>
> a couple of minor comments
>
> On Tue, 10 Jul 2012, Kevin Hilman wrote:
>
>> Use the bus notifier to keep track of driver bound status by adding a
>> new internal field to struct omap_device: _driver_staus.
>
> "_dr
Hi Paul,
Paul Walmsley writes:
> NFS is broken on 37xx EVM with v3.6-rc1 after return from off-mode with
> dynamic idle. System suspend ("echo mem > /sys/power/state") with
> off-mode enabled seems to work fine.
>
> No obvious ideas here as to what could have broken this. It worked in
> v3.
Paul Walmsley writes:
> Hi Kevin,
>
> On Mon, 6 Aug 2012, Kevin Hilman wrote:
>
>> Is this only happening on this 37xx platform?Just curious, because
>> it seems to be a problem on any OMAP3xxx SoC.
>
> So far I've only run the baseline tests on 37xx,
l in the idle path.
Cc: Jean Pihet
Cc: Tero Kristo
Cc: Rajendra Nayak
Reported-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/
s not fail use pm_runtime_put_sync() when disabling the timer.
>
> Note that this will not be seen on OMAP1 devices, because these devices do
> not use the clock framework for dmtimers.
>
> Signed-off-by: Jon Hunter
Acked-by: Kevin Hilman
> ---
> arch/arm/plat-omap/dmtim
Hi Wolfram,
Kevin Hilman writes:
> In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
> failure.
>
> Without this, after a failed xfer, the runtime PM usecount will have
> been incremented, but not decremented causing the usecount to never
> reach zero after a fa
Kevin Hilman writes:
> Tero Kristo writes:
>
>> mpu / core powerdomain usecounts are now statically increased
>> by 1 during MPU activity. This allows the domains to reflect
>> actual usage, and will allow the usecount to reach 0 just before
>> all CPUs are rea
for usecount
> tracking on powerdomain level and autoidle flag for clocks that
> are hardware controlled and should be skipped in usecount
> calculations.
>
> Signed-off-by: Tero Kristo
> Cc: Paul Walmsley
> Cc: Kevin Hilman
[...]
> /* Clock control for DPLL outputs *
Hi Paul,
Paul Walmsley writes:
> On v3.6-rc1 on 37xx EVM, DSS and USBHOST powerdomains aren't entering
> low-power states. Test log is below.
Is this only happening on this 37xx platform?Just curious, because
it seems to be a problem on any OMAP3xxx SoC.
[...]
> # echo mem > /sys/power/
t your thoughts.
After all the digging I did, I agree that the revert is the best
solution.
While it's a slightly different problem/bug, I think the gpio_free() in
common-board-devices.c should still be unconditonal since the
gpio_request() is now unconditional. That can be a separate patch t
Hi Joe,
"Joe Woodward" writes:
> I have a GUMSTIX Overo AirSTORM (AM3703-based).
>
> When running a 3.4 kernel the USB host works just fine!
>
> However when switching to 3.5 I get a few new warning messages and USB host
> no longer works.
As usual, thanks for the bug/problem reports.
EHCI is
Tero Kristo writes:
> PM code doesn't really care about the PRCM wakeup + io interrupts on
> OMAP3, as these are used only for acking PRCM internal events, and the
> IO chain handler is taken care of by hwmod code. Thus move the interrupt
> handling logic from pm34xx.c to prm2xxx_3xxx.c file. Thi
Tero, Paul,
Tero Kristo writes:
> Hi,
>
> Following set moves some PRM related code away from PM core code to
> PRM / HWMOD. This requires the hwmod cleanup set from Paul that
> implements the setup_preprogram hooks for hwmods. Sending as RFC for
> initial commenting.
What is the status of the
"Poddar, Sourav" writes:
> On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti
> wrote:
>> Sourav,
>>
>> On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav wrote:
>>> Hi All,
>>>
>>> I tried using gpio as an interrupt line for my driver
>>> (drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
Olof Johansson writes:
> On Thu, Jul 26, 2012 at 11:44 PM, Colin Cross wrote:
>> On Thu, Jul 26, 2012 at 11:34 PM, Shilimkar, Santosh
>> wrote:
>>> On Fri, Jul 27, 2012 at 2:19 AM, Olof Johansson wrote:
>>>> Kevin,
>>>>
>>>> On Thu,
Igor Grinberg writes:
> On 07/27/12 20:46, Kevin Hilman wrote:
>> Igor Grinberg writes:
>>
>>> On 07/26/12 22:30, Kevin Hilman wrote:
>>>> + Zumeng Chen
>>>>
>>>> Igor Grinberg writes:
>>>>
>>>>> Hi
Rajendra Nayak writes:
> On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote:
>> On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote:
>>> On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something
owerdomains.
>
> This patch also provices a way to do printk dumps from kernel code,
> by calling the pm_dbg_dump_X functions. The plan is to call these
> functions once an error condition is detected, e.g. failed suspend.
>
> Signed-off-by: Tero Kristo
> Cc: Paul Walmsley
&g
; propageted to voltagedomain level also, and will allow vc
> callbacks to be triggered at right point of time.
>
> Signed-off-by: Tero Kristo
> Cc: Paul Walmsley
> Cc: Kevin Hilman
IMO, the idea is fine, but I'm not crazy about the implementation in
powerdomain.c, which is
for usecount
> tracking on powerdomain level and autoidle flag for clocks that
> are hardware controlled and should be skipped in usecount
> calculations.
>
> Signed-off-by: Tero Kristo
> Cc: Paul Walmsley
> Cc: Kevin Hilman
Minor nit: please avoid using BUG_ON() which wil
Igor Grinberg writes:
> On 07/26/12 22:30, Kevin Hilman wrote:
>> + Zumeng Chen
>>
>> Igor Grinberg writes:
>>
>>> Hi Kevin,
>>>
>>> I've just noticed that the patch has been modified by Arnd in a way
>>> that of course wil
Igor Grinberg writes:
> On 07/26/12 22:30, Kevin Hilman wrote:
>> + Zumeng Chen
>>
>> Igor Grinberg writes:
>>
>>> Hi Kevin,
>>>
>>> I've just noticed that the patch has been modified by Arnd in a way
>>> that of course wil
"Nayak, Rajendra" writes:
> Paul,
>
> On Fri, Jul 27, 2012 at 2:34 AM, Paul Walmsley wrote:
>>
>> Commit 4da71ae6 ("OMAP: clockdomain: Arch specific funcs for
>> clkdm_clk_enable/disable") called the OMAP2xxx-specific functions for
>> clockdomain wakeup and sleep. This would probably have broke
"zumeng.chen" writes:
> On 2012年07月27日 03:30, Kevin Hilman wrote:
>> + Zumeng Chen
>>
>> Igor Grinberg writes:
>>
>>> Hi Kevin,
>>>
>>> I've just noticed that the patch has been modified by Arnd in a way
>>> that of
h changes up to b93d70aeb8f3b5ed2d74643f5009239a55634e1d:
ARM: OMAP4: CPUidle: Open broadcast clock-event device. (2012-07-25 16:06:08
-0700)
--------
Kevin Hilman (1):
ARM: OMAP4: CPUidle: add synchronization for coupled idle states
Santosh Shilimkar
ly don't have a board setup with a touchscreen in my
board farm.
Kevin
>From 85516c6a3354967caf4cff434d28c3001cd411eb Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Thu, 26 Jul 2012 12:15:38 -0700
Subject: [PATCH 2/2] ARM: OMAP2+: ads7846: fix ->get_pendown_state() to work
Rajendra Nayak writes:
> On Thursday 26 July 2012 04:13 AM, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>>> On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
>>>> On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
>>>>> On Fr
is statically controlled through cpu online / offline.
> Once per-cpu cpuidle is in, these should be changed so that each
> individual cpu increases the usecounts when they are brought up,
> decrease/increase during idle, and decrease when they are brought down.
> The usecount should alway
Linus Walleij writes:
> On Mon, Jul 16, 2012 at 7:10 PM, Kevin Hilman wrote:
>
>> Subject: [PATCH] MAINTAINERS: add entry OMAP GPIO driver
>>
>> Since I've been maintaining this, making it official at the request of the
>> GPIO maintainers.
>>
>>
Tony Lindgren writes:
> * Kevin Hilman [120711 14:34]:
>> Omar Ramirez Luna writes:
>>
>> > On 11 July 2012 12:07, Kevin Hilman wrote:
>> > ...
>> >>> [2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>> >>>
Javier Martinez Canillas writes:
> commit 13f30fc893e4610f67dd7a8b0b67aec02eac1775
> Author: Russell King
> Date: Sat Apr 21 22:41:10 2012 +0100
>
> mmc: omap: remove private DMA API implementation
>
> removed the private DMA API implementation from the OMAP mmc host to
> make it use exclu
Linus Walleij writes:
> On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman wrote:
>
>> In the case of OMAP GPIO, unless it's an obvious fix, I would recommend
>> you wait at least until you see some acks/tested tags from any of
>>
>> - Santosh Shilimkar
>&
"Joe Woodward" writes:
> ...snip...
>> > Hmm, interesting, I don't see this on my 3730-based Over FireSTORM.
>> >
>> > But, after "converting" mine into an AirStorm[1], I see the same
>> errors
>> > as you're seeing. We're obviously doing something wrong when IVA
>> and/or
>> > SGX are not prese
es, and PM regressions. Fix the double
> registration and add some clockdomain code to prevent this from happening
> again.
>
> Reported-by: Joe Woodward
> Cc: Tony Lindgren
> Cc: Kevin Hilman
> Signed-off-by: Paul Walmsley
Acked-by: Kevin Hilman
This fixes the problem
Hi Linus,
Linus Walleij writes:
> On Thu, Jul 12, 2012 at 1:25 AM, Kevin Hilman wrote:
>
>> There is quite a bit of other things to do in remove to properly cleanup
>> what is done in probe.
>
> OK I'm dropping this patch for now...
>
Thanks.
For future
y are GPIO IRQs.
Also, what about runtime PM?
In short, this seems very premature and I suspect untested.
Kevin
> Signed-off-by: Tarun Kanti DebBarma
> Reported-by: Paul Walmsley
> Reviewed-by: Jon Hunter
> Cc: Kevin Hilman
> Cc: Rajendra Nayak
> Cc: Santosh Shilimk
() --> _set_gpio_triggering() which can fault if the
bank has been runtime suspended.
This is exctly what happens on Overo platforms (3530 Water, 3730 Overo
FireSTORM) since this is the only GPIO used in the bank.
To fix, don't free the GPIO at all since it is always in use.
Cc: Igor Grinberg
Signed-off-b
the first
attempt to use the GPIO will fault.
For example, on my Overo board(s), I noticed this failing as soon as teh
ads7846 driver probes, requests the IRQ and the GPIO triggering is set.
Getting rid of this free fixes the problem.
The changelog doesn't describe why the GPIO is freed here s
Omar Ramirez Luna writes:
> On 12 June 2012 07:01, Rajendra Nayak wrote:
[...]
>> ..anyone knows of any more fixes going around?
>
> I'm seeing the same thing, it gets stuck trying to enable CPU1, tried
> this with pm-20120710 from linux-omap-pm and current LO master (based
> on 3.5-rc6), also
Omar Ramirez Luna writes:
> On 11 July 2012 12:07, Kevin Hilman wrote:
> ...
>>> [2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>>> [2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine
>>> channel 62
>>> [2.
Hi Tony,
In your current master branch, commit 3dd50d054 (Merge tag
'omap-cleanup-for-v3.6' into tmp-merge) added back the mpu_3xxx_clkdm
into the common clockdomains that was removed by commit 16e5e2c47 (ARM:
OMAP AM35x: clockdomain data: Fix clockdomain dependencies)
This causes duplicate regis
+Paul
Kevin Hilman writes:
> "Joe Woodward" writes:
>
>> -Original Message-
>> From: Kevin Hilman
>> To: "Joe Woodward"
>> Cc: "linux-omap\@vger.kernel.org"
>> Date: Tue, 10 Jul 2012 16:58:18 -0700
>> Su
"Mark A. Greer" writes:
> On Wed, Jul 11, 2012 at 10:07:06AM -0700, Kevin Hilman wrote:
>> "Joe Woodward" writes:
>>
>> > -Original Message-
>> > From: Kevin Hilman
>> > To: "Joe Woodward"
>> > Cc: "
"Joe Woodward" writes:
> -Original Message-
> From: Kevin Hilman
> To: "Joe Woodward"
> Cc: "linux-omap\@vger.kernel.org"
> Date: Tue, 10 Jul 2012 16:58:18 -0700
> Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with
"Munegowda, Keshava" writes:
> On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz wrote:
>> Hi Keshava, Kevin,
>>
>> On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote:
>>> Samuel
>>> I have sent that patch to disable the ehci in
>>> omap2plus_defconfig; after merging that
>
"Joe Woodward" writes:
> I've got 3.5-rc5 with the following patches applied to get system suspend
> working on OMAP3:
> - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
> - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data: fix 32K
> sync timer
>
> This has been buil
value, the driver core assumes probe was successful
and will bind the driver to the device.
Fix this by ensuring that probe returns an error code in this failure
path.
Signed-off-by: Kevin Hilman
---
drivers/mmc/host/omap_hsmmc.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/omap_device.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 150112e..28ab6af 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/omap_device.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 1d1b5ff..150112e 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/p
Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 14 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap
"S, Venkatraman" writes:
> On Tue, Jul 10, 2012 at 7:47 PM, Kevin Hilman wrote:
>> "S, Venkatraman" writes:
>>
>>> On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman wrote:
>>>> Due to the way the driver core takes runtime PM references durin
gine
> channel %u\n", tx_req);
> + goto err_irq;
> }
If either of these fails, ret is zero so even though this results in a
failed probe, the return value (ret) is zero meaning the driver still
gets bound to the device.
The patch below fixes this and applies on
"S, Venkatraman" writes:
> On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman wrote:
>> Due to the way the driver core takes runtime PM references during
>> probe, a driver's runtime PM callbacks may not be called until probe
>> returns. During probe, drvdata
Santosh Shilimkar writes:
> From: R Sricharan
>
> OMAP socs has a legacy and a highlander version of the
> 32k sync counter IP. The register offsets vary between the
> highlander and the legacy scheme. So use the 'SCHEME'
> bits(30-31) of the revision register to distinguish between
> the two ve
Peter Ujfalusi writes:
> On 07/06/2012 04:33 PM, Shilimkar, Santosh wrote:
>>> Since this is TWL6030 specific, it should rather be done in TWL code
>>> like I did for sys_nirq1:
>>>
>>>http://marc.info/?l=linux-omap&m=134090312118873&w=2
>>>
>>> That would avoid having to do this in both boar
Zumeng Chen writes:
> The offset of WKUP_MOD is not right for the PRM_RSTST of OMAP3. So here
> put the right one to match to the actual physical addr 0x48307258, which
> defined in PRCM Registers section.
>
> And there is a MPU_WD_RST bit in PRM_RSTST(0x48307258) holding the signal
> from omap-w
Tony Lindgren writes:
> * Kevin Hilman [120706 11:25]:
>> The EHCI driver is not stable enough to be enabled by default. In v3.5,
>> it has at least the following problems:
>>
>> - warning dump during bootup
>> - hang during suspend
>> - prevents C
Hi Grant,
Here's a couple (hopefully) final OMAP GPIO fixes for v3.5-rc.
Thanks,
Kevin
The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc:
Linux 3.5-rc4 (2012-06-24 12:53:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel
driver has not been thoroughly tested and
therfore should not be enabled in the default defconfig.
In addition, the problems above cause new PM regressions which need be
addressed before this driver should be enabled in the default
defconfig.
Signed-off-by: Kevin Hilman
---
Tony, this applies to
Kevin Hilman writes:
> Keshava Munegowda writes:
>
>> The usb host is disabled in the omap2 build; This is because
>> usb host is causing the retention to break in cpu idle.
>
> ... and causes warnings during boot, and hangs in suspend, can't suspend
> using NFSr
to the IRQ flags.
Tested on OMAP3730/OveroSTORM and OMAP4430/Panda board using rtcwake
to wake from system suspend multiple times.
Signed-off-by: Kevin Hilman
---
Resending to broader audience and including Andrew. Since, I understand
that drivers/rtc is somewhat orphaned, Andrew, can you qu
Peter Ujfalusi writes:
> The sys_nirq2 is used for twl6040, make sure the pin is configured
> correctly.
>
> Signed-off-by: Peter Ujfalusi
> Acked-by: Santosh Shilimkar
> ---
> arch/arm/mach-omap2/board-4430sdp.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/a
601 - 700 of 5500 matches
Mail list logo
