[libcamera-devel] Firmware (devicetree/ACPI interface) for marking camera sensors being on the front/back of a device
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Sun Jan 16 23:20:05 CET 2022
Hi Hans,
On Sun, Jan 16, 2022 at 10:43:25PM +0100, Hans de Goede wrote:
> Hi All,
>
> IIRC there was some discussion about $subject a while ago,
> esp. being pushed by the ChromeOS folks (IIRC). If you know what
> I'm talking about, please add relevant folks to the Cc.
>
> While doing some work on atomisp support I noticed that the
> ACPI device fwnode-s describing the sensors have an ACPI _PLD
> method, which is a standardized ACPI method to retreive an
> package (ACPI for struct) describing the location of things
> like USB ports; and in this case of the camera sensors.
>
> And upon checking the Surface Go DSDT the sensors there seem to
> have the _PLD bits to. And in both cases at least the following
> PLD field (bits 67-69) seems to contain valid and relevant info,
> quoting from the ACPI spec 6.2 version, page 329:
>
> """
> Panel: Describes which panel surface of the system’s housing
> the device connection point resides on:
> 0 – Top
> 1 – Bottom
> 2 – Left
> 3 – Right
> 4 – Front
> 5 – Back
> 6 – Unknown
> """
>
> This seems to be consistently set to 4 or 5 for the _PLD method
> of the sensor ACPI nodes which I checked.
>
> So rather then defining a new devicetree property for this and
> embedding that inside the ACPI tables, IMHO it would be best if
> the ChromeOS devices would use the standardized _PLD ACPI method
> for this too.
I have no specific objection to this, given that the _PLD is
standardized. In your experience, is the rotation also populated
correctly ? That's important information too.
It we go in that direction, we should try to push OEMs to also populate
the vertical offset and horizontal offset fields, as I expect it to
become useful when multiple cameras are present in the same location.
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list