Hi everyone!
I set the clk_rate to be 216000000 in my own patched Kernel 4.17. RC
5, and my touchpad now works!
Thank you so much!
On Fri, May 18, 2018 at 12:39 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> Hi,
>
>
> On 18-05-18 09:32, Hans de Goede 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...
>>
>> 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.
>
>
> Ok, so I just read the new mails in the threads where this is being
> discussed and it has been confirmed by Intel that for all Canon Lake
> devices the correct clk_rate is 216000000 . Which likely explains
> the i2c errors here. Jarkko (added to the Cc) is working on a patch
> for this.
>
> For now if you can build your own kernels you can make the change I
> suggested above, but that will also change the clock-rate on other
> machines, so that is just for testing on Canon Lake hardware!
>
> The way the Interrupt is specified is still suspicious btw, but
> we'll cross that bridge when we get there.
>
> Regards,
>
> Hans
