i2c: designware: unhandled interrupt on N100 lpss channel 0

i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On a N100-based mini pc I see the following. I found older reports with the same symptom,
but root cause seems to be different.

- Interrupt 27 is not shared in my case
- I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
  are both 0.
- After an interrupt storm of 100,000 interrupts the interrupt gets disabled
- The issue affects channel 0 only

If not the I2C IP, then who else can touch the interrupt line?
May the BIOS play a role here? I have few ACPI errors on boot, and it seems the vendor
of this dirt-cheap device didn't give much love to the BIOS.


[    5.228854] irq 27: nobody cared (try booting with the "irqpoll" option)
[    5.228929] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-next-20240312+ #4
[    5.228981] Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
[    5.229045] Call Trace:
[    5.229065]  <IRQ>
[    5.229084]  dump_stack_lvl+0x81/0xe0
[    5.229125]  dump_stack+0x10/0x20
[    5.229154]  __report_bad_irq+0x2b/0xc0
[    5.229190]  note_interrupt+0x28f/0x2d0
[    5.229220]  ? __this_cpu_preempt_check+0x13/0x20
[    5.229262]  handle_irq_event+0x70/0x80
[    5.229296]  handle_fasteoi_irq+0x90/0x210
[    5.229331]  __common_interrupt+0x6f/0x140
[    5.229369]  common_interrupt+0xab/0xd0
[    5.229403]  </IRQ>
[    5.229420]  <TASK>
[    5.229440]  asm_common_interrupt+0x27/0x40
[    5.229476] RIP: 0010:cpuidle_enter_state+0xff/0x4f0
[    5.229516] Code: 8b 00 48 0f a3 05 c1 7f 9d 00 0f 82 fd 02 00 00 31 ff e8 a4 03 6a ff 80 7d cf 00 0f 85 cc 02 00 00 e8 15 e0 77 ff fb 45 85 ff <0f> 88 f4 01 00 00 49 63 f7 4c 89 f2 48 8d 04 76 48 8d 04 86 49 8d
[    5.229627] RSP: 0018:ffffa6c44016fe58 EFLAGS: 00000202
[    5.229668] RAX: 000000000007a19b RBX: ffffc6c43fcac660 RCX: 0000000000000000
[    5.229715] RDX: 0000000000000000 RSI: ffffffff89323d8f RDI: ffffffff8930f62b
[    5.229760] RBP: ffffa6c44016fe98 R08: 0000000000000001 R09: 0000000000000000
[    5.229806] R10: 0000000000000001 R11: ffffa2a0b7aad824 R12: 0000000000000001
[    5.229851] R13: ffffffff895b69a0 R14: 0000000137a9c564 R15: 0000000000000001
[    5.229907]  ? cpuidle_enter_state+0xfb/0x4f0
[    5.229946]  cpuidle_enter+0x29/0x40
[    5.229978]  call_cpuidle+0x1d/0x40
[    5.230010]  do_idle+0x1c2/0x220
[    5.230040]  cpu_startup_entry+0x24/0x30
[    5.230072]  start_secondary+0xf9/0x100
[    5.230105]  common_startup_64+0x13e/0x148
[    5.230148]  </TASK>
[    5.230166] handlers:
[    5.230185] [<00000000a498cda6>] i2c_dw_isr [i2c_designware_core]
[    5.230354] Disabling IRQ #27


            CPU0       CPU1       CPU2       CPU3
   8:          0          0          0          0  IR-IO-APIC    8-edge      rtc0
   9:          0         51          0          0  IR-IO-APIC    9-fasteoi   acpi
  16:          0          3          0          0  IR-IO-APIC   16-fasteoi   i801_smbus
  27:          0     100000          0          0  IR-IO-APIC   27-fasteoi   i2c_designware.0
  29:          0          0          0          0  IR-IO-APIC   29-fasteoi   i2c_designware.2
  31:          0          0          0          0  IR-IO-APIC   31-fasteoi   i2c_designware.4
  32:          0          0          0          0  IR-IO-APIC   32-fasteoi   i2c_designware.5
  33:          0          0          0          0  IR-IO-APIC   33-fasteoi   i2c_designware.3
  40:          0          0          0          0  IR-IO-APIC   40-fasteoi   i2c_designware.1

Thanks, Heiner

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On 19.03.2024 22:11, Heiner Kallweit wrote:
> On a N100-based mini pc I see the following. I found older reports with the same symptom,
> but root cause seems to be different.
> 
> - Interrupt 27 is not shared in my case
> - I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
>   are both 0.
> - After an interrupt storm of 100,000 interrupts the interrupt gets disabled
> - The issue affects channel 0 only
> 
> If not the I2C IP, then who else can touch the interrupt line?

I noticed that after including INTEL_IDMA64 in my config the problem no longer occurs.
So there seems to be a dependency. Should it be reflected in Kconfig, e.g.
make MFD_INTEL_LPSS dependent on INTEL_IDMA64, or let it imply INTEL_IDMA64?

> May the BIOS play a role here? I have few ACPI errors on boot, and it seems the vendor
> of this dirt-cheap device didn't give much love to the BIOS.
> 
> 
> [    5.228854] irq 27: nobody cared (try booting with the "irqpoll" option)
> [    5.228929] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-next-20240312+ #4
> [    5.228981] Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
> [    5.229045] Call Trace:
> [    5.229065]  <IRQ>
> [    5.229084]  dump_stack_lvl+0x81/0xe0
> [    5.229125]  dump_stack+0x10/0x20
> [    5.229154]  __report_bad_irq+0x2b/0xc0
> [    5.229190]  note_interrupt+0x28f/0x2d0
> [    5.229220]  ? __this_cpu_preempt_check+0x13/0x20
> [    5.229262]  handle_irq_event+0x70/0x80
> [    5.229296]  handle_fasteoi_irq+0x90/0x210
> [    5.229331]  __common_interrupt+0x6f/0x140
> [    5.229369]  common_interrupt+0xab/0xd0
> [    5.229403]  </IRQ>
> [    5.229420]  <TASK>
> [    5.229440]  asm_common_interrupt+0x27/0x40
> [    5.229476] RIP: 0010:cpuidle_enter_state+0xff/0x4f0
> [    5.229516] Code: 8b 00 48 0f a3 05 c1 7f 9d 00 0f 82 fd 02 00 00 31 ff e8 a4 03 6a ff 80 7d cf 00 0f 85 cc 02 00 00 e8 15 e0 77 ff fb 45 85 ff <0f> 88 f4 01 00 00 49 63 f7 4c 89 f2 48 8d 04 76 48 8d 04 86 49 8d
> [    5.229627] RSP: 0018:ffffa6c44016fe58 EFLAGS: 00000202
> [    5.229668] RAX: 000000000007a19b RBX: ffffc6c43fcac660 RCX: 0000000000000000
> [    5.229715] RDX: 0000000000000000 RSI: ffffffff89323d8f RDI: ffffffff8930f62b
> [    5.229760] RBP: ffffa6c44016fe98 R08: 0000000000000001 R09: 0000000000000000
> [    5.229806] R10: 0000000000000001 R11: ffffa2a0b7aad824 R12: 0000000000000001
> [    5.229851] R13: ffffffff895b69a0 R14: 0000000137a9c564 R15: 0000000000000001
> [    5.229907]  ? cpuidle_enter_state+0xfb/0x4f0
> [    5.229946]  cpuidle_enter+0x29/0x40
> [    5.229978]  call_cpuidle+0x1d/0x40
> [    5.230010]  do_idle+0x1c2/0x220
> [    5.230040]  cpu_startup_entry+0x24/0x30
> [    5.230072]  start_secondary+0xf9/0x100
> [    5.230105]  common_startup_64+0x13e/0x148
> [    5.230148]  </TASK>
> [    5.230166] handlers:
> [    5.230185] [<00000000a498cda6>] i2c_dw_isr [i2c_designware_core]
> [    5.230354] Disabling IRQ #27
> 
> 
>             CPU0       CPU1       CPU2       CPU3
>    8:          0          0          0          0  IR-IO-APIC    8-edge      rtc0
>    9:          0         51          0          0  IR-IO-APIC    9-fasteoi   acpi
>   16:          0          3          0          0  IR-IO-APIC   16-fasteoi   i801_smbus
>   27:          0     100000          0          0  IR-IO-APIC   27-fasteoi   i2c_designware.0
>   29:          0          0          0          0  IR-IO-APIC   29-fasteoi   i2c_designware.2
>   31:          0          0          0          0  IR-IO-APIC   31-fasteoi   i2c_designware.4
>   32:          0          0          0          0  IR-IO-APIC   32-fasteoi   i2c_designware.5
>   33:          0          0          0          0  IR-IO-APIC   33-fasteoi   i2c_designware.3
>   40:          0          0          0          0  IR-IO-APIC   40-fasteoi   i2c_designware.1
> 
> Thanks, Heiner

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Jarkko Nikula]

Hi

+ Andy

On 3/20/24 2:27 PM, Heiner Kallweit wrote:
> On 19.03.2024 22:11, Heiner Kallweit wrote:
>> On a N100-based mini pc I see the following. I found older reports with the same symptom,
>> but root cause seems to be different.
>>
>> - Interrupt 27 is not shared in my case
>> - I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
>>    are both 0.
>> - After an interrupt storm of 100,000 interrupts the interrupt gets disabled
>> - The issue affects channel 0 only
>>
>> If not the I2C IP, then who else can touch the interrupt line?
> 
> I noticed that after including INTEL_IDMA64 in my config the problem no longer occurs.
> So there seems to be a dependency. Should it be reflected in Kconfig, e.g.
> make MFD_INTEL_LPSS dependent on INTEL_IDMA64, or let it imply INTEL_IDMA64?
> 
Hmm.. interesting. I'd say BIOS perhaps has left the IDMA active and is 
generating interrupts until the idma64 driver acknowledges it.

There should not be generic dependency since the i2c_designware is not 
using the DMA and a quick test on one platform where idma64 and 
i2c_designware are sharing the same interrupt without 
CONFIG_INTEL_IDMA64 not set didn't show similar behavior.

Andy: Do you have any additional ideas or debug hints to this?

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Wed, Mar 20, 2024 at 03:37:34PM +0200, Jarkko Nikula wrote:
> On 3/20/24 2:27 PM, Heiner Kallweit wrote:
> > On 19.03.2024 22:11, Heiner Kallweit wrote:
> > > On a N100-based mini pc I see the following. I found older reports with the same symptom,
> > > but root cause seems to be different.
> > > 
> > > - Interrupt 27 is not shared in my case
> > > - I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
> > >    are both 0.
> > > - After an interrupt storm of 100,000 interrupts the interrupt gets disabled
> > > - The issue affects channel 0 only
> > > 
> > > If not the I2C IP, then who else can touch the interrupt line?
> > 
> > I noticed that after including INTEL_IDMA64 in my config the problem no longer occurs.
> > So there seems to be a dependency. Should it be reflected in Kconfig, e.g.
> > make MFD_INTEL_LPSS dependent on INTEL_IDMA64, or let it imply INTEL_IDMA64?
> > 
> Hmm.. interesting. I'd say BIOS perhaps has left the IDMA active and is
> generating interrupts until the idma64 driver acknowledges it.
> 
> There should not be generic dependency since the i2c_designware is not using
> the DMA and a quick test on one platform where idma64 and i2c_designware are
> sharing the same interrupt without CONFIG_INTEL_IDMA64 not set didn't show
> similar behavior.
> 
> Andy: Do you have any additional ideas or debug hints to this?

Can you share `cat /proc/interrupts` in non-working and working cases?

Just to confirm: loading idma64 driver fixes the issue, correct?

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On 20.03.2024 15:15, Andy Shevchenko wrote:
> On Wed, Mar 20, 2024 at 03:37:34PM +0200, Jarkko Nikula wrote:
>> On 3/20/24 2:27 PM, Heiner Kallweit wrote:
>>> On 19.03.2024 22:11, Heiner Kallweit wrote:
>>>> On a N100-based mini pc I see the following. I found older reports with the same symptom,
>>>> but root cause seems to be different.
>>>>
>>>> - Interrupt 27 is not shared in my case
>>>> - I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
>>>>    are both 0.
>>>> - After an interrupt storm of 100,000 interrupts the interrupt gets disabled
>>>> - The issue affects channel 0 only
>>>>
>>>> If not the I2C IP, then who else can touch the interrupt line?
>>>
>>> I noticed that after including INTEL_IDMA64 in my config the problem no longer occurs.
>>> So there seems to be a dependency. Should it be reflected in Kconfig, e.g.
>>> make MFD_INTEL_LPSS dependent on INTEL_IDMA64, or let it imply INTEL_IDMA64?
>>>
>> Hmm.. interesting. I'd say BIOS perhaps has left the IDMA active and is
>> generating interrupts until the idma64 driver acknowledges it.
>>
>> There should not be generic dependency since the i2c_designware is not using
>> the DMA and a quick test on one platform where idma64 and i2c_designware are
>> sharing the same interrupt without CONFIG_INTEL_IDMA64 not set didn't show
>> similar behavior.
>>
>> Andy: Do you have any additional ideas or debug hints to this?
> 
> Can you share `cat /proc/interrupts` in non-working and working cases?
> 
> Just to confirm: loading idma64 driver fixes the issue, correct?
> 
I spoke too soon. Loading idma64 didn't actually fix the problem.
What happened:
Runtime PM kicked in and set the device to D3. Therefore reads to the idma64
status register returned 0xffffffff, resulting the idma64 ISR returning
IRQ_HANDLED. IRQ number still was rapidly growing.

After disabling RPM the problem is back.
Who else could pull the level-triggered interrupt high?

[    4.642978] irq 27: nobody cared (try booting with the "irqpoll" option)
[    4.643067] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.8.0-next-20240312+ #5
[    4.643133] Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
[    4.643215] Call Trace:
[    4.643241]  <IRQ>
[    4.643266]  dump_stack_lvl+0x81/0xe0
[    4.643319]  dump_stack+0x10/0x20
[    4.643358]  __report_bad_irq+0x2b/0xc0
[    4.643403]  note_interrupt+0x28f/0x2d0
[    4.643442]  ? __this_cpu_preempt_check+0x13/0x20
[    4.643496]  handle_irq_event+0x70/0x80
[    4.643541]  handle_fasteoi_irq+0x90/0x210
[    4.643586]  __common_interrupt+0x6f/0x140
[    4.643633]  common_interrupt+0xab/0xd0
[    4.643672]  </IRQ>
[    4.643694]  <TASK>
[    4.643720]  asm_common_interrupt+0x27/0x40
[    4.643761] RIP: 0010:cpuidle_enter_state+0xff/0x4f0
[    4.643815] Code: 8b 00 48 0f a3 05 d1 5f 9d 00 0f 82 fd 02 00 00 31 ff e8 f4 e0 69 ff 80 7d cf 00 0f 85 cc 02 00 00 e8 65 bd 77 ff fb 45 85 ff <0f> 88 f4 01 00 00 49 63 f7 4c 89 f2 48 8d 04 76 48 8d 04 86 49 8d
[    4.643957] RSP: 0018:ffffb21dc017fe58 EFLAGS: 00000202
[    4.644010] RAX: 000000000007987d RBX: ffffd21dbfdac690 RCX: 0000000000000000
[    4.644069] RDX: 0000000000000000 RSI: ffffffff8f724a02 RDI: ffffffff8f710113
[    4.644128] RBP: ffffb21dc017fe98 R08: 0000000000000001 R09: 0000000000000000
[    4.644186] R10: 0000000000000001 R11: ffff91cfb7bad824 R12: 0000000000000001
[    4.644244] R13: ffffffff8f9b69a0 R14: 0000000114be1938 R15: 0000000000000001
[    4.644315]  ? cpuidle_enter_state+0xfb/0x4f0
[    4.644367]  cpuidle_enter+0x29/0x40
[    4.644409]  call_cpuidle+0x1d/0x40
[    4.644450]  do_idle+0x1c2/0x220
[    4.644489]  cpu_startup_entry+0x24/0x30
[    4.644529]  start_secondary+0xf9/0x100
[    4.644571]  common_startup_64+0x13e/0x148
[    4.644626]  </TASK>
[    4.644649] handlers:
[    4.644674] [<000000008b061326>] idma64_irq [idma64]
[    4.644852] [<000000008273d6d5>] i2c_dw_isr [i2c_designware_core]
[    4.644920] Disabling IRQ #27


            CPU0       CPU1       CPU2       CPU3
   8:          0          0          0          0  IR-IO-APIC    8-edge      rtc0
   9:          0         44          0          0  IR-IO-APIC    9-fasteoi   acpi
  16:          0          3          0          0  IR-IO-APIC   16-fasteoi   i801_smbus, idma64.6
  27:          0          0          0     112018  IR-IO-APIC   27-fasteoi   idma64.0, i2c_designware.0
  29:          0          0          0          0  IR-IO-APIC   29-fasteoi   idma64.2, i2c_designware.2
  31:          0          0          0          0  IR-IO-APIC   31-fasteoi   idma64.4, i2c_designware.4
  32:          0          0          0          0  IR-IO-APIC   32-fasteoi   idma64.5, i2c_designware.5
  33:          0          0          0          0  IR-IO-APIC   33-fasteoi   idma64.3, i2c_designware.3
  37:          0          0          0          0  IR-IO-APIC   37-fasteoi   idma64.7
  40:          0          0          0          0  IR-IO-APIC   40-fasteoi   idma64.1, i2c_designware.1

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
> On 20.03.2024 15:15, Andy Shevchenko wrote:
> > On Wed, Mar 20, 2024 at 03:37:34PM +0200, Jarkko Nikula wrote:
> >> On 3/20/24 2:27 PM, Heiner Kallweit wrote:
> >>> On 19.03.2024 22:11, Heiner Kallweit wrote:
> >>>> On a N100-based mini pc I see the following. I found older reports with the same symptom,
> >>>> but root cause seems to be different.
> >>>>
> >>>> - Interrupt 27 is not shared in my case
> >>>> - I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
> >>>>    are both 0.
> >>>> - After an interrupt storm of 100,000 interrupts the interrupt gets disabled
> >>>> - The issue affects channel 0 only
> >>>>
> >>>> If not the I2C IP, then who else can touch the interrupt line?
> >>>
> >>> I noticed that after including INTEL_IDMA64 in my config the problem no longer occurs.
> >>> So there seems to be a dependency. Should it be reflected in Kconfig, e.g.
> >>> make MFD_INTEL_LPSS dependent on INTEL_IDMA64, or let it imply INTEL_IDMA64?
> >>>
> >> Hmm.. interesting. I'd say BIOS perhaps has left the IDMA active and is
> >> generating interrupts until the idma64 driver acknowledges it.
> >>
> >> There should not be generic dependency since the i2c_designware is not using
> >> the DMA and a quick test on one platform where idma64 and i2c_designware are
> >> sharing the same interrupt without CONFIG_INTEL_IDMA64 not set didn't show
> >> similar behavior.
> >>
> >> Andy: Do you have any additional ideas or debug hints to this?
> > 
> > Can you share `cat /proc/interrupts` in non-working and working cases?
> > 
> > Just to confirm: loading idma64 driver fixes the issue, correct?
> > 
> I spoke too soon. Loading idma64 didn't actually fix the problem.
> What happened:
> Runtime PM kicked in and set the device to D3. Therefore reads to the idma64
> status register returned 0xffffffff, resulting the idma64 ISR returning
> IRQ_HANDLED.

Okay, bug in idma4 driver then :-) Good catch!

> IRQ number still was rapidly growing.
> 
> After disabling RPM the problem is back.
> Who else could pull the level-triggered interrupt high?

Need to understand a bit about RTE programming.
You need to add 'apic=debug' to the kernel command line and look for IRQ 27
related bits, and also makes sense to collect this

  grep 0000001b /sys/kernel/debug/pinctrl/*/pins

it will show the GPIO pins related to RTE 27 (and we can check if direct IRQ is
enabled there).

> [    4.642978] irq 27: nobody cared (try booting with the "irqpoll" option)
> [    4.643067] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.8.0-next-20240312+ #5
> [    4.643133] Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
> [    4.643215] Call Trace:
> [    4.643241]  <IRQ>
> [    4.643266]  dump_stack_lvl+0x81/0xe0
> [    4.643319]  dump_stack+0x10/0x20
> [    4.643358]  __report_bad_irq+0x2b/0xc0
> [    4.643403]  note_interrupt+0x28f/0x2d0
> [    4.643442]  ? __this_cpu_preempt_check+0x13/0x20
> [    4.643496]  handle_irq_event+0x70/0x80
> [    4.643541]  handle_fasteoi_irq+0x90/0x210
> [    4.643586]  __common_interrupt+0x6f/0x140
> [    4.643633]  common_interrupt+0xab/0xd0
> [    4.643672]  </IRQ>
> [    4.643694]  <TASK>
> [    4.643720]  asm_common_interrupt+0x27/0x40
> [    4.643761] RIP: 0010:cpuidle_enter_state+0xff/0x4f0
> [    4.643815] Code: 8b 00 48 0f a3 05 d1 5f 9d 00 0f 82 fd 02 00 00 31 ff e8 f4 e0 69 ff 80 7d cf 00 0f 85 cc 02 00 00 e8 65 bd 77 ff fb 45 85 ff <0f> 88 f4 01 00 00 49 63 f7 4c 89 f2 48 8d 04 76 48 8d 04 86 49 8d
> [    4.643957] RSP: 0018:ffffb21dc017fe58 EFLAGS: 00000202
> [    4.644010] RAX: 000000000007987d RBX: ffffd21dbfdac690 RCX: 0000000000000000
> [    4.644069] RDX: 0000000000000000 RSI: ffffffff8f724a02 RDI: ffffffff8f710113
> [    4.644128] RBP: ffffb21dc017fe98 R08: 0000000000000001 R09: 0000000000000000
> [    4.644186] R10: 0000000000000001 R11: ffff91cfb7bad824 R12: 0000000000000001
> [    4.644244] R13: ffffffff8f9b69a0 R14: 0000000114be1938 R15: 0000000000000001
> [    4.644315]  ? cpuidle_enter_state+0xfb/0x4f0
> [    4.644367]  cpuidle_enter+0x29/0x40
> [    4.644409]  call_cpuidle+0x1d/0x40
> [    4.644450]  do_idle+0x1c2/0x220
> [    4.644489]  cpu_startup_entry+0x24/0x30
> [    4.644529]  start_secondary+0xf9/0x100
> [    4.644571]  common_startup_64+0x13e/0x148
> [    4.644626]  </TASK>
> [    4.644649] handlers:
> [    4.644674] [<000000008b061326>] idma64_irq [idma64]
> [    4.644852] [<000000008273d6d5>] i2c_dw_isr [i2c_designware_core]
> [    4.644920] Disabling IRQ #27
> 
> 
>             CPU0       CPU1       CPU2       CPU3
>    8:          0          0          0          0  IR-IO-APIC    8-edge      rtc0
>    9:          0         44          0          0  IR-IO-APIC    9-fasteoi   acpi
>   16:          0          3          0          0  IR-IO-APIC   16-fasteoi   i801_smbus, idma64.6
>   27:          0          0          0     112018  IR-IO-APIC   27-fasteoi   idma64.0, i2c_designware.0
>   29:          0          0          0          0  IR-IO-APIC   29-fasteoi   idma64.2, i2c_designware.2
>   31:          0          0          0          0  IR-IO-APIC   31-fasteoi   idma64.4, i2c_designware.4
>   32:          0          0          0          0  IR-IO-APIC   32-fasteoi   idma64.5, i2c_designware.5
>   33:          0          0          0          0  IR-IO-APIC   33-fasteoi   idma64.3, i2c_designware.3
>   37:          0          0          0          0  IR-IO-APIC   37-fasteoi   idma64.7
>   40:          0          0          0          0  IR-IO-APIC   40-fasteoi   idma64.1, i2c_designware.1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On 20.03.2024 16:59, Andy Shevchenko wrote:
> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
>> On 20.03.2024 15:15, Andy Shevchenko wrote:
>>> On Wed, Mar 20, 2024 at 03:37:34PM +0200, Jarkko Nikula wrote:
>>>> On 3/20/24 2:27 PM, Heiner Kallweit wrote:
>>>>> On 19.03.2024 22:11, Heiner Kallweit wrote:
>>>>>> On a N100-based mini pc I see the following. I found older reports with the same symptom,
>>>>>> but root cause seems to be different.
>>>>>>
>>>>>> - Interrupt 27 is not shared in my case
>>>>>> - I checked register values on entering the ISR. Interrupt mask and DW_IC_RAW_INTR_STAT
>>>>>>    are both 0.
>>>>>> - After an interrupt storm of 100,000 interrupts the interrupt gets disabled
>>>>>> - The issue affects channel 0 only
>>>>>>
>>>>>> If not the I2C IP, then who else can touch the interrupt line?
>>>>>
>>>>> I noticed that after including INTEL_IDMA64 in my config the problem no longer occurs.
>>>>> So there seems to be a dependency. Should it be reflected in Kconfig, e.g.
>>>>> make MFD_INTEL_LPSS dependent on INTEL_IDMA64, or let it imply INTEL_IDMA64?
>>>>>
>>>> Hmm.. interesting. I'd say BIOS perhaps has left the IDMA active and is
>>>> generating interrupts until the idma64 driver acknowledges it.
>>>>
>>>> There should not be generic dependency since the i2c_designware is not using
>>>> the DMA and a quick test on one platform where idma64 and i2c_designware are
>>>> sharing the same interrupt without CONFIG_INTEL_IDMA64 not set didn't show
>>>> similar behavior.
>>>>
>>>> Andy: Do you have any additional ideas or debug hints to this?
>>>
>>> Can you share `cat /proc/interrupts` in non-working and working cases?
>>>
>>> Just to confirm: loading idma64 driver fixes the issue, correct?
>>>
>> I spoke too soon. Loading idma64 didn't actually fix the problem.
>> What happened:
>> Runtime PM kicked in and set the device to D3. Therefore reads to the idma64
>> status register returned 0xffffffff, resulting the idma64 ISR returning
>> IRQ_HANDLED.
> 
> Okay, bug in idma4 driver then :-) Good catch!
> 
>> IRQ number still was rapidly growing.
>>
>> After disabling RPM the problem is back.
>> Who else could pull the level-triggered interrupt high?
> 
> Need to understand a bit about RTE programming.
> You need to add 'apic=debug' to the kernel command line and look for IRQ 27
> related bits, and also makes sense to collect this

IOAPIC[0]: Preconfigured routing entry (2-27 -> IRQ 27 Level:1 ActiveLow:1)

For the sake of completeness I add below the output of dmesg | grep -i apic

> 
>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> 

pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]

> it will show the GPIO pins related to RTE 27 (and we can check if direct IRQ is
> enabled there).
> 
>> [    4.642978] irq 27: nobody cared (try booting with the "irqpoll" option)
>> [    4.643067] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.8.0-next-20240312+ #5
>> [    4.643133] Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
>> [    4.643215] Call Trace:
>> [    4.643241]  <IRQ>
>> [    4.643266]  dump_stack_lvl+0x81/0xe0
>> [    4.643319]  dump_stack+0x10/0x20
>> [    4.643358]  __report_bad_irq+0x2b/0xc0
>> [    4.643403]  note_interrupt+0x28f/0x2d0
>> [    4.643442]  ? __this_cpu_preempt_check+0x13/0x20
>> [    4.643496]  handle_irq_event+0x70/0x80
>> [    4.643541]  handle_fasteoi_irq+0x90/0x210
>> [    4.643586]  __common_interrupt+0x6f/0x140
>> [    4.643633]  common_interrupt+0xab/0xd0
>> [    4.643672]  </IRQ>
>> [    4.643694]  <TASK>
>> [    4.643720]  asm_common_interrupt+0x27/0x40
>> [    4.643761] RIP: 0010:cpuidle_enter_state+0xff/0x4f0
>> [    4.643815] Code: 8b 00 48 0f a3 05 d1 5f 9d 00 0f 82 fd 02 00 00 31 ff e8 f4 e0 69 ff 80 7d cf 00 0f 85 cc 02 00 00 e8 65 bd 77 ff fb 45 85 ff <0f> 88 f4 01 00 00 49 63 f7 4c 89 f2 48 8d 04 76 48 8d 04 86 49 8d
>> [    4.643957] RSP: 0018:ffffb21dc017fe58 EFLAGS: 00000202
>> [    4.644010] RAX: 000000000007987d RBX: ffffd21dbfdac690 RCX: 0000000000000000
>> [    4.644069] RDX: 0000000000000000 RSI: ffffffff8f724a02 RDI: ffffffff8f710113
>> [    4.644128] RBP: ffffb21dc017fe98 R08: 0000000000000001 R09: 0000000000000000
>> [    4.644186] R10: 0000000000000001 R11: ffff91cfb7bad824 R12: 0000000000000001
>> [    4.644244] R13: ffffffff8f9b69a0 R14: 0000000114be1938 R15: 0000000000000001
>> [    4.644315]  ? cpuidle_enter_state+0xfb/0x4f0
>> [    4.644367]  cpuidle_enter+0x29/0x40
>> [    4.644409]  call_cpuidle+0x1d/0x40
>> [    4.644450]  do_idle+0x1c2/0x220
>> [    4.644489]  cpu_startup_entry+0x24/0x30
>> [    4.644529]  start_secondary+0xf9/0x100
>> [    4.644571]  common_startup_64+0x13e/0x148
>> [    4.644626]  </TASK>
>> [    4.644649] handlers:
>> [    4.644674] [<000000008b061326>] idma64_irq [idma64]
>> [    4.644852] [<000000008273d6d5>] i2c_dw_isr [i2c_designware_core]
>> [    4.644920] Disabling IRQ #27
>>
>>
>>             CPU0       CPU1       CPU2       CPU3
>>    8:          0          0          0          0  IR-IO-APIC    8-edge      rtc0
>>    9:          0         44          0          0  IR-IO-APIC    9-fasteoi   acpi
>>   16:          0          3          0          0  IR-IO-APIC   16-fasteoi   i801_smbus, idma64.6
>>   27:          0          0          0     112018  IR-IO-APIC   27-fasteoi   idma64.0, i2c_designware.0
>>   29:          0          0          0          0  IR-IO-APIC   29-fasteoi   idma64.2, i2c_designware.2
>>   31:          0          0          0          0  IR-IO-APIC   31-fasteoi   idma64.4, i2c_designware.4
>>   32:          0          0          0          0  IR-IO-APIC   32-fasteoi   idma64.5, i2c_designware.5
>>   33:          0          0          0          0  IR-IO-APIC   33-fasteoi   idma64.3, i2c_designware.3
>>   37:          0          0          0          0  IR-IO-APIC   37-fasteoi   idma64.7
>>   40:          0          0          0          0  IR-IO-APIC   40-fasteoi   idma64.1, i2c_designware.1
>>
> 

[    0.000000] Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=/dev/nvme0n1p2 rw apic=debug
[    0.000000] APIC: Static calls initialized
[    0.001448] ACPI: APIC 0x000000007341E000 0001DC (v05 ALASKA A M I    01072009 AMI  01000013)
[    0.001547] ACPI: Reserving APIC table memory at [mem 0x7341e000-0x7341e1db]
[    0.001589] mapped APIC to ffffffffff5fc000 (        fee00000)
[    0.021194] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.021196] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.021198] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.021199] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.021201] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.021202] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.021203] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.021205] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[    0.021206] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[    0.021207] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[    0.021209] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[    0.021210] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[    0.021211] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[    0.021213] ACPI: LAPIC_NMI (acpi_id[0x0e] high edge lint[0x1])
[    0.021214] ACPI: LAPIC_NMI (acpi_id[0x0f] high edge lint[0x1])
[    0.021215] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[    0.021217] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[    0.021218] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[    0.021219] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[    0.021221] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[    0.021222] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[    0.021223] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[    0.021225] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[    0.021226] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.021279] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119
[    0.021287] Int: type 0, pol 0, trig 0, bus 00, IRQ 00, APIC ID 2, APIC INT 02
[    0.021292] Int: type 0, pol 1, trig 3, bus 00, IRQ 09, APIC ID 2, APIC INT 09
[    0.021295] Int: type 0, pol 0, trig 0, bus 00, IRQ 01, APIC ID 2, APIC INT 01
[    0.021297] Int: type 0, pol 0, trig 0, bus 00, IRQ 03, APIC ID 2, APIC INT 03
[    0.021299] Int: type 0, pol 0, trig 0, bus 00, IRQ 04, APIC ID 2, APIC INT 04
[    0.021300] Int: type 0, pol 0, trig 0, bus 00, IRQ 05, APIC ID 2, APIC INT 05
[    0.021302] Int: type 0, pol 0, trig 0, bus 00, IRQ 06, APIC ID 2, APIC INT 06
[    0.021304] Int: type 0, pol 0, trig 0, bus 00, IRQ 07, APIC ID 2, APIC INT 07
[    0.021306] Int: type 0, pol 0, trig 0, bus 00, IRQ 08, APIC ID 2, APIC INT 08
[    0.021307] Int: type 0, pol 0, trig 0, bus 00, IRQ 0a, APIC ID 2, APIC INT 0a
[    0.021309] Int: type 0, pol 0, trig 0, bus 00, IRQ 0b, APIC ID 2, APIC INT 0b
[    0.021311] Int: type 0, pol 0, trig 0, bus 00, IRQ 0c, APIC ID 2, APIC INT 0c
[    0.021313] Int: type 0, pol 0, trig 0, bus 00, IRQ 0d, APIC ID 2, APIC INT 0d
[    0.021314] Int: type 0, pol 0, trig 0, bus 00, IRQ 0e, APIC ID 2, APIC INT 0e
[    0.021316] Int: type 0, pol 0, trig 0, bus 00, IRQ 0f, APIC ID 2, APIC INT 0f
[    0.021345] mapped IOAPIC to ffffffffff5fb000 (fec00000)
[    0.021769] Kernel command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=/dev/nvme0n1p2 rw apic=debug
[    0.077440] APIC: Switch to symmetric I/O mode setup
[    0.077586] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.077618] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.079697] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.079716] x2apic enabled
[    0.079925] APIC: Switched APIC routing to: cluster x2apic
[    0.084973] ENABLING IO-APIC IRQs
[    0.084989] init IO_APIC IRQs
[    0.084991]  apic 2 pin 0 not connected
[    0.085011] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085036] IOAPIC[0]: Preconfigured routing entry (2-1 -> IRQ 1 Level:0 ActiveLow:0)
[    0.085046] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085065] IOAPIC[0]: Preconfigured routing entry (2-2 -> IRQ 0 Level:0 ActiveLow:0)
[    0.085074] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085092] IOAPIC[0]: Preconfigured routing entry (2-3 -> IRQ 3 Level:0 ActiveLow:0)
[    0.085100] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085119] IOAPIC[0]: Preconfigured routing entry (2-4 -> IRQ 4 Level:0 ActiveLow:0)
[    0.085131] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085149] IOAPIC[0]: Preconfigured routing entry (2-5 -> IRQ 5 Level:0 ActiveLow:0)
[    0.085158] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085176] IOAPIC[0]: Preconfigured routing entry (2-6 -> IRQ 6 Level:0 ActiveLow:0)
[    0.085184] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085203] IOAPIC[0]: Preconfigured routing entry (2-7 -> IRQ 7 Level:0 ActiveLow:0)
[    0.085210] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085229] IOAPIC[0]: Preconfigured routing entry (2-8 -> IRQ 8 Level:0 ActiveLow:0)
[    0.085237] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085255] IOAPIC[0]: Preconfigured routing entry (2-9 -> IRQ 9 Level:1 ActiveLow:0)
[    0.085263] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085282] IOAPIC[0]: Preconfigured routing entry (2-10 -> IRQ 10 Level:0 ActiveLow:0)
[    0.085291] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085309] IOAPIC[0]: Preconfigured routing entry (2-11 -> IRQ 11 Level:0 ActiveLow:0)
[    0.085325] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085343] IOAPIC[0]: Preconfigured routing entry (2-12 -> IRQ 12 Level:0 ActiveLow:0)
[    0.085351] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085369] IOAPIC[0]: Preconfigured routing entry (2-13 -> IRQ 13 Level:0 ActiveLow:0)
[    0.085377] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085395] IOAPIC[0]: Preconfigured routing entry (2-14 -> IRQ 14 Level:0 ActiveLow:0)
[    0.085403] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.085422] IOAPIC[0]: Preconfigured routing entry (2-15 -> IRQ 15 Level:0 ActiveLow:0)
[    0.085427]  apic 2 pin 16 not connected
[    0.085429]  apic 2 pin 17 not connected
[    0.085431]  apic 2 pin 18 not connected
[    0.085433]  apic 2 pin 19 not connected
[    0.085434]  apic 2 pin 20 not connected
[    0.085436]  apic 2 pin 21 not connected
[    0.085438]  apic 2 pin 22 not connected
[    0.085440]  apic 2 pin 23 not connected
[    0.085442]  apic 2 pin 24 not connected
[    0.085443]  apic 2 pin 25 not connected
[    0.085445]  apic 2 pin 26 not connected
[    0.085447]  apic 2 pin 27 not connected
[    0.085449]  apic 2 pin 28 not connected
[    0.085451]  apic 2 pin 29 not connected
[    0.085452]  apic 2 pin 30 not connected
[    0.085454]  apic 2 pin 31 not connected
[    0.085456]  apic 2 pin 32 not connected
[    0.085458]  apic 2 pin 33 not connected
[    0.085460]  apic 2 pin 34 not connected
[    0.085461]  apic 2 pin 35 not connected
[    0.085463]  apic 2 pin 36 not connected
[    0.085465]  apic 2 pin 37 not connected
[    0.085467]  apic 2 pin 38 not connected
[    0.085468]  apic 2 pin 39 not connected
[    0.085470]  apic 2 pin 40 not connected
[    0.085472]  apic 2 pin 41 not connected
[    0.085474]  apic 2 pin 42 not connected
[    0.085476]  apic 2 pin 43 not connected
[    0.085477]  apic 2 pin 44 not connected
[    0.085479]  apic 2 pin 45 not connected
[    0.085481]  apic 2 pin 46 not connected
[    0.085483]  apic 2 pin 47 not connected
[    0.085485]  apic 2 pin 48 not connected
[    0.085486]  apic 2 pin 49 not connected
[    0.085488]  apic 2 pin 50 not connected
[    0.085490]  apic 2 pin 51 not connected
[    0.085492]  apic 2 pin 52 not connected
[    0.085493]  apic 2 pin 53 not connected
[    0.085495]  apic 2 pin 54 not connected
[    0.085497]  apic 2 pin 55 not connected
[    0.085499]  apic 2 pin 56 not connected
[    0.085501]  apic 2 pin 57 not connected
[    0.085502]  apic 2 pin 58 not connected
[    0.085504]  apic 2 pin 59 not connected
[    0.085506]  apic 2 pin 60 not connected
[    0.085508]  apic 2 pin 61 not connected
[    0.085510]  apic 2 pin 62 not connected
[    0.085511]  apic 2 pin 63 not connected
[    0.085513]  apic 2 pin 64 not connected
[    0.085515]  apic 2 pin 65 not connected
[    0.085517]  apic 2 pin 66 not connected
[    0.085519]  apic 2 pin 67 not connected
[    0.085520]  apic 2 pin 68 not connected
[    0.085522]  apic 2 pin 69 not connected
[    0.085524]  apic 2 pin 70 not connected
[    0.085526]  apic 2 pin 71 not connected
[    0.085527]  apic 2 pin 72 not connected
[    0.085529]  apic 2 pin 73 not connected
[    0.085531]  apic 2 pin 74 not connected
[    0.085533]  apic 2 pin 75 not connected
[    0.085535]  apic 2 pin 76 not connected
[    0.085536]  apic 2 pin 77 not connected
[    0.085538]  apic 2 pin 78 not connected
[    0.085540]  apic 2 pin 79 not connected
[    0.085542]  apic 2 pin 80 not connected
[    0.085544]  apic 2 pin 81 not connected
[    0.085545]  apic 2 pin 82 not connected
[    0.085547]  apic 2 pin 83 not connected
[    0.085549]  apic 2 pin 84 not connected
[    0.085551]  apic 2 pin 85 not connected
[    0.085552]  apic 2 pin 86 not connected
[    0.085554]  apic 2 pin 87 not connected
[    0.085556]  apic 2 pin 88 not connected
[    0.085558]  apic 2 pin 89 not connected
[    0.085560]  apic 2 pin 90 not connected
[    0.085561]  apic 2 pin 91 not connected
[    0.085563]  apic 2 pin 92 not connected
[    0.085565]  apic 2 pin 93 not connected
[    0.085567]  apic 2 pin 94 not connected
[    0.085569]  apic 2 pin 95 not connected
[    0.085570]  apic 2 pin 96 not connected
[    0.085572]  apic 2 pin 97 not connected
[    0.085574]  apic 2 pin 98 not connected
[    0.085576]  apic 2 pin 99 not connected
[    0.085577]  apic 2 pin 100 not connected
[    0.085579]  apic 2 pin 101 not connected
[    0.085581]  apic 2 pin 102 not connected
[    0.085583]  apic 2 pin 103 not connected
[    0.085585]  apic 2 pin 104 not connected
[    0.085587]  apic 2 pin 105 not connected
[    0.085588]  apic 2 pin 106 not connected
[    0.085590]  apic 2 pin 107 not connected
[    0.085592]  apic 2 pin 108 not connected
[    0.085594]  apic 2 pin 109 not connected
[    0.085595]  apic 2 pin 110 not connected
[    0.085597]  apic 2 pin 111 not connected
[    0.085599]  apic 2 pin 112 not connected
[    0.085601]  apic 2 pin 113 not connected
[    0.085603]  apic 2 pin 114 not connected
[    0.085604]  apic 2 pin 115 not connected
[    0.085606]  apic 2 pin 116 not connected
[    0.085608]  apic 2 pin 117 not connected
[    0.085610]  apic 2 pin 118 not connected
[    0.085611]  apic 2 pin 119 not connected
[    0.439206] ACPI: Using IOAPIC for interrupt routing
[    0.888327] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.888340] IOAPIC[0]: Preconfigured routing entry (2-16 -> IRQ 16 Level:1 ActiveLow:1)
[    0.924695] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.924712] IOAPIC[0]: Preconfigured routing entry (2-18 -> IRQ 18 Level:1 ActiveLow:1)
[    0.926473] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.926487] IOAPIC[0]: Preconfigured routing entry (2-16 -> IRQ 16 Level:1 ActiveLow:1)
[    0.927996] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    0.928009] IOAPIC[0]: Preconfigured routing entry (2-19 -> IRQ 19 Level:1 ActiveLow:1)
[    0.950816] ... APIC ID:      00000000 (0)
[    0.950828] ... APIC VERSION: 01060015
[    0.950869] number of IO-APIC #2 registers: 120.
[    0.950870] testing the IO APIC.......................
[    0.950910] IO APIC #2......
[    0.950913] .......    : physical APIC id: 02
[    0.950921] .......     : IO APIC version: 20
[    0.950926] IOAPIC 0:
[    2.325225] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.325240] IOAPIC[0]: Preconfigured routing entry (2-27 -> IRQ 27 Level:1 ActiveLow:1)
[    2.351687] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.351698] IOAPIC[0]: Preconfigured routing entry (2-40 -> IRQ 40 Level:1 ActiveLow:1)
[    2.367659] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.367669] IOAPIC[0]: Preconfigured routing entry (2-29 -> IRQ 29 Level:1 ActiveLow:1)
[    2.385216] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.385228] IOAPIC[0]: Preconfigured routing entry (2-33 -> IRQ 33 Level:1 ActiveLow:1)
[    2.414104] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.414113] IOAPIC[0]: Preconfigured routing entry (2-31 -> IRQ 31 Level:1 ActiveLow:1)
[    2.427592] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.427603] IOAPIC[0]: Preconfigured routing entry (2-32 -> IRQ 32 Level:1 ActiveLow:1)
[    2.534690] IOAPIC[2]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:0 Avail:0 Vector:EF Dest:00000001 SID:00F7 SQ:0 SVT:1)
[    2.534700] IOAPIC[0]: Preconfigured routing entry (2-37 -> IRQ 37 Level:1 ActiveLow:1)

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
> On 20.03.2024 16:59, Andy Shevchenko wrote:
> > On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:

...

> >   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> 
> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]

I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
up/down can be enabled.

Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
the end of .probe:

	{
		void __iomem *padcfg0;
	        u32 value;

		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);

		value = readl(padcfg0);
		value |= PADCFG0_GPIOTXDIS;
		value |= PADCFG0_GPIORXDIS;
		writel(value, padcfg0);
	}

If it helps, it will show the BIOS bug (likely).

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Wed, Mar 20, 2024 at 11:07:53PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
> > On 20.03.2024 16:59, Andy Shevchenko wrote:
> > > On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:

...

> > >   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> > 
> > pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
> > pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> > pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> 
> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
> up/down can be enabled.
> 
> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
> the end of .probe:

(Meaning intel_pinctrl_probe() implementation)

> 	{
> 		void __iomem *padcfg0;
> 	        u32 value;
> 
> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);

It might also need

	        guard(raw_spinlock_irqsave)(&pctrl->lock);

just in case.

> 		value = readl(padcfg0);
> 		value |= PADCFG0_GPIOTXDIS;
> 		value |= PADCFG0_GPIORXDIS;
> 		writel(value, padcfg0);
> 	}
> 
> If it helps, it will show the BIOS bug (likely).

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On 20.03.2024 22:07, Andy Shevchenko wrote:
> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
>> On 20.03.2024 16:59, Andy Shevchenko wrote:
>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
> 
> ...
> 
>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
>>
>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> 
> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
> up/down can be enabled.
> 
Result is the same

> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
> the end of .probe:
> 
> 	{
> 		void __iomem *padcfg0;
> 	        u32 value;
> 
> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
> 
> 		value = readl(padcfg0);
> 		value |= PADCFG0_GPIOTXDIS;
> 		value |= PADCFG0_GPIORXDIS;
> 		writel(value, padcfg0);
> 	}
> 
> If it helps, it will show the BIOS bug (likely).
> 
Wow, this indeed fixes the issue for me. Thanks a lot!
For my understanding: Shall we (kernel driver) rely on the BIOS to configure
GPIO's properly? Or better assume that GPIO's are in an unknown state on
driver load and configure them for our needs?
IOW: If we assume that other systems may have similar issues, should "some driver"
use e.g. the pinctrl API to configure relevant pins?

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On 20.03.2024 22:26, Heiner Kallweit wrote:
> On 20.03.2024 22:07, Andy Shevchenko wrote:
>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
>>
>> ...
>>
>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
>>>
>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>
>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
>> up/down can be enabled.
>>
> Result is the same
> 
>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
>> the end of .probe:
>>
>> 	{
>> 		void __iomem *padcfg0;
>> 	        u32 value;
>>
>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
>>
>> 		value = readl(padcfg0);
>> 		value |= PADCFG0_GPIOTXDIS;
>> 		value |= PADCFG0_GPIORXDIS;
>> 		writel(value, padcfg0);
>> 	}
>>
>> If it helps, it will show the BIOS bug (likely).
>>
> Wow, this indeed fixes the issue for me. Thanks a lot!
> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
> GPIO's properly? Or better assume that GPIO's are in an unknown state on
> driver load and configure them for our needs?
> IOW: If we assume that other systems may have similar issues, should "some driver"
> use e.g. the pinctrl API to configure relevant pins?
> 
By the way: Great support! I wish I could get the same support level everywhere.

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
> On 20.03.2024 22:07, Andy Shevchenko wrote:
> > On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
> >> On 20.03.2024 16:59, Andy Shevchenko wrote:
> >>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:

...

> >>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> >>
> >> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
> >> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> > 
> > I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
> > up/down can be enabled.
> > 
> Result is the same
> 
> > Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
> > RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
> > the end of .probe:
> > 
> > 	{
> > 		void __iomem *padcfg0;
> > 	        u32 value;
> > 
> > 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
> > 
> > 		value = readl(padcfg0);
> > 		value |= PADCFG0_GPIOTXDIS;
> > 		value |= PADCFG0_GPIORXDIS;
> > 		writel(value, padcfg0);
> > 	}
> > 
> > If it helps, it will show the BIOS bug (likely).
> > 
> Wow, this indeed fixes the issue for me. Thanks a lot!

Wow! Glad to hear this.
(Side note, can you test the patch against idma64 I sent yesterday?
 Tested-by tag will be appreciated!)

We may try to have the quirk in the kernel, but it might be (quite) tricky
(see the link below).

Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
I would like to see if this pin is anyhow being mentioned in the DSDT.

> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
> GPIO's properly?

Yes, but there are bugs.
You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.

> Or better assume that GPIO's are in an unknown state on
> driver load and configure them for our needs?

It depends. But usually (> 99% cases) we rely on the firmware.

> IOW: If we assume that other systems may have similar issues, should
> "some driver" use e.g. the pinctrl API to configure relevant pins?


-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]

On 21.03.2024 12:20, Andy Shevchenko wrote:
> On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
>> On 20.03.2024 22:07, Andy Shevchenko wrote:
>>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
>>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
>>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
> 
> ...
> 
>>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
>>>>
>>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
>>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>>
>>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
>>> up/down can be enabled.
>>>
>> Result is the same
>>
>>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
>>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
>>> the end of .probe:
>>>
>>> 	{
>>> 		void __iomem *padcfg0;
>>> 	        u32 value;
>>>
>>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
>>>
>>> 		value = readl(padcfg0);
>>> 		value |= PADCFG0_GPIOTXDIS;
>>> 		value |= PADCFG0_GPIORXDIS;
>>> 		writel(value, padcfg0);
>>> 	}
>>>
>>> If it helps, it will show the BIOS bug (likely).
>>>
>> Wow, this indeed fixes the issue for me. Thanks a lot!
> 
> Wow! Glad to hear this.
> (Side note, can you test the patch against idma64 I sent yesterday?
>  Tested-by tag will be appreciated!)
> 
Done, sent the Tested-by

> We may try to have the quirk in the kernel, but it might be (quite) tricky
> (see the link below).
> 
> Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
> I would like to see if this pin is anyhow being mentioned in the DSDT.
> 
Attached. Compressed file isn't that big, so hope it's ok to send it
as an attachment.

>> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
>> GPIO's properly?
> 
> Yes, but there are bugs.
> You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.
> 
>> Or better assume that GPIO's are in an unknown state on
>> driver load and configure them for our needs?
> 
> It depends. But usually (> 99% cases) we rely on the firmware.
> 
>> IOW: If we assume that other systems may have similar issues, should
>> "some driver" use e.g. the pinctrl API to configure relevant pins?
> 
> 

[-- Attachment #2: n100-tables.dat.xz --]
[-- Type: application/octet-stream, Size: 311760 bytes --]

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Thu, Mar 21, 2024 at 12:59:59PM +0100, Heiner Kallweit wrote:
> On 21.03.2024 12:20, Andy Shevchenko wrote:
> > On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
> >> On 20.03.2024 22:07, Andy Shevchenko wrote:
> >>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
> >>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
> >>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:

...

> >>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> >>>>
> >>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
> >>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >>>
> >>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
> >>> up/down can be enabled.
> >>>
> >> Result is the same
> >>
> >>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
> >>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
> >>> the end of .probe:
> >>>
> >>> 	{
> >>> 		void __iomem *padcfg0;
> >>> 	        u32 value;
> >>>
> >>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
> >>>
> >>> 		value = readl(padcfg0);
> >>> 		value |= PADCFG0_GPIOTXDIS;
> >>> 		value |= PADCFG0_GPIORXDIS;
> >>> 		writel(value, padcfg0);
> >>> 	}
> >>>
> >>> If it helps, it will show the BIOS bug (likely).
> >>>
> >> Wow, this indeed fixes the issue for me. Thanks a lot!
> > 
> > Wow! Glad to hear this.
> > (Side note, can you test the patch against idma64 I sent yesterday?
> >  Tested-by tag will be appreciated!)
> > 
> Done, sent the Tested-by

Thank you!

> > We may try to have the quirk in the kernel, but it might be (quite) tricky
> > (see the link below).
> > 
> > Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
> > I would like to see if this pin is anyhow being mentioned in the DSDT.
> > 
> Attached. Compressed file isn't that big, so hope it's ok to send it
> as an attachment.

Yes, got it.

Can you also share the output of

1) `dmesg` (when kernel command line has 'ignore_loglevel apic=debug');
2) `lspci -nk -vv`;
3) `grep -H 15 /sys/bus/acpi/devices/*/status`?

> >> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
> >> GPIO's properly?
> > 
> > Yes, but there are bugs.
> > You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.
> > 
> >> Or better assume that GPIO's are in an unknown state on
> >> driver load and configure them for our needs?
> > 
> > It depends. But usually (> 99% cases) we rely on the firmware.
> > 
> >> IOW: If we assume that other systems may have similar issues, should
> >> "some driver" use e.g. the pinctrl API to configure relevant pins?

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

On 21.03.2024 18:33, Andy Shevchenko wrote:
> On Thu, Mar 21, 2024 at 12:59:59PM +0100, Heiner Kallweit wrote:
>> On 21.03.2024 12:20, Andy Shevchenko wrote:
>>> On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
>>>> On 20.03.2024 22:07, Andy Shevchenko wrote:
>>>>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
>>>>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
>>>>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
> 
> ...
> 
>>>>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
>>>>>>
>>>>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
>>>>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>>>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>>>>
>>>>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
>>>>> up/down can be enabled.
>>>>>
>>>> Result is the same
>>>>
>>>>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
>>>>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
>>>>> the end of .probe:
>>>>>
>>>>> 	{
>>>>> 		void __iomem *padcfg0;
>>>>> 	        u32 value;
>>>>>
>>>>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
>>>>>
>>>>> 		value = readl(padcfg0);
>>>>> 		value |= PADCFG0_GPIOTXDIS;
>>>>> 		value |= PADCFG0_GPIORXDIS;
>>>>> 		writel(value, padcfg0);
>>>>> 	}
>>>>>
>>>>> If it helps, it will show the BIOS bug (likely).
>>>>>
>>>> Wow, this indeed fixes the issue for me. Thanks a lot!
>>>
>>> Wow! Glad to hear this.
>>> (Side note, can you test the patch against idma64 I sent yesterday?
>>>  Tested-by tag will be appreciated!)
>>>
>> Done, sent the Tested-by
> 
> Thank you!
> 
>>> We may try to have the quirk in the kernel, but it might be (quite) tricky
>>> (see the link below).
>>>
>>> Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
>>> I would like to see if this pin is anyhow being mentioned in the DSDT.
>>>
>> Attached. Compressed file isn't that big, so hope it's ok to send it
>> as an attachment.
> 
> Yes, got it.
> 
> Can you also share the output of
> 
> 1) `dmesg` (when kernel command line has 'ignore_loglevel apic=debug');
attached
> 2) `lspci -nk -vv`;
attached
> 3) `grep -H 15 /sys/bus/acpi/devices/*/status`?
> 
/sys/bus/acpi/devices/ACPI0003:00/status:15
/sys/bus/acpi/devices/ACPI000C:00/status:15
/sys/bus/acpi/devices/ACPI000E:00/status:15
/sys/bus/acpi/devices/device:4a/status:15
/sys/bus/acpi/devices/device:86/status:15
/sys/bus/acpi/devices/device:87/status:15
/sys/bus/acpi/devices/device:88/status:15
/sys/bus/acpi/devices/device:8a/status:15
/sys/bus/acpi/devices/device:8b/status:15
/sys/bus/acpi/devices/device:8c/status:15
/sys/bus/acpi/devices/INT33A1:00/status:15
/sys/bus/acpi/devices/INTC1041:00/status:15
/sys/bus/acpi/devices/INTC1048:00/status:15
/sys/bus/acpi/devices/INTC1057:00/status:15
/sys/bus/acpi/devices/INTC1070:00/status:15
/sys/bus/acpi/devices/INTC1099:00/status:15
/sys/bus/acpi/devices/MSFT0001:00/status:15
/sys/bus/acpi/devices/OVTI01AS:00/status:15
/sys/bus/acpi/devices/OVTID858:00/status:15
/sys/bus/acpi/devices/PNP0103:00/status:15
/sys/bus/acpi/devices/PNP0C09:00/status:15
/sys/bus/acpi/devices/PNP0C0C:00/status:15
/sys/bus/acpi/devices/PNP0C0D:00/status:15
/sys/bus/acpi/devices/PRP00001:00/status:15
/sys/bus/acpi/devices/TXNW3643:00/status:15
/sys/bus/acpi/devices/TXNW3643:01/status:15

>>>> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
>>>> GPIO's properly?
>>>
>>> Yes, but there are bugs.
>>> You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.
>>>
>>>> Or better assume that GPIO's are in an unknown state on
>>>> driver load and configure them for our needs?
>>>
>>> It depends. But usually (> 99% cases) we rely on the firmware.
>>>
>>>> IOW: If we assume that other systems may have similar issues, should
>>>> "some driver" use e.g. the pinctrl API to configure relevant pins?
> 

[-- Attachment #2: dmesg.log.xz --]
[-- Type: application/octet-stream, Size: 17128 bytes --]

[-- Attachment #3: lspci.log.xz --]
[-- Type: application/octet-stream, Size: 4772 bytes --]

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Thu, Mar 21, 2024 at 10:00:27PM +0100, Heiner Kallweit wrote:
> On 21.03.2024 18:33, Andy Shevchenko wrote:
> > On Thu, Mar 21, 2024 at 12:59:59PM +0100, Heiner Kallweit wrote:
> >> On 21.03.2024 12:20, Andy Shevchenko wrote:
> >>> On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
> >>>> On 20.03.2024 22:07, Andy Shevchenko wrote:
> >>>>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
> >>>>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
> >>>>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:

...

> >>>>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> >>>>>>
> >>>>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
> >>>>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >>>>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >>>>>
> >>>>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
> >>>>> up/down can be enabled.
> >>>>>
> >>>> Result is the same
> >>>>
> >>>>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
> >>>>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
> >>>>> the end of .probe:
> >>>>>
> >>>>> 	{
> >>>>> 		void __iomem *padcfg0;
> >>>>> 	        u32 value;
> >>>>>
> >>>>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
> >>>>>
> >>>>> 		value = readl(padcfg0);
> >>>>> 		value |= PADCFG0_GPIOTXDIS;
> >>>>> 		value |= PADCFG0_GPIORXDIS;
> >>>>> 		writel(value, padcfg0);
> >>>>> 	}
> >>>>>
> >>>>> If it helps, it will show the BIOS bug (likely).
> >>>>>
> >>>> Wow, this indeed fixes the issue for me. Thanks a lot!
> >>>
> >>> Wow! Glad to hear this.
> >>> (Side note, can you test the patch against idma64 I sent yesterday?
> >>>  Tested-by tag will be appreciated!)
> >>>
> >> Done, sent the Tested-by
> > 
> > Thank you!
> > 
> >>> We may try to have the quirk in the kernel, but it might be (quite) tricky
> >>> (see the link below).
> >>>
> >>> Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
> >>> I would like to see if this pin is anyhow being mentioned in the DSDT.
> >>>
> >> Attached. Compressed file isn't that big, so hope it's ok to send it
> >> as an attachment.
> > 
> > Yes, got it.
> > 
> > Can you also share the output of
> > 
> > 1) `dmesg` (when kernel command line has 'ignore_loglevel apic=debug');
> attached
> > 2) `lspci -nk -vv`;
> attached
> > 3) `grep -H 15 /sys/bus/acpi/devices/*/status`?
> > 
> /sys/bus/acpi/devices/ACPI0003:00/status:15
> /sys/bus/acpi/devices/ACPI000C:00/status:15
> /sys/bus/acpi/devices/ACPI000E:00/status:15
> /sys/bus/acpi/devices/device:4a/status:15
> /sys/bus/acpi/devices/device:86/status:15
> /sys/bus/acpi/devices/device:87/status:15
> /sys/bus/acpi/devices/device:88/status:15
> /sys/bus/acpi/devices/device:8a/status:15
> /sys/bus/acpi/devices/device:8b/status:15
> /sys/bus/acpi/devices/device:8c/status:15
> /sys/bus/acpi/devices/INT33A1:00/status:15
> /sys/bus/acpi/devices/INTC1041:00/status:15
> /sys/bus/acpi/devices/INTC1048:00/status:15
> /sys/bus/acpi/devices/INTC1057:00/status:15
> /sys/bus/acpi/devices/INTC1070:00/status:15
> /sys/bus/acpi/devices/INTC1099:00/status:15
> /sys/bus/acpi/devices/MSFT0001:00/status:15
> /sys/bus/acpi/devices/OVTI01AS:00/status:15
> /sys/bus/acpi/devices/OVTID858:00/status:15
> /sys/bus/acpi/devices/PNP0103:00/status:15
> /sys/bus/acpi/devices/PNP0C09:00/status:15
> /sys/bus/acpi/devices/PNP0C0C:00/status:15
> /sys/bus/acpi/devices/PNP0C0D:00/status:15
> /sys/bus/acpi/devices/PRP00001:00/status:15
> /sys/bus/acpi/devices/TXNW3643:00/status:15
> /sys/bus/acpi/devices/TXNW3643:01/status:15

Can you also add this

 grep -H 15 /sys/bus/acpi/devices/*/status | while read x; do grep -H . `dirname $x`/path; done

?

> >>>> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
> >>>> GPIO's properly?
> >>>
> >>> Yes, but there are bugs.
> >>> You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.
> >>>
> >>>> Or better assume that GPIO's are in an unknown state on
> >>>> driver load and configure them for our needs?
> >>>
> >>> It depends. But usually (> 99% cases) we rely on the firmware.
> >>>
> >>>> IOW: If we assume that other systems may have similar issues, should
> >>>> "some driver" use e.g. the pinctrl API to configure relevant pins?

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

On 22.03.2024 17:18, Andy Shevchenko wrote:
> On Thu, Mar 21, 2024 at 10:00:27PM +0100, Heiner Kallweit wrote:
>> On 21.03.2024 18:33, Andy Shevchenko wrote:
>>> On Thu, Mar 21, 2024 at 12:59:59PM +0100, Heiner Kallweit wrote:
>>>> On 21.03.2024 12:20, Andy Shevchenko wrote:
>>>>> On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
>>>>>> On 20.03.2024 22:07, Andy Shevchenko wrote:
>>>>>>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
>>>>>>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
>>>>>>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:
> 
> ...
> 
>>>>>>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
>>>>>>>>
>>>>>>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
>>>>>>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>>>>>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
>>>>>>>
>>>>>>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
>>>>>>> up/down can be enabled.
>>>>>>>
>>>>>> Result is the same
>>>>>>
>>>>>>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
>>>>>>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
>>>>>>> the end of .probe:
>>>>>>>
>>>>>>> 	{
>>>>>>> 		void __iomem *padcfg0;
>>>>>>> 	        u32 value;
>>>>>>>
>>>>>>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
>>>>>>>
>>>>>>> 		value = readl(padcfg0);
>>>>>>> 		value |= PADCFG0_GPIOTXDIS;
>>>>>>> 		value |= PADCFG0_GPIORXDIS;
>>>>>>> 		writel(value, padcfg0);
>>>>>>> 	}
>>>>>>>
>>>>>>> If it helps, it will show the BIOS bug (likely).
>>>>>>>
>>>>>> Wow, this indeed fixes the issue for me. Thanks a lot!
>>>>>
>>>>> Wow! Glad to hear this.
>>>>> (Side note, can you test the patch against idma64 I sent yesterday?
>>>>>  Tested-by tag will be appreciated!)
>>>>>
>>>> Done, sent the Tested-by
>>>
>>> Thank you!
>>>
>>>>> We may try to have the quirk in the kernel, but it might be (quite) tricky
>>>>> (see the link below).
>>>>>
>>>>> Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
>>>>> I would like to see if this pin is anyhow being mentioned in the DSDT.
>>>>>
>>>> Attached. Compressed file isn't that big, so hope it's ok to send it
>>>> as an attachment.
>>>
>>> Yes, got it.
>>>
>>> Can you also share the output of
>>>
>>> 1) `dmesg` (when kernel command line has 'ignore_loglevel apic=debug');
>> attached
>>> 2) `lspci -nk -vv`;
>> attached
>>> 3) `grep -H 15 /sys/bus/acpi/devices/*/status`?
>>>
>> /sys/bus/acpi/devices/ACPI0003:00/status:15
>> /sys/bus/acpi/devices/ACPI000C:00/status:15
>> /sys/bus/acpi/devices/ACPI000E:00/status:15
>> /sys/bus/acpi/devices/device:4a/status:15
>> /sys/bus/acpi/devices/device:86/status:15
>> /sys/bus/acpi/devices/device:87/status:15
>> /sys/bus/acpi/devices/device:88/status:15
>> /sys/bus/acpi/devices/device:8a/status:15
>> /sys/bus/acpi/devices/device:8b/status:15
>> /sys/bus/acpi/devices/device:8c/status:15
>> /sys/bus/acpi/devices/INT33A1:00/status:15
>> /sys/bus/acpi/devices/INTC1041:00/status:15
>> /sys/bus/acpi/devices/INTC1048:00/status:15
>> /sys/bus/acpi/devices/INTC1057:00/status:15
>> /sys/bus/acpi/devices/INTC1070:00/status:15
>> /sys/bus/acpi/devices/INTC1099:00/status:15
>> /sys/bus/acpi/devices/MSFT0001:00/status:15
>> /sys/bus/acpi/devices/OVTI01AS:00/status:15
>> /sys/bus/acpi/devices/OVTID858:00/status:15
>> /sys/bus/acpi/devices/PNP0103:00/status:15
>> /sys/bus/acpi/devices/PNP0C09:00/status:15
>> /sys/bus/acpi/devices/PNP0C0C:00/status:15
>> /sys/bus/acpi/devices/PNP0C0D:00/status:15
>> /sys/bus/acpi/devices/PRP00001:00/status:15
>> /sys/bus/acpi/devices/TXNW3643:00/status:15
>> /sys/bus/acpi/devices/TXNW3643:01/status:15
> 
> Can you also add this
> 
>  grep -H 15 /sys/bus/acpi/devices/*/status | while read x; do grep -H . `dirname $x`/path; done
> 

/sys/bus/acpi/devices/ACPI0003:00/path:\_SB_.ADP1
/sys/bus/acpi/devices/ACPI000C:00/path:\_SB_.PAGD
/sys/bus/acpi/devices/ACPI000E:00/path:\_SB_.AWAC
/sys/bus/acpi/devices/device:4a/path:\_SB_.PC00.TCPU
/sys/bus/acpi/devices/device:86/path:\_SB_.PC00.THC0.TLC1
/sys/bus/acpi/devices/device:87/path:\_SB_.PC00.THC0.TLC2
/sys/bus/acpi/devices/device:88/path:\_SB_.PC00.THC0.TLC3
/sys/bus/acpi/devices/device:8a/path:\_SB_.PC00.THC1.TLC1
/sys/bus/acpi/devices/device:8b/path:\_SB_.PC00.THC1.TLC2
/sys/bus/acpi/devices/device:8c/path:\_SB_.PC00.THC1.TLC3
/sys/bus/acpi/devices/INT33A1:00/path:\_SB_.PEPD
/sys/bus/acpi/devices/INTC1041:00/path:\_SB_.IETM
/sys/bus/acpi/devices/INTC1048:00/path:\_SB_.PC00.LPCB.H_EC.TFN1
/sys/bus/acpi/devices/INTC1057:00/path:\_SB_.GPI0
/sys/bus/acpi/devices/INTC1070:00/path:\_SB_.HIDD
/sys/bus/acpi/devices/INTC1099:00/path:\_SB_.PC00.LPCB.CWDT
/sys/bus/acpi/devices/MSFT0001:00/path:\_SB_.PC00.LPCB.PS2K
/sys/bus/acpi/devices/OVTI01AS:00/path:\_SB_.PC00.LNK0
/sys/bus/acpi/devices/OVTID858:00/path:\_SB_.PC00.LNK1
/sys/bus/acpi/devices/PNP0103:00/path:\_SB_.PC00.LPCB.HPET
/sys/bus/acpi/devices/PNP0C09:00/path:\_SB_.PC00.LPCB.H_EC
/sys/bus/acpi/devices/PNP0C0C:00/path:\_SB_.PWRB
/sys/bus/acpi/devices/PNP0C0D:00/path:\_SB_.PC00.LPCB.H_EC.LID0
/sys/bus/acpi/devices/PRP00001:00/path:\_SB_.PC00.HDAS.IDA_.SNDW
/sys/bus/acpi/devices/TXNW3643:00/path:\_SB_.PC00.FLM0
/sys/bus/acpi/devices/TXNW3643:01/path:\_SB_.PC00.FLM1


> ?
> 
>>>>>> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
>>>>>> GPIO's properly?
>>>>>
>>>>> Yes, but there are bugs.
>>>>> You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.
>>>>>
>>>>>> Or better assume that GPIO's are in an unknown state on
>>>>>> driver load and configure them for our needs?
>>>>>
>>>>> It depends. But usually (> 99% cases) we rely on the firmware.
>>>>>
>>>>>> IOW: If we assume that other systems may have similar issues, should
>>>>>> "some driver" use e.g. the pinctrl API to configure relevant pins?
> 

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Fri, Mar 22, 2024 at 08:28:08PM +0100, Heiner Kallweit wrote:
> On 22.03.2024 17:18, Andy Shevchenko wrote:
> > On Thu, Mar 21, 2024 at 10:00:27PM +0100, Heiner Kallweit wrote:
> >> On 21.03.2024 18:33, Andy Shevchenko wrote:
> >>> On Thu, Mar 21, 2024 at 12:59:59PM +0100, Heiner Kallweit wrote:
> >>>> On 21.03.2024 12:20, Andy Shevchenko wrote:
> >>>>> On Wed, Mar 20, 2024 at 10:26:06PM +0100, Heiner Kallweit wrote:
> >>>>>> On 20.03.2024 22:07, Andy Shevchenko wrote:
> >>>>>>> On Wed, Mar 20, 2024 at 09:21:34PM +0100, Heiner Kallweit wrote:
> >>>>>>>> On 20.03.2024 16:59, Andy Shevchenko wrote:
> >>>>>>>>> On Wed, Mar 20, 2024 at 03:56:29PM +0100, Heiner Kallweit wrote:

...

> >>>>>>>>>   grep 0000001b /sys/kernel/debug/pinctrl/*/pins
> >>>>>>>>
> >>>>>>>> pin 3 (GPPC_B_3) 3:INTC1057:00 GPIO 0x80100102 0x0000001b 0x00000000 [LOCKED tx]
> >>>>>>>> pin 82 (GPP_F_7_EMMC_CMD) 135:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >>>>>>>> pin 182 (GPPC_C_13) 269:INTC1057:00 GPIO 0x44000300 0x0000001b 0x00000000 [LOCKED full, ACPI]
> >>>>>>>
> >>>>>>> I was not correct, the value to grep is '0000[0-3][0-9a-f]1b' as there pull
> >>>>>>> up/down can be enabled.
> >>>>>>>
> >>>>>> Result is the same
> >>>>>>
> >>>>>>> Nevertheless from the above the pin 3 is one that is enabled as GPIO input with
> >>>>>>> RTE 27 and direct IRQ.  If it's a culprit, try to add in the pinctrl-intel.c at
> >>>>>>> the end of .probe:
> >>>>>>>
> >>>>>>> 	{
> >>>>>>> 		void __iomem *padcfg0;
> >>>>>>> 	        u32 value;
> >>>>>>>
> >>>>>>> 		padcfg0 = intel_get_padcfg(pctrl, 3, PADCFG0);
> >>>>>>>
> >>>>>>> 		value = readl(padcfg0);
> >>>>>>> 		value |= PADCFG0_GPIOTXDIS;
> >>>>>>> 		value |= PADCFG0_GPIORXDIS;
> >>>>>>> 		writel(value, padcfg0);
> >>>>>>> 	}
> >>>>>>>
> >>>>>>> If it helps, it will show the BIOS bug (likely).
> >>>>>>>
> >>>>>> Wow, this indeed fixes the issue for me. Thanks a lot!
> >>>>>
> >>>>> Wow! Glad to hear this.
> >>>>> (Side note, can you test the patch against idma64 I sent yesterday?
> >>>>>  Tested-by tag will be appreciated!)
> >>>>>
> >>>> Done, sent the Tested-by
> >>>
> >>> Thank you!
> >>>
> >>>>> We may try to have the quirk in the kernel, but it might be (quite) tricky
> >>>>> (see the link below).
> >>>>>
> >>>>> Can you share `acpidump -o n100-tables.dat` (the file) somewhere?
> >>>>> I would like to see if this pin is anyhow being mentioned in the DSDT.
> >>>>>
> >>>> Attached. Compressed file isn't that big, so hope it's ok to send it
> >>>> as an attachment.
> >>>
> >>> Yes, got it.
> >>>
> >>> Can you also share the output of
> >>>
> >>> 1) `dmesg` (when kernel command line has 'ignore_loglevel apic=debug');
> >> attached
> >>> 2) `lspci -nk -vv`;
> >> attached
> >>> 3) `grep -H 15 /sys/bus/acpi/devices/*/status`?
> >>>
> >> /sys/bus/acpi/devices/ACPI0003:00/status:15
> >> /sys/bus/acpi/devices/ACPI000C:00/status:15
> >> /sys/bus/acpi/devices/ACPI000E:00/status:15
> >> /sys/bus/acpi/devices/device:4a/status:15
> >> /sys/bus/acpi/devices/device:86/status:15
> >> /sys/bus/acpi/devices/device:87/status:15
> >> /sys/bus/acpi/devices/device:88/status:15
> >> /sys/bus/acpi/devices/device:8a/status:15
> >> /sys/bus/acpi/devices/device:8b/status:15
> >> /sys/bus/acpi/devices/device:8c/status:15
> >> /sys/bus/acpi/devices/INT33A1:00/status:15
> >> /sys/bus/acpi/devices/INTC1041:00/status:15
> >> /sys/bus/acpi/devices/INTC1048:00/status:15
> >> /sys/bus/acpi/devices/INTC1057:00/status:15
> >> /sys/bus/acpi/devices/INTC1070:00/status:15
> >> /sys/bus/acpi/devices/INTC1099:00/status:15
> >> /sys/bus/acpi/devices/MSFT0001:00/status:15
> >> /sys/bus/acpi/devices/OVTI01AS:00/status:15
> >> /sys/bus/acpi/devices/OVTID858:00/status:15
> >> /sys/bus/acpi/devices/PNP0103:00/status:15
> >> /sys/bus/acpi/devices/PNP0C09:00/status:15
> >> /sys/bus/acpi/devices/PNP0C0C:00/status:15
> >> /sys/bus/acpi/devices/PNP0C0D:00/status:15
> >> /sys/bus/acpi/devices/PRP00001:00/status:15
> >> /sys/bus/acpi/devices/TXNW3643:00/status:15
> >> /sys/bus/acpi/devices/TXNW3643:01/status:15
> > 
> > Can you also add this
> > 
> >  grep -H 15 /sys/bus/acpi/devices/*/status | while read x; do grep -H . `dirname $x`/path; done
> > 
> 
> /sys/bus/acpi/devices/ACPI0003:00/path:\_SB_.ADP1
> /sys/bus/acpi/devices/ACPI000C:00/path:\_SB_.PAGD
> /sys/bus/acpi/devices/ACPI000E:00/path:\_SB_.AWAC
> /sys/bus/acpi/devices/device:4a/path:\_SB_.PC00.TCPU
> /sys/bus/acpi/devices/device:86/path:\_SB_.PC00.THC0.TLC1
> /sys/bus/acpi/devices/device:87/path:\_SB_.PC00.THC0.TLC2
> /sys/bus/acpi/devices/device:88/path:\_SB_.PC00.THC0.TLC3
> /sys/bus/acpi/devices/device:8a/path:\_SB_.PC00.THC1.TLC1
> /sys/bus/acpi/devices/device:8b/path:\_SB_.PC00.THC1.TLC2
> /sys/bus/acpi/devices/device:8c/path:\_SB_.PC00.THC1.TLC3
> /sys/bus/acpi/devices/INT33A1:00/path:\_SB_.PEPD
> /sys/bus/acpi/devices/INTC1041:00/path:\_SB_.IETM
> /sys/bus/acpi/devices/INTC1048:00/path:\_SB_.PC00.LPCB.H_EC.TFN1
> /sys/bus/acpi/devices/INTC1057:00/path:\_SB_.GPI0
> /sys/bus/acpi/devices/INTC1070:00/path:\_SB_.HIDD
> /sys/bus/acpi/devices/INTC1099:00/path:\_SB_.PC00.LPCB.CWDT
> /sys/bus/acpi/devices/MSFT0001:00/path:\_SB_.PC00.LPCB.PS2K
> /sys/bus/acpi/devices/OVTI01AS:00/path:\_SB_.PC00.LNK0
> /sys/bus/acpi/devices/OVTID858:00/path:\_SB_.PC00.LNK1
> /sys/bus/acpi/devices/PNP0103:00/path:\_SB_.PC00.LPCB.HPET
> /sys/bus/acpi/devices/PNP0C09:00/path:\_SB_.PC00.LPCB.H_EC
> /sys/bus/acpi/devices/PNP0C0C:00/path:\_SB_.PWRB
> /sys/bus/acpi/devices/PNP0C0D:00/path:\_SB_.PC00.LPCB.H_EC.LID0
> /sys/bus/acpi/devices/PRP00001:00/path:\_SB_.PC00.HDAS.IDA_.SNDW
> /sys/bus/acpi/devices/TXNW3643:00/path:\_SB_.PC00.FLM0
> /sys/bus/acpi/devices/TXNW3643:01/path:\_SB_.PC00.FLM1

Okay, from these and DSDT I see no active device using GPIO from DSDT.
So, the behaviour you have is definitely is a BIOS bug.

Let me and maybe others think if we can to work this around in the kernel
and if so, how.

> > ?
> > 
> >>>>>> For my understanding: Shall we (kernel driver) rely on the BIOS to configure
> >>>>>> GPIO's properly?
> >>>>>
> >>>>> Yes, but there are bugs.
> >>>>> You may look, e.g., https://bugzilla.kernel.org/show_bug.cgi?id=214749.
> >>>>>
> >>>>>> Or better assume that GPIO's are in an unknown state on
> >>>>>> driver load and configure them for our needs?
> >>>>>
> >>>>> It depends. But usually (> 99% cases) we rely on the firmware.
> >>>>>
> >>>>>> IOW: If we assume that other systems may have similar issues, should
> >>>>>> "some driver" use e.g. the pinctrl API to configure relevant pins?

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Andy Shevchenko]

On Tue, Apr 02, 2024 at 11:46:49PM +0300, Andy Shevchenko wrote:
> On Fri, Mar 22, 2024 at 08:28:08PM +0100, Heiner Kallweit wrote:

...

> Okay, from these and DSDT I see no active device using GPIO from DSDT.
> So, the behaviour you have is definitely is a BIOS bug.
> 
> Let me and maybe others think if we can to work this around in the kernel
> and if so, how.

Can you share output of `dmidecode`?

-- 
With Best Regards,
Andy Shevchenko

Re: i2c: designware: unhandled interrupt on N100 lpss channel 0

[Heiner Kallweit]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On 05.04.2024 18:01, Andy Shevchenko wrote:
> On Tue, Apr 02, 2024 at 11:46:49PM +0300, Andy Shevchenko wrote:
>> On Fri, Mar 22, 2024 at 08:28:08PM +0100, Heiner Kallweit wrote:
> 
> ...
> 
>> Okay, from these and DSDT I see no active device using GPIO from DSDT.
>> So, the behaviour you have is definitely is a BIOS bug.
>>
>> Let me and maybe others think if we can to work this around in the kernel
>> and if so, how.
> 
> Can you share output of `dmidecode`?
> 
is attached

[-- Attachment #2: dmidecode.txt.xz --]
[-- Type: application/octet-stream, Size: 4476 bytes --]