Re: your mail

Re: your mail

[Heikki Krogerus]

+Andy

Adding also the linux-usb mailing list.

On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> with cpu interrups causing issues with deeper CPU sleep and increased power
> usage. Also load is always 1 even if machine has nothing to do.
>  
> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> device is related with USB and according to datasheet it's "USB Interface IC USB
> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> nothing connected to NUC except power plug and ethernet cable.
>  
> Screenshots: https://imgur.com/a/uw9NDCi
>  
> How to solve this issue? Could you help me?

My guess is that the IRQ resource is not correct for the PD
controller causing you to see irq flood.

The problem is that the ACPI device entry (the node) on this platform
has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
single ACPI device entry can represent up to 4 USB PD controllers. The
problem is that there is no way to know which IRQ resource belongs to
which I2CSerialBus resource :-(.

Andy, this is one of those multi-instantiate I2C slave devices with
HID INT3515.

The only solution I can think of is that we start maintaining DMI
quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
supply the correct i2c to irq resource mapping for every platform
that has this device(s).

> Kernel version:
>  
> Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>  
> Bios version:
> FNCML357 Version: 0039 Date: 3/12/2020
> -- 
> Best regards
> Jakub Bilan

thanks,

-- 
heikki

Re: your mail

[Andy Shevchenko]

+Cc: Hans

On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> +Andy
>
> Adding also the linux-usb mailing list.
>
> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> > Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> > with cpu interrups causing issues with deeper CPU sleep and increased power
> > usage. Also load is always 1 even if machine has nothing to do.
> >
> > I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> > device is related with USB and according to datasheet it's "USB Interface IC USB
> > Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> > nothing connected to NUC except power plug and ethernet cable.
> >
> > Screenshots: https://imgur.com/a/uw9NDCi
> >
> > How to solve this issue? Could you help me?
>
> My guess is that the IRQ resource is not correct for the PD
> controller causing you to see irq flood.
>
> The problem is that the ACPI device entry (the node) on this platform
> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
> single ACPI device entry can represent up to 4 USB PD controllers. The
> problem is that there is no way to know which IRQ resource belongs to
> which I2CSerialBus resource :-(.
>
> Andy, this is one of those multi-instantiate I2C slave devices with
> HID INT3515.
>
> The only solution I can think of is that we start maintaining DMI
> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
> supply the correct i2c to irq resource mapping for every platform
> that has this device(s).

I would rather disable them and issue a firmware bug.
Vendors, including us, should do something sane about this.

> > Kernel version:
> >
> > Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > Bios version:
> > FNCML357 Version: 0039 Date: 3/12/2020

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Hans de Goede]

Hi,

On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> +Cc: Hans

Thank you, I'm afraid that I do not have much of value
to add here, Heikki knows these systems (with an INT3515 device)
a lot better then I do.

> On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
>>
>> +Andy
>>
>> Adding also the linux-usb mailing list.
>>
>> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
>>> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
>>> with cpu interrups causing issues with deeper CPU sleep and increased power
>>> usage. Also load is always 1 even if machine has nothing to do.
>>>
>>> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
>>> device is related with USB and according to datasheet it's "USB Interface IC USB
>>> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
>>> nothing connected to NUC except power plug and ethernet cable.
>>>
>>> Screenshots: https://imgur.com/a/uw9NDCi
>>>
>>> How to solve this issue? Could you help me?
>>
>> My guess is that the IRQ resource is not correct for the PD
>> controller causing you to see irq flood.
>>
>> The problem is that the ACPI device entry (the node) on this platform
>> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
>> single ACPI device entry can represent up to 4 USB PD controllers. The
>> problem is that there is no way to know which IRQ resource belongs to
>> which I2CSerialBus resource :-(.
>>
>> Andy, this is one of those multi-instantiate I2C slave devices with
>> HID INT3515.
>>
>> The only solution I can think of is that we start maintaining DMI
>> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
>> supply the correct i2c to irq resource mapping for every platform
>> that has this device(s).
> 
> I would rather disable them and issue a firmware bug.
> Vendors, including us, should do something sane about this.

I have to partially disagree here. I agree that for future hardware
versions the firmware team of those devices should offer a saner
interface. But for the current hardware gen I guess we are stuck
with this and having a DMI table for popular models (well any model
a Linux user is willing to submit a quirk for) is better then simply
not having things working under Linux.

I do wonder what Windows does here though. Perhaps the INT3513 device
has some ACPI methods to query for more info, like how many Type-C
controllers there actually are?

Regards,

Hans

Re: your mail

[Andy Shevchenko]

On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@redhat.com> wrote:
> On 5/11/20 1:44 PM, Andy Shevchenko wrote:

...

> > I would rather disable them and issue a firmware bug.
> > Vendors, including us, should do something sane about this.
>
> I have to partially disagree here. I agree that for future hardware
> versions the firmware team of those devices should offer a saner
> interface. But for the current hardware gen I guess we are stuck
> with this and having a DMI table for popular models (well any model
> a Linux user is willing to submit a quirk for) is better then simply
> not having things working under Linux.
>
> I do wonder what Windows does here though. Perhaps the INT3513 device
> has some ACPI methods to query for more info, like how many Type-C
> controllers there actually are?

I think they do silly things there in usual obscure MS way, i.e.
hardcoding everything in the driver per platform.
That's why I'm really disappointed how things are going on.

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Heikki Krogerus]

Hi Jakub,

On Mon, May 11, 2020 at 04:40:05PM +0300, Andy Shevchenko wrote:
> On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@redhat.com> wrote:
> > On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> 
> ...
> 
> > > I would rather disable them and issue a firmware bug.
> > > Vendors, including us, should do something sane about this.
> >
> > I have to partially disagree here. I agree that for future hardware
> > versions the firmware team of those devices should offer a saner
> > interface. But for the current hardware gen I guess we are stuck
> > with this and having a DMI table for popular models (well any model
> > a Linux user is willing to submit a quirk for) is better then simply
> > not having things working under Linux.
> >
> > I do wonder what Windows does here though. Perhaps the INT3513 device
> > has some ACPI methods to query for more info, like how many Type-C
> > controllers there actually are?
> 
> I think they do silly things there in usual obscure MS way, i.e.
> hardcoding everything in the driver per platform.
> That's why I'm really disappointed how things are going on.

I've been trying to figure out which exact NUC10i3 your NUC is? I
can't find a NUC10i3 that uses Comet Lake -S?

If your NUC isn't actually "-S" variant, then the ACPI device entry
with HID INT3515 should return 0 from its _STA method.

But can you please share the full name of your board (like NUC10i3FNH
or something like that - should read on the bottom of the device).
Also, dmesg output would be useful.

thanks,

-- 
heikki