lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB4CAwdRHQOiqrK5utgCzZKB-X+mDcJePBLa7o0rTWzAogo5vw@mail.gmail.com>
Date:   Wed, 4 Sep 2019 12:38:24 +0800
From:   Chris Chiu <chiu@...lessm.com>
To:     Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        lee.jones@...aro.org, Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>
Subject: Re: Tweak I2C SDA hold time on GemniLake to make touchpad work

On Tue, Sep 3, 2019 at 8:03 PM Jarkko Nikula
<jarkko.nikula@...ux.intel.com> wrote:
>
> Hi Chris
>
> On 9/3/19 11:18 AM, Mika Westerberg wrote:
> > +Jarkko
> >
> > On Tue, Sep 03, 2019 at 04:10:27PM +0800, Chris Chiu wrote:
> >> Hi,
> >>
> >> We're working on the acer Gemnilake laptop TravelMate B118-M for
> >> touchpad not working issue. The touchpad fails to bring up and the
> >> i2c-hid ouput the message as follows
> >>      [    8.317293] i2c_hid i2c-ELAN0502:00: hid_descr_cmd failed
> >> We tried on latest linux kernel 5.3.0-rc6 and it reports the same.
> >>
> >> We then look into I2C signal level measurement to find out why.
> >> The following is the signal output from LA for the SCL/SDA.
> >> https://imgur.com/sKcpvdo
> >> The SCL frequency is ~400kHz from the SCL period, but the SDA
> >> transition is quite weird. Per the I2C spec, the data on the SDA line
> >> must be stable during the high period of the clock. The HIGH or LOW
> >> state of the data line can only change when the clock signal on the
> >> SCL line is LOW. The SDA period span across 2 SCL high, I think
> >> that's the reason why the I2C read the wrong data and fail to initialize.
> >>
> >> Thus, we treak the SDA hold time by the following modification.
> >>
> >> --- a/drivers/mfd/intel-lpss-pci.c
> >> +++ b/drivers/mfd/intel-lpss-pci.c
> >> @@ -97,7 +97,8 @@ static const struct intel_lpss_platform_info bxt_uart_info = {
> >>   };
> >>
> >>   static struct property_entry bxt_i2c_properties[] = {
> >> -       PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 42),
> >> +       PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
> >>          PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
> >>          PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 208),
> >>          { },
> >>
> >> The reason why I choose sda hold time is by the Table 10 of
> >> https://www.nxp.com/docs/en/user-guide/UM10204.pdf, the device
> >> must provide a hold time at lease 300ns and and 42 here is relatively
> >> too small. The signal measurement result for the same pin on Windows
> >> is as follows.
> >> https://imgur.com/BtKUIZB
> >> Comparing to the same result running Linux
> >> https://imgur.com/N4fPTYN
> >>
> >> After applying the sda hold time tweak patch above, the touchpad can
> >> be correctly initialized and work. The LA signal is shown as down below.
> >> https://imgur.com/B3PmnIp
> >>
> Could you try does attached patch work for you?
>
> It's from last year for another related issue but there platform was
> actually Apollo Lake instead of Gemini Lake but anyway it was found out
> that Windows uses different timing parameters than Linux on Gemini Lake.
>
> I didn't take patch forward back then due known Gemini Lake machines
> were working with the Broxton I2C timing parameters but now it's time if
> attached patch fixes the issue on your machine.
>
> Patch is from top of v5.3-rc7 but should probably apply also to older
> kernels.
>
> --
> Jarkko

Thanks, Jarkko, the patche works on my acer laptops.

Chris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ