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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 18, 2010 at 12:12 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> On Tue, May 18, 2010 at 3:34 PM, Robert Nelson <robertcnelson@xxxxxxxxx> wrote:
>> On Tue, May 18, 2010 at 2:55 AM, Tomi Valkeinen
>> <tomi.valkeinen@xxxxxxxxx> 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/
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;

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux