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

[Kieran Bingham]

Hi Dave,

On 19/10/2020 16:53, Dave Stevenson wrote:
> 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

Ahem, cough cough. Indeed :-)

Is there a board available that can connect this to the RPi?
If so I'd be interested in buying one.



> 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 ADV748x requires endpoint matching, and it complicates things indeed.

For a long time, I think the only receiver that supported this driver
was the Renesas RCar-CSI2/VIN.

There is a series here:

https://lore.kernel.org/linux-media/20200701062140.12953-1-laurent.pinchart+renesas@ideasonboard.com/

Which should finally ease things and make endpoint matching compatible
with all receivers, which I believe has landed in v5.9.


> 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.

+Niklas,

I sort of agree here, as it should be easier for end users. Niklas may
have different opinions as he has felt pain of supporting both MC and
non-MC interfaces in the RCar-VIN.


> 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.

Indeed, those can then be operated on the subdev node.


> 
> 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
> _______________________________________________
> libcamera-devel mailing list
> libcamera-devel at lists.libcamera.org
> https://lists.libcamera.org/listinfo/libcamera-devel
> 

-- 
Regards
--
Kieran