Hi Mario, On 5-Mar-25 4:42 PM, Mario Limonciello wrote: > On 3/5/2025 09:26, Hans de Goede wrote: <snip> >> Thanks. >> >> So looking at this there are ACPI devices for the sensors, which >> unfortunately lack a _CRS with an I2CSerialBusV2 resource pointing >> to the ISP childdevice as bus-controller. So that i2c-client >> instantiating would be instant. >> >> +Cc Mario >> >> Mario any chance that for the next (or the next-next) generation of >> AMD devices we can get the ACPI tables fixed to properly describe >> the sensors as having an I2cSerialBusV2 resource, just like how e.g. >> I2C touchpads / touchscreens have this ? I suspect this will benefit >> Windows too. Likewise any enable GPIOs for the sensor really also >> should be proper ACPi Gpio resources in the ACPI device describing >> the sensor. > > Due to the architecture of how the ISP is accessed "through" the GPU, I'm not sure it's viable and furthermore if it actually changes anything for Windows. But the ISP team and BIOS team can certainly discuss it for future designs. There could be an ACPI child device under the ACPI device / fwnode for the GPU which models the ISP, this could have its own _HID to allow the ISP driver to find it. If the I2C adapter part of the ISP driver then sets the fwnode of the adapter to that child fwnode, it can be used as the I2C controller reference in I2cSerialBusV2 resources for the sensors. This is how I2C devices generally are handled / enumerated under ACPI and I don't really see why future AMD designs could not follow how this is all supposed to work under ACPI instead of having drivers need to manually instantiate the i2c-client. This also allows putting things like the sensor i2c-address (and GPIOs) in ACPI instead of having to hardcode this all in the drivers. And as mentioned before I think this would benefit the windows drivers too, for similar reasons (not needing to hardcode things like i2c-address and GPIOs which really belongs in the ACPI tables). Regards, Hans
