On Fri, May 18, 2018 at 9:32 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> Hi,
>
>
> On 17-05-18 20:14, Dmitry Torokhov wrote:
>>
>> On Thu, May 17, 2018 at 2:36 AM, Benjamin Tissoires
>> <benjamin.tissoires@xxxxxxxxx> wrote:
>>>
>>> Scope (_SB.PCI0.I2C1)
>>> {
>>> Device (ETPD)
>>> {
>>> Name (SBFB, ResourceTemplate ()
>>> {
>>> I2cSerialBusV2 (0x004C, ControllerInitiated, 0x00061A80,
>>> AddressingMode7Bit, "\\_SB.PCI0.I2C1",
>>> 0x00, ResourceConsumer, _Y34, Exclusive,
>>> )
>>> })
>>> Name (SBFI, ResourceTemplate ()
>>> {
>>> Interrupt (ResourceConsumer, Level, ActiveHigh,
>>> Exclusive, ,, )
>>> {
>>> 0x0000005F,
>>> }
>>> })
>>
>> ...
>>>
>>>
>>> So nothing scary, the interrupt is a plain interrupt, not a GPIO. I
>>> guess the issue lies in i2c-designware and the AMD implementation...
>>
>>
>> Also, in dmesg we have:
>>
>> [ 25.020612] cannonlake-pinctrl INT3450:00: pin 26 cannot be used as IRQ
>> [ 25.020615] genirq: Setting trigger mode 3 for irq 137 failed
>> (intel_gpio_irq_type+0x0/0x140)
>> [ 25.023113] intel-lpss 0000:00:15.1: enabling device (0000 -> 0002)
>> [ 25.023336] idma64 idma64.1: Found Intel integrated DMA 64-bit
>> [ 25.025326] i2c_hid i2c-ELAN1201:00: i2c-ELAN1201:00 supply vdd not
>> found, using dummy regulator
>> [ 25.025494] i2c_designware i2c_designware.1:
>> i2c_dw_handle_tx_abort: lost arbitration
>> [ 25.025652] i2c_designware i2c_designware.1:
>> i2c_dw_handle_tx_abort: lost arbitration
>> [ 25.025811] i2c_designware i2c_designware.1:
>> i2c_dw_handle_tx_abort: lost arbitration
>> [ 25.025970] i2c_designware i2c_designware.1:
>> i2c_dw_handle_tx_abort: lost arbitration
>> [ 25.025972] i2c_hid i2c-ELAN1201:00: hid_descr_cmd failed
>>
>> 0x5F is kind of high for a plain interrupt; I wonder if ACPI table
>> relies on static gpio->virq mapping that could be different on
>> Linux... Also I am surprised the IRQ is active-HIGH, normally it is
>> active low. Might want to try and hack the driver to force it to low
>> and see what happens...
>
>
> Yes the interrupt is definitely suspect. Actually using plain interrupts
> rather then a GpioInt is something which I would only expect to see in
> old DSDTs and not in recent ones, because for i2c devices there is
> no clear parent interrupt controller and as such no well defined way to
> properly interpret a raw Interrupt number.
>
> What is with the AMD reference btw, the above dmesg snippet looks
> to be about an Intel system? I would not expect cannonlake-pinctrl
> to be used on an AMD system...
>
My bad, I overlooked the dmesg, and when trying to find the CPU type,
the following caught my eye and my brain did not process it correctly:
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
Cheers,
Benjamin
