[BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD

Message ID CAPpJ_ed-JPOzQPtyCdH4_C7dzEeM3fznus8XDuaojaiM_4nFpw@mail.gmail.com
State Not Applicable
Headers show
Series
  • [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
Related show

Commit Message

Jian-Hong Pan May 4, 2018, 6:55 a.m.
Hi,

We have an ASUS X580GD (Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz) laptop
equipped with ELAN1200 touchpad which does not work totally, but the
external mouse works fine.

We have checked the input devices by "cat /proc/bus/input/devices", and
the touchpad does not appear in the list.

According to ASUS' information, the ELAN touchpad is attached to the i2c
bus of the system.  Then, we do find the corresponding error messages in
dmesg:

with kernel 4.15.15
[   10.290192] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not
found, using dummy regulator
[   10.290818] i2c_hid i2c-ELAN1200:00: can't add hid device: -22
[   10.290852] i2c_hid: probe of i2c-ELAN1200:00 failed with error -22

with kernel 4.16.7
[   10.638729] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not
found, using dummy regulator
[   10.639304] i2c_hid i2c-ELAN1200:00: unexpected HID descriptor
bcdVersion (0xff00)

Then check the i2c bus and get:
i2c-7
  name: Synopsys DesignWare I2C adapter
  firmware_path: \_SB_.PCI0.I2C1
  driver: i2c_designware

i2c-ELAN1200:00
  name: ELAN1200:00
  firmware_path: \_SB_.PCI0.I2C1.ETPD

Besides, according to ASUS's input, they observed that after entering
the OS, the frequency of SCL is too fast (about 600kHz) and the SCL High
time is around 450ns, not following I2C spec which is 0.6us.
https://pasteboard.co/HjzSWXd.png

so, we get the kernel 4.17-rc3 and add some debug message:

        case 100000:
                dev->sda_hold_time = ss_ht;
@@ -310,6 +311,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
        if (has_acpi_companion(&pdev->dev))
                dw_i2c_acpi_configure(pdev);

+printk("%s clk freq %u\n", __func__, dev->clk_freq);
        /*
         * Only standard mode at 100kHz, fast mode at 400kHz,
         * fast mode plus at 1MHz and high speed mode at 3.4MHz are supported.
@@ -333,6 +335,9 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
                i2c_dw_configure_master(dev);

        dev->clk = devm_clk_get(&pdev->dev, NULL);
+printk("%s parent clk freq %u\n", __func__, clk_get_rate(dev->clk));
+if (dev->sda_hold_time)
+       printk("sda hold time %u\n", dev->sda_hold_time);
        if (!i2c_dw_prepare_clk(dev, true)) {
                dev->get_clk_rate_khz = i2c_dw_get_clk_rate_khz;

Rebuild kernel, reboot and check dmesg again:
(the touchpad still not work)

[    5.004195] acpi PNP0C14:03: duplicate WMI GUID
05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on
PNP0C14:02)
[    5.004250] acpi PNP0C14:04: duplicate WMI GUID
05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on
PNP0C14:02)
[    5.022086] intel-lpss 0000:00:15.0: enabling device (0000 -> 0002)
[    5.056084] idma64 idma64.0: Found Intel integrated DMA 64-bit
[    5.057994] dw_i2c_acpi_configure: freq 400000 and ss_ht 0 fp_ht 0
hs_ht 0 fs_ht 0
[    5.057995] dw_i2c_plat_probe clk freq 400000
[    5.058001] dw_i2c_plat_probe parent clk freq 120000000
[    5.058025] i2c_dw_init_master sda falling 300 scl falling 300
[    5.058026] i2c_dw_init_master ss no hcnt 513 lcnt 599
[    5.058028] i2c_designware i2c_designware.0: Standard-mode
HCNT:LCNT = 513:599
[    5.058028] i2c_dw_init_master fs no hcnt 105 lcnt 191
[    5.058029] i2c_designware i2c_designware.0: Fast-mode HCNT:LCNT = 105:191
[    5.058033] i2c_dw_init_master new ver sda hold time 28
[    5.060998] Adding 7776500k swap on /dev/zram0.  Priority:-2
extents:1 across:7776500k SSFS
[    5.091397] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[    5.094840] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    5.097905] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters,
655360 ms ovfl timer
[    5.097907] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[    5.097907] RAPL PMU: hw unit of domain package 2^-14 Joules
[    5.097908] RAPL PMU: hw unit of domain dram 2^-14 Joules
[    5.097908] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[    5.097909] RAPL PMU: hw unit of domain psys 2^-14 Joules
[    5.098206] intel-lpss 0000:00:15.1: enabling device (0000 -> 0002)
[    5.098570] idma64 idma64.1: Found Intel integrated DMA 64-bit
[    5.098676] media: Linux media interface: v0.10
[    5.100423] dw_i2c_acpi_configure: freq 400000 and ss_ht 0 fp_ht 0
hs_ht 0 fs_ht 0
[    5.100424] dw_i2c_plat_probe clk freq 400000
[    5.100427] dw_i2c_plat_probe parent clk freq 120000000
[    5.100435] i2c_dw_init_master sda falling 300 scl falling 300
[    5.100436] i2c_dw_init_master ss no hcnt 513 lcnt 599
[    5.100437] i2c_designware i2c_designware.1: Standard-mode
HCNT:LCNT = 513:599
[    5.100438] i2c_dw_init_master fs no hcnt 105 lcnt 191
[    5.100439] i2c_designware i2c_designware.1: Fast-mode HCNT:LCNT = 105:191
[    5.100443] i2c_dw_init_master new ver sda hold time 28
[    5.102504] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[    5.102508] cfg80211: failed to load regulatory.db

According to the information "dw_i2c_plat_probe clk freq 400000" in the
dmesg, the system has the right SCL clock with 400K Hz.  But why it is
apparently not taking effect?

Thnaks,
Jian-Hong Pan

Comments

Chris Chiu May 7, 2018, 8:07 a.m. | #1
On Fri, May 4, 2018 at 2:55 PM, Jian-Hong Pan <jian-hong@endlessm.com> wrote:
> Hi,
>
> We have an ASUS X580GD (Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz) laptop
> equipped with ELAN1200 touchpad which does not work totally, but the
> external mouse works fine.
>
> We have checked the input devices by "cat /proc/bus/input/devices", and
> the touchpad does not appear in the list.
>
> According to ASUS' information, the ELAN touchpad is attached to the i2c
> bus of the system.  Then, we do find the corresponding error messages in
> dmesg:
>
> with kernel 4.15.15
> [   10.290192] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not
> found, using dummy regulator
> [   10.290818] i2c_hid i2c-ELAN1200:00: can't add hid device: -22
> [   10.290852] i2c_hid: probe of i2c-ELAN1200:00 failed with error -22
>
> with kernel 4.16.7
> [   10.638729] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not
> found, using dummy regulator
> [   10.639304] i2c_hid i2c-ELAN1200:00: unexpected HID descriptor
> bcdVersion (0xff00)
>
> Then check the i2c bus and get:
> i2c-7
>   name: Synopsys DesignWare I2C adapter
>   firmware_path: \_SB_.PCI0.I2C1
>   driver: i2c_designware
>
> i2c-ELAN1200:00
>   name: ELAN1200:00
>   firmware_path: \_SB_.PCI0.I2C1.ETPD
>
> Besides, according to ASUS's input, they observed that after entering
> the OS, the frequency of SCL is too fast (about 600kHz) and the SCL High
> time is around 450ns, not following I2C spec which is 0.6us.
> https://pasteboard.co/HjzSWXd.png
>
> so, we get the kernel 4.17-rc3 and add some debug message:
>
> diff --git a/drivers/i2c/busses/i2c-designware-master.c
> b/drivers/i2c/busses/i2c-designware-master.c
> index fd36c39ddf4e..bbe76e033133 100644
> --- a/drivers/i2c/busses/i2c-designware-master.c
> +++ b/drivers/i2c/busses/i2c-designware-master.c
> @@ -88,10 +88,12 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>         sda_falling_time = dev->sda_falling_time ?: 300; /* ns */
>         scl_falling_time = dev->scl_falling_time ?: 300; /* ns */
>
> +printk("%s sda falling %u scl falling %u\n", __func__,
> sda_falling_time, scl_falling_time);
>         /* Set SCL timing parameters for standard-mode */
>         if (dev->ss_hcnt && dev->ss_lcnt) {
>                 hcnt = dev->ss_hcnt;
>                 lcnt = dev->ss_lcnt;
> +printk("%s ss set hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
>         } else {
>                 hcnt = i2c_dw_scl_hcnt(i2c_dw_clk_rate(dev),
>                                         4000,   /* tHD;STA = tHIGH = 4.0 us */
> @@ -102,10 +104,11 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>                                         4700,   /* tLOW = 4.7 us */
>                                         scl_falling_time,
>                                         0);     /* No offset */
> +printk("%s ss no hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
>         }
>         dw_writel(dev, hcnt, DW_IC_SS_SCL_HCNT);
>         dw_writel(dev, lcnt, DW_IC_SS_SCL_LCNT);
> -       dev_dbg(dev->dev, "Standard-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
> +       dev_err(dev->dev, "Standard-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
>
>         /* Set SCL timing parameters for fast-mode or fast-mode plus */
>         if ((dev->clk_freq == 1000000) && dev->fp_hcnt && dev->fp_lcnt) {
> @@ -114,6 +117,7 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>         } else if (dev->fs_hcnt && dev->fs_lcnt) {
>                 hcnt = dev->fs_hcnt;
>                 lcnt = dev->fs_lcnt;
> +printk("%s fs set hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
>         } else {
>                 hcnt = i2c_dw_scl_hcnt(i2c_dw_clk_rate(dev),
>                                         600,    /* tHD;STA = tHIGH = 0.6 us */
> @@ -124,10 +128,11 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>                                         1300,   /* tLOW = 1.3 us */
>                                         scl_falling_time,
>                                         0);     /* No offset */
> +printk("%s fs no hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
>         }
>         dw_writel(dev, hcnt, DW_IC_FS_SCL_HCNT);
>         dw_writel(dev, lcnt, DW_IC_FS_SCL_LCNT);
> -       dev_dbg(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
> +       dev_err(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
>
>         if ((dev->master_cfg & DW_IC_CON_SPEED_MASK) ==
>                 DW_IC_CON_SPEED_HIGH) {
> @@ -141,7 +146,7 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>                         lcnt = dev->hs_lcnt;
>                         dw_writel(dev, hcnt, DW_IC_HS_SCL_HCNT);
>                         dw_writel(dev, lcnt, DW_IC_HS_SCL_LCNT);
> -                       dev_dbg(dev->dev, "HighSpeed-mode HCNT:LCNT = %d:%d\n",
> +                       dev_err(dev->dev, "HighSpeed-mode HCNT:LCNT = %d:%d\n",
>                                 hcnt, lcnt);
>                 }
>         }
> @@ -152,6 +157,7 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>                 if (!dev->sda_hold_time) {
>                         /* Keep previous hold time setting if no one set it */
>                         dev->sda_hold_time = dw_readl(dev, DW_IC_SDA_HOLD);
> +printk("%s no sda hold time and read from reg %u\n", __func__,
> dev->sda_hold_time);
>                 }
>                 /*
>                  * Workaround for avoiding TX arbitration lost in case I2C
> @@ -163,7 +169,9 @@ static int i2c_dw_init_master(struct dw_i2c_dev *dev)
>                 if (!(dev->sda_hold_time & DW_IC_SDA_HOLD_RX_MASK))
>                         dev->sda_hold_time |= 1 << DW_IC_SDA_HOLD_RX_SHIFT;
>                 dw_writel(dev, dev->sda_hold_time, DW_IC_SDA_HOLD);
> +printk("%s new ver sda hold time %u\n", __func__, dev->sda_hold_time);
>         } else if (dev->sda_hold_time) {
> +printk("%s old sda hold time %u\n", __func__, dev->sda_hold_time);
>                 dev_warn(dev->dev,
>                         "Hardware too old to adjust SDA hold time.\n");
>         }
> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
> b/drivers/i2c/busses/i2c-designware-pcidrv.c
> index 86e1bd0b82e9..55ac4a6d31da 100644
> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> @@ -277,6 +277,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
>         dev->tx_fifo_depth = controller->tx_fifo_depth;
>         dev->rx_fifo_depth = controller->rx_fifo_depth;
>
> +printk("%s have scl sda config %s\n", __func__,
> controller->scl_sda_cfg?"true":"false");
>         adap = &dev->adapter;
>         adap->owner = THIS_MODULE;
>         adap->class = 0;
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 5660daf6c92e..90b443c6b472 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -115,6 +115,7 @@ static int dw_i2c_acpi_configure(struct
> platform_device *pdev)
>         dw_i2c_acpi_params(pdev, "HSCN", &dev->hs_hcnt, &dev->hs_lcnt, &hs_ht);
>         dw_i2c_acpi_params(pdev, "FMCN", &dev->fs_hcnt, &dev->fs_lcnt, &fs_ht);
>
> +printk("%s: freq %u and ss_ht %u fp_ht %u hs_ht %u fs_ht %u\n",
> __func__, dev->clk_freq, ss_ht, fp_ht, hs_ht, fs_ht);
>         switch (dev->clk_freq) {
>         case 100000:
>                 dev->sda_hold_time = ss_ht;
> @@ -310,6 +311,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
>         if (has_acpi_companion(&pdev->dev))
>                 dw_i2c_acpi_configure(pdev);
>
> +printk("%s clk freq %u\n", __func__, dev->clk_freq);
>         /*
>          * Only standard mode at 100kHz, fast mode at 400kHz,
>          * fast mode plus at 1MHz and high speed mode at 3.4MHz are supported.
> @@ -333,6 +335,9 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
>                 i2c_dw_configure_master(dev);
>
>         dev->clk = devm_clk_get(&pdev->dev, NULL);
> +printk("%s parent clk freq %u\n", __func__, clk_get_rate(dev->clk));
> +if (dev->sda_hold_time)
> +       printk("sda hold time %u\n", dev->sda_hold_time);
>         if (!i2c_dw_prepare_clk(dev, true)) {
>                 dev->get_clk_rate_khz = i2c_dw_get_clk_rate_khz;
>
> Rebuild kernel, reboot and check dmesg again:
> (the touchpad still not work)
>
> [    5.004195] acpi PNP0C14:03: duplicate WMI GUID
> 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on
> PNP0C14:02)
> [    5.004250] acpi PNP0C14:04: duplicate WMI GUID
> 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on
> PNP0C14:02)
> [    5.022086] intel-lpss 0000:00:15.0: enabling device (0000 -> 0002)
> [    5.056084] idma64 idma64.0: Found Intel integrated DMA 64-bit
> [    5.057994] dw_i2c_acpi_configure: freq 400000 and ss_ht 0 fp_ht 0
> hs_ht 0 fs_ht 0
> [    5.057995] dw_i2c_plat_probe clk freq 400000
> [    5.058001] dw_i2c_plat_probe parent clk freq 120000000
> [    5.058025] i2c_dw_init_master sda falling 300 scl falling 300
> [    5.058026] i2c_dw_init_master ss no hcnt 513 lcnt 599
> [    5.058028] i2c_designware i2c_designware.0: Standard-mode
> HCNT:LCNT = 513:599
> [    5.058028] i2c_dw_init_master fs no hcnt 105 lcnt 191
> [    5.058029] i2c_designware i2c_designware.0: Fast-mode HCNT:LCNT = 105:191
> [    5.058033] i2c_dw_init_master new ver sda hold time 28
> [    5.060998] Adding 7776500k swap on /dev/zram0.  Priority:-2
> extents:1 across:7776500k SSFS
> [    5.091397] cfg80211: Loading compiled-in X.509 certificates for
> regulatory database
> [    5.094840] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [    5.097905] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters,
> 655360 ms ovfl timer
> [    5.097907] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
> [    5.097907] RAPL PMU: hw unit of domain package 2^-14 Joules
> [    5.097908] RAPL PMU: hw unit of domain dram 2^-14 Joules
> [    5.097908] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
> [    5.097909] RAPL PMU: hw unit of domain psys 2^-14 Joules
> [    5.098206] intel-lpss 0000:00:15.1: enabling device (0000 -> 0002)
> [    5.098570] idma64 idma64.1: Found Intel integrated DMA 64-bit
> [    5.098676] media: Linux media interface: v0.10
> [    5.100423] dw_i2c_acpi_configure: freq 400000 and ss_ht 0 fp_ht 0
> hs_ht 0 fs_ht 0
> [    5.100424] dw_i2c_plat_probe clk freq 400000
> [    5.100427] dw_i2c_plat_probe parent clk freq 120000000
> [    5.100435] i2c_dw_init_master sda falling 300 scl falling 300
> [    5.100436] i2c_dw_init_master ss no hcnt 513 lcnt 599
> [    5.100437] i2c_designware i2c_designware.1: Standard-mode
> HCNT:LCNT = 513:599
> [    5.100438] i2c_dw_init_master fs no hcnt 105 lcnt 191
> [    5.100439] i2c_designware i2c_designware.1: Fast-mode HCNT:LCNT = 105:191
> [    5.100443] i2c_dw_init_master new ver sda hold time 28
> [    5.102504] platform regulatory.0: Direct firmware load for
> regulatory.db failed with error -2
> [    5.102508] cfg80211: failed to load regulatory.db
>
> According to the information "dw_i2c_plat_probe clk freq 400000" in the
> dmesg, the system has the right SCL clock with 400K Hz.  But why it is
> apparently not taking effect?
>
> Thnaks,
> Jian-Hong Pan

Some update, we can make the touchpad work by simply modifying the
clk_rate of spt_i2c_info from 120000000 to 133000000 in intel-lpss-pci.c for
specific PCI ID 8086:a368 ~ a36a (CoffeeLake). Is the clock setting different
for the CoffeeLake series?
Jarkko Nikula May 8, 2018, 2:31 p.m. | #2
Hi

On 05/07/2018 11:07 AM, Chris Chiu wrote:

>> Besides, according to ASUS's input, they observed that after entering
>> the OS, the frequency of SCL is too fast (about 600kHz) and the SCL High
>> time is around 450ns, not following I2C spec which is 0.6us.
>> https://pasteboard.co/HjzSWXd.png
>>
> Some update, we can make the touchpad work by simply modifying the
> clk_rate of spt_i2c_info from 120000000 to 133000000 in intel-lpss-pci.c for
> specific PCI ID 8086:a368 ~ a36a (CoffeeLake). Is the clock setting different
> for the CoffeeLake series?
> 
Hmm.. at quick look it looks like to be 133 MHz but I want to double 
check first from other specs. I'm also wondering why it results 600 kHz 
instead of expected 133/120 * 400 kHz = 443 kHz. Need to check timing 
parameters too.
Daniel Drake May 8, 2018, 3:47 p.m. | #3
On Tue, May 8, 2018 at 8:31 AM, Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>> Some update, we can make the touchpad work by simply modifying the
>> clk_rate of spt_i2c_info from 120000000 to 133000000 in intel-lpss-pci.c for
>> specific PCI ID 8086:a368 ~ a36a (CoffeeLake). Is the clock setting different
>> for the CoffeeLake series?
>>
> Hmm.. at quick look it looks like to be 133 MHz but I want to double check first from other specs. I'm also wondering why it results 600 kHz instead of expected 133/120 * 400 kHz = 443 kHz. Need to check timing parameters too.

Thanks for looking at this. I believe we tried 133MHz just because
some other platforms in the file have the clock at that speed.

In the original/shipped setup, the scope shows the SDA clock is
running at ~635kHz (rather than the intended 400kHz) and the debug
logs from the kernel producing that waveform shows that HCNT=105 and
LCNT=191

105+191=296 parent clock ticks per cycle

At 635kHz, a single clock cycle is 1575ns. What is the speed of the
parent clock if it ticks 296 times in 1575ns? I calculate this to be
187960000Hz and further experiments indicate that clk_rate=187960000
also makes the touchpad work. Unfortunately we don't have easy access
to the scope to measure the effect on the waveform.

Also through experimentation we tried i2c-sda-falling-time-ns=400ns
(increasing from the default of 300ns) in order to make the HCNT
increase to 117. This also makes the touchpad work.

Please let us know if we can help further in finding an upstream fix
for this issue.

Thanks
Daniel
Chris Chiu May 10, 2018, 12:03 p.m. | #4
On Tue, May 8, 2018 at 11:47 PM, Daniel Drake <drake@endlessm.com> wrote:
> On Tue, May 8, 2018 at 8:31 AM, Jarkko Nikula
> <jarkko.nikula@linux.intel.com> wrote:
>>> Some update, we can make the touchpad work by simply modifying the
>>> clk_rate of spt_i2c_info from 120000000 to 133000000 in intel-lpss-pci.c for
>>> specific PCI ID 8086:a368 ~ a36a (CoffeeLake). Is the clock setting different
>>> for the CoffeeLake series?
>>>
>> Hmm.. at quick look it looks like to be 133 MHz but I want to double check first from other specs. I'm also wondering why it results 600 kHz instead of expected 133/120 * 400 kHz = 443 kHz. Need to check timing parameters too.
>
> Thanks for looking at this. I believe we tried 133MHz just because
> some other platforms in the file have the clock at that speed.
>
> In the original/shipped setup, the scope shows the SDA clock is
> running at ~635kHz (rather than the intended 400kHz) and the debug
> logs from the kernel producing that waveform shows that HCNT=105 and
> LCNT=191
>
> 105+191=296 parent clock ticks per cycle
>
> At 635kHz, a single clock cycle is 1575ns. What is the speed of the
> parent clock if it ticks 296 times in 1575ns? I calculate this to be
> 187960000Hz and further experiments indicate that clk_rate=187960000
> also makes the touchpad work. Unfortunately we don't have easy access
> to the scope to measure the effect on the waveform.
>
> Also through experimentation we tried i2c-sda-falling-time-ns=400ns
> (increasing from the default of 300ns) in order to make the HCNT
> increase to 117. This also makes the touchpad work.
>

Report from guys who can access scope. If i2c-sda-falling-time-ns=400ns
, HCNT increase to 117, the SCL high duration is 576ns as follows
https://pasteboard.co/HkwERvP.png

The original SCL high duration (HCNT = 105, 120MHz) is as follows
https://pasteboard.co/HkwFxgY.png

So the HCNT does affect but per this HCNT/LCNT value, just not 400kHz
as expected. Any suggestion?

> Please let us know if we can help further in finding an upstream fix
> for this issue.
>
> Thanks
> Daniel
Jarkko Nikula May 14, 2018, 2:20 p.m. | #5
On 05/10/2018 03:03 PM, Chris Chiu wrote:
> Report from guys who can access scope. If i2c-sda-falling-time-ns=400ns
> , HCNT increase to 117, the SCL high duration is 576ns as follows
> https://pasteboard.co/HkwERvP.png
> 
> The original SCL high duration (HCNT = 105, 120MHz) is as follows
> https://pasteboard.co/HkwFxgY.png
> 
> So the HCNT does affect but per this HCNT/LCNT value, just not 400kHz
> as expected. Any suggestion?
> 
Thanks for measurements. I was sidetracked last week so I don't have yet 
explanation why signals run faster than expected :-(

Using 120 MHz SPT I2C clocks in commit b418bbff36dd ("mfd: intel-lpss: 
Add Intel Cannonlake PCI IDs") is clearly wrong but before going to 133 
MHz (which work for you but still runs too fast) I would like to find 
explanation why it appears to be much higher.
Chris Chiu May 15, 2018, 3:22 a.m. | #6
On Mon, May 14, 2018 at 10:20 PM, Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
> On 05/10/2018 03:03 PM, Chris Chiu wrote:
>>
>> Report from guys who can access scope. If i2c-sda-falling-time-ns=400ns
>> , HCNT increase to 117, the SCL high duration is 576ns as follows
>> https://pasteboard.co/HkwERvP.png
>>
>> The original SCL high duration (HCNT = 105, 120MHz) is as follows
>> https://pasteboard.co/HkwFxgY.png
>>
>> So the HCNT does affect but per this HCNT/LCNT value, just not 400kHz
>> as expected. Any suggestion?
>>
> Thanks for measurements. I was sidetracked last week so I don't have yet
> explanation why signals run faster than expected :-(
>
> Using 120 MHz SPT I2C clocks in commit b418bbff36dd ("mfd: intel-lpss: Add
> Intel Cannonlake PCI IDs") is clearly wrong but before going to 133 MHz
> (which work for you but still runs too fast) I would like to find
> explanation why it appears to be much higher.
>
> --
> Jarkko

What if I change the 120MHz to 180MHz and then make sure that the I2C operates
in target FS mode frequency 400kHz via scope? Would there be any side effect?
Maybe some other busses frequency could be also affected and causing some other
component malfunction?

Chris
Jarkko Nikula May 15, 2018, 10:20 a.m. | #7
On 05/15/2018 06:22 AM, Chris Chiu wrote:
> What if I change the 120MHz to 180MHz and then make sure that the I2C operates
> in target FS mode frequency 400kHz via scope? Would there be any side effect?
> Maybe some other busses frequency could be also affected and causing some other
> component malfunction?
> 
Should be safe. It is only clock rate information when registering a 
fixed clock with known rate in intel-lpss.c and i2c-designware uses that 
info when calculating the timing parameters. I.e. it doesn't change any 
internal clocks.

I'm trying to find a contact who can confirm what is the expected rate 
of I2C input clock and is it common to all Cannon Lake HW.
Jarkko Nikula May 17, 2018, 7:48 a.m. | #8
Hi

On 05/15/2018 01:20 PM, Jarkko Nikula wrote:
> On 05/15/2018 06:22 AM, Chris Chiu wrote:
>> What if I change the 120MHz to 180MHz and then make sure that the I2C 
>> operates
>> in target FS mode frequency 400kHz via scope? Would there be any side 
>> effect?
>> Maybe some other busses frequency could be also affected and causing 
>> some other
>> component malfunction?
>>
> Should be safe. It is only clock rate information when registering a 
> fixed clock with known rate in intel-lpss.c and i2c-designware uses that 
> info when calculating the timing parameters. I.e. it doesn't change any 
> internal clocks.
> 
> I'm trying to find a contact who can confirm what is the expected rate 
> of I2C input clock and is it common to all Cannon Lake HW.
> 
I got confirmation that input clock is actually even higher 216 Mhz.

While checking does it cover all of those CNL CNL-LP and CNL-H PCI IDs 
may I add your Jian-Hong, Chris and Daniel email addresses to Repored-by 
tags in a fix patch?
Chris Chiu May 17, 2018, 9:05 a.m. | #9
On Thu, May 17, 2018 at 3:48 PM, Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
> Hi
>
> On 05/15/2018 01:20 PM, Jarkko Nikula wrote:
>>
>> On 05/15/2018 06:22 AM, Chris Chiu wrote:
>>>
>>> What if I change the 120MHz to 180MHz and then make sure that the I2C
>>> operates
>>> in target FS mode frequency 400kHz via scope? Would there be any side
>>> effect?
>>> Maybe some other busses frequency could be also affected and causing some
>>> other
>>> component malfunction?
>>>
>> Should be safe. It is only clock rate information when registering a fixed
>> clock with known rate in intel-lpss.c and i2c-designware uses that info when
>> calculating the timing parameters. I.e. it doesn't change any internal
>> clocks.
>>
>> I'm trying to find a contact who can confirm what is the expected rate of
>> I2C input clock and is it common to all Cannon Lake HW.
>>
> I got confirmation that input clock is actually even higher 216 Mhz.
>
> While checking does it cover all of those CNL CNL-LP and CNL-H PCI IDs may I
> add your Jian-Hong, Chris and Daniel email addresses to Repored-by tags in a
> fix patch?
>
> --
> Jarkko

No problem. Thanks
Hans de Goede May 18, 2018, 7:48 a.m. | #10
Hi Jarkko, et.al.,

On 17-05-18 09:48, Jarkko Nikula wrote:
> Hi
> 
> On 05/15/2018 01:20 PM, Jarkko Nikula wrote:
>> On 05/15/2018 06:22 AM, Chris Chiu wrote:
>>> What if I change the 120MHz to 180MHz and then make sure that the I2C operates
>>> in target FS mode frequency 400kHz via scope? Would there be any side effect?
>>> Maybe some other busses frequency could be also affected and causing some other
>>> component malfunction?
>>>
>> Should be safe. It is only clock rate information when registering a fixed clock with known rate in intel-lpss.c and i2c-designware uses that info when calculating the timing parameters. I.e. it doesn't change any internal clocks.
>>
>> I'm trying to find a contact who can confirm what is the expected rate of I2C input clock and is it common to all Cannon Lake HW.
>>
> I got confirmation that input clock is actually even higher 216 Mhz.
> 
> While checking does it cover all of those CNL CNL-LP and CNL-H PCI IDs may I add your Jian-Hong, Chris and Daniel email addresses to Repored-by tags in a fix patch?

Could it be the i2c input clock definition in drivers/mfd/intel-lpss-pci.c
is also wrong for Apollo Lake (N3450) ?  There are lots of people having
various issues with i2c attached touchpads on Apollo Lake devices, this bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244

Is sort of a collection bug for these. Various models laptops, lots of
reporters. Note not sure thie is an i2c-designware issue, but it would
be good to double check the input clock on Apollo Lake.

I've checked the datasheet and the datasheet mentions 133MHz as
"serial input clk" in the lpio_bxt_regs Registers Summary, which is
also part of the LPSS, no clk is mentioned in the "Summary of
DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".

Regards,

Hans
Andy Shevchenko May 18, 2018, 8:37 a.m. | #11
On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:


> Could it be the i2c input clock definition in drivers/mfd/intel-lpss-
> pci.c
> is also wrong for Apollo Lake (N3450) ?  There are lots of people
> having
> various issues with i2c attached touchpads on Apollo Lake devices,
> this bug:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
> 
> Is sort of a collection bug for these. Various models laptops, lots of
> reporters. Note not sure thie is an i2c-designware issue, but it would
> be good to double check the input clock on Apollo Lake.
> 
> I've checked the datasheet and the datasheet mentions 133MHz as
> "serial input clk" in the lpio_bxt_regs Registers Summary, which is
> also part of the LPSS, no clk is mentioned in the "Summary of
> DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".

The internal datasheet we have access to mentioned in this case for
Broxton and Cannonlake together. So, your assumption might be quite
close to the truth and the issue is inherited from Broxton.
Andy Shevchenko May 18, 2018, 10:20 a.m. | #12
On Fri, 2018-05-18 at 11:37 +0300, Andy Shevchenko wrote:
> On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:
> 
> 
> > Could it be the i2c input clock definition in drivers/mfd/intel-
> > lpss-
> > pci.c
> > is also wrong for Apollo Lake (N3450) ?  There are lots of people
> > having
> > various issues with i2c attached touchpads on Apollo Lake devices,
> > this bug:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
> > 
> > Is sort of a collection bug for these. Various models laptops, lots
> > of
> > reporters. Note not sure thie is an i2c-designware issue, but it
> > would
> > be good to double check the input clock on Apollo Lake.
> > 
> > I've checked the datasheet and the datasheet mentions 133MHz as
> > "serial input clk" in the lpio_bxt_regs Registers Summary, which is
> > also part of the LPSS, no clk is mentioned in the "Summary of
> > DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
> 
> The internal datasheet we have access to mentioned in this case for
> Broxton and Cannonlake together. So, your assumption might be quite
> close to the truth and the issue is inherited from Broxton.
> 

Hans, can your reporters try the following patch? Depending on the
result I may send it out ASAP.

--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -120,7 +120,7 @@ static struct property_entry apl_i2c_properties[] =
{
 };
 
 static const struct intel_lpss_platform_info apl_i2c_info = {
-       .clk_rate = 133000000,
+       .clk_rate = 216000000,
        .properties = apl_i2c_properties,
 };
Jarkko Nikula May 18, 2018, 10:58 a.m. | #13
On 05/18/2018 01:20 PM, Andy Shevchenko wrote:
> On Fri, 2018-05-18 at 11:37 +0300, Andy Shevchenko wrote:
>> On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:
>>
>>
>>> Could it be the i2c input clock definition in drivers/mfd/intel-
>>> lpss-
>>> pci.c
>>> is also wrong for Apollo Lake (N3450) ?  There are lots of people
>>> having
>>> various issues with i2c attached touchpads on Apollo Lake devices,
>>> this bug:
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
>>>
>>> Is sort of a collection bug for these. Various models laptops, lots
>>> of
>>> reporters. Note not sure thie is an i2c-designware issue, but it
>>> would
>>> be good to double check the input clock on Apollo Lake.
>>>
>>> I've checked the datasheet and the datasheet mentions 133MHz as
>>> "serial input clk" in the lpio_bxt_regs Registers Summary, which is
>>> also part of the LPSS, no clk is mentioned in the "Summary of
>>> DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
>>
>> The internal datasheet we have access to mentioned in this case for
>> Broxton and Cannonlake together. So, your assumption might be quite
>> close to the truth and the issue is inherited from Broxton.
>>
> 
Nope. The specification I have mention the I2C input clock in Broxton is 
fixed 133 MHz but in Cannon Lake it is derived through non-SW visible 
divider.

> Hans, can your reporters try the following patch? Depending on the
> result I may send it out ASAP.
> 
> --- a/drivers/mfd/intel-lpss-pci.c
> +++ b/drivers/mfd/intel-lpss-pci.c
> @@ -120,7 +120,7 @@ static struct property_entry apl_i2c_properties[] =
> {
>   };
>   
>   static const struct intel_lpss_platform_info apl_i2c_info = {
> -       .clk_rate = 133000000,
> +       .clk_rate = 216000000,
>          .properties = apl_i2c_properties,
>   };
> 
Nack. The Apollo Lake HW here shows expected I2C bus clock on 
oscilloscope so it is indeed clocked at 133 MHz.
Hans de Goede May 18, 2018, 1:09 p.m. | #14
Hi,

On 18-05-18 12:58, Jarkko Nikula wrote:
> On 05/18/2018 01:20 PM, Andy Shevchenko wrote:
>> On Fri, 2018-05-18 at 11:37 +0300, Andy Shevchenko wrote:
>>> On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:
>>>
>>>
>>>> Could it be the i2c input clock definition in drivers/mfd/intel-
>>>> lpss-
>>>> pci.c
>>>> is also wrong for Apollo Lake (N3450) ?  There are lots of people
>>>> having
>>>> various issues with i2c attached touchpads on Apollo Lake devices,
>>>> this bug:
>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
>>>>
>>>> Is sort of a collection bug for these. Various models laptops, lots
>>>> of
>>>> reporters. Note not sure thie is an i2c-designware issue, but it
>>>> would
>>>> be good to double check the input clock on Apollo Lake.
>>>>
>>>> I've checked the datasheet and the datasheet mentions 133MHz as
>>>> "serial input clk" in the lpio_bxt_regs Registers Summary, which is
>>>> also part of the LPSS, no clk is mentioned in the "Summary of
>>>> DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
>>>
>>> The internal datasheet we have access to mentioned in this case for
>>> Broxton and Cannonlake together. So, your assumption might be quite
>>> close to the truth and the issue is inherited from Broxton.
>>>
>>
> Nope. The specification I have mention the I2C input clock in Broxton is fixed 133 MHz but in Cannon Lake it is derived through non-SW visible divider.
> 
>> Hans, can your reporters try the following patch? Depending on the
>> result I may send it out ASAP.
>>
>> --- a/drivers/mfd/intel-lpss-pci.c
>> +++ b/drivers/mfd/intel-lpss-pci.c
>> @@ -120,7 +120,7 @@ static struct property_entry apl_i2c_properties[] =
>> {
>>   };
>>   static const struct intel_lpss_platform_info apl_i2c_info = {
>> -       .clk_rate = 133000000,
>> +       .clk_rate = 216000000,
>>          .properties = apl_i2c_properties,
>>   };
>>
> Nack. The Apollo Lake HW here shows expected I2C bus clock on oscilloscope so it is indeed clocked at 133 MHz.

Ok, thank you for checking this.

Regards,

Hans
Jarkko Nikula May 18, 2018, 1:15 p.m. | #15
On 05/18/2018 10:48 AM, Hans de Goede wrote:
> Could it be the i2c input clock definition in drivers/mfd/intel-lpss-pci.c
> is also wrong for Apollo Lake (N3450) ?  There are lots of people having
> various issues with i2c attached touchpads on Apollo Lake devices, this 
> bug:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
> 
> Is sort of a collection bug for these. Various models laptops, lots of
> reporters. Note not sure thie is an i2c-designware issue, but it would
> be good to double check the input clock on Apollo Lake.
> 
Does i2c_designware_core.dyndbg=+p and i2c-hid.debug=1 command line 
arguments give any useful debug information from those machines?
Hans de Goede May 18, 2018, 1:26 p.m. | #16
Hi,

On 18-05-18 15:15, Jarkko Nikula wrote:
> On 05/18/2018 10:48 AM, Hans de Goede wrote:
>> Could it be the i2c input clock definition in drivers/mfd/intel-lpss-pci.c
>> is also wrong for Apollo Lake (N3450) ?  There are lots of people having
>> various issues with i2c attached touchpads on Apollo Lake devices, this bug:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
>>
>> Is sort of a collection bug for these. Various models laptops, lots of
>> reporters. Note not sure thie is an i2c-designware issue, but it would
>> be good to double check the input clock on Apollo Lake.
>>
> Does i2c_designware_core.dyndbg=+p and i2c-hid.debug=1 command line arguments give any useful debug information from those machines?

I've asked people in the bug to collect debug output with this
added.

Regards,

Hans
Hans de Goede May 19, 2018, 11:58 a.m. | #17
Hi,

On 18-05-18 15:15, Jarkko Nikula wrote:
> On 05/18/2018 10:48 AM, Hans de Goede wrote:
>> Could it be the i2c input clock definition in drivers/mfd/intel-lpss-pci.c
>> is also wrong for Apollo Lake (N3450) ?  There are lots of people having
>> various issues with i2c attached touchpads on Apollo Lake devices, this bug:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
>>
>> Is sort of a collection bug for these. Various models laptops, lots of
>> reporters. Note not sure thie is an i2c-designware issue, but it would
>> be good to double check the input clock on Apollo Lake.
>>
> Does i2c_designware_core.dyndbg=+p and i2c-hid.debug=1 command line arguments give any useful debug information from those machines?

A first dmesg with these flags has been provided:
https://launchpadlibrarian.net/370884912/dmesg.log

Regards,

Hans

Patch

diff --git a/drivers/i2c/busses/i2c-designware-master.c
b/drivers/i2c/busses/i2c-designware-master.c
index fd36c39ddf4e..bbe76e033133 100644
--- a/drivers/i2c/busses/i2c-designware-master.c
+++ b/drivers/i2c/busses/i2c-designware-master.c
@@ -88,10 +88,12 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
        sda_falling_time = dev->sda_falling_time ?: 300; /* ns */
        scl_falling_time = dev->scl_falling_time ?: 300; /* ns */

+printk("%s sda falling %u scl falling %u\n", __func__,
sda_falling_time, scl_falling_time);
        /* Set SCL timing parameters for standard-mode */
        if (dev->ss_hcnt && dev->ss_lcnt) {
                hcnt = dev->ss_hcnt;
                lcnt = dev->ss_lcnt;
+printk("%s ss set hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
        } else {
                hcnt = i2c_dw_scl_hcnt(i2c_dw_clk_rate(dev),
                                        4000,   /* tHD;STA = tHIGH = 4.0 us */
@@ -102,10 +104,11 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
                                        4700,   /* tLOW = 4.7 us */
                                        scl_falling_time,
                                        0);     /* No offset */
+printk("%s ss no hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
        }
        dw_writel(dev, hcnt, DW_IC_SS_SCL_HCNT);
        dw_writel(dev, lcnt, DW_IC_SS_SCL_LCNT);
-       dev_dbg(dev->dev, "Standard-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
+       dev_err(dev->dev, "Standard-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);

        /* Set SCL timing parameters for fast-mode or fast-mode plus */
        if ((dev->clk_freq == 1000000) && dev->fp_hcnt && dev->fp_lcnt) {
@@ -114,6 +117,7 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
        } else if (dev->fs_hcnt && dev->fs_lcnt) {
                hcnt = dev->fs_hcnt;
                lcnt = dev->fs_lcnt;
+printk("%s fs set hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
        } else {
                hcnt = i2c_dw_scl_hcnt(i2c_dw_clk_rate(dev),
                                        600,    /* tHD;STA = tHIGH = 0.6 us */
@@ -124,10 +128,11 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
                                        1300,   /* tLOW = 1.3 us */
                                        scl_falling_time,
                                        0);     /* No offset */
+printk("%s fs no hcnt %u lcnt %u\n", __func__, hcnt, lcnt);
        }
        dw_writel(dev, hcnt, DW_IC_FS_SCL_HCNT);
        dw_writel(dev, lcnt, DW_IC_FS_SCL_LCNT);
-       dev_dbg(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
+       dev_err(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);

        if ((dev->master_cfg & DW_IC_CON_SPEED_MASK) ==
                DW_IC_CON_SPEED_HIGH) {
@@ -141,7 +146,7 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
                        lcnt = dev->hs_lcnt;
                        dw_writel(dev, hcnt, DW_IC_HS_SCL_HCNT);
                        dw_writel(dev, lcnt, DW_IC_HS_SCL_LCNT);
-                       dev_dbg(dev->dev, "HighSpeed-mode HCNT:LCNT = %d:%d\n",
+                       dev_err(dev->dev, "HighSpeed-mode HCNT:LCNT = %d:%d\n",
                                hcnt, lcnt);
                }
        }
@@ -152,6 +157,7 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
                if (!dev->sda_hold_time) {
                        /* Keep previous hold time setting if no one set it */
                        dev->sda_hold_time = dw_readl(dev, DW_IC_SDA_HOLD);
+printk("%s no sda hold time and read from reg %u\n", __func__,
dev->sda_hold_time);
                }
                /*
                 * Workaround for avoiding TX arbitration lost in case I2C
@@ -163,7 +169,9 @@  static int i2c_dw_init_master(struct dw_i2c_dev *dev)
                if (!(dev->sda_hold_time & DW_IC_SDA_HOLD_RX_MASK))
                        dev->sda_hold_time |= 1 << DW_IC_SDA_HOLD_RX_SHIFT;
                dw_writel(dev, dev->sda_hold_time, DW_IC_SDA_HOLD);
+printk("%s new ver sda hold time %u\n", __func__, dev->sda_hold_time);
        } else if (dev->sda_hold_time) {
+printk("%s old sda hold time %u\n", __func__, dev->sda_hold_time);
                dev_warn(dev->dev,
                        "Hardware too old to adjust SDA hold time.\n");
        }
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 86e1bd0b82e9..55ac4a6d31da 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -277,6 +277,7 @@  static int i2c_dw_pci_probe(struct pci_dev *pdev,
        dev->tx_fifo_depth = controller->tx_fifo_depth;
        dev->rx_fifo_depth = controller->rx_fifo_depth;

+printk("%s have scl sda config %s\n", __func__,
controller->scl_sda_cfg?"true":"false");
        adap = &dev->adapter;
        adap->owner = THIS_MODULE;
        adap->class = 0;
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 5660daf6c92e..90b443c6b472 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -115,6 +115,7 @@  static int dw_i2c_acpi_configure(struct
platform_device *pdev)
        dw_i2c_acpi_params(pdev, "HSCN", &dev->hs_hcnt, &dev->hs_lcnt, &hs_ht);
        dw_i2c_acpi_params(pdev, "FMCN", &dev->fs_hcnt, &dev->fs_lcnt, &fs_ht);

+printk("%s: freq %u and ss_ht %u fp_ht %u hs_ht %u fs_ht %u\n",
__func__, dev->clk_freq, ss_ht, fp_ht, hs_ht, fs_ht);
        switch (dev->clk_freq) {