Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1681436
| From | Daniel Thompson <daniel.thompson@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support |
| Date | 2017-07-05 12:30 +0200 |
| Message-ID | <tZPJh-4ZW-13@gated-at.bofh.it> (permalink) |
| References | <tZCsF-4Pa-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 04/07/17 21:13, Paul Kocialkowski wrote: > As I try to maintain support for ARM CrOS (read, ChromeOS/ChromiumOS) devices in > upstream Linux on my spare time, I try to test out rc and stable versions as > often as time allows. I have been rolling out 4.12 since Monday and noticed that > the backlight on my tegra124 nyan big stayed dark for this release. > > Not very cool, although I'm not blaming anyone else than myself on this, > I should have just tested it and brought the issue up during the rc cycle. > Still, let's try to move forward. Personally I might be inclined to spread the blame a bit wider ;-). Did you bisect it down to a specific patch? An SHA-1 would be something of a time saver here! Daniel. > > After investigating, it appears that the pwm_bl driver is enforcing a policy on > heavily relying on the backlight initial state > (pwm_backlight_initial_power_state). To make it short, if backlight wasn't > detected as already enabled by the bootloader, it's going to refuse to enable it > during the whole lifetime of the driver. > > This policy isn't exactly new (so I do realize that I'm a bit late to the > party), but it went one step further this cycle by adding a check on the PWM > state. This broke support for my nyan big, as the pwm driver does not check for > the previous state at probe time and reports it as disabled initially. > > One could say that the driver has to be fixed to report that state (and I agree > it is a desirable thing to do), but I think it is a symptom of a broader issue. > > Basically, do we really want pwm_bl to behave this way? What is the rationale > behind this decision, other than "because we can"? A strong argument against it > is that not all bootloaders have support for turning the backlight on (that is > definitely not the case on the omap3 sniper and omap4 kc1 boards with upstream > U-Boot, that I introduced to mainline Linux). > > Also, we can still expect the gpio/regulator/pwm drivers to be reset at probe > time (and I also agree it's not necessarily a good thing, especially as far as > backlight is concerned, but that's the reality and dropping backlight support in > those cases doesn't seem like an appropriate course of action). This will result > in pwm_bl assuming that backlight was not enabled by the bootloader and thus > refuse to enable it at all times. > > Comments and reactions are welcome, as I'd really like to find a sane way to > resolve this problem. > > Cheers! >
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Paul Kocialkowski <contact@paulk.fr> - 2017-07-04 22:20 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Daniel Thompson <daniel.thompson@linaro.org> - 2017-07-05 12:30 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Paul Kocialkowski <contact@paulk.fr> - 2017-07-05 12:50 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Philipp Zabel <p.zabel@pengutronix.de> - 2017-07-05 13:10 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Paul Kocialkowski <contact@paulk.fr> - 2017-07-05 13:50 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Paul Kocialkowski <contact@paulk.fr> - 2017-07-06 14:50 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Daniel Thompson <daniel.thompson@linaro.org> - 2017-07-06 15:10 +0200
Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Paul Kocialkowski <contact@paulk.fr> - 2017-07-06 15:10 +0200
csiph-web