Hi Conor,
Thanks for your review.
On 3/17/24 16:18, Conor Dooley wrote:
On Wed, Mar 13, 2024 at 10:49:20AM +0100, Julien Massot wrote:
Add DT bindings for Maxim MAX96714 GMSL2 Deserializer.
Signed-off-by: Julien Massot <julien.massot@xxxxxxxxxxxxx>
---
Change since v4:
- Add compatible for MAX96714 and use it as a fallback for MAX96714F
- Remove extra '|' for decriptions
- Reference 'i2c-gate' instead of 'i2c-controller'
Change since v3:
- Renamed file to maxim,max96714.yaml dropped the 'f' suffix
- Removed mention to C-PHY since it's not supported by MAX96714 deserializers
- Removed bus-type requirement on CSI endpoint since the device only support D-PHY
- Removed the clock-lanes property in the dt example
Change since v2:
- remove reg description
- rename enable gpio to powerdown
- use generic node name: i2c, serializer, deserializer
---
.../bindings/media/i2c/maxim,max96714.yaml | 176 ++++++++++++++++++
1 file changed, 176 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
new file mode 100644
index 000000000000..59b116092834
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Collabora Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/maxim,max96714.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX96714 GMSL2 to CSI-2 Deserializer
+
+maintainers:
+ - Julien Massot <julien.massot@xxxxxxxxxxxxx>
+
+description:
+ The MAX96714 deserializer converts GMSL2 serial inputs into MIPI
+ CSI-2 D-PHY formatted output. The device allows the GMSL2 link to
+ simultaneously transmit bidirectional control-channel data while forward
+ video transmissions are in progress. The MAX96714 can connect to one
+ remotely located serializer using industry-standard coax or STP
+ interconnects. The device cans operate in pixel or tunnel mode. In pixel mode
+ the MAX96714 can select individual video stream, while the tunnel mode forward all
+ the MIPI data received by the serializer.
+
+ The GMSL2 serial link operates at a fixed rate of 3Gbps or 6Gbps in the
+ forward direction and 187.5Mbps in the reverse direction.
+ MAX96714F only supports a fixed rate of 3Gbps in the forward direction.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - maxim,max96714
There's only once device here, make it const rather than enum.
Okay fixed in v6
+ - items:
+ - enum:
+ - maxim,max96714f
+ - const: maxim,max96714 # fallback for 'f' variant
Drop the comment btw, it doesn't make sense given you have an enum that
will allow for more devices and it being a fallback is obvious. That
said, given what you told me on the last version
| Yes there are a few differences visible to the software, for example the
| GMSL
| link rate since MAX96714 support 6 and 3 Gbps, while MAX96714F only
| supports 3Gbps.
| the registers map is the same, but a few values are not possible with
| the 'f' version.
I don't think your ordering here is correct. The 96714 should fall back
to the 96714f, not the opposite that you have here, as the f is the
version which supports fewer features.
I think this should be:
oneOf:
- const: maxim,max96714f
- items:
- enum:
- maxim,max96714
- const: maxim,max96714f
I just sent a v6 version with your suggestion. Indeed it makes more sense
to use max96714/7f as a fallback for the non f variant.
Best regards,
Julien
