Thread (7 messages) flat view 7 messages, 3 authors, 2012-01-27

Re: [PATCH] fbdev: sh_mipi_dsi: add extra settings method for platform

From: Magnus Damm <magnus.damm@gmail.com>
Date: 2012-01-24 10:44:13

On Tue, Jan 24, 2012 at 7:09 PM, Laurent Pinchart
[off-list ref] wrote:
On Tuesday 24 January 2012 01:48:55 Kuninori Morimoto wrote:
quoted
Hi Laurent
Cc Magnus, Guennadi

Thank you for checking patch
You're welcome.
quoted
quoted
quoted
+ 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help