Re: Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, Nov 01, 2021 at 05:55:18PM +0200, Andy Shevchenko wrote:
> On Fri, Oct 29, 2021 at 12:50:31PM +0100, Daniel Scally wrote:
> > Hi all
> > 
> > +CC linux-media and libcamera-devel, as it's probably a good time to
> > broaden this out. Also Andy because I'm hoping you can help :) The
> > background of the discussion is about how we identify and enumerate
> > (correctly, I.E. with a type matching the vcm driver's i2c_device_id,
> > and there are a few different vcm's in scope which seem encoded in the
> > SSDB buffer) which VCM module is linked to a sensor in Intel's IPU3
> > centric ACPI tables. The I2C address for the device is just a second
> > I2cSerialBusV2 against the sensor's acpi device rather than a separate
> > one, which is no awkward. We also need to get firmware created for the
> > VCM such that the sensor will link to it via the lens-focus property.
> 
> > On 28/10/2021 09:57, Hans de Goede wrote:
> 
> ...
> 
> > To throw a spanner in the works though; I noticed this delightful _CRS
> > for the OV9734 sensor of a  Surface Laptop 1 earlier:
> > 
> > Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
> > {
> >     Name (SBUF, ResourceTemplate ()
> >     {
> >         I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
> >             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
> >             0x00, ResourceConsumer, , Exclusive,
> >             )
> >         I2cSerialBusV2 (0x0050, ControllerInitiated, 0x00061A80,
> >             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
> >             0x00, ResourceConsumer, , Exclusive,
> >             )
> >         I2cSerialBusV2 (0x0051, ControllerInitiated, 0x00061A80,
> >             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
> >             0x00, ResourceConsumer, , Exclusive,
> >             )
> >         I2cSerialBusV2 (0x0052, ControllerInitiated, 0x00061A80,
> >             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
> >             0x00, ResourceConsumer, , Exclusive,
> >             )
> >         I2cSerialBusV2 (0x0053, ControllerInitiated, 0x00061A80,
> >             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
> >             0x00, ResourceConsumer, , Exclusive,
> >             )
> >     })
> >     Return (SBUF) /* \_SB_.PCI0.I2C2.CAMF._CRS.SBUF */
> > }
> > 
> > How do we know which one's the VCM when there's more than just two like
> > that? Andy: don't suppose you can shed any light there?
> 
> Seems to me that the order is defined by address and if software engineers are
> not (so) crazy, it shouldn't deviate from device to device.
> 
> At least this is stated in the internal documentation.
> 
> The order is
> 
> 1. Sensor (single addr)
> 2. VCM (single addr)
> 3. EEPROM (addr per page)
> 
> Interestingly that your list have no VCM in the _CRS defined...
> 
> Not sure how to distinguish that if it's not a typo and indeed the case.
> Sounds like DMI quirk :-( again (something like 3-bit flag to define
> which devices are present in the _CRS taking into account the ordering
> requirements).

Hold on, there is a way out!

SSDB has fields:

	u8 romtype;
	u8 vcmtype;

0 means no device present.

So, seems documentation is consistent and no quirks are needed (until
proven otherwise).

-- 
With Best Regards,
Andy Shevchenko