dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[PATCH v3 0/9] drm, kernel: update locking for DRM
by Desmond Cheong Zhi Xi 19 Aug '21

19 Aug '21

Hi, The patches in this series are largely fixes and prepwork leading up to the final patch which plugs races with modesetting rights. Most of the fixes don't have bug reports, so comments would be very appreciated. The biggest change from the previous version is that we convert drm_device.master_mutex into master_rwsem, instead of introducing master_rwsem as a third lock. Overall, this series makes the following changes: - Patch 1: Move master_lookup_lock into struct drm_device (enables us to use it to protect attributes accessed by different drm_files) - Patch 2: Add a missing master_lookup_lock in drm_master_release - Patch 3: Fix a potential race in drm_is_current_master_locked - Patch 4: Fix potential null ptr dereferences in drm_{auth, ioctl} - Patch 5: Move magic_map,unique{_len} out from master_mutex's protection into master_lookup_lock's protection (allows us to avoid read_lock -> write_lock deadlocks) - Patch 6: Convert master_mutex into rwsem (avoids creating a new lock) - Patch 7: Update global mutex locking in the ioctl handler (avoids deadlock when grabbing read lock on master_rwsem in drm_ioctl_kernel) - Patch 8: Export task_work_add (enables us to write drm_master_flush) - Patch 9: Plug races with drm modesetting rights v2 -> v3: - Unexport drm_master_flush, as suggested by Daniel Vetter. - Merge master_mutex and master_rwsem, as suggested by Daniel Vetter. - Export task_work_add, reported by kernel test robot. - Make master_flush static, reported by kernel test robot. - Move master_lookup_lock into struct drm_device. - Add a missing lock on master_lookup_lock in drm_master_release. - Fix a potential race in drm_is_current_master_locked. - Fix potential null ptr dereferences in drm_{auth, ioctl}. - Protect magic_map,unique{_len} with master_lookup_lock. - Convert master_mutex into a rwsem. - Update global mutex locking in the ioctl handler. v1 -> v2 (suggested by Daniel Vetter): - Address an additional race when drm_open runs. - Switch from SRCU to rwsem to synchronise readers and writers. - Implement drm_master_flush with task_work so that flushes can be queued to run before returning to userspace without creating a new DRM_MASTER_FLUSH ioctl flag. Best wishes, Desmond Desmond Cheong Zhi Xi (9): drm: move master_lookup_lock into drm_device drm: hold master_lookup_lock when releasing a drm_file's master drm: check for null master in drm_is_current_master_locked drm: fix potential null ptr dereferences in drm_{auth,ioctl} drm: protect magic_map,unique{_len} with master_lookup_lock drm: convert drm_device.master_mutex into a rwsem drm: update global mutex lock in the ioctl handler kernel: export task_work_add drm: avoid races with modesetting rights drivers/gpu/drm/drm_auth.c | 108 ++++++++++++++++++++++++--------- drivers/gpu/drm/drm_debugfs.c | 4 +- drivers/gpu/drm/drm_drv.c | 4 +- drivers/gpu/drm/drm_file.c | 1 - drivers/gpu/drm/drm_internal.h | 1 + drivers/gpu/drm/drm_ioctl.c | 39 +++++++----- drivers/gpu/drm/drm_lease.c | 1 + include/drm/drm_auth.h | 6 +- include/drm/drm_device.h | 27 +++++++-- include/drm/drm_file.h | 20 +++--- kernel/task_work.c | 1 + 11 files changed, 145 insertions(+), 67 deletions(-) -- 2.25.1

2 21

[PATCH] This is only used for testing upstream progress
by xuxinxiong 19 Aug '21

19 Aug '21

We want to test the upstream progress. Signed-off-by: xuxinxiong <xuxinxiong(a)huaqin.corp-partner.google.com> --- drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c index dc49079a74d1..ce7437d1b682 100644 --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c @@ -4,6 +4,8 @@ * Author: Jitao Shi <jitao.shi(a)mediatek.com> */ +/* This is used for test upstream progress */ + #include <linux/delay.h> #include <linux/gpio/consumer.h> #include <linux/module.h> -- 2.25.1

1 0

[PATCH] This is only used for testing upstream progress
by xuxinxiong 19 Aug '21

19 Aug '21

1 0

[PATCH] no review: test for uploading patch
by yangcong 19 Aug '21

19 Aug '21

no review: test for uploading patch --- drivers/gpu/drm/panel/panel-simple.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 1b80290c2b53..fa4925e5b1bf 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -42,6 +42,10 @@ /** * struct panel_desc - Describes a simple panel. */ + +/** + * test patch for panel. + */ struct panel_desc { /** * @modes: Pointer to array of fixed modes appropriate for this panel. -- 2.25.1

1 0

[PATCH] backlight: pwm_bl: Improve bootloader/kernel device handover
by Daniel Thompson 19 Aug '21

19 Aug '21

Currently there are (at least) two problems in the way pwm_bl starts managing the enable_gpio pin. Both occur when the backlight is initially off and the driver finds the pin not already in output mode and, as a result, unconditionally switches it to output-mode and asserts the signal. Problem 1: This could cause the backlight to flicker since, at this stage in driver initialisation, we have no idea what the PWM and regulator are doing (an unconfigured PWM could easily "rest" at 100% duty cycle). Problem 2: This will cause us not to correctly honour the post_pwm_on_delay (which also risks flickers). Fix this by moving the code to configure the GPIO output mode until after we have examines the handover state. That allows us to initialize enable_gpio to off if the backlight is currently off and on if the backlight is on. Reported-by: Marek Vasut <marex(a)denx.de> Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Cc: stable(a)vger.kernel.org Acked-by: Marek Vasut <marex(a)denx.de> Tested-by: Marek Vasut <marex(a)denx.de> --- drivers/video/backlight/pwm_bl.c | 54 +++++++++++++++++--------------- 1 file changed, 28 insertions(+), 26 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index e48fded3e414..8d8959a70e44 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -409,6 +409,33 @@ static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data) static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb) { struct device_node *node = pb->dev->of_node; + bool active = true; + + /* + * If the enable GPIO is present, observable (either as input + * or output) and off then the backlight is not currently active. + * */ + if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0) + active = false; + + if (!regulator_is_enabled(pb->power_supply)) + active = false; + + if (!pwm_is_enabled(pb->pwm)) + active = false; + + /* + * Synchronize the enable_gpio with the observed state of the + * hardware. + */ + if (pb->enable_gpio) + gpiod_direction_output(pb->enable_gpio, active); + + /* + * Do not change pb->enabled here! pb->enabled essentially + * tells us if we own one of the regulator's use counts and + * right now we do not. + */ /* Not booted with device tree or no phandle link to the node */ if (!node || !node->phandle) @@ -420,20 +447,7 @@ static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb) * assume that another driver will enable the backlight at the * appropriate time. Therefore, if it is disabled, keep it so. */ - - /* if the enable GPIO is disabled, do not enable the backlight */ - if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0) - return FB_BLANK_POWERDOWN; - - /* The regulator is disabled, do not enable the backlight */ - if (!regulator_is_enabled(pb->power_supply)) - return FB_BLANK_POWERDOWN; - - /* The PWM is disabled, keep it like this */ - if (!pwm_is_enabled(pb->pwm)) - return FB_BLANK_POWERDOWN; - - return FB_BLANK_UNBLANK; + return active ? FB_BLANK_UNBLANK: FB_BLANK_POWERDOWN; } static int pwm_backlight_probe(struct platform_device *pdev) @@ -486,18 +500,6 @@ static int pwm_backlight_probe(struct platform_device *pdev) goto err_alloc; } - /* - * If the GPIO is not known to be already configured as output, that - * is, if gpiod_get_direction returns either 1 or -EINVAL, change the - * direction to output and set the GPIO as active. - * Do not force the GPIO to active when it was already output as it - * could cause backlight flickering or we would enable the backlight too - * early. Leave the decision of the initial backlight state for later. - */ - if (pb->enable_gpio && - gpiod_get_direction(pb->enable_gpio) != 0) - gpiod_direction_output(pb->enable_gpio, 1); - pb->power_supply = devm_regulator_get(&pdev->dev, "power"); if (IS_ERR(pb->power_supply)) { ret = PTR_ERR(pb->power_supply); base-commit: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c -- 2.30.2

2 3

[PATCH v7 00/10] drm/vc4: hdmi: Support the 4k @ 60Hz modes
by Maxime Ripard 19 Aug '21

19 Aug '21

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. Let me know what you think, Maxime --- Changes from v6: - Rebased on current drm-misc-next - Removed stale clk_request pointer Changes from v5: - Fixed unused variables warning Changes from v4: - Removed the patches already applied - Added various fixes for the issues that have been discovered on the downstream tree Changes from v3: - Rework the encoder retrieval code that was broken on the RPi3 and older - Fix a scrambling enabling issue on some display Changes from v2: - Gathered the various tags - Added Cc stable when relevant - Split out the check to test whether the scrambler is required into an helper - Fixed a bug where the scrambler state wouldn't be tracked properly if it was enabled at boot Changes from v1: - Dropped the range accessors - Drop the mention of force_turbo - Reordered the SCRAMBLER_CTL register to match the offset - Removed duplicate HDMI_14_MAX_TMDS_CLK define - Warn about enable_hdmi_4kp60 only if there's some modes that can't be reached - Rework the BVB clock computation Maxime Ripard (10): drm/vc4: hdmi: Remove the DDC probing for status detection drm/vc4: hdmi: Fix HPD GPIO detection drm/vc4: Make vc4_crtc_get_encoder public drm/vc4: crtc: Add encoder to vc4_crtc_config_pv prototype drm/vc4: crtc: Rework the encoder retrieval code (again) drm/vc4: crtc: Add some logging drm/vc4: Leverage the load tracker on the BCM2711 drm/vc4: hdmi: Raise the maximum clock rate drm/vc4: hdmi: Enable the scrambler on reconnection drm/vc4: Increase the core clock based on HVS load drivers/gpu/drm/vc4/vc4_crtc.c | 60 ++++++++------ drivers/gpu/drm/vc4/vc4_debugfs.c | 7 +- drivers/gpu/drm/vc4/vc4_drv.h | 8 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 20 +++-- drivers/gpu/drm/vc4/vc4_kms.c | 126 +++++++++++++++++++++++++----- drivers/gpu/drm/vc4/vc4_plane.c | 5 -- 6 files changed, 163 insertions(+), 63 deletions(-) -- 2.31.1

1 10

Re: [PATCH v3 8/9] kernel: export task_work_add
by Desmond Cheong Zhi Xi 19 Aug '21

19 Aug '21

On 19/8/21 5:26 pm, Christoph Hellwig wrote: > On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote: >> +EXPORT_SYMBOL(task_work_add); > > EXPORT_SYMBOL_GPL for this kinds of functionality, please. > Thanks, I wasn't aware of the GPL-only export. I'll update this in a future series if we still need the export.

1 0

[PATCH] no review: test for uploading patch
by yangcong 19 Aug '21

19 Aug '21

1 0

[PATCH] no review: test for uploading patch
by xiazhengqiao 19 Aug '21

19 Aug '21

no review: test for uploading patch Signed-off-by: xiazhengqiao <xiazhengqiao(a)huaqin.corp-partner.google.com> --- drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c index db9d0b86d542..b2240eee688e 100644 --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c @@ -3,6 +3,7 @@ * Copyright (c) 2018 MediaTek Inc. * Author: Jitao Shi <jitao.shi(a)mediatek.com> */ +/*test for uploading patch*/ #include <linux/delay.h> #include <linux/gpio/consumer.h> -- 2.17.1

1 0

[v1 0/2] drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail
by yangcong 19 Aug '21

19 Aug '21

The auo,b101uan08.3 panel (already supported by this driver) has a 3.3V rail that needs to be turned on. For previous users of this panel this voltage was directly output by pmic. On a new user (the not-yet-upstream sc7180-trogdor-mrbland board) we need to turn the 3.3V rail on. Add support in the driver for this. yangcong (2): drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail dt-bindings: drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail .../bindings/display/panel/boe,tv101wum-nl6.yaml | 4 ++++ drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 11 +++++++++++ 2 files changed, 15 insertions(+) -- 2.25.1

1 2

← Newer
1
...
41
42
43
44
45
46
47
...
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021