Hi Hugues, On Tue, Oct 20, 2020 at 12:14:49PM +0200, Hugues Fruchet wrote: > Add support of BT656 parallel bus mode in DCMI. > This mode is enabled when hsync-active & vsync-active > fields are not specified. > > Signed-off-by: Hugues Fruchet <hugues.fruchet@xxxxxx> > --- > .../devicetree/bindings/media/st,stm32-dcmi.yaml | 30 ++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > index 3fe778c..1ee521a 100644 > --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > @@ -44,6 +44,36 @@ properties: > bindings defined in > Documentation/devicetree/bindings/media/video-interfaces.txt. > > + properties: > + endpoint: > + type: object > + > + properties: > + bus-width: true > + > + hsync-active: > + description: > + If both HSYNC and VSYNC polarities are not specified, BT656 > + embedded synchronization is selected. > + default: 0 > + > + vsync-active: > + description: > + If both HSYNC and VSYNC polarities are not specified, BT656 > + embedded synchronization is selected. > + default: 0 Should I understand this as if the polarities were not specified, BT.656 will be used? The bindings previously documented BT.601 (parallel) only, so it was somewhat ambigious to begin with. Is there a risk of interpreting old BT.601 bindings as BT.656? With bus-type property, I believe you could avoid at least that risk. Also not specifying at least one of the default values leads to BT.656 without bus-type. That could be addressed by removing the defaults. > + > + pclk-sample: true > + > + remote-endpoint: true > + > + required: > + - remote-endpoint > + > + additionalProperties: false > + > + additionalProperties: false > + > required: > - compatible > - reg -- Regards, Sakari Ailus
