summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/display
diff options
context:
space:
mode:
authorDouglas Anderson <dianders@chromium.org>2024-03-26 00:56:27 +0300
committerDouglas Anderson <dianders@chromium.org>2024-04-08 07:47:16 +0300
commitb48ccb18e642c96473325bc0e16977dc7cb81f48 (patch)
tree74c44a418dc9f9dc3255f746b2c7ebc295786db5 /Documentation/devicetree/bindings/display
parentce0ff22388abf87599300283398ddcbd883a7935 (diff)
downloadlinux-b48ccb18e642c96473325bc0e16977dc7cb81f48.tar.xz
drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probe
If we're using the AUX channel for eDP backlight and it fails to probe for some reason, let's _not_ fail the panel probe. At least one case where we could fail to init the backlight is because of a dead or physically missing panel. As talked about in detail in the earlier patch in this series, ("drm/panel-edp: If we fail to powerup/get EDID, use conservative timings"), this can cause the entire system's display pipeline to fail to come up and that's non-ideal. If we fail to init the backlight for some transitory reason, we should dig in and see if there's a way to fix this (perhaps retries?). Even in that case, though, having a panel whose backlight is stuck at 100% (the default, at least in the panel Samsung ATNA33XC20 I tested) is better than having no panel at all. Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.3.I552e8af0ddb1691cc0fe5d27ea3d8020e36f7006@changeid
Diffstat (limited to 'Documentation/devicetree/bindings/display')
0 files changed, 0 insertions, 0 deletions