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
