Matt Delco has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/45091 )
Change subject: drivers/intel/mipi_camera: Add compatible field for NVM ......................................................................
Patch Set 3:
It seems like there's 3 possible schemes: 1) INT3499 with explicit ACPI properties, 2) PRP0001 with a specific compatible string, and 3) scheme #2 plus explicit ACPI properties. To me scheme #3 seems to be a bit redundant and invite inconsistencies with conflicting information, so I'd favor one of the other two schemes.
To me, I see 1 vs. 2 as just about binding the device to a driver, and if the driver has support for OF already, but not ACPI, it's much simpler to just stick with PRP0001/_DSD until we can get a driver upstreamed.
INT3499 is older and more established (it's what all the poppy-based boards are using) so I'd expect it to have boarder compatibility than PRP0001/_DSD. There's tradeoffs to both, but i mostly wanted people to be aware that there's been a change in precedent that seemed more likely to be accidental (or a reflection of change in personnel) than intentional.
Anyway, my long-term motivation would be to see Intel's drivers for Linux and Windows converge on a single ACPI scheme, so I'm concerned to see there's now additional schemes going on on the Linux side for advertising NVM and hope there can be at least some kind of consistency/re-convergence on how the NVM is advertised.
I have zero familiarity with the way Windows consumes ACPI, is there some info available on how it looks there?
I'm not sure if you're asking about cameras or ACPI in general. Some example DSDT dumps can be found on the net, e.g. (search on cam0/cam1/camf/camr for camera-specific parts):
https://gist.github.com/carlocaione/9c8e2fb47d1100584378 https://gist.github.com/JoshKaufman/e9479620626b10849276443b2875c3c9
and I've looked at other systems that were in a lab (but don't have access to at the moment due to covid-related restrictions).
The cameras basically show up in ACPI as 1 CAM device, with no separate devices for NVM or VCM. The CAM device advertises 1 or more I2C address resources, and custom ACPI attributes in the CAM device help to distinguish which are for the actual camera (vs. optional NVM or VCM). I'm not sure how the NVM type is identified--there's a byte for this in the SSDB blob ("rom_type" in coreboot), but it's very course grained so I figured it was more likely the driver uses I2C to query the NVM device for its make/model. Just to be clear, what I've described in this paragraph is defined by the camera drivers that Intel provides for their SoCs, rather than something defined by Microsoft or the Windows OS.
As for how Windows drivers bind to devices (which is defined by Microsoft), a driver for an ACPI device can basically claim 0+ _HIDs (hardware ID) and/or 0+ _CIDs (compatible ID). Each of those claims can optionally be restricted to a particular _SUB (subsystem ID) (e.g., _HID&_SUB or _CID&_SUB). So, if someone were to write a Windows driver for INT3499 they'd need to write a driver that can handle most/all NVMs, or add a _SUB to the ACPI device and make the driver specific to that _SUB. PRP0001 is used for a much broader range of devices, so the only well-behaved approach would be to use a _SUB (without a _SUB the driver would try to claim all PRP0001 devices on a system, and if it was posted to Windows Update then it could cause havoc on other kinds of systems).
I've used the NVM device as an illustrative example, though as things are currently you wouldn't actually want to write an actual standalone driver for the NVM device. Intel's CAM driver expects to see a monolithic CAM device and will handle the camera, nvm, and vcm functionality together in that driver. If you were to boot Windows on a Chromebook using coreboot and the mipi_camera driver, then it'll see the CAM device, plus possibly an NVM and/or VCM device (depending on the system and devicetree config). The camera can/will work, assuming you've got a driver from Intel for the particular sensor. For the NVM/VCM devices (if present), Windows will likely complain that it doesn't have a driver for the device. A typical way for system manufacturers to mute this complaint is to make a "null driver" (a driver which basically puts a descriptive name on a device but doesn't actually use the device [or even have a presence anywhere in the kernel]--most chipset drivers are really just a null driver). It'd be reasonable for someone to make a null driver for INT3499 (assuming the ID is only used for camera-related NVMs), though handling PRP0001 would be trickier (e.g., add a _SUB on the device and make the driver specific to that).