Re: [PATCH 09/12] dt-bindings: panel: Add Bananapi S070WV20-CT16 MIPI-DSI panel bindings - Chen-Yu Tsai

From: Chen-Yu Tsai <wens@csie.org>
To: Rob Herring <robh@kernel.org>, Jagan Teki <jagan@amarulasolutions.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
	Icenowy Zheng <icenowy@aosc.io>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Vasily Khoruzhick <anarsoul@gmail.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Michael Trimarchi <michael@amarulasolutions.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-sunxi@googlegroups.com
Subject: Re: [PATCH 09/12] dt-bindings: panel: Add Bananapi S070WV20-CT16 MIPI-DSI panel bindings
Date: Wed, 24 Oct 2018 21:22:30 +0100	[thread overview]
Message-ID: <CAGb2v64euJCAZvyGFL+pr+CLQfY8ypnhRAJFKZQ9xGai6RvLDQ@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqJPn9hhGsk62RzLc1dPQyF2_iCSau+MvY9mD_QADybgvg@mail.gmail.com>

On Tue, Oct 23, 2018 at 4:11 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Oct 22, 2018 at 5:22 AM Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > Hi Rob,
> >
> > On Mon, Oct 15, 2018 at 7:24 PM Rob Herring <robh@kernel.org> 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@amarulasolutions.com>
> > > > ---
> > > >  .../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@kernel.org>
> >
> > 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