* Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> [081003 16:26]: > Hi, > > > > -----Original Message----- > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > > > Sent: Thursday, October 02, 2008 1:55 PM > > > To: Hiremath, Vaibhav > > > Cc: Shah, Hardik; linux-omap@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx > > > 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 -- 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
