Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> writes: > 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. 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@xxxxxxxxx -- 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
