Re:?==?utf-8?q? [PATCH?==?utf-8?q? 3/5] Documentation/devicetree/bindings: Add b850v3_lvds_dp
Peter Senna Tschudin
peter.senna at collabora.co.uk
Thu Jun 2 16:19:35 PDT 2016
Thank you very much for the review! I'll send V2 soon, doing my best to avoid collisions with other patches that are under review.
On Thursday, June 2, 2016 14:49 CEST, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Hi Peter,
> Am Montag, den 30.05.2016, 18:39 +0200 schrieb Peter Senna Tschudin:
> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > display bridge.
> > Signed-off-by: Peter Senna Tschudin <peter.senna at collabora.com>
> > ---
> > .../devicetree/bindings/ge/b850v3_lvds_dp.txt | 38 ++++++++++++++++++++++
> > 1 file changed, 38 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3_lvds_dp.txt
> > diff --git a/Documentation/devicetree/bindings/ge/b850v3_lvds_dp.txt b/Documentation/devicetree/bindings/ge/b850v3_lvds_dp.txt
> > new file mode 100644
> > index 0000000..32e123a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ge/b850v3_lvds_dp.txt
> > @@ -0,0 +1,38 @@
> > +Driver for GE B850v3 LVDS/DP++ display bridge
> > +
> > +Required properties:
> > + - compatible : should be "ge,b850v3_lvds_dp".
> In the cover mail you write that this is a combination of the STDP4028
> DP transmitter and STDP2690 DP/DP++ converter. So shouldn't this binding
> comprise two device tree nodes, one with compatible "st,stdp4028", one
> with "st,stdp2690", then?
> Is the stdp2690 connected to the stdp4028's i2c master?
The hardware and firmware made it complicated for this binding to comprise two device tree nodes. The hardware and firmware are designed to configure both bridges based on the LVDS signal. This part works very well, but it leave the driver powerless to control the video processing pipeline. The bridges sort of behave as a single bridge, the sort of part is the need of interacting with both bridges: EDID from the STDP2690 and HPD events from the STDP4028. So the driver is only needed for telling the host about EDID / HPD, and for giving the host powers to ack interrupts.
I would find it nicer to be author of two drivers instead of one, but as the behavior handled by the driver is specific of the B850v3, and do not reflect the standard behavior of each bridge, I find it unlikely that the driver could be useful to handle STDP4028 and STPD2690 with stock firmware, or in other designs. On the other hand, I made sure to use the chip name on the defines to maximize chances of reuse.
More information about the linux-arm-kernel