> I would expect 4.18 given that 4.17 is more or less a done deal, but
> once the patch is out I expect it to also be cherry-picked as a bug-fix
> to the stable releases of older kernels.
Sounds great! Thanks, Hans! And thank you, to all of you!
On Mon, May 21, 2018 at 11:12 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> Hi,
>
>
> On 21-05-18 19:02, wereturtle wrote:
>>
>> Hi Hans,
>>
>>> Have you tried turning off the computer and removing the battery,
>>> then wait 5 minutes and put the battery back again?
>>
>>
>> OK, I had to run to the store to get the right size Torx screwdriver,
>> but I removed the battery and waited 15 minutes before putting it back
>> in. Unfortunately, that didn't help.
>>
>>> Likely having the touchpad properly working results in either the
>>> touchpad
>>> or the i2c controller firing an interrupt at boot because of state left
>>> over from the previous boot with working touchpad. Since you now lack
>>> a working driver, nothing acks the interrupt and it keeps firing.
>>
>>
>> Interesting! Thanks for teaching me!
>>
>>> The proper solution here would be to build 4.15 with the fix, or
>>> see if there are some patches to the nvidia driver to make it build
>>> with 4.17, which avoids the need for another kernel build.
>>
>>
>> Alas, I've had too much difficulty with the latter solutions. 4.17
>> vanilla (no patch) seems to ack it already. 4.15 would need something
>> else to ack it in the first place, and I'm not sure where to patch
>> that. I couldn't find any Nvidia patches for 4.17.
>>
>> Fortunately, Best Buy let me return the laptop without any fuss. They
>> were even offering to exchange it. I declined, but I might try again
>> and live without the touchpad for a time since the laptop just went on
>> sale this morning.
>>
>> As such, when, roughly, do you think the official patch will land?
>> Kernel 4.17 or 4.18? (Supposedly Ubuntu 18.10 will have 4.18, if the
>> stars align.)
>
>
> I would expect 4.18 given that 4.17 is more or less a done deal, but
> once the patch is out I expect it to also be cherry-picked as a bug-fix
> to the stable releases of older kernels.
>
> Jarkko, I did not see an official patch for this yet, I'm not on the
> list though, so I don't know if was not posted at all, or if you did
> not Cc me? (not Cc-ing me is fine I'm only sideways involved).
>
> Regards,
>
> Hans
>
>
>
>
>
>>
>> Thanks!
>>
>> On Sun, May 20, 2018 at 3:13 AM, Hans de Goede <hdegoede@xxxxxxxxxx>
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 20-05-18 04:34, wereturtle wrote:
>>>>
>>>>
>>>> Some bad news to follow up the good news.
>>>>
>>>> Installing the patched Kernel for my touchpad had a negative side
>>>> effect. While running the patched Kernel, I didn't have any issues.
>>>> However, I couldn't get the Nvidia driver to install with this Kernel.
>>>> As such, I tried rebooting into my old 4.15 Kernel. Even after
>>>> removing the patched Kernel and reinstalling the Nvidia driver several
>>>> times for 4.15, my computer became sluggish during browsing, typing,
>>>> etc. Games were locking up or else having a huge framerate drop. My
>>>> CPU cores were spinning like crazy without even any processes taking
>>>> up CPU.
>>>>
>>>> Further investigation revealed a an "unexpected IRQ trap at vector 9a"
>>>> error message at startup and shutdown in the console. The message
>>>> fires constantly. Under /proc/interrupts, it was listing intel-gpio
>>>> (i2c) for 9a. It was firing off like crazy. I think that's for my
>>>> touchpad?
>>>>
>>>> I tried reinstalling Kubuntu altogether, twice, and it wouldn't stop.
>>>> It's like that patch permanently wrote something to my hardware? I
>>>> tried installing 4.17 RC5 with Ukuu without the touchpad patch built
>>>> in. The intel-gpio interrupts went away, and the computer is snappy
>>>> and responsive again. However, rebooting back into 4.15 resulted in
>>>> the interrupts returning.
>>>>
>>>> How did this patch end up doing something permanently to my computer,
>>>> and what can I do to undo it for Kernel 4.15 so that I can use my
>>>> Nvidia drivers again?
>>>
>>>
>>>
>>> Have you tried turning off the computer and removing the battery,
>>> then wait 5 minutes and put the battery back again?
>>>
>>> Likely having the touchpad properly working results in either the
>>> touchpad
>>> or the i2c controller firing an interrupt at boot because of state left
>>> over from the previous boot with working touchpad. Since you now lack
>>> a working driver, nothing acks the interrupt and it keeps firing.
>>>
>>> The proper solution here would be to build 4.15 with the fix, or
>>> see if there are some patches to the nvidia driver to make it build
>>> with 4.17, which avoids the need for another kernel build.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
>>>
>>>>
>>>> Also, I don't notice this same sluggishness with Windows 10. Windows
>>>> is snappy regardless of the Kernel.
>>>>
>>>> On Sat, May 19, 2018 at 12:42 PM, wereturtle <wereturtledev@xxxxxxxxx>
>>>> wrote:
>>>>>
>>>>>
>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
