Skip to contentSkip to conversation

New display subsystem for OMAP2/3

PREVIEW 2 Tomi Valkeinen 4 participants 8 messages Sep 22, 2008 – Sep 23, 2008

lore
Share & tools
lore

Tomi Valkeinen

author
#0 lore raw

Hi,

I sent a preview of a new display subsystem for OMAP2/3 some time ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

What's new
----------

As was pointed out in the feedback, my version was not enough to fully utilize OMAP's DISPC. I did a bit of a rewrite and I now model the overlays and overlay managers. This conveniently allows multiple display configurations, and it also solved some other problems I had previously. The code is still bit of a mess after this change.

The tv-out and DVI are also now working on OMAP3 SDP board, and you can switch between, and combine, LCD, TV-out and DVI outputs. The current interface for this is a couple of hackish sysfs files.

The Kconfig is also a bit more versatile, you can leave out the parts of the DSS that you don't need.

Overlays
--------

Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI and TV-out are not in use. The columns from left to right are:
framebuffers, overlays, overlay managers, displays. Framebuffers are handled by omapfb, and the rest by the DSS.

FB0 --- GFX -\ DVI
FB1 --- VID1 --+- LCD ---- LCD
FB2 --- VID2 -/ TV ----- TV

In the examples below we use DVI and TV so that the setup changes to the following:

FB0 --- GFX -\ -- DVI
FB1 --- VID1 --+- LCD -/ LCD
FB2 --- VID2 ---- TV ----- TV

It is also possible to setup a virtual overlay & overlay manager, which can be used with displays that can be updated with CPU/sDMA. For example:

FB3 --- VOVL ---- VMGR

You can also change the overlay to which a framebuffer is connected. With this we can, for example, change fb0 from DISPC overlay to virtual overlay while X is running on the framebuffer. This way X doesn't notice anything, but DISPC is free for other displays.

And, although not implemented yet, one framebuffer can be connected to multiple overlays. This will allow cloning of a framebuffer to multiple outputs.

Sysfs
-----
The sysfs interface is a hack, but works for testing. And I don't think sysfs interface is the best for this in the final version.

In /sys/devices/platform/omapfb we have four files: framebuffers, overlays, managers and displays. You can read them so see the current setup, and change it by writing "arg1:arg2" to it. So changing framebuffer 0 to point to vid1 overlay would require writing "0:vid1" to framebuffers file.

Examples
--------
In these examples I have symlink omapfb -> /sys/devices/platform/omapfb

# VIDEO2 plane to TV out

echo "vid2:" > omapfb/overlays                                 # (1)
fbset -fb /dev/fb2 -xres 720 -pw 720 -yres 482 -ph 482 -pe 1   # (2)
echo "vid2:tv" > omapfb/overlays                               # (3)
echo "tv:1" > omapfb/displays                                  # (4)

1. Detach vid2 overlay. Otherwise the DSS will reject the fbset, as the asked resolution is larger than the LCD's resolution.
2. Set x/y res, and enable plane
3. Attach vid2 to tv overlay manager.
4. Enable tv display

# Use DVI instead of LCD

echo "lcd:0" > omapfb/displays                                 # (1)
echo "lcd:" > omapfb/managers                                  # (2)
# switch the dvi/lcd dip-switch                                # (3)
fbset -fb /dev/fb0 -xres 800 -pw 800 -yres 600 -ph 600 -pe 1   # (4)
echo "lcd:dvi" > omapfb/managers                               # (5)
echo "dvi:1" > omapfb/displays                                 # (6)

1. Disable LCD display. We have to disable LCD before we can enable DVI
2. Detach LCD overlay manager
3. Here you have to set the DIP switch to DVI position
4. Set the new resolution
5. Attach LCD overlay manager to DVI display
6. Enable DVI display

Tomi

#1 lore raw

Hi,

Quoted 7 lines · Tomi Valkeinen

Hi,

I sent a preview of a new display subsystem for OMAP2/3 some time ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o list Cc'd though. Also you should post the patches as a proper inline series, please see git-send-email man page.

Tony

Quoted 100 lines

What's new
----------

As was pointed out in the feedback, my version was not enough to fully utilize OMAP's DISPC. I did a bit of a rewrite and I now model the overlays and overlay managers. This conveniently allows multiple display configurations, and it also solved some other problems I had previously. The code is still bit of a mess after this change.

The tv-out and DVI are also now working on OMAP3 SDP board, and you can switch between, and combine, LCD, TV-out and DVI outputs. The current interface for this is a couple of hackish sysfs files.

The Kconfig is also a bit more versatile, you can leave out the parts of the DSS that you don't need.

Overlays
--------

Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI and TV-out are not in use. The columns from left to right are:
framebuffers, overlays, overlay managers, displays. Framebuffers are handled by omapfb, and the rest by the DSS.

FB0 --- GFX -\ DVI
FB1 --- VID1 --+- LCD ---- LCD
FB2 --- VID2 -/ TV ----- TV

In the examples below we use DVI and TV so that the setup changes to the following:

FB0 --- GFX -\ -- DVI
FB1 --- VID1 --+- LCD -/ LCD
FB2 --- VID2 ---- TV ----- TV

It is also possible to setup a virtual overlay & overlay manager, which can be used with displays that can be updated with CPU/sDMA. For example:

FB3 --- VOVL ---- VMGR

You can also change the overlay to which a framebuffer is connected. With this we can, for example, change fb0 from DISPC overlay to virtual overlay while X is running on the framebuffer. This way X doesn't notice anything, but DISPC is free for other displays.

And, although not implemented yet, one framebuffer can be connected to multiple overlays. This will allow cloning of a framebuffer to multiple outputs.

Sysfs
-----
The sysfs interface is a hack, but works for testing. And I don't think sysfs interface is the best for this in the final version.

In /sys/devices/platform/omapfb we have four files: framebuffers, overlays, managers and displays. You can read them so see the current setup, and change it by writing "arg1:arg2" to it. So changing framebuffer 0 to point to vid1 overlay would require writing "0:vid1" to framebuffers file.

Examples
--------
In these examples I have symlink omapfb -> /sys/devices/platform/omapfb

# VIDEO2 plane to TV out

echo "vid2:" > omapfb/overlays                                 # (1)
fbset -fb /dev/fb2 -xres 720 -pw 720 -yres 482 -ph 482 -pe 1   # (2)
echo "vid2:tv" > omapfb/overlays                               # (3)
echo "tv:1" > omapfb/displays                                  # (4)

1. Detach vid2 overlay. Otherwise the DSS will reject the fbset, as the asked resolution is larger than the LCD's resolution.
2. Set x/y res, and enable plane
3. Attach vid2 to tv overlay manager.
4. Enable tv display

# Use DVI instead of LCD

echo "lcd:0" > omapfb/displays                                 # (1)
echo "lcd:" > omapfb/managers                                  # (2)
# switch the dvi/lcd dip-switch                                # (3)
fbset -fb /dev/fb0 -xres 800 -pw 800 -yres 600 -ph 600 -pe 1   # (4)
echo "lcd:dvi" > omapfb/managers                               # (5)
echo "dvi:1" > omapfb/displays                                 # (6)

1. Disable LCD display. We have to disable LCD before we can enable DVI
2. Detach LCD overlay manager
3. Here you have to set the DIP switch to DVI position
4. Set the new resolution
5. Attach LCD overlay manager to DVI display
6. Enable DVI display

Tomi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#2 lore raw

Hi,

Quoted 8 lines · ext Tony Lindgren

Hi,

Quoted 5 lines · Tomi Valkeinen

Hi,

I sent a preview of a new display subsystem for OMAP2/3 some time ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

Quoted 7 lines
Quoted 2 lines

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o list Cc'd though. Also you should post the patches as a proper inline series, please see git-send-email man page.

Ok, I'll move it to linux-fbdev-devel.

I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not to mail them.

What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to Linus' tree?

Tomi

#3 lore raw

Op 23 sep 2008, om 10:19 heeft Tomi Valkeinen het volgende geschreven:

Quoted 21 lines

Hi,

Quoted 8 lines · ext Tony Lindgren

Hi,

Quoted 5 lines · Tomi Valkeinen

Hi,

I sent a preview of a new display subsystem for OMAP2/3 some time ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

Quoted 7 lines
Quoted 2 lines

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o list Cc'd though. Also you should post the patches as a proper inline series, please see git-send-email man page.

Ok, I'll move it to linux-fbdev-devel.

Quoted 7 lines

I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not to mail them.

What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to Linus' tree?

Or a branch on l-o (like pm-0) that will get rebased when things change.

regards,

Koen

Quoted 10 lines

Tomi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
Quoted 30 lines · Koen Kooi

Op 23 sep 2008, om 10:19 heeft Tomi Valkeinen het volgende geschreven:

Quoted 27 lines

Hi,

Quoted 9 lines · ext Tony Lindgren

Hi,

Quoted 6 lines · Tomi Valkeinen

Hi,

I sent a preview of a new display subsystem for OMAP2/3 some time ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

Quoted 7 lines
Quoted 2 lines

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o list Cc'd though. Also you should post the patches as a proper inline series, please see git-send-email man page.

Ok, I'll move it to linux-fbdev-devel.

I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not
to mail them.

Quoted 6 lines
Quoted 3 lines

What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to Linus' tree?

Or a branch on l-o (like pm-0) that will get rebased when things change.

I'd suggest discussing it on fbdevel list, and then have the necessary patches included into the mainline kernel via fbdevel. If you cc l-o list, people will have a chance to comment also.

Once you have an ack from the fbdevel list, we can apply the patches for testing into l-o tree while waiting for the patches to come down to l-o tree from the mainline tree.

And of course you might want to have your own branch for the patches like Koen suggested. That will make it easy for people using l-o tree to try them out by doing a pull from your branch.

Tony

#5 lore raw

Op 23 sep 2008, om 11:24 heeft Tony Lindgren het volgende geschreven:

Quoted 29 lines · Koen Kooi
Quoted 28 lines

Op 23 sep 2008, om 10:19 heeft Tomi Valkeinen het volgende geschreven:

Quoted 25 lines · ext Tony Lindgren
Quoted 6 lines · Tomi Valkeinen

I sent a preview of a new display subsystem for OMAP2/3 some time

Quoted 3 lines

ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

Quoted 7 lines
Quoted 2 lines

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o list Cc'd though. Also you should post the patches as a proper inline series, please see git-send-email man page.

Ok, I'll move it to linux-fbdev-devel.

I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not
to mail them.

What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to Linus' tree?

Quoted 6 lines
Quoted 2 lines

Or a branch on l-o (like pm-0) that will get rebased when things change.

I'd suggest discussing it on fbdevel list, and then have the necessary patches included into the mainline kernel via fbdevel. If you cc l-o list, people will have a chance to comment also.

This patch also hooks into boardcode for omap3 boards, which AFAIK aren't in mainline yet, which makes it hard to funnel a working patch through the fbdev tree to mainline. But apart from that, going through fbdev-devel first would cut down on tedious review rounds later on. Does davinci share enough bits to make this DSS lib work for that as well?

regards,

Koen

#6 lore raw
Quoted 43 lines · Koen Kooi

Op 23 sep 2008, om 11:24 heeft Tony Lindgren het volgende geschreven:

Quoted 33 lines · Koen Kooi
Quoted 32 lines

Op 23 sep 2008, om 10:19 heeft Tomi Valkeinen het volgende geschreven:

Quoted 28 lines · ext Tony Lindgren
Quoted 6 lines · Tomi Valkeinen

I sent a preview of a new display subsystem for OMAP2/3 some time

Quoted 3 lines

ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

Quoted 9 lines
Quoted 2 lines

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o
list Cc'd though. Also you should post the patches as a proper inline
series, please see git-send-email man page.

Ok, I'll move it to linux-fbdev-devel.

I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not
to mail them.

What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to
Linus' tree?

Quoted 6 lines
Quoted 2 lines

Or a branch on l-o (like pm-0) that will get rebased when things change.

I'd suggest discussing it on fbdevel list, and then have the necessary patches included into the mainline kernel via fbdevel. If you cc l-o list, people will have a chance to comment also.

Quoted 6 lines

This patch also hooks into boardcode for omap3 boards, which AFAIK aren't in mainline yet, which makes it hard to funnel a working patch through the fbdev tree to mainline. But apart from that, going through fbdev-devel first would cut down on tedious review rounds later on. Does davinci share enough bits to make this DSS lib work for that as well?

The drivers should be independent of the platform_data in the board-*.c files as it may take a while longer to get the omap3 board-*.c files into the mainline kernel.

Tony

#7 lore raw

Thanks,
Vaibhav Hiremath
Senior Software Engg.
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

Quoted 8 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tony Lindgren
Sent: Tuesday, September 23, 2008 4:11 PM
To: Koen Kooi
Cc: [email protected] List
Subject: Re: [PREVIEW 2] New display subsystem for OMAP2/3

Quoted 51 lines
Quoted 49 lines · Koen Kooi

Op 23 sep 2008, om 11:24 heeft Tony Lindgren het volgende geschreven:

Quoted 33 lines · Koen Kooi
Quoted 32 lines

Op 23 sep 2008, om 10:19 heeft Tomi Valkeinen het volgende geschreven:

Quoted 28 lines · ext Tony Lindgren
Quoted 6 lines · Tomi Valkeinen

I sent a preview of a new display subsystem for OMAP2/3 some time

Quoted 3 lines

ago:
http://marc.info/?l=linux-omap&m=122114505030542&w=2

Quoted 9 lines
Quoted 2 lines

I now have updated it, the patches are at the same place:
http://www.bat.org/~tomba/omap-dss/

This discussion should go to linux-fbdev-devel list. Please keep l-o
list Cc'd though. Also you should post the patches as a proper inline
series, please see git-send-email man page.

Ok, I'll move it to linux-fbdev-devel.

I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not
to mail them.

What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to
Linus' tree?

Quoted 6 lines
Quoted 2 lines

Or a branch on l-o (like pm-0) that will get rebased when things change.

I'd suggest discussing it on fbdevel list, and then have the necessary patches included into the mainline kernel via fbdevel. If you cc l-o list, people will have a chance to comment also.

This patch also hooks into boardcode for omap3 boards, which AFAIK aren't in mainline yet, which makes it hard to funnel a working patch through the fbdev tree to mainline. But apart from that, going through fbdev-devel first would cut down on tedious review rounds later on. Does davinci share enough bits to make this DSS lib work for that as well?

I believe that this discussion is happening for separate FBDEV driver which will be
compliant to DSS library posted few days back (http://lists-archives.org/video4linux/24409-omap2-3-dss-library.html).

Quoted 10 lines

The drivers should be independent of the platform_data in the board-*.c files as it may take a while longer to get the omap3 board-*.c files into the mainline kernel.

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html