[PATCH v3 15/20] drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()

2021-04-19 Thread Lyude Paul
So that we can start using drm_dbg_*() throughout the DRM DP helpers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +--- drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++- include/drm/drm_dp_dual_mode_helper.h | 4 ++-- 3 files changed, 14

[PATCH v3 11/20] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()

2021-04-19 Thread Lyude Paul
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll need to be able to access the DRM device in the dual mode DP helpers as well. Note however that since drm_dp_dual_mode_detect() can be called with DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down th

[PATCH v3 17/20] drm/print: Handle potentially NULL drm_devices in drm_dbg_*

2021-04-19 Thread Lyude Paul
While this shouldn't really be something that happens all that often, since we're going to be using the drm_dbg_* log helpers in DRM helpers it's technically possible that a driver could use an AUX adapter before it's been associated with it's respective drm_device. While drivers should take care t

[PATCH v3 18/20] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()

2021-04-19 Thread Lyude Paul
Now that we've added a back-pointer to drm_device to drm_dp_aux, made drm_dp_aux available to any functions in drm_dp_helper.c which need to print to the kernel log, and ensured all of our logging uses a consistent format, let's do the final step of the conversion and actually move everything over

[PATCH v3 16/20] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()

2021-04-19 Thread Lyude Paul
Since this is one of the few functions in drm_dp_mst_topology.c that doesn't have any way of getting access to a drm_device, let's pass the drm_dp_mst_topology_mgr down to this function so that it can use drm_dbg_kms(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_mst_topology.c |

[PATCH v3 19/20] drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()

2021-04-19 Thread Lyude Paul
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c over to using drm_err() and drm_dbg_kms(). This was done using the following cocci script: @@ expression list expr; @@ ( - DRM_DEBUG_KMS(expr); + drm_dbg_kms(dev, expr); | - DRM_ERROR(expr); + drm_err(dev,

[PATCH v3 20/20] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

2021-04-19 Thread Lyude Paul
And finally, convert all of the code in drm_dp_mst_topology.c over to using drm_err() and drm_dbg*(). Note that this refactor would have been a lot more complicated to have tried writing a coccinelle script for, so this whole thing was done by hand. v2: * Fix line-wrapping in drm_dp_mst_atomic_che

Re: [PATCH v3 03/20] drm/dp: Move i2c init to drm_dp_aux_init, add __must_check and fini

2021-04-19 Thread Ville Syrjälä
On Mon, Apr 19, 2021 at 06:55:05PM -0400, Lyude Paul wrote: > When moving around drm_dp_aux_register() calls, it turned out we > accidentally managed to cause issues with the Tegra driver due to the fact > the Tegra driver would attempt to retrieve a reference to the AUX channel's > i2c adapter - w

Re: [PATCH] drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access

2021-04-19 Thread abhinavk
On 2021-04-09 18:19, Dmitry Baryshkov wrote: The parent_name initialization was lost in refactoring, restore it now. Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into a generic code") Reported-by: kernel test robot Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar

Re: [PATCH] drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code

2021-04-19 Thread abhinavk
On 2021-04-11 17:01, Dmitry Baryshkov wrote: msm_dsi_phy_get_clk_provider() always returns two provided clocks, so return 0 instead of returning incorrect -EINVAL error code. Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into a generic code") Signed-off-by: Dmitry Baryshkov

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-19 Thread Dominique MARTINET
Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200: > In some cases, you can use the device_link infrastructure to deal > with dependencies between devices. Not sure if this would help > in your case, but have a look at device_link_add() etc in drivers/base/core.c I'll need to actually t

[Bug 212729] New: amdgpu: WARN_ON drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:119 set_reg_field_values.constprop.0+0xbe/0xe0

2021-04-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=212729 Bug ID: 212729 Summary: amdgpu: WARN_ON drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:1 19 set_reg_field_values.constprop.0+0xbe/0xe0 Product: Drivers Vers

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-19 Thread Marek Olšák
We already don't have accurate BO fences in some cases. Instead, BOs can have fences which are equal to the last seen command buffer for each queue. It's practically the same as if the kernel had no visibility into command submissions and just added a fence into all queues when it needed to wait fo

Re: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly

2021-04-19 Thread Inki Dae
21. 4. 13. 오후 6:48에 Daniel Vetter 이(가) 쓴 글: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done automatically as part of pla

<    1   2