RE: [PREVIEW] New display subsystem for OMAP2/3

RE: [PREVIEW] New display subsystem for OMAP2/3

[Hiremath, Vaibhav]

Tomi,

Have you got a chance to review the DSS library and V4l2 driver which we have posted?


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

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Monday, September 15, 2008 9:51 PM
> To: 'Tomi Valkeinen'
> Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> 
> 
> 
> Thanks,
> Vaibhav Hiremath
> Senior Software Engg.
> Platform Support Products
> Texas Instruments Inc
> Ph: +91-80-25099927
> TI IP Ph: 509-9927
> http://dbdwss01.india.ti.com/pspproducts/
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tomi
> > Valkeinen
> > Sent: Monday, September 15, 2008 8:08 PM
> > To: Hiremath, Vaibhav
> > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> >
> > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote:
> >
> > > 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?
> >
> > 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.
> >
> > > 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?
> 
> Yes, it should. I don't see any reason why it should fail if the display is completely independent.
> 
> >
> > 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.
> >
> 
> Let me take this opportunity, shortly I will post the DSS library and V4L2 driver. We can work
> together to add support for DSI, RFBI and SDI support to it.
> 
> > > http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-
> inside-
> > a-media-device.html
> > >
> > >
> > > > 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.
> > >
> > > > 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?
> >
> > 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?
> >
> 
> Yes some of the features of the DSS are tied to overlay managers and not the individual planes like
> global alpha, alpha blending enabling and timing parameters. So while programming of these parameters
> DSS library will have to maintain the data structures for the same and then any high level drivers
> can query those data structures.
> 
> > > > 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?
> > >
> >
> > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

Hi Vaibhav,

On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote:
> Tomi,
> 
> Have you got a chance to review the DSS library and V4l2 driver which we have posted?

Unfortunately not very much. I've been glancing the DSS side of the
driver, but not the v4l side as I don't know much about it.

There seems to be awfully lot ifdefs for board/cpu types in the code.
Also there are strange things defined, like L4_VIRT

My biased and superficial view of the differences between my DSS and
yours is that:
- My implementation is cleaner, better organized and more generic
- My implementation has support for DSI, SDI, RFBI, L4 updates
- Your implementation has better support for "extra" things like VRFB,
color conversions, alpha etc.
- Your implementation most likely has better power management support.
- And of course what is most visible to the user, my version uses only
framebuffers, and yours uses also v4l2 devices.

As for the future, I have no choice but to keep using my DSS as we need
the features it has. I feel it would be quite a big job to get those in
to your driver. And even if I had a choice, I (unsurprisingly =) think
that my version is better and would stick to it.

Have you had time to look at my code after I changed the overlay
handling? I've put the most recent version to a public git tree at
http://www.bat.org/~tomba/git/linux-omap-dss.git/ and I'll try to keep
that up to date. 

 Tomi

> 
> Thanks,
> Vaibhav Hiremath
> Senior Software Engg.
> Platform Support Products
> Texas Instruments Inc
> Ph: +91-80-25099927
> 
> > -----Original Message-----
> > From: Hiremath, Vaibhav
> > Sent: Monday, September 15, 2008 9:51 PM
> > To: 'Tomi Valkeinen'
> > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > 
> > 
> > 
> > Thanks,
> > Vaibhav Hiremath
> > Senior Software Engg.
> > Platform Support Products
> > Texas Instruments Inc
> > Ph: +91-80-25099927
> > TI IP Ph: 509-9927
> > http://dbdwss01.india.ti.com/pspproducts/
> > 
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tomi
> > > Valkeinen
> > > Sent: Monday, September 15, 2008 8:08 PM
> > > To: Hiremath, Vaibhav
> > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > >
> > > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote:
> > >
> > > > 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?
> > >
> > > 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.
> > >
> > > > 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?
> > 
> > Yes, it should. I don't see any reason why it should fail if the display is completely independent.
> > 
> > >
> > > 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.
> > >
> > 
> > Let me take this opportunity, shortly I will post the DSS library and V4L2 driver. We can work
> > together to add support for DSI, RFBI and SDI support to it.
> > 
> > > > http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-
> > inside-
> > > a-media-device.html
> > > >
> > > >
> > > > > 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.
> > > >
> > > > > 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?
> > >
> > > 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?
> > >
> > 
> > Yes some of the features of the DSS are tied to overlay managers and not the individual planes like
> > global alpha, alpha blending enabling and timing parameters. So while programming of these parameters
> > DSS library will have to maintain the data structures for the same and then any high level drivers
> > can query those data structures.
> > 
> > > > > 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?
> > > >
> > >
> > > 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 majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: [PREVIEW] New display subsystem for OMAP2/3

[Hiremath, Vaibhav]

Hi Tomi,

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

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Thursday, October 02, 2008 1:55 PM
> To: Hiremath, Vaibhav
> Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> 
> Hi Vaibhav,
> 
> On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote:
> > Tomi,
> >
> > Have you got a chance to review the DSS library and V4l2 driver which we have posted?
> 
> Unfortunately not very much. I've been glancing the DSS side of the
> driver, but not the v4l side as I don't know much about it.
> 
> There seems to be awfully lot ifdefs for board/cpu types in the code.

As far as ifdefs are concerned, they are added to take care of OMAP2/3 variants. Especially you will find many instances of CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have VENC. As I have mentioned before, DSS library is designed to support both LCD, TV, and many more.

> Also there are strange things defined, like L4_VIRT
> 

You are right; the code requires little-bit cleaning. There are some macros defined which driver or library doesn't use. We are in the process of cleaning and soon will be posting patches.

> My biased and superficial view of the differences between my DSS and
> yours is that:

Tomi, here I differ from you. There should not be biased opinion. What we are looking here is a good design which will fulfill all our requirements/use case, like LCD, DVI, HDMI and TV for us and DSI, RFBI for you.

> - My implementation is cleaner, better organized and more generic

Again, here both of us will be having biased comments to support our own design, so I would prefer not to comment on this. Lets people on the community decide whose design is better.

> - My implementation has support for DSI, SDI, RFBI, L4 updates

DSI, SDI and RFBI are the modes, which we can add anytime to the system depending as per our requirement. 
It is again driven by use case; you have use cases for DSI, SDI and RFBI. We have for TV, DVI, HDMI and LCD, so we strongly concentrated on these. 

We can very well add these supports to DSS Library with minimal effort.

> - Your implementation has better support for "extra" things like VRFB,
> color conversions, alpha etc.
> - Your implementation most likely has better power management support.
> - And of course what is most visible to the user, my version uses only
> framebuffers, and yours uses also v4l2 devices.
> 

You really can't deny the V4L2 framework advantages over framebuffer, especially for streaming kind of applications. Looking towards the hardware features OMAP supports; we would really require to have such support/capabilities. Community is also in agreement for the V4L2 interface on OMAP-DSS.

Tony/Hans,
Your comments would be helpful here.

> As for the future, I have no choice but to keep using my DSS as we need
> the features it has. I feel it would be quite a big job to get those in
> to your driver. And even if I had a choice, I (unsurprisingly =) think
> that my version is better and would stick to it.
> 

It's your personal choice to stick to whichever code base you want, I don't want to comment on that. But what I believe is, with your design we are limiting ourselves from supporting most of the features which hardware provides. 

We can work together to add more support to DSS library. 

> Have you had time to look at my code after I changed the overlay
> handling? I've put the most recent version to a public git tree at
> http://www.bat.org/~tomba/git/linux-omap-dss.git/ and I'll try to keep that up to date.
> 

Definitely I will review this code base, and will appreciate if I found something good.

>  Tomi
> 
> >
> > Thanks,
> > Vaibhav Hiremath
> > Senior Software Engg.
> > Platform Support Products
> > Texas Instruments Inc
> > Ph: +91-80-25099927
> >
> > > -----Original Message-----
> > > From: Hiremath, Vaibhav
> > > Sent: Monday, September 15, 2008 9:51 PM
> > > To: 'Tomi Valkeinen'
> > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > >
> > >
> > >
> > > Thanks,
> > > Vaibhav Hiremath
> > > Senior Software Engg.
> > > Platform Support Products
> > > Texas Instruments Inc
> > > Ph: +91-80-25099927
> > > TI IP Ph: 509-9927
> > > http://dbdwss01.india.ti.com/pspproducts/
> > >
> > > > -----Original Message-----
> > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> Tomi
> > > > Valkeinen
> > > > Sent: Monday, September 15, 2008 8:08 PM
> > > > To: Hiremath, Vaibhav
> > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > > >
> > > > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote:
> > > >
> > > > > 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?
> > > >
> > > > 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.
> > > >
> > > > > 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?
> > >
> > > Yes, it should. I don't see any reason why it should fail if the display is completely
> independent.
> > >
> > > >
> > > > 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.
> > > >
> > >
> > > Let me take this opportunity, shortly I will post the DSS library and V4L2 driver. We can work
> > > together to add support for DSI, RFBI and SDI support to it.
> > >
> > > > > http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-
> > > inside-
> > > > a-media-device.html
> > > > >
> > > > >
> > > > > > 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.
> > > > >
> > > > > > 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?
> > > >
> > > > 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?
> > > >
> > >
> > > Yes some of the features of the DSS are tied to overlay managers and not the individual planes
> like
> > > global alpha, alpha blending enabling and timing parameters. So while programming of these
> parameters
> > > DSS library will have to maintain the data structures for the same and then any high level
> drivers
> > > can query those data structures.
> > >
> > > > > > 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?
> > > > >
> > > >
> > > > 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 majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

RE: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

Hi,

> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > Sent: Thursday, October 02, 2008 1:55 PM
> > To: Hiremath, Vaibhav
> > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > 
> > Hi Vaibhav,
> > 
> > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote:
> > > Tomi,
> > >
> > > Have you got a chance to review the DSS library and V4l2 driver which we have posted?
> > 
> > Unfortunately not very much. I've been glancing the DSS side of the
> > driver, but not the v4l side as I don't know much about it.
> > 
> > There seems to be awfully lot ifdefs for board/cpu types in the code.
> 
> As far as ifdefs are concerned, they are added to take care of OMAP2/3 variants. Especially you will find many instances of CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have VENC. As I have mentioned before, DSS library is designed to support both LCD, TV, and many more.

They make the code unclear. I have divided the functionality to separate
files, that can easily be left out. So for OMAP3410 I would just disable
the VENC config option. And then I can test for CONFIG_DSS_VENC, instead
of OMAP3410 || OMAP2410 || OMAPwhatnot. Of course you can't do this for
all things, but at least VENC is not one of these.

And all board specific code should, in my opinion, be in board files. I
don't have any board specific definitions in the DSS driver or the
LCD/controller drivers. (well, ok, there is something in the DSI driver,
it's still quite raw).

> > My biased and superficial view of the differences between my DSS and
> > yours is that:
> 
> Tomi, here I differ from you. There should not be biased opinion. What we are looking here is a good design which will fulfill all our requirements/use case, like LCD, DVI, HDMI and TV for us and DSI, RFBI for you.

Agreed. I was just pointing out that I haven't used enough time to study
your DSS to really comment on it, and that a coder tends to like his own
code =).

> > - My implementation is cleaner, better organized and more generic
> 
> Again, here both of us will be having biased comments to support our own design, so I would prefer not to comment on this. Lets people on the community decide whose design is better.
> 
> > - My implementation has support for DSI, SDI, RFBI, L4 updates
> 
> DSI, SDI and RFBI are the modes, which we can add anytime to the system depending as per our requirement. 
> It is again driven by use case; you have use cases for DSI, SDI and RFBI. We have for TV, DVI, HDMI and LCD, so we strongly concentrated on these. 
> 
> We can very well add these supports to DSS Library with minimal effort.

SDI is quite easy, but I wouldn't say adding RFBI and DSI is minimal
effort. DSI is quite complex in itself, and the manual update mode
changes how the DSS has to handle things.

> > - Your implementation has better support for "extra" things like VRFB,
> > color conversions, alpha etc.
> > - Your implementation most likely has better power management support.
> > - And of course what is most visible to the user, my version uses only
> > framebuffers, and yours uses also v4l2 devices.
> > 
> 
> You really can't deny the V4L2 framework advantages over framebuffer, especially for streaming kind of applications. Looking towards the hardware features OMAP supports; we would really require to have such support/capabilities. Community is also in agreement for the V4L2 interface on OMAP-DSS.

Well, I'm not the best one to comment on V4L2 as I don't know much about
it. But I remember seeing quite negative comments about V4L2 a while ago
in this or related mail thread, so I'm not yet ready to change to V4L2
camp.

The best option would be, of course, to have both =).

> Tony/Hans,
> Your comments would be helpful here.
> 
> > As for the future, I have no choice but to keep using my DSS as we need
> > the features it has. I feel it would be quite a big job to get those in
> > to your driver. And even if I had a choice, I (unsurprisingly =) think
> > that my version is better and would stick to it.
> > 
> 
> It's your personal choice to stick to whichever code base you want, I don't want to comment on that. But what I believe is, with your design we are limiting ourselves from supporting most of the features which hardware provides. 

Is the limiting factor here the missing V4L2 interface? Or something in
the core DSS driver? To my knowledge you can have all the HW features
supported with framebuffers, even though V4L2 device can perhaps make
the use easier for some applications.

Well, one thing comes to my mind, and it's sharing the framebuffer
memory between, for example, display and camera drivers. I believe you
can do that with V4L2. Something else?

> We can work together to add more support to DSS library.

Sure, I don't really care which version is accepted, as long as we get
all the features =). So if you see something usable in my code, just
take it and add to your version.

 Tomi

Re: [PREVIEW] New display subsystem for OMAP2/3

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [081003 16:26]:
> Hi,
> 
> > > -----Original Message-----
> > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > Sent: Thursday, October 02, 2008 1:55 PM
> > > To: Hiremath, Vaibhav
> > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > > 
> > > Hi Vaibhav,
> > > 
> > > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote:
> > > > Tomi,
> > > >
> > > > Have you got a chance to review the DSS library and V4l2 driver which we have posted?
> > > 
> > > Unfortunately not very much. I've been glancing the DSS side of the
> > > driver, but not the v4l side as I don't know much about it.
> > > 
> > > There seems to be awfully lot ifdefs for board/cpu types in the code.
> > 
> > As far as ifdefs are concerned, they are added to take care of OMAP2/3 variants. Especially you will find many instances of CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have VENC. As I have mentioned before, DSS library is designed to support both LCD, TV, and many more.
> 
> They make the code unclear. I have divided the functionality to separate
> files, that can easily be left out. So for OMAP3410 I would just disable
> the VENC config option. And then I can test for CONFIG_DSS_VENC, instead
> of OMAP3410 || OMAP2410 || OMAPwhatnot. Of course you can't do this for
> all things, but at least VENC is not one of these.
> 
> And all board specific code should, in my opinion, be in board files. I
> don't have any board specific definitions in the DSS driver or the
> LCD/controller drivers. (well, ok, there is something in the DSI driver,
> it's still quite raw).

Yeah we should be able to compile in any combination of omap boards with
whatever configuration from board-*.c files as platform_data.

So ifdefs will totally break this.

> > > My biased and superficial view of the differences between my DSS and
> > > yours is that:
> > 
> > Tomi, here I differ from you. There should not be biased opinion. What we are looking here is a good design which will fulfill all our requirements/use case, like LCD, DVI, HDMI and TV for us and DSI, RFBI for you.
> 
> Agreed. I was just pointing out that I haven't used enough time to study
> your DSS to really comment on it, and that a coder tends to like his own
> code =).
> 
> > > - My implementation is cleaner, better organized and more generic
> > 
> > Again, here both of us will be having biased comments to support our own design, so I would prefer not to comment on this. Lets people on the community decide whose design is better.
> > 
> > > - My implementation has support for DSI, SDI, RFBI, L4 updates
> > 
> > DSI, SDI and RFBI are the modes, which we can add anytime to the system depending as per our requirement. 
> > It is again driven by use case; you have use cases for DSI, SDI and RFBI. We have for TV, DVI, HDMI and LCD, so we strongly concentrated on these. 
> > 
> > We can very well add these supports to DSS Library with minimal effort.
> 
> SDI is quite easy, but I wouldn't say adding RFBI and DSI is minimal
> effort. DSI is quite complex in itself, and the manual update mode
> changes how the DSS has to handle things.
> 
> > > - Your implementation has better support for "extra" things like VRFB,
> > > color conversions, alpha etc.
> > > - Your implementation most likely has better power management support.
> > > - And of course what is most visible to the user, my version uses only
> > > framebuffers, and yours uses also v4l2 devices.
> > > 
> > 
> > You really can't deny the V4L2 framework advantages over framebuffer, especially for streaming kind of applications. Looking towards the hardware features OMAP supports; we would really require to have such support/capabilities. Community is also in agreement for the V4L2 interface on OMAP-DSS.
> 
> Well, I'm not the best one to comment on V4L2 as I don't know much about
> it. But I remember seeing quite negative comments about V4L2 a while ago
> in this or related mail thread, so I'm not yet ready to change to V4L2
> camp.
> 
> The best option would be, of course, to have both =).
> 
> > Tony/Hans,
> > Your comments would be helpful here.

I'd rather not get too involved in the fb or v4l stuff, I already have
enough things to look at. But I can certainly comment on stuff that will
break booting multiple omaps the same time once the patches are posted.

> > > As for the future, I have no choice but to keep using my DSS as we need
> > > the features it has. I feel it would be quite a big job to get those in
> > > to your driver. And even if I had a choice, I (unsurprisingly =) think
> > > that my version is better and would stick to it.
> > > 
> > 
> > It's your personal choice to stick to whichever code base you want, I don't want to comment on that. But what I believe is, with your design we are limiting ourselves from supporting most of the features which hardware provides. 
> 
> Is the limiting factor here the missing V4L2 interface? Or something in
> the core DSS driver? To my knowledge you can have all the HW features
> supported with framebuffers, even though V4L2 device can perhaps make
> the use easier for some applications.
> 
> Well, one thing comes to my mind, and it's sharing the framebuffer
> memory between, for example, display and camera drivers. I believe you
> can do that with V4L2. Something else?
> 
> > We can work together to add more support to DSS library.
> 
> Sure, I don't really care which version is accepted, as long as we get
> all the features =). So if you see something usable in my code, just
> take it and add to your version.

Regards,

Tony

RE: [PREVIEW] New display subsystem for OMAP2/3

[Hiremath, Vaibhav]

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

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Friday, October 03, 2008 7:04 PM
> To: Tomi Valkeinen
> Cc: Hiremath, Vaibhav; hverkuil@xs4all.nl; Shah, Hardik; linux-
> omap@vger.kernel.org; video4linux-list@redhat.com
> Subject: Re: [PREVIEW] New display subsystem for OMAP2/3
> 
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [081003 16:26]:
> > Hi,
> >
> > > > -----Original Message-----
> > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > > Sent: Thursday, October 02, 2008 1:55 PM
> > > > To: Hiremath, Vaibhav
> > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-
> list@redhat.com
> > > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > > >
> > > > Hi Vaibhav,
> > > >
> > > > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav
> wrote:
> > > > > Tomi,
> > > > >
> > > > > Have you got a chance to review the DSS library and V4l2
> driver which we have posted?
> > > >
> > > > Unfortunately not very much. I've been glancing the DSS side
> of the
> > > > driver, but not the v4l side as I don't know much about it.
> > > >
> > > > There seems to be awfully lot ifdefs for board/cpu types in
> the code.
> > >
> > > As far as ifdefs are concerned, they are added to take care of
> OMAP2/3 variants. Especially you will find many instances of
> CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't
> have VENC. As I have mentioned before, DSS library is designed to
> support both LCD, TV, and many more.
> >
> > They make the code unclear. I have divided the functionality to
> separate
> > files, that can easily be left out. So for OMAP3410 I would just
> disable
> > the VENC config option. And then I can test for CONFIG_DSS_VENC,
> instead
> > of OMAP3410 || OMAP2410 || OMAPwhatnot. Of course you can't do
> this for
> > all things, but at least VENC is not one of these.
> >
> > And all board specific code should, in my opinion, be in board
> files. I
> > don't have any board specific definitions in the DSS driver or the
> > LCD/controller drivers. (well, ok, there is something in the DSI
> driver,
> > it's still quite raw).
> 
> Yeah we should be able to compile in any combination of omap boards
> with
> whatever configuration from board-*.c files as platform_data.
> 
> So ifdefs will totally break this.
> 

Point taken, we will try to avoid ifdefs as much as possible and will divide depending on the functionality.

> > > > My biased and superficial view of the differences between my
> DSS and
> > > > yours is that:
> > >
> > > Tomi, here I differ from you. There should not be biased
> opinion. What we are looking here is a good design which will
> fulfill all our requirements/use case, like LCD, DVI, HDMI and TV
> for us and DSI, RFBI for you.
> >
> > Agreed. I was just pointing out that I haven't used enough time to
> study
> > your DSS to really comment on it, and that a coder tends to like
> his own
> > code =).
> >
> > > > - My implementation is cleaner, better organized and more
> generic
> > >
> > > Again, here both of us will be having biased comments to support
> our own design, so I would prefer not to comment on this. Lets
> people on the community decide whose design is better.
> > >
> > > > - My implementation has support for DSI, SDI, RFBI, L4 updates
> > >
> > > DSI, SDI and RFBI are the modes, which we can add anytime to the
> system depending as per our requirement.
> > > It is again driven by use case; you have use cases for DSI, SDI
> and RFBI. We have for TV, DVI, HDMI and LCD, so we strongly
> concentrated on these.
> > >
> > > We can very well add these supports to DSS Library with minimal
> effort.
> >
> > SDI is quite easy, but I wouldn't say adding RFBI and DSI is
> minimal
> > effort. DSI is quite complex in itself, and the manual update mode
> > changes how the DSS has to handle things.
> >
> > > > - Your implementation has better support for "extra" things
> like VRFB,
> > > > color conversions, alpha etc.
> > > > - Your implementation most likely has better power management
> support.
> > > > - And of course what is most visible to the user, my version
> uses only
> > > > framebuffers, and yours uses also v4l2 devices.
> > > >
> > >
> > > You really can't deny the V4L2 framework advantages over
> framebuffer, especially for streaming kind of applications. Looking
> towards the hardware features OMAP supports; we would really require
> to have such support/capabilities. Community is also in agreement
> for the V4L2 interface on OMAP-DSS.
> >
> > Well, I'm not the best one to comment on V4L2 as I don't know much
> about
> > it. But I remember seeing quite negative comments about V4L2 a
> while ago
> > in this or related mail thread, so I'm not yet ready to change to
> V4L2
> > camp.
> >
> > The best option would be, of course, to have both =).
> >
> > > Tony/Hans,
> > > Your comments would be helpful here.
> 
> I'd rather not get too involved in the fb or v4l stuff, I already
> have
> enough things to look at. But I can certainly comment on stuff that
> will
> break booting multiple omaps the same time once the patches are
> posted.
> 
> > > > As for the future, I have no choice but to keep using my DSS
> as we need
> > > > the features it has. I feel it would be quite a big job to get
> those in
> > > > to your driver. And even if I had a choice, I (unsurprisingly
> =) think
> > > > that my version is better and would stick to it.
> > > >
> > >
> > > It's your personal choice to stick to whichever code base you
> want, I don't want to comment on that. But what I believe is, with
> your design we are limiting ourselves from supporting most of the
> features which hardware provides.
> >
> > Is the limiting factor here the missing V4L2 interface? Or
> something in
> > the core DSS driver? To my knowledge you can have all the HW
> features
> > supported with framebuffers, even though V4L2 device can perhaps
> make
> > the use easier for some applications.
> >
> > Well, one thing comes to my mind, and it's sharing the framebuffer
> > memory between, for example, display and camera drivers. I believe
> you
> > can do that with V4L2. Something else?
> >
> > > We can work together to add more support to DSS library.
> >
> > Sure, I don't really care which version is accepted, as long as we
> get
> > all the features =). So if you see something usable in my code,
> just
> > take it and add to your version.
> 
> Regards,
> 
> Tony


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

RE: [PREVIEW] New display subsystem for OMAP2/3

[Shah, Hardik]

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Friday, October 03, 2008 7:46 PM
> To: Tony Lindgren; Tomi Valkeinen
> Cc: hverkuil@xs4all.nl; Shah, Hardik; linux-omap@vger.kernel.org; video4linux-
> list@redhat.com
> Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> 
> 
> 
> Thanks,
> Vaibhav Hiremath
> Senior Software Engg.
> Platform Support Products
> Texas Instruments Inc
> Ph: +91-80-25099927
> 
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Friday, October 03, 2008 7:04 PM
> > To: Tomi Valkeinen
> > Cc: Hiremath, Vaibhav; hverkuil@xs4all.nl; Shah, Hardik; linux-
> > omap@vger.kernel.org; video4linux-list@redhat.com
> > Subject: Re: [PREVIEW] New display subsystem for OMAP2/3
> >
> > * Tomi Valkeinen <tomi.valkeinen@nokia.com> [081003 16:26]:
> > > Hi,
> > >
> > > > > -----Original Message-----
> > > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > > > Sent: Thursday, October 02, 2008 1:55 PM
> > > > > To: Hiremath, Vaibhav
> > > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-
> > list@redhat.com
> > > > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> > > > >
> > > > > Hi Vaibhav,
> > > > >
> > > > > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav
> > wrote:
> > > > > > Tomi,
> > > > > >
> > > > > > Have you got a chance to review the DSS library and V4l2
> > driver which we have posted?
> > > > >
> > > > > Unfortunately not very much. I've been glancing the DSS side
> > of the
> > > > > driver, but not the v4l side as I don't know much about it.
> > > > >
> > > > > There seems to be awfully lot ifdefs for board/cpu types in
> > the code.
> > > >
> > > > As far as ifdefs are concerned, they are added to take care of
> > OMAP2/3 variants. Especially you will find many instances of
> > CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't
> > have VENC. As I have mentioned before, DSS library is designed to
> > support both LCD, TV, and many more.
> > >
> > > They make the code unclear. I have divided the functionality to
> > separate
> > > files, that can easily be left out. So for OMAP3410 I would just
> > disable
> > > the VENC config option. And then I can test for CONFIG_DSS_VENC,
> > instead
> > > of OMAP3410 || OMAP2410 || OMAPwhatnot. Of course you can't do
> > this for
> > > all things, but at least VENC is not one of these.
> > >
> > > And all board specific code should, in my opinion, be in board
> > files. I
> > > don't have any board specific definitions in the DSS driver or the
> > > LCD/controller drivers. (well, ok, there is something in the DSI
> > driver,
> > > it's still quite raw).
> >
> > Yeah we should be able to compile in any combination of omap boards
> > with
> > whatever configuration from board-*.c files as platform_data.
> >
> > So ifdefs will totally break this.
> >
> 
> Point taken, we will try to avoid ifdefs as much as possible and will divide
> depending on the functionality.
> 
> > > > > My biased and superficial view of the differences between my
> > DSS and
> > > > > yours is that:
> > > >
> > > > Tomi, here I differ from you. There should not be biased
> > opinion. What we are looking here is a good design which will
> > fulfill all our requirements/use case, like LCD, DVI, HDMI and TV
> > for us and DSI, RFBI for you.
> > >
> > > Agreed. I was just pointing out that I haven't used enough time to
> > study
> > > your DSS to really comment on it, and that a coder tends to like
> > his own
> > > code =).
> > >
> > > > > - My implementation is cleaner, better organized and more
> > generic
> > > >
> > > > Again, here both of us will be having biased comments to support
> > our own design, so I would prefer not to comment on this. Lets
> > people on the community decide whose design is better.
> > > >
> > > > > - My implementation has support for DSI, SDI, RFBI, L4 updates
> > > >
> > > > DSI, SDI and RFBI are the modes, which we can add anytime to the
> > system depending as per our requirement.
> > > > It is again driven by use case; you have use cases for DSI, SDI
> > and RFBI. We have for TV, DVI, HDMI and LCD, so we strongly
> > concentrated on these.
> > > >
> > > > We can very well add these supports to DSS Library with minimal
> > effort.
> > >
> > > SDI is quite easy, but I wouldn't say adding RFBI and DSI is
> > minimal
> > > effort. DSI is quite complex in itself, and the manual update mode
> > > changes how the DSS has to handle things.
> > >
> > > > > - Your implementation has better support for "extra" things
> > like VRFB,
> > > > > color conversions, alpha etc.
> > > > > - Your implementation most likely has better power management
> > support.
> > > > > - And of course what is most visible to the user, my version
> > uses only
> > > > > framebuffers, and yours uses also v4l2 devices.
> > > > >
> > > >
> > > > You really can't deny the V4L2 framework advantages over
> > framebuffer, especially for streaming kind of applications. Looking
> > towards the hardware features OMAP supports; we would really require
> > to have such support/capabilities. Community is also in agreement
> > for the V4L2 interface on OMAP-DSS.
> > >
> > > Well, I'm not the best one to comment on V4L2 as I don't know much
> > about
> > > it. But I remember seeing quite negative comments about V4L2 a
> > while ago
> > > in this or related mail thread, so I'm not yet ready to change to
> > V4L2
> > > camp.
> > >
> > > The best option would be, of course, to have both =).
> > >
> > > > Tony/Hans,
> > > > Your comments would be helpful here.
> >
> > I'd rather not get too involved in the fb or v4l stuff, I already
> > have
> > enough things to look at. But I can certainly comment on stuff that
> > will
> > break booting multiple omaps the same time once the patches are
> > posted.
> >
> > > > > As for the future, I have no choice but to keep using my DSS
> > as we need
> > > > > the features it has. I feel it would be quite a big job to get
> > those in
> > > > > to your driver. And even if I had a choice, I (unsurprisingly
> > =) think
> > > > > that my version is better and would stick to it.
> > > > >
> > > >
> > > > It's your personal choice to stick to whichever code base you
> > want, I don't want to comment on that. But what I believe is, with
> > your design we are limiting ourselves from supporting most of the
> > features which hardware provides.
> > >
> > > Is the limiting factor here the missing V4L2 interface? Or
> > something in
> > > the core DSS driver? To my knowledge you can have all the HW
> > features
> > > supported with framebuffers, even though V4L2 device can perhaps
> > make
> > > the use easier for some applications.
> > >
> > > Well, one thing comes to my mind, and it's sharing the framebuffer
> > > memory between, for example, display and camera drivers. I believe
> > you
> > > can do that with V4L2. Something else?
> > >
> > > > We can work together to add more support to DSS library.
> > >
> > > Sure, I don't really care which version is accepted, as long as we
> > get
> > > all the features =). So if you see something usable in my code,
> > just
> > > take it and add to your version.

Hi All,
I will be posting the version 2 of the DSS library and V4L2 display driver 
with almost all the comments from the community taken care of.
It will be series of 4 patches containing

OMAP 2/3 DSS Library
OMAP3 EVM TV encoder Driver.
New IOCTLS added to V4L2 Framework (Already posted on V4L2 mailing list)
OMAP 2/3 V4L2 Display driver on the Video planes of DSS hardware.

We are enhancing the DSS library.  This is the first post containing the
features like power management, video pipeline, Digital overlay manager,
clock management support.

Further plan is to add graphics pipeline, LCD overlay manager, RFBI, DSI,
support and frame buffer interface for graphics pipeline

Please let us know your comments on further enhancements of the DSS Library
and V4L2 display driver.

Thanks and Regards,
Hardik Shah> > Regards,
> >
> > Tony

Re: [PREVIEW] New display subsystem for OMAP2/3

[Hans Verkuil]

Hi Vaibhav,

Hmm, this is getting quite confusing for me :-)

If I understand it correctly, TI posted two patches while I was on 
vacation: one for the DSS library and one for the V4L2 driver. I 
quickly looked at the DSS library patch, but I cannot really comment on 
that one as it is very omap specific, so as far as I am concerned it is 
pretty much up to TI to decide how to set this up. If I understand it 
correctly the DSS 'library' basically provides v4l2/fb drivers with the 
low-level platform functionality those drivers need. So I'm not sure 
whether 'library' is really the right term here. 'DSS platform code' is 
more appropriate.

I definitely have questions regarding the V4L2 driver, but I'll reply to 
that patch separately.

I also understand that there is an alternative DSS implementation from 
Tomi? But I can't seem to find any link to that code. A link to the 
code would be appreciated.

Regarding v4l2 vs fb: the normal way such things are implemented is that 
the V4L2 API is used for video streaming while the FB API is used to 
interface to displays and/or menu overlays. The FB API is a natural fit 
for graphics applications like X and Qt, whereas the V4L2 API is meant 
to handle video streaming in an efficient manner and with correct 
timings. You can be creative and use a FB device to stream video or a 
V4L2 device for graphics/overlay output, but you only make it hard on 
yourself and the application writers.

Regards,

	Hans

On Friday 03 October 2008 14:47:23 Hiremath, Vaibhav wrote:
> Hi Tomi,
>
> Thanks,
> Vaibhav Hiremath
> Senior Software Engg.
> Platform Support Products
> Texas Instruments Inc
> Ph: +91-80-25099927
>
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > Sent: Thursday, October 02, 2008 1:55 PM
> > To: Hiremath, Vaibhav
> > Cc: Shah, Hardik; linux-omap@vger.kernel.org;
> > video4linux-list@redhat.com Subject: RE: [PREVIEW] New display
> > subsystem for OMAP2/3
> >
> > Hi Vaibhav,
> >
> > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote:
> > > Tomi,
> > >
> > > Have you got a chance to review the DSS library and V4l2 driver
> > > which we have posted?
> >
> > Unfortunately not very much. I've been glancing the DSS side of the
> > driver, but not the v4l side as I don't know much about it.
> >
> > There seems to be awfully lot ifdefs for board/cpu types in the
> > code.
>
> As far as ifdefs are concerned, they are added to take care of
> OMAP2/3 variants. Especially you will find many instances of
> CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have
> VENC. As I have mentioned before, DSS library is designed to support
> both LCD, TV, and many more.
>
> > Also there are strange things defined, like L4_VIRT
>
> You are right; the code requires little-bit cleaning. There are some
> macros defined which driver or library doesn't use. We are in the
> process of cleaning and soon will be posting patches.
>
> > My biased and superficial view of the differences between my DSS
> > and yours is that:
>
> Tomi, here I differ from you. There should not be biased opinion.
> What we are looking here is a good design which will fulfill all our
> requirements/use case, like LCD, DVI, HDMI and TV for us and DSI,
> RFBI for you.
>
> > - My implementation is cleaner, better organized and more generic
>
> Again, here both of us will be having biased comments to support our
> own design, so I would prefer not to comment on this. Lets people on
> the community decide whose design is better.
>
> > - My implementation has support for DSI, SDI, RFBI, L4 updates
>
> DSI, SDI and RFBI are the modes, which we can add anytime to the
> system depending as per our requirement. It is again driven by use
> case; you have use cases for DSI, SDI and RFBI. We have for TV, DVI,
> HDMI and LCD, so we strongly concentrated on these.
>
> We can very well add these supports to DSS Library with minimal
> effort.
>
> > - Your implementation has better support for "extra" things like
> > VRFB, color conversions, alpha etc.
> > - Your implementation most likely has better power management
> > support. - And of course what is most visible to the user, my
> > version uses only framebuffers, and yours uses also v4l2 devices.
>
> You really can't deny the V4L2 framework advantages over framebuffer,
> especially for streaming kind of applications. Looking towards the
> hardware features OMAP supports; we would really require to have such
> support/capabilities. Community is also in agreement for the V4L2
> interface on OMAP-DSS.
>
> Tony/Hans,
> Your comments would be helpful here.
>
> > As for the future, I have no choice but to keep using my DSS as we
> > need the features it has. I feel it would be quite a big job to get
> > those in to your driver. And even if I had a choice, I
> > (unsurprisingly =) think that my version is better and would stick
> > to it.
>
> It's your personal choice to stick to whichever code base you want, I
> don't want to comment on that. But what I believe is, with your
> design we are limiting ourselves from supporting most of the features
> which hardware provides.
>
> We can work together to add more support to DSS library.
>
> > Have you had time to look at my code after I changed the overlay
> > handling? I've put the most recent version to a public git tree at
> > http://www.bat.org/~tomba/git/linux-omap-dss.git/ and I'll try to
> > keep that up to date.
>
> Definitely I will review this code base, and will appreciate if I
> found something good.
>
> >  Tomi
> >
> > > Thanks,
> > > Vaibhav Hiremath
> > > Senior Software Engg.
> > > Platform Support Products
> > > Texas Instruments Inc
> > > Ph: +91-80-25099927
> > >
> > > > -----Original Message-----
> > > > From: Hiremath, Vaibhav
> > > > Sent: Monday, September 15, 2008 9:51 PM
> > > > To: 'Tomi Valkeinen'
> > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org;
> > > > video4linux-list@redhat.com Subject: RE: [PREVIEW] New display
> > > > subsystem for OMAP2/3
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Vaibhav Hiremath
> > > > Senior Software Engg.
> > > > Platform Support Products
> > > > Texas Instruments Inc
> > > > Ph: +91-80-25099927
> > > > TI IP Ph: 509-9927
> > > > http://dbdwss01.india.ti.com/pspproducts/
> > > >
> > > > > -----Original Message-----
> > > > > From: linux-omap-owner@vger.kernel.org
> > > > > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> >
> > Tomi
> >
> > > > > Valkeinen
> > > > > Sent: Monday, September 15, 2008 8:08 PM
> > > > > To: Hiremath, Vaibhav
> > > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org;
> > > > > video4linux-list@redhat.com Subject: RE: [PREVIEW] New
> > > > > display subsystem for OMAP2/3
> > > > >
> > > > > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav 
wrote:
> > > > > > 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?
> > > >
> > > > > 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.
> > > > >
> > > > > > 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?
> > > >
> > > > Yes, it should. I don't see any reason why it should fail if
> > > > the display is completely
> >
> > independent.
> >
> > > > > 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.
> > > >
> > > > Let me take this opportunity, shortly I will post the DSS
> > > > library and V4L2 driver. We can work together to add support
> > > > for DSI, RFBI and SDI support to it.
> > > >
> > > > > > http://lists-archives.org/video4linux/23652-rfc-add-support
> > > > > >-to-query-and-change-connections-
> > > >
> > > > inside-
> > > >
> > > > > a-media-device.html
> > > > >
> > > > > > > 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.
> > > > >
> > > > > > > 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?
> > > > >
> > > > > 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?
> > > >
> > > > Yes some of the features of the DSS are tied to overlay
> > > > managers and not the individual planes
> >
> > like
> >
> > > > global alpha, alpha blending enabling and timing parameters. So
> > > > while programming of these
> >
> > parameters
> >
> > > > DSS library will have to maintain the data structures for the
> > > > same and then any high level
> >
> > drivers
> >
> > > > can query those data structures.
> > > >
> > > > > > > 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?
> > > > >
> > > > > 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
> > > > > majordomo@vger.kernel.org
> > > > > More majordomo info at 
> > > > > http://vger.kernel.org/majordomo-info.html


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

Hi,

On Fri, 2008-10-03 at 16:03 +0200, ext Hans Verkuil wrote:
> Hi Vaibhav,
> 
> Hmm, this is getting quite confusing for me :-)
> 
> If I understand it correctly, TI posted two patches while I was on 
> vacation: one for the DSS library and one for the V4L2 driver. I 
> quickly looked at the DSS library patch, but I cannot really comment on 
> that one as it is very omap specific, so as far as I am concerned it is 
> pretty much up to TI to decide how to set this up. If I understand it 
> correctly the DSS 'library' basically provides v4l2/fb drivers with the 
> low-level platform functionality those drivers need. So I'm not sure 
> whether 'library' is really the right term here. 'DSS platform code' is 
> more appropriate.
> 
> I definitely have questions regarding the V4L2 driver, but I'll reply to 
> that patch separately.
> 
> I also understand that there is an alternative DSS implementation from 
> Tomi? But I can't seem to find any link to that code. A link to the 
> code would be appreciated.

I've only sent it to linux-omap list for now. I'm planning to send it to
fbdev-devel list sometime in the near future.

Here are my mails:

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

The link to the implementation is a bit old, since then I've set up a
public repo at http://www.bat.org/~tomba/git/linux-omap-dss.git/

But most of that code is also very omap specific =).

> Regarding v4l2 vs fb: the normal way such things are implemented is that 
> the V4L2 API is used for video streaming while the FB API is used to 
> interface to displays and/or menu overlays. The FB API is a natural fit 
> for graphics applications like X and Qt, whereas the V4L2 API is meant 
> to handle video streaming in an efficient manner and with correct 
> timings. You can be creative and use a FB device to stream video or a 
> V4L2 device for graphics/overlay output, but you only make it hard on 
> yourself and the application writers.

That has been my understanding. OMAP has three overlays (gfx, vid1,
vid2) but I wouldn't want to dedicate vid1/2 overlays to V4L2 devices,
because often you want to use them the same way as the gfx overlay, and
framebuffer fits that better (for example, having a UI on the LCD and
TV-out at the same time).

So if and when I add V4L2 support, I'd like the choice between FB and
V4L2 to be configurable per overlay. Perhaps just compile time
configuration, but still. 

> Regards,
> 
> 	Hans

Tomi


> On Friday 03 October 2008 14:47:23 Hiremath, Vaibhav wrote:
> > Hi Tomi,
> >
> > Thanks,
> > Vaibhav Hiremath
> > Senior Software Engg.
> > Platform Support Products
> > Texas Instruments Inc
> > Ph: +91-80-25099927
> >
> > > -----Original Message-----
> > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > Sent: Thursday, October 02, 2008 1:55 PM
> > > To: Hiremath, Vaibhav
> > > Cc: Shah, Hardik; linux-omap@vger.kernel.org;
> > > video4linux-list@redhat.com Subject: RE: [PREVIEW] New display
> > > subsystem for OMAP2/3
> > >
> > > Hi Vaibhav,
> > >
> > > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote:
> > > > Tomi,
> > > >
> > > > Have you got a chance to review the DSS library and V4l2 driver
> > > > which we have posted?
> > >
> > > Unfortunately not very much. I've been glancing the DSS side of the
> > > driver, but not the v4l side as I don't know much about it.
> > >
> > > There seems to be awfully lot ifdefs for board/cpu types in the
> > > code.
> >
> > As far as ifdefs are concerned, they are added to take care of
> > OMAP2/3 variants. Especially you will find many instances of
> > CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have
> > VENC. As I have mentioned before, DSS library is designed to support
> > both LCD, TV, and many more.
> >
> > > Also there are strange things defined, like L4_VIRT
> >
> > You are right; the code requires little-bit cleaning. There are some
> > macros defined which driver or library doesn't use. We are in the
> > process of cleaning and soon will be posting patches.
> >
> > > My biased and superficial view of the differences between my DSS
> > > and yours is that:
> >
> > Tomi, here I differ from you. There should not be biased opinion.
> > What we are looking here is a good design which will fulfill all our
> > requirements/use case, like LCD, DVI, HDMI and TV for us and DSI,
> > RFBI for you.
> >
> > > - My implementation is cleaner, better organized and more generic
> >
> > Again, here both of us will be having biased comments to support our
> > own design, so I would prefer not to comment on this. Lets people on
> > the community decide whose design is better.
> >
> > > - My implementation has support for DSI, SDI, RFBI, L4 updates
> >
> > DSI, SDI and RFBI are the modes, which we can add anytime to the
> > system depending as per our requirement. It is again driven by use
> > case; you have use cases for DSI, SDI and RFBI. We have for TV, DVI,
> > HDMI and LCD, so we strongly concentrated on these.
> >
> > We can very well add these supports to DSS Library with minimal
> > effort.
> >
> > > - Your implementation has better support for "extra" things like
> > > VRFB, color conversions, alpha etc.
> > > - Your implementation most likely has better power management
> > > support. - And of course what is most visible to the user, my
> > > version uses only framebuffers, and yours uses also v4l2 devices.
> >
> > You really can't deny the V4L2 framework advantages over framebuffer,
> > especially for streaming kind of applications. Looking towards the
> > hardware features OMAP supports; we would really require to have such
> > support/capabilities. Community is also in agreement for the V4L2
> > interface on OMAP-DSS.
> >
> > Tony/Hans,
> > Your comments would be helpful here.
> >
> > > As for the future, I have no choice but to keep using my DSS as we
> > > need the features it has. I feel it would be quite a big job to get
> > > those in to your driver. And even if I had a choice, I
> > > (unsurprisingly =) think that my version is better and would stick
> > > to it.
> >
> > It's your personal choice to stick to whichever code base you want, I
> > don't want to comment on that. But what I believe is, with your
> > design we are limiting ourselves from supporting most of the features
> > which hardware provides.
> >
> > We can work together to add more support to DSS library.
> >
> > > Have you had time to look at my code after I changed the overlay
> > > handling? I've put the most recent version to a public git tree at
> > > http://www.bat.org/~tomba/git/linux-omap-dss.git/ and I'll try to
> > > keep that up to date.
> >
> > Definitely I will review this code base, and will appreciate if I
> > found something good.
> >
> > >  Tomi
> > >
> > > > Thanks,
> > > > Vaibhav Hiremath
> > > > Senior Software Engg.
> > > > Platform Support Products
> > > > Texas Instruments Inc
> > > > Ph: +91-80-25099927
> > > >
> > > > > -----Original Message-----
> > > > > From: Hiremath, Vaibhav
> > > > > Sent: Monday, September 15, 2008 9:51 PM
> > > > > To: 'Tomi Valkeinen'
> > > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org;
> > > > > video4linux-list@redhat.com Subject: RE: [PREVIEW] New display
> > > > > subsystem for OMAP2/3
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Vaibhav Hiremath
> > > > > Senior Software Engg.
> > > > > Platform Support Products
> > > > > Texas Instruments Inc
> > > > > Ph: +91-80-25099927
> > > > > TI IP Ph: 509-9927
> > > > > http://dbdwss01.india.ti.com/pspproducts/
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: linux-omap-owner@vger.kernel.org
> > > > > > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> > >
> > > Tomi
> > >
> > > > > > Valkeinen
> > > > > > Sent: Monday, September 15, 2008 8:08 PM
> > > > > > To: Hiremath, Vaibhav
> > > > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org;
> > > > > > video4linux-list@redhat.com Subject: RE: [PREVIEW] New
> > > > > > display subsystem for OMAP2/3
> > > > > >
> > > > > > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav 
> wrote:
> > > > > > > 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?
> > > > >
> > > > > > 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.
> > > > > >
> > > > > > > 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?
> > > > >
> > > > > Yes, it should. I don't see any reason why it should fail if
> > > > > the display is completely
> > >
> > > independent.
> > >
> > > > > > 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.
> > > > >
> > > > > Let me take this opportunity, shortly I will post the DSS
> > > > > library and V4L2 driver. We can work together to add support
> > > > > for DSI, RFBI and SDI support to it.
> > > > >
> > > > > > > http://lists-archives.org/video4linux/23652-rfc-add-support
> > > > > > >-to-query-and-change-connections-
> > > > >
> > > > > inside-
> > > > >
> > > > > > a-media-device.html
> > > > > >
> > > > > > > > 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.
> > > > > >
> > > > > > > > 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?
> > > > > >
> > > > > > 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?
> > > > >
> > > > > Yes some of the features of the DSS are tied to overlay
> > > > > managers and not the individual planes
> > >
> > > like
> > >
> > > > > global alpha, alpha blending enabling and timing parameters. So
> > > > > while programming of these
> > >
> > > parameters
> > >
> > > > > DSS library will have to maintain the data structures for the
> > > > > same and then any high level
> > >
> > > drivers
> > >
> > > > > can query those data structures.
> > > > >
> > > > > > > > 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?
> > > > > >
> > > > > > 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
> > > > > > majordomo@vger.kernel.org
> > > > > > More majordomo info at 
> > > > > > http://vger.kernel.org/majordomo-info.html
> 
> 

[PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

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

-- 

RE: [PREVIEW] New display subsystem for OMAP2/3

[Shah, Hardik]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tomi
> Valkeinen
> Sent: Thursday, September 11, 2008 8:26 PM
> To: linux-omap@vger.kernel.org
> 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
> 
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/linux-omap@vger.kernel.org/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.

Below is the link to our implementation which we were about to post as mentioned in the RFC posted earlier. Please have a look at this.

https://omapzoom.org/gf/project/omapkernel/docman/?subdir=10

Following are the important features of the DSS library.  Detail design about the DSS library is also available under above link.

1. 	Display library will be the master controlling the DSS hardware. Any driver
	required to configure the DSS registers should call the DSS library APIs.
2. 	Display library includes modular functions for programming the video and
	graphics pipeline of the DSS independently of the framework (V4L2 and FBDEV)
	used.
3. 	Display library includes functions for controlling the clock management and
	interrupt management. Since these functionalities is shared between the
	individual pipelines and individual pipelines may be controlled by different
	drivers (V4L2 and FBDEV). Display library will maintain the reference count and
	necessary data structures for concurrency handling.
4. 	Display library has interface for registering and deregistering the encoders
	attached with the overlay managers.
5. 	Display library includes functions for selecting the output and standards. Based
	on the output selected display library will select the active encoder from the
	registered encoders.
6. 	Display library supports programming of the overlay managers registers
	depending upon the output and mode selected. It will maintain the data
	structures for overlay manager parameters as the overlay managers are shared
	between the pipelines.
7. 	Display library supports saving and restoring of the context for power
	management.
8. 	Display library is easily extendable to add the DSI, SDI and RFBI functionality 
	supported by DSS Hardware.

Let us work together to get a best design out for OMAP2/3 DSS.


Thanks and Regards,
Hardik


> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PREVIEW] New display subsystem for OMAP2/3

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote:
> 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.

> 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/linux-omap@vger.kernel.org/msg02510.html

I like this proposal a lot better, but I think fbdev + v4l is not a
great plan.  Have you looked at DRM modesetting drivers?

Cheers,
Daniel

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PREVIEW] New display subsystem for OMAP2/3

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]


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

> On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote:
>> 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.

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

regards,

Koen

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PREVIEW] New display subsystem for OMAP2/3

[Måns Rullgård]

Koen Kooi <k.kooi@student.utwente.nl> writes:

> Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:
>
>> On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote:
>>> 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.
>
> 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.

-- 
Måns Rullgård
mans@mansr.com

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

RE: [PREVIEW] New display subsystem for OMAP2/3

[Shah, Hardik]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Måns
> Rullgård
> Sent: Sunday, September 14, 2008 3:18 AM
> To: linux-omap@vger.kernel.org
> Cc: video4linux-list@redhat.com
> Subject: Re: [PREVIEW] New display subsystem for OMAP2/3
> 
> Koen Kooi <k.kooi@student.utwente.nl> writes:
> 
> > Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:
> >
> >> On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote:
> >>> 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.
> >
> > 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.

Our DSS library is inline with the above model suggested by you.  Following is the link containing DSS library code and small design document, which currently handles only video pipeline.  The next immediate goal is to add the support for graphics pipeline functionality.  

https://omapzoom.org/gf/project/omapkernel/docman/?subdir=10

 

Thanks and Regards,
Hardik Shah

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote:
> Koen Kooi <k.kooi@student.utwente.nl> writes:
> 
> > Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:
> >
> >> On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote:
> >>> 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.
> >
> > 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.

Yes, that was my idea while implementing the driver.

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

 Tomi

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

Re: [PREVIEW] New display subsystem for OMAP2/3

[Måns Rullgård]

Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

> On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote:
>> Koen Kooi <k.kooi@student.utwente.nl> writes:
>> 
>> > Op 12 sep 2008, om 17:29 heeft Daniel Stone het volgende geschreven:
>> >
>> >> On Fri, Sep 12, 2008 at 07:59:44PM +0530, ext Shah, Hardik wrote:
>> >>> 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.
>> >
>> > 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.
>
> Yes, that was my idea while implementing the driver.
>
>> 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.

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.

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

Fair enough.  Migrating the old display drivers one by one makes
sense, and when all are done, we can drop the old fb driver.

-- 
Måns Rullgård
mans@mansr.com

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

Re: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote:
> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:
> 
> > On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote:
> >> Koen Kooi <k.kooi@student.utwente.nl> 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.
> 
> 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).

 Tomi


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

Re: [PREVIEW] New display subsystem for OMAP2/3

[Måns Rullgård]

Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

> On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote:
>> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:
>> 
>> > On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote:
>> >> Koen Kooi <k.kooi@student.utwente.nl> 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.
>> 
>> 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).

I don't like working on old code.  It inevitably leads to wasting time
re-doing things that have already been done in the latest version.

-- 
Måns Rullgård
mans@mansr.com

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

RE: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

On Fri, 2008-09-12 at 19:59 +0530, ext Shah, Hardik wrote:
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tomi
> > Valkeinen
> > Sent: Thursday, September 11, 2008 8:26 PM
> > To: linux-omap@vger.kernel.org
> > 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/linux-omap@vger.kernel.org/msg02510.html

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

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

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.

> Thanks and Regards,
> Hardik

 Tomi

RE: [PREVIEW] New display subsystem for OMAP2/3

[Shah, Hardik]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Monday, September 15, 2008 4:38 PM
> To: Shah, Hardik
> Cc: linux-omap@vger.kernel.org; video4linux-list@redhat.com
> Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> 
> On Fri, 2008-09-12 at 19:59 +0530, ext Shah, Hardik wrote:
> >
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> Tomi
> > > Valkeinen
> > > Sent: Thursday, September 11, 2008 8:26 PM
> > > To: linux-omap@vger.kernel.org
> > > 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/linux-omap@vger.kernel.org/msg02510.html
> 
> Ah, I seem to have missed these, I was on my summer holidays at that
> time =). I'll study those.
> 
> >
> > 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.
> 
> 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.
> 
We have the implementation for the V4L2 as well as the FBDEV driver on the DSS library.  Although FBDEV driver is not in the shape to be posted to open source lists.

> 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
DSS library is easily extendible to add DSI, RFBI, SDI support.

> 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.
> 
DSS library gives the flexibility to change to add the as many overlay managers or as many encoder on the overlay manager.

> 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?
> 
The controls of the display library which are shared between the pipelines like the timing parameters, panel width, panel height can be configured through the sysfs entries.  It will be something like  "echo ntsc_m > /sys/class/display_control/standard".  DSS library maintains the data structures and individual userspace drivers can query these controls for setting their parameters dependent on these controls.

> 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.
> > Thanks and Regards,
> > Hardik
> 
>  Tomi
> 

RE: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

Hi,

On Mon, 2008-09-15 at 17:22 +0530, ext Shah, Hardik wrote:
> 
> DSS library gives the flexibility to change to add the as many overlay managers or as many encoder on the overlay manager.

Is an encoder here the same as an output from DISPC? So OMAP2 and 3 have
two encoders, the tv-out and lcd out?

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

That is true, and that's why the default mode should be something
"normal". However, if there are two LCDs on the device, someone has to
understand that only one of them can be updated with DISPC (and thus can
have the overlays), and the other is just a plain framebuffer. 

An application doesn't probably have to understand this, but some
display manager entity has. So this is only needed for HW that is
something else than the normal one LCD device.

Tomi

Re: [PREVIEW] New display subsystem for OMAP2/3

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Mon, Sep 15, 2008 at 02:07:34PM +0300, ext Tomi Valkeinen wrote:
> 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.

All of which sound very poorly suited to fbdev and very well suited to
DRM modesetting. :)

Cheers,
Daniel

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: [PREVIEW] New display subsystem for OMAP2/3

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath
Senior Software Engg.
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
TI IP Ph: 509-9927
http://dbdwss01.india.ti.com/pspproducts/

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tomi
> Valkeinen
> Sent: Monday, September 15, 2008 4:38 PM
> To: Shah, Hardik
> Cc: linux-omap@vger.kernel.org; video4linux-list@redhat.com
> Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> 
> On Fri, 2008-09-12 at 19:59 +0530, ext Shah, Hardik wrote:
> >
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
> Tomi
> > > Valkeinen
> > > Sent: Thursday, September 11, 2008 8:26 PM
> > > To: linux-omap@vger.kernel.org
> > > 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/linux-omap@vger.kernel.org/msg02510.html
> 
> Ah, I seem to have missed these, I was on my summer holidays at that
> time =). I'll study those.
> 
> >
> > 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.
> 
> 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.
> 

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


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

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

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

> > Thanks and Regards,
> > Hardik
> 
>  Tomi
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PREVIEW] New display subsystem for OMAP2/3

[Tomi Valkeinen]

On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote:

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

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.

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

> http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-inside-a-media-device.html
> 
> 
> > 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.
> 
> > 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?

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?

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

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

RE: [PREVIEW] New display subsystem for OMAP2/3

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath
Senior Software Engg.
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
TI IP Ph: 509-9927
http://dbdwss01.india.ti.com/pspproducts/

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tomi
> Valkeinen
> Sent: Monday, September 15, 2008 8:08 PM
> To: Hiremath, Vaibhav
> Cc: Shah, Hardik; linux-omap@vger.kernel.org; video4linux-list@redhat.com
> Subject: RE: [PREVIEW] New display subsystem for OMAP2/3
> 
> On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote:
> 
> > 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?
> 
> 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.
> 
> > 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?

Yes, it should. I don't see any reason why it should fail if the display is completely independent.

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

Let me take this opportunity, shortly I will post the DSS library and V4L2 driver. We can work together to add support for DSI, RFBI and SDI support to it.

> > http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-inside-
> a-media-device.html
> >
> >
> > > 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.
> >
> > > 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?
> 
> 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?
> 

Yes some of the features of the DSS are tied to overlay managers and not the individual planes like global alpha, alpha blending enabling and timing parameters. So while programming of these parameters DSS library will have to maintain the data structures for the same and then any high level drivers can query those data structures.

> > > 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?
> >
> 
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html