> -----Original Message----- > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > Sent: Tuesday, November 04, 2008 9:40 PM > To: linux-fbdev-devel@xxxxxxxxxxxxxxxxxxxxx > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description > > New Display Subsystem for OMAP2/3 > --------------------------------- > > This patch set implements new Display Subsystem (DSS) for OMAP2/3 processors. > The DSS is still under work and these patches are for review. Note that there > is also another new DSS implementation from TI. > > The DSS has been tested on OMAP3 SDP board, Beagle Board and on two unreleased > boards with DSI and SDI displays. The DSS used to work on OMAP2 board also, > but > it's been a while since I was able to test with OMAP2 board. > > The first patch is a doc file that tries to explain a bit how the drivers > work. > > The patch set is based on the current linux-omap tree. > > You can find the patches also from a git tree at > http://www.bat.org/~tomba/git/linux-omap-dss.git/ > > Note that you also need two patches from Mans Rullgard to make things work. > These > are needed to be able to reconfigure DSS functional clock. > http://git.mansr.com/?p=linux- > omap;a=commit;h=e2de5e5578fbaa9b4b75074796da0608fc93e6ae > http://git.mansr.com/?p=linux- > omap;a=commit;h=2b7b958dc79e51127d7a4ecf88ce12dbc6c31426 > > Questions/problems > ------------------ > > Perhaps the biggest problems I have is the interface to user space. OMAP > hardware doesn't quite fit in to the framebuffer framework. The problem is > that > a framebuffer can go to multiple overlays, and also the target display, to > which a framebuffer goes, can change. In addition, the framebuffer size is > used as overlay size, not display resolution. So a framebuffer != display. > > I believe DRM modesetting could be of help here, at least partially, but I > haven't tried that approach yet. > > But DRM modesetting wouldn't solve all the problems. For example, we still > need > to configure overlays and overlay managers, and they don't quite belong to > either the framebuffer side or the display side. Currently you configure them > via a hackish sysfs interface, but I've been wondering if a /dev/omap-dss > device with ioctls would be a better choice. > > There's currently no V4L2 support, but I have been thinking about that. I > don't > want to make any hardcoded configuration for those, because sometimes you want > to use framebuffer devices for video overlays. So what I'd like to have is a > way, compile time or run time, to configure which overlays go to framebuffer > devices and which go to V4L2 devices. > [Shah, Hardik] Hi Tomi, We are successful to bring up the basic functionality of the V4L2 driver onto your patches. We will be posting those patches in a day or two. Based on our V4L2 driver development we have few questions/suggestions on DSS patches you submitted. 1. Display enable function is returning false if the display is already enabled. Instead it should just return without error if display is already enabled as V4L2 and fbdev both may be enabling it without each other's knowledge. 2. Second display enable/disable should maintain the reference count as disabling of the display by one driver will leave other driver without display. 3. I think the row increment value should not be calculate inside the dispc.c file instead high level driver will pass the value it requires based on his buffer requirement and dispc.c should program it dumbly. This is mainly due to the odd row_inc_value requirement for the VRFB space. 4. There is API in dispc.c file to change pixel increment value. 5. We need separate API to enable the plane and enable the clocks. Once the clock is enabled driver can directly go and program registers through low level dispc APIs instead of dispc APIs enabling the clock for each register programming and then disabling it. This will avoid the enabling and disabling of the clocks for each frame displayed. As for V4L2 interface driver will enable planes and clocks during VIDIOC_STREAMON ioctls and during the streaming it will just change the buffer address for displaying frames. This way delay between the enabling/disabling of the clocks can also be saved. It would be driver's responsibility to enable the clocks before programming any registers. Same may be true for setting the GO bit of the respective overlay managers. 6. We also need a public API to program the color conversion values. Some application may need to program it differently than standard values. Thanks and Regards, Hardik Shah Vaibhav Hiremath > -- > Tomi Valkeinen > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Linux-fbdev-devel mailing list > Linux-fbdev-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel -- 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
