* Re: omap DSS cmdline resolution not working for HDMI?
@ 2012-10-05 11:04 ` Tomi Valkeinen
0 siblings, 0 replies; 12+ messages in thread
From: Tomi Valkeinen @ 2012-10-05 11:04 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]
On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
> Hi,
>
> FYI, looks like for some reason DSS command line is not
> working for HDMI while it works for DSS. On my panda es
> I'm trying to set my motorola lapdock resolution from
> cmdline with:
>
> omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
>
> But it does not seem to do anything and resolution is
> VGA. If I change the cable to DVI port this works:
>
> omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
>
> Any ideas? This is with current linux next.
That's because our HDMI only supports certain timings. To be honest, I
don't really understand this restriction, as I believe the hardware
should be able to use more or less any timings just like DVI.
The 1366x768@60 mode is parsed with fbdev functions, which returns a
video timings. These timings are then given to the HDMI driver, which
tries to find matching timings from its timing table. And when it
doesn't find a match, it fails.
This is a known problem, and the hdmi driver would really need some love
in other aspects also. I'm not sure what would be the best way to
improve this without doing major rewrites. Perhaps the check in the hdmi
driver could be more relaxed, but that needs some careful thought.
> I can change the HDMI resolution OK from userspace with:
>
> echo "1" > /sys/devices/platform/omapdss/display1/enabled
> echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
> echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
> echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
That's because the above line has timings that are in the hdmi driver's
table. They are somewhat different than what fbdev gives for
"1366x768@60".
> The reason to use HDMI instead of DVI here is that HDMI
> also has the speakers on the lapdock ;)
>
> Then I'm able to switch between HDMI panel and DVI panel
> just fine using overlay0. I don't know if getting both
> HDMI and DVI to work the same time using overlay1 is
> supposed to work, but trying use overlay1 produces the
> following:
HDMI and DVI cannot be used reliably at the same time, due to a HW issue
we've had unresolved for a long time. Luckily, it was solved this week
and we'll have a patch for next merge window to get this working.
> echo "1" > /sys/devices/platform/omapdss/display0/enabled
> echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
> echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
> echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
> echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
>
> [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
> [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
> [ 958.946594] ------------[ cut here ]------------
> [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
> [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
> ...
Having said the above, I don't quite know where this error comes from...
Tiler (DMM) is not even used by omapfb.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
2012-10-05 11:04 ` Tomi Valkeinen
@ 2012-10-05 11:35 ` Archit Taneja
-1 siblings, 0 replies; 12+ messages in thread
From: Archit Taneja @ 2012-10-05 11:23 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, linux-fbdev
On Friday 05 October 2012 04:34 PM, Tomi Valkeinen wrote:
> On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
>> Hi,
>>
>> FYI, looks like for some reason DSS command line is not
>> working for HDMI while it works for DSS. On my panda es
>> I'm trying to set my motorola lapdock resolution from
>> cmdline with:
>>
>> omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
>>
>> But it does not seem to do anything and resolution is
>> VGA. If I change the cable to DVI port this works:
>>
>> omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
>>
>> Any ideas? This is with current linux next.
>
> That's because our HDMI only supports certain timings. To be honest, I
> don't really understand this restriction, as I believe the hardware
> should be able to use more or less any timings just like DVI.
>
> The 1366x768@60 mode is parsed with fbdev functions, which returns a
> video timings. These timings are then given to the HDMI driver, which
> tries to find matching timings from its timing table. And when it
> doesn't find a match, it fails.
>
> This is a known problem, and the hdmi driver would really need some love
> in other aspects also. I'm not sure what would be the best way to
> improve this without doing major rewrites. Perhaps the check in the hdmi
> driver could be more relaxed, but that needs some careful thought.
>
>> I can change the HDMI resolution OK from userspace with:
>>
>> echo "1" > /sys/devices/platform/omapdss/display1/enabled
>> echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
>> echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
>> echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
>> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
>
> That's because the above line has timings that are in the hdmi driver's
> table. They are somewhat different than what fbdev gives for
> "1366x768@60".
>
>> The reason to use HDMI instead of DVI here is that HDMI
>> also has the speakers on the lapdock ;)
>>
>> Then I'm able to switch between HDMI panel and DVI panel
>> just fine using overlay0. I don't know if getting both
>> HDMI and DVI to work the same time using overlay1 is
>> supposed to work, but trying use overlay1 produces the
>> following:
>
> HDMI and DVI cannot be used reliably at the same time, due to a HW issue
> we've had unresolved for a long time. Luckily, it was solved this week
> and we'll have a patch for next merge window to get this working.
>
>> echo "1" > /sys/devices/platform/omapdss/display0/enabled
>> echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
>> echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
>> echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
>> echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
>>
>> [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
>> [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
>> [ 958.946594] ------------[ cut here ]------------
>> [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
>> [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
>> ...
>
> Having said the above, I don't quite know where this error comes from...
> Tiler (DMM) is not even used by omapfb.
There is a timeout in wait_pending_extra_info_updates() which happens
before. That's something that shouldn't have occurred.
The overlay1 disable would have led to extra info being dirty. The
unsetting of the manager led to the call of
wait_pending_extra_info_updates(). This function noticed that there is
an extra_info update on going, and waited for the completion, but never
got it. I'm not sure why that's happened.
Archit
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
@ 2012-10-05 11:35 ` Archit Taneja
0 siblings, 0 replies; 12+ messages in thread
From: Archit Taneja @ 2012-10-05 11:35 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Tony Lindgren, linux-omap, linux-fbdev
On Friday 05 October 2012 04:34 PM, Tomi Valkeinen wrote:
> On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
>> Hi,
>>
>> FYI, looks like for some reason DSS command line is not
>> working for HDMI while it works for DSS. On my panda es
>> I'm trying to set my motorola lapdock resolution from
>> cmdline with:
>>
>> omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
>>
>> But it does not seem to do anything and resolution is
>> VGA. If I change the cable to DVI port this works:
>>
>> omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
>>
>> Any ideas? This is with current linux next.
>
> That's because our HDMI only supports certain timings. To be honest, I
> don't really understand this restriction, as I believe the hardware
> should be able to use more or less any timings just like DVI.
>
> The 1366x768@60 mode is parsed with fbdev functions, which returns a
> video timings. These timings are then given to the HDMI driver, which
> tries to find matching timings from its timing table. And when it
> doesn't find a match, it fails.
>
> This is a known problem, and the hdmi driver would really need some love
> in other aspects also. I'm not sure what would be the best way to
> improve this without doing major rewrites. Perhaps the check in the hdmi
> driver could be more relaxed, but that needs some careful thought.
>
>> I can change the HDMI resolution OK from userspace with:
>>
>> echo "1" > /sys/devices/platform/omapdss/display1/enabled
>> echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
>> echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
>> echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
>> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
>
> That's because the above line has timings that are in the hdmi driver's
> table. They are somewhat different than what fbdev gives for
> "1366x768@60".
>
>> The reason to use HDMI instead of DVI here is that HDMI
>> also has the speakers on the lapdock ;)
>>
>> Then I'm able to switch between HDMI panel and DVI panel
>> just fine using overlay0. I don't know if getting both
>> HDMI and DVI to work the same time using overlay1 is
>> supposed to work, but trying use overlay1 produces the
>> following:
>
> HDMI and DVI cannot be used reliably at the same time, due to a HW issue
> we've had unresolved for a long time. Luckily, it was solved this week
> and we'll have a patch for next merge window to get this working.
>
>> echo "1" > /sys/devices/platform/omapdss/display0/enabled
>> echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
>> echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
>> echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
>> echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
>>
>> [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
>> [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
>> [ 958.946594] ------------[ cut here ]------------
>> [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
>> [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
>> ...
>
> Having said the above, I don't quite know where this error comes from...
> Tiler (DMM) is not even used by omapfb.
There is a timeout in wait_pending_extra_info_updates() which happens
before. That's something that shouldn't have occurred.
The overlay1 disable would have led to extra info being dirty. The
unsetting of the manager led to the call of
wait_pending_extra_info_updates(). This function noticed that there is
an extra_info update on going, and waited for the completion, but never
got it. I'm not sure why that's happened.
Archit
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
2012-10-05 11:04 ` Tomi Valkeinen
@ 2012-10-05 16:43 ` Tony Lindgren
-1 siblings, 0 replies; 12+ messages in thread
From: Tony Lindgren @ 2012-10-05 16:43 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121005 04:06]:
> On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > FYI, looks like for some reason DSS command line is not
> > working for HDMI while it works for DSS. On my panda es
> > I'm trying to set my motorola lapdock resolution from
> > cmdline with:
> >
> > omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
> >
> > But it does not seem to do anything and resolution is
> > VGA. If I change the cable to DVI port this works:
> >
> > omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
> >
> > Any ideas? This is with current linux next.
>
> That's because our HDMI only supports certain timings. To be honest, I
> don't really understand this restriction, as I believe the hardware
> should be able to use more or less any timings just like DVI.
>
> The 1366x768@60 mode is parsed with fbdev functions, which returns a
> video timings. These timings are then given to the HDMI driver, which
> tries to find matching timings from its timing table. And when it
> doesn't find a match, it fails.
>
> This is a known problem, and the hdmi driver would really need some love
> in other aspects also. I'm not sure what would be the best way to
> improve this without doing major rewrites. Perhaps the check in the hdmi
> driver could be more relaxed, but that needs some careful thought.
OK, I'll take a look when I have a chance.
> > I can change the HDMI resolution OK from userspace with:
> >
> > echo "1" > /sys/devices/platform/omapdss/display1/enabled
> > echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
> > echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
> > echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
> > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
>
> That's because the above line has timings that are in the hdmi driver's
> table. They are somewhat different than what fbdev gives for
> "1366x768@60".
OK
> > The reason to use HDMI instead of DVI here is that HDMI
> > also has the speakers on the lapdock ;)
> >
> > Then I'm able to switch between HDMI panel and DVI panel
> > just fine using overlay0. I don't know if getting both
> > HDMI and DVI to work the same time using overlay1 is
> > supposed to work, but trying use overlay1 produces the
> > following:
>
> HDMI and DVI cannot be used reliably at the same time, due to a HW issue
> we've had unresolved for a long time. Luckily, it was solved this week
> and we'll have a patch for next merge window to get this working.
That's nice, I'll give that a try at some point.
> > echo "1" > /sys/devices/platform/omapdss/display0/enabled
> > echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
> > echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
> > echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
> > echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
> >
> > [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
> > [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
> > [ 958.946594] ------------[ cut here ]------------
> > [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
> > [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
> > ...
>
> Having said the above, I don't quite know where this error comes from...
> Tiler (DMM) is not even used by omapfb.
Looks like somehow also output_size won't change when changing
display output from DVI to HDMI.
If I boot with DVI panel at 1600x1200, then try to switch to the
HDMI monitor with the following script:
#!/bin/sh
export dvi=display0
export hdmi=display1
export overlay=overlay0
echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
echo tv > /sys/devices/platform/omapdss/$overlay/manager
#echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
cat /sys/devices/platform/omapdss/$hdmi/timings
cat /sys/devices/platform/omapdss/$overlay/output_size
I get the following which may provide more clues:
[64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
[64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
[64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
[64370.849670] omapdss HDMI error: failed to power on device
[64370.855407] omapdss error: failed to power on
[64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
[64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
[64370.880798] omapdss HDMI error: failed to power on device
[64370.886505] omapdss error: failed to power on
85500,1366/70/213/143,768/3/24/3
1600,1200
FYI, I'm also seeing the DVI monitor blank out on it's own for
about a second or so on regular basis every 10 minutes or so.
No idea what's causing that, maybe it's a reminder to take
a short break :)
Regards,
Tony
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
@ 2012-10-05 16:43 ` Tony Lindgren
0 siblings, 0 replies; 12+ messages in thread
From: Tony Lindgren @ 2012-10-05 16:43 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121005 04:06]:
> On Thu, 2012-10-04 at 10:56 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > FYI, looks like for some reason DSS command line is not
> > working for HDMI while it works for DSS. On my panda es
> > I'm trying to set my motorola lapdock resolution from
> > cmdline with:
> >
> > omapdss.def_disp=hdmi omapfb.mode=hdmi:1366x768@60
> >
> > But it does not seem to do anything and resolution is
> > VGA. If I change the cable to DVI port this works:
> >
> > omapdss.def_disp=dvi omapfb.mode=dvi:1366x768@60
> >
> > Any ideas? This is with current linux next.
>
> That's because our HDMI only supports certain timings. To be honest, I
> don't really understand this restriction, as I believe the hardware
> should be able to use more or less any timings just like DVI.
>
> The 1366x768@60 mode is parsed with fbdev functions, which returns a
> video timings. These timings are then given to the HDMI driver, which
> tries to find matching timings from its timing table. And when it
> doesn't find a match, it fails.
>
> This is a known problem, and the hdmi driver would really need some love
> in other aspects also. I'm not sure what would be the best way to
> improve this without doing major rewrites. Perhaps the check in the hdmi
> driver could be more relaxed, but that needs some careful thought.
OK, I'll take a look when I have a chance.
> > I can change the HDMI resolution OK from userspace with:
> >
> > echo "1" > /sys/devices/platform/omapdss/display1/enabled
> > echo "0" > /sys/devices/platform/omapdss/overlay0/enabled
> > echo "tv" > /sys/devices/platform/omapdss/overlay0/manager
> > echo "1" > /sys/devices/platform/omapdss/overlay0/enabled
> > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/display1/timings
>
> That's because the above line has timings that are in the hdmi driver's
> table. They are somewhat different than what fbdev gives for
> "1366x768@60".
OK
> > The reason to use HDMI instead of DVI here is that HDMI
> > also has the speakers on the lapdock ;)
> >
> > Then I'm able to switch between HDMI panel and DVI panel
> > just fine using overlay0. I don't know if getting both
> > HDMI and DVI to work the same time using overlay1 is
> > supposed to work, but trying use overlay1 produces the
> > following:
>
> HDMI and DVI cannot be used reliably at the same time, due to a HW issue
> we've had unresolved for a long time. Luckily, it was solved this week
> and we'll have a patch for next merge window to get this working.
That's nice, I'll give that a try at some point.
> > echo "1" > /sys/devices/platform/omapdss/display0/enabled
> > echo "0" > /sys/devices/platform/omapdss/overlay1/enabled
> > echo "lcd2" > /sys/devices/platform/omapdss/overlay1/manager
> > echo "1" > /sys/devices/platform/omapdss/overlay1/enabled
> > echo "170666,1920/336/128/208,1200/38/1/3" > /sys/devices/platform/omapdss/display0/timings
> >
> > [ 816.446044] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz
> > [ 881.639221] omapdss APPLY: timeout in wait_pending_extra_info_updates
> > [ 958.946594] ------------[ cut here ]------------
> > [ 958.953277] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0xc0/0x184()
> > [ 958.965576] L3 standard error: TARGET:DMM2 at address 0x0
> > ...
>
> Having said the above, I don't quite know where this error comes from...
> Tiler (DMM) is not even used by omapfb.
Looks like somehow also output_size won't change when changing
display output from DVI to HDMI.
If I boot with DVI panel at 1600x1200, then try to switch to the
HDMI monitor with the following script:
#!/bin/sh
export dvi=display0
export hdmi=display1
export overlay=overlay0
echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
echo tv > /sys/devices/platform/omapdss/$overlay/manager
#echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
cat /sys/devices/platform/omapdss/$hdmi/timings
cat /sys/devices/platform/omapdss/$overlay/output_size
I get the following which may provide more clues:
[64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
[64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
[64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
[64370.849670] omapdss HDMI error: failed to power on device
[64370.855407] omapdss error: failed to power on
[64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
[64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
[64370.880798] omapdss HDMI error: failed to power on device
[64370.886505] omapdss error: failed to power on
85500,1366/70/213/143,768/3/24/3
1600,1200
FYI, I'm also seeing the DVI monitor blank out on it's own for
about a second or so on regular basis every 10 minutes or so.
No idea what's causing that, maybe it's a reminder to take
a short break :)
Regards,
Tony
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
2012-10-05 16:43 ` Tony Lindgren
@ 2012-10-09 13:06 ` Tomi Valkeinen
-1 siblings, 0 replies; 12+ messages in thread
From: Tomi Valkeinen @ 2012-10-09 13:06 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]
On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
> Looks like somehow also output_size won't change when changing
> display output from DVI to HDMI.
>
> If I boot with DVI panel at 1600x1200, then try to switch to the
> HDMI monitor with the following script:
>
> #!/bin/sh
>
> export dvi=display0
> export hdmi=display1
> export overlay=overlay0
>
> echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> echo tv > /sys/devices/platform/omapdss/$overlay/manager
> #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> cat /sys/devices/platform/omapdss/$hdmi/timings
> cat /sys/devices/platform/omapdss/$overlay/output_size
>
> I get the following which may provide more clues:
>
> [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.849670] omapdss HDMI error: failed to power on device
> [64370.855407] omapdss error: failed to power on
> [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.880798] omapdss HDMI error: failed to power on device
> [64370.886505] omapdss error: failed to power on
> 85500,1366/70/213/143,768/3/24/3
> 1600,1200
Well, it's not that simple =). There are three things to consider:
- Framebuffer in the sdram. It has xres and yres parameters.
- Overlay, and it's input size (from fb) and output sizes (must fit into
the display).
- Display, which has certain size depending on video mode.
Only VID overlays can have different input and output sizes, GFX overlay
does not support scaling.
In the script above you don't change the fb at all. You can do that with
when the overlay is disabled, for example:
fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
But that only works if there's enough memory allocated for the
framebuffer, but that is the case for you if the fb was bigger
initially. Otherwise you need to set the new size
with /sys/class/graphics/fb0/size before resizing the fb.
And, of course, the framebuffer cannot be in use at that time by, for
example, X.
Yes, it's complex! I hope omapdrm will make all things simple, and we
can forget omapfb. In hindsight, I should've designed omapfb to be much
simpler, and only use gfx overlay. Making it support all overlays is a
never ending source for problems and complexity.
> FYI, I'm also seeing the DVI monitor blank out on it's own for
> about a second or so on regular basis every 10 minutes or so.
> No idea what's causing that, maybe it's a reminder to take
> a short break :)
Well that's something different. I've recently done some testing with
using DSI PLL for generating pixel clock, and I've seen unstabilities
with that. But perhaps there's something else wrong also, even when
using the PRCM for pix clock as in your case.
Does your monitor ever report something like bad signal or such?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
@ 2012-10-09 13:06 ` Tomi Valkeinen
0 siblings, 0 replies; 12+ messages in thread
From: Tomi Valkeinen @ 2012-10-09 13:06 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]
On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
> Looks like somehow also output_size won't change when changing
> display output from DVI to HDMI.
>
> If I boot with DVI panel at 1600x1200, then try to switch to the
> HDMI monitor with the following script:
>
> #!/bin/sh
>
> export dvi=display0
> export hdmi=display1
> export overlay=overlay0
>
> echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> echo tv > /sys/devices/platform/omapdss/$overlay/manager
> #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> cat /sys/devices/platform/omapdss/$hdmi/timings
> cat /sys/devices/platform/omapdss/$overlay/output_size
>
> I get the following which may provide more clues:
>
> [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.849670] omapdss HDMI error: failed to power on device
> [64370.855407] omapdss error: failed to power on
> [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.880798] omapdss HDMI error: failed to power on device
> [64370.886505] omapdss error: failed to power on
> 85500,1366/70/213/143,768/3/24/3
> 1600,1200
Well, it's not that simple =). There are three things to consider:
- Framebuffer in the sdram. It has xres and yres parameters.
- Overlay, and it's input size (from fb) and output sizes (must fit into
the display).
- Display, which has certain size depending on video mode.
Only VID overlays can have different input and output sizes, GFX overlay
does not support scaling.
In the script above you don't change the fb at all. You can do that with
when the overlay is disabled, for example:
fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
But that only works if there's enough memory allocated for the
framebuffer, but that is the case for you if the fb was bigger
initially. Otherwise you need to set the new size
with /sys/class/graphics/fb0/size before resizing the fb.
And, of course, the framebuffer cannot be in use at that time by, for
example, X.
Yes, it's complex! I hope omapdrm will make all things simple, and we
can forget omapfb. In hindsight, I should've designed omapfb to be much
simpler, and only use gfx overlay. Making it support all overlays is a
never ending source for problems and complexity.
> FYI, I'm also seeing the DVI monitor blank out on it's own for
> about a second or so on regular basis every 10 minutes or so.
> No idea what's causing that, maybe it's a reminder to take
> a short break :)
Well that's something different. I've recently done some testing with
using DSI PLL for generating pixel clock, and I've seen unstabilities
with that. But perhaps there's something else wrong also, even when
using the PRCM for pix clock as in your case.
Does your monitor ever report something like bad signal or such?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
2012-10-09 13:06 ` Tomi Valkeinen
@ 2012-10-09 21:54 ` Tony Lindgren
-1 siblings, 0 replies; 12+ messages in thread
From: Tony Lindgren @ 2012-10-09 21:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121009 06:08]:
> On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
>
> > Looks like somehow also output_size won't change when changing
> > display output from DVI to HDMI.
> >
> > If I boot with DVI panel at 1600x1200, then try to switch to the
> > HDMI monitor with the following script:
> >
> > #!/bin/sh
> >
> > export dvi=display0
> > export hdmi=display1
> > export overlay=overlay0
> >
> > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> > echo tv > /sys/devices/platform/omapdss/$overlay/manager
> > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> > cat /sys/devices/platform/omapdss/$hdmi/timings
> > cat /sys/devices/platform/omapdss/$overlay/output_size
> >
> > I get the following which may provide more clues:
> >
> > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.849670] omapdss HDMI error: failed to power on device
> > [64370.855407] omapdss error: failed to power on
> > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.880798] omapdss HDMI error: failed to power on device
> > [64370.886505] omapdss error: failed to power on
> > 85500,1366/70/213/143,768/3/24/3
> > 1600,1200
>
> Well, it's not that simple =). There are three things to consider:
>
> - Framebuffer in the sdram. It has xres and yres parameters.
> - Overlay, and it's input size (from fb) and output sizes (must fit into
> the display).
> - Display, which has certain size depending on video mode.
>
> Only VID overlays can have different input and output sizes, GFX overlay
> does not support scaling.
>
> In the script above you don't change the fb at all. You can do that with
> when the overlay is disabled, for example:
>
> fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
>
> But that only works if there's enough memory allocated for the
> framebuffer, but that is the case for you if the fb was bigger
> initially. Otherwise you need to set the new size
> with /sys/class/graphics/fb0/size before resizing the fb.
>
> And, of course, the framebuffer cannot be in use at that time by, for
> example, X.
Thanks for the explanation, I'll give that a try at some point.
> Yes, it's complex! I hope omapdrm will make all things simple, and we
> can forget omapfb. In hindsight, I should've designed omapfb to be much
> simpler, and only use gfx overlay. Making it support all overlays is a
> never ending source for problems and complexity.
Heh oh well it works reasonably for most cases I guess.
> > FYI, I'm also seeing the DVI monitor blank out on it's own for
> > about a second or so on regular basis every 10 minutes or so.
> > No idea what's causing that, maybe it's a reminder to take
> > a short break :)
>
> Well that's something different. I've recently done some testing with
> using DSI PLL for generating pixel clock, and I've seen unstabilities
> with that. But perhaps there's something else wrong also, even when
> using the PRCM for pix clock as in your case.
>
> Does your monitor ever report something like bad signal or such?
Yes I've seen that too, but that seems to be different issue and
I may have passed wrong timings in that case.
I guess the random blanking for a second or so could also be
an occastional bad timing. No warnings in that case on the monitor
though.
Regards,
Tony
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: omap DSS cmdline resolution not working for HDMI?
@ 2012-10-09 21:54 ` Tony Lindgren
0 siblings, 0 replies; 12+ messages in thread
From: Tony Lindgren @ 2012-10-09 21:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121009 06:08]:
> On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
>
> > Looks like somehow also output_size won't change when changing
> > display output from DVI to HDMI.
> >
> > If I boot with DVI panel at 1600x1200, then try to switch to the
> > HDMI monitor with the following script:
> >
> > #!/bin/sh
> >
> > export dvi=display0
> > export hdmi=display1
> > export overlay=overlay0
> >
> > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> > echo tv > /sys/devices/platform/omapdss/$overlay/manager
> > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> > cat /sys/devices/platform/omapdss/$hdmi/timings
> > cat /sys/devices/platform/omapdss/$overlay/output_size
> >
> > I get the following which may provide more clues:
> >
> > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.849670] omapdss HDMI error: failed to power on device
> > [64370.855407] omapdss error: failed to power on
> > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.880798] omapdss HDMI error: failed to power on device
> > [64370.886505] omapdss error: failed to power on
> > 85500,1366/70/213/143,768/3/24/3
> > 1600,1200
>
> Well, it's not that simple =). There are three things to consider:
>
> - Framebuffer in the sdram. It has xres and yres parameters.
> - Overlay, and it's input size (from fb) and output sizes (must fit into
> the display).
> - Display, which has certain size depending on video mode.
>
> Only VID overlays can have different input and output sizes, GFX overlay
> does not support scaling.
>
> In the script above you don't change the fb at all. You can do that with
> when the overlay is disabled, for example:
>
> fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
>
> But that only works if there's enough memory allocated for the
> framebuffer, but that is the case for you if the fb was bigger
> initially. Otherwise you need to set the new size
> with /sys/class/graphics/fb0/size before resizing the fb.
>
> And, of course, the framebuffer cannot be in use at that time by, for
> example, X.
Thanks for the explanation, I'll give that a try at some point.
> Yes, it's complex! I hope omapdrm will make all things simple, and we
> can forget omapfb. In hindsight, I should've designed omapfb to be much
> simpler, and only use gfx overlay. Making it support all overlays is a
> never ending source for problems and complexity.
Heh oh well it works reasonably for most cases I guess.
> > FYI, I'm also seeing the DVI monitor blank out on it's own for
> > about a second or so on regular basis every 10 minutes or so.
> > No idea what's causing that, maybe it's a reminder to take
> > a short break :)
>
> Well that's something different. I've recently done some testing with
> using DSI PLL for generating pixel clock, and I've seen unstabilities
> with that. But perhaps there's something else wrong also, even when
> using the PRCM for pix clock as in your case.
>
> Does your monitor ever report something like bad signal or such?
Yes I've seen that too, but that seems to be different issue and
I may have passed wrong timings in that case.
I guess the random blanking for a second or so could also be
an occastional bad timing. No warnings in that case on the monitor
though.
Regards,
Tony
^ permalink raw reply [flat|nested] 12+ messages in thread