On Tue, Oct 23, 2018 at 4:11 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > On Mon, Oct 22, 2018 at 5:22 AM Chen-Yu Tsai <wens@xxxxxxxx> wrote: > > > > Hi Rob, > > > > On Mon, Oct 15, 2018 at 7:24 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > On Thu, 27 Sep 2018 17:18:47 +0530, Jagan Teki wrote: > > > > Bananapi S070WV20-CT16 is 800x480, 4-lane MIPI-DSI panel, the > > > > same panel PCB comes with parallel RBG which is supported via > > > > panel-simple with "bananapi,s070wv20-ct16" compatible. > > > > > > > > Signed-off-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> > > > > --- > > > > .../panel/bananapi,s070wv20-ct16-dsi.txt | 21 +++++++++++++++++++ > > > > 1 file changed, 21 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16-dsi.txt > > > > > > > > > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > > > > This "panel" is actually an RGB panel with a MIPI-DSI-to-RGB bridge > > tacked on. On one particular revision of this module, one can also > > directly use the RGB interface. > > > > Would it be better to model this as bridge+panel? We already have > > a binding for the RGB version [1]. This would make it harder to > > make a driver though, as there is no publicly available datasheet > > for the bridge chip, so it's likely that part of the init sequence > > would have to be hard-coded. > > Perhaps you can use the same compatible and detect based on the OF > graph connection whether it is DSI or RGB interface? That would mean > the RGB version doesn't use simple-panel driver, but that should be > okay. I think that would work. > If there's other users of this bridge chip, then modeling the bridge > separately would be better. I doubt we'd find it. And given that there are no docs for the init sequence, even though we could make out some parts, it will always be a partially binary sequence tied to the compatible for the panel. Thanks ChenYu
