From cb8e30ddb7e345867f6f2da8a08291d7d9e037db Mon Sep 17 00:00:00 2001 From: Douglas Anderson Date: Mon, 17 Oct 2022 12:18:51 -0700 Subject: [PATCH 1/3] drm/bridge: ps8640: Add back the 50 ms mystery delay after HPD Back in commit 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power management") we removed a mysterious 50 ms delay because "Parade's support [couldn't] explain what the delay [was] for". While I'm always a fan of removing mysterious delays, I suspect that we need this mysterious delay to avoid some problems. Specifically, what I found recently is that on sc7180-trogdor-homestar sometimes the AUX backlight wasn't initializing properly. Some debugging showed that the drm_dp_dpcd_read() function that the AUX backlight driver was calling was returning bogus data about 1% of the time when I booted up. This confused drm_panel_dp_aux_backlight(). From continued debugging: - If I retried the read then the read worked just fine. - If I added a loop to perform the same read that drm_panel_dp_aux_backlight() was doing 30 times at bootup I could see that some percentage of the time the first read would give bogus data but all 29 additional reads would always be fine. - If I added a large delay _after_ powering on the panel but before powering on PS8640 I could still reproduce the problem. - If I added a delay after PS8640 powered on then I couldn't reproduce the problem. - I couldn't reproduce the problem on a board with the same panel but the ti-sn65dsi86 bridge chip. To me, the above indicated that there was a problem with PS8640 and not the panel. I don't really have any insight into what's going on in the MCU, but my best guess is that when the MCU itself sees the HPD go high that it does some AUX transfers itself and this is confusing things. Let's go back and add back in the mysterious 50 ms delay. We only want to do this the first time we see HPD go high after booting the MCU, not every time we double-check HPD. With this, the backlight initializes reliably on homestar. Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power management") Reviewed-by: Stephen Boyd Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20221017121813.1.I59700c745fbc31559a5d5c8e2a960279c751dbd5@changeid --- drivers/gpu/drm/bridge/parade-ps8640.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index d7483c13c569..083337a27966 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -105,6 +105,7 @@ struct ps8640 { struct gpio_desc *gpio_powerdown; struct device_link *link; bool pre_enabled; + bool need_post_hpd_delay; }; static const struct regmap_config ps8640_regmap_config[] = { @@ -173,14 +174,31 @@ static int _ps8640_wait_hpd_asserted(struct ps8640 *ps_bridge, unsigned long wai { struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL]; int status; + int ret; /* * Apparently something about the firmware in the chip signals that * HPD goes high by reporting GPIO9 as high (even though HPD isn't * actually connected to GPIO9). */ - return regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, - status & PS_GPIO9, wait_us / 10, wait_us); + ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, + status & PS_GPIO9, wait_us / 10, wait_us); + + /* + * The first time we see HPD go high after a reset we delay an extra + * 50 ms. The best guess is that the MCU is doing "stuff" during this + * time (maybe talking to the panel) and we don't want to interrupt it. + * + * No locking is done around "need_post_hpd_delay". If we're here we + * know we're holding a PM Runtime reference and the only other place + * that touches this is PM Runtime resume. + */ + if (!ret && ps_bridge->need_post_hpd_delay) { + ps_bridge->need_post_hpd_delay = false; + msleep(50); + } + + return ret; } static int ps8640_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long wait_us) @@ -381,6 +399,9 @@ static int __maybe_unused ps8640_resume(struct device *dev) msleep(50); gpiod_set_value(ps_bridge->gpio_reset, 0); + /* We just reset things, so we need a delay after the first HPD */ + ps_bridge->need_post_hpd_delay = true; + /* * Mystery 200 ms delay for the "MCU to be ready". It's unclear if * this is truly necessary since the MCU will already signal that From b3af84383e7abdc5e63435817bb73a268e7c3637 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= Date: Tue, 27 Sep 2022 18:43:03 +0200 Subject: [PATCH 2/3] drm/scheduler: fix fence ref counting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We leaked dependency fences when processes were beeing killed. Additional to that grab a reference to the last scheduled fence. Signed-off-by: Christian König Reviewed-by: Andrey Grodzovsky Link: https://patchwork.freedesktop.org/patch/msgid/20220929180151.139751-1-christian.koenig@amd.com --- drivers/gpu/drm/scheduler/sched_entity.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 6137537aaea4..4b913dbb7d7b 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -207,6 +207,7 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f, struct drm_sched_job *job = container_of(cb, struct drm_sched_job, finish_cb); + dma_fence_put(f); INIT_WORK(&job->work, drm_sched_entity_kill_jobs_work); schedule_work(&job->work); } @@ -234,8 +235,10 @@ static void drm_sched_entity_kill_jobs(struct drm_sched_entity *entity) struct drm_sched_fence *s_fence = job->s_fence; /* Wait for all dependencies to avoid data corruptions */ - while ((f = drm_sched_job_dependency(job, entity))) + while ((f = drm_sched_job_dependency(job, entity))) { dma_fence_wait(f, false); + dma_fence_put(f); + } drm_sched_fence_scheduled(s_fence); dma_fence_set_error(&s_fence->finished, -ESRCH); @@ -250,6 +253,7 @@ static void drm_sched_entity_kill_jobs(struct drm_sched_entity *entity) continue; } + dma_fence_get(entity->last_scheduled); r = dma_fence_add_callback(entity->last_scheduled, &job->finish_cb, drm_sched_entity_kill_jobs_cb); From e0ba1a39b8dfe4f005bebdd85daa89e7382e26b7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= Date: Thu, 27 Oct 2022 02:06:16 +0200 Subject: [PATCH 3/3] fbdev/core: Avoid uninitialized read in aperture_remove_conflicting_pci_device() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return on error directly from the BAR-iterating loop instead of break+return. This is actually a cosmetic fix, since it would be highly unusual to have this called for a PCI device without any memory BARs. Fixes: 9d69ef183815 ("fbdev/core: Remove remove_conflicting_pci_framebuffers()") Signed-off-by: Michał Mirosław Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/e75323732bedc46d613d72ecb40f97e3bc75eea8.1666829073.git.mirq-linux@rere.qmqm.pl --- drivers/video/aperture.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c index 9e6bcc03a1a4..41e77de1ea82 100644 --- a/drivers/video/aperture.c +++ b/drivers/video/aperture.c @@ -340,12 +340,9 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na size = pci_resource_len(pdev, bar); ret = aperture_remove_conflicting_devices(base, size, primary, name); if (ret) - break; + return ret; } - if (ret) - return ret; - /* * WARNING: Apparently we must kick fbdev drivers before vgacon, * otherwise the vga fbdev driver falls over.