Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9d07309f-9596-2be0-97ab-2bb9ee237c11@mariushoch.de>
Date:   Sun, 18 Jun 2023 14:52:50 +0200
MIME-Version: 1.0
From:   Marius Hoch <mail@mariushoch.de>
Subject: Re: [PATCH 0/2] i2c: i801: Force no IRQ for Dell Latitude E7450
To:     Rudolf Marek <r.marek@assembler.cz>,
        Jean Delvare <jdelvare@suse.de>
Cc:     linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230514103634.235917-1-mail@mariushoch.de>
 <20230523200350.62ab4788@endymion.delvare>
 <59a6a917-2a93-d52d-37f3-091295dd0db4@mariushoch.de>
 <20230604160132.102dd6a7@endymion.delvare>
 <ae93843f-7ab0-9d10-cf93-261f986962a5@assembler.cz>
Content-Language: en-US
In-Reply-To: <ae93843f-7ab0-9d10-cf93-261f986962a5@assembler.cz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Rudolf,

thanks for the reply.

On 04/06/2023 22:41, Rudolf Marek wrote:
> Hi Jean,
>
> Dne 04. 06. 23 v 16:01 Jean Delvare napsal(a):
>> I admit I don't know. I'm not familiar with how GSI numbers relate to
>> IRQ numbers. I think I understand that GSI numbers are an ACPI thing,
>> and the ACPI layer is responsible for mapping these to actual IRQ
>> numbers? Is there a GSI-to-IRQ table available somewhere as part of the
>> ACPI tables? If so, it would be interesting to disassemble the ACPI
>> tables on your system and check what this looks like for you.
>
> You need to check _PRT method of PCI0 device in APIC mode.
> This will tell you to what GSI (APIC/pin) it goes.
> To check you need to have a look to the DSDT table and decompile
> it. You can obtain it by running acpidump > tables.txt and the 
> acpixtract -a tables.txt
> and finally running iasl -d dsdt.asl.
>
> Then, because the SMBUS lives on bus0, you just need to check _PRT method
> under PCI0 device for the entry of 001fffff (INT C).
> If this entry exists it will tell you where is it connected.
The PCI0 device's _PRT, when PICM is true, returns AR00. That contains:
             Package (0x04)
             {
                 0x001FFFFF,
                 0x02,
                 Zero,
                 0x12
             },

So according to this IRQ (=GSI?) 18 should be used (which, as mentioned 
earlier is also used for the freefall device). (In acpi_pci_irq_enable) 
acpi_register_gsi fails for this (with gsi=18) and afterwards dev->irq 
is at 255 (which might just be an initial value? dev->irq is only set in 
acpi_pci_irq_enable afterwards).

> I assume this has no entry and then as a last chance Linux tries the 
> PCI IRQ entry
> in the configuration space gets queried. And this has 0xff which is
> telling no IRQ connected.
>
> The southbridge has a IRQ routing configuration register which can be 
> used to verify
> if this is routed anywhere or really left "unconnected". This is 
> usually in the the RCBA base + something
> register. Have a look to "D31IP" register:
>
> SMBus Pin (SMIP) — R/W. Indicates which pin the SMBus controller 
> drives as its
> interrupt. bits 15:12
>
> If there is 0, it is not routed anywhere. Also you need to check 
> "D31IR" where the PIN C is going:
>
> Interrupt C Pin Route (ICR) — R/W. Indicates which physical pin on the 
> PCH is
> connected to the INTC# pin reported for device 31 functions.
>
> The PIRQA corresponds to the PIN 16 of IOAPIC etc.
>
> If you need more info on that feel free to contact me. I can try to help.
I skipped these steps (after identifying the _PRT entry) as it seems to 
me that we have a ACPI entry here (it's just not functional), thus this 
information would presumably be of no help.

Further help in debugging this would be much appreciated. In order to 
further see why acpi_register_gsi failed, I also got the irqdomain debug 
output and this also didn't help me (except that it doesn't register a 
domain for our SMBus, like "irq: Added domain IR-PCI-MSI-0000:00:XX").
>
>
> Thanks,
> Rudolf
>