[libcamera-devel] How to detect camera after power on the raspberryPi.

[Dave Stevenson]

Hi Laurent

On Mon, 19 Oct 2020 at 13:50, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> Hi Dave,
>
> On Mon, Oct 19, 2020 at 11:10:55AM +0100, Dave Stevenson wrote:
> > On Mon, 19 Oct 2020 at 10:38, <tetsuya.nomura at soho-enterprise.com> wrote:
> > >
> > > Dear Sirs.
> > >
> > > May I have your favor about initialization of the RaspberryPi and the camera?
> > >
> > > I'm now evaluating the camera extension board of FPD LINK III technology to extend the camera cable for 2~3m from the RaspberryPi.
> > > https://soho-enterprise.com/2020/10/11/post-866/
> > >
> > > This board can pass the I2C communication to IMX219 after configuring the transceiver chip,
> > > However, after configuration and run the qcam, it seems the qcam program does not detect the IMX219
> > > And I cannot start the camera even I designate the image sensor name.
> >
> > The Pi kernel driver for imx219 probes the sensor driver as the module
> > loads, which is only a few seconds into boot if you've added
> > "dtoverlay=imx219" into config.txt. No or incorrect response from the
> > sensor and it won't create the /dev/video0 device nodes. If your
> > transceivers need some form of configuration then I suspect this has
> > not happened by this point.
> >
> > The correct approach is probably to have a driver for your transceiver
> > in the kernel driver chain, ie imx219 -> transceiver -> Unicam,
> > however that opens a big can of worms over configuration as it forces
> > the use of the Media Controller API to configure each link
> > independently.
>
> A very open question: assuming we can retain control through the video
> node as implemented today for the existing use cases, and implement
> MC-based pipeline control in parallel in the driver (possibly selecting
> one of the options through a module parameter) for use cases that would
> be tricky to support otherwise, would you be OK with that ?

I'm totally OK with it!
I've had a couple of other threads in the last few weeks that kicked
me to look into MC and what is required.

The first was trying to support Analog Devices ADV7482 which Kieran
will know and "love". That showed up a couple of oddities around
linking to async_notifier and incorrect behaviour with our use of pad
indexes. Those two bits are easy to rectify, although having made the
async_notifier stuff match other platforms it no longer probed the
simple modules correctly :-( There must be a solution there somewhere,
it's only finding the correct runes.

The second use case was Toshiba's TC358746/TC358748 parallel to CSI
bridges, where similar to this case it's chaining sensor ->
TC35874[6|8] -> Unicam.

With regard switching behaviours, it's relatively simple to look at
the immediately upstream node and see if it has any sink pads. If yes
we go MC, otherwise video-device. Doing so dynamically at runtime is
nicer than a module parameter.
That's the easy bit. The harder bit is working out which bits of
functionality that then requires dropping when in MC mode. At the
moment I'm not totally clear over the correct approach for configuring
the actual Unicam hardware - S_FMT on /dev/videoN, or MC API setting
the sink pad format of Unicam. The mismash of MEDIA_BUS_FMT_xxx vs
V4L2_PIX_FMT_xxx formats surfaces again, how do you avoid format
mismatches (and unpacking to 16bit), and which do you use to configure
CSI data type filtering.
I'm assuming all the subdev API calls for EDIDs, timings (DV and
standards), parm, and enumerations disappear with MC too, as you open
the subdev node to configure that lot.

Thanks
  Dave

> > One workaround would be to remove "dtoverlay=imx219" from config.txt
> > and use dynamic device tree overlay loading to load the relevant
> > modules later in boot. "sudo dtoverlay imx219" should do that for you.
> > The niggle is that when done from config.txt the firmware fixes up the
> > camera shutdown GPIO to match the platform (it moves GPIOs between
> > different variants of the Pi). If loading dynamically then this can't
> > happen, and you'll need to fix up the regulator shutdown line manually
> > [1] (assuming that it is actually controllable at the other end of the
> > FPD Link)
> >
> > [1] (https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/imx219-overlay.dts#L77)
> >
> > > I can start the IMX219, get the RAW image by our own program and see the image.
> > > Then if qcam can send the necessary command to IMX219 when start running the qcam,
> > > I think I can see the image through qcam program.
> > >
> > > It would be great if you could give us an advice to solve it.
> > > I appreciate your kind help in advance.
> > >
> > > Best Regards,
> > >
> > > NOMURA
>
> --
> Regards,
>
> Laurent Pinchart