While working on integrating backlight functionality with the DRM sub- system, I came across an oddity of sorts. The backlight subsystem seems to have an implicit policy of enabling the backlight device when it's registered. Pretty much every driver seems to do something like this in .probe(): bl->props.brightness = default_brightness; bl->props.fb_blank = FB_BLANK_UNBLANK; backlight_update_status(bl); There are variations of this theme, but the tendency is certainly to enable the backlight once it has been registered. Some don't even set the .fb_blank field, so it will usually stay initialized to zero, which happens to be FB_BLANK_UNBLANK, so the result will be the same. I understand that this is actually useful when using something such as fbdev where the backlight isn't necessarily bound to a display device, but when used in conjunction with a higher-level API such as DRM, then this default behaviour becomes somewhat annoying. The problem is that backlight devices are usually instantiated separately from the display driver, so with the current default the backlight will be enabled at some random point in time during boot. However, DRM for example provides for a display to control very precisely when the backlight should be enabled, which in turn makes it easy to light it up right after the display has initialized. If the backlight is turned on right after it has been probed this could mean that the display hasn't been initialized yet and therefore there's no meaningful content yet, and worse, the display might show garbage during initialization of the display controller. So I wonder if perhaps a better default would be to not enable the backlight on boot. If so, this will actually cause a regression of some sort on non-DRM systems because suddenly the backlight is no longer enabled by default on boot. Does anyone have any comments or ideas? My first reaction was to add a property to the DT so that the driver could skip enabling the backlight, but I don't think that will be accepted because it encodes software policy in DT rather than purely a description of hardware. Thierry
Attachment:
pgpRG1ZQ5LSY8.pgp
Description: PGP signature
