On Fri, Jan 15, 2010 at 12:07 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> wrote: > 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. Pandora's TPO display supports mirroring (vertical and horizontal), and also several resolutions. It would be nice to have this functionality accessible somehow. > 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. Good luck then, I should be able to do some testing as needed. > > 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
