Kevin Hilman writes:
> Aaro Koskinen writes:
>
>> Hi,
>>
>> On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
>>> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
>>> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc
From: Kevin Hilman
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above
p: Invalid parameters" messages appear on boot;
>> related warnings follow
>> - Cause unknown
>
> This one seems to be caused by this commit:
>
> commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64
> Author: Kevin Hilman
> Date: Thu Sep 6 14:03:08 2012 -0
Aaro Koskinen writes:
> Hi,
>
> On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
>> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
>> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c
>> > omap_i2c.1: timeout waiting for bus ready). After several reboo
+Colin Cross, Barry Song also
Felipe Balbi writes:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driver is written
Peter Zijlstra writes:
> On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
>
>> So I did the same thing for my ARM SoC, and it definitley stops the RT
>> throttling.
>>
>> However, it has the undesriable (IMO) side effect of making timed printk
>> o
Peter Zijlstra writes:
> On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
>> > So the primary question remains: is RT runtime supposed to include the
>> > time spent suspended? I suspect not.
>>
>> you might be right there, though we need Thomas or Peter to answer :-s
>
> re, sorry both
Peter Zijlstra writes:
> On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
>> > So the primary question remains: is RT runtime supposed to include the
>> > time spent suspended? I suspect not.
>>
>> you might be right there, though we need Thomas or Peter to answer :-s
>
> re, sorry both
From: Kevin Hilman
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a "no idle" option
during omap_device init in order to allow earlyprintk usa
Felipe Balbi writes:
[...]
> ps: I'll continue reading the code and further test my series to see
> if I can understand what you say here.
OK. And please get it working in cases where drivers are using I2C in
their suspend/resume (and even late/early) paths, and also where device
runtime PM is
Felipe Balbi writes:
[...]
> if the device implements none of the suspend methods, then you
> shouldn't suspend it at all, because you'd be masking a bug in the
> driver, IMHO.
OK, let's start over here, because here's the fundamental difference. I
don't think missing suspend methods means a b
Felipe Balbi writes:
> Hi,
>
> On Thu, Oct 18, 2012 at 10:42:37AM -0700, Kevin Hilman wrote:
>> Felipe Balbi writes:
>>
>> > Hi,
>> >
>> > On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
>> >> Felipe Balbi writes:
&
Felipe Balbi writes:
> Hi,
>
> On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
>> Felipe Balbi writes:
>>
>> > current implementation doesn't take care about
>> > drivers which don't provide *_noirq methods
>>
>> T
Felipe Balbi writes:
> OMAP I2C driver will re-enable IRQs right after
> masking them during suspend.
>
> That's not what we want. We want to keep IRQs
> masked until our resume method is called.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/i2c/busses/i2c-omap.c | 10 ++
> 1 file cha
Felipe Balbi writes:
> current omap_device PM implementation defines
> omap-specific *_noirq methods but uses the
> generic versions for all other PM methods.
>
> As it turns out, if a device decides to implement
> non-runtime PM callbacks, we might fall into a
> situation where the hwmod is stil
Felipe Balbi writes:
> device drivers should be smart enough to provide
> ->suspend/->resume callbacks when needed and they
> should take care of doing whatever needs to be
> done in order to allow a device to be suspended.
>
> Calling pm_runtime_* from system suspend isn't
> the right way to ach
Felipe Balbi writes:
> current implementation doesn't take care about
> drivers which don't provide *_noirq methods
The generic ops handle this. See below.
> and we could fall into a situation where we would suspend/resume
> devices even though they haven't asked for it.
The following explan
Felipe Balbi writes:
> On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
>>
>> On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
>> > + peterz, tglx
>> >
>> > Felipe Balbi writes:
>> >
>> > [...]
>>
Tony Lindgren writes:
> * Felipe Balbi [121016 03:32]:
>> Hi,
>>
>> On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
>> > From: Kevin Hilman
>> >
>> > The runtime PM framework assumes that the hardware state of devices
>> >
Paul Walmsley writes:
> Hi Kevin,
>
> Here's an updated version of this one, with the erratum coverage expanded
> to include OMAP34xx/35xx.
>
> I think this one can replace Tero's "[PATCHv6 06/11] ARM: OMAP:
> clockdomain: add support for preventing autodep delete" and "[PATCHv6
> 07/11] ARM:
s have not been enabled yet, a flood of interrupts hangs
> the device.
>
> Fixed the issue by setting the SIH irqs with IRQF_EARLY_RESUME
> flags, so they get enabled before the PIH.
>
> Signed-off-by: Kalle Jokiniemi
Acked-by: Kevin Hilman
Thanks, I like this better than th
() returning early on subsequent
resends because the replay flag is still set.
Problem discovered on ARM/OMAP platforms where a nested IRQ that's
also a wakeup IRQ happens late in suspend and needed to be retriggered
during the resume process.
Reported-by: Kevin Hilman
Tested-by: Kevin Hilman
Mike Turquette writes:
> Quoting Tony Lindgren (2012-10-16 09:32:25)
>> * Mike Turquette [121011 15:27]:
>> > Quoting Nishanth Menon (2012-10-11 06:33:04)
>> > > On 18:26-20121003, Mike Turquette wrote:
>> > > > From: Mike Turquette
>> > > [...]
>> > > >
>> > > > arch/arm/mach-omap2/Makefile
From: Kevin Hilman
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a "no idle" option
during omap_device init in order to allow earlyprintk usa
Tony Lindgren writes:
> * Kevin Hilman [121012 13:34]:
>>
>> I'm not conviced (yet) that a mismatch is the root cause. Yes, that's
>> what the author of $SUBJECT patch assumed and stated, but I'm not
>> pursuaded.
>>
>> If it's a
Kalle Jokiniemi writes:
> Hi,
>
> la, 2012-10-13 kello 01:00 +0530, Shubhrajyoti Datta kirjoitti:
>> On Sat, Oct 13, 2012 at 12:10 AM, Kevin Hilman
>> wrote:
>> > From: Kevin Hilman
>> >
>> > Currently, runtime PM is used to keep the device ena
Russell King - ARM Linux writes:
> On Fri, Oct 12, 2012 at 10:59:22AM -0700, Kevin Hilman wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
>> >> Sourav writes:
>> >> > diff
Shubhrajyoti Datta writes:
> On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman
> wrote:
>> "Strashko, Grygorii" writes:
>>
>>> Hi Kevin,
>>>
>>> yep, [1] is the same fix - thanks.
>>
>>> Hi Kalle,
>>>
>>> i
Tony Lindgren writes:
> * Russell King - ARM Linux [121012 08:56]:
>> For those who don't bother looking at my kautobuild boot tests on the OMAP
>> boards I have, here's the errors which get spat out at boot time. Note
>> that some of these I've reported in the past, and one of them is missing
From: Kevin Hilman
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device, driver's ->runtime_suspend() method
currently disables device interrupts w
Russell King - ARM Linux writes:
> On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
>> Sourav writes:
>> > diff --git a/drivers/tty/serial/omap-serial.c
>> > b/drivers/tty/serial/omap-serial.c
>> > index 6ede6fd..3fbc7f7 100644
>> > ---
ret = pm_runtime_resume(dev);
> + if (ret < 0)
> + return ret;
> + return 0;
> +}
> +
> static struct dev_pm_ops omap_i2c_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(omap_i2c_suspend, NULL)
> SET_RUNTIME_PM_OPS(omap_i2c_runtime
Sourav writes:
> Hi Paul,
>
> There are
> On Thursday 11 October 2012 11:58 PM, Paul Walmsley wrote:
>> Hi Sourav, Felipe,
>>
>> any progress on fixing the N800 problem? Would be good to keep it booting
>> since we use it as our primary 2420 test platform.
>>
>>
>> - Paul
> The patch sent inline
"Strashko, Grygorii" writes:
> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
Hi Grygorii, thanks for reviewing. I was hoping you would have some
ideas here as this was sounding familiar to something you had
mentioned elsewhere
"Strashko, Grygorii" writes:
> Hi All,
>
> Sorry, for the late reply.
> + CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
Hi Grygorii, thanks for reviewing. I was hoping you would have some
ideas here as this was sounding familiar to something you had mentioned
elsewhere
> twl4030 power key on N9. Patch tested on N9.
>
> Signed-off-by: Kalle Jokiniemi
This version looks good, thanks for the extra comments.
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Wolfram, This should also probably be Cc'd to stable since it affects
earlier kernels as well.
Hi Sourav,
Sourav writes:
[...]
> Boot Tested this patch series against v3.6 tag(applied cleanly) on
> panda board and
> PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
>
> Note, I also tested the patches against the current master but only
> after rebasing, since the
Tomi Valkeinen writes:
> On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote:
>> Hi Tomi,
>>
>> Tomi Valkeinen writes:
>>
>> > This patch converts vrfb library into a platform device, in an effort to
>> > remove omap dependencies.
>> >
&
Sakari Ailus writes:
> Hi Kevin,
>
> Thanks for the comments!
>
> On Tue, Oct 09, 2012 at 01:50:04PM -0700, Kevin Hilman wrote:
>> Hi Sakari,
>>
>> Sakari Ailus writes:
>>
>> > The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are conn
From: Kevin Hilman
commit 6b8029fab64164b5895d58d23229b75c82e3a6fc (rtc: kconfig: remove
unnecessary dependencies) removed various 'depends on RTC_CLASS'
dependencies but also removed a few 'default RTC_CLASS' statements,
which actually changed default behavior.
This resulte
Hi Sakari,
Sakari Ailus writes:
> The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to
> the actual CSI-2 receivers outside the ISP itself. Allow changing this
> configuration from the ISP driver.
>
> Signed-off-by: Sakari Ailus
These control module registers (CSIRXFE, C
Hi Tomi,
Tomi Valkeinen writes:
> This patch converts vrfb library into a platform device, in an effort to
> remove omap dependencies.
>
> The platform device is registered in arch/arm/plat-omap/fb.c and
> assigned resources depending on whether running on omap2 or omap3.
>
> The vrfb driver wil
Tony,
Please pull the following OMAP PM fixes for v3.7-rc.
Thanks,
Kevin
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linu
e23bbda013fc32d8f6c68982eab603.
--------
Kevin Hilman (4):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused
cpufreq: OMAP: use get_cpu_device() instead of omap_device API
ARM: OMAP2+: PM: MPU DVFS: use generic CPU devic
"Rafael J. Wysocki" writes:
> On Wednesday 03 of October 2012 16:00:25 Kevin Hilman wrote:
>> From: Kevin Hilman
>>
>> Here's a series with a couple bug fixes and a couple fixes that
>> make this driver support newer OMAP-based SoCs.
>>
>>
+Grygorii (who's been working on various I2C related suspend/resume
issues also)
Hi Kalle,
Kalle Jokiniemi writes:
> The resume_noirq enables interrupts one-by-one starting from
> first one. Now if the wake up event for suspend came from i2c
> device, the i2c bus irq gets enabled bef
Tobias Klauser writes:
> A pointer to "pdev->dev" is already stored in "dev", so use it in
> devm_kzalloc.
>
> Signed-off-by: Tobias Klauser
Acked-by: Kevin Hilman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the b
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> Remove the device dependent code (ex. cpu_is_xxx()) and settings
> from the driver code and instead pass them via the platform
> data. This allows a clean separation of the driver code and the platform
> code, as required by the move of the
Thomas Petazzoni writes:
> On Thu, 4 Oct 2012 22:30:58 +0200, Enric Balletbò i Serra wrote:
>
>> I recently tested kernel 3.6-rc5 and worked for me. Let me check tomorrow
>> kernel 3.6. Which u-boot version are you using?
>
> 2011.12 + a few patches to make the NAND of the IGEPv2 rev6 work. Let
>
Thomas Petazzoni writes:
> Kevin,
>
> On Thu, 04 Oct 2012 10:18:04 -0700, Kevin Hilman wrote:
>
>> Can you dump the UART mux registers on a working kernel and compare
>> them to the broken one? (Table 7-4 in the 34xx public TRM[1] will
>> list all the mux register
Hi Thomas,
Thomas Petazzoni writes:
> Kevin,
>
> Reviving an old thread.
>
> On Fri, 04 May 2012 16:46:32 -0700, Kevin Hilman wrote:
>
>> >> Thomas Petazzoni writes:
>> >>
>> >> > I have an IGEPv2 revision 6 board, which uses the DM373
Tony Lindgren writes:
> * jean.pi...@newoldbits.com [121003 08:48]:
>> @@ -1036,8 +1036,8 @@ static struct omap_clk am33xx_clks[] = {
>> CLK("davinci-mcasp.1", NULL, &mcasp1_fck,CK_AM33XX),
>> CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
>> CL
.
Signed-off-by: Paul Walmsley
Cc: Rafael J. Wysocki
[t...@atomide.com: updated already changed clock aliases]
Signed-off-by: Tony Lindgren
[khil...@ti.com: minor shortlog/changelog updates]
Signed-off-by: Kevin Hilman
---
drivers/cpufreq/omap-cpufreq.c | 19 +--
1 file
From: Kevin Hilman
Ensure the clock rate that will be used is a valid one before
attempting to scale the voltage. Currently the driver assumes it has
a valid frequency from the OPP table, but boards using different
system oscillators might not have exact matches with the OPP table,
and result
From: Kevin Hilman
The headers are going away, and this one is not used. remove it.
Signed-off-by: Kevin Hilman
---
drivers/cpufreq/omap-cpufreq.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 0fe395a..7d4d455
From: Kevin Hilman
OMAP PM core code has moved to using the existing, generic CPU devices
for attaching OPPs, so the CPUfreq driver can now use the generic
get_cpu_device() API instead of the OMAP-specific omap_device API.
This allows us to remove the last include from this driver.
Cc: Paul
From: Kevin Hilman
Here's a series with a couple bug fixes and a couple fixes that
make this driver support newer OMAP-based SoCs.
The 'get_cpu_device' patch is needed due to a change in the OMAP
OMAP PM core code which enforces use of get_cpu_device() instead of
a deprecated OM
From: Kevin Hilman
Currently, a dummy omap_device is created for the MPU sub-system so
that a device node exists for MPU DVFS. Specifically, for the
association of MPU OPPs to a device node, and so that a voltage
regulator can be mapped to a device node.
For drivers to get a handle to this
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> Remove the device dependent code (ex. cpu_is_xxx()) and settings
> from the driver code and instead pass them via the platform
> data. This allows a clean separation of the driver code and the platform
> code, as required by the move of the
"Shilimkar, Santosh" writes:
> On Wed, Oct 3, 2012 at 5:05 AM, Kevin Hilman
> wrote:
>> Hi Santosh, Tero,
>>
>> I just added my 4460/PandaES to my board farm for automated PM testing
>> and see that basic suspend/resume tests don't work in mainline
"Poddar, Sourav" writes:
> Hi,
>
> On Tue, Sep 25, 2012 at 2:51 PM, Russell King - ARM Linux
> wrote:
>> On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
>>> On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
>>> > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Fel
Hi Jean,
Jean Pihet writes:
> Remove the device dependent settings (cpu_is_xxx(), IP fck etc.)
> from the driver code and pass them instead via the platform
> data.
> This allows a clean separation of the driver code and the platform
> code, as required by the move of the platform header files t
On 10/02/2012 02:49 PM, Kevin Hilman wrote:
Jean Pihet writes:
Rename the smartreflex fck names for consistency and better readability;
rename the clock aliases for use by the SmartReflex driver, with the
"smartreflex.%d" format.
hmm, do we even need the clkdev nodes anymore?
Jean Pihet writes:
> Fix the error handling path in omap_sr_probe to correctly
> de-allocate resources in case of problems.
>
> Signed-off-by: Jean Pihet
Thanks, queuing this one as a fix for v3.7-rc
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> Select POWER_SUPPLY from POWER_AVS_OMAP entry in Kconfig.
>
> This avoids the following build problems using a randconfig
> that has CONFIG_POWER_SUPPLY not set:
>
> LD init/built-in.o
> arch/arm/mach-omap2/built-in.o: In function `s
Jean Pihet writes:
> Rename the smartreflex fck names for consistency and better readability;
> rename the clock aliases for use by the SmartReflex driver, with the
> "smartreflex.%d" format.
hmm, do we even need the clkdev nodes anymore? The driver isn't
directly accessing the fclk at all, so
Jean Pihet writes:
> On Thu, Sep 27, 2012 at 7:54 AM, Wei Yongjun wrote:
>> From: Wei Yongjun
>>
>> In case of error, the function voltdm_lookup() returns NULL
>> not ERR_PTR(). The IS_ERR() test in the return value check
>> should be replaced with NULL test.
>>
>> dpatch engine is used to auto
Jean Pihet writes:
> Hello,
>
> On Thu, Sep 27, 2012 at 7:54 AM, Wei Yongjun wrote:
>> From: Wei Yongjun
>>
>> In case of error, the function voltdm_lookup() returns NULL
>> not ERR_PTR(). The IS_ERR() test in the return value check
>> should be replaced with NULL test.
>>
>> dpatch engine is u
Wei Yongjun writes:
> From: Wei Yongjun
>
> In case of error, the function omap_device_alloc() returns ERR_PTR()
> and never returns NULL pointer. The NULL test in the return value
> check should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
> (https://github
Wei Yongjun writes:
> From: Wei Yongjun
>
> In case of error, the function omap_device_get_by_hwmod_name()
> returns ERR_PTR() not NULL pointer. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
> (https://github.c
"Maximilian Schwerin" writes:
> Hi,
>
> I've just built a linux-omap kernel at 3.6-rc6 using omap2plus_defconfig
> as basis for the kernel config.
>
> When I enable smartreflex and switch to 800MHz via
>
> echo 1 > /sys/kernel/debug/smartreflex/smartreflex_core/autocomp
> echo 1 > /sys/kernel/deb
this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun
Acked-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/ar
this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun
Acked-by: Kevin Hilman
> ---
> arch/arm/plat-omap/omap_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-omap/omap_device.c
> b/arch/arm/plat-om
the next power state of the MPU subsystem.
>
> The I2C device latency timing is derived from the FIFO size and the
> clock speed and so is applicable to all OMAP SoCs.
>
> Signed-off-by: Jean Pihet
Acked-by: Kevin Hilman
--
To unsubscribe from this list: send the line "unsub
R Sricharan writes:
> From: Colin Cross
>
> read_persistent_clock uses a global variable, use a spinlock to
> ensure non-atomic updates to the variable don't overlap and cause
> time to move backwards.
>
> Signed-off-by: Colin Cross
> Signed-off-by: R Sricharan
From: Kevin Hilman
There are several drivers where the return value of
pm_runtime_get_sync() is used to decide whether or not it is safe to
access hardware and that don't provide .suspend() callbacks for system
suspend (but may use late/noirq callbacks.) If such a driver happens
to
Not sure if it's related to the cleanup series, but I've also been
seeing a bunch of 'callbacks suppressed messages lately. Is anyone else
seeing this?
Here's an example from a debian nfsfroot boot:
[ 20.044006] tty_init_dev: 59 callbacks suppressed
[ 25.063934] tty_init_dev: 57 callbacks su
>
> Signed-off-by: Shubhrajyoti D
> ---
> - Tested on omap4sdp.
> - pm tested hitting off in idle and suspend.
> - v2 changes update the changelogs.
> - Also remove the dummy check as FE , PE , BI and OE are the only
> receiver errors.
Tested-by: Kevin Hilman
This one also makes
Alan Stern writes:
> On Fri, 21 Sep 2012, Rafael J. Wysocki wrote:
>
>> > Kevin makes a good case that pm_runtime_resume() and related functions
>> > should succeed even when runtime PM is disabled, if the device is
>> > already in the desired state.
>> >
>> > The same may be true for pm_runti
me.
>
> Signed-off-by: Shubhrajyoti D
> ---
> - functional testing on omap4sdp
> - Verified idle and suspend path hits off on beagle.
Tested-by: Kevin Hilman
This fixes the console hang I was seeing on 3530/Overo.
Thanks,
Kevin
> drivers/tty/serial/omap-serial.c |7 +++
Kevin Hilman writes:
> Hi Felipe,
>
> I just noticed today that one of my boards (3530/Overo) was not making
> it to the console when using an Debian rootfs (nfsroot) but works fine
> with my basic busybox initramfs. Basically, it hangs somewhere between
> finishing the
Hi Felipe,
I just noticed today that one of my boards (3530/Overo) was not making
it to the console when using an Debian rootfs (nfsroot) but works fine
with my basic busybox initramfs. Basically, it hangs somewhere between
finishing the userspace init and launching the login shell.
git bisect e
From: Kevin Hilman
When runtime PM is disabled, what we want is for callbacks not to be
called from then on. However, currently, when runtime PM is disabled,
operations such as 'get' will also fail even if the device is
currently active.
Since calling 'get' on a de
ed.
Below is a simple fix.
Kevin
>From cae062932d1d28e499b03d31da815fc2696badfd Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Thu, 20 Sep 2012 09:28:43 -0700
Subject: [PATCH] ARM: OMAP: AM33xx hwmod: fixup SPI after platform_data move
AM33xx hwmod data includes "mcspi.h" w
From: Kevin Hilman
When runtime PM is disabled, what we want is for callbacks not to be
called from then on. However, currently, when runtime PM is disabled,
operations such as 'get' will also fail even if the device is
currently active.
Since calling 'get' on a de
et to CSWR or
>ON;
>
> 2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
>if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
>PER went OFF while CORE stayed on. If loopback tests fail, then
>those devices will be unusable until PER an
"Poddar, Sourav" writes:
> Hi Felipe,
>
> On Tue, Sep 18, 2012 at 5:04 PM, Felipe Balbi wrote:
>> On Tue, Sep 18, 2012 at 05:05:54PM +0530, Sourav Poddar wrote:
>>> Drop the check for "up" being valid on suspend/resume callbacks.
>>> It should be valid always. Get rid of the "pdata" check also a
"Rafael J. Wysocki" writes:
> On Tuesday, September 18, 2012, Axel Lin wrote:
>> omap_device_get_by_hwmod_name() returns ERR_PTR on error.
>>
>> Signed-off-by: Axel Lin
>
> Kevin, should I take this?
Yes, please.
Acked-by: Kevin Hilman
Thanks,
Kev
Shubhrajyoti Datta writes:
> Hi Kevin,
>
> On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman
> wrote:
>> From: Kevin Hilman
>>
>> On some platforms, bootloaders are known to do some interesting RTC
>> programming. Without going into the obscurities as to why th
Marc Kleine-Budde writes:
> On 09/13/2012 04:14 PM, Kevin Hilman wrote:
>> AnilKumar Ch writes:
>>
>>> Move pm_runtime_enable/disable calls to c_can.c driver. Current
>>> implementation is such that platform driver is doing pm_runtime
>>> enable
Felipe Balbi writes:
> Hi,
>
> On Thu, Sep 13, 2012 at 11:04:42AM -0700, Kevin Hilman wrote:
>> Kevin Hilman writes:
>>
>> > Kevin Hilman writes:
>> >
>> [...]
>>
>> >> Sorry to be late to the party (again), but still catchin
Kevin Hilman writes:
> Kevin Hilman writes:
>
[...]
>> Sorry to be late to the party (again), but still catching up after some
>> time off.
>>
>> Unfortunately, this series causes PM regressions on several OMAP
>> platforms. I hope we can hold off on this
Felipe Balbi writes:
[...]
> I just ran same tests on pandaboard and i2c is suspended actually,
> though no power domain transitions to RET. Do we not have retention
> while idle on pandaboard ?
Not for CORE. Only CPUx and MPU domains will be transitioning on OMAP4,
and then, only with CPUidle
AnilKumar Ch writes:
> Move pm_runtime_enable/disable calls to c_can.c driver. Current
> implementation is such that platform driver is doing pm_runtime
> enable/disable and core driver is doing put_sync/get_sync.
>
> PM runtime calls should be invoked if there is a valid device
> pointer from pl
Jean Pihet writes:
> Here is a re-spin after some comments and suggestions after review
> and discussions.
>
> Implement the functional states for the power domains:
> - unify the API to use the functional states. The new API
> consists of the pwrdm_set*_fpwrst and pwrdm_read*_fpwrst
> functi
Jean Pihet writes:
> The PM code uses some counters to keep track of the power domains
> transitions, in order to provide the information to drivers (in
> pwrdm_get_context_loss_count) and to expose the information to
> sysfs for debug purpose.
nit: this is part of debugfs, not sysfs
Otherwise,
Jean Pihet writes:
> The newly added code for functional power states re-defines the
> API to query and control the power domains settings.
>
> The API is now split in the following parts in powerdomain.h:
> - the public or external API, to be used by external PM components:
> cpuidle, suspend,
Jean Pihet writes:
> Trace the power domain transitions using the functional power states,
> which include the power and logic states.
Just to be clear, this means that a trace will only contain functional
power state changes, not logical ones, correct?
> While at it, fix the trace in the case
Paul Walmsley writes:
[...]
>
> It kind of looks to me like there are two or three separate sets within
> the series. My feeling is that Kevin should take the first two, then I
> should take the rest other than 6 and 7. Then once those are queued,
> we can pull in 6 and 7. Does that make s
Kevin Hilman writes:
> 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 follo
501 - 600 of 5500 matches
Mail list logo
