On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote: > Koen Kooi <k.kooi@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
