On 09/01/2021 09:17, Andy Shevchenko wrote:
> On Saturday, January 9, 2021, Daniel Scally wrote:
>
>> Hi Andy
>>
>> On 08/01/2021 12:17, Andy Shevchenko wrote:
>>> On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally
>> wrote:
On 30/11/2020 20:07, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020
Hi Laurent
On 09/01/2021 00:18, Laurent Pinchart wrote:
> H Andy and Daniel,
>
> On Fri, Jan 08, 2021 at 02:17:49PM +0200, Andy Shevchenko wrote:
>> On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally wrote:
>>> On 30/11/2020 20:07, Andy Shevchenko wrote:
On Mon, Nov 30, 2020 at 01:31:29PM +,
H Andy and Daniel,
On Fri, Jan 08, 2021 at 02:17:49PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally wrote:
> > On 30/11/2020 20:07, Andy Shevchenko wrote:
> > > On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
>
> ...
>
> > > It's solely Windows
Hi Andy
On 08/01/2021 12:17, Andy Shevchenko wrote:
> On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally wrote:
>> On 30/11/2020 20:07, Andy Shevchenko wrote:
>>> On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
> ...
>
>>> It's solely Windows driver design...
>>> Luckily I found some
On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally wrote:
> On 30/11/2020 20:07, Andy Shevchenko wrote:
> > On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
...
> > It's solely Windows driver design...
> > Luckily I found some information and can clarify above table:
> >
> > 0x00 Reset
Hi Andy, all
On 30/11/2020 20:07, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
>> On platforms where ACPI is designed for use with Windows, resources
>> that are intended to be consumed by sensor devices are sometimes in
>> the _CRS of a dummy INT3472
On Sun, Dec 13, 2020 at 10:48:39PM +, Daniel Scally wrote:
> On 01/12/2020 18:49, Andy Shevchenko wrote:
> +table_entry = (struct
> gpiod_lookup)GPIO_LOOKUP_IDX(acpi_dev_name(adev),
> +
>
On 01/12/2020 18:49, Andy Shevchenko wrote:
+ table_entry = (struct gpiod_lookup)GPIO_LOOKUP_IDX(acpi_dev_name(adev),
+
ares->data.gpio.pin_table[0],
+ func, 0,
On Thu, Dec 03, 2020 at 12:37:12PM +, Dan Scally wrote:
> On 02/12/2020 15:08, Andy Shevchenko wrote:
> > On Wed, Dec 02, 2020 at 02:42:28PM +0200, Laurent Pinchart wrote:
> >> On Wed, Dec 02, 2020 at 01:09:56PM +0200, Sakari Ailus wrote:
> >>> On Tue, Dec 01, 2020 at 08:37:58PM +0200, Laurent
On 02/12/2020 15:08, Andy Shevchenko wrote:
> On Wed, Dec 02, 2020 at 02:42:28PM +0200, Laurent Pinchart wrote:
>> On Wed, Dec 02, 2020 at 01:09:56PM +0200, Sakari Ailus wrote:
>>> On Tue, Dec 01, 2020 at 08:37:58PM +0200, Laurent Pinchart wrote:
>
> ...
>
>> I think we should consider ACPI to
On 02/12/2020 09:39, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 08:59:53PM +, Dan Scally wrote:
>> On 01/12/2020 18:49, Andy Shevchenko wrote:
>
> ...
>
>>> Seems we can do this, by locating intel_int3472.c under PDx86 hood and
>>> dropping
>>> ACPI ID table from TPS68470 MFD driver.
On Wed, Dec 02, 2020 at 02:48:47PM +0200, Laurent Pinchart wrote:
> On Tue, Dec 01, 2020 at 09:34:58PM +0100, Hans de Goede wrote:
> > On 12/1/20 8:21 PM, Andy Shevchenko wrote:
> > > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
...
> > > I would rather ask Hans' opinion
On Wed, Dec 02, 2020 at 02:35:40PM +0200, Laurent Pinchart wrote:
> On Wed, Dec 02, 2020 at 11:39:52AM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 08:59:53PM +, Dan Scally wrote:
> > > On 01/12/2020 18:49, Andy Shevchenko wrote:
...
> > I just realize that the name of int3472
On Wed, Dec 02, 2020 at 02:42:28PM +0200, Laurent Pinchart wrote:
> On Wed, Dec 02, 2020 at 01:09:56PM +0200, Sakari Ailus wrote:
> > On Tue, Dec 01, 2020 at 08:37:58PM +0200, Laurent Pinchart wrote:
...
> I think we should consider ACPI to be a hack in the first place :-)
I feel that about DT
Hi Hans,
On Tue, Dec 01, 2020 at 09:34:58PM +0100, Hans de Goede wrote:
> On 12/1/20 8:21 PM, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
> >> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
> >>> On Tue, Dec 01, 2020 at 08:55:48PM
On Wed, Dec 02, 2020 at 01:09:56PM +0200, Sakari Ailus wrote:
> Hi Laurent,
>
> On Tue, Dec 01, 2020 at 08:37:58PM +0200, Laurent Pinchart wrote:
> > Hi Sakari,
> >
> > On Tue, Dec 01, 2020 at 05:55:13PM +0200, Sakari Ailus wrote:
> > > On Tue, Dec 01, 2020 at 01:32:32AM +0200, Laurent Pinchart
On Wed, Dec 02, 2020 at 11:39:52AM +0200, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 08:59:53PM +, Dan Scally wrote:
> > On 01/12/2020 18:49, Andy Shevchenko wrote:
>
> ...
>
> > > Seems we can do this, by locating intel_int3472.c under PDx86 hood and
> > > dropping
> > > ACPI ID
Hi Laurent,
On Tue, Dec 01, 2020 at 08:37:58PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Tue, Dec 01, 2020 at 05:55:13PM +0200, Sakari Ailus wrote:
> > On Tue, Dec 01, 2020 at 01:32:32AM +0200, Laurent Pinchart wrote:
> > > On Mon, Nov 30, 2020 at 10:07:19PM +0200, Andy Shevchenko
On Tue, Dec 01, 2020 at 09:05:11PM +, Dan Scally wrote:
> On 01/12/2020 19:21, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
...
> > I would rather ask Hans' opinion since he has quite an expertise with DMI
> > for
> > good and bad.
> >
> I
On Tue, Dec 01, 2020 at 08:59:53PM +, Dan Scally wrote:
> On 01/12/2020 18:49, Andy Shevchenko wrote:
...
> > Seems we can do this, by locating intel_int3472.c under PDx86 hood and
> > dropping
> > ACPI ID table from TPS68470 MFD driver. The PMIC can be instantiated via
> >
On 01/12/2020 19:21, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
>> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
>>> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
>>>
Do you think the Windows driver would
Hi Andy
On 01/12/2020 18:49, Andy Shevchenko wrote:
> P.S. Dan, can you drop unrelated text when replying?
Ah - sure, sorry.
> Seems we can do this, by locating intel_int3472.c under PDx86 hood and
> dropping
> ACPI ID table from TPS68470 MFD driver. The PMIC can be instantiated via
>
On Tue, Dec 1, 2020 at 10:39 PM Hans de Goede wrote:
> On 12/1/20 8:21 PM, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
> >> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
> >>> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent
Hi,
On 12/1/20 8:21 PM, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
>> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
>>> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
On Tue, Dec 01, 2020 at 08:54:17PM
On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:
> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
> > > On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Dec 01,
On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
> > On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote:
> > > On Tue, Dec 01, 2020 at 08:30:03AM +, Dan Scally wrote:
> > > > On 30/11/2020 20:07,
On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
> On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 08:30:03AM +, Dan Scally wrote:
> > > On 30/11/2020 20:07, Andy Shevchenko wrote:
...
> > > >> +static struct
On Tue, Dec 01, 2020 at 12:48:28PM +, Dan Scally wrote:
> On 01/12/2020 12:32, Sakari Ailus wrote:
...
> Sorry, clarification here: The INT3472 driver in patch #18 runs probe()
> for the device representing a physical tps68470, but then -EINVAL's. The
> existing tps68470 mfd driver doesn't
On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
> On 30/11/2020 20:52, Sakari Ailus wrote:
> >> +static const struct acpi_device_id int3472_device_id[] = {
> >> + { "INT3472", 0 },
> > The INT3472 _HID is really allocated for the tps68470 PMIC chip. It may not
> > be used by other
Hi Andy,
On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 01, 2020 at 08:30:03AM +, Dan Scally wrote:
> > On 30/11/2020 20:07, Andy Shevchenko wrote:
>
> ...
>
> > >> +static struct int3472_sensor_regulator_map
> > >> int3472_sensor_regulator_maps[] = {
> > >>
On Tue, Dec 01, 2020 at 08:30:03AM +, Dan Scally wrote:
> On 30/11/2020 20:07, Andy Shevchenko wrote:
...
> >> +static struct int3472_sensor_regulator_map
> >> int3472_sensor_regulator_maps[] = {
> >> + { "GNDF140809R", 2, miix_510_ov2680 },
> >> + { "YHCU", 2, surface_go2_ov5693 },
> >>
On Tue, Dec 01, 2020 at 08:36:16PM +0200, Laurent Pinchart wrote:
> On Tue, Dec 01, 2020 at 08:31:39PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 30, 2020 at 11:20:55PM +, Dan Scally wrote:
> > > On 30/11/2020 16:17, Jean-Michel Hautbois wrote:
...
> > > but the ACPI table doesn't define
On Tue, Dec 01, 2020 at 01:32:32AM +0200, Laurent Pinchart wrote:
> On Mon, Nov 30, 2020 at 10:07:19PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
...
> > So, something like
> >
> > tps68470.h with API to consume
> > split tps68470 to
Hi Sakari,
On Tue, Dec 01, 2020 at 05:55:13PM +0200, Sakari Ailus wrote:
> On Tue, Dec 01, 2020 at 01:32:32AM +0200, Laurent Pinchart wrote:
> > On Mon, Nov 30, 2020 at 10:07:19PM +0200, Andy Shevchenko wrote:
> > > On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
> > > > On
Hi Andy,
On Tue, Dec 01, 2020 at 08:31:39PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 11:20:55PM +, Dan Scally wrote:
> > On 30/11/2020 16:17, Jean-Michel Hautbois wrote:
>
> ...
>
> > but the ACPI table doesn't define an I2CSerialBusV2 for it. Instead it's
> > rolled under
On Mon, Nov 30, 2020 at 11:20:55PM +, Dan Scally wrote:
> On 30/11/2020 16:17, Jean-Michel Hautbois wrote:
...
> but the ACPI table doesn't define an I2CSerialBusV2 for it. Instead it's
> rolled under the sensor's entry, there's a second entry in _CRS for the
> sensor that matches the
Hi Laurent,
On Tue, Dec 01, 2020 at 01:32:32AM +0200, Laurent Pinchart wrote:
> Hi Andy,
>
> On Mon, Nov 30, 2020 at 10:07:19PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
> > > On platforms where ACPI is designed for use with Windows,
On 01/12/2020 12:32, Sakari Ailus wrote:
> Hi Dan,
>
> On Tue, Dec 01, 2020 at 08:08:26AM +, Dan Scally wrote:
>> On 01/12/2020 06:44, Sakari Ailus wrote:
>>> Hi Dan,
>>>
>>> On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
Hi Sakari
On 30/11/2020 20:52, Sakari
On Tue, Dec 01, 2020 at 02:40:32PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Tue, Dec 01, 2020 at 02:32:44PM +0200, Sakari Ailus wrote:
> > On Tue, Dec 01, 2020 at 08:08:26AM +, Dan Scally wrote:
> > > On 01/12/2020 06:44, Sakari Ailus wrote:
> > > > On Mon, Nov 30, 2020 at
Hi Sakari,
On Tue, Dec 01, 2020 at 02:32:44PM +0200, Sakari Ailus wrote:
> On Tue, Dec 01, 2020 at 08:08:26AM +, Dan Scally wrote:
> > On 01/12/2020 06:44, Sakari Ailus wrote:
> > > On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
> > >> On 30/11/2020 20:52, Sakari Ailus wrote:
> >
Hi Dan,
On Tue, Dec 01, 2020 at 08:08:26AM +, Dan Scally wrote:
>
> On 01/12/2020 06:44, Sakari Ailus wrote:
> > Hi Dan,
> >
> > On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
> >> Hi Sakari
> >>
> >> On 30/11/2020 20:52, Sakari Ailus wrote:
> +static const struct
Hi Andy, thanks for comments
On 30/11/2020 20:07, Andy Shevchenko wrote:
>> We know that at least some of those pins have to be toggled active for the
>> sensor devices to be available in i2c, so the conclusion we came to was
>> that those GPIO entries assigned to the INT3472 device actually
On 01/12/2020 06:44, Sakari Ailus wrote:
> Hi Dan,
>
> On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
>> Hi Sakari
>>
>> On 30/11/2020 20:52, Sakari Ailus wrote:
+static const struct acpi_device_id int3472_device_id[] = {
+ { "INT3472", 0 },
>>> The INT3472 _HID is really
On 01/12/2020 08:08, Dan Scally wrote:
> On 01/12/2020 06:44, Sakari Ailus wrote:
>> Hi Dan,
>>
>> On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
>>> Hi Sakari
>>>
>>> On 30/11/2020 20:52, Sakari Ailus wrote:
> +static const struct acpi_device_id int3472_device_id[] = {
> +
Hi Dan,
On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
> Hi Sakari
>
> On 30/11/2020 20:52, Sakari Ailus wrote:
> >> +static const struct acpi_device_id int3472_device_id[] = {
> >> + { "INT3472", 0 },
> > The INT3472 _HID is really allocated for the tps68470 PMIC chip. It may not
On 30/11/2020 23:21, Laurent Pinchart wrote:
>>> Instead, I propose, that you add this as an option to the tps68470 driver
>>> that figures out whether the ACPI device for the tps68470 device actually
>>> describes something else, in a similar fashion you do with the cio2-bridge
>>> driver. I
Hi Andy,
On Mon, Nov 30, 2020 at 10:07:19PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
> > On platforms where ACPI is designed for use with Windows, resources
> > that are intended to be consumed by sensor devices are sometimes in
> > the _CRS
Hello,
On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
> On 30/11/2020 20:52, Sakari Ailus wrote:
> >> +static const struct acpi_device_id int3472_device_id[] = {
> >> + { "INT3472", 0 },
> >
> > The INT3472 _HID is really allocated for the tps68470 PMIC chip. It may not
> > be used
Hi Jean-Michel
On 30/11/2020 16:17, Jean-Michel Hautbois wrote:
>> We're guessing as to the exact meaning of the function byte, but I
>> conclude they're something like this:
>>
>> 0x00 - probably a reset GPIO
>> 0x01 - regulator for the sensor
>> 0x0c - regulator for the sensor
>> 0x0b -
Hi Sakari
On 30/11/2020 20:52, Sakari Ailus wrote:
>> +static const struct acpi_device_id int3472_device_id[] = {
>> +{ "INT3472", 0 },
> The INT3472 _HID is really allocated for the tps68470 PMIC chip. It may not
> be used by other drivers; people will want to build kernels where both of
>
Hi Daniel,
Thanks for the patch.
On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
> On platforms where ACPI is designed for use with Windows, resources
> that are intended to be consumed by sensor devices are sometimes in
> the _CRS of a dummy INT3472 device upon which the sensor
On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote:
> On platforms where ACPI is designed for use with Windows, resources
> that are intended to be consumed by sensor devices are sometimes in
> the _CRS of a dummy INT3472 device upon which the sensor depends. This
> driver binds to the
Hello,
On Mon, Nov 30, 2020 at 04:29:04PM +, Kieran Bingham wrote:
> On 30/11/2020 13:31, Daniel Scally wrote:
> > On platforms where ACPI is designed for use with Windows, resources
> > that are intended to be consumed by sensor devices are sometimes in
> > the _CRS of a dummy INT3472 device
Hi Daniel,
On 30/11/2020 13:31, Daniel Scally wrote:
> On platforms where ACPI is designed for use with Windows, resources
> that are intended to be consumed by sensor devices are sometimes in
> the _CRS of a dummy INT3472 device upon which the sensor depends. This
> driver binds to the dummy
Hi Daniel,
Thanks for the patch !
On 30/11/2020 14:31, Daniel Scally wrote:
> On platforms where ACPI is designed for use with Windows, resources
> that are intended to be consumed by sensor devices are sometimes in
> the _CRS of a dummy INT3472 device upon which the sensor depends. This
>
On platforms where ACPI is designed for use with Windows, resources
that are intended to be consumed by sensor devices are sometimes in
the _CRS of a dummy INT3472 device upon which the sensor depends. This
driver binds to the dummy acpi device (which does not represent a
physical PMIC) and maps
56 matches
Mail list logo
