Hi,

On Mon 02 Nov 20, 10:21, Maxime Ripard wrote:

On Fri, Oct 30, 2020 at 07:45:18PM -0300, Helen Koike wrote:

quoted

On 10/23/20 2:45 PM, Paul Kocialkowski wrote:

quoted

The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 controller
found on Allwinner SoCs such as the A31 and V3/V3s.

It is a standalone block, connected to the CSI controller on one side
and to the MIPI D-PHY block on the other. It has a dedicated address
space, interrupt line and clock.

Currently, the MIPI CSI-2 controller is hard-tied to a specific CSI
controller (CSI0) but newer SoCs (such as the V5) may allow switching
MIPI CSI-2 controllers between CSI controllers.

It is represented as a V4L2 subdev to the CSI controller and takes a
MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
media controller API.

Maybe this is a bad idea, but I was thinking:
This driver basically just turn on/off and catch some interrupts for errors,
and all the rest of v4l2 config you just forward to the next subdevice
on the pipeline.

So instead of exposing it as a subdevice, I was wondering if modeling
this driver also through the phy subsystem wouldn't be cleaner, so
you won't need all the v4l2 subdevice/topology boilerplate code that
it seems you are not using (unless you have plans to add controls or
some specific configuration on this node later).

But this would require changes on the sun6i-csi driver.

What do you think?

Eventually we'll need to filter the virtual channels / datatypes I
guess, so it's definitely valuable to have it in v4l2

Agreed and like I mentionned in the discussion on 00/14 I don't think it
would be a cleaner way to expose things.

There's also the fact that newer SoCs like the V5 seem to allow connecting
any MIPI CSI-2 controller to any CSI controller, so the graph representation
is definitely welcome here.

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com