[libcamera-devel] presentation

[Laurent Pinchart]

Hi Enrique,

On Wed, Apr 29, 2020 at 08:36:50PM +0200, Enrique Artal wrote:
> Hi Laurent,
> 
> Thanks for the answer. If at some point, I can provide information, 
> please let me know. Amitiés, Enrique.

Would you be able to provide a dump of your ACPI tables ? This can be
done with 'acpidump -b' (running as root). I won't promise to work in
this for the time being, but if we (or someone else) finds time later,
collecting ACPI dumps of systems we will need to support will help.

> El 29/4/20 a las 16:07, Laurent Pinchart escribió:
> > On Wed, Apr 29, 2020 at 03:08:44PM +0200, Enrique Artal wrote:
> >> In the previous reply I forgot to send the output to the list:
> >>
> >> Media controller API version 5.6.7
> >>
> >> Media device information
> >> ------------------------
> >> driver          ipu3-cio2
> >> model           Intel IPU3 CIO2
> >> serial
> >> bus info        PCI:0000:00:14.3
> >> hw revision     0x0
> >> driver version  5.6.7
> >>
> >> Device topology
> >> - entity 1: ipu3-csi2 0 (2 pads, 1 link)
> >>               type V4L2 subdev subtype Unknown flags 0
> >>               device node name /dev/v4l-subdev0
> >>       pad0: Sink
> >>       pad1: Source
> >>           [fmt:SGRBG10_1X10/1936x1096 field:none]
> >>           -> "ipu3-cio2 0":0 [ENABLED,IMMUTABLE]
> >>
> >> - entity 4: ipu3-cio2 0 (1 pad, 1 link)
> >>               type Node subtype V4L flags 0
> >>               device node name /dev/video0
> >>       pad0: Sink
> >>           <- "ipu3-csi2 0":1 [ENABLED,IMMUTABLE]
> >>
> >> - entity 10: ipu3-csi2 1 (2 pads, 1 link)
> >>                type V4L2 subdev subtype Unknown flags 0
> >>                device node name /dev/v4l-subdev1
> >>       pad0: Sink
> >>       pad1: Source
> >>           [fmt:SGRBG10_1X10/1936x1096 field:none]
> >>           -> "ipu3-cio2 1":0 [ENABLED,IMMUTABLE]
> >>
> >> - entity 13: ipu3-cio2 1 (1 pad, 1 link)
> >>                type Node subtype V4L flags 0
> >>                device node name /dev/video1
> >>       pad0: Sink
> >>           <- "ipu3-csi2 1":1 [ENABLED,IMMUTABLE]
> >>
> >> - entity 19: ipu3-csi2 2 (2 pads, 1 link)
> >>                type V4L2 subdev subtype Unknown flags 0
> >>                device node name /dev/v4l-subdev2
> >>       pad0: Sink
> >>       pad1: Source
> >>           [fmt:SGRBG10_1X10/1936x1096 field:none]
> >>           -> "ipu3-cio2 2":0 [ENABLED,IMMUTABLE]
> >>
> >> - entity 22: ipu3-cio2 2 (1 pad, 1 link)
> >>                type Node subtype V4L flags 0
> >>                device node name /dev/video2
> >>       pad0: Sink
> >>           <- "ipu3-csi2 2":1 [ENABLED,IMMUTABLE]
> >>
> >> - entity 28: ipu3-csi2 3 (2 pads, 1 link)
> >>                type V4L2 subdev subtype Unknown flags 0
> >>                device node name /dev/v4l-subdev3
> >>       pad0: Sink
> >>       pad1: Source
> >>           [fmt:SGRBG10_1X10/1936x1096 field:none]
> >>           -> "ipu3-cio2 3":0 [ENABLED,IMMUTABLE]
> >>
> >> - entity 31: ipu3-cio2 3 (1 pad, 1 link)
> >>                type Node subtype V4L flags 0
> >>                device node name /dev/video3
> >>       pad0: Sink
> >>           <- "ipu3-csi2 3":1 [ENABLED,IMMUTABLE]
> > OK, this is where things get a bit messy I'm afraid. The CIO2 driver
> > didn't detect the camera sensor. In a nutshell, the driver gets
> > information about the hardware topology (which sensor is used and how
> > it's connected) from the platform firmware. On x86, this means ACPI (in
> > the DSDT table to be exact), on arm it means device tree.
> >
> > There's no standard to express that information ACPI, and all device
> > vendors came up with their own solution (there has been some effort to
> > standardize this though, but no complete formal solution in the ACPI
> > spec itself). Intel has, for reasons that are out of scope, developed
> > two different ways to represent that information in the DSDT. One has
> > been designed for devices manufactured for the Windows market, and
> > another one for devices manufactured for the Linux market (mostly
> > Chromebooks). The CIO2 driver only supports the latter, and your device
> > probably implements the former.
> >
> > We need to teach the CIO2 driver about the Windows-specific data
> > representation. The challenge is that, on Windows, vendors usually
> > hardcode some information in drivers, so not all the information we need
> > may be available in the DSDT. The information that is available also
> > makes it difficult to find the sensor from the CIO2, as far as I know
> > there's no "link" between the two. Finally, the format of the data isn't
> > documented. Different solutions can be considered, but it will take
> > someone to do the work. Once that is done, libcamera should be able to
> > support your device.
> >
> > All we need is a volunteer :-)
> >
> >> El 29/4/20 a las 14:22, Laurent Pinchart escribió:
> >>> On Wed, Apr 29, 2020 at 09:04:57AM +0200, Enrique Artal wrote:
> >>>> Dear members of the lists,
> >>>>
> >>>> I am not a developer, so my contribution to this list may be only for
> >>>> testing. I use an hp pro x2 612 g2, with Fedora 31 at this time, which
> >>>> has (I think!) an ipu3 device. I have compiled libcamera and the device
> >>>> is recognized somehow (four /dev/video*) are created but none of them
> >>>> are listed with "sudo cam -l"; neither cheese nor webcamoid recognize
> >>>> them, only ucview seems to detect something with no image. Last git
> >>>> version is installed. If there is some test that should run for this
> >>>> device, you can use my assistance. Thanks for you work, Enrique.
> >>>>
> >>>> PS. If more data is needed, feel free to ask for it.
> >>> Could you please send the output of
> >>>
> >>> media-ctl -p -d /dev/mediaX
> >>>
> >>> for each of the /dev/media* devices present in your system ? media-ctl
> >>> is part of v4l-utils.

-- 
Regards,

Laurent Pinchart