linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: omap DSS cmdline resolution not working for HDMI?
Date: Fri, 05 Oct 2012 11:04:54 +0000	[thread overview]
Message-ID: <1349435094.2401.17.camel@deskari> (raw)
In-Reply-To: <20121004175604.GE3874@atomide.com>

[-- 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 --]

  reply	other threads:[~2012-10-05 11:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-04 17:56 omap DSS cmdline resolution not working for HDMI? Tony Lindgren
2012-10-05 11:04 ` Tomi Valkeinen [this message]
2012-10-05 11:35   ` Archit Taneja
2012-10-05 16:43   ` Tony Lindgren
2012-10-09 13:06     ` Tomi Valkeinen
2012-10-09 21:54       ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1349435094.2401.17.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).