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...
If this indeed is an Intel system one thing worth trying is
changing the clk_freq we use in the i2c-designware driver to
calculate clk high and low counts. There are some reports from
people attaching scopes to the i2c wires that on kabylake at
least the driver is driving the bus about 1.5 times the
expected rate (so 600KHz instead of 400KHz).
A workaround for now would be to edit:
drivers/mfd/intel-lpss-pci.c
And change clk_rate in:
static const struct intel_lpss_platform_info spt_i2c_info = {
.clk_rate = 120000000,
.properties = spt_i2c_properties,
};
From 120000000 to 180000000, people are still working on getting
to the bottom of this but it is worth a shot. The clk_rate
value here is only used to calculate i2c timings and does
not actually program a clock, it only specifies the frequency
the clock is expected to be running at. So changing this should
be safe.
Regards,
Hans
