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. 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! -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
signature.asc
Description: This is a digitally signed message part
