Hi Jyri,
On Thursday 10 Nov 2016 11:16:53 Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
> > On Wednesday 02 Nov 2016 18:32:16 Jyri Sarha wrote:
> >> Add very basic ti-ftp410 HDMI transmitter driver. The only feature
> >> separating this from a completely dummy bridge is the DDC i2c
> >> support. However, other HW specific features may be added later when
> >> needed. For instance there is a set of registers behind i2c if it is
> >> connected. The implementations is tested against my new tilcdc bridge
> >> support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
> >> document is also added.
> >>
> >> Signed-off-by: Jyri Sarha <jsarha@xxxxxx>
> >> ---
> >>
> >> .../bindings/display/bridge/ti,tfp410.txt | 30 ++++
> >> drivers/gpu/drm/bridge/Kconfig | 7 +
> >> drivers/gpu/drm/bridge/Makefile | 1 +
> >> drivers/gpu/drm/bridge/ti-tfp410.c | 199 +++++++++++++++
> >> 4 files changed, 237 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file
> >> mode 100644
> >> index 0000000..dc93713
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> @@ -0,0 +1,30 @@
> >> +TFP410 HDMI/DVI bridge bindings
> >
> > I'd name the document "TI TFP410 DVI Transmitter". DVI bridge doesn't tell
> > whether the device is a receiver or transmitter.
> >
> >> +Required properties:
> >> + - compatible: "ti,tfp410"
> >
> > The device is an I2C slave, it should have a reg property. Given that the
> > chip can be used without being controlled through I2C, the reg property
> > should be optional. You should document this clearly, and explain how the
> > DT node can be instantiated as a child of an I2C controller when the I2C
> > interface is used, or in other parts of the device tree otherwise.
> >
> >> +Optional properties:
> >> + - ddc-i2c: phandle of an I2C controller used for DDC EDID probing
> >
> > The TFP410 doesn't handle DDC, this property should be part of the
> > connector node.
> >
> >> +Optional subnodes:
> >> + - video input: this subnode can contain a video input port node
> >> + to connect the bridge to a display controller output (See this
> >> + documentation [1]).
> >
> > You also need an output port for the DVI output. Those two ports should be
> > required, not optional.
>
> Ok. So I need another device node. Should I create some specific
> compatible string for connectors behind tfp410, or a generic DVI/HDMI
> connector with optional ddc-i2c phandle?
The generic DVI/HDMI connector bindings should work fine.
> The implementation side is not so critical, because it more easily
> changed, but should I create an independent generic platform-device
> driver for such DVI/HDMI connector or just implement the connector side
> within tfp410 driver?
Longer term I'd like to go for connector drivers, but it might take a bit of
infrastructure work. If you can give it a try it would be great ! Otherwise
I'm fine with handling that in the tfp410 driver for now.
> >> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >> +
> >> +Example:
> >> + hdmi-bridge {
> >> + compatible = "ti,tfp410";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@0 {
> >> + reg = <0>;
> >> + bridge_in: endpoint {
> >> + remote-endpoint = <&dc_out>;
> >> + };
> >> + };
> >> + };
> >> + };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
