Bug 155241 - i2c_designware 808622C1:06: punit semaphore timed out, resetting
Summary: i2c_designware 808622C1:06: punit semaphore timed out, resetting
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: I2C (show other bugs)
Hardware: Intel Linux
: P1 high
Assignee: Drivers/I2C virtual user
URL:
Keywords:
: 150481 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-08-29 10:43 UTC by tagorereddy
Modified: 2017-03-28 06:35 UTC (History)
13 users (show)

See Also:
Kernel Version: 4.8.0 -rc3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
DMESG (56.17 KB, text/plain)
2016-08-31 01:29 UTC, tagorereddy
Details
DSDT (decompiled) (1.06 MB, text/plain)
2016-08-31 01:30 UTC, tagorereddy
Details
Test patch to bind iosf_mbi via ACPI for Braswell (5.83 KB, patch)
2016-11-25 11:29 UTC, Takashi Iwai
Details | Diff
Revised test patch to bind iosc_mbi via ACPI for Braswell (5.83 KB, patch)
2016-11-26 19:47 UTC, Takashi Iwai
Details | Diff
Revised patch to bind iosf_mbi via ACPI for Braswell (5.95 KB, patch)
2016-11-30 06:29 UTC, Takashi Iwai
Details | Diff
Patch to switch PUNIT semaphore value for Cherry Trail (3.96 KB, patch)
2016-11-30 06:29 UTC, Takashi Iwai
Details | Diff
[PATCH 1/2] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions (2.80 KB, patch)
2016-12-02 15:26 UTC, Hans de Goede
Details | Diff
[PATCH 2/2] i2c: designware-baytrail: Add support for cherrytrail (4.17 KB, patch)
2016-12-02 15:27 UTC, Hans de Goede
Details | Diff
Logs, Kernel config file (693.14 KB, application/x-zip-compressed)
2016-12-13 19:13 UTC, Agostinho Carvalho
Details
dmesg (299.33 KB, text/x-log)
2016-12-29 01:18 UTC, jayki
Details
Set of i2c + sfio_mbi + i915 patches (9.38 KB, application/gzip)
2017-01-01 20:01 UTC, Hans de Goede
Details
dmesg_with_patchset (47.42 KB, application/octet-stream)
2017-01-03 01:12 UTC, jayki
Details
0001-drm-i915-HACK-forcewake-ALL.patch (682 bytes, patch)
2017-01-03 09:32 UTC, Hans de Goede
Details | Diff
Set of i2c + sfio_mbi + i915 patches (12.38 KB, application/gzip)
2017-01-06 09:42 UTC, Hans de Goede
Details

Description tagorereddy 2016-08-29 10:43:16 UTC
CPU: Intel Atom x5-z8300 (cherrytrail)

BUG:
====
[   21.058284] i2c_designware 808622C1:06: I2C bus managed by PUNIT
[   21.162118] i2c_designware 808622C1:06: punit semaphore timed out, resetting
[   21.168783] i2c_designware 808622C1:06: PUNIT SEM: 2
[   21.173454] ------------[ cut here ]------------
[   21.173477] WARNING: CPU: 0 PID: 452 at ../drivers/i2c/busses/i2c-designware-baytrail.c:106 baytrail_i2c_acquire+0x159/0x1c0 [i2c_designware_platform]
[   21.173482] Modules linked in: mmc_block glue_helper ablk_helper i2c_designware_platform(+) cryptd i2c_designware_core sdhci_acpi sdhci tpm_crb i2c_algo_bit mmc_core sparse_keymap pcspkr ac tpm_tis dw_dmac dw_dmac_core tpm video thermal acpi_pad button wmi pwm_lpss_platform pwm_lpss processor_thermal_device acpi_thermal_rel 8250_dw int3403_thermal intel_soc_dts_iosf int340x_thermal_zone soundcore efivarfs hid_generic usbhid uas usb_storage xhci_pci xhci_hcd usbcore usb_common sg
[   21.173562] CPU: 0 PID: 452 Comm: systemd-udevd Not tainted 4.8.0-rc3-default #1
[   21.173568] Hardware name: To Be Filled By O.E.M To Be Filled By O.E.M/Default string, BIOS 0.07 07/06/2016
[   21.173574]  0000000000000000 ffffffff81393104 0000000000000000 0000000000000000
[   21.173584]  ffffffff8107ca1e 00000000ffffff92 ffff88006f2eb018 00000000fffeef98
[   21.173593]  ffffffffa01a56d0 00000000fffeef7f ffff880071def410 ffffffffa01a4859
[   21.173602] Call Trace:
[   21.173637]  [<ffffffff8102ed5e>] dump_trace+0x5e/0x320
[   21.173653]  [<ffffffff8102f12c>] show_stack_log_lvl+0x10c/0x180
[   21.173666]  [<ffffffff8102fe41>] show_stack+0x21/0x40
[   21.173680]  [<ffffffff81393104>] dump_stack+0x5c/0x78
[   21.173693]  [<ffffffff8107ca1e>] __warn+0xbe/0xe0
[   21.173711]  [<ffffffffa01a4859>] baytrail_i2c_acquire+0x159/0x1c0 [i2c_designware_platform]
[   21.173739]  [<ffffffffa015122e>] i2c_dw_init+0x1e/0x410 [i2c_designware_core]
[   21.173753]  [<ffffffffa0151ff4>] i2c_dw_probe+0x34/0x1c0 [i2c_designware_core]
[   21.173768]  [<ffffffffa01a445a>] dw_i2c_plat_probe+0x1ca/0x3f0 [i2c_designware_platform]
[   21.173785]  [<ffffffff814da465>] platform_drv_probe+0x35/0x90
[   21.173801]  [<ffffffff814d84dc>] driver_probe_device+0x21c/0x430
[   21.173814]  [<ffffffff814d87bc>] __driver_attach+0xcc/0xf0
[   21.173830]  [<ffffffff814d624a>] bus_for_each_dev+0x5a/0x90
[   21.173843]  [<ffffffff814d76fc>] bus_add_driver+0x1bc/0x280
[   21.173859]  [<ffffffff814d90c7>] driver_register+0x57/0xc0
[   21.173873]  [<ffffffff8100217b>] do_one_initcall+0x4b/0x180
[   21.173888]  [<ffffffff8118b824>] do_init_module+0x5b/0x1e7
[   21.173902]  [<ffffffff811035c0>] load_module+0x1a30/0x1cc0
[   21.173916]  [<ffffffff81103a4b>] SYSC_finit_module+0xab/0xe0
[   21.173930]  [<ffffffff81003bb9>] do_syscall_64+0x59/0xb0
[   21.173946]  [<ffffffff816bb5a5>] entry_SYSCALL64_slow_path+0x25/0x25
[   21.182231] DWARF2 unwinder stuck at return_from_SYSCALL_64+0x0/0x6a

[   21.182239] Leftover inexact backtrace:

[   21.184339] ---[ end trace 9ea7452477773249 ]---
[   21.184352] i2c_designware 808622C1:06: couldn't acquire bus ownership
[   21.188205] i2c_designware: probe of 808622C1:06 failed with error -110
Comment 1 [account disabled by the administrator] 2016-08-30 19:30:04 UTC
First thing is this a regression or has this always been happening for you.
Comment 2 tagorereddy 2016-08-31 01:14:57 UTC
(In reply to indolflinus from comment #1)
> First thing is this a regression or has this always been happening for you.

It happens every time on this device. Its been happening through kernel versions 4.6 to 4.8. I haven't tested on previous kernels but there are many others complaining the same thing on older kernels.
Comment 3 tagorereddy 2016-08-31 01:29:20 UTC
Created attachment 231541 [details]
DMESG
Comment 4 tagorereddy 2016-08-31 01:30:05 UTC
Created attachment 231551 [details]
DSDT (decompiled)
Comment 5 Chris Cheney 2016-09-23 12:19:10 UTC
This appears to be the same issue as bz150481.

See https://bugzilla.kernel.org/show_bug.cgi?id=150481#c1
Comment 6 Chris Cheney 2016-09-23 12:19:47 UTC
I also have several x5-z8300 boards with the same problem.
Comment 7 tagorereddy 2016-09-23 13:00:22 UTC
(In reply to Chris Cheney from comment #6)
> I also have several x5-z8300 boards with the same problem.

Unfortunately I couldn't identify why there is a race condition on the semaphore.
But one interesting thing is this problem doesn't exist in Kernel 4.6.0 of Kali Linux 2016.2 Distro.
I2C bus initializes fine and all the devices are enumerated.

But the problem persists on openSUSE with same kernel. I've tried multiple kernels with openSUSE. All report the same. I should try other distros with newer kernels and see what happens.
Comment 8 tagorereddy 2016-09-26 19:12:43 UTC
I have observed that the problem persists irrespective of the distro and  kernel version as long you implement CONFIG_I2C_DESIGNWARE_BAYTRAIL=y. The host driver  writes 0x2 into PUNIT SEMAPHORE (Register 0x7) and waits for the hardware to write back 0x1 into the register. But the hardware isn't writing anything, resulting in the timeout. Now I've tried changing the Semaphore register address for cherry trail device to 0x10E as someone suggested but that hangs the device when host driver attempts to write into the register.

The only thing that seems to be working is disabling the driver for I2C semaphore for baytrail devices. That's how Kali Linux is shipping their distro. I tried disabling the semaphore driver on openSUSE, but device hangs up. I'm yet to isolate the cause.
Comment 9 tagorereddy 2016-10-08 09:04:03 UTC
UPDATE: I think I've tracked the core problem here. The IOSF_MBI driver provided in linux is a PCI driver. But the IOSF device on the gadget is ACPI/INT33BD. So, there is no driver for the device. Initially David E. Box, the author of the driver, wrote the driver for ACPI devices but by the time it was pushed upstream, it was converted to PCI driver. All we need is ACPI version of the driver.
Comment 10 porlock 2016-11-11 22:47:33 UTC
tagorereddy: so the proper driver is not present in the current kernel, do You manage to make it work ?
Comment 11 RussianNeuroMancer 2016-11-13 03:42:06 UTC
If I have same errors on Z3735G not right after boot, but one hour later (probably triggered by overheating due to charding) my issue is same as this one or different? Do I need to fill separate bugreport?

dmesg: http://pastebin.ubuntu.com/23469066/
Comment 12 RussianNeuroMancer 2016-11-13 03:43:03 UTC
Build options: https://bugs.freedesktop.org/show_bug.cgi?id=85977#c38
i2c hardware:
i2cdetect -l
i2c-3   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-1   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-11  i2c             DPDDC-B                                 I2C adapter
i2c-8   i2c             i915 gmbus dpc                          I2C adapter
i2c-6   i2c             i915 gmbus vga                          I2C adapter
i2c-4   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-2   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-12  i2c             DPDDC-C                                 I2C adapter
i2c-0   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-9   i2c             i915 gmbus dpb                          I2C adapter
i2c-10  i2c             i915 gmbus dpd                          I2C adapter
i2c-7   i2c             i915 gmbus panel                        I2C adapter
i2c-5   i2c             i915 gmbus ssc                          I2C adapter
Comment 13 Takashi Iwai 2016-11-25 11:28:19 UTC
(In reply to tagorereddy from comment #9)
> UPDATE: I think I've tracked the core problem here. The IOSF_MBI driver
> provided in linux is a PCI driver. But the IOSF device on the gadget is
> ACPI/INT33BD. So, there is no driver for the device. Initially David E. Box,
> the author of the driver, wrote the driver for ACPI devices but by the time
> it was pushed upstream, it was converted to PCI driver. All we need is ACPI
> version of the driver.

This doesn't look like the cause.  We recently got cherry trail based devices, and I hacked a bit to get ACPI binding for Braswell.  Alas, the error behavior is persistent.

OTOH, when I switch the PUNIT_SEMAPHORE to 0x10e, it seems working.  So, this magic value seems valid for some systems, at least.

FWIW, I attach the test patch to use ACPI binding in below.  Also, the patch for changing PUNIT_SEMAPHORE is found in openSUSE bugzilla:
  https://bugzilla.suse.com/show_bug.cgi?id=1011913
Comment 14 Takashi Iwai 2016-11-25 11:29:42 UTC
Created attachment 245911 [details]
Test patch to bind iosf_mbi via ACPI for Braswell

Might need to adjust some lines depending on the kernel version, but it should be trivial.
Comment 15 Fernando Jiménez 2016-11-25 12:25:22 UTC
Hi, I have one of the affected devices, will try to test Takashi's patch today or tomorrow.

Thank you!
Comment 16 porlock 2016-11-25 12:55:29 UTC
Also changing in bios all ACPI settings to PCI seams to solve the problem.
Comment 17 Fernando Jiménez 2016-11-26 02:13:11 UTC
I tried the patch provided bu Takashi.

The original error disappears.

Nov 26 02:32:35 ez kernel: i2c_designware 808622C1:06: I2C bus managed by PUNIT
(only mention of i2c)

But unfortunately this may be because of iosf_mbi_acpi no longer loads:

Nov 26 02:32:34 ez kernel: iosf_mbi_acpi: probe of INT33BD:00 failed with error -2119985240

lshw shows the IOSF device with id 0x2280, as per the patch.

My device is a Jumper EZBook 2. (Intel(R) Atom(TM) x5-Z8300)
Comment 18 Takashi Iwai 2016-11-26 19:46:36 UTC
(In reply to Fernando Jiménez from comment #17)
> Nov 26 02:32:34 ez kernel: iosf_mbi_acpi: probe of INT33BD:00 failed with
> error -2119985240

Ah, sorry, I attached a wrong patch.  Try the next one below instead.
Comment 19 Takashi Iwai 2016-11-26 19:47:31 UTC
Created attachment 245941 [details]
Revised test patch to bind iosc_mbi via ACPI for Braswell
Comment 20 Fernando Jiménez 2016-11-29 22:39:43 UTC
Sorry for the delay! Just tried it; still failing. Here's the  i2c-related dmesg:

[    3.683401] i2c_designware 808622C1:06: I2C bus managed by PUNIT
[    3.696023] FUJITSU Extended Socket Network Device Driver - version 1.1 - Copyright (c) 2015 FUJITSU LIMITED
[    3.708831] Bluetooth: HCI UART driver ver 2.3
[    3.708837] Bluetooth: HCI UART protocol H4 registered
[    3.708838] Bluetooth: HCI UART protocol BCSP registered
[    3.708840] Bluetooth: HCI UART protocol LL registered
[    3.708842] Bluetooth: HCI UART protocol ATH3K registered
[    3.708843] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    3.708985] Bluetooth: HCI UART protocol Intel registered
[    3.709036] Bluetooth: HCI UART protocol BCM registered
[    3.709038] Bluetooth: HCI UART protocol QCA registered
[    3.709040] Bluetooth: HCI UART protocol AG6XX registered
[    3.783189] i2c_designware 808622C1:06: punit semaphore timed out, resetting
[    3.783422] i2c_designware 808622C1:06: PUNIT SEM: 0
[    3.783569] ------------[ cut here ]------------
[    3.783593] WARNING: CPU: 2 PID: 224 at drivers/i2c/busses/i2c-designware-baytrail.c:106 baytrail_i2c_acquire+0x139/0x1f0 [i2c_designware_platform]
[    3.783596] Modules linked in: snd_intel_sst_acpi(+) snd_intel_sst_core hci_uart snd_soc_sst_mfld_platform snd_soc_sst_match fjes snd_soc_core btbcm snd_compress snd_pcm_dmaengine intel_hid(+) sparse_keymap ac97_bus btqca snd_pcm btintel snd_timer i915(+) snd i2c_designware_platform(+) bluetooth i2c_designware_core rfkill_gpio soundcore drm_kms_helper rfkill crc16 int3406_thermal soc_button_array drm tpm_tis tpm_tis_core tpm video acpi_pad button ac intel_gtt dptf_power processor_thermal_device intel_soc_dts_iosf 8250_dw lpc_ich int3403_thermal syscopyarea mei_txe sysfillrect int340x_thermal_zone sysimgblt fb_sys_fops i2c_algo_bit mei int3400_thermal spi_pxa2xx_platform acpi_thermal_rel sch_fq_codel ip_tables x_tables hid_multitouch hid_generic usbhid hid btrfs xor raid6_pq mmc_block crc32c_intel
[    3.783746]  xhci_pci xhci_hcd usbcore usb_common sdhci_acpi sdhci led_class mmc_core
[    3.783773] CPU: 2 PID: 224 Comm: systemd-udevd Tainted: G        W       4.8.10-1-zen #1
[    3.783777] Hardware name: Insyde CherryTrail/Type2 - Board Product Name, BIOS JUMPERx.WT314.NBNEEEN02 07/07/2016
[    3.783783]  0000000000000286 0000000052105446 ffff8801393e39e0 ffffffff81316a90
[    3.783797]  0000000000000000 0000000000000000 ffff8801393e3a20 ffffffff8107ca5b
[    3.783808]  0000006a393e3a00 ffff88013981c018 00000000fffea4dc ffffffffa03156d0
[    3.783820] Call Trace:
[    3.783839]  [<ffffffff81316a90>] dump_stack+0x63/0x83
[    3.783849]  [<ffffffff8107ca5b>] __warn+0xcb/0xf0
[    3.783858]  [<ffffffff8107cb8d>] warn_slowpath_null+0x1d/0x20
[    3.783869]  [<ffffffffa03148c9>] baytrail_i2c_acquire+0x139/0x1f0 [i2c_designware_platform]
[    3.783879]  [<ffffffffa0364233>] i2c_dw_init+0x23/0x470 [i2c_designware_core]
[    3.783888]  [<ffffffffa0365049>] i2c_dw_probe+0x39/0x1d0 [i2c_designware_core]
[    3.783897]  [<ffffffff814640a4>] ? pm_runtime_forbid+0x54/0x60
[    3.783907]  [<ffffffffa03144b2>] dw_i2c_plat_probe+0x1e2/0x420 [i2c_designware_platform]
[    3.783919]  [<ffffffff8145a56b>] platform_drv_probe+0x3b/0xa0
[    3.783928]  [<ffffffff813b5538>] ? acpi_lpss_activate+0x62/0x6a
[    3.783936]  [<ffffffff814582e3>] driver_probe_device+0x223/0x430
[    3.783945]  [<ffffffff814585cf>] __driver_attach+0xdf/0xf0
[    3.783953]  [<ffffffff814584f0>] ? driver_probe_device+0x430/0x430
[    3.783961]  [<ffffffff81455dcc>] bus_for_each_dev+0x6c/0xc0
[    3.783969]  [<ffffffff814579ee>] driver_attach+0x1e/0x20
[    3.783976]  [<ffffffff81457400>] bus_add_driver+0x170/0x270
[    3.783983]  [<ffffffffa0376000>] ? 0xffffffffa0376000
[    3.783991]  [<ffffffff81458f90>] driver_register+0x60/0xe0
[    3.783997]  [<ffffffffa0376000>] ? 0xffffffffa0376000
[    3.784006]  [<ffffffff8145a4e6>] __platform_driver_register+0x36/0x40
[    3.784016]  [<ffffffffa0376017>] dw_i2c_init_driver+0x17/0x1000 [i2c_designware_platform]
[    3.784025]  [<ffffffff81002190>] do_one_initcall+0x50/0x180
[    3.784033]  [<ffffffff811c5751>] ? __vunmap+0x81/0xd0
[    3.784043]  [<ffffffff811e5a86>] ? kfree+0x176/0x190
[    3.784053]  [<ffffffff811787a6>] do_init_module+0x5f/0x1f9
[    3.784061]  [<ffffffff811090ee>] load_module+0x26ce/0x2a30
[    3.784069]  [<ffffffff81105c90>] ? symbol_put_addr+0x50/0x50
[    3.784082]  [<ffffffff811095c8>] SyS_init_module+0x178/0x190
[    3.784091]  [<ffffffff81003b97>] do_syscall_64+0x57/0xb0
[    3.784102]  [<ffffffff81613ba1>] entry_SYSCALL64_slow_path+0x25/0x25
[    3.784108] ---[ end trace d6394fcbfc40eaf9 ]---
[    3.784117] i2c_designware 808622C1:06: couldn't acquire bus ownership
[    3.784377] i2c_designware: probe of 808622C1:06 failed with error -110
Comment 21 Takashi Iwai 2016-11-30 06:28:18 UTC
(In reply to Fernando Jiménez from comment #20)
> Sorry for the delay! Just tried it; still failing.

So, ACPI binding doesn't make difference, no surprise.  It failed on mine, too.
But did you already check whether PUNIT_SEMAPHORE 0x10e works?

To be sure, I put a message when ACPI binding is used instead of PCI in the revised patch below.  Just check whether you see the line or not (no need to paste the output again).  If the message "iosf_mbi: probing Braswell PUNIT semaphore via ACPI" doesn't appear, your chip is different.

Also, the next one is the patch to switch to 0x10e only for Cherry Trail chip I confirmed to work.  The patch is exclusive with the former one, so you can apply one of them.  It also shows a message "Using semaphore reg 0x10e for Cherry Trail".  If you don't see it, the chip is a different variant.
Comment 22 Takashi Iwai 2016-11-30 06:29:09 UTC
Created attachment 246351 [details]
Revised patch to bind iosf_mbi via ACPI for Braswell
Comment 23 Takashi Iwai 2016-11-30 06:29:43 UTC
Created attachment 246361 [details]
Patch to switch PUNIT semaphore value for Cherry Trail
Comment 24 Fernando Jiménez 2016-11-30 15:34:20 UTC
Both patches seem to produce the expected outputs:

Nov 30 14:45:28 ez kernel: i2c_designware 808622C1:06: Using semaphore reg 0x10e for Cherry Trail

Nov 30 16:22:28 ez kernel: iosf_mbi: probing Braswell PUNIT semaphore via ACPI
Comment 25 Hans de Goede 2016-12-02 10:56:38 UTC
*** Bug 150481 has been marked as a duplicate of this bug. ***
Comment 26 Hans de Goede 2016-12-02 15:22:20 UTC
Hi All,

I've been looking into this myself recently, as I recently bought myself a cherrytrail tablet to try and run mainline Linux on it. I see that since I last checked this bug 2 weeks ago a lot has happened here :)

Takashi, great to see that you're working on cherrytrails support too :)

I think we all agree now that there really are 2 problems here:

1) On Cherrytrail the punit has the pmic i2c bus access semaphore at a different address (0x10e)

About the correctness of the 0x10e address, I've also found this used in the android kernel sources for cherrytrail devices:
https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/i2c-dw_i2c-Ported-punit-locking-patch-from-MCG-kerne.patch

So I believe that this is correct. Note BTW that Intel has datasheets available for the Cherrytrail family of SoCs: 
https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-1.pdf
https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf

As said I last checked this bug 2 weeks ago, so in the mean time I've written a patch (2 patches, one prep patch) for this myself too, my solution is somewhat different it uses the PCI device-id / ACPI-id to
determine which address to use instead of the CPU-id. IMHO that is the more correct way to deal with this. I'll attach my 2 patches here, once we agree on which solution is better we can post one or the other upstream.

2) iosf_mbi also needs to be bound for things to work. The mainline kernel currently only has iosf_mbi support in pci mode not for acpi mode. So for some people just fixing 1. is enough, but not for everyone. 

My tablet has the iosf_mbi block in PCI mode, so my testing is not affected by this. Great to see that there is a fix for this now too though!

Regards,

Hans


p.s.

Takashi, not sure what your plans are wrt working on cherrytrail. To make sure we're not doing double
work. I've recently fixed a nasty bug where sometimes the i915 driver would hang on load on tablets with DSI screens, as well as 2 other DSI init bug fixes:

https://lists.freedesktop.org/archives/intel-gfx/2016-December/113455.html
https://lists.freedesktop.org/archives/intel-gfx/2016-December/113460.html
https://lists.freedesktop.org/archives/intel-gfx/2016-December/113339.html

If you've a tablet with a DSI screen you likely want these 3 fixes (the middle one only applies to drm-next).

I'm currently wrapping up fixing the lpss-pwm <-> i915 driver integration, needed for proper backlight control.

For this weekend I plan to work on gsl367x touchscreen support.

After that I will likely look into the otg port not being able to dynamically switch from host to gadget mode and back (implement an upstream version of:
https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/0001-extcon-3gpio-add-driver-for-USB-OTG-port-controlled-.patch
Comment 27 Hans de Goede 2016-12-02 15:26:55 UTC
Created attachment 246631 [details]
[PATCH 1/2] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions
Comment 28 Hans de Goede 2016-12-02 15:27:27 UTC
Created attachment 246641 [details]
[PATCH 2/2] i2c: designware-baytrail: Add support for cherrytrail
Comment 29 Takashi Iwai 2016-12-02 16:04:17 UTC
(In reply to Hans de Goede from comment #26)
> Hi All,
> 
> I've been looking into this myself recently, as I recently bought myself a
> cherrytrail tablet to try and run mainline Linux on it. I see that since I
> last checked this bug 2 weeks ago a lot has happened here :)
> 
> Takashi, great to see that you're working on cherrytrails support too :)
> 
> I think we all agree now that there really are 2 problems here:
> 
> 1) On Cherrytrail the punit has the pmic i2c bus access semaphore at a
> different address (0x10e)
> 
> About the correctness of the 0x10e address, I've also found this used in the
> android kernel sources for cherrytrail devices:
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-
> m1stable/patches/i2c-dw_i2c-Ported-punit-locking-patch-from-MCG-kerne.patch
> 
> So I believe that this is correct. Note BTW that Intel has datasheets
> available for the Cherrytrail family of SoCs: 
> https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/
> atom-z8000-datasheet-vol-1.pdf
> https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/
> atom-z8000-datasheet-vol-2.pdf

Great, thanks for the pointer!
 
> As said I last checked this bug 2 weeks ago, so in the mean time I've
> written a patch (2 patches, one prep patch) for this myself too, my solution
> is somewhat different it uses the PCI device-id / ACPI-id to
> determine which address to use instead of the CPU-id. IMHO that is the more
> correct way to deal with this. I'll attach my 2 patches here, once we agree
> on which solution is better we can post one or the other upstream.

Your patches look good to me.  Although the PUNIT_SEMAPHORE macro expansion appears a bit too hackish to my taste, we can change it later if it matters.
Feel free to take my ack if you'd upstream it.

  Reviewed-by: Takashi Iwai <tiwai@suse.de>
  Tested-by: Takashi Iwai <tiwai@suse.de>
 
> 2) iosf_mbi also needs to be bound for things to work. The mainline kernel
> currently only has iosf_mbi support in pci mode not for acpi mode. So for
> some people just fixing 1. is enough, but not for everyone. 
> 
> My tablet has the iosf_mbi block in PCI mode, so my testing is not affected
> by this. Great to see that there is a fix for this now too though!

Mine is also PCI, too, so I'd hear if anyone has a device only with ACPI.

> Takashi, not sure what your plans are wrt working on cherrytrail. To make
> sure we're not doing double
> work. I've recently fixed a nasty bug where sometimes the i915 driver would
> hang on load on tablets with DSI screens, as well as 2 other DSI init bug
> fixes:
> 
> https://lists.freedesktop.org/archives/intel-gfx/2016-December/113455.html
> https://lists.freedesktop.org/archives/intel-gfx/2016-December/113460.html
> https://lists.freedesktop.org/archives/intel-gfx/2016-December/113339.html
> 
> If you've a tablet with a DSI screen you likely want these 3 fixes (the
> middle one only applies to drm-next).

Thank you for sharing the information.  Mine has no DSI screen, so luckily I didn't hit such an issue.  (But it has non-working DP audio, which I'm involved now :)
Comment 30 Hans de Goede 2016-12-09 11:02:25 UTC
(In reply to Takashi Iwai from comment #29)
> (In reply to Hans de Goede from comment #26)

<snip>

> > As said I last checked this bug 2 weeks ago, so in the mean time I've
> > written a patch (2 patches, one prep patch) for this myself too, my
> solution
> > is somewhat different it uses the PCI device-id / ACPI-id to
> > determine which address to use instead of the CPU-id. IMHO that is the more
> > correct way to deal with this. I'll attach my 2 patches here, once we agree
> > on which solution is better we can post one or the other upstream.
> 
> Your patches look good to me.  Although the PUNIT_SEMAPHORE macro expansion
> appears a bit too hackish to my taste, we can change it later if it matters.
> Feel free to take my ack if you'd upstream it.
> 
>   Reviewed-by: Takashi Iwai <tiwai@suse.de>
>   Tested-by: Takashi Iwai <tiwai@suse.de>

Ok, I've just submitted my patches upstream with your reviewed and tested-by added.

<snip>

> > Takashi, not sure what your plans are wrt working on cherrytrail. To make
> > sure we're not doing double
> > work. I've recently fixed a nasty bug where sometimes the i915 driver would
> > hang on load on tablets with DSI screens, as well as 2 other DSI init bug
> > fixes:
> > 
> > https://lists.freedesktop.org/archives/intel-gfx/2016-December/113455.html
> > https://lists.freedesktop.org/archives/intel-gfx/2016-December/113460.html
> > https://lists.freedesktop.org/archives/intel-gfx/2016-December/113339.html
> > 
> > If you've a tablet with a DSI screen you likely want these 3 fixes (the
> > middle one only applies to drm-next).
> 
> Thank you for sharing the information.  Mine has no DSI screen, so luckily I
> didn't hit such an issue.  (But it has non-working DP audio, which I'm
> involved now :)

Ok, I'm working on axp288 pmic support now, the patches fix the i2c-designware issues (i2c-tools can access the pmic fine with the patches), but there seems to be an issue with the axp288 interrupt controller code, causing an interrupt to get stuck and my tablet to hang.
Comment 31 Agostinho Carvalho 2016-12-13 19:07:30 UTC
Hello all.

I also have problems with i2c in ECS Cherry Trail platforms.

First, I had problems with backlight, with the following error in dmesg:
[drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip

So, I recompiled with the suggestions from Jani Nikula in
https://bugs.freedesktop.org/show_bug.cgi?id=85977#c38
--------------------
CONFIG_PWM=y
CONFIG_PWM_CRC=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DESIGNWARE_PCI=y
CONFIG_INTEL_SOC_PMIC=y
CONFIG_DRM_I915=m
--------------------

The above configuration, will also try to activate i2c support... in my case without success, because during boot, the machine shows:
i2c_designware 808622C1:06: couldn't acquire bus ownership
i2c_designware: probe of 808622C1:06 failed with error -110

So I applied Takashi Iwai patch into k4.8.11 and compiled everything from scratch:
https://bugzilla.kernel.org/attachment.cgi?id=246361&action=diff
Now the machine shuts down during 'systemd' (it doesn't even load Gnome).
By analyzing 'kern.log', I can see some i2c info, saying that 0x10e is indeed being considered:
i2c_designware 808622C1:06: I2C bus managed by PUNIT
i2c_designware 808622C1:06: Using semaphore reg 0x10e for Cherry Trail
...
...

But for some reason, the machine shuts down abruptly.

The machine being used is an ECS TF10EA model (2-in-1 system):
http://www.ecsusa.com/ECSWebSite/Product/Product_SPEC.aspx?DetailID=1664&CategoryID=3&DetailName=Feature&MenuID=27&LanID=0

From what I can gather, this machine uses a Goodix GT9110 touch controller (which also needs i2c support).

So at this moment I don't have:
-i2c support
-touch pannel support (since it depends on i2c)
-battery status indicator (since it depends on i2c)
-wifi and bluetooth (sdio/uart problem probably)

@ Hans de Goede
My system also uses an AXP288 PMIC chip.
Did your system hang during boot?
Did you had any luck applying full support for it?
Comment 32 Agostinho Carvalho 2016-12-13 19:13:56 UTC
Created attachment 247591 [details]
Logs, Kernel config file

Multiple logs and kernel 4.8.11 config file.
Comment 33 RussianNeuroMancer 2016-12-13 19:16:45 UTC
Agostinho, read latest designware conversations on linux-i2c: https://www.spinics.net/lists/linux-i2c/
Comment 34 tagorereddy 2016-12-21 08:37:53 UTC
The current IOSF_MBI driver for PCI is driving me crazy. Let me point out few of my observations:

1) Windows Installation shows that 'INTEL SIDEBAND FABRIC DEVICE' is located at ACPI/INT33BD and it has no PCI block.

2) In linux, the IOSF driver is searching for PCI/0x2280 device and not ACPI/INT33BD.

3) PCI/0x2280 is getting attached to ACPI/80860F14:01 as node which should never happen as ACPI/80860F14:01 is a SDIO Controller with its own children. Needless to say , this fault is causing the failure of creation of SDIO Controller. Its a major bug.

4) PCI/0x2280 is simple PCI Host bridge on which other PCI devices like display are located. It has nothing to do with IOSF. 

Someone please contact David.E.Box and ask for his kind explanation as to why he had to re-write the driver is PCI mode. 

I don't think its problem of PUNIT semaphore. If so, all other non-i2c drivers using IOSF-MBI should function. The other drivers dependent on IOSF-MBI are 'intel-rapl', 'intel-soc-dts'. By simply debugging them, we should know if IOSF-MBI driver is actually functional.
Comment 35 tagorereddy 2016-12-21 08:53:00 UTC
If you check on windows, pci/0x2280 is PCI standard host CPU bridge, not sideband fabric device.

I think IOSF-MBI driver needs to be rewritten or more accurately restored to older version when it was actually written for ACPI/INT33BD
Comment 36 Hans de Goede 2016-12-21 09:25:34 UTC
(In reply to tagorereddy from comment #35)
> If you check on windows, pci/0x2280 is PCI standard host CPU bridge, not
> sideband fabric device.
> 
> I think IOSF-MBI driver needs to be rewritten or more accurately restored to
> older version when it was actually written for ACPI/INT33BD

The IOSF-MBI registers are part of the PCI config space, so binding to the pci-bridge although not really elegant, is the right thing todo. And is also safe as the presence of the host-bridge with that specific product id does indicate that the IOSF is there.

I think you likely have a completely different problem with your sdio wifi, all pci dattached evices whether they are enumerated through ACPI or PCI are attached to the host-bridge, so ACPI/80860F14:01 having
the bridge as physical-node is fine, if you look at other ACPI device, like e.g. the eMMC controller which does work fine in ACPI mode you will see it has the same thing.

Have you tried the patch I attached to the rtl8723bs githhub issue, to see if that actually fixes things on your tablet, as that patch does fix a real bug, where as your worries about how the IOSF-MBI driver binds itself are just about chasing ghosts AFAICT.
Comment 37 tagorereddy 2016-12-28 11:56:05 UTC
(In reply to Hans de Goede from comment #36)

My device is a laptop with no USB charging or OTG. So, I'd tried only SDIO _ADR patch, i2c and axp288_fuel_gauge patches. Everything works well for upto 3 mins after boot, then the device freezes. I hadn't tried any drm patches BTW. Here's the log:

[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake ack request.
clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
clocksource:                       'refined-jiffies' wd_now: 10002ee30 wd_last: 10002edb8 mask: ffffffff
clocksource:                       'tsc' cs_now: 16ac2c7744a cs_last: 16a8d9bd8f2 mask: ffffffffffffffff
clocksource: Switched to clocksource refined-jiffies
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
i2c_designware 808622C1:06: punit semaphore timed out, resetting
i2c_designware 808622C1:06: PUNIT SEM: 2
i2c_designware 808622C1:06: couldn't acquire bus ownership
axp288_fuel_gauge axp288_fuel_gauge: axp288 reg read err:-110
axp288_fuel_gauge axp288_fuel_gauge: PWR STAT read failed:-110
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
i2c_designware 808622C1:06: punit semaphore timed out, resetting
i2c_designware 808622C1:06: PUNIT SEM: 0
i2c_designware 808622C1:06: couldn't acquire bus ownership
axp288_fuel_gauge axp288_fuel_gauge: IIO channel read error: fffffffb, 0
power_supply axp288_fuel_gauge: driver failed to report `voltage_now' property: -5
***SYSTEM FREEZE***

If I blacklist axp288_fuel_gauge, then there were no errors.
Comment 38 jayki 2016-12-29 01:18:53 UTC
Created attachment 248881 [details]
dmesg

Hello,
i have the same Problem as described here on my Odys Vario Pro 12,
patched 4.10-git with patches above (after editing some lines)
Dmesg still shows me errors:
Sound, Camera still dont work and Touchscreen and Pen have regressions after Linux 4.5, they simply work 1 second an then stucks in "pressed" even if i release my finger/the pen. :(
Wlan only works after setting it to pci in bios and applying other pachtes..


[    2.789523] i2c_designware 808622C1:00: failure requesting irq 8: -16
[    2.789637] i2c_designware: probe of 808622C1:00 failed with error -16
[    3.023058] i2c_designware 808622C1:06: I2C bus managed by PUNIT
[    3.023064] i2c_designware 808622C1:06: Using semaphore reg 0x10e for Cherry Trail
[    3.115557] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found
[    3.154605] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded
Comment 39 tagorereddy 2016-12-29 03:04:12 UTC
UPDATE: I'd disabled i915 module during boot to only find that device runs perfectly fine and axp288-fuel-gauge cause no issue. So, I guess current set of patches(i2c or axp2) are conflicting with i915 or its related modules(drm, i2c-algo-bit).
Comment 40 Hans de Goede 2017-01-01 20:01:39 UTC
Created attachment 249551 [details]
Set of i2c + sfio_mbi + i915 patches

Hi,

(In reply to tagorereddy from comment #39)
> UPDATE: I'd disabled i915 module during boot to only find that device runs
> perfectly fine and axp288-fuel-gauge cause no issue. So, I guess current set
> of patches(i2c or axp2) are conflicting with i915 or its related
> modules(drm, i2c-algo-bit).

Ok, here is a set of patches (replacing the previous i2c patches, but not the axp288 patches) which attempt to fix this. Note as said this is an attempt to fix this, no guarantees.

Alternatively you can just build a kernel from this branch:

https://github.com/jwrdegoede/linux-sunxi/commits/drm-intel-next-queued

Regards,

Hans
Comment 41 tagorereddy 2017-01-01 23:14:42 UTC
(In reply to Hans de Goede from comment #40)
> Ok, here is a set of patches (replacing the previous i2c patches, but not
> the axp288 patches) which attempt to fix this. Note as said this is an
> attempt to fix this, no guarantees.
>
> 
> Regards,
> 
> Hans

The patches look good. No issues yet. The machine's up and running for almost an hour.
Thanks Hans. Happy New Year.
Comment 42 tagorereddy 2017-01-01 23:42:02 UTC
(In reply to Hans de Goede from comment #40)

Strike my last comment. I ran into the same issue again. It happened out of no where. After a reboot, it happened in less than 5 mins.
Comment 43 Hans de Goede 2017-01-02 07:53:04 UTC
(In reply to tagorereddy from comment #42)
> (In reply to Hans de Goede from comment #40)
> 
> Strike my last comment. I ran into the same issue again. It happened out of
> no where. After a reboot, it happened in less than 5 mins.

Bummer, any specific activities (or non activity) you were doing when this happened ?
Comment 44 tagorereddy 2017-01-02 12:40:42 UTC
(In reply to Hans de Goede from comment #43)
> Bummer, any specific activities (or non activity) you were doing when this
> happened ?

I've observed that drm timeout is occurring when ever gpu is asked to render something. 
I've tried 'your_patches+mainline' and the kernel from 'drm-intel-next-queued'. Both produce identical output. I'm hotplugging the axp288-fuel-gauge module and resetting the clocksource in-time to avoid a system freeze so as to look at the log. AFAICT, drm timeouts for every render request. 

On a sidenote, the 'drm-intel-next-queued' has a patch for intel-xhci extended capabilities which is not exporting the symbol 'xhci_intel_cap_init' properly. It's leading to a build failure producing,
ERROR: "xhci_intel_cap_init" [drivers/usb/host/xhci-pci.ko] undefined!
Comment 45 jayki 2017-01-03 01:12:49 UTC
Created attachment 249741 [details]
dmesg_with_patchset

Hello,
i've also applied the patchset and get the follwing errors in dmesg:
Maybe you can help ?
Thanks :)
Comment 46 Hans de Goede 2017-01-03 09:32:26 UTC
Created attachment 249851 [details]
0001-drm-i915-HACK-forcewake-ALL.patch

Hi,

(In reply to tagorereddy from comment #44)
> I've observed that drm timeout is occurring when ever gpu is asked to render
> something. 

Ok, what desktop environment are you using? I'm using gnome3 and not seeing this, but perhaps your desktop environment allows the GPU to go into deeper sleep states; or it is a due to BIOS differences.

> I've tried 'your_patches+mainline' and the kernel from
> 'drm-intel-next-queued'. Both produce identical output. I'm hotplugging the
> axp288-fuel-gauge module and resetting the clocksource in-time to avoid a
> system freeze so as to look at the log. AFAICT, drm timeouts for every
> render request. 

Interesting I'm seeing freezes after suspend/resume, although I never get any clocksource related messages. Are you setting the clocksource to jiffies to avoid these freezes ?

Anyways I've a hunch that the new hangs you're seeing is due to a bad interaction between enabling / disabling GPU powerplanes and the axp288 driver accessing the pmic i2c bus at the same time.
Can you try the patch I'm attaching ?  Note this is a big hammer fix which simply keeps all GPU powerplanes enabled all the time. Please make sure you do not use any form of suspend (some desktop environments do a supsend-to-idle / ACPI-S1 when idle) while using this, I think things may break if you do. Note this is in no way a proper fix, just a hack to see if keeping the forcewake locks in use all the time avoids the issue.

Regards,

Hans

p.s.

I'm going on a short trip for a couple of days so you may not hear anything from me until Saturday.
Comment 47 tagorereddy 2017-01-03 11:16:28 UTC
(In reply to Hans de Goede from comment #46)
> Created attachment 249851 [details]
> 0001-drm-i915-HACK-forcewake-ALL.patch
>
> (In reply to tagorereddy from comment #44)
> > I've observed that drm timeout is occurring when ever gpu is asked to
> render
> > something. 
> 
> Ok, what desktop environment are you using? 

I'm using KDE Plasma 5.8.4 on openSUSE Tumbleweed

> I'm using gnome3 and not seeing this, but perhaps your desktop environment
> allows > the GPU to go into deeper sleep states; or it is a due to BIOS
> differences.

Perhaps. I don't see any power management services handling the GPU though. Could be some KDE plasma thing.
And I think we can rule out any BIOS differences. Most of these machines are identical.
 
> > I've tried 'your_patches+mainline' and the kernel from
> > 'drm-intel-next-queued'. Both produce identical output. I'm hotplugging the
> > axp288-fuel-gauge module and resetting the clocksource in-time to avoid a
> > system freeze so as to look at the log. AFAICT, drm timeouts for every
> > render request. 
> 
> Interesting I'm seeing freezes after suspend/resume, although I never get
> any clocksource related messages. Are you setting the clocksource to jiffies
> to avoid these freezes ?

By default, 
available_clocksources: tsc, jiffies, refined_jiffies.
current_clocksource: tsc.

But when some bugs make 'tsc' skew go too large deeming it unstable. Then clocksource is witched to 'refined_jiffies' which is very erratic. Its almost sinusoidal. At peaks, its rushes clock 4-5 secs in matter of a single second. All clocks go haywire including system clock. All kernel modules depending on time-based calculations go haywire which i2c-designware-baytrail is BTW. The only way to halt system freeze is to unload axp288_fuel_gauge module before i2c bus stops responding and then reset clocksource to tsc.

> Anyways I've a hunch that the new hangs you're seeing is due to a bad
> interaction between enabling / disabling GPU powerplanes and the axp288
> driver accessing the pmic i2c bus at the same time.
> Can you try the patch I'm attaching ?  Note this is a big hammer fix which
> simply keeps all GPU powerplanes enabled all the time. Please make sure you
> do not use any form of suspend (some desktop environments do a
> supsend-to-idle / ACPI-S1 when idle) while using this, I think things may
> break if you do. Note this is in no way a proper fix, just a hack to see if
> keeping the forcewake locks in use all the time avoids the issue.

The patch you've included stopped freezing(no timeouts) and no incidents yet. Everything is running clean. The Hammer patch works. Now lets try for a chisel.

> p.s.
> 
> I'm going on a short trip for a couple of days so you may not hear anything
> from me until Saturday.

Good Luck and safe travel.
Comment 48 Hans de Goede 2017-01-06 09:42:08 UTC
Created attachment 250511 [details]
Set of i2c + sfio_mbi + i915 patches

Hi,

i've managed to reproduce the "timed out waiting for forcewake ack request." errors on my own z8300 device (I got them during the resume phase of a suspend / resume cycle).

And I've managed to write a new version of my patch set, which for me fix these without needing a big hammer. Please test. Note patches 1-6 are the same as before the others are either changed or new.

Please do not forget to drop the HACK / big hammer patch while testing. If everything works for you with this set, can you please also test with the last patch dropped ? I'm not 100% sure that last patch is needed, but it does seem to be the sane thing to do.

Regards,

Hans
Comment 49 Hans de Goede 2017-01-06 09:43:58 UTC
p.s.

My git repo / branch is here now:
https://github.com/jwrdegoede/linux-sunxi/commits/drm-intel-next-queued

As it seems that my linuxtv gspca repo got corrupted somehow.
Comment 50 tagorereddy 2017-01-06 12:54:33 UTC
(In reply to Hans de Goede from comment #48)
> Created attachment 250511 [details]
> Set of i2c + sfio_mbi + i915 patches
> 
> Hi,
> 
> i've managed to reproduce the "timed out waiting for forcewake ack request."
> errors on my own z8300 device (I got them during the resume phase of a
> suspend / resume cycle).
> 
> And I've managed to write a new version of my patch set, which for me fix
> these without needing a big hammer. 

The set of patches work without the HAMMER. No bugs reported.
Fantastic!
What next?
Comment 51 tagorereddy 2017-01-06 13:28:55 UTC
(In reply to Hans de Goede from comment #48)

After using the machine for a while the following error poped up:

[drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=145979 end=145980) time 339 us, min 763, max 767, scanline start 759, end 776

No freezes though. I don't know what caused it. I was doing simple browsing through the file manager. I'm using your kernel from drm-intel-next-queued btw.
Comment 52 Hans de Goede 2017-01-07 19:15:31 UTC
Hi

(In reply to tagorereddy from comment #51)
> (In reply to Hans de Goede from comment #48)
> 
> After using the machine for a while the following error poped up:
> 
> [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A
> (start=145979 end=145980) time 339 us, min 763, max 767, scanline start 759,
> end 776

Yes I've seen that once too, I believe it is unrelated to my patches, this also happens occasionally on machines with normal desktop CPUs.

(In reply to tagorereddy from comment #50)
> What next?

I'll submit these patches upstream tomorrow, I expect there to be some discussion around them though, so I may need to rework them.

Is it ok if I add a:

Tested-by: tagorereddy <tagore.chandan@#####.com>

To the commit msg of these patches ?

Regards,

Hans
Comment 53 tagorereddy 2017-01-08 00:52:35 UTC
(In reply to Hans de Goede from comment #52)
> > [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A
> > (start=145979 end=145980) time 339 us, min 763, max 767, scanline start
> 759,
> > end 776
> 
> Yes I've seen that once too, I believe it is unrelated to my patches, this
> also happens occasionally on machines with normal desktop CPUs.

I thought so too. But the bug must be propagating through the drm patches on your branch. It never occurred on the mainstream kernel. Also the bug is very rare and hard to reproduce.
 
> I'll submit these patches upstream tomorrow, I expect there to be some
> discussion around them though, so I may need to rework them.
> Is it ok if I add a:
> Tested-by: tagorereddy <tagore.chandan@#####.com>
> To the commit msg of these patches ?
> 

Sure. 

> Regards,
> 
> Hans

Once again thanks Hans. Fantastic work.
Comment 54 em.viala 2017-02-02 16:28:52 UTC
Hi

I have an ACER SW5_017 with an intel atom x5-z8350 and I had the same punit semaphore bug... Then compiled 4.10 with your set of patches.. This prevents the kernel crash, but the screen is still black with i915.
Here are some new messages that comes up with theses patches:

07:52:58: i2c_designware 808622C1:04: failure requesting irq 8: -16
07:52:58: i2c_designware: probe of 808622C1:04 failed with error -16
...
07:52:58: i2c_designware 808622C1:06: I2C bus managed by PUNIT
...
07:52:58: i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xaa43
07:52:58: [drm] failed to find VBIOS tables
...
07:52:58: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 33: Can't calculate constants, dotclock = 0!
Comment 55 Hans de Goede 2017-02-02 17:35:05 UTC
Hi,

(In reply to em.viala from comment #54)
> 07:52:58: i915 0000:00:02.0: Invalid PCI ROM header signature: expecting
> 0xaa55, got 0xaa43
> 07:52:58: [drm] failed to find VBIOS tables

These 2 lines are what is causing your screen to not lite up. This definitely has a different root cause then this bug.

You might want to try adding this patch:

https://github.com/jwrdegoede/linux-sunxi/commit/3a081e625bc6e3561d62b34a8b79ceb1e9c62557

Not promises it will help though.

Regards.

Hans
Comment 56 em.viala 2017-02-03 13:41:33 UTC
(In reply to Hans de Goede from comment #55)
> Hi,
> 
> (In reply to em.viala from comment #54)
> > 07:52:58: i915 0000:00:02.0: Invalid PCI ROM header signature: expecting
> > 0xaa55, got 0xaa43
> > 07:52:58: [drm] failed to find VBIOS tables
> 
> These 2 lines are what is causing your screen to not lite up. This
> definitely has a different root cause then this bug.
> 
> You might want to try adding this patch:
> 
> https://github.com/jwrdegoede/linux-sunxi/commit/
> 3a081e625bc6e3561d62b34a8b79ceb1e9c62557
> 
> Not promises it will help though.
> 
> Regards.
> 
> Hans

It does work !
That's amazing, thank you so much Hans !
Comment 57 Hans de Goede 2017-02-10 10:18:29 UTC
(In reply to tagorereddy from comment #50)
> The set of patches work without the HAMMER. No bugs reported.
> Fantastic!
> What next?

tagoreddy, upstream review has resulted in one patch being dropped from the patch-set as it seems to be unnecessary, when you've some time can you please retest my latest cht branch ? :

https://github.com/jwrdegoede/linux-sunxi/commits/drm-intel-next-queued-cht

Thanks,

Hans
Comment 58 tagorereddy 2017-02-11 08:13:22 UTC
(In reply to Hans de Goede from comment #57)
> 
> tagoreddy, upstream review has resulted in one patch being dropped from the
> patch-set as it seems to be unnecessary, when you've some time can you
> please retest my latest cht branch ? :
> 
> https://github.com/jwrdegoede/linux-sunxi/commits/drm-intel-next-queued-cht

Could you please, mention the name of the rejected patch?
Comment 59 tagorereddy 2017-02-11 23:36:51 UTC
(In reply to Hans de Goede from comment #57)
>
> tagoreddy, upstream review has resulted in one patch being dropped from the
> patch-set as it seems to be unnecessary, when you've some time can you
> please retest my latest cht branch ? :

I've successfully tested the branch. No issues to report other than the build error reported in comment #44 regarding 'xhci_intel_cap_init'.

Thanks,
tagorereddy
Comment 60 Hans de Goede 2017-02-12 10:48:45 UTC
(In reply to tagorereddy from comment #58)
> (In reply to Hans de Goede from comment #57)
> > 
> > tagoreddy, upstream review has resulted in one patch being dropped from the
> > patch-set as it seems to be unnecessary, when you've some time can you
> > please retest my latest cht branch ? :
> > 
> > https://github.com/jwrdegoede/linux-sunxi/commits/drm-intel-next-queued-cht
> 
> Could you please, mention the name of the rejected patch?

"drm/i915: Acquire P-Unit access when modifying P-Unit settings" this was basically my first attempt to fix the forcewake timeouts which I left in, but upstream thought things should work without it and in my testing they did, so it got dropped (for now, we can resurrect it later if necessary).

(In reply to tagorereddy from comment #59)
> I've successfully tested the branch. No issues to report other than the
> build error reported in comment #44 regarding 'xhci_intel_cap_init'.

Great, thank you.

About the build error I'm not seeing that but I'm building xhci in, I need to respin the xhci patches anyways but I've not gotten around to that yet.
Comment 61 tagorereddy 2017-03-02 10:03:22 UTC
(In reply to Hans de Goede from comment #60)

Hello Hans,

I've recently noticed that whenever 'axp288_fuel_gauge' module loads before 'axp288_adc', its throwing the following error continuously until the later is loaded:

axp288_fuel_gauge: ADC charge current read failed:-19

Would you please add 'axp288_adc' as a dependency for 'axp288_fuel_gauge'.

Thanks,
Tagore
Comment 62 tagorereddy 2017-03-28 06:35:27 UTC
Hans De Goede's patches are now upstream.

Note You need to log in before you can comment on or make changes to this bug.