[libcamera-devel] presentation
Enrique Artal
artal at unizar.es
Wed Apr 29 23:31:59 CEST 2020
Hi Laurent,
I attached in a tar.gz the files given by this order. Thanks, Enrique.
El 29/4/20 a las 21:20, Laurent Pinchart escribió:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acpidump.tar.gz
Type: application/gzip
Size: 76690 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20200429/06b1ec7c/attachment-0001.gz>
More information about the libcamera-devel
mailing list