On Tue, Jan 24, 2012 at 7:09 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Tuesday 24 January 2012 01:48:55 Kuninori Morimoto wrote: >> Hi Laurent >> Cc Magnus, Guennadi >> >> Thank you for checking patch > > You're welcome. > >> > > + void (*set_dcs)(int handle, >> > > + int (*mipi_dcs)(int handle, u8 cmd), >> > > + int (*mipi_dcs_param)(int handle, u8 cmd, u8 param)); >> > >> > I don't think this is a good idea. First of all, we should reduce the >> > number of board code callbacks to make transition to the device tree >> > easier. Then, passing two functions to board code to read and write any >> > device register without the driver having any knowledge about that is a >> > clear violation of the device model, and will result in problems sooner >> > or later. >> > >> > What MIPI settings do platforms need to modify ? Can those settings be >> > expressed as data in the sh_mipi_dsi_info structure instead ? >> >> Hmm... now I'm in dilemma. >> Actually this is v2 patch for mipi display. >> (v1 patch was dropped since merge window issue) >> >> The v1 patch was data-table style for mipi display initialization. >> (if platform had init data-table, driver used it) >> >> But someone reviewed it and teach me that it is not-good idea. >> So, I created this style in v2. >> >> Now platform needs "backlight ON" and "memory write ON" command, >> but I could not find these command on include/video/mipi_display.h. >> So, I thought it is platform specific command. > > Why does the platform need that ? Please correct me if I'm wrong, but it seems > to me that what you're trying to do is configure and control the display > panel. I don't think that's platform-specific, it should be panel-specific > instead. It looks to me like the right solution would be to write a display > panel driver, similar to what is done for the OMAP2+ platform > (drivers/video/omap2/displays). I think that it is a very good recommendation to solve this in theory, but in practice we've never really seen anyone use the same LCD module and/or on-glass LCD controller for another board. What I've done so far is to write the part number of the LCD module together with LCD controller part number and hopefully also LCD panel configuration together with the register settings so it is possible to search and consolidate at some point when we have multiple users. I'm not sure about this particular case, but I've seen quite much code that just has a set of LCD controller register settings without documentation, and it's kind of hard to turn that into a proper driver. Especially since these register settings are both related to the on-module LCD controller and LCD panel that together form a LCD module. We usually don't know which setting is for what part. And we probably would like to abstract the module into separate pieces of code for different parts. I've seen some data sheet of a on-module LCD controller and it was about 800 pages I believe, so it's not exactly something you can cook up in an afternoon. And add closed MIPI specs and all sorts of fun and this can take forever. =) That aside, it would be really nice to see some proper drivers for LCD modules. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
