From 938f324e7df25e89226c6fe137028af73cd6160b Mon Sep 17 00:00:00 2001 From: Guido Günther Date: Tue, 13 Oct 2020 12:32:46 +0200 Subject: drm/panel: mantix: Don't dereference NULL mode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Don't dereference mode which was just NULL checked. Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel") Signed-off-by: Guido Günther Reported-by: Dan Carpenter Signed-off-by: Sam Ravnborg Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/659158549f3c6cc1c71ceed0943e760e861c1206.1602584953.git.agx@sigxcpu.org --- drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c index 3482e28e30fc..4a7fbf64bb7a 100644 --- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c @@ -204,7 +204,7 @@ static int mantix_get_modes(struct drm_panel *panel, if (!mode) { dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n", default_mode.hdisplay, default_mode.vdisplay, - drm_mode_vrefresh(mode)); + drm_mode_vrefresh(&default_mode)); return -ENOMEM; } -- cgit v1.2.3 From 6af672523fe4bd71f5e70c50258fd0fc09663fae Mon Sep 17 00:00:00 2001 From: Guido Günther Date: Tue, 13 Oct 2020 12:32:47 +0200 Subject: drm/panel: mantix: Fix panel reset MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The mantix panel needs two reset lines (RESX and TP_RSTN) deasserted to output an image. Only deasserting RESX is not enough and the display will stay blank. Deassert in prepare() and assert in unprepare() to keep device held in reset when off. Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel") Signed-off-by: Guido Günther Signed-off-by: Sam Ravnborg Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/ba71a8ab010d263a8058dd4f711e3bcd95877bf2.1602584953.git.agx@sigxcpu.org --- drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c index 4a7fbf64bb7a..0c5f22e95c2d 100644 --- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c @@ -26,7 +26,9 @@ struct mantix { struct device *dev; struct drm_panel panel; + struct gpio_desc *reset_gpio; + struct gpio_desc *tp_rstn_gpio; struct regulator *avdd; struct regulator *avee; @@ -124,6 +126,10 @@ static int mantix_unprepare(struct drm_panel *panel) { struct mantix *ctx = panel_to_mantix(panel); + gpiod_set_value_cansleep(ctx->tp_rstn_gpio, 1); + usleep_range(5000, 6000); + gpiod_set_value_cansleep(ctx->reset_gpio, 1); + regulator_disable(ctx->avee); regulator_disable(ctx->avdd); /* T11 */ @@ -165,13 +171,10 @@ static int mantix_prepare(struct drm_panel *panel) return ret; } - /* T3+T5 */ - usleep_range(10000, 12000); - - gpiod_set_value_cansleep(ctx->reset_gpio, 1); - usleep_range(5150, 7000); - + /* T3 + T4 + time for voltage to become stable: */ + usleep_range(6000, 7000); gpiod_set_value_cansleep(ctx->reset_gpio, 0); + gpiod_set_value_cansleep(ctx->tp_rstn_gpio, 0); /* T6 */ msleep(50); @@ -236,12 +239,18 @@ static int mantix_probe(struct mipi_dsi_device *dsi) if (!ctx) return -ENOMEM; - ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); if (IS_ERR(ctx->reset_gpio)) { dev_err(dev, "cannot get reset gpio\n"); return PTR_ERR(ctx->reset_gpio); } + ctx->tp_rstn_gpio = devm_gpiod_get(dev, "mantix,tp-rstn", GPIOD_OUT_HIGH); + if (IS_ERR(ctx->tp_rstn_gpio)) { + dev_err(dev, "cannot get tp-rstn gpio\n"); + return PTR_ERR(ctx->tp_rstn_gpio); + } + mipi_dsi_set_drvdata(dsi, ctx); ctx->dev = dev; -- cgit v1.2.3 From 84c971b356379c621df595bd00c3114579dfa59f Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 15 Oct 2020 11:36:40 +0200 Subject: drm/sun4i: frontend: Rework a bit the phase data The scaler filter phase setup in the allwinner kernel has two different cases for setting up the scaler filter, the first one using different phase parameters for the two channels, and the second one reusing the first channel parameters on the second channel. The allwinner kernel has a third option where the horizontal phase of the second channel will be set to a different value than the vertical one (and seems like it's the same value than one used on the first channel). However, that code path seems to never be taken, so we can ignore it for now, and it's essentially what we're doing so far as well. Since we will have always the same values across each components of the filter setup for a given channel, we can simplify a bit our frontend structure by only storing the phase value we want to apply to a given channel. Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-maxime@cerno.tech --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++++++++-------------------------- drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +----- 2 files changed, 9 insertions(+), 31 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index b51cc685c13a..b9eaaef41876 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, * related to the scaler FIR filter phase parameters. */ regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, - frontend->data->ch_phase[0].horzphase); + frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, - frontend->data->ch_phase[1].horzphase); + frontend->data->ch_phase[1]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, - frontend->data->ch_phase[0].vertphase[0]); + frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, - frontend->data->ch_phase[1].vertphase[0]); + frontend->data->ch_phase[1]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, - frontend->data->ch_phase[0].vertphase[1]); + frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, - frontend->data->ch_phase[1].vertphase[1]); + frontend->data->ch_phase[1]); /* * Checking the input format is sufficient since we currently only @@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = { }; static const struct sun4i_frontend_data sun4i_a10_frontend = { - .ch_phase = { - { - .horzphase = 0, - .vertphase = { 0, 0 }, - }, - { - .horzphase = 0xfc000, - .vertphase = { 0xfc000, 0xfc000 }, - }, - }, + .ch_phase = { 0x000, 0xfc000 }, .has_coef_rdy = true, }; static const struct sun4i_frontend_data sun8i_a33_frontend = { - .ch_phase = { - { - .horzphase = 0x400, - .vertphase = { 0x400, 0x400 }, - }, - { - .horzphase = 0x400, - .vertphase = { 0x400, 0x400 }, - }, - }, + .ch_phase = { 0x400, 0x400 }, .has_coef_access_ctrl = true, }; diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h b/drivers/gpu/drm/sun4i/sun4i_frontend.h index 0c382c1ddb0f..2e7b76e50c2b 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.h +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h @@ -115,11 +115,7 @@ struct reset_control; struct sun4i_frontend_data { bool has_coef_access_ctrl; bool has_coef_rdy; - - struct { - u32 horzphase; - u32 vertphase[2]; - } ch_phase[2]; + u32 ch_phase[2]; }; struct sun4i_frontend { -- cgit v1.2.3 From 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 15 Oct 2020 11:36:41 +0200 Subject: drm/sun4i: frontend: Reuse the ch0 phase for RGB formats When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index b9eaaef41876..80f0c4392fef 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, struct drm_framebuffer *fb = state->fb; const struct drm_format_info *format = fb->format; uint64_t modifier = fb->modifier; + unsigned int ch1_phase_idx; u32 out_fmt_val; u32 in_fmt_val, in_mod_val, in_ps_val; unsigned int i; @@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, * I have no idea what this does exactly, but it seems to be * related to the scaler FIR filter phase parameters. */ + ch1_phase_idx = (format->num_planes > 1) ? 1 : 0; regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, - frontend->data->ch_phase[1]); + frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, - frontend->data->ch_phase[1]); + frontend->data->ch_phase[ch1_phase_idx]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, frontend->data->ch_phase[0]); regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, - frontend->data->ch_phase[1]); + frontend->data->ch_phase[ch1_phase_idx]); /* * Checking the input format is sufficient since we currently only -- cgit v1.2.3 From e3190b5e9462067714d267c40d8c8c1d0463dda3 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 15 Oct 2020 11:36:42 +0200 Subject: drm/sun4i: frontend: Fix the scaler phase on A33 The A33 has a different phase parameter in the Allwinner BSP on the channel1 than the one currently applied. Fix this. Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c index 80f0c4392fef..edb60ae0a9b7 100644 --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c @@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend = { }; static const struct sun4i_frontend_data sun8i_a33_frontend = { - .ch_phase = { 0x400, 0x400 }, + .ch_phase = { 0x400, 0xfc400 }, .has_coef_access_ctrl = true, }; -- cgit v1.2.3 From 897dbea6b716c0f2c5bcd4ba1eb4d809caba290c Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Mon, 26 Oct 2020 12:49:05 +0300 Subject: drm/v3d: Fix double free in v3d_submit_cl_ioctl() Originally this error path used to leak "bin" but then we accidentally applied two separate commits to fix it and ended up with a double free. Signed-off-by: Dan Carpenter Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201026094905.GA1634423@mwanda --- drivers/gpu/drm/v3d/v3d_gem.c | 1 - 1 file changed, 1 deletion(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c index 915f8bfdb58c..182c586525eb 100644 --- a/drivers/gpu/drm/v3d/v3d_gem.c +++ b/drivers/gpu/drm/v3d/v3d_gem.c @@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data, ret = v3d_job_init(v3d, file_priv, &bin->base, v3d_job_free, args->in_sync_bcl); if (ret) { - kfree(bin); v3d_job_put(&render->base); kfree(bin); return ret; -- cgit v1.2.3 From 444d03badc72e246bbcbca4b9c922d70ef046934 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:14 +0100 Subject: drm: kernel-doc: document drm_dp_set_subconnector_property() params Changeset e5b92773287c ("drm: report dp downstream port type as a subconnector property") added a new function to the kAPI, but didn't add any documentation for the parameters for drm_dp_set_subconnector_property(). Fixes: e5b92773287c ("drm: report dp downstream port type as a subconnector property") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/0870be85a77bea4ba5cf1715010834289a4e10b1.1603791716.git.mchehab+huawei@kernel.org --- drivers/gpu/drm/drm_dp_helper.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 90807a6b415c..b1c71af88579 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1028,7 +1028,8 @@ EXPORT_SYMBOL(drm_dp_downstream_debug); /** * drm_dp_subconnector_type() - get DP branch device type - * + * @dpcd: DisplayPort configuration data + * @port_cap: port capabilities */ enum drm_mode_subconnector drm_dp_subconnector_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE], @@ -1079,6 +1080,10 @@ EXPORT_SYMBOL(drm_dp_subconnector_type); /** * drm_mode_set_dp_subconnector_property - set subconnector for DP connector + * @connector: connector to set property on + * @status: connector status + * @dpcd: DisplayPort configuration data + * @port_cap: port capabilities * * Called by a driver on every detect event. */ -- cgit v1.2.3 From 21a53bbd469b6df21c13f3a5aee1b935f032c03c Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:15 +0100 Subject: drm/dp: fix kernel-doc warnings at drm_dp_helper.c As warned by kernel-doc: ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type' ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode' Some function parameters weren't documented. Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port types") Reviewed-by: Lyude Paul Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/03c9c8ba3f492aca76e2b4836803219cd9c971cf.1603791716.git.mchehab+huawei@kernel.org --- drivers/gpu/drm/drm_dp_helper.c | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b1c71af88579..deeed73f4ed6 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -374,6 +374,10 @@ static bool is_edid_digital_input_dp(const struct edid *edid) * drm_dp_downstream_is_type() - is the downstream facing port of certain type? * @dpcd: DisplayPort configuration data * @port_cap: port capabilities + * @type: port type to be checked. Can be: + * %DP_DS_PORT_TYPE_DP, %DP_DS_PORT_TYPE_VGA, %DP_DS_PORT_TYPE_DVI, + * %DP_DS_PORT_TYPE_HDMI, %DP_DS_PORT_TYPE_NON_EDID, + * %DP_DS_PORT_TYPE_DP_DUALMODE or %DP_DS_PORT_TYPE_WIRELESS. * * Caveat: Only works with DPCD 1.1+ port caps. * @@ -870,6 +874,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion); /** * drm_dp_downstream_mode() - return a mode for downstream facing port + * @dev: DRM device * @dpcd: DisplayPort configuration data * @port_cap: port capabilities * -- cgit v1.2.3 From 8d7d8c0afbeae253a2bc0a304ebbd21fa980467f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:16 +0100 Subject: drm/dp: fix a kernel-doc issue at drm_edid.c The name of the argument is different, causing those warnings: ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic' ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic' Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()") Reviewed-by: Lyude Paul Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/7f4d6c3ff6df63ebd006eb90a5108006c23e2168.1603791716.git.mchehab+huawei@kernel.org --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a82f37d44258..631125b46e04 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8 svd) /** * drm_display_mode_from_cea_vic() - return a mode for CEA VIC * @dev: DRM device - * @vic: CEA VIC of the mode + * @video_code: CEA VIC of the mode * * Creates a new mode matching the specified CEA VIC. * -- cgit v1.2.3 From 7811a339da2e3b741dc19de50bad5a7728b6ef22 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:29 +0100 Subject: drm: kernel-doc: add description for a new function parameter As reported by "make htmldocs": ./drivers/gpu/drm/drm_prime.c:808: warning: Function parameter or member 'dev' not described in 'drm_prime_pages_to_sg' Add a description for the new parameter. Fixes: 707d561f77b5 ("drm: allow limiting the scatter list size.") Signed-off-by: Mauro Carvalho Chehab Acked-by: Gerd Hoffmann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/9366f48e6e9c3ec2f31a3e68452a2b23a1089fce.1603791716.git.mchehab+huawei@kernel.org --- drivers/gpu/drm/drm_prime.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index d6808f678db5..9f955f2010c2 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -794,6 +794,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { /** * drm_prime_pages_to_sg - converts a page array into an sg list + * @dev: DRM device * @pages: pointer to the array of page pointers to convert * @nr_pages: length of the page vector * -- cgit v1.2.3 From 9ce0af3e9573fb84c4c807183d13ea2a68271e4b Mon Sep 17 00:00:00 2001 From: Hoegeun Kwon Date: Tue, 27 Oct 2020 13:14:42 +0900 Subject: drm/vc4: drv: Add error handding for bind There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index f1a5fd5dab6f..a17aa1db11b6 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -314,6 +314,7 @@ unbind_all: component_unbind_all(dev, drm); gem_destroy: vc4_gem_destroy(drm); + drm_mode_config_cleanup(drm); vc4_bo_cache_destroy(drm); dev_put: drm_dev_put(drm); -- cgit v1.2.3 From 58d043690deb7c145f8a0bd07370dcaefa97a733 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 27 Oct 2020 11:15:58 +0100 Subject: drm/vc4: hdmi: Avoid sleeping in atomic context When running the trigger hook, ALSA by default will take a spinlock, and thus will run the trigger hook in atomic context. However, our HDMI driver will send the infoframes as part of the trigger hook, and part of that process is to wait for a bit to be cleared for up to 100ms. To be nicer to the system, that wait has some usleep_range that interact poorly with the atomic context. There's several ways we can fix this, but the more obvious one is to make ALSA take a mutex instead by setting the nonatomic flag on the DAI link. That doesn't work though, since now the cyclic callback installed by the dmaengine helpers in ALSA will take a mutex, while that callback is run by dmaengine's virt-chan code in a tasklet where sleeping is not allowed either. Given the delay we need to poll the bit for, changing the usleep_range for a udelay and keep running it from a context where interrupts are disabled is not really a good option either. However, we can move the infoframe setup code in the hw_params hook, like is usually done in other HDMI controllers, that isn't protected by a spinlock and thus where we can sleep. Infoframes will be sent on a regular basis anyway, and since hw_params is where the audio parameters that end up in the infoframes are setup, this also makes a bit more sense. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Suggested-by: Mark Brown Signed-off-by: Maxime Ripard Reviewed-by: Mark Brown Reviewed-by: Takashi Iwai Link: https://patchwork.freedesktop.org/patch/msgid/20201027101558.427256-1-maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_hdmi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index e8f99e290655..73ac52714e54 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -922,6 +922,7 @@ static int vc4_hdmi_audio_hw_params(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { struct vc4_hdmi *vc4_hdmi = dai_to_hdmi(dai); + struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base; struct device *dev = &vc4_hdmi->pdev->dev; u32 audio_packet_config, channel_mask; u32 channel_map; @@ -981,6 +982,8 @@ static int vc4_hdmi_audio_hw_params(struct snd_pcm_substream *substream, HDMI_WRITE(HDMI_AUDIO_PACKET_CONFIG, audio_packet_config); vc4_hdmi_set_n_cts(vc4_hdmi); + vc4_hdmi_set_audio_infoframe(encoder); + return 0; } @@ -988,11 +991,9 @@ static int vc4_hdmi_audio_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_dai *dai) { struct vc4_hdmi *vc4_hdmi = dai_to_hdmi(dai); - struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base; switch (cmd) { case SNDRV_PCM_TRIGGER_START: - vc4_hdmi_set_audio_infoframe(encoder); vc4_hdmi->audio.streaming = true; if (vc4_hdmi->variant->phy_rng_enable) -- cgit v1.2.3 From f49a51bfdc8ea717c97ccd4cc98b7e6daaa5553a Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 27 Oct 2020 22:49:22 +0100 Subject: drm/shme-helpers: Fix dma_buf_mmap forwarding bug MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When we forward an mmap to the dma_buf exporter, they get to own everything. Unfortunately drm_gem_mmap_obj() overwrote vma->vm_private_data after the driver callback, wreaking the exporter complete. This was noticed because vb2_common_vm_close blew up on mali gpu with panfrost after commit 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf"). Unfortunately drm_gem_mmap_obj also acquires a surplus reference that we need to drop in shmem helpers, which is a bit of a mislayer situation. Maybe the entire dma_buf_mmap forwarding should be pulled into core gem code. Note that the only two other drivers which forward mmap in their own code (etnaviv and exynos) get this somewhat right by overwriting the gem mmap code. But they seem to still have the leak. This might be a good excuse to move these drivers over to shmem helpers completely. Reviewed-by: Boris Brezillon Acked-by: Christian König Cc: Christian König Cc: Sumit Semwal Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") Cc: Boris Brezillon Cc: Thomas Zimmermann Cc: Gerd Hoffmann Cc: Rob Herring Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: # v5.9+ Reported-and-tested-by: piotr.oniszczuk@gmail.com Cc: piotr.oniszczuk@gmail.com Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201027214922.3566743-1-daniel.vetter@ffwll.ch --- drivers/gpu/drm/drm_gem.c | 4 ++-- drivers/gpu/drm/drm_gem_shmem_helper.c | 7 ++++++- 2 files changed, 8 insertions(+), 3 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 19d73868490e..69c2c079d803 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1085,6 +1085,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, */ drm_gem_object_get(obj); + vma->vm_private_data = obj; + if (obj->funcs && obj->funcs->mmap) { ret = obj->funcs->mmap(obj, vma); if (ret) { @@ -1107,8 +1109,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); } - vma->vm_private_data = obj; - return 0; } EXPORT_SYMBOL(drm_gem_mmap_obj); diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index d77c9f8ff26c..e00616d94f26 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -593,8 +593,13 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) /* Remove the fake offset */ vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node); - if (obj->import_attach) + if (obj->import_attach) { + /* Drop the reference drm_gem_mmap_obj() acquired.*/ + drm_gem_object_put(obj); + vma->vm_private_data = NULL; + return dma_buf_mmap(obj->dma_buf, vma, 0); + } shmem = to_drm_gem_shmem_obj(obj); -- cgit v1.2.3 From a3a0ded3ed38f4eafa86cef61799d50250da4dbe Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 8 Jul 2020 16:45:55 +0200 Subject: drm/vc4: hdmi: Add a name to the codec DAI component Since the components for a given device in ASoC are identified by their name, it makes sense to add one even though it's not strictly necessary. Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20200708144555.718404-1-maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_hdmi.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 73ac52714e54..95779d50cca0 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1077,6 +1077,7 @@ static const struct snd_soc_dapm_route vc4_hdmi_audio_routes[] = { }; static const struct snd_soc_component_driver vc4_hdmi_audio_component_drv = { + .name = "vc4-hdmi-codec-dai-component", .controls = vc4_hdmi_audio_controls, .num_controls = ARRAY_SIZE(vc4_hdmi_audio_controls), .dapm_widgets = vc4_hdmi_audio_widgets, -- cgit v1.2.3 From 5066f42c7d3c7766c16ba6e73da514af04d43ff7 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 28 Oct 2020 13:37:52 +0100 Subject: drm/vc4: Rework the structure conversion functions Most of the helpers to retrieve vc4 structures from the DRM base structures rely on the fact that the first member of the vc4 structure is the DRM one and just cast the pointers between them. However, this is pretty fragile especially since there's no check to make sure that the DRM structure is indeed at the offset 0 in the structure, so let's use container_of to make it more robust. Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20201028123752.1733242-1-maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_drv.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h index 90b911fd2a7f..66d4fb16db8f 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.h +++ b/drivers/gpu/drm/vc4/vc4_drv.h @@ -287,7 +287,7 @@ struct vc4_bo { static inline struct vc4_bo * to_vc4_bo(struct drm_gem_object *bo) { - return (struct vc4_bo *)bo; + return container_of(to_drm_gem_cma_obj(bo), struct vc4_bo, base); } struct vc4_fence { @@ -300,7 +300,7 @@ struct vc4_fence { static inline struct vc4_fence * to_vc4_fence(struct dma_fence *fence) { - return (struct vc4_fence *)fence; + return container_of(fence, struct vc4_fence, base); } struct vc4_seqno_cb { @@ -347,7 +347,7 @@ struct vc4_plane { static inline struct vc4_plane * to_vc4_plane(struct drm_plane *plane) { - return (struct vc4_plane *)plane; + return container_of(plane, struct vc4_plane, base); } enum vc4_scaling_mode { @@ -423,7 +423,7 @@ struct vc4_plane_state { static inline struct vc4_plane_state * to_vc4_plane_state(struct drm_plane_state *state) { - return (struct vc4_plane_state *)state; + return container_of(state, struct vc4_plane_state, base); } enum vc4_encoder_type { @@ -499,7 +499,7 @@ struct vc4_crtc { static inline struct vc4_crtc * to_vc4_crtc(struct drm_crtc *crtc) { - return (struct vc4_crtc *)crtc; + return container_of(crtc, struct vc4_crtc, base); } static inline const struct vc4_crtc_data * @@ -537,7 +537,7 @@ struct vc4_crtc_state { static inline struct vc4_crtc_state * to_vc4_crtc_state(struct drm_crtc_state *crtc_state) { - return (struct vc4_crtc_state *)crtc_state; + return container_of(crtc_state, struct vc4_crtc_state, base); } #define V3D_READ(offset) readl(vc4->v3d->regs + offset) -- cgit v1.2.3