New display subsystem for OMAP2/3

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tomi Valkeinen
Sent: Thursday, September 11, 2008 8:26 PM
To: [email protected]
Subject: [PREVIEW] New display subsystem for OMAP2/3

Display Subsystem driver for OMAP2 and 3 (DSS2)
-----------------------------------------------

This is an almost total rewrite of the current OmapFB driver (let's call it DSS1). The main targets for this work are to implement DSI, TV-out and multiple display support.

The DSS2 driver (omap-dss module) lives in arch/arm/plat-omap/dss/, and the FB, panel and controller drivers live in drivers/video/omap2/. DSS1 and DSS2 live currently side by side, you can choose which one to use.

I know it would be best to modify the DSS1 driver to implement the missing features, but the task seemed overwhelming. The DSS1 driver was just not designed for multiple displays or other outputs than parallel and rfbi, and I thought maintaining a patch set to change those wasn't something I could handle and stay sane. So I implemented DSS2 parallel to the DSS1.

I'm sending this now as a preview. DSS2 is in no way ready yet, even though it should be usable. I'm interested to hear comments about it, most importantly if it is ok to have DSS2 as a separate driver from DSS1 or is it a no-no.

Some code, especially in the dispc and rfbi, was taken and modified from the DSS1 driver by Imre Deak and others.

The patch set is about 200kB, so I decided not to send it as email, but to put it to http://www.bat.org/~tomba/omap-dss/

Architecture
------------

DSS driver has to be loaded first, then the panel and the controller drivers are loaded and they register themselves to the DSS. At this point the DSS is ready. The DSS abstracts each display behind a struct omap_display, and these are the main interface to the DSS.

OmapFB driver gets a display from DSS, initializes framebuffer memory, configures the display and activates it. Currently OmapFB only uses the first display. Also, one could implement other ways to handle the displays as the DSS does not depend on OmapFB in any way.

And a piece of cool ascii art:

DSS
/ \
/ \ +--- Panel
/ \ /
Panel----Display Display

             \       /      \
              \     /        +--- Ctrl
               \   /
              OmapFB

Porting panel and controller drivers to DSS2 is trivial. However, only OMAP3 SDP panel driver is currently ported, as I don't have any other public hardware.

Features
--------

Current implemented and tested features include:
- DSI output in command mode
- SDI output (not tested for a while, might've gotten broken)
- RFBI output (not tested for a while, might've gotten broken)
- Parallel output (OMAP3 SDP, both LCD and DVI)
- All pieces can be compiled as a module or inside kernel
- Display timing change (with, for example, fbset)
- Using DISPC to update any of the outputs
- Using CPU to update RFBI or DSI output
- OMAP DISPC planes
- RGB16, RGB24 packed, RGB24 unpacked
- YUV2, UYVY

TODO
----

OMAP2 not tested for some time
- DSS2 did work on OMAP2, but I haven't been able to test it for some time.

DSS locking
- Things break if you change dispc settings during DSI screen update. Probably the same for RFBI.

Error checking
- Lots of checks are missing or implemented just as BUG()

Rotate (external FB)
Rotate (VRFB)
Rotate (SMS)
VENC

Pixel clock
- Currently allows only pixel clocks that can be exactly produced.
- Use DSI PLL to produce pixel clock

System DMA update for DSI
- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how to skip the empty byte?)

Power management
- Clocks on/off in the first place

Multiple display handling
- Perhaps extra framebuffers, and an ioctl to map any of the FBs to any of the DISPC planes or L4. So, for example, fb1 could be GFX plane, fb0 could be updated with CPU. Then later on fb1 could be changed to use CPU with an ioctl, and fb0 to use GFX.
- Because of the dependencies of the DISPC planes, LCD/DIGIT output, the application has to know what it is doing.

Resolution change
- The x/y res of the framebuffer are not display resolutions, but just the resolution of the framebuffer (and the plane).
- The display resolution affects all planes on the display.
- Display resolution is not really a framebuffer feature. A sysfs entry for each display? If yes, is that an omapfb or DSS feature? Changing resolution affects the framebuffers.

DSI configuration
- Currently quite hardcoded configuration

OMAP1 support
- Not sure if needed

FBSET
-----

fbset with omap planes support can be found at
http://www.bat.org/~tomba/fbset/

The debian package is from ubuntu, with a patch that adds omap support.

---

 arch/arm/mach-omap2/board-3430sdp.c       |   66 +-
 arch/arm/plat-omap/Kconfig                |    2 +
 arch/arm/plat-omap/Makefile               |    2 +
 arch/arm/plat-omap/dss/Kconfig            |    5 +
 arch/arm/plat-omap/dss/Makefile           |    6 +
 arch/arm/plat-omap/dss/dispc.c            | 1539 +++++++++++++++++++
 arch/arm/plat-omap/dss/display.c          |  304 ++++
 arch/arm/plat-omap/dss/dpi.c              |  196 +++
 arch/arm/plat-omap/dss/dsi.c              | 2371 +++++++++++++++++++++++++++++
 arch/arm/plat-omap/dss/dss.c              |  389 +++++
 arch/arm/plat-omap/dss/dss.h              |  191 +++
 arch/arm/plat-omap/dss/rfbi.c             | 1274 ++++++++++++++++
 arch/arm/plat-omap/dss/sdi.c              |  152 ++
 arch/arm/plat-omap/dss/venc.c             |  501 ++++++
 arch/arm/plat-omap/fb.c                   |    9 +-
 arch/arm/plat-omap/include/mach/display.h |  358 +++++
 arch/arm/plat-omap/include/mach/omapfb.h  |    7 +
 drivers/video/Kconfig                     |    1 +
 drivers/video/Makefile                    |    1 +
 drivers/video/omap/Kconfig                |    2 +-
 drivers/video/omap2/Kconfig               |   20 +
 drivers/video/omap2/Makefile              |    4 +
 drivers/video/omap2/omapfb.c              | 1377 +++++++++++++++++
 drivers/video/omap2/panel-sdp3430-dvi.c   |  157 ++
 drivers/video/omap2/panel-sdp3430.c       |  187 +++
 25 files changed, 9108 insertions(+), 13 deletions(-)

--

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

It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

We have already initiated the re-designing of the DSS drivers and already posted the RFC for the same on the Linux-Omap and the V4L2 mailing lists. Below is the link for the RFC submitted by us on the open source mailing lists -

http://lists-archives.org/video4linux/23648-omap3-display-driver-v4l2.html
http://www.mail-archive.com/[email protected]/msg02510.html

Quoted 1 line

It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

If you want to use v4l for video output, don't let me stop you, but I don't see that it has much actual wide use beyond TI PowerPoint presentations about their graphical architecture.

Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:

Quoted 10 lines · Hardik

Quoted 8 lines

It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

Quoted 3 lines

If you want to use v4l for video output, don't let me stop you, but I don't see that it has much actual wide use beyond TI PowerPoint presentations about their graphical architecture.

That was my thought as well, but I've encountered at least 2 products this weekend at IBC using the v4l way on omap3. One of the engineers was complaining about the lack of synchronous updates if you move various videoplanes around (think resizing video windows) which makes the video picture end up outside your nice cairo-drawn borders. So yes, it is getting used outside of TI :)

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Måns Rullgård
Sent: Sunday, September 14, 2008 3:18 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [PREVIEW] New display subsystem for OMAP2/3

Quoted 16 lines · Koen Kooi

Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:

Quoted 10 lines · Hardik

Quoted 8 lines

It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

Quoted 3 lines

If you want to use v4l for video output, don't let me stop you, but I don't see that it has much actual wide use beyond TI PowerPoint presentations about their graphical architecture.

Quoted 6 lines

That was my thought as well, but I've encountered at least 2 products this weekend at IBC using the v4l way on omap3. One of the engineers was complaining about the lack of synchronous updates if you move various videoplanes around (think resizing video windows) which makes the video picture end up outside your nice cairo-drawn borders. So yes, it is getting used outside of TI :)

I'm thinking the best solution is probably to have a low-level internal driver providing access to various planes, exposing as much functionality as is practical. Various user-space interfaces, such as fbdev and v4l, could then be implemented on top of this with very little code. If I've understood things correctly, this is essentially what the patch in this thread is doing. This approach should let the TI people and Koen's mythical friends from IBC use the v4l2 interface, while still allowing the less masochistic among us to use a simpler interface.

What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch.

Quoted 16 lines · Koen Kooi

Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:

Quoted 10 lines · Hardik

Quoted 8 lines

It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

Quoted 3 lines

If you want to use v4l for video output, don't let me stop you, but I don't see that it has much actual wide use beyond TI PowerPoint presentations about their graphical architecture.

Quoted 6 lines

That was my thought as well, but I've encountered at least 2 products this weekend at IBC using the v4l way on omap3. One of the engineers was complaining about the lack of synchronous updates if you move various videoplanes around (think resizing video windows) which makes the video picture end up outside your nice cairo-drawn borders. So yes, it is getting used outside of TI :)

I'm thinking the best solution is probably to have a low-level internal driver providing access to various planes, exposing as much functionality as is practical. Various user-space interfaces, such as fbdev and v4l, could then be implemented on top of this with very little code. If I've understood things correctly, this is essentially what the patch in this thread is doing. This approach should let the TI people and Koen's mythical friends from IBC use the v4l2 interface, while still allowing the less masochistic among us to use a simpler interface.

What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch.

Quoted 25 lines · ext Måns Rullgård

Quoted 16 lines · Koen Kooi

Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:

Quoted 10 lines · Hardik

Quoted 8 lines

It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

Quoted 3 lines

If you want to use v4l for video output, don't let me stop you, but I don't see that it has much actual wide use beyond TI PowerPoint presentations about their graphical architecture.

Quoted 6 lines

That was my thought as well, but I've encountered at least 2 products this weekend at IBC using the v4l way on omap3. One of the engineers was complaining about the lack of synchronous updates if you move various videoplanes around (think resizing video windows) which makes the video picture end up outside your nice cairo-drawn borders. So yes, it is getting used outside of TI :)

Quoted 9 lines

I'm thinking the best solution is probably to have a low-level internal driver providing access to various planes, exposing as much functionality as is practical. Various user-space interfaces, such as fbdev and v4l, could then be implemented on top of this with very little code. If I've understood things correctly, this is essentially what the patch in this thread is doing. This approach should let the TI people and Koen's mythical friends from IBC use the v4l2 interface, while still allowing the less masochistic among us to use a simpler interface.

Yes, that was my idea while implementing the driver.

Quoted 5 lines

What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch.

I don't like the size either. However, I have no idea how the old driver could be transformed to include this functionality with a reasonable effort. The implementations are quite different.

Any suggestions how I could approach this task? Only thing that comes to my mind is that there are very similar low level functions in both DSS1 and DSS2 (for dispc and rfbi), that I could remove from the old place and move to arch/arm/plat-omap/dss/, but that doesn't take us very far.

I wanted to keep the old driver because it works and contains drivers for many displays. At some point my driver could of course include these, but it may take time. Also, the old driver supports OMAP1, mine doesn't.

Quoted 13 lines · Tomi Valkeinen

Quoted 7 lines · ext Måns Rullgård

Koen Kooi <[email protected]> writes:

What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch.

I don't like the size either. However, I have no idea how the old driver could be transformed to include this functionality with a reasonable effort. The implementations are quite different.

Quoted 4 lines

Any suggestions how I could approach this task? Only thing that comes to my mind is that there are very similar low level functions in both DSS1 and DSS2 (for dispc and rfbi), that I could remove from the old place and move to arch/arm/plat-omap/dss/, but that doesn't take us very far.

Are the patches you posted your latest version of the code? Do you have this code in a public git repo? I'd like to take a closer look at what you've done.

Quoted 20 lines · ext Måns Rullgård

Quoted 17 lines · Tomi Valkeinen

Quoted 7 lines · ext Måns Rullgård

Koen Kooi <[email protected]> writes:

What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch.

I don't like the size either. However, I have no idea how the old driver could be transformed to include this functionality with a reasonable effort. The implementations are quite different.

Any suggestions how I could approach this task? Only thing that comes to my mind is that there are very similar low level functions in both DSS1 and DSS2 (for dispc and rfbi), that I could remove from the old place and move to arch/arm/plat-omap/dss/, but that doesn't take us very far.

Quoted 3 lines

Are the patches you posted your latest version of the code? Do you have this code in a public git repo? I'd like to take a closer look at what you've done.

They are not the very latest, but they are recent enough. Unfortunately I don't have them on a public git. Nokia is still a bit lacking in that area =). They should apply to linux-omap kernel from last Thursday (I think the commit id is mentioned in the series file).

Quoted 10 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tomi Valkeinen
Sent: Thursday, September 11, 2008 8:26 PM
To: [email protected]
Subject: [PREVIEW] New display subsystem for OMAP2/3

Display Subsystem driver for OMAP2 and 3 (DSS2)
-----------------------------------------------

Hi,
It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

We have already initiated the re-designing of the DSS drivers and already posted the RFC for the same on the Linux-Omap and the V4L2 mailing lists. Below is the link for the RFC submitted by us on the open source mailing lists -

http://lists-archives.org/video4linux/23648-omap3-display-driver-v4l2.html
http://www.mail-archive.com/[email protected]/msg02510.html

Typically most of the modern display devices which include the OMAP2 and OMAP3, are required to support two separate types of interfaces - V4L2 interface for the video planes and fbdev interface for graphics planes. It is impossible for these two drivers on separate frameworks to co-exist as independent full fledged drivers. Hence this has been one of the main aspects we are trying to address through our design, which includes as a common DSS library which can be used by both of the drivers.

VIDEO0(V4L2) VIDEO1(V4L2) GFX0(fbdev0)

		|	|		|
		|	|		|
		----DSS Library----
		     |    | 
		    LCD   TV

Here, the DSS library is the central set of APIs which is designed to make sure that, there are no conflicts for resources, resources being the Graphics plane (pipeline), Video planes (pipelines) and Overlay Managers. Display library is not tied to any interfaces, like V4L2 or FBDEV.

Output devices registers to the DSS library and applications will be able to switch/exchange/change parameters through their interfaces going through the DSS library.

We believe that currently your implementation does not address these important aspects and lot of the users will be at loss of functionality if this is not addressed.

Thanks and Regards,
Hardik

-----Original Message-----
From: Tomi Valkeinen [mailto:[email protected]]
Sent: Monday, September 15, 2008 4:38 PM
To: Shah, Hardik
Cc: [email protected]; [email protected]
Subject: RE: [PREVIEW] New display subsystem for OMAP2/3

Quoted 3 lines · Hardik

Quoted 3 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of

Tomi

Quoted 9 lines

Quoted 7 lines

Valkeinen
Sent: Thursday, September 11, 2008 8:26 PM
To: [email protected]
Subject: [PREVIEW] New display subsystem for OMAP2/3

Display Subsystem driver for OMAP2 and 3 (DSS2)
-----------------------------------------------

Hi,
It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not

covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

Quoted 2 lines

We have already initiated the re-designing of the DSS drivers and already posted the RFC for the

same on the Linux-Omap and the V4L2 mailing lists. Below is the link for the RFC submitted by us on the open source mailing lists -

Quoted 3 lines

http://lists-archives.org/video4linux/23648-omap3-display-driver-v4l2.html
http://www.mail-archive.com/[email protected]/msg02510.html

Ah, I seem to have missed these, I was on my summer holidays at that time =). I'll study those.

Quoted 2 lines

Typically most of the modern display devices which include the OMAP2 and OMAP3, are required to

support two separate types of interfaces - V4L2 interface for the video planes and fbdev interface for graphics planes. It is impossible for these two drivers on separate frameworks to co-exist as independent full fledged drivers. Hence this has been one of the main aspects we are trying to address through our design, which includes as a common DSS library which can be used by both of the drivers.

Quoted 10 lines

VIDEO0(V4L2) VIDEO1(V4L2) GFX0(fbdev0)

		|	|		|
		|	|		|
		----DSS Library----
		     |    |
		    LCD   TV

Here, the DSS library is the central set of APIs which is designed to make sure that, there are no

conflicts for resources, resources being the Graphics plane (pipeline), Video planes (pipelines) and Overlay Managers. Display library is not tied to any interfaces, like V4L2 or FBDEV.

Quoted 2 lines

Output devices registers to the DSS library and applications will be able to switch/exchange/change

parameters through their interfaces going through the DSS library.

Quoted 1 line

Quoted 1 line

We believe that currently your implementation does not address these important aspects and lot of

the users will be at loss of functionality if this is not addressed.

I haven't used much time on the userspace interface, so my fb driver is just a copy of the old omapfb. It sounds my implementation is somewhat similar to yours. The DSS driver is not tied to fb or v4l interface, and offers ways to configure the displays and planes however you want.

I concentrated more on the the lower part than to fbdev or v4l, and more specifically I needed DSI support and multiple display support, while

still retaining the old functionality. And with multiple displays I don't mean just an LCD and a TV-out, but, for example, two LCD's and tv-out. Configurations like one LCD connected to parallel output, updated with DISPC, and the other one connected to DSI and updated with CPU or system DMA. Or two displays connected to DSI.

I also wanted to be able to change the configuration on the fly, changing where DISPC output is going and which displays are updated with CPU or sDMA.

This is why I have the display-concept in my design.

I haven't made support for multiple users of the displays (like separate fb and v4l drivers), but I don't immediately see why it couldn't be done.

However, there are some questions regarding that, as the planes do not represent displays, but just overlay planes. What happens when both fb and v4l drivers want to change the resolution or timings of the display?

Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace.

Quoted 2 lines

Thanks and Regards,
Hardik

Tomi

DSS library gives the flexibility to change to add the as many overlay managers or as many encoder on the overlay manager.

Quoted 7 lines

Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace.

Most of the open source applications are not aware of the hardware capabilities. So it should be transparently handled by the low level drivers/libraries.

Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tomi Valkeinen
Sent: Monday, September 15, 2008 4:38 PM
To: Shah, Hardik
Cc: [email protected]; [email protected]
Subject: RE: [PREVIEW] New display subsystem for OMAP2/3

Quoted 3 lines · Hardik

Quoted 3 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of

Tomi

Quoted 9 lines

Quoted 7 lines

Valkeinen
Sent: Thursday, September 11, 2008 8:26 PM
To: [email protected]
Subject: [PREVIEW] New display subsystem for OMAP2/3

Display Subsystem driver for OMAP2 and 3 (DSS2)
-----------------------------------------------

Hi,
It's time to re-design DSS frame buffer driver for the OMAP2/3. Current frame buffer driver is not

covering the most of the functionality of the OMAP2/3 DSS Hardware like multiple outputs and multiple overlay managers supported by OMAP2/3 class of SoC. Again there is no V4L2 interface exposed by the DSS drivers for controlling the video pipelines of the DSS which is highly desirable feature as the video pipelines of the DSS hardware is a natural fit to the V4L2 architecture.

Quoted 2 lines

We have already initiated the re-designing of the DSS drivers and already posted the RFC for the

same on the Linux-Omap and the V4L2 mailing lists. Below is the link for the RFC submitted by us on the open source mailing lists -

Quoted 3 lines

http://lists-archives.org/video4linux/23648-omap3-display-driver-v4l2.html
http://www.mail-archive.com/[email protected]/msg02510.html

Ah, I seem to have missed these, I was on my summer holidays at that time =). I'll study those.

Quoted 2 lines

Typically most of the modern display devices which include the OMAP2 and OMAP3, are required to

support two separate types of interfaces - V4L2 interface for the video planes and fbdev interface for graphics planes. It is impossible for these two drivers on separate frameworks to co-exist as independent full fledged drivers. Hence this has been one of the main aspects we are trying to address through our design, which includes as a common DSS library which can be used by both of the drivers.

Quoted 10 lines

VIDEO0(V4L2) VIDEO1(V4L2) GFX0(fbdev0)

		|	|		|
		|	|		|
		----DSS Library----
		     |    |
		    LCD   TV

Here, the DSS library is the central set of APIs which is designed to make sure that, there are no

conflicts for resources, resources being the Graphics plane (pipeline), Video planes (pipelines) and Overlay Managers. Display library is not tied to any interfaces, like V4L2 or FBDEV.

Quoted 2 lines

Output devices registers to the DSS library and applications will be able to switch/exchange/change

parameters through their interfaces going through the DSS library.

Quoted 2 lines

We believe that currently your implementation does not address these important aspects and lot of

the users will be at loss of functionality if this is not addressed.

I haven't used much time on the userspace interface, so my fb driver is just a copy of the old omapfb. It sounds my implementation is somewhat similar to yours. The DSS driver is not tied to fb or v4l interface, and offers ways to configure the displays and planes however you want.

I concentrated more on the the lower part than to fbdev or v4l, and more specifically I needed DSI support and multiple display support, while still retaining the old functionality. And with multiple displays I don't mean just an LCD and a TV-out, but, for example, two LCD's and tv-out. Configurations like one LCD connected to parallel output, updated with DISPC, and the other one connected to DSI and updated with CPU or system DMA. Or two displays connected to DSI.

I also wanted to be able to change the configuration on the fly, changing where DISPC output is going and which displays are updated with CPU or sDMA.

This is why I have the display-concept in my design.

I haven't made support for multiple users of the displays (like separate fb and v4l drivers), but I don't immediately see why it couldn't be done.

However, there are some questions regarding that, as the planes do not represent displays, but just overlay planes. What happens when both fb and v4l drivers want to change the resolution or timings of the display?

Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace.

Quoted 2 lines

Thanks and Regards,
Hardik

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

We more concentrated on TV and LCD interface, out design doesn't support DSI as of now. As mentioned earlier it is easily extendible to support DSI.

If I understand your implementation correctly, right now there is no way you can switch the outputs, I mean to say from LCD to DVI. The frame buffer driver gets the handle with API omap_dss_get_display, which will return pointer to omap_display for panel-sdp3430. Henceforth all your functions will use omap_display configuring for LCD panel. How are you planning to add support for this? Through some ioctls or sysfs entry? How about switching between multiple overlay managers?

This issue has been addresses with our design, you can change the output either to TV, LCD or to DVI through sysfs entry. Switching between multiple overlay managers is very well supported in DSS library. Currently SYSFS is the user interface layer to control the overlay managers. But in future DSS library will easily be suitable to support media processor interface which is in concept phase right now. RFC for the media processor is at

http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-inside-a-media-device.html

Quoted 6 lines

I also wanted to be able to change the configuration on the fly, changing where DISPC output is going and which displays are updated with CPU or sDMA.

This is why I have the display-concept in my design.

Here we both are on same page, you have broken the displays and modes supported into multiple files registering functions to the display.c file, there are many loopholes though.

Quoted 4 lines

I haven't made support for multiple users of the displays (like separate fb and v4l drivers), but I don't immediately see why it couldn't be done.

How are you going to handle the concurrency between these two?

Quoted 11 lines

However, there are some questions regarding that, as the planes do not represent displays, but just overlay planes. What happens when both fb and v4l drivers want to change the resolution or timings of the display?

Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace.

Here are you saying application will have hardware specific support? Is this feasible?

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tomi Valkeinen
Sent: Monday, September 15, 2008 8:08 PM
To: Hiremath, Vaibhav
Cc: Shah, Hardik; [email protected]; [email protected]
Subject: RE: [PREVIEW] New display subsystem for OMAP2/3

Quoted 1 line · Vaibhav

We more concentrated on TV and LCD interface, out design doesn't support DSI as of now. As

mentioned earlier it is easily extendible to support DSI.

Quoted 2 lines

If I understand your implementation correctly, right now there is no way you can switch the

outputs, I mean to say from LCD to DVI. The frame buffer driver gets the handle with API omap_dss_get_display, which will return pointer to omap_display for panel-sdp3430. Henceforth all your functions will use omap_display configuring for LCD panel. How are you planning to add support for this? Through some ioctls or sysfs entry? How about switching between multiple overlay managers?

You can switch the outputs in the DSS driver. You can enable/disable displays individually, and configure the planes and or L4 pixel source for the display.

But yes, the fb driver does not support that currently.

One idea I had was to present each display with one framebuffer, so let's say we have 3 displays, we would have fb[0-2]. In addition to that, we would have two framebuffers for the video overlays. Only one of the displays can be updated with DISPC, so the overlays would appear there.

Then the display that is updated with DISPC could be changed on the fly to another one, but the framebuffer arrangement would stay the same (so fb0 would still be seen on display0, even if it's now updated with L4).

There's still the question how to manage the video overlays, in this scenario they would automatically move to other LCD's as the DISPC target is changed. Also the TV-out is problematic.

Quoted 1 line

This issue has been addresses with our design, you can change the output either to TV, LCD or to

DVI through sysfs entry. Switching between multiple overlay managers is very well supported in DSS library. Currently SYSFS is the user interface layer to control the overlay managers. But in future DSS library will easily be suitable to support media processor interface which is in concept phase right now. RFC for the media processor is at

Does your design support displays that are not updated with DISPC?

Your design has good points. I have to think about the overlay managers a bit more. Especially if in some future hardware there were more overlay managers instead of the current two.

Quoted 1 line

http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-inside-

a-media-device.html

Quoted 11 lines

Quoted 8 lines

I also wanted to be able to change the configuration on the fly, changing where DISPC output is going and which displays are updated with CPU or sDMA.

This is why I have the display-concept in my design.

Here we both are on same page, you have broken the displays and modes supported into multiple files

registering functions to the display.c file, there are many loopholes though.

Quoted 6 lines

Quoted 5 lines

I haven't made support for multiple users of the displays (like separate fb and v4l drivers), but I don't immediately see why it couldn't be done.

Quoted 1 line

How are you going to handle the concurrency between these two?

In the simple case of just an LCD and a TV-out, what are the concurrency problems? Each plane is independent of each other. Sure you need to check that the output is on if there's a plane enabled there and basic things like that. Are there some other issues I'm not seeing?

Quoted 12 lines

Quoted 11 lines

However, there are some questions regarding that, as the planes do not represent displays, but just overlay planes. What happens when both fb and v4l drivers want to change the resolution or timings of the display?

Also I still don't quite know how to present displays to user space. Currently my omapfb just uses the first display, and that's it. I think in the end the user (be it X server, or perhaps some entity over it), needs to have some understanding of what OMAP offers and how it can use the displays. And there probably needs to be some product spesific configuration regarding this in userspace.

Quoted 2 lines

Here are you saying application will have hardware specific support? Is this feasible?

I don't see any other way. The displays are not independent of each other. For example the OMAP3 SDP has LCD and DVI outputs. They can't be switched programmatically, but let's say it was possible. Only one of those displays can be enabled at time. If an application wants to use them both, it has to understand that they will not both work at the same time.

Or if there are two DSI displays, and one is updated with DISPC and the other via L4. The application has to know that a video overlay can only be used on the first display, or it has to exchange the DISPC/L4 updating order.

Of course this is product specific software and configuration, not something I'm planning to put in the driver. A normal application does not have to know anything about it. I was just bringing it up to demonstrate what must be possible.

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