I recently read the OMAP3530 spec sheet and noticed it said it
supports up to two LCD panels. I am unsure how it would handle two as
I would imagine it would need two sets of data and hsync / vsync lines
but am interested if knowing of the beagle has access to this feature.
I know the upcoming xM will have an LCD header will it support dual
panels?
Hi Trevor,
I recently read the OMAP3530 spec sheet and noticed it said it
supports up to two LCD panels. I am unsure how it would handle two as
I would imagine it would need two sets of data and hsync / vsync lines
but am interested if knowing of the beagle has access to this feature.
The OMAP supports two LCDs running the LCD interface in RFBI (Remote Frame
Buffer Interface) mode, which not that many (easily accessible) displays
support. More information can be found in the OMAP TRM (spruf98g.pdf)
chapter 15. Figure 15-2 is a good starting point for understanding the
topic...
I know the upcoming xM will have an LCD header will it support dual
panels?
The upcoming xM has a LCD header compatible with the one already available
on the current rev Cx boards. And AFAIR all signals for RFBI usage are
available - I however don't know about SW support and sourcing RFBI
compliant displays...
An easier solution might be to create a little external logic letting two
similar (normal) LCDs act like one (of double the size) to the OMAP LCD
controller?
I hope this helped your forward - Good luck
Søren
Hmm good and bad news I guess.
I took a look around the tech ref manual and I see how they got two
displays working. I have never seen a RFB display before but they seem
to be just standard displays with a chip handling the RFB protocol. I
will keep looking into this though as my project goal is to get a dual
folding LCD design working in linux.
I'm also going to look into possibly creating a intermediary between
the panels so they appear as one large one.
Thanks for the reply!
Trevor Johansen wrote:
Hmm good and bad news I guess.
I took a look around the tech ref manual and I see how they got two
displays working. I have never seen a RFB display before but they seem
to be just standard displays with a chip handling the RFB protocol. I
will keep looking into this though as my project goal is to get a dual
folding LCD design working in linux.I'm also going to look into possibly creating a intermediary between
the panels so they appear as one large one.
This is actually moderately tricky unless your panels have fairly
forgiving timing; though it's only a little bit of logic to divide your
pixels into two fairly sensibly timed streams, you'd end up with the
framebuffer memory interleaved, making for rather slow drawing.
Annoyingly, there aren't quite enough display panes for you to
draw at double-width and then 'zebra-stripe' the masks (unless
you're willing to do chroma-key, in which case you might be able
to do it).
If you're doing colour-space conversion anyway (eg. 420 -> 422 for
video) or your application is forgiving, you can probably use the
zebra-stripe approach and get the DMA engine to rearrange the data
as it hits the frame buffer.
If your panels will accept it, a (much) better way would be to
configure your display as double-height and pass alternate VSYNCs to
your panels, but they would then see a rather odd frame gap which they
may or may not tolerate well, though I would've thought most LCD
panels would cope.
Other approaches include using the McSPI or GPIOs driven by
DMA as graphics outputs if one of your displays is small,
Good luck!
Richard.
The displays I am using are 800x480 and I have tested to see how long
it can hold an image without artifacts without receiving new data and
I have promising results. I am trying for your second method mentioned
with alternate Vsyncs and when I have enough spare change for another
screen I am going to put together an FPGA setup to figure out my
required pixel clocks and maximum timings. When I get something done I
will submit my website to the beagleboard project provided this idea
actually works.
Trevor Johansen wrote:
Hmm good and bad news I guess.
I took a look around the tech ref manual and I see how they got two
displays working. I have never seen a RFB display before but they seem
to be just standard displays with a chip handling the RFB protocol. I
will keep looking into this though as my project goal is to get a dual
folding LCD design working in linux.
One example of hardware using display over RFBI are Nokia N800 and N810 tablets. OMAP (2420?) is connected to external Epson S1D13745 LCD controller [1] with its own framebuffer. OMAP uses RFBI to update rectangular areas in S1D13745 framebuffer where pixel data changed. The LCD panel is driven from Epson controller.
Same concept was used also for Nokia 770 (OMAP 1710, Epson S1D13742)
1. http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=291&Itemid=99
I think someone asked about this a while back, not sure if you are the same
person but I'll risk saying the same thing again.
If you are doing an FPGA, you can present standard timing to your LCD. For
your 800x480 LCD, you can setup the DSS for a 800x960 LCD with 2x the pixel
clock. Then have the FPGA buffer the lines. Clock things from the DSS at
twice the speed and have the FPGA pace it out. You'll need some glue like a
divide by two. So you clock out the entire first line in 1/2 the normal time
from the DSS for the first LCD and while it is still being slowly pushed out
to the first LCD, the DSS will be clocking out information for the second
LCD. This way, the LCD see normal timing. Drawback as pointed out is your
software side can get "interesting".
Hunyue Yau wrote:
The displays I am using are 800x480 and I have tested to see how long
it can hold an image without artifacts without receiving new data and
I have promising results. I am trying for your second method mentioned
with alternate Vsyncs and when I have enough spare change for another
screen I am going to put together an FPGA setup to figure out my
required pixel clocks and maximum timings. When I get something done I
will submit my website to the beagleboard project provided this idea
actually works.
Good luck! Do yell if you have any problems ..
Bear in mind that you can, of course, also do your split in X rather
than Y and have odd line timing rather than odd frame timing; swings
and roundabouts 
I think someone asked about this a while back, not sure if you are the same person but I'll risk saying the same thing again.
If you are doing an FPGA, you can present standard timing to your LCD. For your 800x480 LCD, you can setup the DSS for a 800x960 LCD with 2x the pixel clock. Then have the FPGA buffer the lines. Clock things from the DSS at twice the speed and have the FPGA pace it out. You'll need some glue like a divide by two. So you clock out the entire first line in 1/2 the normal time from the DSS for the first LCD and while it is still being slowly pushed out to the first LCD, the DSS will be clocking out information for the second LCD. This way, the LCD see normal timing. Drawback as pointed out is your software side can get "interesting".
Oh! If you have a line buffer it's all trivial, of course
(I think one line of dual-ported RAM should be enough?); I was
assuming you wanted to do this with a CPLD at most.
If you've a line buffer, it's pretty trivial to keep your images
separate: configure DSS to 800 x 960, set your row stride to 800
and treat your images as horizontally next to each other in memory:
DSS will think your memory is laid out
p0l0 p0l1 p0l2 .. p0l960
But your line buffer will make it
p0l0 p1l0 p0l1 p1l1 ...
You can even do this with non-line-sized strides (and keep a gutter
between your frames so you don't need to clip/DMA so accurately)
Well suggested
Richard.
I think I see where the ideas going. Combine both ideas and have one
frame buffer for both displays but have the display data interleaved
and the pixel clock running at 2x each display clock. That way you
deal a pixel at the proper clock rate to each LCD sequentially.
Shouldn't require a whole lot of modifications, a FLGA or CPLD to
handle the pixel delivery and a modification of the memory map for the
frame buffer driver. Sounds simple enough.. in theory lol I have a
ways to go before I can even start but now I want to start digging
around FBDev sources.
I had no idea the Nokia n810 is running in RFBI, I actually have a
n810 on my desk and wish it preformed like a beagle board. Its also a
horror to develop on with the sd card being the only means of
updating. Maybe I will take a peek at the maemo porting projects.
@Frantisek, Thanks for that S1D13745 link I have been looking for a
chip wit nearly those exact specs and did not realize that it was a
remote frame buffer. Of course it all makes since now but I have used
many Intel 80 interfaced LCD's before and I could just cheat and put
one of these on my 800x480 boards and not even deal with the FPGA.
Anybody know a distributor that actually carries display controllers
of this kind?
Trevor Johansen wrote:
I think I see where the ideas going. Combine both ideas and have one
frame buffer for both displays but have the display data interleaved
and the pixel clock running at 2x each display clock. That way you
deal a pixel at the proper clock rate to each LCD sequentially.
Shouldn't require a whole lot of modifications, a FLGA or CPLD to
handle the pixel delivery and a modification of the memory map for the
frame buffer driver. Sounds simple enough.. in theory lol I have a
ways to go before I can even start but now I want to start digging
around FBDev sources.
That's the obvious thing to do, but has the irritating disadvantage
that your in-memory framebuffer is now arranged
d0:(0,0) d1:(0,0) d0:(0,1) d1:(0,1)
d0:(1,0) d1:(1,0) d0:(1,1) d1:(1,1)
So that you can't easily draw onto only one display - you'll at least
have to draw into an in-memory buffer which is arranged in the
conventional way and then DMA pixels into your framebuffer for DSS,
which is a waste of memory bandwidth (though you do get this for
free if you are DMAing into the framebuffer anyway from the 3d
engine or video decoders).
(if you want both displays to display the same thing, of course,
there is a far easier way to do that :-)).
[snip]
Richard.
I've been able to get a two LCD setup working (two DVI monitors) by
having an FPGA connected to the OMAP3 and doing an expanded
framebuffer.
I.e for 1024x768x60hz, i've done 2048x768x30Hz, and have the FPGA
frame double, split it on a line by line basis and send to two DVI
transmitters for two flat panels.
I've got Linux setup with a custom API that allows for run-time
resolution switching using the sysfs interface.
It has worked out extremely well.
Hence, I can confidently say it is doable if you have no problems
putting an FPGA in the path.
Jerry
@Jerry, You make it sound easy, congrats getting it to work!
Do you have a website or any documentation we can take a peek at?
Richard Watts wrote:
Trevor Johansen wrote:
I think I see where the ideas going. Combine both ideas and have one
frame buffer for both displays but have the display data interleaved
and the pixel clock running at 2x each display clock. That way you
deal a pixel at the proper clock rate to each LCD sequentially.
Shouldn't require a whole lot of modifications, a FLGA or CPLD to
handle the pixel delivery and a modification of the memory map for the
frame buffer driver. Sounds simple enough.. in theory lol I have a
ways to go before I can even start but now I want to start digging
around FBDev sources.That's the obvious thing to do, but has the irritating disadvantage
that your in-memory framebuffer is now arrangedd0:(0,0) d1:(0,0) d0:(0,1) d1:(0,1)
d0:(1,0) d1:(1,0) d0:(1,1) d1:(1,1)So that you can't easily draw onto only one display - you'll at least
have to draw into an in-memory buffer which is arranged in the
conventional way and then DMA pixels into your framebuffer for DSS,
which is a waste of memory bandwidth (though you do get this for
free if you are DMAing into the framebuffer anyway from the 3d
engine or video decoders).
How about this flashback of 1980s demo coding:
Send out interleaved lines at 2x the rate as above (or just interleave frames/lines and abuse LCD timing a little) and demultiplex them to the two panels. With an HSYNC FIQ/IRQ, change the display DMA pointer between one of two normal flat framebuffers; after one line is displayed, set up the next line to be displayed but from the other framebuffer -- pingpong between them.
I'm not that familiar with OMAP3's DSS but the video DMA may well be restartable each line like this. Does the DSS provide an HSYNC interrupt? If so, it's a small extra software cost (the FIQ handler could really be tiny) with the advantage of being able to display from two perfectly normal framebuffers without interleaving or weird addressing, or any DMA chewing up bandwidth.
Cheers,
Matt
PS: I didn't say it'd be pretty.
Matt Evans wrote:
How about this flashback of 1980s demo coding:
Send out interleaved lines at 2x the rate as above (or just interleave frames/lines and abuse LCD timing a little)
and demultiplex them to the two panels. With an HSYNC FIQ/IRQ, change the display DMA pointer between one of two
normal flat framebuffers; after one line is displayed, set up the next line to be displayed but from the other
framebuffer -- pingpong between them.I'm not that familiar with OMAP3's DSS but the video DMA may well be restartable each line like this. Does the DSS
provide an HSYNC interrupt? If so, it's a small extra software cost (the FIQ handler could really be tiny) with the
advantage of being able to display from two perfectly normal framebuffers without interleaving or weird addressing,
or any DMA chewing up bandwidth.
no HSYNC afaik, also the DSS seems to latch the memory address of the display buffer at VSYNC, I am not sure you can
change it on the fly during the frame...
Vladimir Pantelic wrote:
Matt Evans wrote:
How about this flashback of 1980s demo coding:
Send out interleaved lines at 2x the rate as above (or just interleave frames/lines and abuse LCD timing a little)
and demultiplex them to the two panels. With an HSYNC FIQ/IRQ, change the display DMA pointer between one of two
normal flat framebuffers; after one line is displayed, set up the next line to be displayed but from the other
framebuffer -- pingpong between them.I'm not that familiar with OMAP3's DSS but the video DMA may well be restartable each line like this. Does the DSS
provide an HSYNC interrupt? If so, it's a small extra software cost (the FIQ handler could really be tiny) with the
advantage of being able to display from two perfectly normal framebuffers without interleaving or weird addressing,
or any DMA chewing up bandwidth.no HSYNC afaik, also the DSS seems to latch the memory address of the display buffer at VSYNC, I am not sure you can
change it on the fly during the frame...
Aw, that's no fun 
Didn't these people have Amigas etc. when growing up?
Cheers,
Matt
Matt Evans wrote:
Vladimir Pantelic wrote:
Matt Evans wrote:
How about this flashback of 1980s demo coding:
Send out interleaved lines at 2x the rate as above (or just interleave frames/lines and abuse LCD timing a little)
and demultiplex them to the two panels. With an HSYNC FIQ/IRQ, change the display DMA pointer between one of two
normal flat framebuffers; after one line is displayed, set up the next line to be displayed but from the other
framebuffer -- pingpong between them.I'm not that familiar with OMAP3's DSS but the video DMA may well be restartable each line like this. Does the DSS
provide an HSYNC interrupt? If so, it's a small extra software cost (the FIQ handler could really be tiny) with the
advantage of being able to display from two perfectly normal framebuffers without interleaving or weird addressing,
or any DMA chewing up bandwidth.no HSYNC afaik, also the DSS seems to latch the memory address of the display buffer at VSYNC, I am not sure you can
change it on the fly during the frame...Aw, that's no fun
I'd think you might be able to emulate an Amiga nicely on an OMAP3
I unfortunately cannot give our source-code as it is now the property
of the client i designed it for.
However, i can mention some high level details.
Basically, you set up the frame-buffer on the OMAP3 for 2W x H
resolution, where W = desired single screen resolution, and H = single
screen horizontal.
This part is trivial - you can create a new display panel driver for
your fpga in drivers/video/omap2/panels/*
For our design, we used the GPMC to communicate with the FPGA - this
part was not trivial to setup from a timing perspective on the OMAP3/
FPGA, but after many simulations, trial and errors, etc. we setup the
GPMC for both bursting and non-bursting accesses to the FPGA. I wrote
some simple FPGA chip-select configuration code in Linux to initialize
the GPMC Chip-select for proper timings.
Then, in our frame-buffer panel driver for the FPGA, we ioremap'ed the
FPGA register space into the driver, and added support in the panel
driver to automatically grab new resolutions, recompute paramters etc.
and pump it into the FPGA.
The FPGA is currently demultiplexing on a line-by-line basis - this
reduces your memory requirements from a frame-buffer on the FPGA to a
line-buffer. There are some regs to configure these timings/
resolutions.
After that, it was pretty straight-forward - i wrote some user-space
code to interact with the omap2 dss sysfs entries that allow you to
set resolutions, display timings, etc. These were wrapped in a nice
library and allowed us to switch between various resolutions at run-
time. The FPGA Panel driver catches these changes and configures the
FPGA appropriately.
That's pretty much it 
Jerry
Thanks for the rundown Jerry. Luckily my design will be much simpler
as my panels are only capable of one resolution.
Where you running the dual screens as one large single display? I
would like to run either separate window managers and restrict them to
half the frame buffer or use a single window manager and write some
extra management code so windows stay to their specified screens.