30.11.2016, 18:44, "Jean-Francois Moine" <moinejf at free.fr>: > On Wed, 30 Nov 2016 11:52:25 +0200 > Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote: > >>  Hi Jean-François, >> >>  On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote: >>  > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote: >>  > >> Well, I don't see what this connector can be. >>  > >> May you give me a DT example? >>  > > >>  > > Sure. >>  > > >>  > > arch/arm/boot/dts/r8a7791-koelsch.dts >>  > > >>  > > /* HDMI encoder */ > >         [snip] >>  > > /* HDMI connector */ >>  > > >>  > > hdmi-out { >>  > > compatible = "hdmi-connector"; >>  > > type = "a"; >>  > > >>  > > port { >>  > > hdmi_con: endpoint { >>  > > remote-endpoint = <&adv7511_out>; >>  > > }; >>  > > }; >>  > > }; > >         [snip] >>  > - what does the software do with the connector type? >> >>  That's up to the software to decide, the DT bindings should describe the >>  hardware in the most accurate and usable way for the OS as possible. One >> of my >>  longer term goals is to add connector drivers to handle DDC and HPD when >>  they're not handled by the encoder (they are in the above example). >> >>  If the DDC was connected to a general-purpose I2C bus of the SoC, and the >> HPD >>  to a GPIO, we would have >> >>          hdmi-out { >>                  compatible = "hdmi-connector"; >>                  type = "a"; >>                  /* I2C bus and GPIO references are made up >> for the example */ >>                  ddc-i2c-bus = <&i2c4>; >>                  hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH> >> >>                  port { >>                          hdmi_con: endpoint { >>                                  >> remote-endpoint = <&adv7511_out>; >>                          }; >>                  }; >>          }; >> >>  and both HPD and EDID reading should be handled by the connector driver. > >         [snip] > > Hi Laurent, > > OK. I understand. This connector complexity should be added in all DTs, > and the same code would be used. > > Actually, for component binding, I use drm_of_component_probe(): > > - from the DRM master, loop on the "ports" phandle array and bind the >   CRTCs, > > - for each CRTC, loop on the first remote port level and bind the >   encoders/connectors > > Now, this should be: > > - from the DRM master, loop on the first remote ports level and bind >   the CRTCs, > > - for each CRTC, loop on the second remote port level and bind the >   encoders (and bridges?), > > - for each encoder, loop on the third remote port level and bind the >   connectors. > > Then, it would be nice to have a generic function for doing this job. > > Otherwise, from your description: > >>          hdmi-out { >>                  compatible = "hdmi-connector"; >>                  type = "a"; >>                  /* I2C bus and GPIO references are made up >> for the example */ >>                  ddc-i2c-bus = <&i2c4>; >>                  hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH> > > the "hdmi-connector" is a big piece of software. It must handle a lot > of more and more exotic connectors. > So, I hope that you have written a "simple-hdmi-connector" which does > nothing but setting the connector type. > Where is it?
I suddenly thought about something... If a DVI connector instead of a HDMI connector is soldered, how should such a device tree be written? How about solder a HDMI-to-VGA bridge on the board? (Maybe there should be "dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge" drivers?) > > -- > Ken ar c'hentañ | ** Breizh ha Linux atav! ** > Jef | http://moinejf.free.fr/ > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout.