From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Daniel Scally <djrscally@gmail.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kate Hsuan <hpa@redhat.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
libcamera-devel@lists.libcamera.org
Subject: Re: Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))
Date: Mon, 1 Nov 2021 20:51:48 +0100 [thread overview]
Message-ID: <f1761496-7974-7892-962b-e6079cb6d8ca@redhat.com> (raw)
In-Reply-To: <YYA9bJ/DZp0+K0MB@smile.fi.intel.com>
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
next prev parent reply other threads:[~2021-11-01 19:52 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <e2312277-f967-7d3f-5ce9-fbb197d35fd6@gmail.com>
2021-10-29 11:50 ` Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1)) Daniel Scally
2021-11-01 15:55 ` Andy Shevchenko
2021-11-01 15:59 ` Andy Shevchenko
2021-11-01 23:26 ` Daniel Scally
2021-11-01 16:02 ` Hans de Goede
2021-11-01 19:18 ` Andy Shevchenko
2021-11-01 19:51 ` Hans de Goede [this message]
2021-11-01 23:43 ` Daniel Scally
2021-11-04 14:49 ` Hans de Goede
2021-11-04 18:14 ` Andy Shevchenko
2021-11-06 14:12 ` Hans de Goede
2021-11-06 18:39 ` Andy Shevchenko
2021-11-04 23:20 ` Daniel Scally
2021-11-08 13:12 ` Hans de Goede
2021-11-08 14:12 ` Andy Shevchenko
2021-11-16 9:54 ` Hans de Goede
2021-11-16 12:26 ` Andy Shevchenko
2021-11-09 0:43 ` Daniel Scally
2021-11-09 12:09 ` Daniel Scally
2021-11-09 16:02 ` Hans de Goede
2021-11-09 16:35 ` Daniel Scally
2021-11-10 0:01 ` Daniel Scally
2021-11-10 8:15 ` Andy Shevchenko
2021-11-11 10:35 ` Hans de Goede
2021-11-11 11:18 ` Daniel Scally
2021-11-11 15:23 ` Hans de Goede
2021-11-11 15:51 ` Dave Stevenson
2021-11-11 16:50 ` Hans de Goede
2021-11-11 19:30 ` Dave Stevenson
2021-11-11 22:04 ` Laurent Pinchart
2021-11-12 10:32 ` Dave Stevenson
2021-11-12 10:46 ` Laurent Pinchart
2021-11-12 11:37 ` Andy Shevchenko
2021-11-15 13:33 ` Laurent Pinchart
2021-11-15 15:03 ` Andy Shevchenko
2021-11-12 11:43 ` Dave Stevenson
2021-11-15 13:21 ` Laurent Pinchart
2021-11-12 12:23 ` Sakari Ailus
2021-11-15 12:00 ` Laurent Pinchart
2021-11-12 17:51 ` [libcamera-devel] " Kieran Bingham
2021-11-15 13:08 ` Laurent Pinchart
2021-11-11 15:51 ` Laurent Pinchart
2021-11-23 12:10 ` Daniel Scally
2021-11-23 19:02 ` Hans de Goede
2021-11-11 15:59 ` Hans de Goede
2021-11-15 23:43 ` Daniel Scally
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f1761496-7974-7892-962b-e6079cb6d8ca@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=djrscally@gmail.com \
--cc=hpa@redhat.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=libcamera-devel@lists.libcamera.org \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox