On Wed, Nov 04, 2020 at 11:48:27AM +0100, Paul Kocialkowski wrote: > Hi, > > On Tue 27 Oct 20, 19:44, Maxime Ripard wrote: > > On Tue, Oct 27, 2020 at 10:52:21AM +0100, Paul Kocialkowski wrote: > > > Hi, > > > > > > On Mon 26 Oct 20, 17:14, Maxime Ripard wrote: > > > > i2c? :) > > > > > > Oops, good catch! > > > > > > > On Fri, Oct 23, 2020 at 07:45:39PM +0200, Paul Kocialkowski wrote: > > > > > This introduces YAML bindings documentation for the A31 MIPI CSI-2 > > > > > controller. > > > > > > > > > > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> > > > > > --- > > > > > .../media/allwinner,sun6i-a31-mipi-csi2.yaml | 168 ++++++++++++++++++ > > > > > 1 file changed, 168 insertions(+) > > > > > create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > > > > > new file mode 100644 > > > > > index 000000000000..9adc0bc27033 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > > > > > @@ -0,0 +1,168 @@ > > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Allwinner A31 MIPI CSI-2 Device Tree Bindings > > > > > + > > > > > +maintainers: > > > > > + - Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> > > > > > + > > > > > +properties: > > > > > + compatible: > > > > > + oneOf: > > > > > + - const: allwinner,sun6i-a31-mipi-csi2 > > > > > + - items: > > > > > + - const: allwinner,sun8i-v3s-mipi-csi2 > > > > > + - const: allwinner,sun6i-a31-mipi-csi2 > > > > > + > > > > > + reg: > > > > > + maxItems: 1 > > > > > + > > > > > + interrupts: > > > > > + maxItems: 1 > > > > > + > > > > > + clocks: > > > > > + items: > > > > > + - description: Bus Clock > > > > > + - description: Module Clock > > > > > + > > > > > + clock-names: > > > > > + items: > > > > > + - const: bus > > > > > + - const: mod > > > > > + > > > > > + phys: > > > > > + items: > > > > > + - description: MIPI D-PHY > > > > > + > > > > > + phy-names: > > > > > + items: > > > > > + - const: dphy > > > > > + > > > > > + resets: > > > > > + maxItems: 1 > > > > > + > > > > > + # See ./video-interfaces.txt for details > > > > > + ports: > > > > > + type: object > > > > > + > > > > > + properties: > > > > > + port@0: > > > > > + type: object > > > > > + description: Input port, connect to a MIPI CSI-2 sensor > > > > > + > > > > > + properties: > > > > > + reg: > > > > > + const: 0 > > > > > + > > > > > + endpoint: > > > > > + type: object > > > > > + > > > > > + properties: > > > > > + remote-endpoint: true > > > > > + > > > > > + bus-type: > > > > > + const: 4 > > > > > + > > > > > + clock-lanes: > > > > > + maxItems: 1 > > > > > + > > > > > + data-lanes: > > > > > + minItems: 1 > > > > > + maxItems: 4 > > > > > + > > > > > + required: > > > > > + - bus-type > > > > > + - data-lanes > > > > > + - remote-endpoint > > > > > + > > > > > + additionalProperties: false > > > > > + > > > > > + required: > > > > > + - endpoint > > > > > + > > > > > + additionalProperties: false > > > > > + > > > > > + port@1: > > > > > + type: object > > > > > + description: Output port, connect to a CSI controller > > > > > + > > > > > + properties: > > > > > + reg: > > > > > + const: 1 > > > > > + > > > > > + endpoint: > > > > > + type: object > > > > > + > > > > > + properties: > > > > > + remote-endpoint: true > > > > > + > > > > > + bus-type: > > > > > + const: 4 > > > > > > > > That one seems a bit weird. If the input and output ports are using the > > > > same format, what is that "bridge" supposed to be doing? > > > > > > Fair enough. What this represents is the internal link (likely a FIFO) between > > > the two controllers. It is definitely not a MIPI CSI-2 bus but there's no > > > mbus type for an internal link (probably because it's not a bus after all). > > > > > > Note that on the CSI controller side, we need the bus-type to be set to 4 for it > > > to properly select the MIPI CSI-2 input. So it just felt more logical to have > > > the same on the other side of the endpoint. On the other hand, we can just > > > remove it on the MIPI CSI-2 controller side since it won't check it and have it > > > fallback to the unknown mbus type. > > > > > > But that would make the types inconsistent on the two sides of the link. > > > I don't think V4L2 will complain about it at the moment, but it would also make > > > sense that it does eventually. > > > > > > What do you think? > > > > There's still the same issue though, it doesn't make any sense that a > > bridge doesn't change the bus type. If it really did, we wouldn't need > > that in the first place. > > Yes I agreee. > > > What you want to check in your driver is whether the subdev you're > > connected to has a sink pad that uses MIPI-CSI > > I'm not really sure that's possible, but if it is it would indeed be the most > appropriate solution. If it's not, we still need to know that we need to feed > from MIPI CSI-2 so I don't see any other option than report MIPI CSI-2 on both > ends of MIPI CSI-2 controller. > > But there's still the question of what media bus type should be reported for > the CSI <-> MIPI CSI-2 link. I'm fine with unknown but we could also add a > generic internal bus type for this case. I guess both questions would need to be discussed more on the v4l2 side. Maxime
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
