Bug 96571

Summary: [CHV] Backlight init fails on Surface 3 if module load order is wrong
Product: DRI Reporter: Stephen Just <stephenjust>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: NEW --- QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: minor    
Priority: low CC: bugzilla, darlor, hatomist, hstn, intel-gfx-bugs, jan.brummer, lvlrdka22, mike, oto.stava, sassmann, scorp, shobhit.kumar, viric
Version: XOrg git   
Hardware: All   
OS: Linux (All)   
Whiteboard: ReadyForDev
i915 platform: BSW/CHT, BYT i915 features: display/backlight
Bug Depends on:    
Bug Blocks: 96923    
Description Flags
-EPROBE_DEFER attemp for i915
lpss traces verifying it is added
Fix the device name of pwm-lpss so the pwm lookup table is correct
kernel log with drm.debug=0xe
dump of i915_vbt
Kernel config for 4.16.3 which works on Asus T100HA with delayed loading of i915 none

Description Stephen Just 2016-06-18 01:39:14 UTC
As stated by Jani in https://bugs.freedesktop.org/show_bug.cgi?id=85977#c38, if i915 is loaded before relevant PMIC/I2C/PWM drivers, PWM backlight probe can fail.

[drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip

It would be nice to have this fixed so that the backlight on Surface 3 might work reliably on distro-stock kernels that don't build-in certain modules to influence the probe order.

Quote from Bug 85977:
>There still remains the issue with probe ordering: if i915 gets probed before all >the related pmic/i2c drivers, pwm_get() fails as described in comment #32. If you >want to file a new bug for that, I don't mind.
>As a workaround, these config options worked for me on Surface 3 PMIC backlight:
Comment 1 Jani Nikula 2016-06-20 09:11:52 UTC
Please don't hold your breath while waiting for this. :(

The "straightforward" solution is to have i915 support probe defer until the required stuff becomes available. However we're pretty deep in the probe before we realize, whoops, we need something else. It's a complex driver with complex init, and the backoff gets tricky. If it were easy, it would have been done already.

Dunno, maybe it would be easier to just make the PWM backlight independent of i915. It's just that it's not without issues either.
Comment 2 Stephen Just 2016-06-20 14:15:33 UTC

Is there possibly some mechanism to force a deferred probe via a kernel parameter, which would achieve the same thing in most cases? I haven't seen any generic way to do this, though it sounds like much less work to implement.
Comment 3 Jani Nikula 2016-06-20 15:57:00 UTC
(In reply to Stephen Just from comment #2)
> Is there possibly some mechanism to force a deferred probe via a kernel
> parameter, which would achieve the same thing in most cases? I haven't seen
> any generic way to do this, though it sounds like much less work to
> implement.

I'm afraid I don't have any good ideas. Perhaps you could tweak the init system to not probe i915 until later. *shrug*.
Comment 4 Shobhit 2016-06-29 15:54:41 UTC
Created attachment 124781 [details] [review]
-EPROBE_DEFER attemp for i915

I did attempt implementing deferred probe, but really couldn't test without a device. Attaching the patch. Am sure it will not be as simple as the patch makes it look. So not much hope but you can give it a try and we'll know what are the problems you face with this.
Comment 5 viric 2016-07-09 14:03:26 UTC
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. So I don't see how it is a problem of ordering.

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 90075 is very well related to this (I also wrote this text therE). Isn't it?
Comment 6 Stephen Just 2016-07-09 14:45:41 UTC
I think there may be some confusion: the Surface 3 seems to use pwm-crystalcove, not lpss. As far as I can tell, these are different implementations although I could be wrong.

I have not seen any dmesg logs about gpio devices as are addressed in Shobhit's attached patch.
Comment 7 viric 2016-07-09 14:50:30 UTC
Isn't there the very same problem? pwm_bl.c (PWM based backlight driver), the piece required by i915, will not do anything at all unless there is CONFIG_OF and a pwm in devicetree.
Comment 8 viric 2016-07-09 14:52:35 UTC
As far as I understand, i915 wants a "backlight control". That control is provided, for example, by pwm_bl (pwm-based backlight control), that will use any of the pwm available in the system (lpss, crystalcove, pmic, whatever). 3 pieces that have to work fine. I think that i915 works fine in my Intel Atom ACPI system, also works fine the pwm (lpss), but the glue (pwm-based backlight control) is just not there at all.
Comment 9 Shobhit 2016-07-11 05:36:10 UTC
I could never test my patches as I didn't have any device using LPSS, but on looking at drivers/pwm/pwm-lpss-platform.c, I could see that it is registering a platform driver with ACPI ID - "80860F09". So I assumed it would be probed and loaded.

If that worked, then I hoped we should be able to use pwm-lpss in i915. But as I said, I could not test or debug anything with lack of device. 

I am sure that the pwm-crystalcove should be working once module load problem is solved (Try attached patch in this bug)

Putting patch set attempting lpss related changes in i915 again in this bug for completeness.

Comment 10 viric 2016-07-11 07:22:08 UTC
I guess that the pwm driver patches are OK, as they were in this my LPSS:


But the problem is that there is no glue between any PWM and i915 other than drivers/video/backlight/pwm_bl.c. It only adds support for *some* PWM devices to be used as backlight, and only in CONFIG_OF (embedded x86, with devicetree, non-ACPI).

So, PWM works, i915 works, but the pwm-backlight glue called by i915 is not present in x86 ACPI.


See how pwm_backlight_probe() calls just pwm_backlight_parse_dt(), that for non-CONFIG_OF just returns -ENODEV. Then, i915 never finds a backlight pwm for an ACPI (non-CONFIG_OF) system).
Comment 11 viric 2016-07-11 07:37:55 UTC
This is the i915 code that tries to find the pwm-backlight controller:


that controller is added in drivers/video/backlight/pwm_bl.c , but not for ACPI systems like my LPSS and, I guess, also this crystalcove. Someone should add ACPI code to pwm_bl.c to handle those ACPI PWM devices, because it only works for non-ACPI (very few x86, with devicetree, CONFIG_OF).

I have very little idea of kernel developing and I may be wrong, but that is how I understand the situation.
Comment 12 Shobhit 2016-07-11 08:31:52 UTC
pwm_bl.c is not used and as you said is based on device tree. The code that you point in i915, I wrote based on ACPI match from drivers/mfd/intel_soc_pmic_core.c

The MFD driver will add this controller to pwm_table and will call the necessary probes. This works fine as I have tested the code for pwm-crystalcove. The pwm-crc is a cell device for MFD crystal cove PMIC.

In case of LPSS, my understanding is that we need to load drivers/pwm/pwm-lpss.c and drivers/pwm/pwm-lpss-platform.c which is again based on ACPI. The corresponding ID in the driver is "80860F09". So once we ensure that this is loading the glue path should be okay. I just could not test this because I don't have a device.

If you can enable -

And use my other patches, I assumed it should work. Of course I maybe wrong, so if you have not tested this, can you test it and update me on your findings ? Basically check if in pwm-lpss-platform.c probe is being called or not.
Comment 13 viric 2016-07-11 08:47:21 UTC
I already tested that in April and reported about it. Is there anything new that I should test?


The PWM devices are present and drivers loaded, as shown in:


but they are not detected by i915. None of them is named "pwm-backlight", so I guess that I miss something that would map the existing PWM to the name "pwm-backligth", maybe like this line does for crystalcove:


Is there anything that can map LPSS pwm to "pwm-backlight"? That's the piece I could not find anywhere.
Comment 14 Shobhit 2016-07-11 08:51:54 UTC
Check the patches -
General re factoring in i915

Add pwm lookup table. Device is called - "pwm-lpss" Added in probe of pwm-lpss-platform.c

Uses the same in i915 -

Hope you pulled all the above patches ?
Comment 15 Shobhit 2016-07-11 08:56:28 UTC
module load order is another problem because of which even with these patches we might not be able to find pwm. Try  "-EPROBE_DEFER attemp for i915" in the attachment, or perhaps make pwm related stuff as in built with kernel and i915 as kernel module to ensure it loads later by udev.
Comment 16 viric 2016-07-11 09:16:22 UTC
Ah! Clear. Maybe I was looking at a tree without the patches and got confused. The patches clearly introduce the "pwm-backlight" for lpss.

Did you see that my kernel log of April shows:

[    2.658013] pwm-byt-plat 80860F09:00: PWM device probed: pwm_num=0, mmio_base=ffffc90001a46000 clk_khz=25000
[    2.658223] pwm-byt-plat 80860F09:01: PWM device probed: pwm_num=1, mmio_base=ffffc90001a48000 clk_khz=25000

and only at 15s i915 reports failure to own?

[   15.203281] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip: pwm_lpss

Doesn't this mean that the order is already correct?

(I will try the patches here provided though)
Comment 17 Shobhit 2016-07-11 10:16:50 UTC
Sorry, I think I missed them. BTW I found two logs in the mail - panic-mtd.txt and lpss-pwm-patches-dmesg.txt

The first set of log you gave -
[    2.658013] pwm-byt-plat 80860F09:00: PWM device probed: pwm_num=0, mmio_base=ffffc90001a46000 clk_khz=25000
[    2.658223] pwm-byt-plat 80860F09:01: PWM device probed: pwm_num=1, mmio_base=ffffc90001a48000 clk_khz=25000

are seen in panic-mtd.txt and which is based on 3.10 kernel version as per the logs.

Following one is seen in the other file which shows version as 4.5

[   15.203281] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip: pwm_lpss

So I am totally confused in the relationship of the logs. Look like they are from two different kernel boot instance of two different kernel version.

Please provide me logs with latest run that you are planning to test now. put some prints in platform driver probe for LPSS pwm so that we can confirm that it found ACPI ID match or not. Also provide acpi table dump using acpidump.
Comment 18 viric 2016-07-11 10:39:31 UTC
Ah it's me that confused both logs today; sorry.

I will prepare what you request. Thank you!
Comment 19 viric 2016-07-11 10:46:37 UTC
The ACPI match worked, because definitely I have pwm in /sys:

But I will add printk, otherwise we don't see the order.
Comment 20 viric 2016-07-11 20:07:25 UTC
Created attachment 125013 [details]
lpss traces verifying it is added

I added some printk in pwm-lpss.c (pwm_lpss_probe()) and I can see it added quite before i915 tries to 'own' it.
Comment 21 viric 2016-07-11 21:11:56 UTC
hmmm I think that pwm_get() fails because the chip does not have the name "pwm-lpss" (.provider in pwm-lpss-platform PWM_LOOKUP entry), but instead has the name "80860F09:00" or "80860F09:01", depending on what pwm should handle the backlight.

I will try to build it with name "80860F09:00" and see.

I don't have acpidump at hand and I failed to find its sources in a quick search. I will search more.
Comment 22 viric 2016-07-11 23:29:51 UTC
Created attachment 125015 [details]
Fix the device name of pwm-lpss so the pwm lookup table is correct

Right, changing the device name, I got light in my screen and text showed up. I attach the patch.

Nevertheless, when the fb0 gets enabled, my screen goes black. With backlight, but black. This is what I get in dmesg:

[   23.524933] Console: switching to colour frame buffer device 100x80
[   23.535952] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[   23.622751] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 0 doesn't have DAPM widget!!!
[   23.622908] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 1 doesn't have DAPM widget!!!
[   23.623053] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 2 doesn't have DAPM widget!!!
[   23.623201] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 3 doesn't have DAPM widget!!!
[   23.623341] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_0 doesn't have DAPM widget!!!
[   23.623743] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_1 doesn't have DAPM widget!!!
[   23.623897] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_0 doesn't have DAPM widget!!!
[   23.624051] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_1 doesn't have DAPM widget!!!
Comment 23 viric 2016-07-11 23:35:05 UTC
Sorry, previous lines were about soundcard. The only I can see graphics related is:

[   21.030274] fb: switching to inteldrmfb from EFI VGA
[   21.030391] Console: switching to colour dummy device 80x25
[   21.030514] [drm] Replacing VGA console driver
[   21.030878] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   21.030883] [drm] Driver supports precise vblank timestamp query.
[   21.096406] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   21.176696] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   21.177392] [drm] Initialized i915 1.6.0 20151218 for 0000:00:02.0 on minor 0
[   21.510911] fbcon: inteldrmfb (fb0) is primary device
[   23.524933] Console: switching to colour frame buffer device 100x80
[   23.535952] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

These 20 seconds is more or less when it goes black.
Comment 24 Shobhit 2016-07-12 06:02:27 UTC
Thanks for correcting the provider name. I made a mistake there.

And I don't see the failed to get_pwm ERROR log so assuming everything just loaded fine. Can you please provide debug log with drm.debug=0xe kernel parameter ?
Comment 25 viric 2016-07-12 08:01:16 UTC
Created attachment 125017 [details]
kernel log with drm.debug=0xe

I attach the kernel log requested, with drm.debug=0xe. I see most of even systemd log fine, but it goes black a bit before the login prompt.

(Before the pwm fix, I could never see a single line of kernel text on screen and it was completely dark, no backlight).
Comment 26 Shobhit 2016-07-12 09:07:44 UTC
All generally looks good in DSI enabling sequence. And seems back light is also working from your description.

Perhaps there is something going wrong when UI starts. Would need more debug if you can you boot in console mode kernel param: "text". And if you are able to get console, then run intel-gpu-tools and use test_display utility to test the display. It should show you sample image for 800x1200 resolution on DSI if it works.

Also share the /var/log/Xorg.0.log in normal boot scenario in case your console is working fine and test_display is successful.

At the same time if you have console, you can also check if backlight control is working by simply

echo <0-100> > /sys/class/backlight/intel_backlight

Does display comes up fine in BIOS mode (if you can go into that mode) on your device ?
Comment 27 viric 2016-07-12 10:06:59 UTC
Backlight works perfect; I can change the values and the effective change of backlight is noticeable.

But I have all pixels in black, after some point of the boot, with some kind of 'flash'; as if font were set or so. X.org is not there, so I should just get agetty.

Maybe it is 'systemd-vconsole-setup' that changes something? I can't tell. I have ssh access and the journal to check, but I can't see anything relevant there.
Comment 28 viric 2016-07-12 10:32:13 UTC
I blacklisted the 'i915' module on boot, and the screen does not go black anymore. Then, from the root shell I type "modprobe i915" and it goes black.

The kernel log says, since the modprobe:

[   72.226417] Linux agpgart interface v0.103
[   72.265453] [drm] Initialized drm 1.1.0 20060810
[   72.384656] [drm] Memory usable by graphics device = 2048M
[   72.384666] checking generic (80000000 1d5000) vs hw (80000000 10000000)
[   72.384669] fb: switching to inteldrmfb from EFI VGA
[   72.384773] Console: switching to colour dummy device 80x25
[   72.384904] [drm] Replacing VGA console driver
[   72.385680] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   72.385686] [drm] Driver supports precise vblank timestamp query.
[   72.407090] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   72.465860] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   72.466436] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
[   72.466663] [drm] Initialized i915 1.6.0 20160229 for 0000:00:02.0 on minor 0
[   72.508911] audit: type=1130 audit(1468319461.361:75): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-backlight@backlight:intel_backlight comm="systemd" exe="/nix/store/24qss832pv2xwpjbzk354kimypf4f1jc-systemd-230/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   72.695713] fbcon: inteldrmfb (fb0) is primary device
[   74.649688] Console: switching to colour frame buffer device 100x80
[   74.660835] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Comment 29 viric 2016-07-12 17:06:23 UTC
I don't know what else I can provide to solve this black-screen problem. I have debugfs, if this helps.

The driver is using the DSI output, which may require some specific code for the "panel". Something like this:

Comment 30 Shobhit 2016-07-12 17:17:50 UTC
So I believe with the patches to enable LPSS PWM, the backlight is working now which was the main issue in this bug ? Now this has become a different problem with display itself not coming up on surface 3. 

The display driver has generic support to enable any DSI panel. So there should not be any specific code needed. The VBT has panel dependent information which driver will use to enable it. Can you attach the VBT dump.
Comment 31 Shobhit 2016-07-12 17:20:34 UTC
The ordering problem probably is not yet solved, LPSS PWM works. Can you try the DEFER probe patch to see if load order is fine when we have i915 as in kernel with PWM drivers as module. I am sure that patch would not be so trivial as I have given but it would be good to know the errors.
Comment 32 viric 2016-07-12 17:27:33 UTC
Created attachment 125034 [details]
dump of i915_vbt

I attach i915_vbt. I can open a new bug for this problem, if you want.

In my tests, I had the pwm parts in kernel, and i915 as module, so I got always the right order. I will see if I can test the patch here provided, but it is not that I have a cheap way of testing a new kernel in the device - it takes 1h30m of cpu.
Comment 33 viric 2016-07-12 17:37:07 UTC
As an additional comment, I do not have a "Surface 3" device. I have a "Woxter Zen 10". I wrote in this bug because I thought it was a similar enough case.
Comment 34 viric 2016-07-12 17:51:30 UTC
The AMI BIOS of this computer has a section that says "MIPI PANEL" and has selected "Innolux 8x12". It should be a 10.1" display, I guess it is this one:

Comment 35 Shobhit 2016-07-13 06:36:20 UTC
Thanks Viric, for your testing. I think display not coming up on your device is a different issues and should be tracked differently. This one is more for load order problem which though was started for Surface 3 (guess its based on pwm-crc) but should hold true for pwm-lpss as well. So that we can discuss here for probably both crystalcove and lpss based pwm,

@Stephen: Did you get a change to test the patch "-EPROBE_DEFER attemp for i915" on your device ?
Comment 36 viric 2016-07-13 21:45:07 UTC
I opened the bug 96923 for the black screen (with backlight) problem.
Comment 37 Stephen Just 2016-07-15 01:43:08 UTC
(In reply to Shobhit from comment #35)
> @Stephen: Did you get a change to test the patch "-EPROBE_DEFER attemp for
> i915" on your device ?

I haven't had the time to try to apply this against recent kernels. However, I'm not expecting it to work - the failure on Surface 3 is in intel_panel.c:pwm_setup_backlight(), and I do not see the "Failed to own gpio for panel control" error.
Comment 38 viric 2016-07-15 07:15:45 UTC
Hello Stephen,

why doesn't your message include *what* pwm chip is it looked for? I was getting:

[   15.203281] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip: pwm_lpss

What is your exact kernel version and what patches have you applied? The patches from Shobhit explicitly add the name of the pwm in the trace.
Comment 39 viric 2016-07-15 07:25:32 UTC
Ah sorry, now I notice that your device is completely unrelated to LPSS and you were interested exclusively in the probe delay. I understand that you could reproduce both situations: good load in proper order, and bad load in bad order.

I think I quite vampirized your bug report towards LPSS with Shobhit, and it became quite confusing. Sorry. I had writen about LPSS in other bugs, but Shobhit happened to answer only here, so I also went on.
Comment 40 Shobhit 2016-07-15 09:09:11 UTC
Stephen, you are right. At the time I prepared the patch it handled only gpio load error path. I have updated the patch to handle panel_setup_backlight failures as well to return -EPROBE_DEFER

Maybe this will be more useful - 
Comment 41 Jani Nikula 2016-08-02 10:58:34 UTC
*** Bug 97178 has been marked as a duplicate of this bug. ***
Comment 42 russianneuromancer 2016-11-13 03:03:29 UTC
Recently I discover two patch sets for fixing backlight on Toshiba Click Mini and  Nextbook Flexx 10.1.

Toshiba Click Mini patches, compiled kernel and detailed explanation about DSDT: https://www.tinc-vpn.org/pipermail/click/2016-October/000347.html

Nextbook Flexx 10.1 patches that seems like doesn't require DSDT modification: https://github.com/burzumishi/linux-baytrail-flexx10/tree/master/kernel/patches/v4.8

Try it, maybe this will work for your hardware.
Comment 43 Oleg K 2016-11-13 16:36:38 UTC
Acer One 10 (S1002), Kali Linux Live 2016.2
Don't work Backlight
Comment 44 russianneuromancer 2017-02-27 15:05:41 UTC
Hi, Jani

Any progress on getting this into upstream?
Comment 45 Jani Nikula 2017-03-14 14:16:49 UTC
(In reply to russianneuromancer from comment #44)
> Hi, Jani
> Any progress on getting this into upstream?
> https://lists.freedesktop.org/archives/intel-gfx/2017-January/117353.html

Not really.
Comment 46 Jani Nikula 2017-03-27 19:01:24 UTC
*** Bug 100383 has been marked as a duplicate of this bug. ***
Comment 47 sassmann 2017-06-26 14:36:45 UTC
I found a workaround that helps to delay the loading of i915.

Removing i915 from the initramfs causes it to be loaded later in the boot process. On my baytrail tablet this is sufficient to avoid the "*ERROR* Failed to own the pwm chip" problem.

For dracut based distributions you can do
# dracut -f --omit-drivers="i915"
to rebuild the initramfs without i915.
Comment 48 Elizabeth 2017-07-04 19:55:23 UTC
*** Bug 101093 has been marked as a duplicate of this bug. ***
Comment 49 Elizabeth 2017-10-20 20:57:28 UTC
Decreasing priority since they are workarounds and no really advance to get this fixed upstream.
Comment 50 Jani Saarinen 2018-03-29 07:10:13 UTC
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.
Comment 51 Denis 2018-04-12 13:15:51 UTC
Bug is still valid, Toshiba Satellite Click 10 (LX0W-C64)
Comment 52 Houston 2018-04-17 09:32:25 UTC
The bug seems to be still present in 4.16 (tested on Asus T100HA).

Also, there's workaround for non-modular kernels with statically compiled modules, known workarounds are based on delayed loading of i915, which cannot be used in case of non-modular kernel. Embedded systems using non-modular kernels are therefore quite screwed on affected hardware (the only way to support new HW is to temporarily enable kernel module loading and add kmod to userspace until this issue is fixed). So please also consider increasing priority of this issue or introducing a workaround for non-modular kernels.
Comment 53 Steve Dodd 2018-04-20 17:51:43 UTC
Just to add to the confusion here, I am still seeing what looks like the ordering problem, even though LPSS PWM driver is built-in (this is on Asus T100HA):

steved@asus:~$ journalctl -b -1 | grep -i pwm
Apr 20 18:31:16 asus kernel:  (null): Device [PWM1] is in always present list
Apr 20 18:31:43 asus kernel: [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip

steved@asus:~$ uname -a
Linux asus #14 SMP Thu Apr 19 00:11:41 MST 2018 x86_64 x86_64 x86_64 GNU/Linux

steved@asus:~$ grep LPSS /boot/config- | grep -v MFD

Have I misunderstood something?
Comment 54 Houston 2018-04-21 08:31:46 UTC
Created attachment 138976 [details]
Kernel config for 4.16.3 which works on Asus T100HA with delayed loading of i915

Attaching config which works on Asus T100HA (everything except CONFIG_DRM_I915 and CONFIG_HDMI_LPE_AUDIO is built in, the modules go to /lib/modules, not to initramfs)
Comment 55 deuti 2018-07-14 18:29:34 UTC
Just to bump this up:

Asus T102HA Ubuntu 18.04 bug is still present.

journalctl -b -1 | grep -i pwm
Jul 14 17:57:11 MateTablet kernel:  (null): Device [PWM1] is in always present list
Jul 14 17:57:11 MateTablet kernel: [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
uname -a
Linux MateTablet 4.17.5-041705-generic #201807081431 SMP Sun Jul 8 14:33:41 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Comment 56 russianneuromancer 2018-07-27 08:28:33 UTC
I tested Linux 4.18rc6 and find that, as before, backlight adjustment does not work unless kernel is built with three following options:


Jani, if possible, could you please look into this issue again?
Comment 57 russianneuromancer 2018-07-27 08:31:09 UTC
Forgot to mention, test was performed on HP Stream 7 Tablet.
Comment 58 russianneuromancer 2018-07-27 08:38:07 UTC
Also reported downstream: https://bugs.launchpad.net/bugs/1783964
Comment 59 Houston 2019-05-04 12:59:08 UTC
Retested with 5.0.12, bug is still present, backlight control fails & excessive power consumption and/or battery damage caused by excessive wear occurs with statically linked kernel on cherrytrail-based HW.

The workaround based on enabling loadable module support, crippling userspace and system architecture to support module loading (which is unfortunately not allowed in some cases) and delayed loading of i915 still works, but better workaround seems to be to replace any low-power Atom based systems with ARM-based competition these days.

Please consider moving affected drivers to Staging area of kernel sources. Such step could attract some support & help, which is obviously needed here.
Comment 60 Houston 2019-05-04 13:40:07 UTC
Forgot to mention that hdmi-lpe-audio might have joined this dependency hell somewhere in 4.19.x, it started to throw previously unseen boot errors. Disabling CONFIG_HDMI_LPE_AUDIO seems to be a "workaround" here.

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.