| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Sep 2022 17:26:32 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>, mchehab@...nel.org,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
kishon@...com, vkoul@...nel.org, hverkuil@...all.nl,
jacopo@...ndi.org, kieran.bingham+renesas@...asonboard.com,
linux-media@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-phy@...ts.infradead.org,
kernel@...gutronix.de
Subject: Re: [PATCH v2 3/4] media: dt-bindings: add bindings for Toshiba
TC358746
Hi Laurent, Sakari,
On 22-09-19, Laurent Pinchart wrote:
> On Mon, Sep 19, 2022 at 10:23:55AM +0000, Sakari Ailus wrote:
> > On Mon, Sep 19, 2022 at 12:08:44PM +0200, Marco Felsch wrote:
> > > On 22-09-18, Laurent Pinchart wrote:
> > > > On Fri, Sep 16, 2022 at 03:45:34PM +0200, Marco Felsch wrote:
> > > > > Add the bindings for the Toshiba TC358746 Parallel <-> MIPI-CSI bridge
> > > > > driver.
> > > > >
> > > > > Signed-off-by: Marco Felsch <m.felsch@...gutronix.de>
> > > > > Reviewed-by: Rob Herring <robh@...nel.org>
> > > > > ---
> > > > > Changelog:
> > > > >
> > > > > v2:
> > > > > - addded Robs r-b
> > > > > - s/than/then/
> > > > > - added hsync/vsync/bus-type, make hsync/vsync required
> > > > > - fix example indent
> > > > >
> > > > > .../bindings/media/i2c/toshiba,tc358746.yaml | 179 ++++++++++++++++++
> > > > > 1 file changed, 179 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..1fa574400bc2
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
> > > > > @@ -0,0 +1,179 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge
> > > > > +
> > > > > +maintainers:
> > > > > + - Marco Felsch <kernel@...gutronix.de>
> > > > > +
> > > > > +description: |-
> > > > > + The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2
> > > > > + stream. The direction can be either parallel-in -> csi-out or csi-in ->
> > > > > + parallel-out The chip is programmable trough I2C and SPI but the SPI
> > > > > + interface is only supported in parallel-in -> csi-out mode.
> > > > > +
> > > > > + Note that the current device tree bindings only support the
> > > > > + parallel-in -> csi-out path.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: toshiba,tc358746
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + clocks:
> > > > > + description:
> > > > > + The phandle to the reference clock source. This corresponds to the
> > > > > + hardware pin REFCLK.
> > > > > + maxItems: 1
> > > > > +
> > > > > + clock-names:
> > > > > + const: refclk
> > > > > +
> > > > > +# The bridge can act as clock provider for the sensor. To enable this support
> > > > > +# #clock-cells must be specified. Attention if this feature is used then the
> > > > > +# mclk rate must be at least: (2 * link-frequency) / 8
> > > > > +# `------------------ยด ^
> > > > > +# internal PLL rate smallest possible mclk-div
> > > > > + "#clock-cells":
> > > > > + const: 0
> > > > > +
> > > > > + clock-output-names:
> > > > > + description:
> > > > > + The clock name of the MCLK output, the default name is tc358746-mclk.
> > > > > + maxItems: 1
> > > > > +
> > > > > + vddc-supply:
> > > > > + description: Digital core voltage supply, 1.2 volts
> > > > > +
> > > > > + vddio-supply:
> > > > > + description: Digital I/O voltage supply, 1.8 volts
> > > > > +
> > > > > + vddmipi-supply:
> > > > > + description: MIPI CSI phy voltage supply, 1.2 volts
> > > > > +
> > > > > + reset-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls the chip reset.
> > > > > + This corresponds to the hardware pin RESX which is physically active low.
> > > > > + maxItems: 1
> > > > > +
> > > > > + ports:
> > > > > + $ref: /schemas/graph.yaml#/properties/ports
> > > > > + properties:
> > > > > + port@0:
> > > > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > > > + description: Input port
> > > > > +
> > > > > + properties:
> > > > > + endpoint:
> > > > > + $ref: /schemas/media/video-interfaces.yaml#
> > > > > + unevaluatedProperties: false
> > > > > +
> > > > > + properties:
> > > > > + hsync-active:
> > > > > + enum:
> > > > > + - 0 # Hvalid active high
> > > > > + vsync-active:
> > > > > + enum:
> > > > > + - 0 # Vvalid active high
> > > > > + bus-type:
> > > > > + enum:
> > > > > + - 5 # Parallel
> > > > > +
> > > > > + required:
> > > > > + - hsync-active
> > > > > + - vsync-active
> > > >
> > > > Let's make bus-type required too, to prepare for BT.656 support.
> > >
> > > I would have done it when the BT.656 support is added. Since the BT.656
> > > don't require the sync signals I would have made a descision:
> > > - either: hsync/vsync present -> parallel with external syncs, or
> > > - bus-type present -> parallel bus with embedded syncs.
> > >
> > > So we don't bother the system-integrator with specifying unnecessary
> > > properties. Also having v/hsync required in place with the bus-type (set
> > > to bt.656) can cause confusion about the final used mode.
> >
> > The V4L2 fwnode framework can guess the type of the bus but it's not
> > recommended to use the feature.
>
> Explicit bus types in DT indeed makes it easier for drivers, so if a
> device can support multiple bus types (even if not implemented yet in
> the corresponding drivers), the property should be there.
Okay, I will make it required.
> > Why do you have hsync-active and vsync-active if both are always zero? Can
> > the hardware not support other configuration?
Sure the device supports toggling the logic but it is not implemented.
So the bindings needs to enforce it to 0 right now. As soon as it is
implemented & tested, we can say that both is supported :)
Regards,
Marco
Powered by blists - more mailing lists