First thing is this a regression or has this always been happening for you.

(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.

Created attachment 231541 [details]
DMESG

Created attachment 231551 [details]
DSDT (decompiled)

This appears to be the same issue as bz150481.

See https://bugzilla.kernel.org/show_bug.cgi?id=150481#c1

I also have several x5-z8300 boards with the same problem.

(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.

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.

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.

tagorereddy: so the proper driver is not present in the current kernel, do You manage to make it work ?

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/

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

(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

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.

Hi, I have one of the affected devices, will try to test Takashi's patch today or tomorrow.

Thank you!

Also changing in bios all ACPI settings to PCI seams to solve the problem.

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)

(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.

Created attachment 245941 [details]
Revised test patch to bind iosc_mbi via ACPI for Braswell

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

(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.

Created attachment 246351 [details]
Revised patch to bind iosf_mbi via ACPI for Braswell

Created attachment 246361 [details]
Patch to switch PUNIT semaphore value for Cherry Trail

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

*** Bug 150481 has been marked as a duplicate of this bug. ***

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

Created attachment 246631 [details]
[PATCH 1/2] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions

Created attachment 246641 [details]
[PATCH 2/2] i2c: designware-baytrail: Add support for cherrytrail

(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 :)

(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.

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?

Created attachment 247591 [details]
Logs, Kernel config file

Multiple logs and kernel 4.8.11 config file.

Agostinho, read latest designware conversations on linux-i2c: https://www.spinics.net/lists/linux-i2c/

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.

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

(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.

(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.

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

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).

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

(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.

(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.

(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 ?

(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!

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 :)

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.

(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.

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

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.

(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?

(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.

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

(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.

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!

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

(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 !

(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

(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?

(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

(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.

(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

Hans De Goede's patches are now upstream.