On Thu, 2010-01-14 at 21:59 +0100, ext Grazvydas Ignotas wrote: > Hi, > > there is an issue related to panel drivers: > even if panel driver provides get_rotate/set_rotate and/or > get_mirror/set_mirror functions, those cannot be accessed over sysfs, > even though corresponding entries are created in omapdss/displayX. > This is because panel driver fills omap_dss_driver structure, but > sysfs entries are created for omap_dss_device when it probes. So > perhaps those pointers need to be copied from omap_dss_driver to > omap_dss_device somewhere in dss_driver_probe(). If you look at dsi.c, you'll see how it currently works. So it's the job of the interface (dpi, sdi, rfbi or dsi) to act as a intermediary, and call the functions in the driver. Rotate and mirror aren't implemented in dpi and sdi, as I don't know any displays that could use them. But if there are such displays, dpi.c can either just copy the driver's function in to the device struct, or implement an intermediary function of its own. That said, I'm actually in the process of changing the driver/device model a bit. My aim is that all the calls (from omapfb, sysfs etc) go directly to the driver code, which then will call necessary functions in the dss to accomplish its goal. It was foolish of me to design the model the way it's now, but my reasoning was that all the displays of certain type must be very similar, and thus it's easier for everyone if the dss driver is in control. I coulnd't have been more wrong =). Especially the more complex DSI peripherals are unique, and the only solution is to let the driver be in total control. But more of that later, when I have something working. 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
