Backlight hack/WIP patch found in #85977 doesn't work for Acer Aspire Switch 10 with Intel Atom Z3735F. dev_priv->vbt.dsi.config->pwm_blc == 1 on it, so it seems to be BYT-CR and, as Shohbit answered, needs to have brightness controlled by LPSS PWM. However, unlike another Z3735F tablet (Teclast X98 Air 3G) PWM is not present in ACPI DSDT and not detected by LPSS PWM 4.0 kernel driver (CONFIG_PWM_LPSS_PCI, CONFIG_PWM_LPSS_PLATFORM and CONFIG_X86_INTEL_LPSS are enabled in kernel options). lspci also doesn't show any PWM device. In Windows, I can see Intel Atom LPIO1 PWM Controller at PCI Bus 0-30-1 (should be probably pci 0000:00:1e.1 in Linux enumeration) in System Information Viewer tool, but it's not present in Device Manager, so I'm not sure if it's used at all. May there be any other method to set backlight level involved? I tried compiling 3.14 kernel from Android-IA, and it actually tries to set backlight via LPSS, but fails since PWM is not detected: [ 0.968667] lpio_bl_read: can't find pwm device with pwm_num 0 [ 2.414817] lpio_bl_write: can't find pwm device with pwm_num 0
Please try http://mid.gmane.org/1452610789-30032-1-git-send-email-shobhit.kumar@intel.com
Created attachment 122343 [details] dmesg from vanilla 4.5.0 kernel
Created attachment 122344 [details] vanilla kernel 4.5.0 with 3 lpss/pwm patches from Shobhit Kumar Hello, another Linux user of Acer Switch 10 here. I was hoping that creator of this bug will add needed info, but nothing happened for long time. So I applied those patches: https://patchwork.freedesktop.org/patch/70286/ https://patchwork.freedesktop.org/patch/70287/ https://patchwork.freedesktop.org/patch/70288/ I hope that those are patches that Jani Nikula was asking for. Dmesg from pure vanilla kernel is already attached. If there is anything else I can do to make backlight work, Iam available for testing/more info providing. cat dmesg_4.5_vanilla.txt | grep -i backlight [ 3.838230] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip cat dmesg_4.5_vanilla+lpss.txt | grep -i backlight [ 3.831272] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip: pwm_lpss Thank you for your work
Also apply - https://patchwork.freedesktop.org/patch/70965/ This is just a quick hack and I have not got around posting a proper patch as my device broke in between and I couldn't test it.
Created attachment 122348 [details] dmesg after applying drm/i915: Retry few time... patch Nothing visible changed. Ill recompile kernel with additional sound patches for later today - dmesg will be much less bloated with unrelated messages. All pwm/lpss patches were applied without problem (no manual patching needed with v4.5.0 source code). Full dmesg in attachment. cat dmesg_4.5_vanilla+lpss+retrypatch | grep -i backlight [ 3.832961] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip: pwm_lpss Thanks
Hi again, After applying all four patches, I did some debugging via additional kernel messages. I went backwards from message "Failed to own the pwm chip: pwm_lpss" to function *pwm_get(struct device *dev, const char *con_id) in drivers/pwm/core.c. After macro function "list_for_each_entry(p, &pwm_lookup_list, list) {.....}" variable "best" is still set to zero and pwm_get jumps to label "out:" because pointer "chosen" is still NULL. list_for_each_entry did not iterate at all - printk message (placed after "match = 0;") did not occurred in dmesg. Ill try to investigate further why &pwm_lookup_list is empty.
Now I know why list_for_each_entry did not iterate. Function pwm_add_table fills the list in "drivers/mfd/intel_soc_pmic_core.c, line 109" AFTER the pwm_get is already executed (and failed). dmesg with my debugging lines: dmesg | grep ZR [ 5.360759] ZR pwm_setup_backlight after variable definition [ 5.360841] ZR pwm_setup_backlight pwm is set to &lpss_pwm_info [ 5.360853] ZR *pwm_get() [ 5.360860] ZR *pwm_get() const char *dev_id = 0000:00:02.0 *con_id=pwm_lpss [ 5.360867] ZR *pwm_get() IS_ENABLE(CONFIG_OF) && dev && dev->of_node = FALSE and non return [ 5.360877] ZR *pwm_get() and mutex_lock(&pwm_lookup_lock); [ 5.360884] ZR *pwm_get() after list_for_each_entry() best = 0 [ 5.360891] ZR *pwm_get() (!chosen==true) goto out [ 5.360897] ZR *pwm_get() mutex_unlock(&pwm_lookup_lock); [ 5.360959] [drm:pwm_setup_backlight [i915]] *ERROR* ZR Failed to own the pwm chip: pwm_lpss [ 5.492548] ZR intel_soc_pmic_i2c_probe() starting pwm_add_table [ 5.492566] ZR pwm_add_table mutex lock and size_t num = 1 [ 5.492577] ZR pwm_add_table inside while (num--){...} num=0 and &table->provider = crystal_cove_pwm and &table->dev_id = 0000:00:02.0 and &table->con_id = pwm_backlight [ 5.492598] ZR pwm_add_table mutex unlock How can I force pwm_get to wait until pwm_add_table is finished without breaking everything? Another mutex? Ill try to fiddle with it in the evening.
https://patchwork.freedesktop.org/patch/70965/ Just a hack. Correct implementation mostly will use deferred probe. Increase retry counts if needed. I had a patch somewhere for that as well. Need to relook and post.
This patch I have already applied. dev_priv->vbt.dsi.config->pwm_blc == 1 PPS_BLC_PMIC==0 as defined in drivers/gpu/drm/i915/intel_bios.h, line 786 so the while retry loop does not execute at all. if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) { int retry = 4; do { intel_dsi->gpio_panel = gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH); msleep(50); } while (IS_ERR(intel_dsi->gpio_panel) && --retry); if (!retry) { DRM_ERROR("Failed to own gpio for panel control\n"); intel_dsi->gpio_panel = NULL; } New dmesg debug. Message from inside the loop is missing. [ 5.668493] ZR intel_soc_pmic_i2c_probe() starting pwm_add_table [ 5.668509] ZR pwm_add_table mutex lock and size_t num = 1 [ 5.668518] ZR pwm_add_table inside while (num--){...} num=0 and &table->provider = crystal_cove_pwm and &table->dev_id = 0000:00:02.0 and &table->con_id = pwm_backlight [ 5.668536] ZR pwm_add_table mutex unlock [ 5.758320] ZR intel_dsi_init BEFORE if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {...} AND dev_priv->vbt.dsi.config->pwm_blc is set to 1 [ 5.758340] ZR intel_dsi_init AFTER if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {...} [ 5.758446] ZR pwm_setup_backlight after variable definition [ 5.758456] ZR pwm_setup_backlight pwm is set to &lpss_pwm_info [ 5.758464] ZR *pwm_get() [ 5.758472] ZR *pwm_get() const char *dev_id = 0000:00:02.0 *con_id=pwm_lpss [ 5.758480] ZR *pwm_get() IS_ENABLE(CONFIG_OF) && dev && dev->of_node = FALSE and non return [ 5.758492] ZR *pwm_get() and mutex_lock(&pwm_lookup_lock); [ 5.758500] ZR *pwm_get() inside list_for_each_entry() 0000:00:02.0 match = 0 [ 5.758509] ZR *pwm_get() after list_for_each_entry() best = 0 [ 5.758516] ZR *pwm_get() (!chosen==true) goto out [ 5.758524] ZR *pwm_get() mutex_unlock(&pwm_lookup_lock); [ 5.758531] ZR Failed to own the pwm chip: pwm_lpss
I noticed the patches don't work on the 4.6.3 kernel. Are there patches available for it? I'm trying to get the backlight working on my HP Stream 7 with Z3735G. Be glad to help with testing.
I think that regarding pwm backlight on x86_64 and these patches from Shobit, it still applies what I wrote months ago in the mailing list (text copied below). There is no code at all to use an lpss pwm as backlight in a normal ACPI x86 kernel. http://www.spinics.net/lists/intel-gfx/msg92148.html ----------------- I think there is a lot to be done first, to be able to test this. If I understand correctly, despite the lpss pwm may be available, it will not be used as pwm-backlight (video/backlight/pwm_bl.c) because it depends on "CONFIG_OF" and it is ready for devicetree only. The only x86 that enable OF are X86_INTEL_CE and OLPC, and pwm_bl is completely disabled without OF. I don't have any INTEL_CE or OLPC, this LPSS of the Atom SoC is a different thing. So, someone has to implement pwm_bl on my x86 first, for any of the patches wrt i915 to be used at all. Should X86_INTEL_LPSS enable OF? Should there be a devicetree definition for it first? Does someone have to allow pwm_bl to work with ACPI? Is all that ready in some branch of some other linux team? -------------------- By the way, I think that bug 85977 and bug 96571 are very well related to this. Isn't it?
Hello everybody, I checked the patches listed and they aren't upstream yet. Is there any update on this case? Do these patches have effectively fixed the problem? Thank you.
None of the patches posted here can be applied to the current mainline (4.13.0-rc2) kernel. They didn't work for me on 4.6.0 either. As far as I know, noone has ever managed to control the backlight of this laptop under Linux. From what I can tell (not a dev), the problem is with the LPSS PWM driver for this device, not just the bwm_bl backlight driver. There are no devices listed under /sys/class/pwm/ so even if pwm_bl works, there is no pwm chip for it to use. Here are the results of some of my testing: https://frangez.tech/switch10/ . If there's any info missing, let me know.
Created attachment 133201 [details] dsdt.dsl from bios version 1.18 Hello again, just to let you know, even Hans de Goede`s linux-sunxi [1] with a lot of not-yet-upstreamed patches for baytrail/cherrytrail does not work. Strange thing is that this kernel supports lpss-pwm for certain devices (accoring Hans` Hacking Blog), but on Acer Switch 10 dmesg there is: [drm] Using crystal_cove_wpm pwm-device for backlight control. I inserted a lot of debuging printk messages into sunxi, and there is nothing indicating that lpss should be used for Switch 10. (but maybe I did something wrong - modules pwm-lpss and pwm-lpss-platform forced to load from initrd.img, and i915 module loaded later (via modprobe manualy)) In sunxi I find some commits very interesting: ACPI / LPSS: Only call pwm_add_table() for Bay Trail PWM if PMIC HRV is 2 [2] mfd: intel_soc_pmic: Differentiate between Bay and Cherry Trail CRC variants [3] mfd: intel_soc_pmic: Export separate mfd-cell configs for BYT and CHT [4] and very very interesting ACPI / bus: Introduce a list of ids for "always present" devices "Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide the LPSS PWM controller in ACPI..." Maybe Hans De Goede could shed some light on this issue. [1] https://github.com/jwrdegoede/linux-sunxi [2] https://github.com/jwrdegoede/linux-sunxi/commit/44eb7ab01b1a3bd3d70f623df013c314e8032316 [3] https://github.com/jwrdegoede/linux-sunxi/commit/118c804aa8ba9be46667cbafa1755c058e47ed77 [4] https://github.com/jwrdegoede/linux-sunxi/commit/cb63e6df172879b5476ae704c87bd06ba391a1f9 [5] https://github.com/jwrdegoede/linux-sunxi/commit/b7ecf663c75eed1e764f57281f9508c49c18516e I`m including dsdt.dsl_ver1.18 from bios versions 1.18 (I was not able to upgrade to last 1.20 version via W8). Maybe using custom dsdt could work around this issue, until (if ever) is this issue solved.
Hello Miha, Darlor, Thank you for the information and the time invested, if any new information is needed for this case it will be requested in the comments below. Thanks again.
Please check out http://www.spinics.net/lists/intel-gfx/msg129332.html which was found to be working on some devices with LPSS. Also if drm log says using crc pwm that means that device is using crystal_cove_pmic as indicated by the VBT.
Hi, Shobhit. I've applied your new patches to 4.13.0-rc2 with PWM_LPSS_PLATFORM=y and DRM_I915=m. No PWM chips showed up in /sys/class/pwm. (more details: https://frangez.tech/switch10/4.13-rc2-switch10-17/) Then I set PWM_CRC=y and this gave me pwmchip0 in sysfs. It only has one channel, which would make sense for a backlight chip. After exporting that channel however, things stop making sense. Reading /sys/class/pwm/pwmchip0/pwm0/enable shows the channel disabled. Since the screen is at full brightness, this could either mean that it's not used, or that the device has some kind of fallback (so the UEFI team didn't have to mess with PWM in firmware). Writing random values into duty_cycle and period and enabling it succeeded, but didn't do anything (no effect on backlight). (more details: https://frangez.tech/switch10/4.13-rc2-switch10-17-16/) If there is a CRC PWM chip in there, it's either not used for backlight or the PWM_CRC driver can't control it. Let me know if you need any more info.
Created attachment 134602 [details] 3 dmesg with different pci kernel parameters Hello everyone, I think (hope) I identified underlying problem why PCI device 8086-0F08 PWM Controller is not detected. (without it backlight will not work) But now I'm stuck because I`m not familiar with PCI Bus, e820 etc... and to be honest I don`t exactly know what I`m looking at... First let me explain my thoughts: On Windows using SIV - System Information Viewer I can see: Bus-Numb-Fun IRQ Vendor-Dev-Sub_OEM-Rev Class (0:63) Vendor and Device Description 0-00-0 8086-0F00-09281025-0F Host Bridge Intel Atom SSA-CUnit 0-02-0 8086-0F31-09281025-0F VGA Controller Intel Atom Gen7 [GPU-0] 0-20-0 8086-0F35-09281025-0F XHCI Controller Intel Atom USB xHCI Host Cntrlr 0-26-0 8086-0F18-09281025-0F Other Encryption Intel Atom SEC 0-30-1 8086-0F08-09281025-0F Other Interface Intel Atom LPIO1 PWM Controller 0-31-0 8086-0F1C-09281025-0F ISA Bridge Intel Atom Power Control Unit 0 None of these devices is mentioned in DSDT. (at least by Vendor-Device code) lspci on linux shows something like: 00:00.0 0600: 8086:0f00 Host bridge: Intel Corporation... 00:02.0 0300: 8086:0f31 VGA compatible controller... 00:14.0 0c03: 8086:0f35 USB controller... 00:1a.0 1080: 8086:0f18 Encryption controller... 00:1f.0 0601: 8086:0f1c ISA bridge... ACPI-IDs are same, but PWM controller is missing. So I think that PWM controller is connected to PCI bus. (CONFIG_PWM_LPSS_PCI must be enabled so pwm-lpss-pci.ko module can be used). But why this PCI device is not detected? Lets have a look on kernel messages in file 'dmesg_nothing_special' Lines that caught my eyes: PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000) PCI: not using MMCONFIG PCI: Using configuration type 1 for base access PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000) [Firmware Info]: PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] not reserved in ACPI motherboard resources PCI: not using MMCONFIG PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. Expanded resource Reserved due to conflict with PCI Bus 0000:00 So I googled a little bit and added kernel parameter "memmap=64M\$0xe0000000" so the extended PCI configuration space 0x00000000e0000000-0x00000000e3ffffff is reserved. (don't forget that $ needs to be escaped with '\' or '\\\' in /etc/default/grub). This dmesg is in file 'dmesg_memmap_64M_0xe0000000' [https://www.centos.org/forums/viewtopic.php?t=53903] and I got: PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xe0000000-0xe3ffffff] (base 0xe0000000) PCI: MMCONFIG at [mem 0xe0000000-0xe3ffffff] reserved in E820 PCI: Using configuration type 1 for base access PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge Expanded resource Reserved due to conflict with PCI Bus 0000:00 So, MMCONFIG only partially covers extended configuration for this bridge. I don`t exactly know what it means. Only that made sense was to add pci=nocrs, but it did not solve a thing except that line: Expanded resource Reserved due to conflict with PCI Bus 0000:00 is not in dmesg anymore. This dmesg is in file 'dmesg_memmap_64M_0xe0000000_pci_nocrs'. Could someone please confirm, that it make sense and/or provide some tips how to go forward? Thanks ('cut -d" " -f6-' < dmesg > graphical_diff makes dmesgs very easy to compare :-) )
Hello everyone, this is just a friendly ping. Shobhit, is there any extra information that you need from Darlor and Miha? Miha, Darlor, have you been able to progress on this issue by your side? Thank you in advance.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Hello, Nothing new on kernel 4.15.x. I think that from i915/drm/pwm point of view everything should work. PWM device is not IMHO detected during PCI enumeration. Maybe we should move this bug into PCI (or ACPI) kernel.bugzilla?
Based on comment resolving this as notourbug and please make bug to kernel side . Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.