Hi Jacopo, Thanks for your work. On 2018-05-29 17:05:57 +0200, Jacopo Mondi wrote: > Document the boolean custom property 'renesas,hsync-as-de' that indicates > that the HSYNC signal is internally used as data-enable, when the > CLKENB signal is not connected. > > As this is a VIN specificity create a custom property specific to the R-Car > VIN driver. > > Signed-off-by: Jacopo Mondi <jacopo+renesas@xxxxxxxxxx> > --- > v3: > - new patch > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt > index ff53226..024c109 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -60,6 +60,9 @@ from local SoC CSI-2 receivers (port1) depending on SoC. > - vsync-active: see [1] for description. Default is active high. > - data-enable-active: polarity of CLKENB signal, see [1] for > description. Default is active high. > + - renesas,hsync-as-de: a boolean property to indicate that HSYNC signal > + is internally used as data-enable when the CLKENB signal is > + not available. I'm not sure I like this, is there really a need to add a custom property for this? The datasheet states that when the CLKENB pin is not connected the driver should enable 'Clock Enable Hsync Select (CHS)'. With the new generic property 'data-enable-active' which describes the polarity of the CLKENB pin we also gain the knowledge if the CLKENB pin is connected or not. I propose we drop this custom property and instead let the driver check if the CLKENB polarity is described or not and use that to determine if CHS bit should be set or not. IMHO that is much simpler then having two properties describing the same pin. > > If both HSYNC and VSYNC polarities are not specified, embedded > synchronization is selected. > -- > 2.7.4 > -- Regards, Niklas Söderlund
