On Wed, 1 Feb 2012, NeilBrown wrote:
On Fri, 27 Jan 2012 23:02:51 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Since the HDQ module doesn't support the idle protocol, the target clock
FSM in the CM is what should determine whether the module is considered
idle or not. And as long
On Fri, 27 Jan 2012 23:02:51 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Since the HDQ module doesn't support the idle protocol, the target clock
FSM in the CM is what should determine whether the module is considered
idle or not. And as long as the bit in the CM_FCLKEN register
On Thu, 26 Jan 2012 07:19:19 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Tue, 24 Jan 2012, NeilBrown wrote:
On Sat, 21 Jan 2012 17:07:18 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
On Wed, 18 Jan 2012, NeilBrown wrote:
Oh - another thing.
Sometimes during
On Sat, 28 Jan 2012, NeilBrown wrote:
On Thu, 26 Jan 2012 07:19:19 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Thanks. Should I add a Tested-by: from you on those patches?
Well... I only tested them after backporting to 3.2, and Linus is a big
proponent of the idea that once you
On Fri, 27 Jan 2012 15:58:40 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Sat, 28 Jan 2012, NeilBrown wrote:
Here's a theory: perhaps the MPU powerdomain is hitting a low-power state
while waiting for an HDQ interrupt. When the MPU powerdomain is in a low
power state, so is
On Sat, 28 Jan 2012, NeilBrown wrote:
On Fri, 27 Jan 2012 15:58:40 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Hmm, okay. Could you please remove the register read from the HDQ probe
and see if that makes a difference?
So with 'kzalloc' in place of 'kmalloc' where hdq_data is
On Tue, 24 Jan 2012, NeilBrown wrote:
On Sat, 21 Jan 2012 17:07:18 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Wed, 18 Jan 2012, NeilBrown wrote:
Oh - another thing.
Sometimes during early boot I get:
[0.158447] omap_hwmod: usbtll_fck: missing clockdomain for
On Sat, 21 Jan 2012 17:07:18 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Wed, 18 Jan 2012, NeilBrown wrote:
Oh - another thing.
Sometimes during early boot I get:
[0.158447] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck.
[0.176879] omap_hwmod: hdq:
On Mon, 23 Jan 2012 14:11:16 -0800 Kevin Hilman khil...@ti.com wrote:
NeilBrown ne...@suse.de writes:
On Thu, 19 Jan 2012 16:22:37 -0800 Kevin Hilman khil...@ti.com wrote:
NeilBrown ne...@suse.de writes:
On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman khil...@ti.com wrote:
NeilBrown ne...@suse.de writes:
On Thu, 19 Jan 2012 16:22:37 -0800 Kevin Hilman khil...@ti.com wrote:
NeilBrown ne...@suse.de writes:
On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman khil...@ti.com wrote:
Joe Woodward j...@terrafix.co.uk writes:
[...]
At least this part is
On Sat, 21 Jan 2012 17:07:18 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Wed, 18 Jan 2012, NeilBrown wrote:
Oh - another thing.
Sometimes during early boot I get:
[0.158447] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck.
[0.176879] omap_hwmod: hdq:
On Thu, 19 Jan 2012 16:22:37 -0800 Kevin Hilman khil...@ti.com wrote:
NeilBrown ne...@suse.de writes:
On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman khil...@ti.com wrote:
Joe Woodward j...@terrafix.co.uk writes:
[...]
If I do (either from the console or via a button press on
On Wed, 18 Jan 2012, NeilBrown wrote:
Oh - another thing.
Sometimes during early boot I get:
[0.158447] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck.
[0.176879] omap_hwmod: hdq: softreset failed (waited 1 usec)
This latter bug just got fixed, it's updated in the
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Thu, 2012-01-19 at 11:24 -0800, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
Now, you already said using pm_runtime_put_sync version is the correct
way when suspending. But to use that I need to either always use
...snip...
cat /sys/kernel/debug/omapdss/clk
is below and reports 66461538 for fck, so 66MHz? Still safe for OPP50.
And disabling SMART REFLEX had no obvious effect.
If you can think of anything else I could try to explore to narrow down
the source of this, I am very happy to test
On Thu, 2012-01-19 at 10:17 +, Joe Woodward wrote:
...snip...
cat /sys/kernel/debug/omapdss/clk
is below and reports 66461538 for fck, so 66MHz? Still safe for OPP50.
And disabling SMART REFLEX had no obvious effect.
If you can think of anything else I could try to
... (apologies for awful formatting of the previous mail) ...
Well, I don't see how UART could directly affect DSS. The thing that
comes to my mind is that typing a char in the console causes a change
in
the power management, which then fixes the DSS. But then again, I'd
expect the console
On Thu, 2012-01-19 at 11:29 +, Joe Woodward wrote:
... (apologies for awful formatting of the previous mail) ...
Well, I don't see how UART could directly affect DSS. The thing that
comes to my mind is that typing a char in the console causes a change
in
the power management, which
: DSS2/PM on 3.2 broken?
On Thu, 2012-01-19 at 11:29 +, Joe Woodward wrote:
... (apologies for awful formatting of the previous mail) ...
Well, I don't see how UART could directly affect DSS. The thing
that
comes to my mind is that typing a char in the console causes a
change
On Thu, 2012-01-19 at 12:21 +, Joe Woodward wrote:
If I do (either from the console or via a button press on the screen) then I
never get a SYNC_LOST.
echo 0 /sys/devices/omapdss/display0/enabled
echo 1 /sys/devices/omapdss/display0/enabled
Just trying to think of some ideas
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Fri, 2012-01-13 at 11:30 -0800, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
pm_runtime_put() is called inside omapdss driver's .suspend callback. So
I guess that means the system suspend has started. However, the logs
Joe Woodward j...@terrafix.co.uk writes:
[...]
If I do (either from the console or via a button press on the screen)
then I never get a SYNC_LOST.
echo 0 /sys/devices/omapdss/display0/enabled
echo 1 /sys/devices/omapdss/display0/enabled
Just trying to think of some ideas that may be
NeilBrown ne...@suse.de writes:
On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman khil...@ti.com wrote:
Joe Woodward j...@terrafix.co.uk writes:
[...]
If I do (either from the console or via a button press on the screen)
then I never get a SYNC_LOST.
echo 0
On Thu, 2012-01-19 at 11:24 -0800, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
Now, you already said using pm_runtime_put_sync version is the correct
way when suspending. But to use that I need to either always use
pm_runtime_put_sync, or add an extra boolean which
On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote:
Having CPUIDLE makes the DSS2 problem worse: lots of
[ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd,
restarting the output with video
On Wed, 2012-01-18 at 22:15 +1100, NeilBrown wrote:
On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote:
Having CPUIDLE makes the DSS2 problem worse: lots of
[ 21.085113] omapdss DISPC error: SYNC_LOST
On Wed, 18 Jan 2012 13:42:20 +0200 Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Wed, 2012-01-18 at 22:15 +1100, NeilBrown wrote:
On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote:
Having CPUIDLE makes
On Sat, 14 Jan 2012 10:09:15 +1100 NeilBrown ne...@suse.de wrote:
On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 13 Jan 2012, NeilBrown wrote:
Also, the HDQ access to the battery 'fuel gauge' is working fine, so
presumably that gets disturbed by
On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote:
Having CPUIDLE makes the DSS2 problem worse: lots of
[ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd,
restarting the output with video overlays disabled
messages whenever the CPU isn't busy.
I'm not sure if it is the case
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
I spent some time exploring why cpuidle never drops below state 0 and found
out that the code explicitly disables other states when uart is active - for
a
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
Not off-mode - just retention.
Okay. It's expected that the UART will drop the first byte also when CORE
is in retention, due to the delay involved in waking up the chip. But
On Fri, 13 Jan 2012 03:05:03 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
I spent some time exploring why cpuidle never drops below state 0 and
On Fri, 13 Jan 2012, NeilBrown wrote:
Also, the HDQ access to the battery 'fuel gauge' is working fine, so
presumably that gets disturbed by one of the lower power states (3,4,5).
I guess it is 4,5,6 when CORE goes to RET or OFF. So we need some way for
HDQ to say I'm busy just like UART
On Fri, Jan 13, 2012 at 3:35 PM, Paul Walmsley p...@pwsan.com wrote:
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
I spent some time exploring why cpuidle never drops below state 0 and found
out that
On Fri, 13 Jan 2012, Govindraj wrote:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 942bb4f..4ef32d4 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -183,6 +183,9 @@ static int
Paul Walmsley p...@pwsan.com writes:
cc Tero, Govindraj
On Thu, 12 Jan 2012, NeilBrown wrote:
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com
wrote:
I spent some time exploring why cpuidle never drops below state 0 and found
out that the code explicitly disables
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Thu, 2012-01-12 at 14:40 -0800, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-01-09 at 12:46 +, Joe Woodward wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel
connected via the
Kevin Hilman khil...@ti.com writes:
[...]
From: Paul Walmsley p...@pwsan.com
Date: Fri, 13 Jan 2012 02:10:30 -0700
Subject: [PATCH] ARM: OMAP3: PM: allow MPU to enter low-power states even
when the UART is active
For some reason, both the existing OMAP3 PM code and the OMAP3 CPUIdle
On Fri, 13 Jan 2012, Kevin Hilman wrote:
Kevin Hilman khil...@ti.com writes:
[...]
From: Paul Walmsley p...@pwsan.com
Date: Fri, 13 Jan 2012 02:10:30 -0700
Subject: [PATCH] ARM: OMAP3: PM: allow MPU to enter low-power states even
when the UART is active
For some reason, both
On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
On Fri, 13 Jan 2012, NeilBrown wrote:
Also, the HDQ access to the battery 'fuel gauge' is working fine, so
presumably that gets disturbed by one of the lower power states (3,4,5).
I guess it is 4,5,6 when CORE
Hi
just to follow up on this, I think there are some other bugs in this
formula... maybe someone might want to tackle them.
On Fri, 13 Jan 2012, Paul Walmsley wrote:
up-calc_latency = (100 * up-port.fifosize) /
(baud / 8);
One problem is that
On Sat, 14 Jan 2012, NeilBrown wrote:
On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
I'm not seeing garbling at all on the OMAP3 BeagleBoard here, running v3.2
with omap2plus_defconfig. The first character from the console gets lost,
which again is
On Fri, 13 Jan 2012, Paul Walmsley wrote:
Let's work out this formula for 115.2kbps:
(100 * 16) / (1000 * 115200 / 8)
= 1600 / 1440
= 1.11... (presumably the unit here is milliseconds)
= 1 (since up-calc_latency is a u32)
Then up-calc_latency is passed to
On Fri, 13 Jan 2012 16:34:06 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
So ideally this formula should change the 8 depending on the number of
data bits, whether there is a parity bit, and on the number of stop bits.
The real formula to determine the number of bits per byte should
On Sat, 14 Jan 2012, NeilBrown wrote:
On Fri, 13 Jan 2012 16:34:06 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
So ideally this formula should change the 8 depending on the number of
data bits, whether there is a parity bit, and on the number of stop bits.
The real formula to
Hi,
On Wed, 2012-01-11 at 15:15 +, Joe Woodward wrote:
The pm_runtime_get_sync() call in dss_runtime_get() is returning a
negative value, could you print out that value too?
If the call to pm_runtime_get_sync() fails, we bail out immediately. So
the LCD interface shouldn't have
On Thu, 2012-01-12 at 11:28 +0200, Tomi Valkeinen wrote:
Hi,
On Wed, 2012-01-11 at 15:15 +, Joe Woodward wrote:
The pm_runtime_get_sync() call in dss_runtime_get() is returning a
negative value, could you print out that value too?
If the call to pm_runtime_get_sync()
On Thu, 2012-01-12 at 11:28 +0200, Tomi Valkeinen wrote:
Hi,
On Wed, 2012-01-11 at 15:15 +, Joe Woodward wrote:
The pm_runtime_get_sync() call in dss_runtime_get() is returning a
negative value, could you print out that value too?
If the call to pm_runtime_get_sync()
On Mon, 2012-01-09 at 12:46 +, Joe Woodward wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected
via the DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on 3.2 I get the
following:
I've been debugging
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-01-09 at 12:46 +, Joe Woodward wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected
via the DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on
On Thu, 2012-01-12 at 14:40 -0800, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Mon, 2012-01-09 at 12:46 +, Joe Woodward wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel
connected via the DPI interface (using the generic panel driver).
On Mon, 9 Jan 2012, Joe Woodward wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected
via the DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on 3.2 I get the
following:
# echo mem /sys/power/state
...
cc Kevin
On Tue, 10 Jan 2012, NeilBrown wrote:
It seems that when cpuidle on an omap3 tries to switch to lower power
states, various things misbehave:
- UARTs lose characters
Is this with off-mode enabled, or is this with only retention idle
enabled?
If off-mode is enabled, and incoming
Hi,
On Wednesday 11 January 2012 07:13 PM, Paul Walmsley wrote:
cc Kevin
On Tue, 10 Jan 2012, NeilBrown wrote:
It seems that when cpuidle on an omap3 tries to switch to lower power
states, various things misbehave:
- UARTs lose characters
Is this with off-mode enabled, or is this with
...snip...
Could you enable omapdss debug by adding 'omapdss.debug=1 debug' in
your bootargs and share logs?
As requested:
# echo mem /sys/power/state
[ 37.371734] PM: Syncing filesystems ... done.
[ 37.397460] PM: Preparing system for mem sleep
[ 37.402923] Freezing user space
Hi,
On Wednesday 11 January 2012 08:45 PM, Joe Woodward wrote:
...snip...
Could you enable omapdss debug by adding 'omapdss.debug=1 debug' in
your bootargs and share logs?
As requested:
# echo mem /sys/power/state
[ 37.371734] PM: Syncing filesystems ... done.
[ 37.397460] PM:
-Original Message-
From: Archit a0393...@ti.com
To: Joe Woodward j...@terrafix.co.uk
Cc: Paul Walmsley p...@pwsan.com, NeilBrown ne...@suse.de,
khil...@ti.com, linux-omap@vger.kernel.org, Tomi Valkeinen
tomi.valkei...@ti.com
Date: Wed, 11 Jan 2012 21:22:00 +0530
Subject: Re: DSS2/PM
: Wed, 11 Jan 2012 21:22:00 +0530
Subject: Re: DSS2/PM on 3.2 broken?
Hi,
On Wednesday 11 January 2012 08:45 PM, Joe Woodward wrote:
...snip...
Could you enable omapdss debug by adding 'omapdss.debug=1 debug' in
your bootargs and share logs?
snip
Archit
I'm not 100% sure what you mean
On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley p...@pwsan.com wrote:
cc Kevin
On Tue, 10 Jan 2012, NeilBrown wrote:
It seems that when cpuidle on an omap3 tries to switch to lower power
states, various things misbehave:
- UARTs lose characters
Is this with off-mode
-Original Message-
From: NeilBrown ne...@suse.de
To: Joe Woodward j...@terrafix.co.uk
Cc: linux-omap@vger.kernel.org
Date: Tue, 10 Jan 2012 08:08:49 +1100
Subject: Re: DSS2/PM on 3.2 broken?
On Mon, 09 Jan 2012 12:46:43 + Joe Woodward j...@terrafix.co.uk
wrote:
I'm running
On Mon, 09 Jan 2012 12:46:43 + Joe Woodward j...@terrafix.co.uk wrote:
I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected
via the DPI interface (using the generic panel driver).
Entering standby used to work just fine on 3.0, but on 3.2 I get the
following:
61 matches
Mail list logo
