dri-devel December 2021

dri-devel@lists.freedesktop.org

310 participants
720 discussions

[PATCH] drm/msm/dpu: fix exception in error path
by Dmitry Baryshkov 01 Dec '21

01 Dec '21

In case of DPU probe failure, prevent the following NULL pointer exception: [ 3.976112] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 3.984983] Mem abort info: [ 3.987800] ESR = 0x96000004 [ 3.990891] EC = 0x25: DABT (current EL), IL = 32 bits [ 3.996251] SET = 0, FnV = 0 [ 3.996254] EA = 0, S1PTW = 0 [ 3.996257] FSC = 0x04: level 0 translation fault [ 3.996260] Data abort info: [ 3.996262] ISV = 0, ISS = … [View More]0x00000004 [ 4.005229] CM = 0, WnR = 0 [ 4.028893] [0000000000000030] user address but active_mm is swapper [ 4.035305] Internal error: Oops: 96000004 [#1] SMP [ 4.040223] Modules linked in: [ 4.043317] CPU: 1 PID: 50 Comm: kworker/u16:2 Not tainted 5.16.0-rc1-00036-g6d4bafcbb015-dirty #166 [ 4.052518] Hardware name: Thundercomm Dragonboard 845c (DT) [ 4.058224] Workqueue: events_unbound deferred_probe_work_func [ 4.064105] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.071124] pc : dpu_core_irq_uninstall+0x28/0x100 [ 4.075960] lr : dpu_core_irq_uninstall+0x24/0x100 [ 4.080793] sp : ffff80001057b990 [ 4.084138] x29: ffff80001057b990 x28: ffff7653c0a41c00 x27: ffff7653c0926480 [ 4.091330] x26: ffffb90d5d262ad0 x25: ffff7653c4b2e980 x24: ffff7653c0046080 [ 4.098520] x23: ffff7653c099a810 x22: ffff7653c5a65800 x21: ffff7653c5a65080 [ 4.105711] x20: ffff7653c5a65800 x19: ffff7653c0046080 x18: 0000000000000034 [ 4.112902] x17: 0000000000000038 x16: 0000000000000005 x15: 000000000000000c [ 4.120095] x14: 000000000000024c x13: ffff7653c2f90358 x12: 0000000000000000 [ 4.127287] x11: ffff7653c2f903b0 x10: 00000000000009c0 x9 : ffff80001057b180 [ 4.134477] x8 : ffff80001057b404 x7 : 0000000000000000 x6 : ffff7653c5a5f190 [ 4.141669] x5 : ffff80001057b890 x4 : 0000000000000000 x3 : ffff7653c5a5f0f4 [ 4.148859] x2 : ffff7653c2f50000 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.156052] Call trace: [ 4.158525] dpu_core_irq_uninstall+0x28/0x100 [ 4.163004] dpu_irq_uninstall+0x10/0x20 [ 4.166963] msm_drm_uninit.isra.0+0xe0/0x1b0 [ 4.171353] msm_drm_bind+0x278/0x5f0 [ 4.175043] try_to_bring_up_master+0x164/0x1d0 [ 4.179610] __component_add+0xa0/0x170 [ 4.183482] component_add+0x14/0x20 [ 4.187086] dsi_dev_probe+0x1c/0x30 [ 4.190691] platform_probe+0x68/0xe0 [ 4.194382] really_probe.part.0+0x9c/0x30c [ 4.198601] __driver_probe_device+0x98/0x144 [ 4.202990] driver_probe_device+0x44/0x15c [ 4.207208] __device_attach_driver+0xb4/0x120 [ 4.211685] bus_for_each_drv+0x78/0xd0 [ 4.215549] __device_attach+0xdc/0x184 [ 4.219412] device_initial_probe+0x14/0x20 [ 4.223630] bus_probe_device+0x9c/0xa4 [ 4.227503] deferred_probe_work_func+0x88/0xc0 [ 4.232075] process_one_work+0x1e8/0x380 [ 4.236126] worker_thread+0x280/0x520 [ 4.239902] kthread+0x168/0x174 [ 4.243166] ret_from_fork+0x10/0x20 [ 4.246778] Code: f9442400 91004000 940188b9 f9430660 (b9403001) [ 4.252925] ---[ end trace b470a50cd7b5e606 ]--- Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c index d2b6dca487e3..fc1b6c47c93d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c @@ -575,6 +575,9 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms) { int i; + if (!dpu_kms->hw_intr) + return; + pm_runtime_get_sync(&dpu_kms->pdev->dev); for (i = 0; i < dpu_kms->hw_intr->total_irqs; i++) if (!list_empty(&dpu_kms->hw_intr->irq_cb_tbl[i])) -- 2.33.0 [View Less]

2 2

[PATCH v2 1/3] dt-bindings: ls2k1000: add gpu device node
by Sui Jingfeng 01 Dec '21

01 Dec '21

From: suijingfeng <suijingfeng(a)loongson.cn> There is a vivante gpu (GC1000 V5037) in ls2k1000, but it is pci device not platform device. ls2k1000 is dual-core mips64 cpu made by loongson. Signed-off-by: suijingfeng <suijingfeng(a)loongson.cn> Signed-off-by: Sui Jingfeng <15330273260(a)189.cn> --- arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi b/arch/… [View More]

1 0

[PATCH v2 0/2] drm: rcar-du: mipi-dsi: Cleanup and Fixes
by Kieran Bingham 01 Dec '21

01 Dec '21

Following on from the earlier version of this series, is an updated patch to move the bridge registration from rcar_mipi_dsi_probe() to rcar_mipi_dsi_host_attach() followed by an immediate update to that code to refactor it to use the new devm_drm_of_get_bridge helper. These two patches are kept distinct to support review, and are both expected to be squashed directly into the still-to-be-posted update of the DSI driver by Laurent [0]. [0] https://lore.kernel.org/all/20210623135639.17125-1-… [View More]

2 6

[PATCH] dma_heap: use sg_table.orig_nents in sg_table release flow
by guangming.cao＠mediatek.com 01 Dec '21

01 Dec '21

From: Guangming <Guangming.Cao(a)mediatek.com> Use (sg_table.orig_nents) rather than (sg_table.nents) to traverse sg_table to free sg_table. Use (sg_table.nents) maybe will casuse some pages can't be freed. Signed-off-by: Guangming <Guangming.Cao(a)mediatek.com> --- drivers/dma-buf/heaps/system_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 23a7e74ef966..ce10d4eb674c 100644 … [View More]

7 10

[PATCH v2] drm/i915/dp: Perform 30ms delay after source OUI write
by Lyude Paul 01 Dec '21

01 Dec '21

While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot up without detecting Intel HDR backlight support - even though it's supported on the system. One example of such a laptop is the Lenovo P17 1st generation. Following some investigation Ville Syrjälä did through the docs they have available to them, they discovered that there's actually supposed to be a 30ms wait after writing the source OUI before we … [View More]begin setting up the rest of the backlight interface. This seems to be correct, as adding this 30ms delay seems to have completely fixed the probing issues I was previously seeing. So - let's start performing a 30ms wait after writing the OUI, which we do in a manner similar to how we keep track of PPS delays (e.g. record the timestamp of the OUI write, and then wait for however many ms are left since that timestamp right before we interact with the backlight) in order to avoid waiting any longer then we need to. As well, this also avoids us performing this delay on systems where we don't end up using the HDR backlight interface. V2: * Move panel delays into intel_pps Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v5.12+ --- drivers/gpu/drm/i915/display/intel_display_types.h | 4 ++++ drivers/gpu/drm/i915/display/intel_dp.c | 11 +++++++++++ drivers/gpu/drm/i915/display/intel_dp.h | 2 ++ drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 5 +++++ 4 files changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h index ea1e8a6e10b0..ad64f9caa7ff 100644 --- a/drivers/gpu/drm/i915/display/intel_display_types.h +++ b/drivers/gpu/drm/i915/display/intel_display_types.h @@ -1485,6 +1485,7 @@ struct intel_pps { bool want_panel_vdd; unsigned long last_power_on; unsigned long last_backlight_off; + unsigned long last_oui_write; ktime_t panel_power_off_time; intel_wakeref_t vdd_wakeref; @@ -1653,6 +1654,9 @@ struct intel_dp { struct intel_dp_pcon_frl frl; struct intel_psr psr; + + /* When we last wrote the OUI for eDP */ + unsigned long last_oui_write; }; enum lspcon_vendor { diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 0a424bf69396..45318891ba07 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -29,6 +29,7 @@ #include <linux/i2c.h> #include <linux/notifier.h> #include <linux/slab.h> +#include <linux/timekeeping.h> #include <linux/types.h> #include <asm/byteorder.h> @@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful) if (drm_dp_dpcd_write(&intel_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) < 0) drm_err(&i915->drm, "Failed to write source OUI\n"); + + intel_dp->pps.last_oui_write = jiffies; +} + +void intel_dp_wait_source_oui(struct intel_dp *intel_dp) +{ + struct drm_i915_private *i915 = dp_to_i915(intel_dp); + + drm_dbg_kms(&i915->drm, "Performing OUI wait\n"); + wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30); } /* If the device supports it, try to set the power state appropriately */ diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h index ce229026dc91..b64145a3869a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.h +++ b/drivers/gpu/drm/i915/display/intel_dp.h @@ -119,4 +119,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp, const struct intel_crtc_state *crtc_state); void intel_dp_phy_test(struct intel_encoder *encoder); +void intel_dp_wait_source_oui(struct intel_dp *intel_dp); + #endif /* __INTEL_DP_H__ */ diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index 8b9c925c4c16..62c112daacf2 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -36,6 +36,7 @@ #include "intel_backlight.h" #include "intel_display_types.h" +#include "intel_dp.h" #include "intel_dp_aux_backlight.h" /* TODO: @@ -106,6 +107,8 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector) int ret; u8 tcon_cap[4]; + intel_dp_wait_source_oui(intel_dp); + ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, sizeof(tcon_cap)); if (ret != sizeof(tcon_cap)) return false; @@ -204,6 +207,8 @@ intel_dp_aux_hdr_enable_backlight(const struct intel_crtc_state *crtc_state, int ret; u8 old_ctrl, ctrl; + intel_dp_wait_source_oui(intel_dp); + ret = drm_dp_dpcd_readb(&intel_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS, &old_ctrl); if (ret != 1) { drm_err(&i915->drm, "Failed to read current backlight control mode: %d\n", ret); -- 2.33.1 [View Less]

3 4

[PATCH v2 0/2] drm/msm: Fix dsi/bridge probe
by AngeloGioacchino Del Regno 01 Dec '21

01 Dec '21

Context, from patch 2/2: Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the DSI host gets initialized earlier, but this caused unability to probe the entire stack of components because they all depend on interrupts coming from the main `mdss` node (mdp5, or dpu1). Series v2: After a very nice conversation with Dmitry, it turned out that my first approach to solve this issue wasn't great: even though it appeared to actually work, it was introducing a number of issues, one of … [View More]

2 4

Re: [PATCH] drm: rcar-du: add modifiers support
by Laurent Pinchart 01 Dec '21

01 Dec '21

Hello Esaki-san, (CC'ing dri-devel and Daniel Stone) On Sat, May 11, 2019 at 09:10:27PM +0300, Laurent Pinchart wrote: > On Thu, May 09, 2019 at 06:25:19PM +0900, Esaki Tomohito wrote: > > Hi Laurent-san > > > > > What's the purpose of this, as it adds no new functionality to the > > > driver ? Why is this change needed ? > > > > Weston compositor (v5.0.0 or later) uses the DRM API to get the > > supported modifiers and determines if the … [View More]sprite plane can be used by > > comparing the modifiers with the client specified modifier. > > In currently driver, since the weston doesn't know supported modifiers, > > that cannot determine if the received dmabuf can be passed through to > > sprite plane. > > Since there are R-Car GPU which support linear modifier, the sprite > > plane cannot be used in a compositor similar to the weston if client > > specify linear modifier. > > I don't think the right solution is to expose the linear modifier from > all drivers that don't otherwise support modifiers. We should instead > fix it either in Weston, and treat drivers that don't support the > modifiers API as supporting the linear modifier only, or in the DRM/KMS > core by reporting the linear modifier for drivers that don't explicitly > support modifiers. I've been pointed to https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3350#note_1…, and we had a discussion on the #dri-devel IRC channel today on this topic. It turns out I was wrong, not specifying modifiers in userspace is different than specifying a linear modifier. This is true for some legacy drivers only (e.g. radeon) that pre-date the modifiers API, and which select a tiling format internally based on some heuristics. I still don't like this patch though, as it would need to be replicated in most drivers. It would be better if we could handle this in the DRM core. Daniel kindly offered to summarize the IRC discussion in a reply to this e-mail. > > On 2019/05/09 16:14, Laurent Pinchart wrote: > > > On Thu, May 09, 2019 at 02:45:18PM +0900, Tomohito Esaki wrote: > > >> Add support for the linear modifier. Since the rcar-du device supports > > >> only linear modifier, this driver doesn't support other modifiers. > > > > > > What's the purpose of this, as it adds no new functionality to the > > > driver ? Why is this change needed ? > > > > > >> Signed-off-by: Tomohito Esaki <etom(a)igel.co.jp> > > >> --- > > >> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 +++++++++++ > > >> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 ++++++++++++++- > > >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 15 ++++++++++++++- > > >> 3 files changed, 39 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > >> index 3b7d50a8fb9b..9c5e15a5ab1c 100644 > > >> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > >> @@ -214,6 +214,16 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv, > > >> return ERR_PTR(-EINVAL); > > >> } > > >> > > >> + /* > > >> + * Support only LINEAR modifier. > > >> + */ > > >> + if ((mode_cmd->flags & DRM_MODE_FB_MODIFIERS) && > > >> + mode_cmd->modifier[0] != DRM_FORMAT_MOD_LINEAR) { > > >> + dev_dbg(dev->dev, "unsupported fb modifier 0x%llx\n", > > >> + mode_cmd->modifier[0]); > > >> + return ERR_PTR(-EINVAL); > > >> + } > > >> + > > >> if (rcdu->info->gen < 3) { > > >> /* > > >> * On Gen2 the DU limits the pitch to 4095 pixels and requires > > >> @@ -529,6 +539,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu) > > >> dev->mode_config.min_width = 0; > > >> dev->mode_config.min_height = 0; > > >> dev->mode_config.normalize_zpos = true; > > >> + dev->mode_config.allow_fb_modifiers = true; > > >> dev->mode_config.funcs = &rcar_du_mode_config_funcs; > > >> dev->mode_config.helper_private = &rcar_du_mode_config_helper; > > >> > > >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > > >> index c6430027169f..32135ad387fa 100644 > > >> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c > > >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > > >> @@ -726,6 +726,13 @@ static int rcar_du_plane_atomic_get_property(struct drm_plane *plane, > > >> return 0; > > >> } > > >> > > >> +static bool rcar_du_plane_format_mod_supported(struct drm_plane *plane, > > >> + uint32_t format, > > >> + uint64_t modifier) > > >> +{ > > >> + return modifier == DRM_FORMAT_MOD_LINEAR; > > >> +} > > >> + > > >> static const struct drm_plane_funcs rcar_du_plane_funcs = { > > >> .update_plane = drm_atomic_helper_update_plane, > > >> .disable_plane = drm_atomic_helper_disable_plane, > > >> @@ -735,6 +742,7 @@ static const struct drm_plane_funcs rcar_du_plane_funcs = { > > >> .atomic_destroy_state = rcar_du_plane_atomic_destroy_state, > > >> .atomic_set_property = rcar_du_plane_atomic_set_property, > > >> .atomic_get_property = rcar_du_plane_atomic_get_property, > > >> + .format_mod_supported = rcar_du_plane_format_mod_supported, > > >> }; > > >> > > >> static const uint32_t formats[] = { > > >> @@ -750,6 +758,11 @@ static const uint32_t formats[] = { > > >> DRM_FORMAT_NV16, > > >> }; > > >> > > >> +static const uint64_t modifiers[] = { > > >> + DRM_FORMAT_MOD_LINEAR, > > >> + DRM_FORMAT_MOD_INVALID, > > >> +}; > > >> + > > >> int rcar_du_planes_init(struct rcar_du_group *rgrp) > > >> { > > >> struct rcar_du_device *rcdu = rgrp->dev; > > >> @@ -776,7 +789,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp) > > >> ret = drm_universal_plane_init(rcdu->ddev, &plane->plane, crtcs, > > >> &rcar_du_plane_funcs, formats, > > >> ARRAY_SIZE(formats), > > >> - NULL, type, NULL); > > >> + modifiers, type, NULL); > > >> if (ret < 0) > > >> return ret; > > >> > > >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > > >> index 0878accbd134..9d1382b02717 100644 > > >> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > > >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > > >> @@ -139,6 +139,11 @@ static const u32 formats_kms[] = { > > >> DRM_FORMAT_YVU444, > > >> }; > > >> > > >> +static const uint64_t modifiers_kms[] = { > > >> + DRM_FORMAT_MOD_LINEAR, > > >> + DRM_FORMAT_MOD_INVALID, > > >> +}; > > >> + > > >> static const u32 formats_v4l2[] = { > > >> V4L2_PIX_FMT_RGB332, > > >> V4L2_PIX_FMT_ARGB444, > > >> @@ -344,6 +349,13 @@ static void rcar_du_vsp_plane_reset(struct drm_plane *plane) > > >> state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1; > > >> } > > >> > > >> +static bool rcar_du_vsp_plane_format_mod_supported(struct drm_plane *plane, > > >> + uint32_t format, > > >> + uint64_t modifier) > > >> +{ > > >> + return modifier == DRM_FORMAT_MOD_LINEAR; > > >> +} > > >> + > > >> static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = { > > >> .update_plane = drm_atomic_helper_update_plane, > > >> .disable_plane = drm_atomic_helper_disable_plane, > > >> @@ -351,6 +363,7 @@ static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = { > > >> .destroy = drm_plane_cleanup, > > >> .atomic_duplicate_state = rcar_du_vsp_plane_atomic_duplicate_state, > > >> .atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state, > > >> + .format_mod_supported = rcar_du_vsp_plane_format_mod_supported, > > >> }; > > >> > > >> int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np, > > >> @@ -397,7 +410,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np, > > >> &rcar_du_vsp_plane_funcs, > > >> formats_kms, > > >> ARRAY_SIZE(formats_kms), > > >> - NULL, type, NULL); > > >> + modifiers_kms, type, NULL); > > >> if (ret < 0) > > >> return ret; > > >> -- Regards, Laurent Pinchart [View Less]

3 6

[PATCH v4] drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms()
by Zhou Qingyang 01 Dec '21

01 Dec '21

In radeon_driver_open_kms(), radeon_vm_bo_add() is assigned to vm->ib_bo_va and passes and used in radeon_vm_bo_set_addr(). In radeon_vm_bo_set_addr(), there is a dereference of vm->ib_bo_va, which could lead to a NULL pointer dereference on failure of radeon_vm_bo_add(). Fix this bug by adding a check of vm->ib_bo_va. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two … [View More]code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_RADEON=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: cc9e67e3d700 ("drm/radeon: fix VM IB handling") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Zhou Qingyang <zhou1615(a)umn.edu> --- Changes in v4: - Initialize the variables to silence warning Changes in v3: - Fix the bug that good case will also be freed - Improve code style Changes in v2: - Improve the error handling into goto style drivers/gpu/drm/radeon/radeon_kms.c | 37 ++++++++++++++++------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index 482fb0ae6cb5..9d0f840286a1 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -648,7 +648,9 @@ void radeon_driver_lastclose_kms(struct drm_device *dev) int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) { struct radeon_device *rdev = dev->dev_private; - int r; + struct radeon_fpriv *fpriv = NULL; + struct radeon_vm *vm = NULL; + int r = 0; file_priv->driver_priv = NULL; @@ -660,8 +662,6 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) /* new gpu have virtual address space support */ if (rdev->family >= CHIP_CAYMAN) { - struct radeon_fpriv *fpriv; - struct radeon_vm *vm; fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL); if (unlikely(!fpriv)) { @@ -672,35 +672,38 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) if (rdev->accel_working) { vm = &fpriv->vm; r = radeon_vm_init(rdev, vm); - if (r) { - kfree(fpriv); - goto out_suspend; - } + if (r) + goto out_fpriv; r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false); - if (r) { - radeon_vm_fini(rdev, vm); - kfree(fpriv); - goto out_suspend; - } + if (r) + goto out_vm_fini; /* map the ib pool buffer read only into * virtual address space */ vm->ib_bo_va = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo); + if (!vm->ib_bo_va) { + r = -ENOMEM; + goto out_vm_fini; + } + r = radeon_vm_bo_set_addr(rdev, vm->ib_bo_va, RADEON_VA_IB_OFFSET, RADEON_VM_PAGE_READABLE | RADEON_VM_PAGE_SNOOPED); - if (r) { - radeon_vm_fini(rdev, vm); - kfree(fpriv); - goto out_suspend; - } + if (r) + goto out_vm_fini; } file_priv->driver_priv = fpriv; } +out_vm_fini: + if (r) + radeon_vm_fini(rdev, vm); +out_fpriv: + if (r) + kfree(fpriv); out_suspend: pm_runtime_mark_last_busy(dev->dev); pm_runtime_put_autosuspend(dev->dev); -- 2.25.1 [View Less]

1 0

[PATCH] drm/exynos: drop the use of label from exynos_dsi_register_te_irq
by Inki Dae 01 Dec '21

01 Dec '21

Dropped the use of 'out' label from exynos_dsi_register_te_irq function because the label isn't needed. This patch returns an error in each error case directly not going to 'out' label. With this patch build warning[1] is also fixed, which was reported by kernel test robot <lkp(a)intel.com> [1] https://www.spinics.net/lists/dri-devel/msg323803.html Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- drivers/gpu/drm/exynos/… [View More]

1 0

[PATCH v5 0/1] Use i915 macros to check for PTEs
by Michael Cheng 01 Dec '21

01 Dec '21

Instead of using _PAGE_RW and _PAGE_PRESENT to check for 0 and 1 bits, this series replaces them with GEN6_PTE_VALID and BYT_PTE_WRITEABLE. We should be using macros defined for i915 to check these bits, instead of macros defined by the mmu. Some arch does not have these macros defined, thus leading to compilation errors. v2: Corrected sender's email. v3: Corrected spelling error. v4: Clean up a few other macros that are checking 0 and 1 bits. v5: Instead of introducing new macros for … [View More]

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2021