Hi Jagan, On Wed, Nov 7, 2018 at 5:13 AM Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Oct 31, 2018 at 2:46 PM Julian Calaby <julian.calaby@xxxxxxxxx> wrote: > > > > Hi Jagan, > > > > On Wed, Oct 31, 2018 at 7:58 PM Chen-Yu Tsai <wens@xxxxxxxx> wrote: > > > > > > On Wed, Oct 31, 2018 at 4:53 PM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: > > > > > > > > On 26.10.2018 16:43, Jagan Teki wrote: > > > > > Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB > > > > > bridge panel, which is available on same PCB with 24-bit RGB interface. > > > > > > > > > > So, this patch adds DSI specific binding details on existing > > > > > dt-bindings file. > > > > > > > > > > Signed-off-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> > > > > > --- > > > > > Changes for v3: > > > > > - Use existing binding doc and update dsi details > > > > > Changes for v2: > > > > > - none > > > > > > > > > > .../display/panel/bananapi,s070wv20-ct16.txt | 31 +++++++++++++++++-- > > > > > 1 file changed, 29 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > > > index 35bc0c839f49..b7855dc7c66f 100644 > > > > > --- a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > > > +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > > > @@ -1,12 +1,39 @@ > > > > > Banana Pi 7" (S070WV20-CT16) TFT LCD Panel > > > > > > > > > > +S070WV20-CT16 is 7" 800x480 panel connected through a 24-bit RGB interface. > > > > > + > > > > > +Depending on the variant, the PCB attached to the panel module either > > > > > +supports DSI, or DSI + 24-bit RGB. DSI is converted to 24-bit RGB via > > > > > +an onboard ICN6211 MIPI DSI - RGB bridge chip, then fed to the panel > > > > > +itself > > > > > > > > As I understand this is display board, which contains 'pure' RGB panel > > > > S070WV20-CT16 and optionally ICN6211 DSI->RGB bridge. > > > > These are separate devices, just connected by vendor to simplify its > > > > assembly. Why don't you create then bridge driver for ICN6211 and RGB > > > > panel driver for S070WV20-CT16 - it looks more generic. > > > > Then you can describe both in dts and voila. > > > > Creating drivers for every combo of devices (panel + bridge), just > > > > because some vendor sells them together seems incorrect - we have > > > > devicetree for it. > > > > > > Rob suggested this, and also the opposite: using the same > > > "bananapi,s070wv20-ct16" > > > compatible string for both types of connections, and have the driver deal with > > > detecting the bus type. > > > > > > The thing about the bridge chip is that there's no available datasheet that > > > describes all the parts of the init sequence, in fact none at all. I managed > > > to work out some bits, but the others remain a mystery and must be hard-coded > > > to match the panel. That would work against having a generic bridge driver. > > > > To me it seems logical that we'd model it as another step in the graph > > between the DSI component and the panel. It's conceivable that some > > other manufacturer will probably buy these for their panels and having > > a somewhat generic driver seems vaguely future proof to me. > > > > As I see it, the weird init process belongs to the bridge chip and the > > timings belong to the panel and we shouldn't "confuse" them by giving > > them the same compatible. > > But the problem here is due to lack of information about the panel, > the init process command opcode data values seem to based on the panel > timings values. This look weird and ie reason for going into separate > panel driver with different compatible. I'd missed that particular wrinkle. In that case, it makes sense to produce a panel driver with the bridge chip's compatible. Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/
