cc linux-pm
Hi
On Sun, 22 Jan 2012, David A. Marlin wrote:
> I experience an unhandled fault on reboot/shutdown using the ARM-OMAP
> kernel-2.6.41.3-1 and later (from Fedora) on a Panda Board. I have logged a
> bug in:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=781552
>
> which provide
On Thu, Jan 19, 2012 at 02:28:28, Grant Likely wrote:
> On Wed, Jan 18, 2012 at 12:43:58PM +0530, Vaibhav Hiremath wrote:
> > Although we consider am33xx device under omap34xx family of devices,
> > there is indeed difference between them, for example,
> >
> > - Initial required mapping (->m
This patch series does the following
Patch 1:
- Prevents the null pointer access
Also fixes the following crash
echo mem > /sys/power/state
[ 263.507019] PM: Syncing filesystems ... done.
[ 263.516876] PM: Preparing system for mem sleep
[ 263.548065] Freezing user space processes ... (elapsed
This patch intends to fix the null pointer access.
Signed-off-by: Shubhrajyoti D
---
drivers/mtd/mtdcore.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 6ae9ca0..2b3bda7 100644
--- a/drivers/mtd/mtdcore.c
+++ b/dr
Currently mtd_suspend returns an error value -EOPNOTSUPP
if the suspend function is not implemented which prevents the
suspend. This patch prevents the nack of suspend if suspend
is not implemented.
Signed-off-by: Shubhrajyoti D
---
include/linux/mtd/mtd.h |6 +++---
1 files changed, 3 inser
On Sat, 2012-01-21 at 00:27 -0700, Paul Walmsley wrote:
> [ This series is targeted for merging during v3.3-rc ]
>
> On v3.3-rc1, the OMAP serial console doesn't behave properly when
> power management is enabled (the default with omap2plus_defconfig).
> This seems to be due to a combination of a
On Sun, 2012-01-22 at 07:46 +1100, NeilBrown wrote:
> On Sat, 21 Jan 2012 17:57:07 +0200 Tomi Valkeinen
> wrote:
> > In this case something is affecting the DSS (clocks? powers?), or the
> > memory, or the process of reading the pixels. I really don't see the MPU
> > or IRQs affecting this proble
On Thu, Jan 19, 2012 at 19:58:21, Hiremath, Vaibhav wrote:
> This patch series cleans up the existing 32k-sync timer implementation
> without any major code change and adds hwmod lookup for omap2+ devices,
> if lookup fails then fall back to gp-timer.
>
> With this, we should be able to support mu
On Wed, Jan 18, 2012 at 12:25:39, Hiremath, Vaibhav wrote:
> Add support for TWL4030, which is interfaced on i2c1 bus.
> Also add clock frequencies for other i2c instances(2 & 3)
> required for client-device exist on OMAP3EVM board.
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Benoit Cousson
> Cc:
On Sat, Jan 21, 2012 at 12:57 PM, Paul Walmsley wrote:
> It seems that when the transmit FIFO threshold is reached on OMAP
> UARTs, it does not result in a PRCM wakeup. This appears to be a
> silicon bug. This means that if the MPU powerdomain is in a low-power
> state, the MPU will not be awake
On Sun, 2012-01-22 at 22:11 +1100, NeilBrown wrote:
> This code disables the auto-idling of some clocks ... not entirely sure of
> the details.
>
> So it seems that it isn't a low power state but rather some clock being
> allowed to turn off which is the problem.
>
> I guess I could selective tr
On Wed, Jan 11, 2012 at 21:48:25, Hiremath, Vaibhav wrote:
> On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
> > Vaibhav Hiremath writes:
> >
> > > AM33XX PRM module (L4_WK domain) will be treated as another seperate
> > > partition in _prm_bases[] table.
> > >
> > > Also, since cpu_is_oma
Hi Vaibhav,
On 1/23/2012 9:49 AM, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 12:25:39, Hiremath, Vaibhav wrote:
Add support for TWL4030, which is interfaced on i2c1 bus.
Also add clock frequencies for other i2c instances(2& 3)
required for client-device exist on OMAP3EVM board.
Signed-o
On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.
Sounds like you've nailed it.
What is perplexing is that the hwmod code should be setting this by
default in oma
On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
>
> > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> > (with SIDLEMODE/IDLEMODE in smart mode) also removes the problem.
>
> Sounds like you've nailed it.
>
> What is per
On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> > On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> >
> > > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
> > > (with SIDLEMODE/IDLEMODE in smart mode) also removes the proble
On Mon, 23 Jan 2012, Govindraj wrote:
> On Sat, Jan 21, 2012 at 12:57 PM, Paul Walmsley wrote:
> > It seems that when the transmit FIFO threshold is reached on OMAP
> > UARTs, it does not result in a PRCM wakeup. This appears to be a
> > silicon bug. This means that if the MPU powerdomain is in
On Mon, Jan 23, 2012 at 2:20 PM, Govindraj wrote:
> On Sat, Jan 21, 2012 at 12:57 PM, Paul Walmsley wrote:
>> It seems that when the transmit FIFO threshold is reached on OMAP
>> UARTs, it does not result in a PRCM wakeup. This appears to be a
>> silicon bug. This means that if the MPU powerdom
On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley wrote:
>
> Hello Govindraj
>
> while trying to track down some of the serial-related PM issues in
> v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
> polling timer when DMA is enabled (uart_dma.rx_timer) (!) This seems
> quite
On Sat, Jan 21, 2012 at 12:57 PM, Paul Walmsley wrote:
> Ensure FIFO levels are set correctly in non-DMA mode (the default).
> This patch will cause a receive FIFO threshold interrupt to be raised when
> there is at least one byte in the RX FIFO. It will also cause a transmit
> FIFO threshold int
On Mon, Jan 23, 2012 at 3:51 PM, Govindraj wrote:
> On Sat, Jan 21, 2012 at 12:57 PM, Paul Walmsley wrote:
>> Ensure FIFO levels are set correctly in non-DMA mode (the default).
>> This patch will cause a receive FIFO threshold interrupt to be raised when
>> there is at least one byte in the RX F
On Mon, 23 Jan 2012, Govindraj wrote:
> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley wrote:
> >
> > while trying to track down some of the serial-related PM issues in
> > v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
> > polling timer when DMA is enabled (uart_dma.rx_ti
On Mon, 2012-01-23 at 02:31 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
>
> > On Mon, 2012-01-23 at 02:04 -0700, Paul Walmsley wrote:
> > > On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> > >
> > > > Then I noticed that the DISPC's ENWAKEUP is not set. Setting ENWAKEUP
>
On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> On Mon, 2012-01-23 at 02:31 -0700, Paul Walmsley wrote:
>
> > Want to spin a quick patch for v3.3-rc1 to add it?
>
> I think there are other bits missing also. CLOCKACTIVITY is missing for
> DISPC. And DSI doesn't have any SYSC flags defined... I'll tr
On Mon, 2012-01-23 at 04:02 -0700, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
>
> > On Mon, 2012-01-23 at 02:31 -0700, Paul Walmsley wrote:
> >
> > > Want to spin a quick patch for v3.3-rc1 to add it?
> >
> > I think there are other bits missing also. CLOCKACTIVITY is missi
This patch series does the following
Patch 1:
Fixes the omap_prcm_get_reset_sources() for omap3/4
Patch 2:
Extends the WDIOC_GETBOOTSTATUS to support omap3/4.
Tested on omap3sdp and omap4sdp.
Rajendra Nayak (1):
ARM: omap: Fix omap_prcm_get_reset_sources() for omap3/4
Shubhrajyoti D (1):
wa
This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl
for the omap3 and omap4.
Signed-off-by: Shubhrajyoti D
---
drivers/watchdog/omap_wdt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 4b33e3f..
From: Rajendra Nayak
Fix omap_prcm_get_reset_sources() for omap3 to look into the
right register, and for omap4 to use the right api (and hence
look into the right register).
With this, get rid of some of the unused and also wrongly
defined macros for OMAP4.
Thanks to Gina Glaser for identifyin
This is an outline of the plan for this cycle, up to the next merge
window, agreed between Olof and myself.
As Nicolas' idle changes weren't merged before the last merge window
opened, we have decided that Nicolas will resubmit his changes after
-rc1 (in other words, now) and they will be merged i
Hi Paul, Tony,
On 12/19/2011 11:51 PM, Paul Walmsley wrote:
> Hi
>
> On Fri, 16 Dec 2011, Cousson, Benoit wrote:
>
>> On 12/16/2011 7:28 AM, Paul Walmsley wrote:
>>> On Mon, 28 Nov 2011, Peter Ujfalusi wrote:
>>>
To be able to get the memory resources by name from
the DMIC driver (for
Signed-off-by: Yegor Yefremov
---
arch/arm/mach-omap2/gpmc.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
Index: b/arch/arm/mach-omap2/gpmc.c
===
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch
Here are two fixes to get DSS work better with PM on OMAP3.
The first two patches fix the missing SYSC_HAS_ENAWAKEUP flag, which removes
the SYNC_LOST problem.
The third patch changes omapdss to use pm_runtime_put_sync functions, which
fixes the system suspend.
I've tested both only on v3.3-rc1,
Currently OMAP2 and 3 share the same omap_hwmod_class and
omap_hwmod_class_sysconfig for dispc. However, OMAP3 has sysconfig
bits that OMAP2 doesn't have, so we need to split those structs into
OMAP2 and OMAP3 specific versions.
This patch only splits the structs, without changing the contents.
S
dispc's sysc_flags is missing SYSC_HAS_ENAWAKEUP flag. This seems to
cause SYNC_LOST errors from the DSS when the power management is
enabled.
This patch adds the missing SYSC_HAS_ENAWAKEUP flag. Note that there are
other flags missing also (clock activity, DSI's sysc flags), but as they
are not c
omapdss doesn't work properly on system suspend. The problem seems to be
the fact that omapdss uses pm_runtime_put() functions when turning off
the hardware, and when system suspend is in process only sync versions
are allowed.
Using non-sync versions normally and sync versions when suspending wou
On 2012-01-22 22:06, Hiremath, Vaibhav wrote:
On Sat, Jan 21, 2012 at 21:46:38, Gary Thomas wrote:
I'm running the public 3.0 kernel on my boards. I have some boards
which can have either OMAP3530 or DM3730 (newer boards have the
newer part, but everything else is the same).
On the OMAP3530, I
On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Govindraj wrote:
>
>> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley wrote:
>> >
>> > while trying to track down some of the serial-related PM issues in
>> > v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 mic
Hi Linus,
On Thu, 2012-01-19 at 15:58 -0800, ext Linus Torvalds wrote:
> So the subject says it all. It's been two weeks(+a day), and 3.3-rc1 is now
> out.
>
> There are a couple of trees I haven't merged on purpose, and there may
> be a few trees I overlooked by mistake. The "on purpose" ones w
Hi Paul
Patchset looks good, feel free to add my ack
On Sun, Jan 22, 2012 at 01:26:23PM -0700, Paul Walmsley (p...@pwsan.com) wrote:
>
> HDQ/1-wire registers are 32 bits long, even if the register contents
> fit into 8 bits, so accesses must be 32-bit aligned. Evidently the
> OMAP2/3 interconne
Hi Rob,
On 1/13/2012 9:41 PM, Rob Clark wrote:
From: Rob Clark
[...]
+static int __init omap_init_gpu(void)
Why is the function to init drm device is named gpu?
+{
+ struct omap_hwmod *oh = NULL;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ o
On Mon, Jan 23, 2012 at 11:24 AM, Cousson, Benoit wrote:
> Hi Rob,
>
> On 1/13/2012 9:41 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>
>
> [...]
>
>> +static int __init omap_init_gpu(void)
>
>
> Why is the function to init drm device is named gpu?
>
drm drivers are typically gpu drivers (although
Hi Evgeniy
On Mon, 23 Jan 2012, Evgeniy Polyakov wrote:
> Hi Paul
>
> Patchset looks good, feel free to add my ack
Thanks, added. If you have a spare moment, could you see if this one is
appropriate for acking too?
http://www.spinics.net/lists/arm-kernel/msg156572.html
regards,
- Paul
--
On Fri, Jan 20, 2012 at 10:26 AM, Russell King - ARM Linux
wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-nomadik/board-nhk8815.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Linus Walleij
Thanks Russell,
Linus Walleij
--
To unsubscribe from this list
On Fri, Jan 20, 2012 at 10:32 AM, Russell King - ARM Linux
wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-nomadik/board-nhk8815.c | 17 -
> arch/arm/mach-nomadik/cpu-8815.c | 9 ++---
> 2 files changed, 6 insertions(+), 20 deletions(-)
1 files change
On Fri, Jan 20, 2012 at 10:23 AM, Russell King - ARM Linux
wrote:
> Convert ux500 to use the new amba_device_alloc APIs.
>
> Signed-off-by: Russell King
Acked-by: Linus Walleij
Thanks Russell,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body o
On Fri, Jan 20, 2012 at 10:24 AM, Russell King - ARM Linux
wrote:
> irq 0 now means no irq, so get rid of this unnecessary initializer.
>
> Signed-off-by: Russell King
> ---
> arch/arm/mach-ux500/devices-common.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Acked-by: Linus Wall
On Fri, Jan 20, 2012 at 10:27 AM, Russell King - ARM Linux
wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-u300/core.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Acked-by: Linus Walleij
Thanks Russell,
Linus Walleij
--
To unsubscribe from this list: send the
On Fri, Jan 20, 2012 at 10:31 AM, Russell King - ARM Linux
wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-u300/core.c | 85
> 1 files changed, 16 insertions(+), 69 deletions(-)
Acked-by: Linus Walleij
Thanks Russell,
Linus Walleij
--
On Mon, Jan 23, 2012 at 4:06 PM, Carlos Chinea wrote:
> Hi Linus,
>
> On Thu, 2012-01-19 at 15:58 -0800, ext Linus Torvalds wrote:
>> So the subject says it all. It's been two weeks(+a day), and 3.3-rc1 is now
>> out.
>>
>> There are a couple of trees I haven't merged on purpose, and there may
>>
On Mon, 23 Jan 2012, Govindraj wrote:
> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley wrote:
> > On Mon, 23 Jan 2012, Govindraj wrote:
> >
> >> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley wrote:
> >> >
> >> > while trying to track down some of the serial-related PM issues in
> >> > v3.3-rc1,
No functional changes.
According to Lindent, the file drv_internface.c had some lines with bad
indentation.
This commit is the output of Lindent.
Signed-off-by: Víctor Manuel Jáquez Leal
---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 22 +++---
1 files changed, 11 ins
Silence the warning when compiling drv_interface.c
Signed-off-by: Víctor Manuel Jáquez Leal
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/drivers/staging/tidspb
I'm trying to learn how to contribute to the kernel and dsp/bridge is
a module that I have used for a while.
These patches are the result of this first effort. It is a clean up of
the file drv_interface.c which is the entry point of the kernel
module.
I would like to have some review in order to
No functional changes.
The header file drv_interface.h was only used locally, hence there's no need
to have it.
Also the only prototyped functions were the file_operations callbacks, then
this commit moves them up to avoid prototyping too.
Signed-off-by: Víctor Manuel Jáquez Leal
---
drivers/s
Uppercase function names are not pretty. Also the code flow readability is
enhanced.
Signed-off-by: Víctor Manuel Jáquez Leal
---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr
drv_interface.c include several header files that are not really used.
Signed-off-by: Víctor Manuel Jáquez Leal
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/
On Mon, Jan 23, 2012 at 11:57:09AM -0700, Paul Walmsley (p...@pwsan.com) wrote:
> http://www.spinics.net/lists/arm-kernel/msg156572.html
Well, if runtime PM does its job for clock manipulation properly, then
things should be fine. I suppose that ->probe() will fire up first and
you say it boots an
NeilBrown writes:
> On Thu, 19 Jan 2012 16:22:37 -0800 Kevin Hilman wrote:
>
>> NeilBrown writes:
>>
>> > On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman wrote:
>> >
>> >> "Joe Woodward" writes:
>> >>
[...]
>> At least this part is expected.
>>
>> In the kernel you're using the UART c
Tomi Valkeinen writes:
> omapdss doesn't work properly on system suspend. The problem seems to be
> the fact that omapdss uses pm_runtime_put() functions when turning off
> the hardware, and when system suspend is in process only sync versions
> are allowed.
>
> Using non-sync versions normally a
"Hiremath, Vaibhav" writes:
> On Wed, Jan 11, 2012 at 21:48:25, Hiremath, Vaibhav wrote:
>> On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
>> > Vaibhav Hiremath writes:
>> >
>> > > AM33XX PRM module (L4_WK domain) will be treated as another seperate
>> > > partition in _prm_bases[] tabl
"Palande, Ameya" writes:
> Any update on this?
A descriptive changelog would be helpful here, ideally with a TRM
reference to the correct values such that a reviewer could verify this
quickly.
Also, please Cc linux-arm-ker...@lists.infradead.org for upstream
patches.
Thanks,
Kevin
> On Wed,
Vaibhav Hiremath writes:
> OMAP device has 32k-sync timer which is currently used as a
> clocksource in the kernel (omap2plus_defconfig).
> The current implementation uses compile time selection between
> gp-timer and 32k-sync timer, which breaks multi-omap build for
> the devices like AM33xx, wh
On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote:
> This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl
> for the omap3 and omap4.
>
Instead of just returning the register content why not parse
the RSTST register value and check if it's really a watchdog
reset or not?
> Sig
On Mon, 23 Jan 2012 5:16 PM, Paul Chiha wrote:
> Hi,
>
> I'm using the DM37x EVM and need to trigger the vibra ports on the
TPS65950.
> It appears that I just need to define INPUT_TWL4030_VIBRA in the
config.
> After doing this, I see that the twl4030-vibra platform driver is
registered, but the
>
Hi Vaibhav,
On Tue, Jan 24, 2012 at 10:32 AM, Bedia, Vaibhav wrote:
> On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote:
>> This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl
>> for the omap3 and omap4.
>>
>
> Instead of just returning the register content why not parse
> the
On Tue, Jan 24, 2012 at 1:18 AM, Paul Walmsley wrote:
> On Mon, 23 Jan 2012, Govindraj wrote:
>
>> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley wrote:
>> > On Mon, 23 Jan 2012, Govindraj wrote:
>> >
>> >> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley wrote:
>> >> >
>> >> > while trying to tra
Hi Shubhrajyoti,
On Tue, Jan 24, 2012 at 11:40:43, Shubhrajyoti Datta wrote:
> Hi Vaibhav,
>
> On Tue, Jan 24, 2012 at 10:32 AM, Bedia, Vaibhav wrote:
> > On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote:
> >> This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl
> >> for the
On Tue, 24 Jan 2012, Govindraj wrote:
> On Tue, Jan 24, 2012 at 1:18 AM, Paul Walmsley wrote:
> > On Mon, 23 Jan 2012, Govindraj wrote:
> >> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley wrote:
> >
> > The point is that if you want tty_insert_flip_string() to be called after
> > every character
68 matches
Mail list logo
