[ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Hello,

I've rebased/updated the PM branch based on current linux-omap master
branch (2.6.32-rc1 based.)

I've also updated the OMAP Power Management wiki, and the 'Current
version' section highlights the changes, supported platforms as well
as the features that have made it into mainline.

     http://elinux.org/OMAP_Power_Management#Current_version

Have fun,

Kevin

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Hello,
>
> I've rebased/updated the PM branch based on current linux-omap master
> branch (2.6.32-rc1 based.)
>
> I've also updated the OMAP Power Management wiki, and the 'Current
> version' section highlights the changes, supported platforms as well
> as the features that have made it into mainline.
>
>      http://elinux.org/OMAP_Power_Management#Current_version
>

FYI... I just rebased the PM branch onto current omap/master.

Some important user-visible changes: The /sys/power/* options are
moving into debugfs.  For mainline, these primarily debug options need
to move to debugfs so I've moved them there.  So, if you're missing
some flag under /sys/power, it's now under /debug/pm_debug.

I've updated the 'Using the PM branch' seciont of PM wiki[1] with
the new filenames.

Kevin

[1] http://elinux.org/OMAP_Power_Management

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Juha Kuikka]

On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
> > Hello,
> >
> > I've rebased/updated the PM branch based on current linux-omap master
> > branch (2.6.32-rc1 based.)
> >
> > I've also updated the OMAP Power Management wiki, and the 'Current
> > version' section highlights the changes, supported platforms as well
> > as the features that have made it into mainline.
> >
> >      http://elinux.org/OMAP_Power_Management#Current_version
> >
>
> FYI... I just rebased the PM branch onto current omap/master.
>
> Some important user-visible changes: The /sys/power/* options are
> moving into debugfs.  For mainline, these primarily debug options need
> to move to debugfs so I've moved them there.  So, if you're missing
> some flag under /sys/power, it's now under /debug/pm_debug.
>
> I've updated the 'Using the PM branch' seciont of PM wiki[1] with
> the new filenames.
>
> Kevin
>
> [1] http://elinux.org/OMAP_Power_Management
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

I build and tried this latest on Beagleboard (C2). Booting from MMC
using ramdisk image. I changed the LL console to the 3rd UART.

The issue I have is that after the system boots up it works for as
long as I keep actively using it but if I leave it idle for a short
time (~5s) it stops responding. I have tried waking it up using both
UART and "USER" button on the board. This is with the default PM
configuration.

If I put the board into suspend (retention) it wakes up without any issues.

Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
without issues. Well the first couple characers on the console seem to
go missing but I guess without CTS/RTS that is expected?

Any pointers would be appreciated.

 - Juha

--
Madness takes it's toll. Please have exact change.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Juha Kuikka <juha.kuikka@gmail.com> writes:

> On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>>
>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>
>> > Hello,
>> >
>> > I've rebased/updated the PM branch based on current linux-omap master
>> > branch (2.6.32-rc1 based.)
>> >
>> > I've also updated the OMAP Power Management wiki, and the 'Current
>> > version' section highlights the changes, supported platforms as well
>> > as the features that have made it into mainline.
>> >
>> >      http://elinux.org/OMAP_Power_Management#Current_version
>> >
>>
>> FYI... I just rebased the PM branch onto current omap/master.
>>
>> Some important user-visible changes: The /sys/power/* options are
>> moving into debugfs.  For mainline, these primarily debug options need
>> to move to debugfs so I've moved them there.  So, if you're missing
>> some flag under /sys/power, it's now under /debug/pm_debug.
>>
>> I've updated the 'Using the PM branch' seciont of PM wiki[1] with
>> the new filenames.
>>
>> Kevin
>>
>> [1] http://elinux.org/OMAP_Power_Management
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Hi,

Hi Juha,

> I build and tried this latest on Beagleboard (C2). Booting from MMC
> using ramdisk image. I changed the LL console to the 3rd UART.
>
> The issue I have is that after the system boots up it works for as
> long as I keep actively using it but if I leave it idle for a short
> time (~5s) it stops responding. I have tried waking it up using both
> UART and "USER" button on the board. This is with the default PM
> configuration.

Thanks for testing, and reporting your problem.  I have noticed
exactly the same problem and am still investigating it.

> If I put the board into suspend (retention) it wakes up without any issues.
>
> Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
> without issues. Well the first couple characers on the console seem to
> go missing but I guess without CTS/RTS that is expected?

Yes, the loss of the first character is expected.

> Any pointers would be appreciated.

I also noticed that it works when 'sleep_while_idle' is enabled, and
this has led me to suspect a bug in that serial timout path, but I
have yet to debug further.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Nishanth Menon]

Kevin,
On Thu, Oct 8, 2009 at 5:32 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Juha Kuikka <juha.kuikka@gmail.com> writes:
>> Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
>> without issues. Well the first couple characers on the console seem to
>> go missing but I guess without CTS/RTS that is expected?
>
> Yes, the loss of the first character is expected.
Curious Question: even with 3430 ES3.1 and IORING? I wonder why..
Regards,
Nishanth Menon

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Juha Kuikka <juha.kuikka@gmail.com> writes:
>
>> On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>>
>>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>>
>>> > Hello,
>>> >
>>> > I've rebased/updated the PM branch based on current linux-omap master
>>> > branch (2.6.32-rc1 based.)
>>> >
>>> > I've also updated the OMAP Power Management wiki, and the 'Current
>>> > version' section highlights the changes, supported platforms as well
>>> > as the features that have made it into mainline.
>>> >
>>> >      http://elinux.org/OMAP_Power_Management#Current_version
>>> >
>>>
>>> FYI... I just rebased the PM branch onto current omap/master.
>>>
>>> Some important user-visible changes: The /sys/power/* options are
>>> moving into debugfs.  For mainline, these primarily debug options need
>>> to move to debugfs so I've moved them there.  So, if you're missing
>>> some flag under /sys/power, it's now under /debug/pm_debug.
>>>
>>> I've updated the 'Using the PM branch' seciont of PM wiki[1] with
>>> the new filenames.
>>>
>>> Kevin
>>>
>>> [1] http://elinux.org/OMAP_Power_Management
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> Hi,
>
> Hi Juha,
>
>> I build and tried this latest on Beagleboard (C2). Booting from MMC
>> using ramdisk image. I changed the LL console to the 3rd UART.
>>
>> The issue I have is that after the system boots up it works for as
>> long as I keep actively using it but if I leave it idle for a short
>> time (~5s) it stops responding. I have tried waking it up using both
>> UART and "USER" button on the board. This is with the default PM
>> configuration.
>
> Thanks for testing, and reporting your problem.  I have noticed
> exactly the same problem and am still investigating it.
>
>> If I put the board into suspend (retention) it wakes up without any issues.
>>
>> Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
>> without issues. Well the first couple characers on the console seem to
>> go missing but I guess without CTS/RTS that is expected?
>
> Yes, the loss of the first character is expected.
>
>> Any pointers would be appreciated.
>
> I also noticed that it works when 'sleep_while_idle' is enabled, and
> this has led me to suspect a bug in that serial timout path, but I
> have yet to debug further.

FYI...

I haven't figured out exactly why yet, but this patch gets things
working again.

Basically, I'm just leaving smart-idle disabled all the time.

Kevin

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 492dd02..90a284c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -305,7 +305,7 @@ static void omap_uart_block_sleep(struct omap_uart_state *uart)
 {
 	omap_uart_enable_clocks(uart);
 
-	omap_uart_smart_idle_enable(uart, 0);
+/* 	omap_uart_smart_idle_enable(uart, 0); */
 	uart->can_sleep = 0;
 	if (uart->timeout)
 		mod_timer(&uart->timer, jiffies + uart->timeout);
@@ -323,7 +323,7 @@ static void omap_uart_allow_sleep(struct omap_uart_state *uart)
 	if (!uart->clocked)
 		return;
 
-	omap_uart_smart_idle_enable(uart, 1);
+/* 	omap_uart_smart_idle_enable(uart, 1); */
 	uart->can_sleep = 1;
 	del_timer(&uart->timer);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
>> Juha Kuikka <juha.kuikka@gmail.com> writes:
>>
>>> On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>>
>>>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>>>
>>>> > Hello,
>>>> >
>>>> > I've rebased/updated the PM branch based on current linux-omap master
>>>> > branch (2.6.32-rc1 based.)
>>>> >
>>>> > I've also updated the OMAP Power Management wiki, and the 'Current
>>>> > version' section highlights the changes, supported platforms as well
>>>> > as the features that have made it into mainline.
>>>> >
>>>> >      http://elinux.org/OMAP_Power_Management#Current_version
>>>> >
>>>>
>>>> FYI... I just rebased the PM branch onto current omap/master.
>>>>
>>>> Some important user-visible changes: The /sys/power/* options are
>>>> moving into debugfs.  For mainline, these primarily debug options need
>>>> to move to debugfs so I've moved them there.  So, if you're missing
>>>> some flag under /sys/power, it's now under /debug/pm_debug.
>>>>
>>>> I've updated the 'Using the PM branch' seciont of PM wiki[1] with
>>>> the new filenames.
>>>>
>>>> Kevin
>>>>
>>>> [1] http://elinux.org/OMAP_Power_Management
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>> Hi,
>>
>> Hi Juha,
>>
>>> I build and tried this latest on Beagleboard (C2). Booting from MMC
>>> using ramdisk image. I changed the LL console to the 3rd UART.
>>>
>>> The issue I have is that after the system boots up it works for as
>>> long as I keep actively using it but if I leave it idle for a short
>>> time (~5s) it stops responding. I have tried waking it up using both
>>> UART and "USER" button on the board. This is with the default PM
>>> configuration.
>>
>> Thanks for testing, and reporting your problem.  I have noticed
>> exactly the same problem and am still investigating it.
>>
>>> If I put the board into suspend (retention) it wakes up without any issues.
>>>
>>> Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
>>> without issues. Well the first couple characers on the console seem to
>>> go missing but I guess without CTS/RTS that is expected?
>>
>> Yes, the loss of the first character is expected.
>>
>>> Any pointers would be appreciated.
>>
>> I also noticed that it works when 'sleep_while_idle' is enabled, and
>> this has led me to suspect a bug in that serial timout path, but I
>> have yet to debug further.
>
> FYI...
>
> I haven't figured out exactly why yet, but this patch gets things
> working again.
>
> Basically, I'm just leaving smart-idle disabled all the time.
>

I've discovered that this is only needed when using the older u-boot
binary I was downloading from beagleboard.org.  I've had lots of PM
headaches when using this u-boot and I had forgotten that I had
(re)flashed with it.

If I build and use a u-boot from the u-boot-ti repo[1], I don't have
this problem anymore.

I don't really have the time or motiviation to debug that older u-boot,
so my recommendation is to use the latest one from the TI repo below.

Thanks,

Kevin


[1] git://git.denx.de/u-boot-ti.git
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>
>>> Juha Kuikka <juha.kuikka@gmail.com> writes:
>>>
>>>> On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman
>>>> <khilman@deeprootsystems.com> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@deeprootsystems.com> writes:
>>>>>
>>>>> > Hello,
>>>>> >
>>>>> > I've rebased/updated the PM branch based on current linux-omap master
>>>>> > branch (2.6.32-rc1 based.)
>>>>> >
>>>>> > I've also updated the OMAP Power Management wiki, and the 'Current
>>>>> > version' section highlights the changes, supported platforms as well
>>>>> > as the features that have made it into mainline.
>>>>> >
>>>>> >      http://elinux.org/OMAP_Power_Management#Current_version
>>>>> >
>>>>>
>>>>> FYI... I just rebased the PM branch onto current omap/master.
>>>>>
>>>>> Some important user-visible changes: The /sys/power/* options are
>>>>> moving into debugfs.  For mainline, these primarily debug options need
>>>>> to move to debugfs so I've moved them there.  So, if you're missing
>>>>> some flag under /sys/power, it's now under /debug/pm_debug.
>>>>>
>>>>> I've updated the 'Using the PM branch' seciont of PM wiki[1] with
>>>>> the new filenames.
>>>>>
>>>>> Kevin
>>>>>
>>>>> [1] http://elinux.org/OMAP_Power_Management
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>> Hi,
>>>
>>> Hi Juha,
>>>
>>>> I build and tried this latest on Beagleboard (C2). Booting from MMC
>>>> using ramdisk image. I changed the LL console to the 3rd UART.
>>>>
>>>> The issue I have is that after the system boots up it works for as
>>>> long as I keep actively using it but if I leave it idle for a short
>>>> time (~5s) it stops responding. I have tried waking it up using both
>>>> UART and "USER" button on the board. This is with the default PM
>>>> configuration.
>>>
>>> Thanks for testing, and reporting your problem.  I have noticed
>>> exactly the same problem and am still investigating it.
>>>
>>>> If I put the board into suspend (retention) it wakes up without any issues.
>>>>
>>>> Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
>>>> without issues. Well the first couple characers on the console seem to
>>>> go missing but I guess without CTS/RTS that is expected?
>>>
>>> Yes, the loss of the first character is expected.
>>>
>>>> Any pointers would be appreciated.
>>>
>>> I also noticed that it works when 'sleep_while_idle' is enabled, and
>>> this has led me to suspect a bug in that serial timout path, but I
>>> have yet to debug further.
>>
>> FYI...
>>
>> I haven't figured out exactly why yet, but this patch gets things
>> working again.
>>
>> Basically, I'm just leaving smart-idle disabled all the time.
>>
>
> I've discovered that this is only needed when using the older u-boot
> binary I was downloading from beagleboard.org.  I've had lots of PM
> headaches when using this u-boot and I had forgotten that I had
> (re)flashed with it.
>
> If I build and use a u-boot from the u-boot-ti repo[1], I don't have
> this problem anymore.

Scratch that.  Operator error.  Actually, I still do have this
particular problem, but upgrading u-boot solved some other unrelated
problems.

Sorry for the noise.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Juha Kuikka]

On Fri, Oct 9, 2009 at 3:04 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
>
> Kevin Hilman <khilman@deeprootsystems.com> writes:
>
> > Kevin Hilman <khilman@deeprootsystems.com> writes:
> >
> >> Kevin Hilman <khilman@deeprootsystems.com> writes:
> >>
> >>> Juha Kuikka <juha.kuikka@gmail.com> writes:
> >>>
> >>>> On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman
> >>>> <khilman@deeprootsystems.com> wrote:
> >>>>>
> >>>>> Kevin Hilman <khilman@deeprootsystems.com> writes:
> >>>>>
> >>>>> > Hello,
> >>>>> >
> >>>>> > I've rebased/updated the PM branch based on current linux-omap master
> >>>>> > branch (2.6.32-rc1 based.)
> >>>>> >
> >>>>> > I've also updated the OMAP Power Management wiki, and the 'Current
> >>>>> > version' section highlights the changes, supported platforms as well
> >>>>> > as the features that have made it into mainline.
> >>>>> >
> >>>>> >      http://elinux.org/OMAP_Power_Management#Current_version
> >>>>> >
> >>>>>
> >>>>> FYI... I just rebased the PM branch onto current omap/master.
> >>>>>
> >>>>> Some important user-visible changes: The /sys/power/* options are
> >>>>> moving into debugfs.  For mainline, these primarily debug options need
> >>>>> to move to debugfs so I've moved them there.  So, if you're missing
> >>>>> some flag under /sys/power, it's now under /debug/pm_debug.
> >>>>>
> >>>>> I've updated the 'Using the PM branch' seciont of PM wiki[1] with
> >>>>> the new filenames.
> >>>>>
> >>>>> Kevin
> >>>>>
> >>>>> [1] http://elinux.org/OMAP_Power_Management
> >>>>> --
> >>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >>>>> the body of a message to majordomo@vger.kernel.org
> >>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>
> >>>> Hi,
> >>>
> >>> Hi Juha,
> >>>
> >>>> I build and tried this latest on Beagleboard (C2). Booting from MMC
> >>>> using ramdisk image. I changed the LL console to the 3rd UART.
> >>>>
> >>>> The issue I have is that after the system boots up it works for as
> >>>> long as I keep actively using it but if I leave it idle for a short
> >>>> time (~5s) it stops responding. I have tried waking it up using both
> >>>> UART and "USER" button on the board. This is with the default PM
> >>>> configuration.
> >>>
> >>> Thanks for testing, and reporting your problem.  I have noticed
> >>> exactly the same problem and am still investigating it.
> >>>
> >>>> If I put the board into suspend (retention) it wakes up without any issues.
> >>>>
> >>>> Also, if I enable "/debug/pm_debug/sleep_while_idle" board wakes up
> >>>> without issues. Well the first couple characers on the console seem to
> >>>> go missing but I guess without CTS/RTS that is expected?
> >>>
> >>> Yes, the loss of the first character is expected.
> >>>
> >>>> Any pointers would be appreciated.
> >>>
> >>> I also noticed that it works when 'sleep_while_idle' is enabled, and
> >>> this has led me to suspect a bug in that serial timout path, but I
> >>> have yet to debug further.
> >>
> >> FYI...
> >>
> >> I haven't figured out exactly why yet, but this patch gets things
> >> working again.
> >>
> >> Basically, I'm just leaving smart-idle disabled all the time.
> >>
> >
> > I've discovered that this is only needed when using the older u-boot
> > binary I was downloading from beagleboard.org.  I've had lots of PM
> > headaches when using this u-boot and I had forgotten that I had
> > (re)flashed with it.
> >
> > If I build and use a u-boot from the u-boot-ti repo[1], I don't have
> > this problem anymore.
>
> Scratch that.  Operator error.  Actually, I still do have this
> particular problem, but upgrading u-boot solved some other unrelated
> problems.
>
> Sorry for the noise.

Hi,

I updated both x-loader and u-boot. And I also pulled the latest
omap-pm and did a fresh build. I noticed there is a commit that should
fix the serial port issue.

Unfortunately I am still plagued by it.

X-Loader 1.41
U-Boot 2009.08 (Oct 09 2009 - 15:59:45)
Latest omap-om git pull (b7ecc865c5f0885fae4c4401fa78a24084f45c40).

 / Juha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Juha Kuikka wrote:
[...]

> 
> I updated both x-loader and u-boot. And I also pulled the latest
> omap-pm and did a fresh build. I noticed there is a commit that should
> fix the serial port issue.
> 
> Unfortunately I am still plagued by it.
> 
> X-Loader 1.41
> U-Boot 2009.08 (Oct 09 2009 - 15:59:45)
> Latest omap-om git pull (b7ecc865c5f0885fae4c4401fa78a24084f45c40).
> 

That's the latest commit.

But I haven't (intentionally) pushed anything to fix that serial issue 
yet.  Which commit are you referring to that should fix the issue?

Kevin

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Juha Kuikka]

On Mon, Oct 12, 2009 at 1:47 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Juha Kuikka wrote:
> [...]
>
>>
>> I updated both x-loader and u-boot. And I also pulled the latest
>> omap-pm and did a fresh build. I noticed there is a commit that should
>> fix the serial port issue.
>>
>> Unfortunately I am still plagued by it.
>>
>> X-Loader 1.41
>> U-Boot 2009.08 (Oct 09 2009 - 15:59:45)
>> Latest omap-om git pull (b7ecc865c5f0885fae4c4401fa78a24084f45c40).
>>
>
> That's the latest commit.
>
> But I haven't (intentionally) pushed anything to fix that serial issue yet.
>  Which commit are you referring to that should fix the issue?
>
This one:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=6ef4035c4a04bab8d94d8b80fcb90ea7230b8126

Committed 5 days ago. It looked like it might have something to do with this.

My bad. Please ignore the noise.

Juha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Juha Kuikka <juha.kuikka@gmail.com> writes:

> On Mon, Oct 12, 2009 at 1:47 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Juha Kuikka wrote:
>> [...]
>>
>>>
>>> I updated both x-loader and u-boot. And I also pulled the latest
>>> omap-pm and did a fresh build. I noticed there is a commit that should
>>> fix the serial port issue.
>>>
>>> Unfortunately I am still plagued by it.
>>>
>>> X-Loader 1.41
>>> U-Boot 2009.08 (Oct 09 2009 - 15:59:45)
>>> Latest omap-om git pull (b7ecc865c5f0885fae4c4401fa78a24084f45c40).
>>>
>>
>> That's the latest commit.
>>
>> But I haven't (intentionally) pushed anything to fix that serial issue yet.
>>  Which commit are you referring to that should fix the issue?
>>
> This one:
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=6ef4035c4a04bab8d94d8b80fcb90ea7230b8126
>
> Committed 5 days ago. It looked like it might have something to do with this.

Yeah, commited 5 days ago due to me rebasing, but if you look at the
author date it's from a while back.

> My bad. Please ignore the noise.

No worries.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Jon Hunter]

Kevin Hilman wrote:
> Hello,
> 
> I've rebased/updated the PM branch based on current linux-omap master
> branch (2.6.32-rc1 based.)
> 
> I've also updated the OMAP Power Management wiki, and the 'Current
> version' section highlights the changes, supported platforms as well
> as the features that have made it into mainline.
> 
>      http://elinux.org/OMAP_Power_Management#Current_version
> 
> Have fun,
> 
> Kevin

Hi Kevin,

I am not sure if anyone else if seeing this, but I have noticed that if 
my root file-system is on an SD card, then if I enable sleep_while_idle 
and off mode then the system will hang after sometime and eventually the 
kernel will panic. If my root file-system is mounted over the network, 
then I see no problems. I have reproduced this problem on both the 
beagle board and 3430sdp.

To reproduce this problem simply enable sleep_while_idle and 
enable_off_mode, wait sometime and then execute any command such as "ls" 
to view the file-system. Eventually you should see the below backtrace.

Not sure what the problem is but appears to be related to MMC and off mode.

Cheers
Jon


INFO: task mmcqd:400 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mmcqd         D c02c977c     0   400      2 0x00000000
Backtrace:
[<c02c9498>] (schedule+0x0/0x370) from [<c02c9df0>] 
(schedule_timeout+0x24/0x21c
)
[<c02c9dcc>] (schedule_timeout+0x0/0x21c) from [<c02c9c58>] 
(wait_for_common+0xe
4/0x19c)
  r7:7fffffff r6:c78d3df4 r5:c78faa40 r4:c78d3db0
[<c02c9b74>] (wait_for_common+0x0/0x19c) from [<c02c9da0>] 
(wait_for_completion+
0x18/0x1c)
[<c02c9d88>] (wait_for_completion+0x0/0x1c) from [<c0229508>] 
(mmc_wait_for_req+
0x124/0x134)
[<c02293e4>] (mmc_wait_for_req+0x0/0x134) from [<c022f838>] 
(mmc_blk_issue_rq+0x
1d0/0x734)
  r5:c78d2000 r4:c78d3e94
[<c022f668>] (mmc_blk_issue_rq+0x0/0x734) from [<c0230450>] 
(mmc_queue_thread+0x
f8/0xfc)
[<c0230358>] (mmc_queue_thread+0x0/0xfc) from [<c0065600>] 
(kthread+0x88/0x90)
[<c0065578>] (kthread+0x0/0x90) from [<c0053214>] (do_exit+0x0/0x644)
  r7:00000000 r6:00000000 r5:00000000 r4:00000000
INFO: task kjournald:405 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kjournald     D c02c977c     0   405      2 0x00000000
Backtrace:
[<c02c9498>] (schedule+0x0/0x370) from [<c02c984c>] (io_schedule+0x44/0x70)
[<c02c9808>] (io_schedule+0x0/0x70) from [<c00d4840>] 
(sync_buffer+0x4c/0x54)
  r5:c7907e9c r4:00000000
[<c00d47f4>] (sync_buffer+0x0/0x54) from [<c02ca204>] 
(__wait_on_bit+0x64/0xb0)
[<c02ca1a0>] (__wait_on_bit+0x0/0xb0) from [<c02ca2d0>] 
(out_of_line_wait_on_bit
+0x80/0x8c)
[<c02ca250>] (out_of_line_wait_on_bit+0x0/0x8c) from [<c00d4778>] 
(__wait_on_buf
fer+0x28/0x30)
[<c00d4750>] (__wait_on_buffer+0x0/0x30) from [<c011f46c>] 
(journal_commit_trans
action+0xc5c/0x141c)
[<c011e810>] (journal_commit_transaction+0x0/0x141c) from [<c01232f8>] 
(kjournal
d+0xc4/0x264)
[<c0123234>] (kjournald+0x0/0x264) from [<c0065600>] (kthread+0x88/0x90)
[<c0065578>] (kthread+0x0/0x90) from [<c0053214>] (do_exit+0x0/0x644)
  r7:00000000 r6:00000000 r5:00000000 r4:00000000
INFO: task ash:427 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ash           D c02c977c     0   427      1 0x00000000
Backtrace:
[<c02c9498>] (schedule+0x0/0x370) from [<c011d96c>] 
(do_get_write_access+0x27c/0
x4b8)
[<c011d6f0>] (do_get_write_access+0x0/0x4b8) from [<c011dbd4>] 
(journal_get_writ
e_access+0x2c/0x40)
[<c011dba8>] (journal_get_write_access+0x0/0x40) from [<c0113ffc>] 
(__ext3_journ
al_get_write_access+0x28/0x58)
  r5:c7471090 r4:00000000
[<c0113fd4>] (__ext3_journal_get_write_access+0x0/0x58) from 
[<c0107468>] (ext3_
reserve_inode_write+0x44/0x80)
  r7:c753fdb0 r6:c7477000 r5:c79b3d24 r4:00000000
[<c0107424>] (ext3_reserve_inode_write+0x0/0x80) from [<c01074c8>] 
(ext3_mark_in
ode_dirty+0x24/0x44)
  r7:00000115 r6:c79b3d24 r5:c753fdb0 r4:c7477000
[<c01074a4>] (ext3_mark_inode_dirty+0x0/0x44) from [<c0107624>] 
(ext3_dirty_inod
e+0x70/0x88)
  r6:c753fdb0 r5:00000000 r4:c7477000
[<c01075b4>] (ext3_dirty_inode+0x0/0x88) from [<c00cd808>] 
(__mark_inode_dirty+0
x34/0x15c)
  r7:00000115 r6:00000000 r5:c753fdb0 r4:00000001
[<c00cd7d4>] (__mark_inode_dirty+0x0/0x15c) from [<c00c3460>] 
(file_update_time+
0x108/0x124)
  r7:00000115 r6:00000000 r5:00000003 r4:c753fdb0
[<c00c3358>] (file_update_time+0x0/0x124) from [<c0084400>] 
(__generic_file_aio_
write+0x37c/0x4e4)
  r8:00000608 r7:c753fdb0 r6:0000001b r5:00000000 r4:00000623
[<c0084084>] (__generic_file_aio_write+0x0/0x4e4) from [<c00845dc>] 
(generic_fil
e_aio_write+0x74/0xd8)
[<c0084568>] (generic_file_aio_write+0x0/0xd8) from [<c00af0b8>] 
(do_sync_write+
0xb4/0x104)
[<c00af004>] (do_sync_write+0x0/0x104) from [<c00afbb8>] 
(vfs_write+0xb8/0x164)
  r8:0000001b r7:0000001b r6:c79b3f70 r5:001d6fa0 r4:c798af00
[<c00afb00>] (vfs_write+0x0/0x164) from [<c00afd28>] (sys_write+0x44/0x70)
  r8:001d6fa0 r7:0000001b r6:c798af00 r5:00000000 r4:00000608
[<c00afce4>] (sys_write+0x0/0x70) from [<c0027f80>] 
(ret_fast_syscall+0x0/0x2c)
  r8:c0028104 r7:00000004 r6:00000003 r5:001d6fa0 r4:0000001b

Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1

[Kevin Hilman]

Jon Hunter <jon-hunter@ti.com> writes:

> Kevin Hilman wrote:
>> Hello,
>>
>> I've rebased/updated the PM branch based on current linux-omap master
>> branch (2.6.32-rc1 based.)
>>
>> I've also updated the OMAP Power Management wiki, and the 'Current
>> version' section highlights the changes, supported platforms as well
>> as the features that have made it into mainline.
>>
>>      http://elinux.org/OMAP_Power_Management#Current_version
>>
>> Have fun,
>>
>> Kevin
>
> Hi Kevin,
>
> I am not sure if anyone else if seeing this, but I have noticed that
> if my root file-system is on an SD card, then if I enable
> sleep_while_idle and off mode then the system will hang after sometime
> and eventually the kernel will panic. If my root file-system is
> mounted over the network, then I see no problems. I have reproduced
> this problem on both the beagle board and 3430sdp.
>
> To reproduce this problem simply enable sleep_while_idle and
> enable_off_mode, wait sometime and then execute any command such as
> "ls" to view the file-system. Eventually you should see the below
> backtrace.
>
> Not sure what the problem is but appears to be related to MMC and off mode.

Right, MMC driver does not yet have OFF mode support enabled.  I
believe latest series from Adrian Hunter heading upstream should get
this working but I have yet to test with PM branch.

I think Madhu has done testing of that series with PM branch.  Maybe
he can report.

Kevin


>
> INFO: task mmcqd:400 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> mmcqd         D c02c977c     0   400      2 0x00000000
> Backtrace:
> [<c02c9498>] (schedule+0x0/0x370) from [<c02c9df0>]
> (schedule_timeout+0x24/0x21c
> )
> [<c02c9dcc>] (schedule_timeout+0x0/0x21c) from [<c02c9c58>]
> (wait_for_common+0xe
> 4/0x19c)
>  r7:7fffffff r6:c78d3df4 r5:c78faa40 r4:c78d3db0
> [<c02c9b74>] (wait_for_common+0x0/0x19c) from [<c02c9da0>]
> (wait_for_completion+
> 0x18/0x1c)
> [<c02c9d88>] (wait_for_completion+0x0/0x1c) from [<c0229508>]
> (mmc_wait_for_req+
> 0x124/0x134)
> [<c02293e4>] (mmc_wait_for_req+0x0/0x134) from [<c022f838>]
> (mmc_blk_issue_rq+0x
> 1d0/0x734)
>  r5:c78d2000 r4:c78d3e94
> [<c022f668>] (mmc_blk_issue_rq+0x0/0x734) from [<c0230450>]
> (mmc_queue_thread+0x
> f8/0xfc)
> [<c0230358>] (mmc_queue_thread+0x0/0xfc) from [<c0065600>]
> (kthread+0x88/0x90)
> [<c0065578>] (kthread+0x0/0x90) from [<c0053214>] (do_exit+0x0/0x644)
>  r7:00000000 r6:00000000 r5:00000000 r4:00000000
> INFO: task kjournald:405 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kjournald     D c02c977c     0   405      2 0x00000000
> Backtrace:
> [<c02c9498>] (schedule+0x0/0x370) from [<c02c984c>] (io_schedule+0x44/0x70)
> [<c02c9808>] (io_schedule+0x0/0x70) from [<c00d4840>]
> (sync_buffer+0x4c/0x54)
>  r5:c7907e9c r4:00000000
> [<c00d47f4>] (sync_buffer+0x0/0x54) from [<c02ca204>]
> (__wait_on_bit+0x64/0xb0)
> [<c02ca1a0>] (__wait_on_bit+0x0/0xb0) from [<c02ca2d0>]
> (out_of_line_wait_on_bit
> +0x80/0x8c)
> [<c02ca250>] (out_of_line_wait_on_bit+0x0/0x8c) from [<c00d4778>]
> (__wait_on_buf
> fer+0x28/0x30)
> [<c00d4750>] (__wait_on_buffer+0x0/0x30) from [<c011f46c>]
> (journal_commit_trans
> action+0xc5c/0x141c)
> [<c011e810>] (journal_commit_transaction+0x0/0x141c) from [<c01232f8>]
> (kjournal
> d+0xc4/0x264)
> [<c0123234>] (kjournald+0x0/0x264) from [<c0065600>] (kthread+0x88/0x90)
> [<c0065578>] (kthread+0x0/0x90) from [<c0053214>] (do_exit+0x0/0x644)
>  r7:00000000 r6:00000000 r5:00000000 r4:00000000
> INFO: task ash:427 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> ash           D c02c977c     0   427      1 0x00000000
> Backtrace:
> [<c02c9498>] (schedule+0x0/0x370) from [<c011d96c>]
> (do_get_write_access+0x27c/0
> x4b8)
> [<c011d6f0>] (do_get_write_access+0x0/0x4b8) from [<c011dbd4>]
> (journal_get_writ
> e_access+0x2c/0x40)
> [<c011dba8>] (journal_get_write_access+0x0/0x40) from [<c0113ffc>]
> (__ext3_journ
> al_get_write_access+0x28/0x58)
>  r5:c7471090 r4:00000000
> [<c0113fd4>] (__ext3_journal_get_write_access+0x0/0x58) from
> [<c0107468>] (ext3_
> reserve_inode_write+0x44/0x80)
>  r7:c753fdb0 r6:c7477000 r5:c79b3d24 r4:00000000
> [<c0107424>] (ext3_reserve_inode_write+0x0/0x80) from [<c01074c8>]
> (ext3_mark_in
> ode_dirty+0x24/0x44)
>  r7:00000115 r6:c79b3d24 r5:c753fdb0 r4:c7477000
> [<c01074a4>] (ext3_mark_inode_dirty+0x0/0x44) from [<c0107624>]
> (ext3_dirty_inod
> e+0x70/0x88)
>  r6:c753fdb0 r5:00000000 r4:c7477000
> [<c01075b4>] (ext3_dirty_inode+0x0/0x88) from [<c00cd808>]
> (__mark_inode_dirty+0
> x34/0x15c)
>  r7:00000115 r6:00000000 r5:c753fdb0 r4:00000001
> [<c00cd7d4>] (__mark_inode_dirty+0x0/0x15c) from [<c00c3460>]
> (file_update_time+
> 0x108/0x124)
>  r7:00000115 r6:00000000 r5:00000003 r4:c753fdb0
> [<c00c3358>] (file_update_time+0x0/0x124) from [<c0084400>]
> (__generic_file_aio_
> write+0x37c/0x4e4)
>  r8:00000608 r7:c753fdb0 r6:0000001b r5:00000000 r4:00000623
> [<c0084084>] (__generic_file_aio_write+0x0/0x4e4) from [<c00845dc>]
> (generic_fil
> e_aio_write+0x74/0xd8)
> [<c0084568>] (generic_file_aio_write+0x0/0xd8) from [<c00af0b8>]
> (do_sync_write+
> 0xb4/0x104)
> [<c00af004>] (do_sync_write+0x0/0x104) from [<c00afbb8>]
> (vfs_write+0xb8/0x164)
>  r8:0000001b r7:0000001b r6:c79b3f70 r5:001d6fa0 r4:c798af00
> [<c00afb00>] (vfs_write+0x0/0x164) from [<c00afd28>] (sys_write+0x44/0x70)
>  r8:001d6fa0 r7:0000001b r6:c798af00 r5:00000000 r4:00000608
> [<c00afce4>] (sys_write+0x0/0x70) from [<c0027f80>]
> (ret_fast_syscall+0x0/0x2c)
>  r8:c0028104 r7:00000004 r6:00000003 r5:001d6fa0 r4:0000001b