[PATCH v2 07/19] media: sun6i-csi: Add support for MIPI CSI-2 bridge input

[Paul Kocialkowski]

Hi,

On Wed 02 Dec 20, 16:40, Maxime Ripard wrote:
> On Wed, Dec 02, 2020 at 03:19:11PM +0100, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Tue 01 Dec 20, 13:12, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Sat, Nov 28, 2020 at 03:28:27PM +0100, Paul Kocialkowski wrote:
> > > > The A31 CSI controller supports a MIPI CSI-2 bridge input, which has
> > > > its own dedicated port in the fwnode graph.
> > > > 
> > > > Support for this input is added with this change:
> > > > - two pads are defined for the media entity instead of one
> > > >   and only one needs to be connected at a time;
> > > > - the pads currently match the fwnode graph representation;
> > > > - links are created between our pads and the subdevs for each
> > > >   interface and are no longer immutable so that userspace can select
> > > >   which interface to use in case both are bound to a subdev;
> > > > - fwnode endpoints are parsed and stored for each interface;
> > > > - the active subdev (and fwnode endpoint) is retrieved when validating
> > > >   the media link at stream on time and cleared at stream off;
> > > > - an error is raised if both links are active at the same time;
> > > > - the MIPI interface bit is set if the MIPI CSI-2 bridge endpoint is
> > > >   active.
> > > > 
> > > > In the future, the media entity representation might evolve to:
> > > > - distinguish the internal parallel bridge and data formatter;
> > > > - represent each of the 4 internal channels that can exist between
> > > >   the parallel bridge (for BT656 time-multiplex) and MIPI CSI-2
> > > >   (internal channels can be mapped to virtual channels);
> > > > - connect the controller's output to the ISP instead of its
> > > >   DMA engine.
> > > > 
> > > > Finally note that the MIPI CSI-2 bridges should not be linked in
> > > > the fwnode graph unless they have a sensor subdev attached.
> > > 
> > > I'll leave most of the review to Laurent and Sakari, but I'm not quite
> > > sure what you meant in the last paragraph. Did you mean that the
> > > MIPI-CSI controller in the Allwinner SoC should only be linked if it has
> > > a sensor attached, or did you mean that any MIPI-CSI2 bridge cannot be
> > > attached to the controller?
> > 
> > So the use of plural was a mistake and your first understanding is the correct
> > one: if the bridge is linked to the CSI controller in the OF graph but the
> > bridge doesn't have a sensor attached, the CSI controller driver will fail
> > to probe, as far as I could see.
> 
> I'm not sure it's reasonable to not link it in the DTSI then, we'll want
> to reduce as much the boilerplate from the board DTS as possible, and
> the MIPI-CSI controller is always there anyway. However, we should
> definitely have it disabled if there's no sensor, which should solve
> your probe issue

Ah yes there's a good chance that it will solve it.
I'll try that and get back to you!

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201202/5d20468c/attachment.sig>