Message-ID: <d15d724b-6af7-3e51-1316-7bdde5a42c60@collabora.com>
Date:   Fri, 30 Oct 2020 19:44:28 -0300
From:   Helen Koike <helen.koike@...labora.com>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devel@...verdev.osuosl.org, linux-sunxi@...glegroups.com
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Ripard <mripard@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Yong Deng <yong.deng@...ewell.com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Hans Verkuil <hverkuil@...all.nl>, kevin.lhopital@...mail.com
Subject: Re: [PATCH 00/14] Allwinner MIPI CSI-2 support for A31/V3s/A83T

Hi Paul,

I have some comments through the series, I hope this helps.

On 10/23/20 2:45 PM, Paul Kocialkowski wrote:
> This series introduces support for MIPI CSI-2, with the A31 controller that is
> found on most SoCs (A31, V3s and probably V5) as well as the A83T-specific
> controller. While the former uses the same MIPI D-PHY that is already supported
> for DSI, the latter embeds its own D-PHY.
> 
> In order to distinguish the use of the D-PHY between Rx mode (for MIPI CSI-2)
> and Tx mode (for MIPI DSI), a submode is introduced for D-PHY in the PHY API.
> This allows adding Rx support in the A31 D-PHY driver.
> 
> A few changes and fixes are applied to the A31 CSI controller driver, in order
> to support the MIPI CSI-2 use-case.
> 
> Follows is the V4L2 device topology representing the interactions between
> the MIPI CSI-2 sensor, the MIPI CSI-2 controller (which controls the D-PHY)
> and the CSI controller:
> - entity 1: sun6i-csi (1 pad, 1 link)
>             type Node subtype V4L flags 0
>             device node name /dev/video0
> 	pad0: Sink
> 		<- "sun6i-mipi-csi2":1 [ENABLED,IMMUTABLE]
> 
> - entity 5: sun6i-mipi-csi2 (2 pads, 2 links)
>             type V4L2 subdev subtype Unknown flags 0
> 	pad0: Sink
> 		<- "ov5648 0-0036":0 [ENABLED,IMMUTABLE]
> 	pad1: Source
> 		-> "sun6i-csi":0 [ENABLED,IMMUTABLE]
> 
> - entity 8: ov5648 0-0036 (1 pad, 1 link)
>             type V4L2 subdev subtype Sensor flags 0
>             device node name /dev/v4l-subdev0

Question: I noticed is that sun6i-mipi-csi2 doesn't expose a node under /dev/, but the sensor
exposes it. Probably because it uses V4L2_SUBDEV_FL_HAS_DEVNODE and sun6i-csi() calls
v4l2_device_register_subdev_nodes().

I find this weird from a userspace pov, since usually we don't mix manual and auto propagation
of the configs, so I started wondering if sun6i-csi driver should be calling
v4l2_device_register_subdev_nodes() in the first place.

Also, sun6i-csi doesn't seem to be used by any board dts (it's declared on the dtsi, but I
didn't find any dts enabling it), so I wonder if it would be a bad thing if we update it.

> 	pad0: Source
> 		[fmt:SBGGR8_1X8/640x480@...0 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range]
> 		-> "sun6i-mipi-csi2":0 [ENABLED,IMMUTABLE]

If I understand correctly, this is very similar to ipu3:
    sensor->bus->dma_engine

in the case of ipu3-cio2:
    sensor->ipu3-csi2->ipu3-cio2

in this case:
    ov5648->sun6i-mipi-csi2->sun6i-csi

On thing that is confusing me is the name csi2 with csi (that makes me think of csi
vesun6i-csirsion one, which is not the case), I would rename it to sun6i-video (or maybe
it is just me who gets confused).
I know this driver is already upstream and not part of this series, but on the other hand it
doesn't seem to be used.

On another note, I always wonder if we should expose the bus in the topology, I'm not
sure if it provides any useful API or information for userspace, and you could have
a cleaner code (maybe code could be under phy subsystem). But at the same time, it
seems this is a pattern on v4l2.

I'd like to hear what others think on the above.

Regards,
Helen

> 
> Happy reviewing!
> 
> Paul Kocialkowski (14):
>   phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
>   phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI
>     CSI-2
>   media: sun6i-csi: Support an optional dedicated memory pool
>   media: sun6i-csi: Fix the image storage bpp for 10/12-bit Bayer
>     formats
>   media: sun6i-csi: Only configure the interface data width for parallel
>   media: sun6i-csi: Support feeding from the MIPI CSI-2 controller
>   dt-bindings: media: i2c: Add A31 MIPI CSI-2 bindings documentation
>   media: sunxi: Add support for the A31 MIPI CSI-2 controller
>   ARM: dts: sun8i: v3s: Add CSI0 camera interface node
>   ARM: dts: sun8i: v3s: Add MIPI D-PHY and MIPI CSI-2 interface nodes
>   dt-bindings: media: i2c: Add A83T MIPI CSI-2 bindings documentation
>   media: sunxi: Add support for the A83T MIPI CSI-2 controller
>   ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node
>   media: sunxi: sun8i-a83t-mipi-csi2: Avoid using the (unsolicited)
>     interrupt
> 
>  .../media/allwinner,sun6i-a31-mipi-csi2.yaml  | 168 +++++
>  .../media/allwinner,sun8i-a83t-mipi-csi2.yaml | 158 +++++
>  arch/arm/boot/dts/sun8i-a83t.dtsi             |  26 +
>  arch/arm/boot/dts/sun8i-v3s.dtsi              |  62 ++
>  drivers/media/platform/sunxi/Kconfig          |   2 +
>  drivers/media/platform/sunxi/Makefile         |   2 +
>  .../platform/sunxi/sun6i-csi/sun6i_csi.c      |  54 +-
>  .../platform/sunxi/sun6i-csi/sun6i_csi.h      |  20 +-
>  .../platform/sunxi/sun6i-mipi-csi2/Kconfig    |  11 +
>  .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
>  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 635 +++++++++++++++++
>  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 116 +++
>  .../sunxi/sun8i-a83t-mipi-csi2/Kconfig        |  11 +
>  .../sunxi/sun8i-a83t-mipi-csi2/Makefile       |   4 +
>  .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c    |  92 +++
>  .../sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h    |  39 ++
>  .../sun8i_a83t_mipi_csi2.c                    | 660 ++++++++++++++++++
>  .../sun8i_a83t_mipi_csi2.h                    | 196 ++++++
>  drivers/phy/allwinner/phy-sun6i-mipi-dphy.c   | 164 ++++-
>  drivers/staging/media/rkisp1/rkisp1-isp.c     |   3 +-
>  include/linux/phy/phy-mipi-dphy.h             |  13 +
>  21 files changed, 2408 insertions(+), 32 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
>  create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
>  create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Kconfig
>  create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/Makefile
>  create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
>  create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.h
>  create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c
>  create mode 100644 drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.h
> 

Powered by blists - more mailing lists