Re: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!

Re: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!

[Tomi Valkeinen]

On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote:
> Hi Tomi,
> 
> I've been using your dss2 branch with much success.
> 
> http://gitorious.org/linux-omap-dss2/linux/commits/for-next
> 
> I've just ran into a weird BUG that occurs on reboot on my headless
> beagles and wondering if you've ran into it too...
> 
> The kernel I'm currently testing is 2.6.34-rc7 plus the 2.6.35 dss2
> for-next commits..
> 
> I was assuming http://gitorious.org/linux-omap-dss2/linux/commit/89627989c6b4408c4578a41bcd5f9d04545797ad
> would fix it, but it hasn't fixed the Opps'ing...
> 
> log on attempt to reboot:
> 
> http://pastebin.com/iqAHMVD4

It looks like there's a mismatch with clock enables and disables
somewhere... I haven't seen that.

Can you tell me more details of your beagle? Does "headless" mean that
it's standard beagle board, but no display is connected to it?

 Tomi

Ps. Added linux-omap to cc, somebody there may have encountered this.

Re: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!

[Robert Nelson]

On Tue, May 18, 2010 at 2:55 AM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote:
>> Hi Tomi,
>>
>> I've been using your dss2 branch with much success.
>>
>> http://gitorious.org/linux-omap-dss2/linux/commits/for-next
>>
>> I've just ran into a weird BUG that occurs on reboot on my headless
>> beagles and wondering if you've ran into it too...
>>
>> The kernel I'm currently testing is 2.6.34-rc7 plus the 2.6.35 dss2
>> for-next commits..
>>
>> I was assuming http://gitorious.org/linux-omap-dss2/linux/commit/89627989c6b4408c4578a41bcd5f9d04545797ad
>> would fix it, but it hasn't fixed the Opps'ing...
>>
>> log on attempt to reboot:
>>
>> http://pastebin.com/iqAHMVD4
>
> It looks like there's a mismatch with clock enables and disables
> somewhere... I haven't seen that.
>
> Can you tell me more details of your beagle? Does "headless" mean that
> it's standard beagle board, but no display is connected to it?

Correct, just a beagle with no display connected..

I upgraded to 2.6.34 final plus dss2 for-next and enabled omapfb.debug
and a generic modesetting to see if would make any difference in the
bootargs.  Same result..

http://www.pastie.org/965380

I should also mention, this only occurs after a small length of time
(about 10 minutes).. I can't seem to trigger it after a frresh reboot
(1-2 minutes)..

config for reference:
http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6.34-devel/annotate/head:/patches/lucid-defconfig

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

Re: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!

[Felipe Contreras]

On Tue, May 18, 2010 at 3:34 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> On Tue, May 18, 2010 at 2:55 AM, Tomi Valkeinen
> <tomi.valkeinen@nokia.com> wrote:
>> On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote:
>>> Hi Tomi,
>>>
>>> I've been using your dss2 branch with much success.
>>>
>>> http://gitorious.org/linux-omap-dss2/linux/commits/for-next
>>>
>>> I've just ran into a weird BUG that occurs on reboot on my headless
>>> beagles and wondering if you've ran into it too...
>>>
>>> The kernel I'm currently testing is 2.6.34-rc7 plus the 2.6.35 dss2
>>> for-next commits..
>>>
>>> I was assuming http://gitorious.org/linux-omap-dss2/linux/commit/89627989c6b4408c4578a41bcd5f9d04545797ad
>>> would fix it, but it hasn't fixed the Opps'ing...
>>>
>>> log on attempt to reboot:
>>>
>>> http://pastebin.com/iqAHMVD4
>>
>> It looks like there's a mismatch with clock enables and disables
>> somewhere... I haven't seen that.
>>
>> Can you tell me more details of your beagle? Does "headless" mean that
>> it's standard beagle board, but no display is connected to it?
>
> Correct, just a beagle with no display connected..
>
> I upgraded to 2.6.34 final plus dss2 for-next and enabled omapfb.debug
> and a generic modesetting to see if would make any difference in the
> bootargs.  Same result..
>
> http://www.pastie.org/965380
>
> I should also mention, this only occurs after a small length of time
> (about 10 minutes).. I can't seem to trigger it after a frresh reboot
> (1-2 minutes)..
>
> config for reference:
> http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6.34-devel/annotate/head:/patches/lucid-defconfig

I think I saw this bug yesterday, but didn't paid much attention.

CC'ing Ville who might have fixed this already.

-- 
Felipe Contreras
--
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: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!

[Robert Nelson]

[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]

On Tue, May 18, 2010 at 12:12 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Tue, May 18, 2010 at 3:34 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
>> On Tue, May 18, 2010 at 2:55 AM, Tomi Valkeinen
>> <tomi.valkeinen@nokia.com> wrote:
>>> On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote:
>>>> Hi Tomi,
>>>>
>>>> I've been using your dss2 branch with much success.
>>>>
>>>> http://gitorious.org/linux-omap-dss2/linux/commits/for-next
>>>>
>>>> I've just ran into a weird BUG that occurs on reboot on my headless
>>>> beagles and wondering if you've ran into it too...
>>>>
>>>> The kernel I'm currently testing is 2.6.34-rc7 plus the 2.6.35 dss2
>>>> for-next commits..
>>>>
>>>> I was assuming http://gitorious.org/linux-omap-dss2/linux/commit/89627989c6b4408c4578a41bcd5f9d04545797ad
>>>> would fix it, but it hasn't fixed the Opps'ing...
>>>>
>>>> log on attempt to reboot:
>>>>
>>>> http://pastebin.com/iqAHMVD4
>>>
>>> It looks like there's a mismatch with clock enables and disables
>>> somewhere... I haven't seen that.
>>>
>>> Can you tell me more details of your beagle? Does "headless" mean that
>>> it's standard beagle board, but no display is connected to it?
>>
>> Correct, just a beagle with no display connected..
>>
>> I upgraded to 2.6.34 final plus dss2 for-next and enabled omapfb.debug
>> and a generic modesetting to see if would make any difference in the
>> bootargs.  Same result..
>>
>> http://www.pastie.org/965380
>>
>> I should also mention, this only occurs after a small length of time
>> (about 10 minutes).. I can't seem to trigger it after a frresh reboot
>> (1-2 minutes)..

After 10mins, the display enters dpms mode (suspend) neither ssh or
serial activity will resume the display. (not a bug, usb
mouse/keyboard will of course awaken it..)

But when reboot is called, it doesn't handle the display correctly
when it's suspended..  By simply un-suspending the display from
suspend the bug goes away.. Not sure on the best method to detect this
situation, but the attached quick patch seems to fix it on my beagles
using generic_panel_disable...

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

[-- Attachment #2: reboot-fix.diff --]
[-- Type: text/x-patch, Size: 662 bytes --]

diff --git a/drivers/video/omap2/displays/panel-generic.c b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..b4b1970 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -91,6 +91,18 @@ static int generic_panel_enable(struct omap_dss_device *dssdev)
 
 static void generic_panel_disable(struct omap_dss_device *dssdev)
 {
+
+	if (dssdev->state == OMAP_DSS_DISPLAY_SUSPENDED)
+	{
+		int r = 0;
+
+		r = generic_panel_power_on(dssdev);
+		if (r)
+			return r;
+
+		dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+	}
+
 	generic_panel_power_off(dssdev);
 
 	dssdev->state = OMAP_DSS_DISPLAY_DISABLED;

Re: dss2 for-next BUG at drivers/video/omap2/dss/core.c:323!

[Tomi Valkeinen]

On Mon, 2010-05-24 at 19:02 +0200, ext Robert Nelson wrote:

> After 10mins, the display enters dpms mode (suspend) neither ssh or
> serial activity will resume the display. (not a bug, usb
> mouse/keyboard will of course awaken it..)
> 
> But when reboot is called, it doesn't handle the display correctly
> when it's suspended..  By simply un-suspending the display from
> suspend the bug goes away.. Not sure on the best method to detect this
> situation, but the attached quick patch seems to fix it on my beagles
> using generic_panel_disable...

Right, panel-generic tries to handle things a bit too simply.

Your patch first powers on the display if it's suspended at disable
time. This is not necessary.

Also, mutexes should be added to all the functions that are called from
outside.

panel-taal.c tries to do these a bit better. I guess the locking and
handling the dssdev->state could be copied quite directly from there. 

I'm overloaded with work currently, so I can't make any promises when
I'll get to do it, but patches are always accepted! =)

 Tomi