On Sun, Feb 7, 2021 at 1:00 PM Daniel Scally wrote:
> On 21/01/2021 00:18, Daniel Scally wrote:
> > On 20/01/2021 12:57, Andy Shevchenko wrote:
...
> > I'm not sure that one's better than the other, to be honest. Either the
> > multi-function device functionality lives in the conventional
Hello Andy, Laurent
On 21/01/2021 00:18, Daniel Scally wrote:
> On 20/01/2021 12:57, Andy Shevchenko wrote:
>> On Wed, Jan 20, 2021 at 06:21:41AM +0200, Laurent Pinchart wrote:
>>> On Tue, Jan 19, 2021 at 07:51:14PM +0200, Andy Shevchenko wrote:
On Tue, Jan 19, 2021 at 06:48:15PM +0200,
Hi both
On 20/01/2021 11:44, Andy Shevchenko wrote:
> On Wed, Jan 20, 2021 at 06:18:53AM +0200, Laurent Pinchart wrote:
>> On Tue, Jan 19, 2021 at 07:43:15PM +0200, Andy Shevchenko wrote:
>>> On Tue, Jan 19, 2021 at 06:36:31PM +0200, Laurent Pinchart wrote:
On Tue, Jan 19, 2021 at 11:33:58AM
On 20/01/2021 12:57, Andy Shevchenko wrote:
> On Wed, Jan 20, 2021 at 06:21:41AM +0200, Laurent Pinchart wrote:
>> On Tue, Jan 19, 2021 at 07:51:14PM +0200, Andy Shevchenko wrote:
>>> On Tue, Jan 19, 2021 at 06:48:15PM +0200, Laurent Pinchart wrote:
On Tue, Jan 19, 2021 at 01:08:37PM +0200,
On Wed, Jan 20, 2021 at 06:21:41AM +0200, Laurent Pinchart wrote:
> On Tue, Jan 19, 2021 at 07:51:14PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 19, 2021 at 06:48:15PM +0200, Laurent Pinchart wrote:
> > > On Tue, Jan 19, 2021 at 01:08:37PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Jan 19,
On Wed, Jan 20, 2021 at 06:18:53AM +0200, Laurent Pinchart wrote:
> On Tue, Jan 19, 2021 at 07:43:15PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 19, 2021 at 06:36:31PM +0200, Laurent Pinchart wrote:
> > > On Tue, Jan 19, 2021 at 11:33:58AM +0200, Andy Shevchenko wrote:
> > > > On Tue, Jan 19,
Hi Andy,
On Tue, Jan 19, 2021 at 07:51:14PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 06:48:15PM +0200, Laurent Pinchart wrote:
> > On Tue, Jan 19, 2021 at 01:08:37PM +0200, Andy Shevchenko wrote:
> > > On Tue, Jan 19, 2021 at 10:40:42AM +, Daniel Scally wrote:
> > > > On
Hi Andy,
On Tue, Jan 19, 2021 at 07:43:15PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 06:36:31PM +0200, Laurent Pinchart wrote:
> > On Tue, Jan 19, 2021 at 11:33:58AM +0200, Andy Shevchenko wrote:
> > > On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> > > > On
On Tue, Jan 19, 2021 at 06:36:31PM +0200, Laurent Pinchart wrote:
> On Tue, Jan 19, 2021 at 11:33:58AM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> > > On 18/01/2021 21:19, Daniel Scally wrote:
...
> > See my previous reply. TL;DR: you have
On Tue, Jan 19, 2021 at 06:48:15PM +0200, Laurent Pinchart wrote:
> On Tue, Jan 19, 2021 at 01:08:37PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 19, 2021 at 10:40:42AM +, Daniel Scally wrote:
> > > On 19/01/2021 09:24, Andy Shevchenko wrote:
> > > > +static struct i2c_driver
On Tue, Jan 19, 2021 at 11:35:42AM +0200, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 08:21:23AM +0200, Laurent Pinchart wrote:
> > On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> > > On 18/01/2021 21:19, Daniel Scally wrote:
>
> ...
>
> > > (also, Laurent, if we did it
On Tue, Jan 19, 2021 at 01:08:37PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 10:40:42AM +, Daniel Scally wrote:
> > On 19/01/2021 09:24, Andy Shevchenko wrote:
> > > +static struct i2c_driver int3472_tps68470 = {
> > > + .driver = {
> > > + .name =
Hi Andy,
On Tue, Jan 19, 2021 at 11:33:58AM +0200, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> > On 18/01/2021 21:19, Daniel Scally wrote:
> >
> > I'm more and more confident that this will work, but it has some
> > knock-on effects:
> >
> > The both
Hi Daniel,
On Tue, Jan 19, 2021 at 08:43:43AM +, Daniel Scally wrote:
> On 19/01/2021 06:19, Laurent Pinchart wrote:
> > On Mon, Jan 18, 2021 at 08:46:34PM +, Daniel Scally wrote:
> >> Hi Laurent, thanks for the comments - really appreciate the detail.
> >>
> >> Some specific responses
On Tue, Jan 19, 2021 at 10:40:42AM +, Daniel Scally wrote:
> On 19/01/2021 09:24, Andy Shevchenko wrote:
> > +static struct i2c_driver int3472_tps68470 = {
> > + .driver = {
> > + .name = "int3472-tps68470",
> > + .acpi_match_table =
On 19/01/2021 11:11, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 10:56:17AM +, Kieran Bingham wrote:
>> On 18/01/2021 00:34, Daniel Scally wrote:
> ...
>
>>> +config INTEL_SKL_INT3472
>>> + tristate "Intel SkyLake ACPI INT3472 Driver"
>>> + depends on X86 && ACPI
>>> + select
On Tue, Jan 19, 2021 at 10:56:17AM +, Kieran Bingham wrote:
> On 18/01/2021 00:34, Daniel Scally wrote:
...
> > +config INTEL_SKL_INT3472
> > + tristate "Intel SkyLake ACPI INT3472 Driver"
> > + depends on X86 && ACPI
> > + select REGMAP_I2C
>
> I've tried compiling this as a built in
Hi Daniel,
On 18/01/2021 00:34, Daniel Scally wrote:
> ACPI devices with _HID INT3472 are currently matched to the tps68470
> driver, however this does not cover all situations in which that _HID
> occurs. We've encountered three possibilities:
>
> 1. On Chrome OS devices, an ACPI device with
On 19/01/2021 09:24, Andy Shevchenko wrote:
> +static struct i2c_driver int3472_tps68470 = {
> + .driver = {
> + .name = "int3472-tps68470",
> + .acpi_match_table = int3472_device_id,
> + },
> + .probe_new = skl_int3472_tps68470_probe,
> +};
>>> I'm
On Tue, Jan 19, 2021 at 08:21:23AM +0200, Laurent Pinchart wrote:
> On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> > On 18/01/2021 21:19, Daniel Scally wrote:
...
> > (also, Laurent, if we did it this way we wouldn't be able to also handle
> > the led-indicator GPIO here
On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> On 18/01/2021 21:19, Daniel Scally wrote:
> I'm more and more confident that this will work, but it has some
> knock-on effects:
>
> The both clk and regulator gpio driver expects to be able to fetch the
> GPIO using
Morning Andy
On 19/01/2021 09:33, Andy Shevchenko wrote:
> On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
>> On 18/01/2021 21:19, Daniel Scally wrote:
>> I'm more and more confident that this will work, but it has some
>> knock-on effects:
>>
>> The both clk and regulator gpio
On Mon, Jan 18, 2021 at 09:19:52PM +, Daniel Scally wrote:
> On 18/01/2021 14:46, Andy Shevchenko wrote:
> > On Mon, Jan 18, 2021 at 11:15:21AM +0200, Laurent Pinchart wrote:
> >> On Mon, Jan 18, 2021 at 12:34:27AM +, Daniel Scally wrote:
...
> >>> +static struct i2c_driver
Hi Laurent
On 19/01/2021 06:19, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Mon, Jan 18, 2021 at 08:46:34PM +, Daniel Scally wrote:
>> Hi Laurent, thanks for the comments - really appreciate the detail.
>>
>> Some specific responses below but assume a general "will do" to
>> everything you
Hi Daniel,
On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> On 18/01/2021 21:19, Daniel Scally wrote:
> +static const struct clk_ops skl_int3472_clock_ops = {
> +.prepare = skl_int3472_clk_prepare,
> +.unprepare = skl_int3472_clk_unprepare,
> +
Hi Daniel,
On Mon, Jan 18, 2021 at 08:46:34PM +, Daniel Scally wrote:
> Hi Laurent, thanks for the comments - really appreciate the detail.
>
> Some specific responses below but assume a general "will do" to
> everything you mentioned otherwise...
>
> On 18/01/2021 09:15, Laurent Pinchart
Hi Andy, Laurent
On 18/01/2021 21:19, Daniel Scally wrote:
+static const struct clk_ops skl_int3472_clock_ops = {
+ .prepare = skl_int3472_clk_prepare,
+ .unprepare = skl_int3472_clk_unprepare,
+ .enable = skl_int3472_clk_enable,
+ .disable = skl_int3472_clk_disable,
Hi Andy - thanks as always for the comments
Some responses below, but if not mentioned I'll follow your suggestion
of course
On 18/01/2021 14:46, Andy Shevchenko wrote:
> On Mon, Jan 18, 2021 at 11:15:21AM +0200, Laurent Pinchart wrote:
>> On Mon, Jan 18, 2021 at 12:34:27AM +, Daniel Scally
Hi Laurent, thanks for the comments - really appreciate the detail.
Some specific responses below but assume a general "will do" to
everything you mentioned otherwise...
On 18/01/2021 09:15, Laurent Pinchart wrote:
>> + PMIC) and one designed for Chrome OS.
> How about expanding this a bit
Hi Hans,
On Mon, Jan 18, 2021 at 04:32:54PM +0100, Hans de Goede wrote:
> On 1/18/21 4:23 PM, andriy.shevche...@linux.intel.com wrote:
> > On Mon, Jan 18, 2021 at 02:51:30PM +, Barnabás Pőcze wrote:
> >> 2021. január 18., hétfő 14:51 keltezéssel, Andy Shevchenko írta:
> >>
> >>> On Mon, Jan
Hi,
On 1/18/21 5:00 PM, Daniel Scally wrote:
>
> On 18/01/2021 15:48, andriy.shevche...@linux.intel.com wrote:
>> On Mon, Jan 18, 2021 at 04:32:54PM +0100, Hans de Goede wrote:
>>> On 1/18/21 4:23 PM, andriy.shevche...@linux.intel.com wrote:
>> ...
>>
>>> 1. Using a folder is fine, desirable
On 18/01/2021 15:48, andriy.shevche...@linux.intel.com wrote:
> On Mon, Jan 18, 2021 at 04:32:54PM +0100, Hans de Goede wrote:
>> On 1/18/21 4:23 PM, andriy.shevche...@linux.intel.com wrote:
> ...
>
>> 1. Using a folder is fine, desirable even
>> 2. I've some concerns about the name, but I'm not
On Mon, Jan 18, 2021 at 04:32:54PM +0100, Hans de Goede wrote:
> On 1/18/21 4:23 PM, andriy.shevche...@linux.intel.com wrote:
...
> 1. Using a folder is fine, desirable even
> 2. I've some concerns about the name, but I'm not really objecting,
> just giving my 2 cents.
Let's get into
Hi,
On 1/18/21 4:23 PM, andriy.shevche...@linux.intel.com wrote:
> On Mon, Jan 18, 2021 at 02:51:30PM +, Barnabás Pőcze wrote:
>> 2021. január 18., hétfő 14:51 keltezéssel, Andy Shevchenko írta:
>>
>>> On Mon, Jan 18, 2021 at 11:12:34AM +, Barnabás Pőcze wrote:
2021. január 18.,
On Mon, Jan 18, 2021 at 02:51:30PM +, Barnabás Pőcze wrote:
> 2021. január 18., hétfő 14:51 keltezéssel, Andy Shevchenko írta:
>
> > On Mon, Jan 18, 2021 at 11:12:34AM +, Barnabás Pőcze wrote:
> > > 2021. január 18., hétfő 1:34 keltezéssel, Daniel Scally írta:
> >
> > > Have you
2021. január 18., hétfő 14:51 keltezéssel, Andy Shevchenko írta:
> On Mon, Jan 18, 2021 at 11:12:34AM +, Barnabás Pőcze wrote:
> > 2021. január 18., hétfő 1:34 keltezéssel, Daniel Scally írta:
>
> > Have you considered putting the source (and header) files into a dedicated
> > folder? I think
On Mon, Jan 18, 2021 at 11:15:21AM +0200, Laurent Pinchart wrote:
> On Mon, Jan 18, 2021 at 12:34:27AM +, Daniel Scally wrote:
My comments on top of Laurent's to avoid dups.
First of all, PDx86 has its own prefix pattern: "platform/x86: ..."
> > ACPI devices with _HID INT3472 are currently
On Mon, Jan 18, 2021 at 11:12:34AM +, Barnabás Pőcze wrote:
> 2021. január 18., hétfő 1:34 keltezéssel, Daniel Scally írta:
> Have you considered putting the source (and header) files into a dedicated
> folder? I think it'd help manageability in the long run, and it'd be
> immediately
>
Hi
2021. január 18., hétfő 1:34 keltezéssel, Daniel Scally írta:
> ACPI devices with _HID INT3472 are currently matched to the tps68470
> driver, however this does not cover all situations in which that _HID
> occurs. We've encountered three possibilities:
>
> 1. On Chrome OS devices, an ACPI
Hi Daniel,
Thank you for the patch.
On Mon, Jan 18, 2021 at 12:34:27AM +, Daniel Scally wrote:
> ACPI devices with _HID INT3472 are currently matched to the tps68470
> driver, however this does not cover all situations in which that _HID
> occurs. We've encountered three possibilities:
>
>
ACPI devices with _HID INT3472 are currently matched to the tps68470
driver, however this does not cover all situations in which that _HID
occurs. We've encountered three possibilities:
1. On Chrome OS devices, an ACPI device with _HID INT3472 (representing
a physical tps68470 device) that
41 matches
Mail list logo
