I've taken home my beagleboard because I'm extremely worried about the
compatibility of omap3x with LCD TV's.
The same 720p works with Samsung SyncMaster 245T.
In my opinion is really important the compatibility with TV's.
Can I be sure that DVI output will be compatible with any TV?
Using 2.6.27 I was able to see from DVI to Sony Bravia KDL-32W4000.
fbset
mode "1280x720-58"
# D: 72.005 MHz, H: 43.639 kHz, V: 58.186 Hz
geometry 1280 720 1280 720 16
timings 13888 110 220 20 5 40 5
accel false
rgba 5/11,6/5,5/0,0/0
endmode
Now with 2.6.28 I can't:
set bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rootdelay=2 rootfstype=ext2 rw omapfb.video_mode=1280x720MR-24@60
omapfb.debug=y'
not supported by Sony KDL-32W4000
your TV set needs probably a proper 720p@50Hz or 720p@60Hz timing.
These timings can be found in the SMPTE-296M standard and are also
found in the CEA-861 standard, as mode 19 (50Hz) and mode 4 (60Hz).
Both timings need a pixelclock of 74.25MHz.
When you use the 2.6.27 kernel, you use the first Display Sub-System
(DSS) implementation that was available.
It is fine but can not produce a pixelclock of more than about 72MHz
because it doesn't make use of the DSI PLL available in the DSS.
If your TV works with this 72MHz pixelclock, it simply means that it
has a low sync, but that's not 100% correct.
When you use the 2.6.28 kernel, you use the second DSS implementation.
It makes use of the DSI PLL and can output the required pixelclock of
74.25MHz.
I've solved this by adding the right timings in drivers/video/modedb.c
and can confirm that it perfectly works with my Sony KDL-40Z4500 and
the 720p@60Hz mode.
For the 720p@50Hz mode, there's still another issue: the beagleboards
previous to Rev.C have a bug in silicon (see sprz278c.pdf from TI) and
some fields in registers DISPC_TIMING_H and DISPC_TIMING_V are limited
to 8 bits instead of 11 bits (see the function _dispc_set_lcd_timings
in arch/arm/plat-omap/dss/dispc.c). This will be fixed in Rev.C which
a new ES of the OMAP on it.
I've removed the limitations in _dispc_set_lcd_timings and can confirm
that it doesn't work with my B5 board but that it works with my B7
board.
Unfortunately I'm not sure if I can post the timings (I've bought them
and there are some copyright restrictions on it that I don't fully
understand) so that you can test on our own.
The issue is that according to [1] ES3.0 is still having the issue. However I confirm that with the two B7 that I’ve tested so far, the correct full values were written in the registers and the output signal was clean (correct h-sync, v-sync, pxclk…).
So I can modify the patch, but it’s mostly a hack that TI cannot guarantee to work with ES3.0…
Oh, I've forgotten to mention to recalcati that the 720p@50/60Hz modes
need a negative h-sync/v-sync/pxclk.
The quickest way to change this is to modify the generic panel [1],
see e.g. [2], and to add:
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC
to the .config field.
But it's an awful hack, the proper way to do that may be to read the
EDID information in the HDTV set, to map them to the CEA 861 modes and
then to setup the DSS...
For the 720p@50Hz mode, there's still another issue: the beagleboards
previous to Rev.C have a bug in silicon (see sprz278c.pdf from TI) and
some fields in registers DISPC_TIMING_H and DISPC_TIMING_V are limited
to 8 bits instead of 11 bits (see the function _dispc_set_lcd_timings
in arch/arm/plat-omap/dss/dispc.c). This will be fixed in Rev.C which
a new ES of the OMAP on it.
I've removed the limitations in _dispc_set_lcd_timings and can confirm
that it doesn't work with my B5 board but that it works with my B7
board.
Unfortunately I'm not sure if I can post the timings (I've bought them
and there are some copyright restrictions on it that I don't fully
understand) so that you can test on our own.
Hi Matthieu,
From where in sprz278.pdf did you get the information, that these registers
would be extended in either ES3.0 or ES3.1?
As I read chapter 2 of this document it just states some limitations of the
OMAP3530 compared to what an ordinary user might expect. I'm *happy* that
you can confirm, that the registers in ES3.0 apparently has been extended,
but I don't like that I can't find this information officially in any
documents - On the contrary I think to find the exact opposite info in
sprz268.pdf - What have I missed?
Thanks to everybody.
I have to understand better OE in order to know wich git version is
the kernel I'm using.
Anyway, EDID is "the right solution", but can be enough
640x480p
720x576p
1280x720p or 1920x1080i
Now I'm too tired.
I'll test the patch ... tomorrow.
I have rev.B6
To have fixed the bug for 720p@50Hz I have to wait rev.C, so when can
I buy it?
My idea is to prepare a demo version of beagleboard and to go to a
market in order to test beagleboard DVI out with a lot of TV's.
I've asked my TI FAE because I need the 720p@50Hz mode and so need a
front porch of 440.
He answers that this is fixed in ES3.1, not before, so the Rev.C. will
still have this issue, what Gerald has already confirmed.
In ES3.1 DISPC_TIMING_H and DISPC_TIMING_V will be 12/12/8 bits
instead of 8/8/6 at the moment.
However my experiments show that with the two B7 I own, it works well.
With my B4 and B5 it doesn't work.
With the Tomi's DSS2 you can safely use the 720p@60Hz mode which only
needs a front porch of 110.
I can confirm that the timing registers have been extended on my OMAP
SDP board which has ES3.0. Also the latest TRM has been changed to
reflect the HW change. But I haven't found information about which ES
versions have this change. I guess experiments have proven it to be
ES3.0+ =).
To summarize: Great - Meaning Rev B7/C2 support full timing (12/12/8)
although not officially according to TI.
The extended registers are officially first announced/promised in ES3.1, but
seems to be active already in ES3.0 - Right?
@Tomi: Which version of the TRM do you have? The version I have is
inconsistent on this topic as highlighted in my previous post "Re: HDMI
output from Beagle board" around one week ago...
> From: beagleboard@googlegroups.com
> [mailto:beagleboard@googlegroups.com] On Behalf Of Tomi Valkeinen
> Sent: Wednesday, February 04, 2009 10:05 AM
> To: beagleboard@googlegroups.com
> Subject: [beagleboard] Re: Testing 2.6.28 with Sony Bravia KDL-32W4000
> > > For the 720p@50Hz mode, there's still another issue: the
> beagleboards
> > > previous to Rev.C have a bug in silicon (see sprz278c.pdf from TI)
> and
> > > some fields in registers DISPC_TIMING_H and DISPC_TIMING_V are
> limited
> > > to 8 bits instead of 11 bits (see the function
> _dispc_set_lcd_timings
> > > in arch/arm/plat-omap/dss/dispc.c). This will be fixed in Rev.C
> which
> > > a new ES of the OMAP on it.
> > > I've removed the limitations in _dispc_set_lcd_timings and can
> confirm
> > > that it doesn't work with my B5 board but that it works with my B7
> > > board.
> > > Unfortunately I'm not sure if I can post the timings (I've bought
> them
> > > and there are some copyright restrictions on it that I don't fully
> > > understand) so that you can test on our own.
> > Hi Matthieu,
> > From where in sprz278.pdf did you get the information, that these
> registers
> > would be extended in either ES3.0 or ES3.1?
> > As I read chapter 2 of this document it just states some limitations
> of the
> > OMAP3530 compared to what an ordinary user might expect. I'm *happy*
> that
> > you can confirm, that the registers in ES3.0 apparently has been
> extended,
> > but I don't like that I can't find this information officially in any
> > documents - On the contrary I think to find the exact opposite info
> in
> > sprz268.pdf - What have I missed?
> I can confirm that the timing registers have been extended on my OMAP
> SDP board which has ES3.0. Also the latest TRM has been changed to
> reflect the HW change. But I haven't found information about which ES
> versions have this change. I guess experiments have proven it to be
> ES3.0+ =).
> Tomi
To summarize: Great - Meaning Rev B7/C2 support full timing (12/12/8)
although not officially according to TI.
The extended registers are officially first announced/promised in ES3.1, but
seems to be active already in ES3.0 - Right?
Right.
@Tomi: Which version of the TRM do you have? The version I have is
inconsistent on this topic as highlighted in my previous post "Re: HDMI
output from Beagle board" around one week ago...
OMAP34xx Multimedia Device
Silicon Revision 3.1
Texas Instruments OMAP™ Family of Products
Version O
Technical Reference Manual
I only now noticed the "silicon revision 3.1" note there. But it _does_
work on my ES3.0 SDP... Probably more testing is needed until we can
really say it works on ES3.0s.
