Bug 96571

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.

Understood.

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.

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

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.

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.

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 90075 is very well related to this (I also wrote this text therE). Isn't it?

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.

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.

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.

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.

https://patchwork.freedesktop.org/patch/70286/
https://patchwork.freedesktop.org/patch/70287/
https://patchwork.freedesktop.org/patch/70288/

I guess that the pwm driver patches are OK, as they were in this my LPSS:

http://www.spinics.net/lists/intel-gfx/msg92110.html

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.

http://lxr.free-electrons.com/source/drivers/video/backlight/pwm_bl.c#L195

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

This is the i915 code that tries to find the pwm-backlight controller:

http://lxr.free-electrons.com/source/drivers/gpu/drm/i915/intel_panel.c#L1636

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.

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 -
CONFIG_PWM_LPSS=y
CONFIG_PWM_LPSS_PLATFORM=y

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.

I already tested that in April and reported about it. Is there anything new that I should test?

http://www.spinics.net/lists/intel-gfx/msg91730.html

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

http://www.spinics.net/lists/intel-gfx/msg92110.html

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:

http://lxr.free-electrons.com/source/drivers/mfd/intel_soc_pmic_core.c#L43

Is there anything that can map LPSS pwm to "pwm-backlight"? That's the piece I could not find anywhere.

Check the patches -
General re factoring in i915
https://patchwork.freedesktop.org/patch/70286/

Add pwm lookup table. Device is called - "pwm-lpss" Added in probe of pwm-lpss-platform.c
https://patchwork.freedesktop.org/patch/70287/

Uses the same in i915 -
https://patchwork.freedesktop.org/patch/70288/

Hope you pulled all the above patches ?

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.

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)

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.

Ah it's me that confused both logs today; sorry.

I will prepare what you request. Thank you!

The ACPI match worked, because definitely I have pwm in /sys:
http://www.spinics.net/lists/intel-gfx/msg92110.html

But I will add printk, otherwise we don't see the order.

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.

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.

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

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.

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 ?

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

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 ?

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.

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

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:

https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/blob/master/linux/kernel/drivers/gpu/drm/i915/intel_dsi.c#L38-L69

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.
/sys/kernel/debug/dri/0/i915_vbt

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.

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.

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.

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:

http://www.innolux.com/Pages/Dyn/Product3_EN.aspx?cateN=Tablet%20Hybrid%20Solution&catedes=Tablet/Hybrid%20Solution&catel1=Tablet&catel2=WXGA&size=10.1"&Language=EN

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 ?

I opened the bug 96923 for the black screen (with backlight) problem.

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

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.

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.

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 - 
https://patchwork.kernel.org/patch/9231361/

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

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.

Acer One 10 (S1002), Kali Linux Live 2016.2
Don't work Backlight

Hi, Jani

Any progress on getting this into upstream?
https://lists.freedesktop.org/archives/intel-gfx/2017-January/117353.html

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

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

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.

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

Decreasing priority since they are workarounds and no really advance to get this fixed upstream.

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.

Bug is still valid, Toshiba Satellite Click 10 (LX0W-C64)

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.

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 4.16.3.0 #14 SMP Thu Apr 19 00:11:41 MST 2018 x86_64 x86_64 x86_64 GNU/Linux

steved@asus:~$ grep LPSS /boot/config-4.16.3.0 | grep -v MFD
CONFIG_X86_INTEL_LPSS=y
CONFIG_SERIAL_8250_LPSS=y
CONFIG_PWM_LPSS=y
CONFIG_PWM_LPSS_PCI=y
CONFIG_PWM_LPSS_PLATFORM=y

Have I misunderstood something?

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)

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

I tested Linux 4.18rc6 and find that, as before, backlight adjustment does not work unless kernel is built with three following options:

CONFIG_PWM_LPSS=y
CONFIG_PWM_LPSS_PCI=y
CONFIG_PWM_LPSS_PLATFORM=y

Jani, if possible, could you please look into this issue again?

Forgot to mention, test was performed on HP Stream 7 Tablet.

Also reported downstream: https://bugs.launchpad.net/bugs/1783964

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.

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.

CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DESIGNWARE_SLAVE=y
CONFIG_I2C_DESIGNWARE_PCI=y
CONFIG_I2C_DESIGNWARE_BAYTRAIL=y
CONFIG_PWM=y
CONFIG_PWM_SYSFS=y
CONFIG_PWM_CRC=y
CONFIG_PWM_LPSS=y
CONFIG_PWM_LPSS_PCI=y
CONFIG_PWM_LPSS_PLATFORM=y

 [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
I see this problem happen again with Linux 5.3rc1 kernel on my BayTrail z3735f device! can't adjust brightness.

Linux 5.3, what reason?

Linux 5.2,bdi 7:4: hash matches

[    1.957833] i2c_designware 80860F41:04: I2C bus managed by PUNIT
[    1.970286] mmcblk2: mmc2:59b4 NCard 29.5 GiB 
[    1.983065]  mmcblk2: p1 p2 p3 p4
[    1.984464] PM:   Magic number: 7:374:39
[    1.989857] bdi 7:4: hash matches
[   10.903210] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   10.903222] [drm] Driver supports precise vblank timestamp query.
[   10.904576] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   10.928967] [drm] Initialized i915 1.6.0 20190417 for 0000:00:02.0 on minor 0

Linux 5.3,pwm pwmchip0: hash matches

[    1.944169] i2c_designware 80860F41:04: I2C bus managed by PUNIT
[    1.961837] PM:   Magic number: 11:414:692
[    1.965361] pwm pwmchip0: hash matches
[   11.268783] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.268836] [drm] Driver supports precise vblank timestamp query.
[   11.270231] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   11.270769] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
[   11.287482] [drm] Initialized i915 1.6.0 20190619 for 0000:00:02.0 on minor 0

Hi All,

I was not aware that this bug existed, @youling257 pointed me here.

Note that the generic issue from this bug, when using a generic kernel with most drivers as modules, has been fixed long ago (January 2017)

I wrote a patch which makes the pwm-core load the module when the pwm device is being looked-up by the i915 driver:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b526a314263ea217b8fa9758dca5dc245fd49997

This does require that at least the i915 driver is a module, so that it is no initialized before request_module is possible. This allows the pwm driver itself to also be a module. Note that if the pwm driver is a module and the i915 driver is loaded by the initrd; then the pwm-driver and all of its dependencies must also be in the initrd. I've patches dracut to get this right a long time ago, I do not know about other initrd generating tools.

As for having i915 / everything builtin that simply is not possible with the current state of things. IIRC having i915 builtin has other issues too (at least with Fedora we hit other issues when building in the drm/kms drivers).

So IMHO this bug can be closed now, as the original issue is solved as long as the i195 driver is a module and building it in is simply not a supportable case on this hardware.

Regards,

Hans

(In reply to youling257 from comment #61)
>  [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
> I see this problem happen again with Linux 5.3rc1 kernel on my BayTrail
> z3735f device! can't adjust brightness.
> 
> Linux 5.3, what reason?

I've just installed 5.3 on a CHT device with LPSS PWM driving the backlight and I'm seeing the same thing. This seems to be a 5.3 regression which is a separate issue from the original issue of this bug.

I'll investigate the 5.3 regression further and write a patch fixing it.

Created attachment 144914 [details] [review]
[PATCH] pwm: Fallback to the static lookup-list when acpi_pwm_get fails

Here is a patch fixing the lookup error in 5.3-rc#

(In reply to Hans de Goede from comment #65)
> Here is a patch fixing the lookup error in 5.3-rc#

p.s. I've submitted this upstream, so hopefully it will show up in a newer 5.3 rc release soon.

(In reply to youling257 from comment #61)
> CONFIG_I2C_DESIGNWARE_CORE=y
> CONFIG_I2C_DESIGNWARE_PLATFORM=y
> CONFIG_I2C_DESIGNWARE_SLAVE=y
> CONFIG_I2C_DESIGNWARE_PCI=y
> CONFIG_I2C_DESIGNWARE_BAYTRAIL=y
> CONFIG_PWM=y
> CONFIG_PWM_SYSFS=y
> CONFIG_PWM_CRC=y
> CONFIG_PWM_LPSS=y
> CONFIG_PWM_LPSS_PCI=y
> CONFIG_PWM_LPSS_PLATFORM=y
> 
>  [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip
> I see this problem happen again with Linux 5.3rc1 kernel on my BayTrail
> z3735f device! can't adjust brightness.
> 
> Linux 5.3, what reason?

So it looks like this comment hijacked the bug about something completely different, and now we have a patch en route upstream claiming it fixes this bug, while in truth the original LPSS issues is not fixed. :(

There's bug 111293 about the regression on v5.3-rc1, bisected commit being 4a6ef8e37c4d ("pwm: Add support referencing PWMs from ACPI") and the fix apparently being https://kernel.googlesource.com/pub/scm/linux/kernel/git/thierry.reding/linux-pwm/+/6cf9481b440da6d6d86bd8e4c99a8b553b9d1271

Jani,

In hindsight I should have put the link to this bugzilla in that patch as:

Related: https://bugs.freedesktop.org/show_bug.cgi?id=96571

And not as:

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96571

Sorry.

As for this bug, as I tried to explain in comment 63, this has been (mostly) fixed for close to 2 years now, at least for configs which build the i915 driver as a module, as almost all generic distro kernels do. So with my Fedora distro contributor had on I consider this bug fixed.

If you want to keep it open to track the i915 builtin case, I suggest changing the summary too:

BYT/CHT: pwm vs i915 driver initialization order when i915 is builtin

To reflect that:
1) This is a generic BYT/CHT issue, not Surface 3 specific
2) This only is a problem when the i915 driver is builtin

You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/26.