Hi Jacopo, On Sat, Mar 09, 2019 at 12:23:08PM +0100, Jacopo Mondi wrote: > On Fri, Mar 08, 2019 at 07:57:39PM +0200, Laurent Pinchart wrote: > > On Fri, Mar 08, 2019 at 05:49:25PM +0100, Jacopo Mondi wrote: > >> On Thu, Mar 07, 2019 at 01:23:35AM +0200, Laurent Pinchart wrote: > >>> The THC63LVD1024 LVDS decoder can operate in two modes, single-link or > >>> dual-link. In dual-link mode both input ports are used to carry even- > >>> and odd-numbered pixels separately. Document this in the DT bindings, > >>> along with the related rules governing port and usage. > >>> > >>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> > >>> --- > >>> .../bindings/display/bridge/thine,thc63lvd1024.txt | 7 +++++++ > >>> 1 file changed, 7 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>> index 37f0c04d5a28..4ff6eb9bbc19 100644 > >>> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>> @@ -28,6 +28,13 @@ Optional video port nodes: > >>> - port@1: Second LVDS input port > >>> - port@3: Second digital CMOS/TTL parallel output > >>> > >>> +The device can operate in single-link mode or dual-link mode. In single-link > >>> +mode, all pixels are received on port@0, and port@1 shall not contain any > >>> +endpoint. In dual-link mode, even-numbered pixels are received on port@0 and > >>> +odd-numbered pixels on port@1, and both port@0 and port@1 shall contain > >>> +endpoints. > >> > >> You know, I'm not sure this is helpful, as if we have to go and > >> describe what the chip supports, a paragraph for dual ouput mode would > >> be required as well. The bindings already document that the chip > >> supports single/dual input/output modes, maybe you can just add rules > >> that prescribes how to populate the endpoints, for both input and > >> output modes? > > > > That's what I was trying to do :-) How else would you like to see it > > described ? > > I wonder if it won't be enough to expand the Optional endpoint > properties description as in: > > - port@1: Second LVDS input port, to be used for dual-input mode > - port@3: Second digital CMOS/TTL parallel output, to be used for > dual-output mode. I think it's useful to explain the constraints regarding presence (or absence) of endpoints for ports 0 and 1 depending on which mode the device operates under, not just what the ports are used for. > If you prefer providing more context, it's fine what you had, just > keep in mind there's also dual-output mode and not just the dual-input > one. Absolutely. The reason why I haven't expanded the bindings to document dual-output mode is that I have no way to test it, and I don't think untested bindings (meaning without a testable end-to-end implementation) are a good idea. > Up to you, feel free to add my > Reviewed-by: Jacopo Mondi <jacopo+renesas@xxxxxxxxxx> > if relevant. > > >>> + > >>> + > >> > >> You can drop this empty line. > >> > >>> Example: > >>> -------- > >>> -- Regards, Laurent Pinchart
