Re: [RFC 10/28] drm: rcar-du: of: Increase buff size for compatible variable
Hi Laurent,
On Sun, Jan 23, 2022 at 2:52 PM Laurent Pinchart
wrote:
> On Fri, Jan 14, 2022 at 11:17:19AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Jan 12, 2022 at 6:46 PM Biju Das wrote:
> > > Increase buff size for compatible variable to avoid stack corruption
> > > with RZ/G2L SoC's(renesas,du-r9a07g044l) which requires a buff size
> > > more than the current allocated size.
> > >
> > > Signed-off-by: Biju Das
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > > @@ -200,7 +200,7 @@ static void __init rcar_du_of_lvds_patch(const struct
> > > of_device_id *of_ids)
> > > struct device_node *lvds_node;
> > > struct device_node *soc_node;
> > > struct device_node *du_node;
> > > - char compatible[22];
> > > + char compatible[24];
> > > const char *soc_name;
> > > unsigned int i;
> > > int ret;
> >
> > What about changing the code to use kasprintf() instead, to prevent
> > this from ever happening again?
>
> Or maybe it's time to drop this backward compatibility code altogether ?
The last R-Car Gen2 DTS was converted in commit edb0c3affe5214a2
("ARM: dts: r8a7793: Convert to new LVDS DT bindings") in v4.17.
The last RZ/G1 DTS was converted in commit 6a6a797625b5fe85 ("ARM:
dts: r8a7743: Convert to new LVDS DT bindings") in v5.0.
Both are older than commit 58256143cff7c2e0 ("clk: renesas: Remove
R-Car Gen2 legacy DT clock support") in v5.5, so I'd say let's get
rid of it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 02/16] drm/edid: Don't clear formats if using deep color
On Thu, Jan 20, 2022 at 04:16:11PM +0100, Maxime Ripard wrote:
> The current code, when parsing the EDID Deep Color depths, that the
> YUV422 cannot be used, referring to the HDMI 1.3 Specification.
>
> This specification, in its section 6.2.4, indeed states:
>
> For each supported Deep Color mode, RGB 4:4:4 shall be supported and
> optionally YCBCR 4:4:4 may be supported.
>
> YCBCR 4:2:2 is not permitted for any Deep Color mode.
>
> This indeed can be interpreted like the code does, but the HDMI 1.4
> specification further clarifies that statement in its section 6.2.4:
>
> For each supported Deep Color mode, RGB 4:4:4 shall be supported and
> optionally YCBCR 4:4:4 may be supported.
>
> YCBCR 4:2:2 is also 36-bit mode but does not require the further use
> of the Deep Color modes described in section 6.5.2 and 6.5.3.
>
> This means that, even though YUV422 can be used with 12 bit per color,
> it shouldn't be treated as a deep color mode.
>
> This is also broken with YUV444 if it's supported by the display, but
> DRM_EDID_HDMI_DC_Y444 isn't set. In such a case, the code will clear
> color_formats of the YUV444 support set previously in
> drm_parse_cea_ext(), but will not set it back.
>
> Since the formats supported are already setup properly in
> drm_parse_cea_ext(), let's just remove the code modifying the formats in
> drm_parse_hdmi_deep_color_info()
>
> Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
> Signed-off-by: Maxime Ripard
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 13644dd579b4..5085ef08c22d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5104,16 +5104,8 @@ static void drm_parse_hdmi_deep_color_info(struct
> drm_connector *connector,
> connector->name, dc_bpc);
> info->bpc = dc_bpc;
>
> - /*
> - * Deep color support mandates RGB444 support for all video
> - * modes and forbids YCRCB422 support for all video modes per
> - * HDMI 1.3 spec.
> - */
> - info->color_formats = DRM_COLOR_FORMAT_RGB444;
> -
> /* YCRCB444 is optional according to spec. */
> if (hdmi[6] & DRM_EDID_HDMI_DC_Y444) {
> - info->color_formats |= DRM_COLOR_FORMAT_YCRCB444;
> DRM_DEBUG("%s: HDMI sink does YCRCB444 in deep color.\n",
> connector->name);
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [PATCH v4 03/16] drm/edid: Split deep color modes between RGB and YUV444
On Thu, Jan 20, 2022 at 04:16:12PM +0100, Maxime Ripard wrote:
> The current code assumes that the RGB444 and YUV444 formats are the
> same, but the HDMI 2.0 specification states that:
>
>The three DC_XXbit bits above only indicate support for RGB 4:4:4 at
>that pixel size. Support for YCBCR 4:4:4 in Deep Color modes is
>indicated with the DC_Y444 bit. If DC_Y444 is set, then YCBCR 4:4:4
>is supported for all modes indicated by the DC_XXbit flags.
>
> So if we have YUV444 support and any DC_XXbit flag set but the DC_Y444
> flag isn't, we'll assume that we support that deep colour mode for
> YUV444 which breaks the specification.
>
> In order to fix this, let's split the edid_hdmi_dc_modes field in struct
> drm_display_info into two fields, one for RGB444 and one for YUV444.
>
> Suggested-by: Ville Syrjälä
> Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
> Signed-off-by: Maxime Ripard
Reviewed-by: Ville Syrjälä
Though we seem to be missing clearing of *dc_modes in
drm_reset_display_info()...
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
> drivers/gpu/drm/drm_edid.c | 7 ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++--
> drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
> include/drm/drm_connector.h| 12 +---
> 5 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index c16a2704ced6..f3160b951df3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -175,7 +175,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
>
> /* Check if bpc is within clock limit. Try to degrade
> gracefully otherwise */
> if ((bpc == 12) && (mode_clock * 3/2 > max_tmds_clock))
> {
> - if ((connector->display_info.edid_hdmi_dc_modes
> & DRM_EDID_HDMI_DC_30) &&
> + if
> ((connector->display_info.edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30) &&
> (mode_clock * 5/4 <= max_tmds_clock))
> bpc = 10;
> else
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5085ef08c22d..471b577dca79 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5075,21 +5075,21 @@ static void drm_parse_hdmi_deep_color_info(struct
> drm_connector *connector,
>
> if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
> dc_bpc = 10;
> - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_30;
> + info->edid_hdmi_rgb444_dc_modes |= DRM_EDID_HDMI_DC_30;
> DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
> connector->name);
> }
>
> if (hdmi[6] & DRM_EDID_HDMI_DC_36) {
> dc_bpc = 12;
> - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_36;
> + info->edid_hdmi_rgb444_dc_modes |= DRM_EDID_HDMI_DC_36;
> DRM_DEBUG("%s: HDMI sink does deep color 36.\n",
> connector->name);
> }
>
> if (hdmi[6] & DRM_EDID_HDMI_DC_48) {
> dc_bpc = 16;
> - info->edid_hdmi_dc_modes |= DRM_EDID_HDMI_DC_48;
> + info->edid_hdmi_rgb444_dc_modes |= DRM_EDID_HDMI_DC_48;
> DRM_DEBUG("%s: HDMI sink does deep color 48.\n",
> connector->name);
> }
> @@ -5106,6 +5106,7 @@ static void drm_parse_hdmi_deep_color_info(struct
> drm_connector *connector,
>
> /* YCRCB444 is optional according to spec. */
> if (hdmi[6] & DRM_EDID_HDMI_DC_Y444) {
> + info->edid_hdmi_ycbcr444_dc_modes =
> info->edid_hdmi_rgb444_dc_modes;
> DRM_DEBUG("%s: HDMI sink does YCRCB444 in deep color.\n",
> connector->name);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 96e508ddc4af..52f6dc248453 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1912,7 +1912,7 @@ static bool intel_hdmi_sink_bpc_possible(struct
> drm_connector *connector,
> if (ycbcr420_output)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36;
> else
> - return info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36;
> + return info->edid_hdmi_rgb444_dc_modes &
> DRM_EDID_HDMI_DC_36;
> case 10:
> if (!has_hdmi_sink)
> return false;
> @@ -1920,7 +1920,7 @@ static bool intel_hdmi_sink_bpc_possible(struct
> drm_connector *connector,
> if (ycbcr420_output)
> return hdmi
[PATCH v2] drm/i915: fix header file inclusion for might_alloc()
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prdouces the following error:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bind_dep_await’:
drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration of
function ‘might_alloc’; did you mean ‘might_lock’?
[-Werror=implicit-function-declaration]
381 | might_alloc(gfp);
| ^~~
| might_lock
Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Signed-off-by: Andi Shyti
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
Hi,
in V2 I just added the Fixes tag (I think I got the right commit)
and added Thomas r-b.
Andi
drivers/gpu/drm/i915/i915_vma_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c
b/drivers/gpu/drm/i915/i915_vma_resource.c
index 1f41c0c699eb..bbb0ff14272f 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.c
+++ b/drivers/gpu/drm/i915/i915_vma_resource.c
@@ -4,7 +4,7 @@
*/
#include
-#include
+#include
#include "i915_sw_fence.h"
#include "i915_vma_resource.h"
--
2.34.1
Re: [PATCH v4 04/16] drm/connector: Fix typo in output format
On Thu, Jan 20, 2022 at 04:16:13PM +0100, Maxime Ripard wrote:
> The HDMI specification mentions YCbCr everywhere, but our enums have
> YCrCb. Let's rename it to match.
I think the CrCb nonsense came from the EDID spec. Though IIRC
it used both CbCr and CrCb terminology in different places.
Either way I think using the standard CbCr order makes sense.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Maxime Ripard
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> .../drm/arm/display/komeda/d71/d71_component.c | 12 ++--
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> .../gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
> .../drm/bridge/cadence/cdns-mhdp8546-core.c| 18 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 16
> drivers/gpu/drm/drm_edid.c | 16
> .../gpu/drm/rockchip/analogix_dp-rockchip.c| 2 +-
> include/drm/drm_connector.h| 6 +++---
> 9 files changed, 39 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8a46b8430f1e..7963421fd42d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5852,7 +5852,7 @@ static void
> fill_stream_properties_from_drm_display_mode(
> else if (drm_mode_is_420_also(info, mode_in)
> && aconnector->force_yuv420_output)
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
> - else if ((connector->display_info.color_formats &
> DRM_COLOR_FORMAT_YCRCB444)
> + else if ((connector->display_info.color_formats &
> DRM_COLOR_FORMAT_YCBCR444)
> && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
> else
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index 8a02ade369db..42510fdea27e 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -1078,11 +1078,11 @@ static void d71_improc_update(struct komeda_component
> *c,
> mask |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420;
>
> /* config color format */
> - if (st->color_format == DRM_COLOR_FORMAT_YCRCB420)
> + if (st->color_format == DRM_COLOR_FORMAT_YCBCR420)
> ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420;
> - else if (st->color_format == DRM_COLOR_FORMAT_YCRCB422)
> + else if (st->color_format == DRM_COLOR_FORMAT_YCBCR422)
> ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422;
> - else if (st->color_format == DRM_COLOR_FORMAT_YCRCB444)
> + else if (st->color_format == DRM_COLOR_FORMAT_YCBCR444)
> ctrl |= IPS_CTRL_YUV;
>
> malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
> @@ -1144,11 +1144,11 @@ static int d71_improc_init(struct d71_dev *d71,
> improc = to_improc(c);
> improc->supported_color_depths = BIT(8) | BIT(10);
> improc->supported_color_formats = DRM_COLOR_FORMAT_RGB444 |
> - DRM_COLOR_FORMAT_YCRCB444 |
> - DRM_COLOR_FORMAT_YCRCB422;
> + DRM_COLOR_FORMAT_YCBCR444 |
> + DRM_COLOR_FORMAT_YCBCR422;
> value = malidp_read32(reg, BLK_INFO);
> if (value & IPS_INFO_CHD420)
> - improc->supported_color_formats |= DRM_COLOR_FORMAT_YCRCB420;
> + improc->supported_color_formats |= DRM_COLOR_FORMAT_YCBCR420;
>
> improc->supports_csc = true;
> improc->supports_gamma = true;
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index f8e5da148599..a694988d991d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -223,7 +223,7 @@ static void adv7511_set_config_csc(struct adv7511
> *adv7511,
> config.csc_coefficents = adv7511_csc_ycbcr_to_rgb;
>
> if ((connector->display_info.color_formats &
> - DRM_COLOR_FORMAT_YCRCB422) &&
> + DRM_COLOR_FORMAT_YCBCR422) &&
> config.hdmi_mode) {
> config.csc_enable = false;
> config.avi_infoframe.colorspace =
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index b7d2e4449cfa..eb590fb8e8d0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1537,9 +1537,9 @@ static void analogix_dp_bridge_mode_set(struct
> drm_bridge *bridge,
> video->color_depth
Re: [PATCH] drm/i915: fix header file inclusion for might_alloc()
Hi Am 24.01.22 um 02:08 schrieb Andi Shyti: Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion as the first is not required, while the second, if not included, prdouces the following error: 'produces' drivers/gpu/drm/i915/i915_vma_resource.c: In function ‘i915_vma_resource_bind_dep_await’: drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration of function ‘might_alloc’; did you mean ‘might_lock’? [-Werror=implicit-function-declaration] 381 | might_alloc(gfp); | ^~~ | might_lock Signed-off-by: Andi Shyti Cc: Thomas Hellström --- drivers/gpu/drm/i915/i915_vma_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c b/drivers/gpu/drm/i915/i915_vma_resource.c index 1f41c0c699eb..bbb0ff14272f 100644 --- a/drivers/gpu/drm/i915/i915_vma_resource.c +++ b/drivers/gpu/drm/i915/i915_vma_resource.c @@ -4,7 +4,7 @@ */ #include -#include +#include #include "i915_sw_fence.h" #include "i915_vma_resource.h" -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[PATCH v2] drm/i915: fix header file inclusion for might_alloc()
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prdouces the following error:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bind_dep_await’:
drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration of
function ‘might_alloc’; did you mean ‘might_lock’?
[-Werror=implicit-function-declaration]
381 | might_alloc(gfp);
| ^~~
| might_lock
Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Signed-off-by: Andi Shyti
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
Hi,
in V2 I just added the Fixes tag (I think I got the right commit)
and added Thomas r-b.
Andi
drivers/gpu/drm/i915/i915_vma_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c
b/drivers/gpu/drm/i915/i915_vma_resource.c
index 1f41c0c699eb..bbb0ff14272f 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.c
+++ b/drivers/gpu/drm/i915/i915_vma_resource.c
@@ -4,7 +4,7 @@
*/
#include
-#include
+#include
#include "i915_sw_fence.h"
#include "i915_vma_resource.h"
--
2.34.1
[PATCH v3] drm/i915: fix header file inclusion for might_alloc()
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prodouces the following error:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bind_dep_await’:
drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration of
function ‘might_alloc’; did you mean ‘might_lock’?
[-Werror=implicit-function-declaration]
381 | might_alloc(gfp);
| ^~~
| might_lock
Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Signed-off-by: Andi Shyti
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
Hi,
v3: fixed a typo in the commit log (prduces/produces). (Thanks
Thomas Zimmermann)
v2: added the 'Fixes' tag (I think I got the right commit) and
Thomas Hellström r-b.
Andi
drivers/gpu/drm/i915/i915_vma_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c
b/drivers/gpu/drm/i915/i915_vma_resource.c
index 1f41c0c699eb..bbb0ff14272f 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.c
+++ b/drivers/gpu/drm/i915/i915_vma_resource.c
@@ -4,7 +4,7 @@
*/
#include
-#include
+#include
#include "i915_sw_fence.h"
#include "i915_vma_resource.h"
--
2.34.1
Re: [PATCH v2] drm/i915: fix header file inclusion for might_alloc()
Sorry for spamming! Just called the command from the history
On Mon, Jan 24, 2022 at 11:42:43AM +0200, Andi Shyti wrote:
> Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
> as the first is not required, while the second, if not included,
> prdouces the following error:
>
> drivers/gpu/drm/i915/i915_vma_resource.c: In function
> ‘i915_vma_resource_bind_dep_await’:
> drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration
> of function ‘might_alloc’; did you mean ‘might_lock’?
> [-Werror=implicit-function-declaration]
> 381 | might_alloc(gfp);
> | ^~~
> | might_lock
>
> Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
> Signed-off-by: Andi Shyti
> Cc: Thomas Hellström
> Reviewed-by: Thomas Hellström
> ---
> Hi,
>
> in V2 I just added the Fixes tag (I think I got the right commit)
> and added Thomas r-b.
>
> Andi
>
> drivers/gpu/drm/i915/i915_vma_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c
> b/drivers/gpu/drm/i915/i915_vma_resource.c
> index 1f41c0c699eb..bbb0ff14272f 100644
> --- a/drivers/gpu/drm/i915/i915_vma_resource.c
> +++ b/drivers/gpu/drm/i915/i915_vma_resource.c
> @@ -4,7 +4,7 @@
> */
>
> #include
> -#include
> +#include
>
> #include "i915_sw_fence.h"
> #include "i915_vma_resource.h"
> --
> 2.34.1
Re: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
On 1/23/22 23:30, Wei Liu wrote:
> On Sun, Jan 23, 2022 at 10:27:56PM +, Michael Kelley (LINUX) wrote:
>> From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
>>>
>>> On Sun, Jan 16, 2022 at 09:53:06PM +, Haiyang Zhang wrote:
> -Original Message-
> From: Michael Kelley (LINUX)
> Sent: Sunday, January 16, 2022 2:19 PM
> To: KY Srinivasan ; Haiyang Zhang
>>> ; Stephen
> Hemminger ; wei@kernel.org; Wei Hu
>>> ; Dexuan
> Cui ; drawat.fl...@gmail.com; hhei ;
>>> linux-
> ker...@vger.kernel.org; linux-hyp...@vger.kernel.org; linux-
>>> fb...@vger.kernel.org; dri-
> de...@lists.freedesktop.org
> Cc: Michael Kelley (LINUX)
> Subject: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
>
> In the WIN10 version of the Synthetic Video protocol with Hyper-V,
> Hyper-V reports a list of supported resolutions as part of the protocol
> negotiation. The driver calculates the maximum width and height from
> the list of resolutions, and uses those maximums to validate any screen
> resolution specified in the video= option on the kernel boot line.
>
> This method of validation is incorrect. For example, the list of
> supported resolutions could contain 1600x1200 and 1920x1080, both of
> which fit in an 8 Mbyte frame buffer. But calculating the max width
> and height yields 1920 and 1200, and 1920x1200 resolution does not fit
> in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted,
> causing a kernel fault when the driver accesses memory outside the
> frame buffer.
>
> Instead, validate the specified screen resolution by calculating
> its size, and comparing against the frame buffer size. Delete the
> code for calculating the max width and height from the list of
> resolutions, since these max values have no use. Also add the
> frame buffer size to the info message to aid in understanding why
> a resolution might be rejected.
>
> Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen resolution
> from Hyper-V
> host")
> Signed-off-by: Michael Kelley
>>> [...]
Reviewed-by: Haiyang Zhang
>>>
>>> Applied to hyperv-fixes. Thanks.
>>
>> This fix got pulled into the fbdev/for-next tree by a new maintainer, Helge
>> Deller.
>> See
>> https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=bcc48f8d980b12e66a3d59dfa1041667db971d86
>
> OK. I will drop it from hyperv-fixes. Thanks for letting me know!
Linus hasn't pulled my tree yet, and he will probably not before the
next merge window. So, if this is an urgent bugfix for you, I can offer
to drop it from the fbdev tree and that you take it through the hyperv-fixes
tree.
In that case you may add an Acked-by: Helge Deller .
Just let me know what you prefer.
Helge
RE: [PATCH v4 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API
Hi Christoph and Jason: Have been talking with Raj. I am going to work on this series this week. Thanks, Zhi. -Original Message- From: Christoph Hellwig Sent: Monday, January 24, 2022 11:40 AM To: Wang, Zhi A Cc: Christoph Hellwig ; Zhi Wang ; intel-...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Jason Gunthorpe ; Jani Nikula ; Joonas Lahtinen ; Vivi, Rodrigo ; Zhenyu Wang ; Xu, Terrence Subject: Re: [PATCH v4 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API On Fri, Dec 17, 2021 at 08:52:53AM +, Wang, Zhi A wrote: > Sorry for the late reply as I am supporting the customers recently. I > will refresh this after the christmas. Did you find some time to look into it? Do you want some help?
[PATCH] drm/i915/selftests: make static read-only array page_count const
The static array page_count is read-only so it make sense to make
it const.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/scatterlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/scatterlist.c
b/drivers/gpu/drm/i915/selftests/scatterlist.c
index d599186d5b71..a4f2fbb451e2 100644
--- a/drivers/gpu/drm/i915/selftests/scatterlist.c
+++ b/drivers/gpu/drm/i915/selftests/scatterlist.c
@@ -195,7 +195,7 @@ static unsigned int random_page_size_pages(unsigned long n,
struct rnd_state *rnd)
{
/* 4K, 64K, 2M */
- static unsigned int page_count[] = {
+ static const unsigned int page_count[] = {
BIT(12) >> PAGE_SHIFT,
BIT(16) >> PAGE_SHIFT,
BIT(21) >> PAGE_SHIFT,
--
2.33.1
[PATCH] drm/imx: make static read-only array channel_offsets const
The static array channel_offsets is read-only so it make sense to make
it const.
Signed-off-by: Colin Ian King
---
drivers/gpu/ipu-v3/ipu-dc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index ca96b235491a..b038a6d7307b 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -344,8 +344,9 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base, unsigned long template_base)
{
struct ipu_dc_priv *priv;
- static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c,
- 0x78, 0, 0x94, 0xb4};
+ static const int channel_offsets[] = {
+ 0, 0x1c, 0x38, 0x54, 0x58, 0x5c, 0x78, 0, 0x94, 0xb4
+ };
int i;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
--
2.33.1
[PATCH 0/5] spi: make remove callback a void function
Hello,
this series goal is to change the spi remove callback's return value to void.
After numerous patches nearly all drivers already return 0 unconditionally.
The four first patches in this series convert the remaining three drivers to
return 0, the final patch changes the remove prototype and converts all
implementers.
The driver core doesn't support error handling on remove, the spi core issues
only a very generic warning when a remove callback returns an error. If there
is really the need for a function call that can fail, the driver can issue a
more helpful error message. I didn't find a single driver where returning
an error code and error handling in the spi core would have been helpful.
So change the prototype of the remove function to make it obvious for driver
authors that there is no error handling in the spi core.
The four preparatory patches were already send out, but not yet taken into
next.
Assuming Mark is fine with this change I'd like to have this go in during the
next merge window. I guess we need a tag that can be pulled into trees that add
a new driver in the next cycle. I can provide such a tag, but I'm open to
alternatives.
The patch set survived an allmodconfig build on various archs (arm64 m68k
powerpc riscv s390 sparc64 x86_64) after the following two commits from
next-20220121 were added to fix an unrelated build problem:
be973481daaa ("pinctrl: thunderbay: rework loops looking for groups
names")
8687999e47d4 ("pinctrl: thunderbay: comment process of building
functions a bit")
Best regards
Uwe
Uwe Kleine-König (5):
staging: fbtft: Fix error path in fbtft_driver_module_init()
staging: fbtft: Deduplicate driver registration macros
tpm: st33zp24: Make st33zp24_remove() a void function
platform/chrome: cros_ec: Make cros_ec_unregister() return void
spi: make remove callback a void function
drivers/bus/moxtet.c | 4 +-
drivers/char/tpm/st33zp24/i2c.c | 5 +-
drivers/char/tpm/st33zp24/spi.c | 9 +-
drivers/char/tpm/st33zp24/st33zp24.c | 3 +-
drivers/char/tpm/st33zp24/st33zp24.h | 2 +-
drivers/char/tpm/tpm_tis_spi_main.c | 3 +-
drivers/clk/clk-lmk04832.c| 4 +-
drivers/gpio/gpio-74x164.c| 4 +-
drivers/gpio/gpio-max3191x.c | 4 +-
drivers/gpio/gpio-max7301.c | 4 +-
drivers/gpio/gpio-mc33880.c | 4 +-
drivers/gpio/gpio-pisosr.c| 4 +-
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 +-
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 4 +-
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 3 +-
drivers/gpu/drm/panel/panel-innolux-ej030na.c | 4 +-
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 4 +-
drivers/gpu/drm/panel/panel-lg-lg4573.c | 4 +-
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 4 +-
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 4 +-
drivers/gpu/drm/panel/panel-samsung-db7430.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 4 +-
drivers/gpu/drm/panel/panel-samsung-s6d27a1.c | 3 +-
.../gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 3 +-
.../gpu/drm/panel/panel-sitronix-st7789v.c| 4 +-
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 4 +-
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 4 +-
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 4 +-
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 3 +-
.../gpu/drm/panel/panel-widechips-ws2401.c| 3 +-
drivers/gpu/drm/tiny/hx8357d.c| 4 +-
drivers/gpu/drm/tiny/ili9163.c| 4 +-
drivers/gpu/drm/tiny/ili9225.c| 4 +-
drivers/gpu/drm/tiny/ili9341.c| 4 +-
drivers/gpu/drm/tiny/ili9486.c| 4 +-
drivers/gpu/drm/tiny/mi0283qt.c | 4 +-
drivers/gpu/drm/tiny/repaper.c| 4 +-
drivers/gpu/drm/tiny/st7586.c | 4 +-
drivers/gpu/drm/tiny/st7735r.c| 4 +-
drivers/hwmon/adcxx.c | 4 +-
drivers/hwmon/adt7310.c | 3 +-
drivers/hwmon/max.c | 3 +-
drivers/hwmon/max31722.c | 4 +-
drivers/iio/accel/bma400_spi.c| 4 +-
drivers/iio/accel/bmc150-accel-spi.c | 4 +-
drivers/iio/accel/bmi088-accel-spi.c | 4 +-
drivers/iio/accel/kxsd9-spi.c | 4 +-
drivers/iio/accel/mma7455_spi.c | 4 +-
drivers/iio/accel/sca3000.c | 4 +-
drivers/iio/adc/ad7266.c | 4 +-
drivers/iio/adc/ltc2496.c | 4 +-
drivers/iio/adc/mcp320x.c | 4 +-
drivers/iio/adc/mcp3911.c | 4 +-
drivers/iio/adc/ti-adc12138.c | 4 +-
drivers/iio/adc/ti-ads7950.c | 4 +-
drivers/iio/adc/ti-ads8688.c | 4 +-
drivers/iio/adc/ti-tlc4541.c
[PATCH 5/5] spi: make remove callback a void function
The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König --- drivers/bus/moxtet.c | 4 +--- drivers/char/tpm/st33zp24/spi.c | 4 +--- drivers/char/tpm/tpm_tis_spi_main.c | 3 +-- drivers/clk/clk-lmk04832.c| 4 +--- drivers/gpio/gpio-74x164.c| 4 +--- drivers/gpio/gpio-max3191x.c | 4 +--- drivers/gpio/gpio-max7301.c | 4 +--- drivers/gpio/gpio-mc33880.c | 4 +--- drivers/gpio/gpio-pisosr.c| 4 +--- drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 +--- drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 4 +--- drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 3 +-- drivers/gpu/drm/panel/panel-innolux-ej030na.c | 4 +--- drivers/gpu/drm/panel/panel-lg-lb035q02.c | 4 +--- drivers/gpu/drm/panel/panel-lg-lg4573.c | 4 +--- drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 4 +--- drivers/gpu/drm/panel/panel-novatek-nt39016.c | 4 +--- drivers/gpu/drm/panel/panel-samsung-db7430.c | 3 +-- drivers/gpu/drm/panel/panel-samsung-ld9040.c | 4 +--- drivers/gpu/drm/panel/panel-samsung-s6d27a1.c | 3 +-- drivers/gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 3 +-- drivers/gpu/drm/panel/panel-sitronix-st7789v.c| 4 +--- drivers/gpu/drm/panel/panel-sony-acx565akm.c | 4 +--- drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 4 +--- drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 4 +--- drivers/gpu/drm/panel/panel-tpo-tpg110.c | 3 +-- drivers/gpu/drm/panel/panel-widechips-ws2401.c| 3 +-- drivers/gpu/drm/tiny/hx8357d.c| 4 +--- drivers/gpu/drm/tiny/ili9163.c| 4 +--- drivers/gpu/drm/tiny/ili9225.c| 4 +--- drivers/gpu/drm/tiny/ili9341.c| 4 +--- drivers/gpu/drm/tiny/ili9486.c| 4 +--- drivers/gpu/drm/tiny/mi0283qt.c | 4 +--- drivers/gpu/drm/tiny/repaper.c| 4 +--- drivers/gpu/drm/tiny/st7586.c | 4 +--- drivers/gpu/drm/tiny/st7735r.c| 4 +--- drivers/hwmon/adcxx.c | 4 +--- drivers/hwmon/adt7310.c | 3 +-- drivers/hwmon/max.c | 3 +-- drivers/hwmon/max31722.c | 4 +--- drivers/iio/accel/bma400_spi.c| 4 +--- drivers/iio/accel/bmc150-accel-spi.c | 4 +--- drivers/iio/accel/bmi088-accel-spi.c | 4 +--- drivers/iio/accel/kxsd9-spi.c | 4 +--- drivers/iio/accel/mma7455_spi.c | 4 +--- drivers/iio/accel/sca3000.c | 4 +--- drivers/iio/adc/ad7266.c | 4 +--- drivers/iio/adc/ltc2496.c | 4 +--- drivers/iio/adc/mcp320x.c | 4 +--- drivers/iio/adc/mcp3911.c | 4 +--- drivers/iio/adc/ti-adc12138.c | 4 +--- drivers/iio/adc/ti-ads7950.c | 4 +--- drivers/iio/adc/ti-ads8688.c | 4 +--- drivers/iio/adc/ti-tlc4541.c | 4 +--- drivers/iio/amplifiers/ad8366.c | 4 +--- drivers/iio/common/ssp_sensors/ssp_dev.c | 4 +--- drivers/iio/dac/ad5360.c | 4 +--- drivers/iio/dac/ad5380.c | 4 +--- drivers/iio/dac/ad5446.c | 4 +--- drivers/iio/dac/ad5449.c | 4 +--- drivers/iio/dac/ad5504.c | 4 +--- drivers/iio/dac/ad5592r.c | 4 +--- drivers/iio/dac/ad5624r_spi.c | 4 +--- drivers/iio/dac/ad5686-spi.c | 4 +--- drivers/iio/dac/ad5761.c | 4 +--- drivers/iio/dac/ad5764.c | 4 +--- drivers/iio/dac/ad5791.c | 4 +--- drivers/iio/dac/ad8801.c | 4 +--- drivers/iio/dac/ltc1660.c | 4 +--- drivers/iio/dac/ltc263
Re: [PATCH 24/31] video: backlight: changing LED_* from enum led_brightness to actual value
On Fri, 21 Jan 2022, Luiz Sampaio wrote: > Hello, Daniel > > Thanks for your reply. This is one of my first patches, so I am still > learning. This series of patches affects others subsystems too (hid, > leds, sound etc). Should I create series for each subsystem > separately, instead of creating one series for everyone? > What do you mean by "this patch might wants to land in one tree"? Can the individual patches be applied on their own without causing issues (warnings/errors) with the build? If so, they can be applied separately via their associated subsystem trees. If not, someone will have to collect them all and take them via a single tree with Acks from the other subsystem maintainers. It's difficult to make that decision for ourselves since you didn't share all of the patches with all of the maintainers. -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
On 1/21/22 08:20, Gerd Hoffmann wrote: >>> So if this really has to come back then I think the pragmatic approach is >>> to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning >>> that enabling that shouldn't be done for any distro which only enables >>> firmware and drm fbdev drivers. >> >> Thanks for coming back on this, but quite frankly I don't understand >> that request. How should that warning look like, something along: >> "BE WARNED: The framebuffer text console on your non-DRM supported >> graphic card will then run faster and smoother if you enable this option." >> That doesn't make sense. People and distros would want to enable that. > > Nope. Most distros want disable fbdev drivers rather sooner than later. > The fbdev drivers enabled in the fedora kernel today: > > CONFIG_FB_VGA16=m > CONFIG_FB_VESA=y > CONFIG_FB_EFI=y > CONFIG_FB_SSD1307=m > > CONFIG_FB_VESA + CONFIG_FB_EFI will go away soon, with simpledrm taking > over their role. That's Ok. Nevertheless, some distros and platforms will still need fbdev drivers for various reasons. >> And if a distro *just* has firmware and drm fbdev drivers enabled, >> none of the non-DRM graphic cards would be loaded anyway and this code >> wouldn't be executed anyway. > > Yes, exactly. That's why there is no point in compiling that code. As long as you have a graphic card which is not supported by DRM you still need it. Here is my proposed way forward: a) I will resend the patches which reverts the remove-fbcon-hardware-scolling patches to the mailing lists. I'll adjust the stable tags and update the commit messages. b) Then after some days I'll include it in the fbdev for-next git branch. That way it's included in the various build & test chains. c) If everything is working well, I'll push that change during the next merge window for kernel 5.18. If problems arise we will need to discuss. While the patches are in the fbdev git tree we should decide how to exclude code which is not needed for DRM. What about this proposal: a) adding a Kconfig option like: CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only this should be disabled. b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig files. c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in fbcon which isn't needed by DRM. Thoughts? Helge
Re: [PATCH v3 2/3] drm/msm/dpu: simplify clocks handling
On Fri, 21 Jan 2022 at 23:44, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-01-20 23:37:45)
> > On Fri, 21 Jan 2022 at 07:30, Stephen Boyd wrote:
> > >
> > > Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> > > > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > > > b/drivers/gpu/drm/msm/msm_io_utils.c
> > > > index 7b504617833a..5533c87c7158 100644
> > > > --- a/drivers/gpu/drm/msm/msm_io_utils.c
> > > > +++ b/drivers/gpu/drm/msm/msm_io_utils.c
> >
> > >
> > > > + if (rc) {
> > > > + DRM_DEV_ERROR(&pdev->dev, "Failed to get clock refs
> > > > %d\n", rc);
> > > > + return rc;
> > > > + }
> > > > +
> > > > + rc = of_clk_set_defaults(pdev->dev.of_node, false);
> > >
> > > Why is this needed?
> >
> > Both mdss and mdp devices use assigned-clocks properties, while not
> > being a clock provider (or a child of it).
> > So I assumed it should call the of_clk_set_defaults(node, false)
>
> A device node doesn't need to be a clk provider to call
> of_clk_set_defaults(). Does the call to of_clk_set_defaults() in
> drivers/base/platform.c cover this?
I'll check if it does.
>
> > Not to mention that this call exists in the msm_dss_parse_clock(),
> > which is being refactored/replaced.
> >
>
> Indeed it's already in the code.
>
> > >
> > > > + if (rc) {
> > > > + DRM_DEV_ERROR(&pdev->dev, "Failed to set clock defaults
> > > > %d\n", rc);
> > > > + return rc;
> > > > + }
> > > > +
> > > > + *clocks = bulk;
> > > > +
--
With best wishes
Dmitry
Re: [Intel-gfx] [PATCH v3] drm/i915: fix header file inclusion for might_alloc()
Op 24-01-2022 om 10:44 schreef Andi Shyti:
> Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
> as the first is not required, while the second, if not included,
> prodouces the following error:
>
> drivers/gpu/drm/i915/i915_vma_resource.c: In function
> ‘i915_vma_resource_bind_dep_await’:
> drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration
> of function ‘might_alloc’; did you mean ‘might_lock’?
> [-Werror=implicit-function-declaration]
> 381 | might_alloc(gfp);
> | ^~~
> | might_lock
>
> Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
> Signed-off-by: Andi Shyti
> Cc: Thomas Hellström
> Reviewed-by: Thomas Hellström
> ---
> Hi,
>
> v3: fixed a typo in the commit log (prduces/produces). (Thanks
> Thomas Zimmermann)
>
> v2: added the 'Fixes' tag (I think I got the right commit) and
> Thomas Hellström r-b.
>
> Andi
>
> drivers/gpu/drm/i915/i915_vma_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c
> b/drivers/gpu/drm/i915/i915_vma_resource.c
> index 1f41c0c699eb..bbb0ff14272f 100644
> --- a/drivers/gpu/drm/i915/i915_vma_resource.c
> +++ b/drivers/gpu/drm/i915/i915_vma_resource.c
> @@ -4,7 +4,7 @@
> */
>
> #include
> -#include
> +#include
>
> #include "i915_sw_fence.h"
> #include "i915_vma_resource.h"
Pushed to drm-intel-gt-next. Should fix drm-tip building, probably needs to be
pulled into drm-fixes asap. :)
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
[snip] > > What about this proposal: > a) adding a Kconfig option like: >CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only > this should be disabled. > b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig > files. > c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in > fbcon which >isn't needed by DRM. > I proposed something similar in: https://lore.kernel.org/lkml/20210827100027.1577561-1-javi...@redhat.com/t/ Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Hi Am 24.01.22 um 12:10 schrieb Helge Deller: [...] Here is my proposed way forward: a) I will resend the patches which reverts the remove-fbcon-hardware-scolling patches to the mailing lists. I'll adjust the stable tags and update the commit messages. b) Then after some days I'll include it in the fbdev for-next git branch. That way it's included in the various build & test chains. c) If everything is working well, I'll push that change during the next merge window for kernel 5.18. If problems arise we will need to discuss. While the patches are in the fbdev git tree we should decide how to exclude code which is not needed for DRM. What about this proposal: a) adding a Kconfig option like: CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only this should be disabled. b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig files. c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in fbcon which isn't needed by DRM. Thoughts? I can't say I approve keeping fbdev alive, but... With fbdev emulation, every DRM driver is an fbdev driver too. So CONFIG_FB_DRIVER is somewhat misleading. Better add an option like CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that absolutely need HW acceleration. That option would then protect the rsp code. Best regards Thomas Helge -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
On 1/24/22 12:33, Thomas Zimmermann wrote: [snip] >> Thoughts? > > I can't say I approve keeping fbdev alive, but... > > With fbdev emulation, every DRM driver is an fbdev driver too. So > CONFIG_FB_DRIVER is somewhat misleading. Better add an option like > CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that > absolutely need HW acceleration. That option would then protect the rsp > code. > Agreed that this option would be better and allow distros to disable the code that was reverted. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH V2 0/7] DRM kmap() fixes and kmap_local_page() conversions
Am 24.01.22 um 02:54 schrieb ira.we...@intel.com: From: Ira Weiny Changes from V1: Use memcpy_to_page() where appropriate Rebased to latest The kmap() call may cause issues with work being done with persistent memory. For this and other reasons it is being deprecated. I'm really wondering how we should be able to implement the kernel mapping without kmap in TTM. This series starts by converting the last easy kmap() uses in the drm tree to kmap_local_page(). The final 2 patches fix bugs found while working on the ttm_bo_kmap_ttm() conversion. They are valid fixes but were found via code inspection not because of any actual bug so don't require a stable tag.[1] There is one more call to kmap() used in ttm_bo_kmap_ttm(). Unfortunately, fixing this is not straight forward so it is left to future work.[2] Patches #2, #4, #6 and #7 are Reviewed-by: Christian König How to you now want to push those upstream? I can pick them up for the AMD tree like Daniel suggested or you can push them through something else. Regards, Christian. [1] https://lore.kernel.org/lkml/fb71af05-a889-8f6e-031b-426b58a64...@amd.com/ [2] https://lore.kernel.org/lkml/20211215210949.gw3538...@iweiny-desk2.sc.intel.com/ Ira Weiny (7): drm/i915: Replace kmap() with kmap_local_page() drm/amd: Replace kmap() with kmap_local_page() drm/gma: Remove calls to kmap() drm/radeon: Replace kmap() with kmap_local_page() drm/msm: Alter comment to use kmap_local_page() drm/amdgpu: Ensure kunmap is called on error drm/radeon: Ensure kunmap is called on error drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 + drivers/gpu/drm/gma500/gma_display.c | 6 ++ drivers/gpu/drm/gma500/mmu.c | 8 drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- drivers/gpu/drm/i915/gt/shmem_utils.c | 7 ++- drivers/gpu/drm/i915/i915_gem.c | 8 drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++-- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- drivers/gpu/drm/radeon/radeon_uvd.c | 1 + 13 files changed, 32 insertions(+), 37 deletions(-) -- 2.31.1
drm/ttm: moving the LRU into the resource
Hi guys, let's hope that I have fixed and documented everything now. This fixes the fundamental problem in TTM that during a move a buffer has resources allocated from two different domains at the same time. Additional to that it's a prerequisite to remove ghost objects and allow to allocate multiple resources per BO. Based on this set I've added an optimization for RADV which Bas pointed out as valuable. Please review, test and/or comment, Christian.
[PATCH 01/12] drm/ttm: add ttm_resource_fini
Make sure we call the common cleanup function in all
implementations of the resource manager.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c| 2 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 1 +
drivers/gpu/drm/nouveau/nouveau_mem.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_mem.h | 3 ++-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 +
drivers/gpu/drm/ttm/ttm_range_manager.c | 2 ++
drivers/gpu/drm/ttm/ttm_resource.c | 6 ++
drivers/gpu/drm/ttm/ttm_sys_manager.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_system_manager.c | 1 +
include/drm/ttm/ttm_resource.h | 3 +++
13 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 675a72ef305d..ea5470c8c921 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -169,6 +169,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
return 0;
err_free:
+ ttm_resource_fini(man, &node->base.base);
kfree(node);
err_out:
@@ -200,6 +201,7 @@ static void amdgpu_gtt_mgr_del(struct ttm_resource_manager
*man,
if (!(res->placement & TTM_PL_FLAG_TEMPORARY))
atomic64_sub(res->num_pages, &mgr->used);
+ ttm_resource_fini(man, res);
kfree(node);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
index d02c8637f909..ffddec08e931 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
@@ -95,6 +95,7 @@ static void amdgpu_preempt_mgr_del(struct
ttm_resource_manager *man,
struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
atomic64_sub(res->num_pages, &mgr->used);
+ ttm_resource_fini(man, res);
kfree(res);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 7b2b0980ec41..55d68408951d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -476,6 +476,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
while (i--)
drm_mm_remove_node(&node->mm_nodes[i]);
spin_unlock(&mgr->lock);
+ ttm_resource_fini(man, &node->base);
kvfree(node);
error_sub:
@@ -515,6 +516,7 @@ static void amdgpu_vram_mgr_del(struct ttm_resource_manager
*man,
atomic64_sub(usage, &mgr->usage);
atomic64_sub(vis_usage, &mgr->vis_usage);
+ ttm_resource_fini(man, res);
kvfree(node);
}
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 6ba314f9836a..bf857703c797 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -124,6 +124,7 @@ static void i915_ttm_buddy_man_free(struct
ttm_resource_manager *man,
drm_buddy_free_list(&bman->mm, &bman_res->blocks);
mutex_unlock(&bman->lock);
+ ttm_resource_fini(man, res);
kfree(bman_res);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 2ca3207c13fc..2e517cdc24c9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -162,11 +162,12 @@ nouveau_mem_vram(struct ttm_resource *reg, bool contig,
u8 page)
}
void
-nouveau_mem_del(struct ttm_resource *reg)
+nouveau_mem_del(struct ttm_resource_manager *man, struct ttm_resource *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
nouveau_mem_fini(mem);
+ ttm_resource_fini(man, reg);
kfree(mem);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.h
b/drivers/gpu/drm/nouveau/nouveau_mem.h
index 2c01166a90f2..325551eba5cd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.h
@@ -23,7 +23,8 @@ nouveau_mem(struct ttm_resource *reg)
int nouveau_mem_new(struct nouveau_cli *, u8 kind, u8 comp,
struct ttm_resource **);
-void nouveau_mem_del(struct ttm_resource *);
+void nouveau_mem_del(struct ttm_resource_manager *man,
+struct ttm_resource *);
int nouveau_mem_vram(struct ttm_resource *, bool contig, u8 page);
int nouveau_mem_host(struct ttm_resource *, struct ttm_tt *);
void nouveau_mem_fini(struct nouveau_mem *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 2ca9d9a9e5d5..91ef33f8f22c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -36,9 +36,10 @@
#include
static void
-nouveau_
[PATCH 02/12] drm/ttm: add back a reference to the bdev to the res manager
It is simply a lot cleaner to have this around instead of adding the device throughout the call chain. Signed-off-by: Christian König Reviewed-by: Huang Rui --- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c| 3 ++- drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 ++-- drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +- drivers/gpu/drm/ttm/ttm_resource.c | 3 +++ drivers/gpu/drm/ttm/ttm_sys_manager.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_system_manager.c | 2 +- include/drm/ttm/ttm_resource.h | 16 +--- 11 files changed, 24 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c index ea5470c8c921..9e7685a4878c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c @@ -293,7 +293,8 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, uint64_t gtt_size) man->use_tt = true; man->func = &amdgpu_gtt_mgr_func; - ttm_resource_manager_init(man, gtt_size >> PAGE_SHIFT); + ttm_resource_manager_init(man, &adev->mman.bdev, + gtt_size >> PAGE_SHIFT); start = AMDGPU_GTT_MAX_TRANSFER_SIZE * AMDGPU_GTT_NUM_TRANSFER_WINDOWS; size = (adev->gmc.gart_size >> PAGE_SHIFT) - start; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c index ffddec08e931..6f7189d32f0a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c @@ -153,7 +153,7 @@ int amdgpu_preempt_mgr_init(struct amdgpu_device *adev) man->use_tt = true; man->func = &amdgpu_preempt_mgr_func; - ttm_resource_manager_init(man, (1 << 30)); + ttm_resource_manager_init(man, &adev->mman.bdev, (1 << 30)); atomic64_set(&mgr->used, 0); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c index 55d68408951d..ddd0b6d74070 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c @@ -699,7 +699,8 @@ int amdgpu_vram_mgr_init(struct amdgpu_device *adev) struct amdgpu_vram_mgr *mgr = &adev->mman.vram_mgr; struct ttm_resource_manager *man = &mgr->manager; - ttm_resource_manager_init(man, adev->gmc.real_vram_size >> PAGE_SHIFT); + ttm_resource_manager_init(man, &adev->mman.bdev, + adev->gmc.real_vram_size >> PAGE_SHIFT); man->func = &amdgpu_vram_mgr_func; diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c index bf857703c797..79dc8c6f2833 100644 --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c @@ -204,7 +204,7 @@ int i915_ttm_buddy_man_init(struct ttm_device *bdev, man = &bman->manager; man->use_tt = use_tt; man->func = &i915_ttm_buddy_manager_func; - ttm_resource_manager_init(man, bman->mm.size >> PAGE_SHIFT); + ttm_resource_manager_init(man, bdev, bman->mm.size >> PAGE_SHIFT); ttm_resource_manager_set_used(man, true); ttm_set_driver_manager(bdev, type, man); diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 91ef33f8f22c..85f1f5a0fe5d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -164,7 +164,7 @@ nouveau_ttm_init_vram(struct nouveau_drm *drm) man->func = &nouveau_vram_manager; - ttm_resource_manager_init(man, + ttm_resource_manager_init(man, &drm->ttm.bdev, drm->gem.vram_available >> PAGE_SHIFT); ttm_set_driver_manager(&drm->ttm.bdev, TTM_PL_VRAM, man); ttm_resource_manager_set_used(man, true); @@ -211,7 +211,7 @@ nouveau_ttm_init_gtt(struct nouveau_drm *drm) man->func = func; man->use_tt = true; - ttm_resource_manager_init(man, size_pages); + ttm_resource_manager_init(man, &drm->ttm.bdev, size_pages); ttm_set_driver_manager(&drm->ttm.bdev, TTM_PL_TT, man); ttm_resource_manager_set_used(man, true); return 0; diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/drm/ttm/ttm_range_manager.c index 55a41355f684..8cd4f3fb9f79 100644 --- a/drivers/gpu/drm/ttm/ttm_range_manager.c +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c @@ -158,7 +158,7 @@ int ttm_range_man_init_nocheck(struct ttm_device *bdev, man->func = &ttm_range_manager_func; - ttm_resource_manager_init(man, p_size); + tt
[PATCH 03/12] drm/ttm: add a weak BO reference to the resource v3
Keep track for which BO a resource was allocated.
This is necessary to move the LRU handling into the resources.
A bit problematic is i915 since it tries to use the resource
interface without a BO which is illegal from the conceptional
point of view.
v2: Document that this is a weak reference and add a workaround for i915
v3: further document that this is protected by ttm_device::lru_lock and
clarify the i915 workaround
Signed-off-by: Christian König
Acked-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 7 +--
drivers/gpu/drm/ttm/ttm_resource.c | 9 +
include/drm/ttm/ttm_resource.h | 4
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 72a94301bc95..544a84fa6589 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -241,6 +241,11 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
if (bo->type != ttm_bo_type_sg)
fbo->base.base.resv = &fbo->base.base._resv;
+ if (fbo->base.resource) {
+ ttm_resource_set_bo(fbo->base.resource, &fbo->base);
+ bo->resource = NULL;
+ }
+
dma_resv_init(&fbo->base.base._resv);
fbo->base.base.dev = NULL;
ret = dma_resv_trylock(&fbo->base.base._resv);
@@ -509,7 +514,6 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object
*bo,
ghost_obj->ttm = NULL;
else
bo->ttm = NULL;
- bo->resource = NULL;
dma_resv_unlock(&ghost_obj->base._resv);
ttm_bo_put(ghost_obj);
@@ -637,7 +641,6 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
dma_resv_unlock(&ghost->base._resv);
ttm_bo_put(ghost);
bo->ttm = ttm;
- bo->resource = NULL;
ttm_bo_assign_mem(bo, sys_res);
return 0;
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 41e7bf195168..7fdd58b53c61 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -41,6 +41,7 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
res->bus.offset = 0;
res->bus.is_iomem = false;
res->bus.caching = ttm_cached;
+ res->bo = bo;
}
EXPORT_SYMBOL(ttm_resource_init);
@@ -122,6 +123,14 @@ bool ttm_resource_compat(struct ttm_resource *res,
}
EXPORT_SYMBOL(ttm_resource_compat);
+void ttm_resource_set_bo(struct ttm_resource *res,
+struct ttm_buffer_object *bo)
+{
+ spin_lock(&bo->bdev->lru_lock);
+ res->bo = bo;
+ spin_unlock(&bo->bdev->lru_lock);
+}
+
/**
* ttm_resource_manager_init
*
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index 6bf37383002b..69eea9d6399b 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -161,6 +161,7 @@ struct ttm_bus_placement {
* @mem_type: Resource type of the allocation.
* @placement: Placement flags.
* @bus: Placement on io bus accessible to the CPU
+ * @bo: weak reference to the BO, protected by ttm_device::lru_lock
*
* Structure indicating the placement and space resources used by a
* buffer object.
@@ -171,6 +172,7 @@ struct ttm_resource {
uint32_t mem_type;
uint32_t placement;
struct ttm_bus_placement bus;
+ struct ttm_buffer_object *bo;
};
/**
@@ -271,6 +273,8 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
void ttm_resource_free(struct ttm_buffer_object *bo, struct ttm_resource
**res);
bool ttm_resource_compat(struct ttm_resource *res,
struct ttm_placement *placement);
+void ttm_resource_set_bo(struct ttm_resource *res,
+struct ttm_buffer_object *bo);
void ttm_resource_manager_init(struct ttm_resource_manager *man,
struct ttm_device *bdev,
--
2.25.1
[PATCH 06/12] drm/ttm: add resource iterator
Instead of duplicating that at different places add an iterator over all
the resources in a resource manager.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 41 +++
drivers/gpu/drm/ttm/ttm_device.c | 26 -
drivers/gpu/drm/ttm/ttm_resource.c | 45 ++
include/drm/ttm/ttm_resource.h | 23 +++
4 files changed, 95 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cb0fa932d495..599be3dda8a9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -579,38 +579,29 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
struct ww_acquire_ctx *ticket)
{
struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
+ struct ttm_resource_cursor cursor;
struct ttm_resource *res;
bool locked = false;
- unsigned i;
int ret;
spin_lock(&bdev->lru_lock);
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- list_for_each_entry(res, &man->lru[i], lru) {
- bool busy;
-
- bo = res->bo;
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
- &locked, &busy)) {
- if (busy && !busy_bo && ticket !=
- dma_resv_locking_ctx(bo->base.resv))
- busy_bo = bo;
- continue;
- }
-
- if (!ttm_bo_get_unless_zero(bo)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
- break;
+ ttm_resource_manager_for_each_res(man, &cursor, res) {
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(res->bo, ctx, place,
+ &locked, &busy)) {
+ if (busy && !busy_bo && ticket !=
+ dma_resv_locking_ctx(bo->base.resv))
+ busy_bo = res->bo;
+ continue;
}
- /* If the inner loop terminated early, we have our candidate */
- if (&res->lru != &man->lru[i])
- break;
-
- bo = NULL;
+ if (!ttm_bo_get_unless_zero(res->bo)) {
+ if (locked)
+ dma_resv_unlock(res->bo->base.resv);
+ continue;
+ }
+ bo = res->bo;
}
if (!bo) {
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index ba35887147ba..a0562ab386f5 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -142,10 +142,10 @@ EXPORT_SYMBOL(ttm_global_swapout);
int ttm_device_swapout(struct ttm_device *bdev, struct ttm_operation_ctx *ctx,
gfp_t gfp_flags)
{
+ struct ttm_resource_cursor cursor;
struct ttm_resource_manager *man;
- struct ttm_buffer_object *bo;
struct ttm_resource *res;
- unsigned i, j;
+ unsigned i;
int ret;
spin_lock(&bdev->lru_lock);
@@ -154,20 +154,16 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
ttm_operation_ctx *ctx,
if (!man || !man->use_tt)
continue;
- for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
- list_for_each_entry(res, &man->lru[j], lru) {
- uint32_t num_pages;
-
- bo = res->bo;
- num_pages = PFN_UP(bo->base.size);
+ ttm_resource_manager_for_each_res(man, &cursor, res) {
+ struct ttm_buffer_object *bo = res->bo;
+ uint32_t num_pages = PFN_UP(bo->base.size);
- ret = ttm_bo_swapout(bo, ctx, gfp_flags);
- /* ttm_bo_swapout has dropped the lru_lock */
- if (!ret)
- return num_pages;
- if (ret != -EBUSY)
- return ret;
- }
+ ret = ttm_bo_swapout(bo, ctx, gfp_flags);
+ /* ttm_bo_swapout has dropped the lru_lock */
+ if (!ret)
+ return num_pages;
+ if (ret != -EBUSY)
+ return ret;
}
}
spin_unlock(&bdev->lru_lock);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 450e665c357b..9e68d
[PATCH 08/12] drm/amdgpu: remove GTT accounting
This is provided by TTM now.
Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 50 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 -
3 files changed, 12 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 9e7685a4878c..ce5eeb3c1097 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -60,7 +60,7 @@ static ssize_t amdgpu_mem_info_gtt_total_show(struct device
*dev,
struct ttm_resource_manager *man;
man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
- return sysfs_emit(buf, "%llu\n", man->size * PAGE_SIZE);
+ return sysfs_emit(buf, "%llu\n", man->size);
}
/**
@@ -80,7 +80,7 @@ static ssize_t amdgpu_mem_info_gtt_used_show(struct device
*dev,
struct ttm_resource_manager *man;
man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
- return sysfs_emit(buf, "%llu\n", amdgpu_gtt_mgr_usage(man));
+ return sysfs_emit(buf, "%llu\n", ttm_resource_manager_usage(man));
}
static DEVICE_ATTR(mem_info_gtt_total, S_IRUGO,
@@ -132,20 +132,17 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
struct amdgpu_gtt_node *node;
int r;
- if (!(place->flags & TTM_PL_FLAG_TEMPORARY) &&
- atomic64_add_return(num_pages, &mgr->used) > man->size) {
- atomic64_sub(num_pages, &mgr->used);
- return -ENOSPC;
- }
-
node = kzalloc(struct_size(node, base.mm_nodes, 1), GFP_KERNEL);
- if (!node) {
- r = -ENOMEM;
- goto err_out;
- }
+ if (!node)
+ return -ENOMEM;
node->tbo = tbo;
ttm_resource_init(tbo, place, &node->base.base);
+ if (!(place->flags & TTM_PL_FLAG_TEMPORARY) &&
+ ttm_resource_manager_usage(man) > man->size) {
+ r = -ENOSPC;
+ goto err_free;
+ }
if (place->lpfn) {
spin_lock(&mgr->lock);
@@ -171,11 +168,6 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
err_free:
ttm_resource_fini(man, &node->base.base);
kfree(node);
-
-err_out:
- if (!(place->flags & TTM_PL_FLAG_TEMPORARY))
- atomic64_sub(num_pages, &mgr->used);
-
return r;
}
@@ -198,27 +190,10 @@ static void amdgpu_gtt_mgr_del(struct
ttm_resource_manager *man,
drm_mm_remove_node(&node->base.mm_nodes[0]);
spin_unlock(&mgr->lock);
- if (!(res->placement & TTM_PL_FLAG_TEMPORARY))
- atomic64_sub(res->num_pages, &mgr->used);
-
ttm_resource_fini(man, res);
kfree(node);
}
-/**
- * amdgpu_gtt_mgr_usage - return usage of GTT domain
- *
- * @man: TTM memory type manager
- *
- * Return how many bytes are used in the GTT domain
- */
-uint64_t amdgpu_gtt_mgr_usage(struct ttm_resource_manager *man)
-{
- struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
-
- return atomic64_read(&mgr->used) * PAGE_SIZE;
-}
-
/**
* amdgpu_gtt_mgr_recover - re-init gart
*
@@ -265,9 +240,6 @@ static void amdgpu_gtt_mgr_debug(struct
ttm_resource_manager *man,
spin_lock(&mgr->lock);
drm_mm_print(&mgr->mm, printer);
spin_unlock(&mgr->lock);
-
- drm_printf(printer, "man size:%llu pages, gtt used:%llu pages\n",
- man->size, atomic64_read(&mgr->used));
}
static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func = {
@@ -293,14 +265,12 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev,
uint64_t gtt_size)
man->use_tt = true;
man->func = &amdgpu_gtt_mgr_func;
- ttm_resource_manager_init(man, &adev->mman.bdev,
- gtt_size >> PAGE_SHIFT);
+ ttm_resource_manager_init(man, &adev->mman.bdev, gtt_size);
start = AMDGPU_GTT_MAX_TRANSFER_SIZE * AMDGPU_GTT_NUM_TRANSFER_WINDOWS;
size = (adev->gmc.gart_size >> PAGE_SHIFT) - start;
drm_mm_init(&mgr->mm, start, size);
spin_lock_init(&mgr->lock);
- atomic64_set(&mgr->used, 0);
ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_TT, &mgr->manager);
ttm_resource_manager_set_used(man, true);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 651c7abfde03..8d5d56d9d26d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -678,7 +678,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
ui64 =
amdgpu_vram_mgr_vis_usage(ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM));
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMD
[PATCH 05/12] drm/ttm: move the LRU into resource handling v2
This way we finally fix the problem that new resource are
not immediately evict-able after allocation.
That has caused numerous problems including OOM on GDS handling
and not being able to use TTM as general resource manager.
v2: stop assuming in ttm_resource_fini that res->bo is still valid.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 115 ++
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c| 64 ++---
drivers/gpu/drm/ttm/ttm_resource.c | 122 +++-
include/drm/ttm/ttm_bo_api.h| 16
include/drm/ttm/ttm_bo_driver.h | 29 +-
include/drm/ttm/ttm_resource.h | 35 +++
9 files changed, 201 insertions(+), 191 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index a96ae4c0e040..cdb489cdf27b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -683,12 +683,12 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
*adev,
if (vm->bulk_moveable) {
spin_lock(&adev->mman.bdev.lru_lock);
- ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
+ ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
spin_unlock(&adev->mman.bdev.lru_lock);
return;
}
- memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
+ ttm_lru_bulk_move_init(&vm->lru_bulk_move);
spin_lock(&adev->mman.bdev.lru_lock);
list_for_each_entry(bo_base, &vm->idle, vm_status) {
@@ -698,11 +698,9 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
if (!bo->parent)
continue;
- ttm_bo_move_to_lru_tail(&bo->tbo, bo->tbo.resource,
- &vm->lru_bulk_move);
+ ttm_bo_move_to_lru_tail(&bo->tbo, &vm->lru_bulk_move);
if (shadow)
ttm_bo_move_to_lru_tail(&shadow->tbo,
- shadow->tbo.resource,
&vm->lru_bulk_move);
}
spin_unlock(&adev->mman.bdev.lru_lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 218a9b3037c7..cdf1ff87c88d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -835,7 +835,7 @@ void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj)
bo->priority = I915_TTM_PRIO_NO_PAGES;
}
- ttm_bo_move_to_lru_tail(bo, bo->resource, NULL);
+ ttm_bo_move_to_lru_tail(bo, NULL);
spin_unlock(&bo->bdev->lru_lock);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index db3dc7ef5382..cb0fa932d495 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -69,108 +69,16 @@ static void ttm_bo_mem_space_debug(struct
ttm_buffer_object *bo,
}
}
-static inline void ttm_bo_move_to_pinned(struct ttm_buffer_object *bo)
-{
- struct ttm_device *bdev = bo->bdev;
-
- list_move_tail(&bo->lru, &bdev->pinned);
-
- if (bdev->funcs->del_from_lru_notify)
- bdev->funcs->del_from_lru_notify(bo);
-}
-
-static inline void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
-{
- struct ttm_device *bdev = bo->bdev;
-
- list_del_init(&bo->lru);
-
- if (bdev->funcs->del_from_lru_notify)
- bdev->funcs->del_from_lru_notify(bo);
-}
-
-static void ttm_bo_bulk_move_set_pos(struct ttm_lru_bulk_move_pos *pos,
-struct ttm_buffer_object *bo)
-{
- if (!pos->first)
- pos->first = bo;
- pos->last = bo;
-}
-
void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
-struct ttm_resource *mem,
struct ttm_lru_bulk_move *bulk)
{
- struct ttm_device *bdev = bo->bdev;
- struct ttm_resource_manager *man;
-
- if (!bo->deleted)
- dma_resv_assert_held(bo->base.resv);
-
- if (bo->pin_count) {
- ttm_bo_move_to_pinned(bo);
- return;
- }
-
- if (!mem)
- return;
-
- man = ttm_manager_type(bdev, mem->mem_type);
- list_move_tail(&bo->lru, &man->lru[bo->priority]);
-
- if (bdev->funcs->del_from_lru_notify)
- bdev->funcs->del_from_lru_notify(bo);
-
- if (bulk && !bo->pin_count) {
- switch (bo->resource->mem_type) {
- case TTM_PL_TT:
- ttm_bo_bulk_move_set_pos(&bulk->tt[bo->priority], bo);
- break;
+ dma_resv_assert_held(bo->base.resv);
- case TTM_PL_VRAM:
-
[PATCH 07/12] drm/radeon: remove resource accounting
Use the one provided by TTM instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 2 --
drivers/gpu/drm/radeon/radeon_kms.c| 7 --
drivers/gpu/drm/radeon/radeon_object.c | 30 +++---
drivers/gpu/drm/radeon/radeon_object.h | 1 -
drivers/gpu/drm/radeon/radeon_ttm.c| 18 ++--
5 files changed, 10 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 895776c421d4..08f83bf2c330 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2462,8 +2462,6 @@ struct radeon_device {
struct radeon_vm_managervm_manager;
struct mutexgpu_clock_mutex;
/* memory stats */
- atomic64_t vram_usage;
- atomic64_t gtt_usage;
atomic64_t num_bytes_moved;
atomic_tgpu_reset_counter;
/* ACPI interface */
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 7afe28408085..3a9226d0cb05 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -241,6 +241,7 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
struct drm_radeon_info *info = data;
struct radeon_mode_info *minfo = &rdev->mode_info;
uint32_t *value, value_tmp, *value_ptr, value_size;
+ struct ttm_resource_manager *man;
uint64_t value64;
struct drm_crtc *crtc;
int i, found;
@@ -550,12 +551,14 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
case RADEON_INFO_VRAM_USAGE:
value = (uint32_t*)&value64;
value_size = sizeof(uint64_t);
- value64 = atomic64_read(&rdev->vram_usage);
+ man = ttm_manager_type(&rdev->mman.bdev, TTM_PL_VRAM);
+ value64 = ttm_resource_manager_usage(man);
break;
case RADEON_INFO_GTT_USAGE:
value = (uint32_t*)&value64;
value_size = sizeof(uint64_t);
- value64 = atomic64_read(&rdev->gtt_usage);
+ man = ttm_manager_type(&rdev->mman.bdev, TTM_PL_TT);
+ value64 = ttm_resource_manager_usage(man);
break;
case RADEON_INFO_ACTIVE_CU_COUNT:
if (rdev->family >= CHIP_BONAIRE)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 56ede9d63b12..c9bbed2a25ad 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -49,27 +49,6 @@ static void radeon_bo_clear_surface_reg(struct radeon_bo
*bo);
* function are calling it.
*/
-static void radeon_update_memory_usage(struct ttm_buffer_object *bo,
- unsigned int mem_type, int sign)
-{
- struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
-
- switch (mem_type) {
- case TTM_PL_TT:
- if (sign > 0)
- atomic64_add(bo->base.size, &rdev->gtt_usage);
- else
- atomic64_sub(bo->base.size, &rdev->gtt_usage);
- break;
- case TTM_PL_VRAM:
- if (sign > 0)
- atomic64_add(bo->base.size, &rdev->vram_usage);
- else
- atomic64_sub(bo->base.size, &rdev->vram_usage);
- break;
- }
-}
-
static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
{
struct radeon_bo *bo;
@@ -434,7 +413,9 @@ void radeon_bo_fini(struct radeon_device *rdev)
static u64 radeon_bo_get_threshold_for_moves(struct radeon_device *rdev)
{
u64 real_vram_size = rdev->mc.real_vram_size;
- u64 vram_usage = atomic64_read(&rdev->vram_usage);
+ struct ttm_resource_manager *man =
+ ttm_manager_type(&rdev->mman.bdev, TTM_PL_VRAM);
+ u64 vram_usage = ttm_resource_manager_usage(man);
/* This function is based on the current VRAM usage.
*
@@ -725,15 +706,10 @@ int radeon_bo_check_tiling(struct radeon_bo *bo, bool
has_moved,
}
void radeon_bo_move_notify(struct ttm_buffer_object *bo,
- unsigned int old_type,
struct ttm_resource *new_mem)
{
struct radeon_bo *rbo;
- radeon_update_memory_usage(bo, old_type, -1);
- if (new_mem)
- radeon_update_memory_usage(bo, new_mem->mem_type, 1);
-
if (!radeon_ttm_bo_is_radeon_bo(bo))
return;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 1afc7992ef91..0b64e202577b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -161,7 +161,6 @@ extern void radeon_bo_get_tiling_flags(struct radeon_bo *b
[PATCH 09/12] drm/amdgpu: remove VRAM accounting
This is provided by TTM now.
Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 56 +++-
7 files changed, 26 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 46cf48b3904a..5a3ecdea20eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -516,9 +516,10 @@ int amdgpu_amdkfd_get_dmabuf_info(struct amdgpu_device
*adev, int dma_buf_fd,
uint64_t amdgpu_amdkfd_get_vram_usage(struct amdgpu_device *adev)
{
- struct ttm_resource_manager *vram_man =
ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
+ struct ttm_resource_manager *vram_man =
+ ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
- return amdgpu_vram_mgr_usage(vram_man);
+ return ttm_resource_manager_usage(vram_man);
}
uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct amdgpu_device *dst,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 53e407ea4c89..936c1a7174f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -315,7 +315,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
}
total_vram = adev->gmc.real_vram_size -
atomic64_read(&adev->vram_pin_size);
- used_vram = amdgpu_vram_mgr_usage(vram_man);
+ used_vram = ttm_resource_manager_usage(vram_man);
free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
spin_lock(&adev->mm_stats.lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 8d5d56d9d26d..6d21ee430f03 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -672,7 +672,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
ui64 = atomic64_read(&adev->num_vram_cpu_page_faults);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VRAM_USAGE:
- ui64 = amdgpu_vram_mgr_usage(ttm_manager_type(&adev->mman.bdev,
TTM_PL_VRAM));
+ ui64 =
ttm_resource_manager_usage(ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM));
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VIS_VRAM_USAGE:
ui64 =
amdgpu_vram_mgr_vis_usage(ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM));
@@ -718,8 +718,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
mem.vram.usable_heap_size = adev->gmc.real_vram_size -
atomic64_read(&adev->vram_pin_size) -
AMDGPU_VM_RESERVED_VRAM;
- mem.vram.heap_usage =
- amdgpu_vram_mgr_usage(vram_man);
+ mem.vram.heap_usage = ttm_resource_manager_usage(vram_man);
mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;
mem.cpu_accessible_vram.total_heap_size =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index eac2ff4647e3..f6b3695979a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1873,7 +1873,7 @@ void amdgpu_ttm_set_buffer_funcs_status(struct
amdgpu_device *adev, bool enable)
size = adev->gmc.real_vram_size;
else
size = adev->gmc.visible_vram_size;
- man->size = size >> PAGE_SHIFT;
+ man->size = size;
adev->mman.buffer_funcs_enabled = enable;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 2ac332cd4f59..f3eb4029bdcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -44,7 +44,6 @@ struct amdgpu_vram_mgr {
spinlock_t lock;
struct list_head reservations_pending;
struct list_head reserved_pages;
- atomic64_t usage;
atomic64_t vis_usage;
};
@@ -127,7 +126,6 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
void amdgpu_vram_mgr_free_sgt(struct device *dev,
enum dma_data_direction dir,
struct sg_table *sgt);
-uint64_t amdgpu_vram_mgr_usage(struct ttm_resource_manager *man);
uint64_t amdgpu_vram_mgr_vis_usage(struct ttm_resource_manager *man);
int amdgpu_vram
[PATCH 04/12] drm/ttm: add common accounting to the resource mgr v2
It makes sense to have this in the common manager for debugging and
accounting of how much resources are used.
v2: cleanup kerneldoc a bit
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_resource.c | 8
include/drm/ttm/ttm_resource.h | 20 +++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 7fdd58b53c61..b8362492980d 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -33,6 +33,8 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
const struct ttm_place *place,
struct ttm_resource *res)
{
+ struct ttm_resource_manager *man;
+
res->start = 0;
res->num_pages = PFN_UP(bo->base.size);
res->mem_type = place->mem_type;
@@ -42,12 +44,16 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
res->bus.is_iomem = false;
res->bus.caching = ttm_cached;
res->bo = bo;
+
+ man = ttm_manager_type(bo->bdev, place->mem_type);
+ atomic64_add(bo->base.size, &man->usage);
}
EXPORT_SYMBOL(ttm_resource_init);
void ttm_resource_fini(struct ttm_resource_manager *man,
struct ttm_resource *res)
{
+ atomic64_sub(res->bo->base.size, &man->usage);
}
EXPORT_SYMBOL(ttm_resource_fini);
@@ -149,6 +155,7 @@ void ttm_resource_manager_init(struct ttm_resource_manager
*man,
spin_lock_init(&man->move_lock);
man->bdev = bdev;
man->size = p_size;
+ atomic64_set(&man->usage, 0);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
INIT_LIST_HEAD(&man->lru[i]);
@@ -221,6 +228,7 @@ void ttm_resource_manager_debug(struct ttm_resource_manager
*man,
drm_printf(p, " use_type: %d\n", man->use_type);
drm_printf(p, " use_tt: %d\n", man->use_tt);
drm_printf(p, " size: %llu\n", man->size);
+ drm_printf(p, " usage: %llu\n", atomic64_read(&man->usage));
if (man->func->debug)
man->func->debug(man, p);
}
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index 69eea9d6399b..3d391279b33f 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -132,8 +133,12 @@ struct ttm_resource_manager {
/*
* Protected by the global->lru_lock.
*/
-
struct list_head lru[TTM_MAX_BO_PRIORITY];
+
+ /**
+* @usage: How much of the region is used, has its own protection.
+*/
+ atomic64_t usage;
};
/**
@@ -261,6 +266,19 @@ ttm_resource_manager_cleanup(struct ttm_resource_manager
*man)
man->move = NULL;
}
+/**
+ * ttm_resource_manager_usage
+ *
+ * @man: A memory manager object.
+ *
+ * Return how many resources are currently used.
+ */
+static inline uint64_t
+ttm_resource_manager_usage(struct ttm_resource_manager *man)
+{
+ return atomic64_read(&man->usage);
+}
+
void ttm_resource_init(struct ttm_buffer_object *bo,
const struct ttm_place *place,
struct ttm_resource *res);
--
2.25.1
[PATCH 10/12] drm/amdgpu: drop amdgpu_gtt_node
We have the BO pointer in the base structure now as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 49 -
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index ce5eeb3c1097..a55bbe1a154c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -26,23 +26,12 @@
#include "amdgpu.h"
-struct amdgpu_gtt_node {
- struct ttm_buffer_object *tbo;
- struct ttm_range_mgr_node base;
-};
-
static inline struct amdgpu_gtt_mgr *
to_gtt_mgr(struct ttm_resource_manager *man)
{
return container_of(man, struct amdgpu_gtt_mgr, manager);
}
-static inline struct amdgpu_gtt_node *
-to_amdgpu_gtt_node(struct ttm_resource *res)
-{
- return container_of(res, struct amdgpu_gtt_node, base.base);
-}
-
/**
* DOC: mem_info_gtt_total
*
@@ -107,9 +96,9 @@ const struct attribute_group amdgpu_gtt_mgr_attr_group = {
*/
bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_resource *res)
{
- struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+ struct ttm_range_mgr_node *node = to_ttm_range_mgr_node(res);
- return drm_mm_node_allocated(&node->base.mm_nodes[0]);
+ return drm_mm_node_allocated(&node->mm_nodes[0]);
}
/**
@@ -129,15 +118,14 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
{
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
uint32_t num_pages = PFN_UP(tbo->base.size);
- struct amdgpu_gtt_node *node;
+ struct ttm_range_mgr_node *node;
int r;
- node = kzalloc(struct_size(node, base.mm_nodes, 1), GFP_KERNEL);
+ node = kzalloc(struct_size(node, mm_nodes, 1), GFP_KERNEL);
if (!node)
return -ENOMEM;
- node->tbo = tbo;
- ttm_resource_init(tbo, place, &node->base.base);
+ ttm_resource_init(tbo, place, &node->base);
if (!(place->flags & TTM_PL_FLAG_TEMPORARY) &&
ttm_resource_manager_usage(man) > man->size) {
r = -ENOSPC;
@@ -146,8 +134,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
if (place->lpfn) {
spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range(&mgr->mm,
- &node->base.mm_nodes[0],
+ r = drm_mm_insert_node_in_range(&mgr->mm, &node->mm_nodes[0],
num_pages, tbo->page_alignment,
0, place->fpfn, place->lpfn,
DRM_MM_INSERT_BEST);
@@ -155,18 +142,18 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
if (unlikely(r))
goto err_free;
- node->base.base.start = node->base.mm_nodes[0].start;
+ node->base.start = node->mm_nodes[0].start;
} else {
- node->base.mm_nodes[0].start = 0;
- node->base.mm_nodes[0].size = node->base.base.num_pages;
- node->base.base.start = AMDGPU_BO_INVALID_OFFSET;
+ node->mm_nodes[0].start = 0;
+ node->mm_nodes[0].size = node->base.num_pages;
+ node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
- *res = &node->base.base;
+ *res = &node->base;
return 0;
err_free:
- ttm_resource_fini(man, &node->base.base);
+ ttm_resource_fini(man, &node->base);
kfree(node);
return r;
}
@@ -182,12 +169,12 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
static void amdgpu_gtt_mgr_del(struct ttm_resource_manager *man,
struct ttm_resource *res)
{
- struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+ struct ttm_range_mgr_node *node = to_ttm_range_mgr_node(res);
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
spin_lock(&mgr->lock);
- if (drm_mm_node_allocated(&node->base.mm_nodes[0]))
- drm_mm_remove_node(&node->base.mm_nodes[0]);
+ if (drm_mm_node_allocated(&node->mm_nodes[0]))
+ drm_mm_remove_node(&node->mm_nodes[0]);
spin_unlock(&mgr->lock);
ttm_resource_fini(man, res);
@@ -204,16 +191,16 @@ static void amdgpu_gtt_mgr_del(struct
ttm_resource_manager *man,
int amdgpu_gtt_mgr_recover(struct ttm_resource_manager *man)
{
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
+ struct ttm_range_mgr_node *node;
struct amdgpu_device *adev;
- struct amdgpu_gtt_node *node;
struct drm_mm_node *mm_node;
int r = 0;
adev = container_of(mgr, typeof(*adev), mman.gtt_mgr);
spin_lock(&mgr->lock);
drm_mm_for_each_node(mm_node, &mgr->mm) {
- node = container_of(mm_node, typeof(*node), base.mm_nodes[0]);
-
[PATCH 12/12] drm/ttm: rework bulk move handling
Instead of providing the bulk move structure for each LRU update set
this as property of the BO. This should avoid costly bulk move rebuilds
with some games under RADV.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 72 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 42 ++--
drivers/gpu/drm/ttm/ttm_resource.c | 87 ++---
include/drm/ttm/ttm_bo_api.h| 18 ++---
include/drm/ttm/ttm_bo_driver.h | 2 +-
include/drm/ttm/ttm_device.h| 9 ---
include/drm/ttm/ttm_resource.h | 7 +-
10 files changed, 124 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f6b3695979a6..7424a4a8d35c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1497,7 +1497,6 @@ static struct ttm_device_funcs amdgpu_bo_driver = {
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
.access_memory = &amdgpu_ttm_access_memory,
- .del_from_lru_notify = &amdgpu_vm_del_from_lru_notify
};
/*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index cdb489cdf27b..35ed849cfe25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -375,7 +375,7 @@ static void amdgpu_vm_bo_base_init(struct amdgpu_vm_bo_base
*base,
if (bo->tbo.base.resv != vm->root.bo->tbo.base.resv)
return;
- vm->bulk_moveable = false;
+ ttm_bo_set_bulk_move(&bo->tbo, &vm->lru_bulk_move);
if (bo->tbo.type == ttm_bo_type_kernel && bo->parent)
amdgpu_vm_bo_relocated(base);
else
@@ -637,36 +637,6 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
list_add(&entry->tv.head, validated);
}
-/**
- * amdgpu_vm_del_from_lru_notify - update bulk_moveable flag
- *
- * @bo: BO which was removed from the LRU
- *
- * Make sure the bulk_moveable flag is updated when a BO is removed from the
- * LRU.
- */
-void amdgpu_vm_del_from_lru_notify(struct ttm_buffer_object *bo)
-{
- struct amdgpu_bo *abo;
- struct amdgpu_vm_bo_base *bo_base;
-
- if (!amdgpu_bo_is_amdgpu_bo(bo))
- return;
-
- if (bo->pin_count)
- return;
-
- abo = ttm_to_amdgpu_bo(bo);
- if (!abo->parent)
- return;
- for (bo_base = abo->vm_bo; bo_base; bo_base = bo_base->next) {
- struct amdgpu_vm *vm = bo_base->vm;
-
- if (abo->tbo.base.resv == vm->root.bo->tbo.base.resv)
- vm->bulk_moveable = false;
- }
-
-}
/**
* amdgpu_vm_move_to_lru_tail - move all BOs to the end of LRU
*
@@ -679,33 +649,9 @@ void amdgpu_vm_del_from_lru_notify(struct
ttm_buffer_object *bo)
void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
struct amdgpu_vm *vm)
{
- struct amdgpu_vm_bo_base *bo_base;
-
- if (vm->bulk_moveable) {
- spin_lock(&adev->mman.bdev.lru_lock);
- ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
- spin_unlock(&adev->mman.bdev.lru_lock);
- return;
- }
-
- ttm_lru_bulk_move_init(&vm->lru_bulk_move);
-
spin_lock(&adev->mman.bdev.lru_lock);
- list_for_each_entry(bo_base, &vm->idle, vm_status) {
- struct amdgpu_bo *bo = bo_base->bo;
- struct amdgpu_bo *shadow = amdgpu_bo_shadowed(bo);
-
- if (!bo->parent)
- continue;
-
- ttm_bo_move_to_lru_tail(&bo->tbo, &vm->lru_bulk_move);
- if (shadow)
- ttm_bo_move_to_lru_tail(&shadow->tbo,
- &vm->lru_bulk_move);
- }
+ ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
spin_unlock(&adev->mman.bdev.lru_lock);
-
- vm->bulk_moveable = true;
}
/**
@@ -728,8 +674,6 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct amdgpu_vm_bo_base *bo_base, *tmp;
int r;
- vm->bulk_moveable &= list_empty(&vm->evicted);
-
list_for_each_entry_safe(bo_base, tmp, &vm->evicted, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
struct amdgpu_bo *shadow = amdgpu_bo_shadowed(bo);
@@ -1047,10 +991,16 @@ static void amdgpu_vm_free_table(struct
amdgpu_vm_bo_base *entry)
if (!entry->bo)
return;
+
shadow = amdgpu_bo_shadowed(entry->bo);
+ if (shadow) {
+ ttm_bo_set_bulk_move(&shadow->tbo, NULL);
+ amdgpu_bo_unref(&shadow);
+ }
+
+ ttm_bo_set_bulk_move(&entry->bo->tbo, NULL);
entry->bo->v
[PATCH 11/12] drm/ttm: allow bulk moves for all domains
Not just TT and VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_resource.c | 49 +-
include/drm/ttm/ttm_device.h | 2 --
include/drm/ttm/ttm_resource.h | 4 +--
3 files changed, 16 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 9e68d36a1546..2ea8fb83377e 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -51,36 +51,23 @@ EXPORT_SYMBOL(ttm_lru_bulk_move_init);
*/
void ttm_lru_bulk_move_tail(struct ttm_lru_bulk_move *bulk)
{
- unsigned i;
-
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- struct ttm_lru_bulk_move_pos *pos = &bulk->tt[i];
- struct ttm_resource_manager *man;
+ unsigned i, j;
- if (!pos->first)
- continue;
+ for (i = 0; i < TTM_NUM_MEM_TYPES; ++i) {
+ for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
+ struct ttm_lru_bulk_move_pos *pos = &bulk->pos[i][j];
+ struct ttm_resource_manager *man;
- dma_resv_assert_held(pos->first->bo->base.resv);
- dma_resv_assert_held(pos->last->bo->base.resv);
+ if (!pos->first)
+ continue;
- man = ttm_manager_type(pos->first->bo->bdev, TTM_PL_TT);
- list_bulk_move_tail(&man->lru[i], &pos->first->lru,
- &pos->last->lru);
- }
-
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- struct ttm_lru_bulk_move_pos *pos = &bulk->vram[i];
- struct ttm_resource_manager *man;
+ dma_resv_assert_held(pos->first->bo->base.resv);
+ dma_resv_assert_held(pos->last->bo->base.resv);
- if (!pos->first)
- continue;
-
- dma_resv_assert_held(pos->first->bo->base.resv);
- dma_resv_assert_held(pos->last->bo->base.resv);
-
- man = ttm_manager_type(pos->first->bo->bdev, TTM_PL_VRAM);
- list_bulk_move_tail(&man->lru[i], &pos->first->lru,
- &pos->last->lru);
+ man = ttm_manager_type(pos->first->bo->bdev, i);
+ list_bulk_move_tail(&man->lru[j], &pos->first->lru,
+ &pos->last->lru);
+ }
}
}
EXPORT_SYMBOL(ttm_lru_bulk_move_tail);
@@ -118,15 +105,7 @@ void ttm_resource_move_to_lru_tail(struct ttm_resource
*res,
if (!bulk)
return;
- switch (res->mem_type) {
- case TTM_PL_TT:
- ttm_lru_bulk_move_set_pos(&bulk->tt[bo->priority], res);
- break;
-
- case TTM_PL_VRAM:
- ttm_lru_bulk_move_set_pos(&bulk->vram[bo->priority], res);
- break;
- }
+ ttm_lru_bulk_move_set_pos(&bulk->pos[res->mem_type][bo->priority], res);
}
void ttm_resource_init(struct ttm_buffer_object *bo,
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 0a4ddec78d8f..425150f35fbe 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -30,8 +30,6 @@
#include
#include
-#define TTM_NUM_MEM_TYPES 8
-
struct ttm_device;
struct ttm_placement;
struct ttm_buffer_object;
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index 13da5e337350..1556d1f62251 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -37,6 +37,7 @@
#include
#define TTM_MAX_BO_PRIORITY4U
+#define TTM_NUM_MEM_TYPES 8
struct ttm_device;
struct ttm_resource_manager;
@@ -216,8 +217,7 @@ struct ttm_lru_bulk_move_pos {
* Helper structure for bulk moves on the LRU list.
*/
struct ttm_lru_bulk_move {
- struct ttm_lru_bulk_move_pos tt[TTM_MAX_BO_PRIORITY];
- struct ttm_lru_bulk_move_pos vram[TTM_MAX_BO_PRIORITY];
+ struct ttm_lru_bulk_move_pos
pos[TTM_NUM_MEM_TYPES][TTM_MAX_BO_PRIORITY];
};
/**
--
2.25.1
[PATCH] drm/i915/overlay: Prevent divide by zero bugs in scaling
Smatch detected a divide by zero bug in check_overlay_scaling().
drivers/gpu/drm/i915/display/intel_overlay.c:976 check_overlay_scaling()
error: potential divide by zero bug '/ rec->dst_height'.
drivers/gpu/drm/i915/display/intel_overlay.c:980 check_overlay_scaling()
error: potential divide by zero bug '/ rec->dst_width'.
Prevent this by ensuring that the dst height and width are non-zero.
Fixes: 02e792fbaadb ("drm/i915: implement drmmode overlay support v4")
Signed-off-by: Dan Carpenter
---
>From static analysis. Not tested.
drivers/gpu/drm/i915/display/intel_overlay.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 1a376e9a1ff3..d610e48cab94 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -959,6 +959,9 @@ static int check_overlay_dst(struct intel_overlay *overlay,
const struct intel_crtc_state *pipe_config =
overlay->crtc->config;
+ if (rec->dst_height == 0 || rec->dst_width == 0)
+ return -EINVAL;
+
if (rec->dst_x < pipe_config->pipe_src_w &&
rec->dst_x + rec->dst_width <= pipe_config->pipe_src_w &&
rec->dst_y < pipe_config->pipe_src_h &&
--
2.20.1
[PATCH 5/5] drm: Add TODO item for requesting memory regions
Add a TODO item about requesting memory regions for each driver. The current DRM drivers don't do this consistently. Signed-off-by: Thomas Zimmermann --- Documentation/gpu/todo.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index da138dd39883..1b2372ef4131 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -467,6 +467,21 @@ Contact: Thomas Zimmermann Level: Intermediate +Request memory regions in all drivers +- + +Go through all drivers and add code to request the memory regions that the +driver uses. This requires adding calls to request_mem_region(), +pci_request_region() or similar functions. Use helpers for managed cleanup +where possible. + +Drivers are pretty bad at doing this and there used to be conflicts among +DRM and fbdev drivers. Still, it's the correct thing to do. + +Contact: Thomas Zimmermann + +Level: Starter + Core refactorings = -- 2.34.1
[PATCH 2/5] drivers/firmware: Don't mark as busy the simple-framebuffer IO resource
From: Javier Martinez Canillas The sysfb_create_simplefb() function requests a IO memory resource for the simple-framebuffer platform device, but it also marks it as busy which can lead to drivers requesting the same memory resource to fail. Let's drop the IORESOURCE_BUSY flag and let drivers to request it as busy instead. Signed-off-by: Javier Martinez Canillas --- drivers/firmware/sysfb_simplefb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/sysfb_simplefb.c b/drivers/firmware/sysfb_simplefb.c index 303a491e520d..76c4abc42a30 100644 --- a/drivers/firmware/sysfb_simplefb.c +++ b/drivers/firmware/sysfb_simplefb.c @@ -99,7 +99,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si, /* setup IORESOURCE_MEM as framebuffer memory */ memset(&res, 0, sizeof(res)); - res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; + res.flags = IORESOURCE_MEM; res.name = simplefb_resname; res.start = base; res.end = res.start + length - 1; -- 2.34.1
[PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal
Hot-unplug all firmware-framebuffer devices as part of removing
them via remove_conflicting_framebuffers() et al. Releases all
memory regions to be acquired by native drivers.
Firmware, such as EFI, install a framebuffer while posting the
computer. After removing the firmware-framebuffer device from fbdev,
a native driver takes over the hardware and the firmware framebuffer
becomes invalid.
Firmware-framebuffer drivers, specifically simplefb, don't release
their device from Linux' device hierarchy. It still owns the firmware
framebuffer and blocks the native drivers from loading. This has been
observed in the vmwgfx driver. [1]
Initiating a device removal (i.e., hot unplug) as part of
remove_conflicting_framebuffers() removes the underlying device and
returns the memory range to the system.
[1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/
Signed-off-by: Thomas Zimmermann
CC: sta...@vger.kernel.org # v5.11+
---
drivers/video/fbdev/core/fbmem.c | 29 ++---
include/linux/fb.h | 1 +
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..f73f8415b8cb 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1557,18 +1558,36 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
+ struct device *dev;
if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
continue;
gen_aper = registered_fb[i]->apertures;
+ dev = registered_fb[i]->device;
if (fb_do_apertures_overlap(gen_aper, a) ||
(primary && gen_aper && gen_aper->count &&
gen_aper->ranges[0].base == VGA_FB_PHYS)) {
printk(KERN_INFO "fb%d: switching to %s from %s\n",
i, name, registered_fb[i]->fix.id);
- do_unregister_framebuffer(registered_fb[i]);
+
+ /*
+* If we kick-out a firmware driver, we also want to
remove
+* the underlying platform device, such as
simple-framebuffer,
+* VESA, EFI, etc. A native driver will then be able to
+* allocate the memory range.
+*
+* If it's not a platform device, at least print a
warning. A
+* fix would add code to remove the device from the
system.
+*/
+ if (dev_is_platform(dev)) {
+ registered_fb[i]->forced_out = true;
+
platform_device_unregister(to_platform_device(dev));
+ } else {
+ pr_warn("fb%d: cannot remove device\n", i);
+ do_unregister_framebuffer(registered_fb[i]);
+ }
}
}
}
@@ -1898,9 +1917,13 @@ EXPORT_SYMBOL(register_framebuffer);
void
unregister_framebuffer(struct fb_info *fb_info)
{
- mutex_lock(®istration_lock);
+ bool forced_out = fb_info->forced_out;
+
+ if (!forced_out)
+ mutex_lock(®istration_lock);
do_unregister_framebuffer(fb_info);
- mutex_unlock(®istration_lock);
+ if (!forced_out)
+ mutex_unlock(®istration_lock);
}
EXPORT_SYMBOL(unregister_framebuffer);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3da95842b207..9a14f3f8a329 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -502,6 +502,7 @@ struct fb_info {
} *apertures;
bool skip_vt_switch; /* no VT switch on suspend/resume required */
+ bool forced_out; /* set when being removed by another driver */
};
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
--
2.34.1
[PATCH 3/5] drm/simpledrm: Request memory region in driver
Requesting the framebuffer memory in simpledrm marks the memory
range as busy. This used to be done by the firmware sysfb code,
but the driver is the correct place.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 04146da2d1d8..f72b71511a65 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -526,21 +526,31 @@ static int simpledrm_device_init_mm(struct
simpledrm_device *sdev)
{
struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
- struct resource *mem;
+ struct resource *res, *mem;
void __iomem *screen_base;
int ret;
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
return -EINVAL;
- ret = devm_aperture_acquire_from_firmware(dev, mem->start,
resource_size(mem));
+ ret = devm_aperture_acquire_from_firmware(dev, res->start,
resource_size(res));
if (ret) {
drm_err(dev, "could not acquire memory range %pr: error %d\n",
- mem, ret);
+ res, ret);
return ret;
}
+ mem = devm_request_mem_region(&pdev->dev, res->start,
resource_size(res),
+ sdev->dev.driver->name);
+ if (!mem) {
+ /*
+* We cannot make this fatal. Sometimes this comes from magic
+* spaces our resource handlers simply don't know about
+*/
+ drm_warn(dev, "could not acquire memory region %pr\n", res);
+ }
+
screen_base = devm_ioremap_wc(&pdev->dev, mem->start,
resource_size(mem));
if (!screen_base)
--
2.34.1
[PATCH 4/5] fbdev/simplefb: Request memory region in driver
Requesting the framebuffer memory in simpledrm marks the memory
range as busy. This used to be done by the firmware sysfb code,
but the driver is the correct place.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/simplefb.c | 59 --
1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 57541887188b..84452028ecc9 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -66,16 +66,36 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int
green, u_int blue,
return 0;
}
-struct simplefb_par;
+struct simplefb_par {
+ u32 palette[PSEUDO_PALETTE_SIZE];
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ bool clks_enabled;
+ unsigned int clk_count;
+ struct clk **clks;
+#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ bool regulators_enabled;
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
+ bool release_mem_region;
+};
+
static void simplefb_clocks_destroy(struct simplefb_par *par);
static void simplefb_regulators_destroy(struct simplefb_par *par);
static void simplefb_destroy(struct fb_info *info)
{
+ struct simplefb_par *par = info->par;
+
simplefb_regulators_destroy(info->par);
simplefb_clocks_destroy(info->par);
if (info->screen_base)
iounmap(info->screen_base);
+
+ if (par->release_mem_region)
+ release_mem_region(info->apertures->ranges[0].base,
+ info->apertures->ranges[0].size);
}
static const struct fb_ops simplefb_ops = {
@@ -169,20 +189,6 @@ static int simplefb_parse_pd(struct platform_device *pdev,
return 0;
}
-struct simplefb_par {
- u32 palette[PSEUDO_PALETTE_SIZE];
-#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
- bool clks_enabled;
- unsigned int clk_count;
- struct clk **clks;
-#endif
-#if defined CONFIG_OF && defined CONFIG_REGULATOR
- bool regulators_enabled;
- u32 regulator_count;
- struct regulator **regulators;
-#endif
-};
-
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
/*
* Clock handling code.
@@ -401,6 +407,7 @@ static void simplefb_regulators_destroy(struct simplefb_par
*par) { }
static int simplefb_probe(struct platform_device *pdev)
{
+ bool request_mem_succeeded = false;
int ret;
struct simplefb_params params;
struct fb_info *info;
@@ -436,9 +443,22 @@ static int simplefb_probe(struct platform_device *pdev)
return -EINVAL;
}
+ if (request_mem_region(mem->start, resource_size(mem), "simplefb")) {
+ request_mem_succeeded = true;
+ } else {
+ /*
+* We cannot make this fatal. Sometimes this comes from magic
+* spaces our resource handlers simply don't know about
+*/
+ dev_warn(&pdev->dev, "simplefb: cannot reserve video memory at
%pR\n",
+mem);
+ }
+
info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
- if (!info)
- return -ENOMEM;
+ if (!info) {
+ ret = -ENOMEM;
+ goto error_release_mem_region;
+ }
platform_set_drvdata(pdev, info);
par = info->par;
@@ -495,6 +515,8 @@ static int simplefb_probe(struct platform_device *pdev)
info->var.xres, info->var.yres,
info->var.bits_per_pixel, info->fix.line_length);
+ par->release_mem_region = request_mem_succeeded;
+
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
@@ -513,6 +535,9 @@ static int simplefb_probe(struct platform_device *pdev)
iounmap(info->screen_base);
error_fb_release:
framebuffer_release(info);
+error_release_mem_region:
+ if (request_mem_succeeded)
+ release_mem_region(mem->start, resource_size(mem));
return ret;
}
--
2.34.1
[PATCH 0/5] sysfb: Fix memory-region management
Request framebuffer memory in simpledrm and simplefb. Do a hot-unplug operation when removing fbdev firmware drivers. After being unloaded by a hardware driver, simplefb leaves behind the firmware framebuffer's platform device. This prevents other drivers from acquiring the memory as reported at [1]. Patch 1 changes the removal code of remove_conflicting_framebuffers() to remove the underlying device and the rsp memory region. Patches 2 to 4 update sysfb and its drivers. The sysfb code does no longer mark the framebuffer memory with IORESOURCE_BUSY. Instead, the device drivers acquire the memory when they probe the device. Patch 5 adds a todo item to acquire memory regions in all DRM drivers. Tested with simpledrm and simplefb. [1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/ Javier Martinez Canillas (1): drivers/firmware: Don't mark as busy the simple-framebuffer IO resource Thomas Zimmermann (4): fbdev: Hot-unplug firmware fb devices on forced removal drm/simpledrm: Request memory region in driver fbdev/simplefb: Request memory region in driver drm: Add TODO item for requesting memory regions Documentation/gpu/todo.rst| 15 drivers/firmware/sysfb_simplefb.c | 2 +- drivers/gpu/drm/tiny/simpledrm.c | 20 --- drivers/video/fbdev/core/fbmem.c | 29 +-- drivers/video/fbdev/simplefb.c| 59 ++- include/linux/fb.h| 1 + 6 files changed, 100 insertions(+), 26 deletions(-) base-commit: 0bb81b5d6db5f689b67f9d8b35323235c45e890f -- 2.34.1
Re: [PATCH v3] drm/ast: Don't check new mode if CRTC is being disabled
Hi Am 21.01.22 um 16:25 schrieb dann frazier: [...] hey, I'm seeing a regression that I bisected down to this change. I installed GNOME on a couple of different server models that have AMI-based BMCs, which provide a web-based graphics display (virtual KVM). When I enter the lock screen on current upstream kernels, the display freezes, and I see the following messages appear in syslog whenever I generate keyboard/mouse events on that display: Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded: drmModeAtomicCommit: Invalid argument Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded: drmModeAtomicCommit: Invalid argument Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded: drmModeAtomicCommit: Invalid argument Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update: drmModeAtomicCommit: Invalid argument Thanks for reporting. I'll investigate soon. Best regards Thomas If I back out this change w/ the following patch (code has evolved slightly preventing a clean revert), then the lock screen once again behaves normally: diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 956c8982192b..336c545c46f5 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -1012,9 +1012,6 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, const struct drm_format_info *format; bool succ; - if (!crtc_state->enable) - return 0; /* no mode checks if CRTC is being disabled */ - ast_state = to_ast_crtc_state(crtc_state); format = ast_state->format; Apologies for noticing so long after the fact. I don't normally run a desktop environment on these servers, I just happened to be debugging something recently that required it. -dann -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[PATCH v2] drm/i915/selftests: Fix NULL vs IS_ERR checking for kernel_context
Since i915_gem_create_context() function return error pointers,
the kernel_context() function does not return null, It returns error
pointers too. Using IS_ERR() to check the return value to fix this.
Signed-off-by: Miaoqian Lin
---
Changes in v2:
- clean up unneeded initialization of err.
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 43 ++--
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index b367ecfa42de..0d453ddcede4 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -1531,7 +1531,7 @@ static int live_busywait_preempt(void *arg)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
enum intel_engine_id id;
- int err = -ENOMEM;
+ int err;
u32 *map;
/*
@@ -1540,13 +1540,16 @@ static int live_busywait_preempt(void *arg)
*/
ctx_hi = kernel_context(gt->i915, NULL);
- if (!ctx_hi)
- return -ENOMEM;
+ if (IS_ERR(ctx_hi))
+ return IS_ERR(ctx_hi);
+
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
ctx_lo = kernel_context(gt->i915, NULL);
- if (!ctx_lo)
+ if (IS_ERR(ctx_lo)) {
+ err = PTR_ERR(ctx_lo);
goto err_ctx_hi;
+ }
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
@@ -1742,13 +1745,17 @@ static int live_preempt(void *arg)
goto err_spin_hi;
ctx_hi = kernel_context(gt->i915, NULL);
- if (!ctx_hi)
+ if (IS_ERR(ctx_hi)) {
+ err = PTR_ERR(ctx_hi);
goto err_spin_lo;
+ }
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
ctx_lo = kernel_context(gt->i915, NULL);
- if (!ctx_lo)
+ if (IS_ERR(ctx_lo)) {
+ err = PTR_ERR(ctx_lo);
goto err_ctx_hi;
+ }
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
for_each_engine(engine, gt, id) {
@@ -1834,12 +1841,16 @@ static int live_late_preempt(void *arg)
goto err_spin_hi;
ctx_hi = kernel_context(gt->i915, NULL);
- if (!ctx_hi)
+ if (IS_ERR(ctx_hi)) {
+ err = PTR_ERR(ctx_hi);
goto err_spin_lo;
+ }
ctx_lo = kernel_context(gt->i915, NULL);
- if (!ctx_lo)
+ if (IS_ERR(ctx_lo)) {
+ err = PTR_ERR(ctx_lo);
goto err_ctx_hi;
+ }
/* Make sure ctx_lo stays before ctx_hi until we trigger preemption. */
ctx_lo->sched.priority = 1;
@@ -1928,8 +1939,8 @@ struct preempt_client {
static int preempt_client_init(struct intel_gt *gt, struct preempt_client *c)
{
c->ctx = kernel_context(gt->i915, NULL);
- if (!c->ctx)
- return -ENOMEM;
+ if (IS_ERR(c->ctx))
+ return PTR_ERR(c->ctx);
if (igt_spinner_init(&c->spin, gt))
goto err_ctx;
@@ -3385,13 +3396,17 @@ static int live_preempt_timeout(void *arg)
return -ENOMEM;
ctx_hi = kernel_context(gt->i915, NULL);
- if (!ctx_hi)
+ if (IS_ERR(ctx_hi)) {
+ err = PTR_ERR(ctx_hi);
goto err_spin_lo;
+ }
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
ctx_lo = kernel_context(gt->i915, NULL);
- if (!ctx_lo)
+ if (IS_ERR(ctx_lo)) {
+ err = PTR_ERR(ctx_lo);
goto err_ctx_hi;
+ }
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
for_each_engine(engine, gt, id) {
@@ -3683,8 +3698,10 @@ static int live_preempt_smoke(void *arg)
for (n = 0; n < smoke.ncontext; n++) {
smoke.contexts[n] = kernel_context(smoke.gt->i915, NULL);
- if (!smoke.contexts[n])
+ if (IS_ERR(smoke.contexts[n])) {
+ err = PTR_ERR(smoke.contexts[n]);
goto err_ctx;
+ }
}
for (n = 0; n < ARRAY_SIZE(phase); n++) {
--
2.17.1
[PATCH] drm/i915: Lock dpt_obj around set_cache_level.
set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221] WARN_ON(debug_locks &&
!(lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map) != 0))
<4> [184.578237] WARNING: CPU: 6 PID: 5544 at
drivers/gpu/drm/i915/i915_gem.c:123 i915_gem_object_unbind+0x4a9/0x510 [i915]
<4> [184.578323] Modules linked in: vgem drm_shmem_helper snd_hda_codec_hdmi
i915 mei_hdcp x86_pkg_temp_thermal snd_hda_intel coretemp crct10dif_pclmul
snd_intel_dspcfg crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel snd_hwdep
drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm sysfillrect
mei pps_core sysimgblt fb_sys_fops prime_numbers intel_lpss_pci smsc75xx usbnet
mii
<4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted
5.16.0-CI-Patchwork_22006+ #1
<4> [184.578351] Hardware name: Intel Corporation Alder Lake Client
Platform/AlderLake-P DDR4 RVP, BIOS ADLPFWI1.R00.2422.A00.2110131104 10/13/2021
<4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510 [i915]
<4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b e1 85 c0 0f 85
b1 fb ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1 a0 e8 a3 54 26 e1 <0f> 0b e9
97 fb ff ff 31 ed 48 8b 5c 24 58 65 48 33 1c 25 28 00 00
<4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
<4> [184.578428] RAX: RBX: c900013b3bb0 RCX:
0001
<4> [184.578429] RDX: 8001 RSI: 8230b42d RDI:
<4> [184.578430] RBP: 888120e1 R08: R09:
c0007fff
<4> [184.578431] R10: 0001 R11: c900013b3980 R12:
8881176ea740
<4> [184.578432] R13: 888120e1 R14: R15:
0001
<4> [184.578433] FS: 7f65074f5e40() GS:8f30()
knlGS:
<4> [184.578435] CS: 0010 DS: ES: CR0: 80050033
<4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4:
00770ee0
<4> [184.578437] PKRU: 5554
<4> [184.578438] Call Trace:
<4> [184.578439]
<4> [184.578440] ? dma_resv_iter_first_unlocked+0x78/0xf0
<4> [184.578447] intel_dpt_create+0x88/0x220 [i915]
<4> [184.578530] intel_framebuffer_init+0x5b8/0x620 [i915]
<4> [184.578612] intel_framebuffer_create+0x3d/0x60 [i915]
<4> [184.578691] intel_user_framebuffer_create+0x18f/0x2c0 [i915]
<4> [184.578775] drm_internal_framebuffer_create+0x36d/0x4c0
<4> [184.578779] drm_mode_addfb2+0x2f/0xd0
<4> [184.578781] ? drm_mode_addfb_ioctl+0x10/0x10
<4> [184.578784] drm_ioctl_kernel+0xac/0x140
<4> [184.578787] drm_ioctl+0x201/0x3d0
<4> [184.578789] ? drm_mode_addfb_ioctl+0x10/0x10
<4> [184.578796] __x64_sys_ioctl+0x6a/0xa0
<4> [184.578800] do_syscall_64+0x37/0xb0
<4> [184.578803] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [184.578805] RIP: 0033:0x7f6506736317
<4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
<4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246 ORIG_RAX:
0010
<4> [184.578810] RAX: ffda RBX: 0006 RCX:
7f6506736317
<4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI:
0006
<4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09:
<4> [184.578813] R10: 0008 R11: 0246 R12:
c06864b8
<4> [184.578813] R13: 0006 R14: R15:
<4> [184.578819]
<4> [184.578820] irq event stamp: 47931
<4> [184.578821] hardirqs last enabled at (47937): []
__up_console_sem+0x62/0x70
<4> [184.578824] hardirqs last disabled at (47942): []
__up_console_sem+0x47/0x70
<4> [184.578826] softirqs last enabled at (47340): []
__do_softirq+0x32d/0x493
<4> [184.578828] softirqs last disabled at (47335): []
irq_exit_rcu+0xa6/0xe0
<4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---
Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and take obj lock
for i915_vma_unbind, v2.")
Signed-off-by: Maarten Lankhorst
Testcase: kms_addfb_basic
---
drivers/gpu/drm/i915/display/intel_dpt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 63a83d5f85a1..c2f8f853db90 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -253,7 +253,11 @@ intel_dpt_create(struct intel_framebuffer *fb)
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
- ret = i915_gem_object_set_cache_level(dpt_obj, I915_CACHE_NONE);
+ ret = i915_gem_object_lock_interruptible(dpt_obj, NULL);
+ if (!ret) {
+ ret = i915_gem_object_set_c
Add WARN_ON nested dma_fence containers
Hi guys, as previously discussed only dma_fence_chain with its previous fence is actually made to build up larger dma_fence structures. Everything else should either flatten all fences into a single dma_fence_array or just add each fence separately to the dma_resv object. Please review and/or comment, Christian.
[PATCH 01/11] drm/radeon: use ttm_resource_manager_debug
Instead of calling the debug operation directly. Signed-off-by: Christian König Reviewed-by: Huang Rui --- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 11b21d605584..0d1283cdc8fb 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -802,7 +802,7 @@ static int radeon_mm_vram_dump_table_show(struct seq_file *m, void *unused) TTM_PL_VRAM); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } @@ -820,7 +820,7 @@ static int radeon_mm_gtt_dump_table_show(struct seq_file *m, void *unused) TTM_PL_TT); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } -- 2.25.1
[PATCH 06/11] dma-buf: warn about containers in dma_resv object
Drivers should not add containers as shared fences to the dma_resv object, instead each fence should be added individually. Signed-off-by: Christian König Reviewed-by: Daniel Vetter --- drivers/dma-buf/dma-resv.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 6dd9a40b55d4..e8a0c1d51da2 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -256,6 +256,11 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence) dma_resv_assert_held(obj); + /* Drivers should not add containers here, instead add each fence +* individually. +*/ + WARN_ON(dma_fence_is_container(fence)); + fobj = dma_resv_shared_list(obj); count = fobj->shared_count; -- 2.25.1
[PATCH 03/11] dma-buf: consolidate dma_fence subclass checking
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
include/linux/dma-fence-array.h | 15 +
include/linux/dma-fence-chain.h | 3 +--
include/linux/dma-fence.h | 38 +
3 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..fec374f69e12 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -45,19 +45,6 @@ struct dma_fence_array {
struct irq_work work;
};
-extern const struct dma_fence_ops dma_fence_array_ops;
-
-/**
- * dma_fence_is_array - check if a fence is from the array subsclass
- * @fence: fence to test
- *
- * Return true if it is a dma_fence_array and false otherwise.
- */
-static inline bool dma_fence_is_array(struct dma_fence *fence)
-{
- return fence->ops == &dma_fence_array_ops;
-}
-
/**
* to_dma_fence_array - cast a fence to a dma_fence_array
* @fence: fence to cast to a dma_fence_array
@@ -68,7 +55,7 @@ static inline bool dma_fence_is_array(struct dma_fence *fence)
static inline struct dma_fence_array *
to_dma_fence_array(struct dma_fence *fence)
{
- if (fence->ops != &dma_fence_array_ops)
+ if (!fence || !dma_fence_is_array(fence))
return NULL;
return container_of(fence, struct dma_fence_array, base);
diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h
index 54fe3443fd2c..ee906b659694 100644
--- a/include/linux/dma-fence-chain.h
+++ b/include/linux/dma-fence-chain.h
@@ -49,7 +49,6 @@ struct dma_fence_chain {
spinlock_t lock;
};
-extern const struct dma_fence_ops dma_fence_chain_ops;
/**
* to_dma_fence_chain - cast a fence to a dma_fence_chain
@@ -61,7 +60,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops;
static inline struct dma_fence_chain *
to_dma_fence_chain(struct dma_fence *fence)
{
- if (!fence || fence->ops != &dma_fence_chain_ops)
+ if (!fence || !dma_fence_is_chain(fence))
return NULL;
return container_of(fence, struct dma_fence_chain, base);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 1ea691753bd3..775cdc0b4f24 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -587,4 +587,42 @@ struct dma_fence *dma_fence_get_stub(void);
struct dma_fence *dma_fence_allocate_private_stub(void);
u64 dma_fence_context_alloc(unsigned num);
+extern const struct dma_fence_ops dma_fence_array_ops;
+extern const struct dma_fence_ops dma_fence_chain_ops;
+
+/**
+ * dma_fence_is_array - check if a fence is from the array subclass
+ * @fence: the fence to test
+ *
+ * Return true if it is a dma_fence_array and false otherwise.
+ */
+static inline bool dma_fence_is_array(struct dma_fence *fence)
+{
+ return fence->ops == &dma_fence_array_ops;
+}
+
+/**
+ * dma_fence_is_chain - check if a fence is from the chain subclass
+ * @fence: the fence to test
+ *
+ * Return true if it is a dma_fence_chain and false otherwise.
+ */
+static inline bool dma_fence_is_chain(struct dma_fence *fence)
+{
+ return fence->ops == &dma_fence_chain_ops;
+}
+
+/**
+ * dma_fence_is_container - check if a fence is a container for other fences
+ * @fence: the fence to test
+ *
+ * Return true if this fence is a container for other fences, false otherwise.
+ * This is important since we can't build up large fence structure or otherwise
+ * we run into recursion during operation on those fences.
+ */
+static inline bool dma_fence_is_container(struct dma_fence *fence)
+{
+ return dma_fence_is_array(fence) || dma_fence_is_chain(fence);
+}
+
#endif /* __LINUX_DMA_FENCE_H */
--
2.25.1
[PATCH 02/11] drm/amdgpu: use ttm_resource_manager_debug
Instead of calling the debug operation directly. Signed-off-by: Christian König Reviewed-by: Huang Rui --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index fb0d8bffdce2..eac2ff4647e3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -2076,7 +2076,7 @@ static int amdgpu_mm_vram_table_show(struct seq_file *m, void *unused) TTM_PL_VRAM); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } @@ -2094,7 +2094,7 @@ static int amdgpu_mm_tt_table_show(struct seq_file *m, void *unused) TTM_PL_TT); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } @@ -2105,7 +2105,7 @@ static int amdgpu_mm_gds_table_show(struct seq_file *m, void *unused) AMDGPU_PL_GDS); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } @@ -2116,7 +2116,7 @@ static int amdgpu_mm_gws_table_show(struct seq_file *m, void *unused) AMDGPU_PL_GWS); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } @@ -2127,7 +2127,7 @@ static int amdgpu_mm_oa_table_show(struct seq_file *m, void *unused) AMDGPU_PL_OA); struct drm_printer p = drm_seq_file_printer(m); - man->func->debug(man, &p); + ttm_resource_manager_debug(man, &p); return 0; } -- 2.25.1
[PATCH 05/11] dma-buf: Warn about dma_fence_chain container rules v2
Chaining of dma_fence_chain objects is only allowed through the prev fence and not through the contained fence. Warn about that when we create a dma_fence_chain. v2: fix comment style Signed-off-by: Christian König Reviewed-by: Daniel Vetter Reviewed-by: Thomas Hellström --- drivers/dma-buf/dma-fence-chain.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index 1b4cb3e5cec9..084c6927b735 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -254,5 +254,14 @@ void dma_fence_chain_init(struct dma_fence_chain *chain, dma_fence_init(&chain->base, &dma_fence_chain_ops, &chain->lock, context, seqno); + + /* +* Chaining dma_fence_chain container together is only allowed through +* the prev fence and not through the contained fence. +* +* The correct way of handling this is to flatten out the fence +* structure into a dma_fence_array by the caller instead. +*/ + WARN_ON(dma_fence_is_chain(fence)); } EXPORT_SYMBOL(dma_fence_chain_init); -- 2.25.1
[PATCH 04/11] dma-buf: warn about dma_fence_array container rules v2
It's not allowed to nest another dma_fence container into a dma_fence_array or otherwise we can run into recursion. Warn about that when we create a dma_fence_array. v2: fix comment style and typo in the warning pointed out by Thomas Signed-off-by: Christian König Reviewed-by: Daniel Vetter --- drivers/dma-buf/dma-fence-array.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 3e07f961e2f3..cb1bacb5a42b 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -176,6 +176,20 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, array->base.error = PENDING_ERROR; + /* +* dma_fence_array objects should never contain any other fence +* containers or otherwise we run into recursion and potential kernel +* stack overflow on operations on the dma_fence_array. +* +* The correct way of handling this is to flatten out the array by the +* caller instead. +* +* Enforce this here by checking that we don't create a dma_fence_array +* with any container inside. +*/ + while (num_fences--) + WARN_ON(dma_fence_is_container(fences[num_fences])); + return array; } EXPORT_SYMBOL(dma_fence_array_create); -- 2.25.1
[PATCH 07/11] dma-buf: Add dma_fence_array_for_each (v2)
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
- Return NULL from dma_fence_array_next if index > array->num_fences.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
Reviewed-by: Christian König
Cc: Daniel Vetter
Cc: Maarten Lankhorst
---
drivers/dma-buf/dma-fence-array.c | 27 +++
include/linux/dma-fence-array.h | 17 +
2 files changed, 44 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index cb1bacb5a42b..52b85d292383 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -219,3 +219,30 @@ bool dma_fence_match_context(struct dma_fence *fence, u64
context)
return true;
}
EXPORT_SYMBOL(dma_fence_match_context);
+
+struct dma_fence *dma_fence_array_first(struct dma_fence *head)
+{
+ struct dma_fence_array *array;
+
+ if (!head)
+ return NULL;
+
+ array = to_dma_fence_array(head);
+ if (!array)
+ return head;
+
+ return array->fences[0];
+}
+EXPORT_SYMBOL(dma_fence_array_first);
+
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+ unsigned int index)
+{
+ struct dma_fence_array *array = to_dma_fence_array(head);
+
+ if (!array || index >= array->num_fences)
+ return NULL;
+
+ return array->fences[index];
+}
+EXPORT_SYMBOL(dma_fence_array_next);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index fec374f69e12..e34dcb0bb462 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -61,6 +61,19 @@ to_dma_fence_array(struct dma_fence *fence)
return container_of(fence, struct dma_fence_array, base);
}
+/**
+ * dma_fence_array_for_each - iterate over all fences in array
+ * @fence: current fence
+ * @index: index into the array
+ * @head: potential dma_fence_array object
+ *
+ * Test if @array is a dma_fence_array object and if yes iterate over all
fences
+ * in the array. If not just iterate over the fence in @array itself.
+ */
+#define dma_fence_array_for_each(fence, index, head) \
+ for (index = 0, fence = dma_fence_array_first(head); fence; \
+++(index), fence = dma_fence_array_next(head, index))
+
struct dma_fence_array *dma_fence_array_create(int num_fences,
struct dma_fence **fences,
u64 context, unsigned seqno,
@@ -68,4 +81,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
bool dma_fence_match_context(struct dma_fence *fence, u64 context);
+struct dma_fence *dma_fence_array_first(struct dma_fence *head);
+struct dma_fence *dma_fence_array_next(struct dma_fence *head,
+ unsigned int index);
+
#endif /* __LINUX_DMA_FENCE_ARRAY_H */
--
2.25.1
[PATCH 08/11] dma-buf: add dma_fence_chain_contained helper
It's a reoccurring pattern that we need to extract the fence
from a dma_fence_chain object. Add a helper for this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 6 ++
include/linux/dma-fence-chain.h | 15 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index 084c6927b735..06f8ef97c6e8 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -148,8 +148,7 @@ static bool dma_fence_chain_enable_signaling(struct
dma_fence *fence)
dma_fence_get(&head->base);
dma_fence_chain_for_each(fence, &head->base) {
- struct dma_fence_chain *chain = to_dma_fence_chain(fence);
- struct dma_fence *f = chain ? chain->fence : fence;
+ struct dma_fence *f = dma_fence_chain_contained(fence);
dma_fence_get(f);
if (!dma_fence_add_callback(f, &head->cb, dma_fence_chain_cb)) {
@@ -165,8 +164,7 @@ static bool dma_fence_chain_enable_signaling(struct
dma_fence *fence)
static bool dma_fence_chain_signaled(struct dma_fence *fence)
{
dma_fence_chain_for_each(fence, fence) {
- struct dma_fence_chain *chain = to_dma_fence_chain(fence);
- struct dma_fence *f = chain ? chain->fence : fence;
+ struct dma_fence *f = dma_fence_chain_contained(fence);
if (!dma_fence_is_signaled(f)) {
dma_fence_put(fence);
diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h
index ee906b659694..10d51bcdf7b7 100644
--- a/include/linux/dma-fence-chain.h
+++ b/include/linux/dma-fence-chain.h
@@ -66,6 +66,21 @@ to_dma_fence_chain(struct dma_fence *fence)
return container_of(fence, struct dma_fence_chain, base);
}
+/**
+ * dma_fence_chain_contained - return the contained fence
+ * @fence: the fence to test
+ *
+ * If the fence is a dma_fence_chain the function returns the fence contained
+ * inside the chain object, otherwise it returns the fence itself.
+ */
+static inline struct dma_fence *
+dma_fence_chain_contained(struct dma_fence *fence)
+{
+ struct dma_fence_chain *chain = to_dma_fence_chain(fence);
+
+ return chain ? chain->fence : fence;
+}
+
/**
* dma_fence_chain_alloc
*
--
2.25.1
[PATCH 11/11] drm/vmwgfx: remove vmw_wait_dma_fence
Decomposing fence containers don't seem to make any sense here.
So just remove the function entirely and call dma_fence_wait() directly.
Signed-off-by: Christian König
Cc: VMware Graphics
Cc: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 46 -
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 3 --
3 files changed, 1 insertion(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 44ca23b0ea4e..0ff28f0e3eb4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -4500,7 +4500,7 @@ int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
goto mksstats_out;
}
- ret = vmw_wait_dma_fence(dev_priv->fman, in_fence);
+ ret = dma_fence_wait(in_fence, true);
if (ret)
goto out;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index c60d395f9e2e..430f83a1847c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -621,52 +621,6 @@ int vmw_user_fence_create(struct drm_file *file_priv,
return ret;
}
-
-/**
- * vmw_wait_dma_fence - Wait for a dma fence
- *
- * @fman: pointer to a fence manager
- * @fence: DMA fence to wait on
- *
- * This function handles the case when the fence is actually a fence
- * array. If that's the case, it'll wait on each of the child fence
- */
-int vmw_wait_dma_fence(struct vmw_fence_manager *fman,
- struct dma_fence *fence)
-{
- struct dma_fence_array *fence_array;
- int ret = 0;
- int i;
-
-
- if (dma_fence_is_signaled(fence))
- return 0;
-
- if (!dma_fence_is_array(fence))
- return dma_fence_wait(fence, true);
-
- /* From i915: Note that if the fence-array was created in
-* signal-on-any mode, we should *not* decompose it into its individual
-* fences. However, we don't currently store which mode the fence-array
-* is operating in. Fortunately, the only user of signal-on-any is
-* private to amdgpu and we should not see any incoming fence-array
-* from sync-file being in signal-on-any mode.
-*/
-
- fence_array = to_dma_fence_array(fence);
- for (i = 0; i < fence_array->num_fences; i++) {
- struct dma_fence *child = fence_array->fences[i];
-
- ret = dma_fence_wait(child, true);
-
- if (ret < 0)
- return ret;
- }
-
- return 0;
-}
-
-
/*
* vmw_fence_fifo_down - signal all unsignaled fence objects.
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h
index 079ab4f3ba51..a7eee579c76a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h
@@ -104,9 +104,6 @@ extern int vmw_user_fence_create(struct drm_file *file_priv,
struct vmw_fence_obj **p_fence,
uint32_t *p_handle);
-extern int vmw_wait_dma_fence(struct vmw_fence_manager *fman,
- struct dma_fence *fence);
-
extern void vmw_fence_fifo_up(struct vmw_fence_manager *fman);
extern void vmw_fence_fifo_down(struct vmw_fence_manager *fman);
--
2.25.1
[PATCH 10/11] drm/i915: use dma_fence extractor functions
Instead of manually messing with the data structures use the iterators
and extraction helpers provided by the framework.
This whole handling should essentially go away when boost handling is
implemented in the core dma-buf framework.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 40 ++--
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 31
drivers/gpu/drm/i915/i915_request.c | 47 +++-
3 files changed, 33 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 470fdfd61a0f..4ea7a5b26405 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -41,6 +41,8 @@ static __always_inline unsigned int
__busy_set_if_active(struct dma_fence *fence, u32 (*flag)(u16 id))
{
const struct i915_request *rq;
+ struct dma_fence *current_fence;
+ unsigned int i;
/*
* We have to check the current hw status of the fence as the uABI
@@ -58,40 +60,22 @@ __busy_set_if_active(struct dma_fence *fence, u32
(*flag)(u16 id))
*
* 2. A single i915 request.
*/
- if (dma_fence_is_array(fence)) {
- struct dma_fence_array *array = to_dma_fence_array(fence);
- struct dma_fence **child = array->fences;
- unsigned int nchild = array->num_fences;
-
- do {
- struct dma_fence *current_fence = *child++;
-
- /* Not an i915 fence, can't be busy per above */
- if (!dma_fence_is_i915(current_fence) ||
- !test_bit(I915_FENCE_FLAG_COMPOSITE,
- ¤t_fence->flags)) {
- return 0;
- }
-
- rq = to_request(current_fence);
- if (!i915_request_completed(rq))
- return flag(rq->engine->uabi_class);
- } while (--nchild);
-
- /* All requests in array complete, not busy */
- return 0;
- } else {
- if (!dma_fence_is_i915(fence))
- return 0;
+ dma_fence_array_for_each(current_fence, i, fence) {
- rq = to_request(fence);
- if (i915_request_completed(rq))
+ /* Not an i915 fence, can't be busy per above */
+ if (!dma_fence_is_i915(current_fence) ||
+ !test_bit(I915_FENCE_FLAG_COMPOSITE, ¤t_fence->flags))
return 0;
+ rq = to_request(current_fence);
/* Beware type-expansion follies! */
BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
- return flag(rq->engine->uabi_class);
+ if (!i915_request_completed(rq))
+ return flag(rq->engine->uabi_class);
}
+
+ /* All requests in array complete, not busy */
+ return 0;
}
static __always_inline unsigned int
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index dab3d30c09a0..13f37b6aedf7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -72,11 +72,6 @@ static void fence_set_priority(struct dma_fence *fence,
rcu_read_unlock();
}
-static inline bool __dma_fence_is_chain(const struct dma_fence *fence)
-{
- return fence->ops == &dma_fence_chain_ops;
-}
-
void i915_gem_fence_wait_priority(struct dma_fence *fence,
const struct i915_sched_attr *attr)
{
@@ -85,25 +80,15 @@ void i915_gem_fence_wait_priority(struct dma_fence *fence,
local_bh_disable();
- /* Recurse once into a fence-array */
- if (dma_fence_is_array(fence)) {
- struct dma_fence_array *array = to_dma_fence_array(fence);
- int i;
+ /* The chain is ordered; if we boost the last, we boost all */
+ dma_fence_chain_for_each(fence, fence) {
+ struct dma_fence *array, *element;
+ unsigned int i;
- for (i = 0; i < array->num_fences; i++)
- fence_set_priority(array->fences[i], attr);
- } else if (__dma_fence_is_chain(fence)) {
- struct dma_fence *iter;
-
- /* The chain is ordered; if we boost the last, we boost all */
- dma_fence_chain_for_each(iter, fence) {
- fence_set_priority(to_dma_fence_chain(iter)->fence,
- attr);
- break;
- }
- dma_fence_put(iter);
- } else {
- fence_set_priority(fence, attr);
+ /* Recurse once into a fence-array */
+ array = dma_fence_chain_contained(fence);
+ dma_f
[PATCH 09/11] drm/amdgpu: use dma_fence_chain_contained
Instead of manually extracting the fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index f7d8487799b2..40e06745fae9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -261,10 +261,9 @@ int amdgpu_sync_resv(struct amdgpu_device *adev, struct
amdgpu_sync *sync,
dma_resv_for_each_fence(&cursor, resv, true, f) {
dma_fence_chain_for_each(f, f) {
- struct dma_fence_chain *chain = to_dma_fence_chain(f);
+ struct dma_fence *tmp = dma_fence_chain_contained(f);
- if (amdgpu_sync_test_fence(adev, mode, owner, chain ?
- chain->fence : f)) {
+ if (amdgpu_sync_test_fence(adev, mode, owner, tmp)) {
r = amdgpu_sync_fence(sync, f);
dma_fence_put(f);
if (r)
--
2.25.1
Re: [PATCH 1/2] drm/i915/guc: Don't check CT descriptor status before CT write / read
On Fri, 21 Jan 2022, Matthew Brost wrote:
> On Fri, Jan 21, 2022 at 09:28:46AM +0200, Jani Nikula wrote:
>> On Thu, 20 Jan 2022, Matthew Brost wrote:
>> > Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
>> > set, before CT write / read as this could result in a read across the
>> > PCIe bus thus adding latency to every CT write / read. On well behavied
>> > systems this vaue should always read as zero. For some reason it doesn't
>> > the CT channel is broken and will eventually recover from a GT reset,
>> > albeit the GT reset will not be triggered immediately by seeing that
>> > descriptor status is non-zero.
>> >
>> > v2:
>> > (CI)
>> > - Fix build error (hide corrupted label in write function behind
>> > CONFIG_DRM_I915_DEBUG_GUC)
>> >
>> > Signed-off-by: Matthew Brost
>> > ---
>> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++
>> > 1 file changed, 6 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> > index de89d40abd38d..948cf31429412 100644
>> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> > @@ -379,8 +379,10 @@ static int ct_write(struct intel_guc_ct *ct,
>> >u32 *cmds = ctb->cmds;
>> >unsigned int i;
>> >
>> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
>> >if (unlikely(desc->status))
>> >goto corrupted;
>> > +#endif
>>
>> Please don't add #ifdefs inline. You can use
>> IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC) in if statements, but otherwise
>> the code needs to be split out to a separate function.
>>
>
> Sure, but I feel like I've actually been by someone else to not use the
> IS_ENABLED macro and use ifdefs inlines...
Citation needed.
Basically never use #if/#ifdef inline. Only use them at the top level
like this:
#if IS_ENABLED(CONFIG_FOO)
static int bar(void)
{
/* implementation with foo */
}
#else
static int bar(void)
{
/* implementation without foo */
}
#endif
Sometimes you can avoid the above boilerplate with IS_ENABLED() inline:
if (IS_ENABLED(CONFIG_FOO))
...
Basically if you think #if/#ifdef inline is the easiest, you need to
refactor the code to do it cleanly without them.
BR,
Jani.
>
> Matt
>
>> BR,
>> Jani.
>>
>> >
>> >GEM_BUG_ON(tail > size);
>> >
>> > @@ -445,11 +447,13 @@ static int ct_write(struct intel_guc_ct *ct,
>> >
>> >return 0;
>> >
>> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
>> > corrupted:
>> >CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>> > desc->head, desc->tail, desc->status);
>> >ctb->broken = true;
>> >return -EPIPE;
>> > +#endif
>> > }
>> >
>> > /**
>> > @@ -815,8 +819,10 @@ static int ct_read(struct intel_guc_ct *ct, struct
>> > ct_incoming_msg **msg)
>> >if (unlikely(ctb->broken))
>> >return -EPIPE;
>> >
>> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
>> >if (unlikely(desc->status))
>> >goto corrupted;
>> > +#endif
>> >
>> >GEM_BUG_ON(head > size);
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v4 1/2] i915/gvt: Introduce the mmio_info_table.c to support VFIO new mdev API
On Mon, Jan 24, 2022 at 12:12:12PM +0200, zhi.wang.li...@gmail.com wrote: > Hi Christoph and Jason: > > Have been talking with Raj. I am going to work on this series this week. Thanks! Jason
Re: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
On Mon, Jan 24, 2022 at 10:52:22AM +0100, Helge Deller wrote:
> On 1/23/22 23:30, Wei Liu wrote:
> > On Sun, Jan 23, 2022 at 10:27:56PM +, Michael Kelley (LINUX) wrote:
> >> From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
> >>>
> >>> On Sun, Jan 16, 2022 at 09:53:06PM +, Haiyang Zhang wrote:
>
>
> > -Original Message-
> > From: Michael Kelley (LINUX)
> > Sent: Sunday, January 16, 2022 2:19 PM
> > To: KY Srinivasan ; Haiyang Zhang
> >>> ; Stephen
> > Hemminger ; wei@kernel.org; Wei Hu
> >>> ; Dexuan
> > Cui ; drawat.fl...@gmail.com; hhei
> > ;
> >>> linux-
> > ker...@vger.kernel.org; linux-hyp...@vger.kernel.org; linux-
> >>> fb...@vger.kernel.org; dri-
> > de...@lists.freedesktop.org
> > Cc: Michael Kelley (LINUX)
> > Subject: [PATCH 1/1] video: hyperv_fb: Fix validation of screen
> > resolution
> >
> > In the WIN10 version of the Synthetic Video protocol with Hyper-V,
> > Hyper-V reports a list of supported resolutions as part of the protocol
> > negotiation. The driver calculates the maximum width and height from
> > the list of resolutions, and uses those maximums to validate any screen
> > resolution specified in the video= option on the kernel boot line.
> >
> > This method of validation is incorrect. For example, the list of
> > supported resolutions could contain 1600x1200 and 1920x1080, both of
> > which fit in an 8 Mbyte frame buffer. But calculating the max width
> > and height yields 1920 and 1200, and 1920x1200 resolution does not fit
> > in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted,
> > causing a kernel fault when the driver accesses memory outside the
> > frame buffer.
> >
> > Instead, validate the specified screen resolution by calculating
> > its size, and comparing against the frame buffer size. Delete the
> > code for calculating the max width and height from the list of
> > resolutions, since these max values have no use. Also add the
> > frame buffer size to the info message to aid in understanding why
> > a resolution might be rejected.
> >
> > Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen
> > resolution from Hyper-V
> > host")
> > Signed-off-by: Michael Kelley
> >>> [...]
>
> Reviewed-by: Haiyang Zhang
>
> >>>
> >>> Applied to hyperv-fixes. Thanks.
> >>
> >> This fix got pulled into the fbdev/for-next tree by a new maintainer,
> >> Helge Deller.
> >> See
> >> https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=bcc48f8d980b12e66a3d59dfa1041667db971d86
> >
> > OK. I will drop it from hyperv-fixes. Thanks for letting me know!
>
> Linus hasn't pulled my tree yet, and he will probably not before the
> next merge window. So, if this is an urgent bugfix for you, I can offer
> to drop it from the fbdev tree and that you take it through the hyperv-fixes
> tree.
> In that case you may add an Acked-by: Helge Deller .
> Just let me know what you prefer.
Hi Helge
Yes, I would like to upstream it as soon as possible so that it can
propagate to stable trees and be backported by downstream vendors.
I will pick it up in hyperv-fixes. Please drop it from your for-next
tree.
Thanks,
Wei.
>
> Helge
Re: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
On 1/24/22 14:31, Wei Liu wrote:
> On Mon, Jan 24, 2022 at 10:52:22AM +0100, Helge Deller wrote:
>> On 1/23/22 23:30, Wei Liu wrote:
>>> On Sun, Jan 23, 2022 at 10:27:56PM +, Michael Kelley (LINUX) wrote:
From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
>
> On Sun, Jan 16, 2022 at 09:53:06PM +, Haiyang Zhang wrote:
>>
>>
>>> -Original Message-
>>> From: Michael Kelley (LINUX)
>>> Sent: Sunday, January 16, 2022 2:19 PM
>>> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen
>>> Hemminger ; wei@kernel.org; Wei Hu
> ; Dexuan
>>> Cui ; drawat.fl...@gmail.com; hhei
>>> ;
> linux-
>>> ker...@vger.kernel.org; linux-hyp...@vger.kernel.org; linux-
> fb...@vger.kernel.org; dri-
>>> de...@lists.freedesktop.org
>>> Cc: Michael Kelley (LINUX)
>>> Subject: [PATCH 1/1] video: hyperv_fb: Fix validation of screen
>>> resolution
>>>
>>> In the WIN10 version of the Synthetic Video protocol with Hyper-V,
>>> Hyper-V reports a list of supported resolutions as part of the protocol
>>> negotiation. The driver calculates the maximum width and height from
>>> the list of resolutions, and uses those maximums to validate any screen
>>> resolution specified in the video= option on the kernel boot line.
>>>
>>> This method of validation is incorrect. For example, the list of
>>> supported resolutions could contain 1600x1200 and 1920x1080, both of
>>> which fit in an 8 Mbyte frame buffer. But calculating the max width
>>> and height yields 1920 and 1200, and 1920x1200 resolution does not fit
>>> in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted,
>>> causing a kernel fault when the driver accesses memory outside the
>>> frame buffer.
>>>
>>> Instead, validate the specified screen resolution by calculating
>>> its size, and comparing against the frame buffer size. Delete the
>>> code for calculating the max width and height from the list of
>>> resolutions, since these max values have no use. Also add the
>>> frame buffer size to the info message to aid in understanding why
>>> a resolution might be rejected.
>>>
>>> Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen
>>> resolution from Hyper-V
>>> host")
>>> Signed-off-by: Michael Kelley
> [...]
>>
>> Reviewed-by: Haiyang Zhang
>>
>
> Applied to hyperv-fixes. Thanks.
This fix got pulled into the fbdev/for-next tree by a new maintainer,
Helge Deller.
See
https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=bcc48f8d980b12e66a3d59dfa1041667db971d86
>>>
>>> OK. I will drop it from hyperv-fixes. Thanks for letting me know!
>>
>> Linus hasn't pulled my tree yet, and he will probably not before the
>> next merge window. So, if this is an urgent bugfix for you, I can offer
>> to drop it from the fbdev tree and that you take it through the hyperv-fixes
>> tree.
>> In that case you may add an Acked-by: Helge Deller .
>> Just let me know what you prefer.
>
> Hi Helge
>
> Yes, I would like to upstream it as soon as possible so that it can
> propagate to stable trees and be backported by downstream vendors.
>
> I will pick it up in hyperv-fixes. Please drop it from your for-next
> tree.
Dropped now from fbdev tree.
Thanks!
Helge
Re: [PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal
Hello Thomas,
Thanks for the patch.
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Hot-unplug all firmware-framebuffer devices as part of removing
> them via remove_conflicting_framebuffers() et al. Releases all
> memory regions to be acquired by native drivers.
>
> Firmware, such as EFI, install a framebuffer while posting the
> computer. After removing the firmware-framebuffer device from fbdev,
> a native driver takes over the hardware and the firmware framebuffer
> becomes invalid.
>
> Firmware-framebuffer drivers, specifically simplefb, don't release
> their device from Linux' device hierarchy. It still owns the firmware
> framebuffer and blocks the native drivers from loading. This has been
> observed in the vmwgfx driver. [1]
>
> Initiating a device removal (i.e., hot unplug) as part of
> remove_conflicting_framebuffers() removes the underlying device and
> returns the memory range to the system.
>
> [1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/
>
I would add a Reported-by tag here for Zack.
> Signed-off-by: Thomas Zimmermann
> CC: sta...@vger.kernel.org # v5.11+
> ---
> drivers/video/fbdev/core/fbmem.c | 29 ++---
> include/linux/fb.h | 1 +
> 2 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 0fa7ede94fa6..f73f8415b8cb 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1557,18 +1558,36 @@ static void do_remove_conflicting_framebuffers(struct
> apertures_struct *a,
> /* check all firmware fbs and kick off if the base addr overlaps */
> for_each_registered_fb(i) {
> struct apertures_struct *gen_aper;
> + struct device *dev;
>
> if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
> continue;
>
> gen_aper = registered_fb[i]->apertures;
> + dev = registered_fb[i]->device;
> if (fb_do_apertures_overlap(gen_aper, a) ||
> (primary && gen_aper && gen_aper->count &&
>gen_aper->ranges[0].base == VGA_FB_PHYS)) {
>
> printk(KERN_INFO "fb%d: switching to %s from %s\n",
> i, name, registered_fb[i]->fix.id);
> - do_unregister_framebuffer(registered_fb[i]);
> +
> + /*
> + * If we kick-out a firmware driver, we also want to
> remove
> + * the underlying platform device, such as
> simple-framebuffer,
> + * VESA, EFI, etc. A native driver will then be able to
> + * allocate the memory range.
> + *
> + * If it's not a platform device, at least print a
> warning. A
> + * fix would add code to remove the device from the
> system.
> + */
> + if (dev_is_platform(dev)) {
In do_register_framebuffer() creating the fb%d is not a fatal error. It would
be safer to do if (!IS_ERR_OR_NULL(dev) && dev_is_platform(dev)) instead here.
https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/core/fbmem.c#L1605
> + registered_fb[i]->forced_out = true;
> +
> platform_device_unregister(to_platform_device(dev));
> + } else {
> + pr_warn("fb%d: cannot remove device\n", i);
> + do_unregister_framebuffer(registered_fb[i]);
> + }
> }
> }
> }
> @@ -1898,9 +1917,13 @@ EXPORT_SYMBOL(register_framebuffer);
> void
> unregister_framebuffer(struct fb_info *fb_info)
> {
> - mutex_lock(®istration_lock);
> + bool forced_out = fb_info->forced_out;
> +
> + if (!forced_out)
> + mutex_lock(®istration_lock);
> do_unregister_framebuffer(fb_info);
> - mutex_unlock(®istration_lock);
> + if (!forced_out)
> + mutex_unlock(®istration_lock);
> }
I'm not sure to follow the logic here. The forced_out bool is set when the
platform device is unregistered in do_remove_conflicting_framebuffers(),
but shouldn't the struct platform_driver .remove callback be executed even
in this case ?
That is, the platform_device_unregister() will trigger the call to the
.remove callback that in turn will call unregister_framebuffer().
Shouldn't we always hold the mutex when calling do_unregister_framebuffer() ?
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
[PATCH] drm/exynos: Search for TE-gpio in DSI panel's node
TE-gpio, if defined, is placed in the panel's node, not the parent DSI
node. Change the devm_gpiod_get_optional() to gpiod_get_optional() and
pass proper device node to it. The code already has a proper cleanup
path, so it looks that the devm_* variant has been applied assidentally
during the conversion to gpiod API.
Fixes: ee6c8b5afa62 ("drm/exynos: Replace legacy gpio interface for gpiod
interface")
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 14ebbb124852..d13f5e3a030d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1334,7 +1334,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
*dsi,
int ret;
int te_gpio_irq;
- dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", GPIOD_IN);
+ dsi->te_gpio = gpiod_get_optional(panel, "te", GPIOD_IN);
if (!dsi->te_gpio) {
return 0;
} else if (IS_ERR(dsi->te_gpio)) {
--
2.17.1
[PATCH] drm/amd/pm: set min, max to 0 if there is no get_dpm_ultimate_freq function
From: Tom Rix
clang static analysis reports this represenative problem
amdgpu_smu.c:144:18: warning: The left operand of '*' is a garbage value
return clk_freq * 100;
^
If there is no get_dpm_ultimate_freq function,
smu_get_dpm_freq_range returns success without setting the
output min,max parameters. Because this is an extern function,
set the min,max to 0 when there is no get_dpm_ultimate_freq.
Fixes: e5ef784b1e17 ("drm/amd/powerplay: revise calling chain on retrieving
frequency range")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 5ace30434e603..35fbe51f52eaa 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -121,11 +121,17 @@ int smu_get_dpm_freq_range(struct smu_context *smu,
if (!min && !max)
return -EINVAL;
- if (smu->ppt_funcs->get_dpm_ultimate_freq)
+ if (smu->ppt_funcs->get_dpm_ultimate_freq) {
ret = smu->ppt_funcs->get_dpm_ultimate_freq(smu,
clk_type,
min,
max);
+ } else {
+ if (min)
+ *min = 0;
+ if (max)
+ *max = 0;
+ }
return ret;
}
--
2.26.3
Re: [PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal
On 1/24/22 14:52, Javier Martinez Canillas wrote:
[snip]
>> @@ -1898,9 +1917,13 @@ EXPORT_SYMBOL(register_framebuffer);
>> void
>> unregister_framebuffer(struct fb_info *fb_info)
>> {
>> -mutex_lock(®istration_lock);
>> +bool forced_out = fb_info->forced_out;
>> +
>> +if (!forced_out)
>> +mutex_lock(®istration_lock);
>> do_unregister_framebuffer(fb_info);
>> -mutex_unlock(®istration_lock);
>> +if (!forced_out)
>> +mutex_unlock(®istration_lock);
>> }
>
> I'm not sure to follow the logic here. The forced_out bool is set when the
> platform device is unregistered in do_remove_conflicting_framebuffers(),
> but shouldn't the struct platform_driver .remove callback be executed even
> in this case ?
>
> That is, the platform_device_unregister() will trigger the call to the
> .remove callback that in turn will call unregister_framebuffer().
>
> Shouldn't we always hold the mutex when calling do_unregister_framebuffer() ?
>
Scratch that, I got it now. That's exactly the reason why you skip the
mutext_lock(). After adding the check for dev, feel free to add:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH 3/5] drm/simpledrm: Request memory region in driver
On 1/24/22 13:36, Thomas Zimmermann wrote: > Requesting the framebuffer memory in simpledrm marks the memory > range as busy. This used to be done by the firmware sysfb code, > but the driver is the correct place. > > Signed-off-by: Thomas Zimmermann > --- Looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 1/1] video: hyperv_fb: Fix validation of screen resolution
On Mon, Jan 24, 2022 at 02:48:57PM +0100, Helge Deller wrote: > On 1/24/22 14:31, Wei Liu wrote: [...] > >> > >> Linus hasn't pulled my tree yet, and he will probably not before the > >> next merge window. So, if this is an urgent bugfix for you, I can offer > >> to drop it from the fbdev tree and that you take it through the > >> hyperv-fixes tree. > >> In that case you may add an Acked-by: Helge Deller . > >> Just let me know what you prefer. > > > > Hi Helge > > > > Yes, I would like to upstream it as soon as possible so that it can > > propagate to stable trees and be backported by downstream vendors. > > > > I will pick it up in hyperv-fixes. Please drop it from your for-next > > tree. > > Dropped now from fbdev tree. Thanks! I added your ack and pushed the patch to hyperv-fixes. Wei. > > Thanks! > Helge
Re: [PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal
Hi
Am 24.01.22 um 14:52 schrieb Javier Martinez Canillas:
Hello Thomas,
Thanks for the patch.
On 1/24/22 13:36, Thomas Zimmermann wrote:
Hot-unplug all firmware-framebuffer devices as part of removing
them via remove_conflicting_framebuffers() et al. Releases all
memory regions to be acquired by native drivers.
Firmware, such as EFI, install a framebuffer while posting the
computer. After removing the firmware-framebuffer device from fbdev,
a native driver takes over the hardware and the firmware framebuffer
becomes invalid.
Firmware-framebuffer drivers, specifically simplefb, don't release
their device from Linux' device hierarchy. It still owns the firmware
framebuffer and blocks the native drivers from loading. This has been
observed in the vmwgfx driver. [1]
Initiating a device removal (i.e., hot unplug) as part of
remove_conflicting_framebuffers() removes the underlying device and
returns the memory range to the system.
[1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/
I would add a Reported-by tag here for Zack.
Indeed, I simply forgot about it.
Signed-off-by: Thomas Zimmermann
CC: sta...@vger.kernel.org # v5.11+
---
drivers/video/fbdev/core/fbmem.c | 29 ++---
include/linux/fb.h | 1 +
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..f73f8415b8cb 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1557,18 +1558,36 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
+ struct device *dev;
if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
continue;
gen_aper = registered_fb[i]->apertures;
+ dev = registered_fb[i]->device;
if (fb_do_apertures_overlap(gen_aper, a) ||
(primary && gen_aper && gen_aper->count &&
gen_aper->ranges[0].base == VGA_FB_PHYS)) {
printk(KERN_INFO "fb%d: switching to %s from %s\n",
i, name, registered_fb[i]->fix.id);
- do_unregister_framebuffer(registered_fb[i]);
+
+ /*
+* If we kick-out a firmware driver, we also want to
remove
+* the underlying platform device, such as
simple-framebuffer,
+* VESA, EFI, etc. A native driver will then be able to
+* allocate the memory range.
+*
+* If it's not a platform device, at least print a
warning. A
+* fix would add code to remove the device from the
system.
+*/
+ if (dev_is_platform(dev)) {
In do_register_framebuffer() creating the fb%d is not a fatal error. It would
be safer to do if (!IS_ERR_OR_NULL(dev) && dev_is_platform(dev)) instead here.
https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/core/fbmem.c#L1605
'dev' here refers to 'fb_info->device', which is the underlying device
created by the sysfb code. fb_info->dev is something different.
+ registered_fb[i]->forced_out = true;
+
platform_device_unregister(to_platform_device(dev));
+ } else {
+ pr_warn("fb%d: cannot remove device\n", i);
+ do_unregister_framebuffer(registered_fb[i]);
+ }
}
}
}
@@ -1898,9 +1917,13 @@ EXPORT_SYMBOL(register_framebuffer);
void
unregister_framebuffer(struct fb_info *fb_info)
{
- mutex_lock(®istration_lock);
+ bool forced_out = fb_info->forced_out;
+
+ if (!forced_out)
+ mutex_lock(®istration_lock);
do_unregister_framebuffer(fb_info);
- mutex_unlock(®istration_lock);
+ if (!forced_out)
+ mutex_unlock(®istration_lock);
}
I'm not sure to follow the logic here. The forced_out bool is set when the
platform device is unregistered in do_remove_conflicting_framebuffers(),
but shouldn't the struct platform_driver .remove callback be executed even
in this case ?
That is, the platform_device_unregister() will trigger the call to the
.remove callback that in turn will call unregister_framebuffer().
Shouldn't we always hold the mutex when calling do_unregister_framebuffer() ?
Doing the hot-unplug will end up in unregister_framebuffer(), but we
already hold the lock from the do_remove_conflicting_framebuffer() code.
Best regards
Thomas
Re: [PATCH 3/5] drm/simpledrm: Request memory region in driver
On 24/01/2022 13:36, Thomas Zimmermann wrote:
Requesting the framebuffer memory in simpledrm marks the memory
range as busy. This used to be done by the firmware sysfb code,
but the driver is the correct place.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 04146da2d1d8..f72b71511a65 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -526,21 +526,31 @@ static int simpledrm_device_init_mm(struct
simpledrm_device *sdev)
{
struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
- struct resource *mem;
+ struct resource *res, *mem;
void __iomem *screen_base;
int ret;
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
return -EINVAL;
- ret = devm_aperture_acquire_from_firmware(dev, mem->start, resource_size(mem));
+ ret = devm_aperture_acquire_from_firmware(dev, res->start,
resource_size(res));
if (ret) {
drm_err(dev, "could not acquire memory range %pr: error %d\n",
- mem, ret);
+ res, ret);
return ret;
}
+ mem = devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
+ sdev->dev.driver->name);
+ if (!mem) {
+ /*
+* We cannot make this fatal. Sometimes this comes from magic
+* spaces our resource handlers simply don't know about
+*/
+ drm_warn(dev, "could not acquire memory region %pr\n", res);
+ }
+
screen_base = devm_ioremap_wc(&pdev->dev, mem->start,
resource_size(mem));
if mem is NULL, accessing mem->start will segfault after the warning.
I think you renamed "mem" to "res" so probably it should be renamed here
too ?
if (!screen_base)
Re: [PATCH] drm/amd/pm: set min,max to 0 if there is no get_dpm_ultimate_freq function
On 1/24/2022 7:22 PM, t...@redhat.com wrote:
From: Tom Rix
clang static analysis reports this represenative problem
amdgpu_smu.c:144:18: warning: The left operand of '*' is a garbage value
return clk_freq * 100;
^
If there is no get_dpm_ultimate_freq function,
smu_get_dpm_freq_range returns success without setting the
output min,max parameters. Because this is an extern function,
set the min,max to 0 when there is no get_dpm_ultimate_freq.
Fixes: e5ef784b1e17 ("drm/amd/powerplay: revise calling chain on retrieving
frequency range")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 5ace30434e603..35fbe51f52eaa 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -121,11 +121,17 @@ int smu_get_dpm_freq_range(struct smu_context *smu,
if (!min && !max)
return -EINVAL;
- if (smu->ppt_funcs->get_dpm_ultimate_freq)
+ if (smu->ppt_funcs->get_dpm_ultimate_freq) {
ret = smu->ppt_funcs->get_dpm_ultimate_freq(smu,
clk_type,
min,
max);
+ } else {
return -ENOTSUPP; would be more appropriate.
Thanks,
Lijo
+ if (min)
+ *min = 0;
+ if (max)
+ *max = 0;
+ }
return ret;
}
Re: [PATCH 4/5] fbdev/simplefb: Request memory region in driver
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Requesting the framebuffer memory in simpledrm marks the memory
> range as busy. This used to be done by the firmware sysfb code,
> but the driver is the correct place.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/video/fbdev/simplefb.c | 59 --
> 1 file changed, 42 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 57541887188b..84452028ecc9 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -66,16 +66,36 @@ static int simplefb_setcolreg(u_int regno, u_int red,
> u_int green, u_int blue,
> return 0;
> }
>
> -struct simplefb_par;
> +struct simplefb_par {
> + u32 palette[PSEUDO_PALETTE_SIZE];
> +#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
> + bool clks_enabled;
> + unsigned int clk_count;
> + struct clk **clks;
> +#endif
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> + bool regulators_enabled;
> + u32 regulator_count;
> + struct regulator **regulators;
> +#endif
> + bool release_mem_region;
Maybe instead you could have:
struct resource *mem;
that would be more consistent with the fields for the other
resources like clocks, regulators, etc.
> +};
> +
> static void simplefb_clocks_destroy(struct simplefb_par *par);
> static void simplefb_regulators_destroy(struct simplefb_par *par);
>
> static void simplefb_destroy(struct fb_info *info)
> {
> + struct simplefb_par *par = info->par;
> +
> simplefb_regulators_destroy(info->par);
> simplefb_clocks_destroy(info->par);
> if (info->screen_base)
> iounmap(info->screen_base);
> +
> + if (par->release_mem_region)
> + release_mem_region(info->apertures->ranges[0].base,
> +info->apertures->ranges[0].size);
and here you could instead use the pointer to the resource:
if (par->mem)
release_mem_region(par->mem->start, resource_size(par->mem));
[snip]
> static int simplefb_probe(struct platform_device *pdev)
> {
> + bool request_mem_succeeded = false;
> int ret;
> struct simplefb_params params;
> struct fb_info *info;
> @@ -436,9 +443,22 @@ static int simplefb_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + if (request_mem_region(mem->start, resource_size(mem), "simplefb")) {
> + request_mem_succeeded = true;
and if you do the request_mem_region() after the struct fb_info allocation then
this could just be:
par->mem = mem;
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH 5/5] drm: Add TODO item for requesting memory regions
On 1/24/22 13:36, Thomas Zimmermann wrote: > Add a TODO item about requesting memory regions for each driver. The > current DRM drivers don't do this consistently. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal
On 1/24/22 15:19, Thomas Zimmermann wrote:
[snip]
>>> + if (dev_is_platform(dev)) {
>>
>> In do_register_framebuffer() creating the fb%d is not a fatal error. It would
>> be safer to do if (!IS_ERR_OR_NULL(dev) && dev_is_platform(dev)) instead
>> here.
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/core/fbmem.c#L1605
>
> 'dev' here refers to 'fb_info->device', which is the underlying device
> created by the sysfb code. fb_info->dev is something different.
>
oh, indeed. I conflated the two.
Maybe the local variable could be renamed to 'device' just to avoid confusion ?
[snip]
>> I'm not sure to follow the logic here. The forced_out bool is set when the
>> platform device is unregistered in do_remove_conflicting_framebuffers(),
>> but shouldn't the struct platform_driver .remove callback be executed even
>> in this case ?
>>
>> That is, the platform_device_unregister() will trigger the call to the
>> .remove callback that in turn will call unregister_framebuffer().
>>
>> Shouldn't we always hold the mutex when calling do_unregister_framebuffer() ?
>
> Doing the hot-unplug will end up in unregister_framebuffer(), but we
> already hold the lock from the do_remove_conflicting_framebuffer() code.
>
Yes, I realized that just after sending the first email. Sorry for the noise.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
[PATCH] drm/arm: Fix hdlcd selects to add DRM_GEM_CMA_HELPER for build
From: Carsten Haitzler Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too. Signed-off-by: Carsten Haitzler --- drivers/gpu/drm/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index 58a242871b28..9eaceb981d92 100644 --- a/drivers/gpu/drm/arm/Kconfig +++ b/drivers/gpu/drm/arm/Kconfig @@ -6,6 +6,7 @@ config DRM_HDLCD depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST) depends on COMMON_CLK select DRM_KMS_HELPER +select DRM_GEM_CMA_HELPER help Choose this option if you have an ARM High Definition Colour LCD controller. -- 2.30.1
Re: [PATCH v2 1/2] drm/edid: support Microsoft extension for HMDs and specialized monitors
On Sun, 23 Jan 2022, Philipp Zabel wrote:
> Add minimal support for parsing VSDBs documented in Microsoft's "EDID
> extension for head-mounted and specialized monitors" [1]. The version
> field and the desktop usage flag can be used to set the non_desktop
> connector property.
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors-edid-extension
>
> Tested with HPN-36C1 and LEN-B800.
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Jani Nikula
Thanks for the patches, both pushed to drm-misc-next.
BR,
Jani.
> ---
> Changes since v1 [2]:
> - Split out quirk removal into a separate patch.
> - Set non_desktop to true instead of 1.
>
> [2] https://lore.kernel.org/all/20211213184706.5776-1-philipp.za...@gmail.com/
> ---
> drivers/gpu/drm/drm_edid.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 12893e7be89b..271b5616cfaf 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -93,6 +93,8 @@ static int oui(u8 first, u8 second, u8 third)
> /* Non desktop display (i.e. HMD) */
> #define EDID_QUIRK_NON_DESKTOP (1 << 12)
>
> +#define MICROSOFT_IEEE_OUI 0xca125c
> +
> struct detailed_mode_closure {
> struct drm_connector *connector;
> struct edid *edid;
> @@ -4222,6 +4224,17 @@ static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
> return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
> }
>
> +static bool cea_db_is_microsoft_vsdb(const u8 *db)
> +{
> + if (cea_db_tag(db) != VENDOR_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) != 21)
> + return false;
> +
> + return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
> +}
> +
> static bool cea_db_is_vcdb(const u8 *db)
> {
> if (cea_db_tag(db) != USE_EXTENDED_TAG)
> @@ -5149,6 +5162,25 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
> *connector, const u8 *db)
> drm_parse_hdmi_deep_color_info(connector, db);
> }
>
> +/*
> + * See EDID extension for head-mounted and specialized monitors, specified
> at:
> + *
> https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors-edid-extension
> + */
> +static void drm_parse_microsoft_vsdb(struct drm_connector *connector,
> + const u8 *db)
> +{
> + struct drm_display_info *info = &connector->display_info;
> + u8 version = db[4];
> + bool desktop_usage = db[5] & BIT(6);
> +
> + /* Version 1 and 2 for HMDs, version 3 flags desktop usage explicitly */
> + if (version == 1 || version == 2 || (version == 3 && !desktop_usage))
> + info->non_desktop = true;
> +
> + drm_dbg_kms(connector->dev, "HMD or specialized display VSDB version
> %u: 0x%02x\n",
> + version, db[5]);
> +}
> +
> static void drm_parse_cea_ext(struct drm_connector *connector,
> const struct edid *edid)
> {
> @@ -5179,6 +5211,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_hdmi_vsdb_video(connector, db);
> if (cea_db_is_hdmi_forum_vsdb(db))
> drm_parse_hdmi_forum_vsdb(connector, db);
> + if (cea_db_is_microsoft_vsdb(db))
> + drm_parse_microsoft_vsdb(connector, db);
> if (cea_db_is_y420cmdb(db))
> drm_parse_y420cmdb_bitmap(connector, db);
> if (cea_db_is_vcdb(db))
>
> base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/edid: improve non-desktop quirk logging
On Sun, 23 Jan 2022, Philipp Zabel wrote: > On Tue, Dec 28, 2021 at 11:10 AM Jani Nikula wrote: >> >> Improve non-desktop quirk logging if the EDID indicates non-desktop. If >> both are set, note about redundant quirk. If there's no quirk but the >> EDID indicates non-desktop, don't log non-desktop is set to 0. >> >> Cc: Philipp Zabel >> Signed-off-by: Jani Nikula > > Thank you, > > Reviewed-by: Philipp Zabel > Tested-by: Philipp Zabel Thanks for the review and testing, pushed to drm-misc-next after v2 of your HMD EDID patches. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[PATCH 0/4] Fix up request cancel
Fix request cancellation + add request cancel low level trace point. v2: - Update cancel reset selftest preemption timeout value to zero - Fix bug in execlists cancel code Signed-off-by: Matthew Brost Matthew Brost (4): drm/i915: Add request cancel low level trace point drm/i915/guc: Cancel requests immediately drm/i915/execlists: Fix execlists request cancellation corner case drm/i915/selftests: Set preemption timeout to zero in cancel reset test drivers/gpu/drm/i915/gt/intel_context.h | 1 + drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++ .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 23 -- .../gpu/drm/i915/gt/intel_engine_heartbeat.h | 1 + .../drm/i915/gt/intel_execlists_submission.c | 18 +--- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 46 +++ drivers/gpu/drm/i915/i915_request.h | 6 +++ drivers/gpu/drm/i915/i915_trace.h | 10 drivers/gpu/drm/i915/selftests/i915_request.c | 7 +-- 9 files changed, 84 insertions(+), 33 deletions(-) -- 2.34.1
[PATCH 4/4] drm/i915/selftests: Set preemption timeout to zero in cancel reset test
Set the preemption timeout to zero to prove that request cancellation with preemption disabled works. Also this seals a race between a possible preemption and request cancellation. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/selftests/i915_request.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c index 2a99dd7c2fe8a..e522e24129f9b 100644 --- a/drivers/gpu/drm/i915/selftests/i915_request.c +++ b/drivers/gpu/drm/i915/selftests/i915_request.c @@ -790,8 +790,9 @@ static int __cancel_completed(struct intel_engine_cs *engine) * wait for spinner to start, create a NOP request and submit it, cancel the * spinner, wait for spinner to complete and verify it failed with an error, * finally wait for NOP request to complete verify it succeeded without an - * error. Preemption timeout also reduced / restored so test runs in a timely - * maner. + * error. Preemption timeout also set to zero to ensure cancellation works with + * preemption disabled and to ensure the NOP request doesn't trigger a + * preemption on the spinner sealing a race between a preemption and the cancel. */ static int __cancel_reset(struct drm_i915_private *i915, struct intel_engine_cs *engine) @@ -807,7 +808,7 @@ static int __cancel_reset(struct drm_i915_private *i915, return 0; preempt_timeout_ms = engine->props.preempt_timeout_ms; - engine->props.preempt_timeout_ms = 100; + engine->props.preempt_timeout_ms = 0; if (igt_spinner_init(&spin, engine->gt)) goto out_restore; -- 2.34.1
[PATCH 2/4] drm/i915/guc: Cancel requests immediately
Change the preemption timeout to the smallest possible value (1 us) when
disabling scheduling to cancel a request and restore it after
cancellation. This not only cancels the request as fast as possible, it
fixes a bug where the preemption timeout is 0 which results in the
schedule disable hanging forever.
Reported-by: Jani Saarinen
Fixes: 62eaf0ae217d4 ("drm/i915/guc: Support request cancellation")
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/4960
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 46 +++
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 30cd81ad8911a..730998823dbea 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -198,6 +198,11 @@ struct intel_context {
* each priority bucket
*/
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
+ /**
+* @preemption_timeout: preemption timeout of the context, used
+* to restore this value after request cancellation
+*/
+ u32 preemption_timeout;
} guc_state;
struct {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3918f1be114fa..966947c450253 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2147,7 +2147,8 @@ static inline u32 get_children_join_value(struct
intel_context *ce,
return __get_parent_scratch(ce)->join[child_index].semaphore;
}
-static void guc_context_policy_init(struct intel_engine_cs *engine,
+static void guc_context_policy_init(struct intel_context *ce,
+ struct intel_engine_cs *engine,
struct guc_lrc_desc *desc)
{
desc->policy_flags = 0;
@@ -2157,7 +2158,8 @@ static void guc_context_policy_init(struct
intel_engine_cs *engine,
/* NB: For both of these, zero means disabled. */
desc->execution_quantum = engine->props.timeslice_duration_ms * 1000;
- desc->preemption_timeout = engine->props.preempt_timeout_ms * 1000;
+ ce->guc_state.preemption_timeout = engine->props.preempt_timeout_ms *
1000;
+ desc->preemption_timeout = ce->guc_state.preemption_timeout;
}
static int guc_lrc_desc_pin(struct intel_context *ce, bool loop)
@@ -2193,7 +2195,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->hw_context_desc = ce->lrc.lrca;
desc->priority = ce->guc_state.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
- guc_context_policy_init(engine, desc);
+ guc_context_policy_init(ce, engine, desc);
/*
* If context is a parent, we need to register a process descriptor
@@ -2226,7 +2228,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->hw_context_desc = child->lrc.lrca;
desc->priority = ce->guc_state.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
- guc_context_policy_init(engine, desc);
+ guc_context_policy_init(child, engine, desc);
}
clear_children_join_go_memory(ce);
@@ -2409,6 +2411,19 @@ static u16 prep_context_pending_disable(struct
intel_context *ce)
return ce->guc_id.id;
}
+static void __guc_context_set_preemption_timeout(struct intel_guc *guc,
+u16 guc_id,
+u32 preemption_timeout)
+{
+ u32 action[] = {
+ INTEL_GUC_ACTION_SET_CONTEXT_PREEMPTION_TIMEOUT,
+ guc_id,
+ preemption_timeout
+ };
+
+ intel_guc_send_busy_loop(guc, action, ARRAY_SIZE(action), 0, true);
+}
+
static struct i915_sw_fence *guc_context_block(struct intel_context *ce)
{
struct intel_guc *guc = ce_to_guc(ce);
@@ -2442,8 +2457,10 @@ static struct i915_sw_fence *guc_context_block(struct
intel_context *ce)
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- with_intel_runtime_pm(runtime_pm, wakeref)
+ with_intel_runtime_pm(runtime_pm, wakeref) {
+ __guc_context_set_preemption_timeout(guc, guc_id, 1);
__guc_context_sched_disable(guc, ce, guc_id);
+ }
return &ce->guc_state.blocked;
}
@@ -2492,8 +2509,10 @@ static void guc_context_unblock(struct intel_context *ce)
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- if (enable) {
- with_intel_runtime_pm(runtime_pm, wakeref)
+ with_intel_runtime_pm(runtime_pm, wakeref) {
+ __
[PATCH 1/4] drm/i915: Add request cancel low level trace point
Add request cancel trace point guarded by
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINT.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.h | 1 +
drivers/gpu/drm/i915/i915_trace.h | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index d8c74bbf9aae2..3aed4d77f116c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -124,6 +124,7 @@ intel_context_is_pinned(struct intel_context *ce)
static inline void intel_context_cancel_request(struct intel_context *ce,
struct i915_request *rq)
{
+ trace_i915_request_cancel(rq);
GEM_BUG_ON(!ce->ops->cancel_request);
return ce->ops->cancel_request(ce, rq);
}
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 37b5c9e9d260e..d0a11a8bb0ca3 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -324,6 +324,11 @@ DEFINE_EVENT(i915_request, i915_request_add,
);
#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
+DEFINE_EVENT(i915_request, i915_request_cancel,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
DEFINE_EVENT(i915_request, i915_request_guc_submit,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
@@ -497,6 +502,11 @@ DEFINE_EVENT(intel_context, intel_context_do_unpin,
#else
#if !defined(TRACE_HEADER_MULTI_READ)
+static inline void
+trace_i915_request_cancel(struct i915_request *rq)
+{
+}
+
static inline void
trace_i915_request_guc_submit(struct i915_request *rq)
{
--
2.34.1
[PATCH 3/4] drm/i915/execlists: Fix execlists request cancellation corner case
More than 1 request can be submitted to a single ELSP at a time if
multiple requests are ready run to on the same context. When a request
is canceled it is marked bad, an idle pulse is triggered to the engine
(high priority kernel request), the execlists scheduler sees that
running request is bad and sets preemption timeout to minimum value (1
ms). This fails to work if multiple requests are combined on the ELSP as
only the most recent request is stored in the execlists schedule (the
request stored in the ELSP isn't marked bad, thus preemption timeout
isn't set to the minimum value). If the preempt timeout is configured to
zero, the engine is permanently hung. This is shown by an upcoming
selftest.
To work around this, mark the idle pulse with a flag to force a preempt
with the minimum value.
Fixes: 38b237eab2bc7 ("drm/i915: Individual request cancellation")
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 23 +++
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 18 ++-
drivers/gpu/drm/i915/i915_request.h | 6 +
4 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index a3698f611f457..efd1c719b4072 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -243,7 +243,8 @@ void intel_engine_init_heartbeat(struct intel_engine_cs
*engine)
INIT_DELAYED_WORK(&engine->heartbeat.work, heartbeat);
}
-static int __intel_engine_pulse(struct intel_engine_cs *engine)
+static int __intel_engine_pulse(struct intel_engine_cs *engine,
+ bool force_preempt)
{
struct i915_sched_attr attr = { .priority = I915_PRIORITY_BARRIER };
struct intel_context *ce = engine->kernel_context;
@@ -258,6 +259,8 @@ static int __intel_engine_pulse(struct intel_engine_cs
*engine)
return PTR_ERR(rq);
__set_bit(I915_FENCE_FLAG_SENTINEL, &rq->fence.flags);
+ if (force_preempt)
+ __set_bit(I915_FENCE_FLAG_FORCE_PREEMPT, &rq->fence.flags);
heartbeat_commit(rq, &attr);
GEM_BUG_ON(rq->sched.attr.priority < I915_PRIORITY_BARRIER);
@@ -299,7 +302,7 @@ int intel_engine_set_heartbeat(struct intel_engine_cs
*engine,
/* recheck current execution */
if (intel_engine_has_preemption(engine)) {
- err = __intel_engine_pulse(engine);
+ err = __intel_engine_pulse(engine, false);
if (err)
set_heartbeat(engine, saved);
}
@@ -312,7 +315,8 @@ int intel_engine_set_heartbeat(struct intel_engine_cs
*engine,
return err;
}
-int intel_engine_pulse(struct intel_engine_cs *engine)
+static int _intel_engine_pulse(struct intel_engine_cs *engine,
+ bool force_preempt)
{
struct intel_context *ce = engine->kernel_context;
int err;
@@ -325,7 +329,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
err = -EINTR;
if (!mutex_lock_interruptible(&ce->timeline->mutex)) {
- err = __intel_engine_pulse(engine);
+ err = __intel_engine_pulse(engine, force_preempt);
mutex_unlock(&ce->timeline->mutex);
}
@@ -334,6 +338,17 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
return err;
}
+int intel_engine_pulse(struct intel_engine_cs *engine)
+{
+ return _intel_engine_pulse(engine, false);
+}
+
+
+int intel_engine_pulse_force_preempt(struct intel_engine_cs *engine)
+{
+ return _intel_engine_pulse(engine, true);
+}
+
int intel_engine_flush_barriers(struct intel_engine_cs *engine)
{
struct i915_sched_attr attr = { .priority = I915_PRIORITY_MIN };
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
index 5da6d809a87a2..d9c8386754cb3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -21,6 +21,7 @@ void intel_gt_park_heartbeats(struct intel_gt *gt);
void intel_gt_unpark_heartbeats(struct intel_gt *gt);
int intel_engine_pulse(struct intel_engine_cs *engine);
+int intel_engine_pulse_force_preempt(struct intel_engine_cs *engine);
int intel_engine_flush_barriers(struct intel_engine_cs *engine);
#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 960a9aaf4f3a3..f0c2024058731 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1222,26 +1222,29 @@ static void record_preemption(struct
intel_engine_execlists *execlists)
}
static unsig
[PATCH] drm/arm: arm hdlcd select DRM_GEM_CMA_HELPER
From: Carsten Haitzler Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too. Signed-off-by: Carsten Haitzler --- drivers/gpu/drm/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index 58a242871b28..6e3f1d600541 100644 --- a/drivers/gpu/drm/arm/Kconfig +++ b/drivers/gpu/drm/arm/Kconfig @@ -6,6 +6,7 @@ config DRM_HDLCD depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST) depends on COMMON_CLK select DRM_KMS_HELPER + select DRM_GEM_CMA_HELPER help Choose this option if you have an ARM High Definition Colour LCD controller. -- 2.30.1
Re: [PATCH] drm/arm: arm hdlcd select DRM_GEM_CMA_HELPER
Sorry - noise. Ignore this one. Following one is fixed. On 1/24/22 15:13, carsten.haitz...@foss.arm.com wrote: From: Carsten Haitzler Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too. Signed-off-by: Carsten Haitzler --- drivers/gpu/drm/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index 58a242871b28..6e3f1d600541 100644 --- a/drivers/gpu/drm/arm/Kconfig +++ b/drivers/gpu/drm/arm/Kconfig @@ -6,6 +6,7 @@ config DRM_HDLCD depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST) depends on COMMON_CLK select DRM_KMS_HELPER + select DRM_GEM_CMA_HELPER help Choose this option if you have an ARM High Definition Colour LCD controller.
Re: [PATCH -next] drm/amd/display: don't use /** for non-kernel-doc comments
On 2022-01-21 20:23, Randy Dunlap wrote:
> Change a static function's comment from "/**" (indicating kernel-doc
> notation) to "/*" (indicating a regular C language comment).
> This prevents multiple kernel-doc warnings:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning:
> Function parameter or member 'max_supported_frl_bw_in_kbps' not described in
> 'intersect_frl_link_bw_support'
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning:
> Function parameter or member 'hdmi_encoded_link_bw' not described in
> 'intersect_frl_link_bw_support'
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning:
> expecting prototype for Return PCON's post FRL link training supported BW if
> its non(). Prototype was for intersect_frl_link_bw_support() instead
>
> Fixes: c022375ae095 ("drm/amd/display: Add DP-HDMI FRL PCON Support in DC")
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: Fangzhi Zuo
> Cc: Alex Deucher
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20220121.orig/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ linux-next-20220121/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -4970,7 +4970,7 @@ uint32_t dc_link_bw_kbps_from_raw_frl_li
> return 0;
> }
>
> -/**
> +/*
> * Return PCON's post FRL link training supported BW if its non-zero,
> otherwise return max_supported_frl_bw.
> */
> static uint32_t intersect_frl_link_bw_support(
Re: [PATCH 11/11] drm/vmwgfx: remove vmw_wait_dma_fence
On Mon, 2022-01-24 at 14:03 +0100, Christian König wrote: > Decomposing fence containers don't seem to make any sense here. > > So just remove the function entirely and call dma_fence_wait() > directly. > > Signed-off-by: Christian König > Cc: VMware Graphics > Cc: Zack Rusin Looks good. That's a great cleanup. Reviewed-by: Zack Rusin
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
On 1/24/22 12:50, Javier Martinez Canillas wrote: > On 1/24/22 12:33, Thomas Zimmermann wrote: > > [snip] > >>> Thoughts? >> >> I can't say I approve keeping fbdev alive, but... >> >> With fbdev emulation, every DRM driver is an fbdev driver too. So >> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like >> CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that >> absolutely need HW acceleration. That option would then protect the rsp >> code. I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not against it either. For me it sounds that this is not the real direction you want to go, which is to prevent that any other drivers take the framebuffer before you take it with simpledrm or similiar. CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable accleration part. With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS) it's an easy option for distros to disable all of the legacy drivers from being built & shipped. Instead of CONFIG_FBCON_HW_SCROLLING we could also choose CONFIG_FBCON_LEGACY_ACCELERATION, because it includes fillrect() as well... > Agreed that this option would be better and allow distros > to disable the code that was reverted. Yes, but IMHO it doesn't hurt either to leave it in. It doesn't break anything at least. Anyway... Helge
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Hi Am 24.01.22 um 16:29 schrieb Helge Deller: On 1/24/22 12:50, Javier Martinez Canillas wrote: On 1/24/22 12:33, Thomas Zimmermann wrote: [snip] Thoughts? I can't say I approve keeping fbdev alive, but... With fbdev emulation, every DRM driver is an fbdev driver too. So CONFIG_FB_DRIVER is somewhat misleading. Better add an option like CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that absolutely need HW acceleration. That option would then protect the rsp code. I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not against it either. For me it sounds that this is not the real direction you want to go, which is to prevent that any other drivers take the framebuffer before you take it with simpledrm or similiar. CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable accleration part. With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS) it's an easy option for distros to disable all of the legacy drivers from being built & shipped. These drivers have been disabled by most distros a long time ago. Those that still remain are the generic, soon to be replaced, ones; and drivers for niche architectures where no DRM-based replacement exists. If I run DRM with fbdev emulation, HW scrolling is unused, possibly buggy, and I'd want to not built it if possible. I guess that's what most distros would want as well. That's the use case for FBCON_HW_SCROLLING. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level.
On 1/24/22 14:02, Maarten Lankhorst wrote:
set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221] WARN_ON(debug_locks &&
!(lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map) != 0))
<4> [184.578237] WARNING: CPU: 6 PID: 5544 at
drivers/gpu/drm/i915/i915_gem.c:123 i915_gem_object_unbind+0x4a9/0x510 [i915]
<4> [184.578323] Modules linked in: vgem drm_shmem_helper snd_hda_codec_hdmi
i915 mei_hdcp x86_pkg_temp_thermal snd_hda_intel coretemp crct10dif_pclmul
snd_intel_dspcfg crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel snd_hwdep
drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm sysfillrect mei
pps_core sysimgblt fb_sys_fops prime_numbers intel_lpss_pci smsc75xx usbnet mii
<4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted
5.16.0-CI-Patchwork_22006+ #1
<4> [184.578351] Hardware name: Intel Corporation Alder Lake Client
Platform/AlderLake-P DDR4 RVP, BIOS ADLPFWI1.R00.2422.A00.2110131104 10/13/2021
<4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510 [i915]
<4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b e1 85 c0 0f 85 b1 fb
ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1 a0 e8 a3 54 26 e1 <0f> 0b e9 97 fb ff ff
31 ed 48 8b 5c 24 58 65 48 33 1c 25 28 00 00
<4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
<4> [184.578428] RAX: RBX: c900013b3bb0 RCX:
0001
<4> [184.578429] RDX: 8001 RSI: 8230b42d RDI:
<4> [184.578430] RBP: 888120e1 R08: R09:
c0007fff
<4> [184.578431] R10: 0001 R11: c900013b3980 R12:
8881176ea740
<4> [184.578432] R13: 888120e1 R14: R15:
0001
<4> [184.578433] FS: 7f65074f5e40() GS:8f30()
knlGS:
<4> [184.578435] CS: 0010 DS: ES: CR0: 80050033
<4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4:
00770ee0
<4> [184.578437] PKRU: 5554
<4> [184.578438] Call Trace:
<4> [184.578439]
<4> [184.578440] ? dma_resv_iter_first_unlocked+0x78/0xf0
<4> [184.578447] intel_dpt_create+0x88/0x220 [i915]
<4> [184.578530] intel_framebuffer_init+0x5b8/0x620 [i915]
<4> [184.578612] intel_framebuffer_create+0x3d/0x60 [i915]
<4> [184.578691] intel_user_framebuffer_create+0x18f/0x2c0 [i915]
<4> [184.578775] drm_internal_framebuffer_create+0x36d/0x4c0
<4> [184.578779] drm_mode_addfb2+0x2f/0xd0
<4> [184.578781] ? drm_mode_addfb_ioctl+0x10/0x10
<4> [184.578784] drm_ioctl_kernel+0xac/0x140
<4> [184.578787] drm_ioctl+0x201/0x3d0
<4> [184.578789] ? drm_mode_addfb_ioctl+0x10/0x10
<4> [184.578796] __x64_sys_ioctl+0x6a/0xa0
<4> [184.578800] do_syscall_64+0x37/0xb0
<4> [184.578803] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [184.578805] RIP: 0033:0x7f6506736317
<4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff
ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73
01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
<4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246 ORIG_RAX:
0010
<4> [184.578810] RAX: ffda RBX: 0006 RCX:
7f6506736317
<4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI:
0006
<4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09:
<4> [184.578813] R10: 0008 R11: 0246 R12:
c06864b8
<4> [184.578813] R13: 0006 R14: R15:
<4> [184.578819]
<4> [184.578820] irq event stamp: 47931
<4> [184.578821] hardirqs last enabled at (47937): []
__up_console_sem+0x62/0x70
<4> [184.578824] hardirqs last disabled at (47942): []
__up_console_sem+0x47/0x70
<4> [184.578826] softirqs last enabled at (47340): []
__do_softirq+0x32d/0x493
<4> [184.578828] softirqs last disabled at (47335): []
irq_exit_rcu+0xa6/0xe0
<4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---
Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for
i915_vma_unbind, v2.")
Signed-off-by: Maarten Lankhorst
Testcase: kms_addfb_basic
---
drivers/gpu/drm/i915/display/intel_dpt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
LGTM. Reviewed-by: Thomas Hellström
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 63a83d5f85a1..c2f8f853db90 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -253,7 +253,11 @@ intel_dpt_create(struct intel_framebuffer *fb)
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
- ret = i915_gem_object_set_cache_level(dpt_obj, I915_CACHE_NONE);
+ ret = i915_gem_object_lock_interru
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Hi Helge,
On Mon, Jan 24, 2022 at 4:30 PM Helge Deller wrote:
> On 1/24/22 12:50, Javier Martinez Canillas wrote:
> > On 1/24/22 12:33, Thomas Zimmermann wrote:
> >
> > [snip]
> >
> >>> Thoughts?
> >>
> >> I can't say I approve keeping fbdev alive, but...
> >>
> >> With fbdev emulation, every DRM driver is an fbdev driver too. So
> >> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like
> >> CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that
> >> absolutely need HW acceleration. That option would then protect the rsp
> >> code.
>
> I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not
> against it either.
> For me it sounds that this is not the real direction you want to go,
> which is to prevent that any other drivers take the framebuffer before
> you take it with simpledrm or similiar.
> CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable
> accleration part.
> With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS)
> it's an easy option for distros to disable all of the legacy drivers
> from being built & shipped.
>
> Instead of CONFIG_FBCON_HW_SCROLLING we could also choose
> CONFIG_FBCON_LEGACY_ACCELERATION, because it includes fillrect() as well...
As this is about resurrecting features indicated by the various
FBINFO_HWACCEL_* flags, what about CONFIG_FB_HWACCEL?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
On Mon, Jan 24, 2022 at 12:33 PM Thomas Zimmermann wrote:
> With fbdev emulation, every DRM driver is an fbdev driver too. So
Some are even without?
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: ret = register_framebuffer(info);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
On Mon, Jan 24, 2022 at 04:29:34PM +0100, Helge Deller wrote: > On 1/24/22 12:50, Javier Martinez Canillas wrote: > > On 1/24/22 12:33, Thomas Zimmermann wrote: > > > > [snip] > > > >>> Thoughts? > >> > >> I can't say I approve keeping fbdev alive, but... > >> > >> With fbdev emulation, every DRM driver is an fbdev driver too. So > >> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like > >> CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that > >> absolutely need HW acceleration. That option would then protect the rsp > >> code. > > I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not > against it either. > For me it sounds that this is not the real direction you want to go, > which is to prevent that any other drivers take the framebuffer before > you take it with simpledrm or similiar. > CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable > accleration part. > With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS) > it's an easy option for distros to disable all of the legacy drivers > from being built & shipped. > > Instead of CONFIG_FBCON_HW_SCROLLING we could also choose > CONFIG_FBCON_LEGACY_ACCELERATION, because it includes fillrect() as well... +1 on that name, since on the lwn discussions I've also seen some noise about resurrecting scrollback. And I guess we could do that too and then just add it all behind that same option. -Daniel > > Agreed that this option would be better and allow distros > > to disable the code that was reverted. > > Yes, but IMHO it doesn't hurt either to leave it in. > It doesn't break anything at least. > Anyway... > > Helge -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/arm: Fix hdlcd selects to add DRM_GEM_CMA_HELPER for build
Sorry - I meant disregard THIS one - following patch is right. On 1/24/22 14:58, carsten.haitz...@foss.arm.com wrote: From: Carsten Haitzler Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too. Signed-off-by: Carsten Haitzler --- drivers/gpu/drm/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index 58a242871b28..9eaceb981d92 100644 --- a/drivers/gpu/drm/arm/Kconfig +++ b/drivers/gpu/drm/arm/Kconfig @@ -6,6 +6,7 @@ config DRM_HDLCD depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST) depends on COMMON_CLK select DRM_KMS_HELPER +select DRM_GEM_CMA_HELPER help Choose this option if you have an ARM High Definition Colour LCD controller.
Re: [PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal
On Mon, 2022-01-24 at 13:36 +0100, Thomas Zimmermann wrote: > Hot-unplug all firmware-framebuffer devices as part of removing > them via remove_conflicting_framebuffers() et al. Releases all > memory regions to be acquired by native drivers. > > Firmware, such as EFI, install a framebuffer while posting the > computer. After removing the firmware-framebuffer device from fbdev, > a native driver takes over the hardware and the firmware framebuffer > becomes invalid. > > Firmware-framebuffer drivers, specifically simplefb, don't release > their device from Linux' device hierarchy. It still owns the firmware > framebuffer and blocks the native drivers from loading. This has been > observed in the vmwgfx driver. [1] > > Initiating a device removal (i.e., hot unplug) as part of > remove_conflicting_framebuffers() removes the underlying device and > returns the memory range to the system. > > [1] > https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/ > > Signed-off-by: Thomas Zimmermann > CC: sta...@vger.kernel.org # v5.11+ Looks great, thanks! Reviewed-by: Zack Rusin
Re: [PATCH 2/5] drivers/firmware: Don't mark as busy the simple-framebuffer IO resource
On Mon, 2022-01-24 at 13:36 +0100, Thomas Zimmermann wrote: > From: Javier Martinez Canillas > > The sysfb_create_simplefb() function requests a IO memory resource for > the > simple-framebuffer platform device, but it also marks it as busy which > can > lead to drivers requesting the same memory resource to fail. > > Let's drop the IORESOURCE_BUSY flag and let drivers to request it as > busy > instead. > > Signed-off-by: Javier Martinez Canillas Reviewed-by: Zack Rusin
Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels
On Sun, 23 Jan 2022 18:25:18 +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
>
> Signed-off-by: Noralf Trønnes
> ---
> .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
> 1 file changed, 69 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
schemas/display/panel/panel/panel-common.yaml: ignoring, error parsing file
make[1]: *** Deleting file
'Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.example.dt.yaml'
schemas/display/panel/panel/panel-common.yaml: ignoring, error parsing file
Traceback (most recent call last):
File "/usr/local/bin/dt-validate", line 170, in
sg.check_trees(filename, testtree)
File "/usr/local/bin/dt-validate", line 119, in check_trees
self.check_subtree(dt, subtree, False, "/", "/", filename)
File "/usr/local/bin/dt-validate", line 110, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
File "/usr/local/bin/dt-validate", line 110, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
File "/usr/local/bin/dt-validate", line 110, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
File "/usr/local/bin/dt-validate", line 105, in check_subtree
self.check_node(tree, subtree, disabled, nodename, fullname, filename)
File "/usr/local/bin/dt-validate", line 49, in check_node
errors = sorted(dtschema.DTValidator(schema).iter_errors(node), key=lambda
e: e.linecol)
File "/usr/local/lib/python3.8/dist-packages/dtschema/lib.py", line 771, in
iter_errors
for error in super().iter_errors(instance, _schema):
File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line
229, in iter_errors
for error in errors:
File "/usr/local/lib/python3.8/dist-packages/jsonschema/_validators.py", line
362, in allOf
yield from validator.descend(instance, subschema, schema_path=index)
File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line
245, in descend
for error in self.evolve(schema=schema).iter_errors(instance):
File "/usr/local/lib/python3.8/dist-packages/dtschema/lib.py", line 771, in
iter_errors
for error in super().iter_errors(instance, _schema):
File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line
229, in iter_errors
for error in errors:
File "/usr/local/lib/python3.8/dist-packages/jsonschema/_validators.py", line
298, in ref
yield from validator.descend(instance, resolved)
File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line
245, in descend
for error in self.evolve(schema=schema).iter_errors(instance):
File "/usr/local/lib/python3.8/dist-packages/dtschema/lib.py", line 771, in
iter_errors
for error in super().iter_errors(instance, _schema):
File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line
219, in iter_errors
scope = id_of(_schema)
File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line
96, in _id_of
return schema.get("$id", "")
AttributeError: 'NoneType' object has no attribute 'get'
make[1]: *** [scripts/Makefile.lib:378:
Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.example.dt.yaml]
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1398: dt_binding_check] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1583159
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
Re: [PATCH 1/6] dt-bindings: input: touchscreen: add bindings for focaltech, fts
On Sun, 23 Jan 2022 17:37:27 +, Caleb Connolly wrote: > Add devicetree bindings for the Focaltech FTS touchscreen drivers. > > Signed-off-by: Caleb Connolly > --- > .../input/touchscreen/focaltech,fts.yaml | 78 +++ > 1 file changed, 78 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/focaltech,fts.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/input/touchscreen/focaltech,fts.example.dts:21.9-14 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [scripts/Makefile.lib:378: Documentation/devicetree/bindings/input/touchscreen/focaltech,fts.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1398: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1583161 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH V2 3/7] drm/gma: Remove calls to kmap()
On Sun, Jan 23, 2022 at 05:54:05PM -0800, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> kmap() is being deprecated and these instances are easy to convert to
> kmap_local_page().
>
> Furthermore, in gma_crtc_cursor_set() use the memcpy_from_page() helper
> instead of an open coded use of kmap_local_page().
>
> Signed-off-by: Ira Weiny
Applied to drm-misc-next, the others should all have full time maintainers
to make sure the patches land. Pls holler if not.
Thanks, Daniel
> ---
> drivers/gpu/drm/gma500/gma_display.c | 6 ++
> drivers/gpu/drm/gma500/mmu.c | 8
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/gma_display.c
> b/drivers/gpu/drm/gma500/gma_display.c
> index 99da3118131a..60ba7de59139 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -335,7 +335,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
> struct psb_gem_object *pobj;
> struct psb_gem_object *cursor_pobj = gma_crtc->cursor_pobj;
> struct drm_gem_object *obj;
> - void *tmp_dst, *tmp_src;
> + void *tmp_dst;
> int ret = 0, i, cursor_pages;
>
> /* If we didn't get a handle then turn the cursor off */
> @@ -400,9 +400,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
> /* Copy the cursor to cursor mem */
> tmp_dst = dev_priv->vram_addr + cursor_pobj->offset;
> for (i = 0; i < cursor_pages; i++) {
> - tmp_src = kmap(pobj->pages[i]);
> - memcpy(tmp_dst, tmp_src, PAGE_SIZE);
> - kunmap(pobj->pages[i]);
> + memcpy_from_page(tmp_dst, pobj->pages[i], 0, PAGE_SIZE);
> tmp_dst += PAGE_SIZE;
> }
>
> diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
> index fe9ace2a7967..a70b01ccdf70 100644
> --- a/drivers/gpu/drm/gma500/mmu.c
> +++ b/drivers/gpu/drm/gma500/mmu.c
> @@ -184,17 +184,17 @@ struct psb_mmu_pd *psb_mmu_alloc_pd(struct
> psb_mmu_driver *driver,
> pd->invalid_pte = 0;
> }
>
> - v = kmap(pd->dummy_pt);
> + v = kmap_local_page(pd->dummy_pt);
> for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> v[i] = pd->invalid_pte;
>
> - kunmap(pd->dummy_pt);
> + kunmap_local(v);
>
> - v = kmap(pd->p);
> + v = kmap_local_page(pd->p);
> for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> v[i] = pd->invalid_pde;
>
> - kunmap(pd->p);
> + kunmap_local(v);
>
> clear_page(kmap(pd->dummy_page));
> kunmap(pd->dummy_page);
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels
On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes wrote:
>
> Add binding for MIPI DBI compatible SPI panels.
I'm sure we already have MIPI DBI panels. What's this for?
>
> Signed-off-by: Noralf Trønnes
> ---
> .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
> 1 file changed, 69 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> new file mode 100644
> index ..d6c8accb045c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MIPI DBI SPI Panels Device Tree Bindings
> +
> +maintainers:
> + - Noralf Trønnes
> +
> +description:
> + This binding is for display panels using a MIPI DBI controller
> + in SPI mode.
> +
> +allOf:
> + - $ref: panel/panel-common.yaml#
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> +const: panel-mipi-dbi-spi
Does the MIPI spec define how to power on a DBI panel with regulators,
enable/reset lines, etc. and all the timing constraints between those?
If not, then this compatible on its own is useless. It's fine as a
fallback if it's presence means the panel uses only standard DBI
commands and no vendor specific commands.
> +
> + model:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: The name of the display panel.
> +
> + write-only:
> +type: boolean
> +description:
> + Controller is not readable (ie. MISO is not wired up).
> +
> + dc-gpios:
> +maxItems: 1
> +description: |
> + Controller data/command selection (D/CX) in 4-line SPI mode.
> + If not set, the controller is in 3-line SPI mode.
> +
> + backlight: true
> + reg: true
> + reset-gpios: true
> +
> +required:
> + - compatible
> + - model
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +display@0{
> +compatible = "panel-mipi-dbi-spi";
> +model = "sainsmart18";
> +reg = <0>;
> +spi-max-frequency = <4000>;
> +dc-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>;
> +write-only;
> +};
> +};
> +
> +...
> --
> 2.33.0
>
Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"
Hi
Am 24.01.22 um 16:50 schrieb Geert Uytterhoeven:
On Mon, Jan 24, 2022 at 12:33 PM Thomas Zimmermann wrote:
With fbdev emulation, every DRM driver is an fbdev driver too. So
Some are even without?
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: ret = register_framebuffer(info);
Well, I counted this as 'emulation' as well. There's fully
driver-agnostic fbdev support in DRM, but some drivers still run their
own. At some point, we want all drivers to use DRM's generic solution.
Best regards
Thomas
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
