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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 11/1/21 20:18, Andy Shevchenko wrote:
> On Mon, Nov 01, 2021 at 05:02:58PM +0100, Hans de Goede wrote:
>> On 10/29/21 13:50, Daniel Scally 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 */
>>> }
>>
>> Hmm, we do have i2c_acpi_client_count(adev), so it is easy to use
>> that and just always use the last resource for the VCM. But that assumes
>> that is what is going on here and I have no idea.
> 
> You probably composed this message before reading my reply(ies).

Yes, sorry about that; and thank you for your answer the info
you provided is very helpful. If I understand things correctly
will can just always take the 2nd I2cSerialBusV2 resource entry
for the VCM since if there is a VCM that is where its
I2cSerialBusV2 resource entry will be.

> ...
> 
>> Change the first parameter of i2c_acpi_new_device() from
>> a struct device * to a struct acpi_device *.
>>
>> This is necessary because in some cases we may only have access
>> to the fwnode / acpi_device and not to the matching physical-node
>> struct device *.
> 
> Can we rather create an fwnode based API and then
> 
> static inline
> struct i2c_client *i2c_acpi_new_device(struct device *dev, int index,
> 				       struct i2c_board_info *info)
> 	return i2c_acpi_new_device_by_fwnode(dev_fwnode(), index, info);
> }
> 
> ?

Yes that is a good idea, I'll switch to that in my local tree, so
v1 (which I will post once I've something working) will have this.

Regards,

Hans




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux