Re: [PATCH] drm/amdgpu/ttm: Fix memory leak userptr pages
Am 17.03.21 um 17:08 schrieb Daniel Gomez: If userptr pages have been pinned but not bounded, they remain uncleared. Signed-off-by: Daniel Gomez Good catch, not sure if that can ever happen in practice but better save than sorry. Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 9fd2157b133a..50c2b4827c13 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1162,13 +1162,13 @@ static void amdgpu_ttm_backend_unbind(struct ttm_bo_device *bdev, struct amdgpu_ttm_tt *gtt = (void *)ttm; int r; - if (!gtt->bound) - return; - /* if the pages have userptr pinning then clear that first */ if (gtt->userptr) amdgpu_ttm_tt_unpin_userptr(bdev, ttm); + if (!gtt->bound) + return; + if (gtt->offset == AMDGPU_BO_INVALID_OFFSET) return; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/ttm: Fix memory leak userptr pages
On Thu, 18 Mar 2021 at 08:49, Christian König wrote: > > Am 17.03.21 um 17:08 schrieb Daniel Gomez: > > If userptr pages have been pinned but not bounded, > > they remain uncleared. > > > > Signed-off-by: Daniel Gomez > > Good catch, not sure if that can ever happen in practice but better save > than sorry. Thanks! We actually had a case with clEnqueueWriteBuffer where the driver was leaking. I can see the problem also affects to the radeon driver so, I'll send a patch for that one as well. > > Reviewed-by: Christian König > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > index 9fd2157b133a..50c2b4827c13 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > > @@ -1162,13 +1162,13 @@ static void amdgpu_ttm_backend_unbind(struct > > ttm_bo_device *bdev, > > struct amdgpu_ttm_tt *gtt = (void *)ttm; > > int r; > > > > - if (!gtt->bound) > > - return; > > - > > /* if the pages have userptr pinning then clear that first */ > > if (gtt->userptr) > > amdgpu_ttm_tt_unpin_userptr(bdev, ttm); > > > > + if (!gtt->bound) > > + return; > > + > > if (gtt->offset == AMDGPU_BO_INVALID_OFFSET) > > return; > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212255] WARNING: at arch/x86/kernel/fpu/core.c:129 kernel_fpu_begin_mask
https://bugzilla.kernel.org/show_bug.cgi?id=212255 --- Comment #5 from Felice Tufo (i...@felicetufo.com) --- Tested also on 5.11.7 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/ttm: Fix memory leak userptr pages
If userptr pages have been pinned but not bounded, they remain uncleared. Signed-off-by: Daniel Gomez --- drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index e8c66d10478f..bbcc6264d48f 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -485,13 +485,14 @@ static void radeon_ttm_backend_unbind(struct ttm_bo_device *bdev, struct ttm_tt struct radeon_ttm_tt *gtt = (void *)ttm; struct radeon_device *rdev = radeon_get_rdev(bdev); + if (gtt->userptr) + radeon_ttm_tt_unpin_userptr(bdev, ttm); + if (!gtt->bound) return; radeon_gart_unbind(rdev, gtt->offset, ttm->num_pages); - if (gtt->userptr) - radeon_ttm_tt_unpin_userptr(bdev, ttm); gtt->bound = false; } -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
AW: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages
Reviewed-by: Christian König Von: Daniel Gomez Gesendet: Donnerstag, 18. März 2021 09:32 Cc: dag...@gmail.com ; Daniel Gomez ; Deucher, Alexander ; Koenig, Christian ; David Airlie ; Daniel Vetter ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Betreff: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages If userptr pages have been pinned but not bounded, they remain uncleared. Signed-off-by: Daniel Gomez --- drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index e8c66d10478f..bbcc6264d48f 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -485,13 +485,14 @@ static void radeon_ttm_backend_unbind(struct ttm_bo_device *bdev, struct ttm_tt struct radeon_ttm_tt *gtt = (void *)ttm; struct radeon_device *rdev = radeon_get_rdev(bdev); + if (gtt->userptr) + radeon_ttm_tt_unpin_userptr(bdev, ttm); + if (!gtt->bound) return; radeon_gart_unbind(rdev, gtt->offset, ttm->num_pages); - if (gtt->userptr) - radeon_ttm_tt_unpin_userptr(bdev, ttm); gtt->bound = false; } -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] drm/vc4: hdmi: Support the 4k @ 60Hz modes
Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. The firmware also has a glitch at the moment and will not properly release the BSC controllers, which will make the EDID retrieval fail. We can work around this using the following config.txt options: disable_fw_kms_setup=1 hdmi_edid_file:0=1 hdmi_edid_filename:0=1366x768.bin hdmi_ignore_edid:0=1 hdmi_edid_file:1=1 hdmi_edid_filename:1=1366x768.bin hdmi_ignore_edid:1=1 A fix will come for the firmware eventually. Let me know what you think, Maxime --- Changes from v1: - Dropped the range accessors - Drop the mention of force_turbo - Reordered the SCRAMBLER_CTL register to match the offset - Removed duplicate HDMI_14_MAX_TMDS_CLK define - Warn about enable_hdmi_4kp60 only if there's some modes that can't be reached - Rework the BVB clock computation Maxime Ripard (5): drm/vc4: hvs: Make the HVS bind first drm/vc4: hdmi: Properly compute the BVB clock rate drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies drm/vc4: hdmi: Enable the scrambler drm/vc4: hdmi: Raise the maximum clock rate drivers/gpu/drm/vc4/vc4_drv.c | 11 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 101 +--- drivers/gpu/drm/vc4/vc4_hdmi.h | 8 +++ drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 + 4 files changed, 113 insertions(+), 10 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/vc4: hvs: Make the HVS bind first
We'll need to have the HVS binding before the HDMI controllers so that
we can check whether the firmware allows to run in 4kp60. Reorder a bit
the component list, and document the current constraints we're aware of.
Acked-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 556ad0f02a0d..0310590ee66e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -303,12 +303,21 @@ static const struct component_master_ops vc4_drm_ops = {
.unbind = vc4_drm_unbind,
};
+/*
+ * This list determines the binding order of our components, and we have
+ * a few constraints:
+ * - The TXP driver needs to be bound before the PixelValves (CRTC)
+ * but after the HVS to set the possible_crtc field properly
+ * - The HDMI driver needs to be bound after the HVS so that we can
+ * lookup the HVS maximum core clock rate and figure out if we
+ * support 4kp60 or not.
+ */
static struct platform_driver *const component_drivers[] = {
+ &vc4_hvs_driver,
&vc4_hdmi_driver,
&vc4_vec_driver,
&vc4_dpi_driver,
&vc4_dsi_driver,
- &vc4_hvs_driver,
&vc4_txp_driver,
&vc4_crtc_driver,
&vc4_v3d_driver,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/vc4: hdmi: Enable the scrambler
The HDMI controller on the BCM2711 includes a scrambler in order to
reach the modes that require it. Let's add the support for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 56 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 0924a1b9e186..530c83097b1a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_SCRAMBLER_CTL_ENABLE BIT(0)
+
#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
@@ -457,6 +460,56 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
+static bool vc4_hdmi_supports_scrambling(struct drm_encoder *encoder,
+struct drm_display_mode *mode)
+{
+ struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_display_info *display = &vc4_hdmi->connector.display_info;
+
+ if (!vc4_encoder->hdmi_monitor)
+ return false;
+
+ if (!display->hdmi.scdc.supported ||
+ !display->hdmi.scdc.scrambling.supported)
+ return false;
+
+ if ((mode->clock * 1000) < HDMI_14_MAX_TMDS_CLK)
+ return false;
+
+ return true;
+}
+
+static void vc4_hdmi_enable_scrambling(struct drm_encoder *encoder)
+{
+ struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+
+ if (!vc4_hdmi_supports_scrambling(encoder, mode))
+ return;
+
+ drm_scdc_set_high_tmds_clock_ratio(vc4_hdmi->ddc, true);
+ drm_scdc_set_scrambling(vc4_hdmi->ddc, true);
+
+ HDMI_WRITE(HDMI_SCRAMBLER_CTL, HDMI_READ(HDMI_SCRAMBLER_CTL) |
+ VC5_HDMI_SCRAMBLER_CTL_ENABLE);
+}
+
+static void vc4_hdmi_disable_scrambling(struct drm_encoder *encoder)
+{
+ struct drm_display_mode *mode = &encoder->crtc->mode;
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+
+ if (!vc4_hdmi_supports_scrambling(encoder, mode))
+ return;
+
+ HDMI_WRITE(HDMI_SCRAMBLER_CTL, HDMI_READ(HDMI_SCRAMBLER_CTL) &
+ ~VC5_HDMI_SCRAMBLER_CTL_ENABLE);
+
+ drm_scdc_set_scrambling(vc4_hdmi->ddc, false);
+ drm_scdc_set_high_tmds_clock_ratio(vc4_hdmi->ddc, false);
+}
+
static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
@@ -469,6 +522,8 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct
drm_encoder *encoder,
HDMI_WRITE(HDMI_VID_CTL,
HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX);
+
+ vc4_hdmi_disable_scrambling(encoder);
}
static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder,
@@ -919,6 +974,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct
drm_encoder *encoder,
}
vc4_hdmi_recenter_fifo(vc4_hdmi);
+ vc4_hdmi_enable_scrambling(encoder);
}
static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
index e1b58eac766f..19d2fdc446bc 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
@@ -100,6 +100,7 @@ enum vc4_hdmi_field {
HDMI_RM_FORMAT,
HDMI_RM_OFFSET,
HDMI_SCHEDULER_CONTROL,
+ HDMI_SCRAMBLER_CTL,
HDMI_SW_RESET_CONTROL,
HDMI_TX_PHY_CHANNEL_SWAP,
HDMI_TX_PHY_CLK_DIV,
@@ -238,6 +239,7 @@ static const struct vc4_hdmi_register __maybe_unused
vc5_hdmi_hdmi0_fields[] = {
VC4_HDMI_REG(HDMI_GCP_CONFIG, 0x178),
VC4_HDMI_REG(HDMI_GCP_WORD_1, 0x17c),
VC4_HDMI_REG(HDMI_HOTPLUG, 0x1a8),
+ VC4_HDMI_REG(HDMI_SCRAMBLER_CTL, 0x1c4),
VC5_DVP_REG(HDMI_CLOCK_STOP, 0x0bc),
VC5_DVP_REG(HDMI_VEC_INTERFACE_XBAR, 0x0f0),
@@ -317,6 +319,7 @@ static const struct vc4_hdmi_register __maybe_unused
vc5_hdmi_hdmi1_fields[] = {
VC4_HDMI_REG(HDMI_GCP_CONFIG, 0x178),
VC4_HDMI_REG(HDMI_GCP_WORD_1, 0x17c),
VC4_HDMI_REG(HDMI_HOTPLUG, 0x1a8),
+ VC4_HDMI_REG(HDMI_SCRAMBLER_CTL, 0x1c4),
VC5_DVP_REG(HDMI_CLOCK_STOP, 0x0bc),
VC5_DVP_REG(HDMI_VEC_INTERFACE_XBAR, 0x0f0),
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
[PATCH v2 5/5] drm/vc4: hdmi: Raise the maximum clock rate
Now that we have the infrastructure in place, we can raise the maximum
pixel rate we can reach for HDMI0 on the BCM2711.
HDMI1 is left untouched since its pixelvalve has a smaller FIFO and
would need a clock faster than what we can provide to support the same
modes.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 530c83097b1a..a31771dd09e6 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -2190,7 +2190,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI0,
.debugfs_name = "hdmi0_regs",
.card_name = "vc4-hdmi-0",
- .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
+ .max_pixel_clock= 6,
.registers = vc5_hdmi_hdmi0_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
.phy_lane_mapping = {
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies
In order to reach the frequencies needed to output at 594MHz, the
firmware needs to be configured with the appropriate parameters in the
config.txt file (enable_hdmi_4kp60 and force_turbo).
Let's detect it at bind time, warn the user if we can't, and filter out
the relevant modes.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 ++
drivers/gpu/drm/vc4/vc4_hdmi.h | 8
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index eaee853bb404..0924a1b9e186 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -210,6 +210,18 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
+ if (vc4_hdmi->disable_4kp60) {
+ struct drm_device *drm = connector->dev;
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, &connector->probed_modes, head) {
+ if ((mode->clock * 1000) > HDMI_14_MAX_TMDS_CLK) {
+ drm_warn_once(drm, "The core clock cannot reach
frequencies high enough to support 4k @ 60Hz.");
+ drm_warn_once(drm, "Please change your
config.txt file to add hdmi_enable_4kp60.");
+ }
+ }
+ }
+
return ret;
}
@@ -959,6 +971,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ if (vc4_hdmi->disable_4kp60 && (pixel_rate > HDMI_14_MAX_TMDS_CLK))
+ return -EINVAL;
+
vc4_state->pixel_rate = pixel_rate;
return 0;
@@ -978,6 +993,9 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
return MODE_CLOCK_HIGH;
+ if (vc4_hdmi->disable_4kp60 && ((mode->clock * 1000) >
HDMI_14_MAX_TMDS_CLK))
+ return MODE_CLOCK_HIGH;
+
return MODE_OK;
}
@@ -1992,6 +2010,14 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
vc4_hdmi->disable_wifi_frequencies =
of_property_read_bool(dev->of_node, "wifi-2.4ghz-coexistence");
+ if (variant->max_pixel_clock == 6) {
+ struct vc4_dev *vc4 = to_vc4_dev(drm);
+ long max_rate = clk_round_rate(vc4->hvs->core_clk, 55000);
+
+ if (max_rate < 55000)
+ vc4_hdmi->disable_4kp60 = true;
+ }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 3cebd1fd00fc..3cd021136402 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -154,6 +154,14 @@ struct vc4_hdmi {
*/
bool disable_wifi_frequencies;
+ /*
+* Even if HDMI0 on the RPi4 can output modes requiring a pixel
+* rate higher than 297MHz, it needs some adjustments in the
+* config.txt file to be able to do so and thus won't always be
+* available.
+*/
+ bool disable_4kp60;
+
struct cec_adapter *cec_adap;
struct cec_msg cec_rx_msg;
bool cec_tx_ok;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/vc4: hdmi: Properly compute the BVB clock rate
The BVB clock rate computation doesn't take into account a mode clock of
594MHz that we're going to need to support 4k60.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index eee9751009c2..eaee853bb404 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -91,7 +91,6 @@
# define VC4_HD_M_ENABLE BIT(0)
#define CEC_CLOCK_FREQ 4
-#define VC4_HSM_MID_CLOCK 149985000
#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
@@ -739,7 +738,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
- unsigned long pixel_rate, hsm_rate;
+ unsigned long bvb_rate, pixel_rate, hsm_rate;
int ret;
ret = pm_runtime_get_sync(&vc4_hdmi->pdev->dev);
@@ -793,12 +792,14 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi_cec_update_clk_div(vc4_hdmi);
- /*
-* FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
-* at 300MHz.
-*/
- ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock,
- (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
7500));
+ if (pixel_rate > 29700)
+ bvb_rate = 3;
+ else if (pixel_rate > 14850)
+ bvb_rate = 15000;
+ else
+ bvb_rate = 7500;
+
+ ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock, bvb_rate);
if (ret) {
DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 1/2] drm/tegra: dc: Support memory bandwidth management
On Wed, Mar 17, 2021 at 09:57:33PM +0300, Dmitry Osipenko wrote:
[...]
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -618,6 +619,9 @@ static int tegra_plane_atomic_check(struct drm_plane
> *plane,
> struct tegra_dc *dc = to_tegra_dc(new_plane_state->crtc);
> int err;
>
> + plane_state->peak_memory_bandwidth = 0;
> + plane_state->avg_memory_bandwidth = 0;
> +
> /* no need for further checks if the plane is being disabled */
> if (!new_plane_state->crtc)
> return 0;
> @@ -808,6 +812,12 @@ static struct drm_plane
> *tegra_primary_plane_create(struct drm_device *drm,
> formats = dc->soc->primary_formats;
> modifiers = dc->soc->modifiers;
>
> + err = tegra_plane_interconnect_init(plane);
> + if (err) {
> + kfree(plane);
> + return ERR_PTR(err);
> + }
> +
> err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
> &tegra_plane_funcs, formats,
> num_formats, modifiers, type, NULL);
> @@ -841,9 +851,13 @@ static int tegra_cursor_atomic_check(struct drm_plane
> *plane,
> {
> struct drm_plane_state *new_plane_state =
> drm_atomic_get_new_plane_state(state,
>
> plane);
> + struct tegra_plane_state *plane_state =
> to_tegra_plane_state(new_plane_state);
> struct tegra_plane *tegra = to_tegra_plane(plane);
> int err;
>
> + plane_state->peak_memory_bandwidth = 0;
> + plane_state->avg_memory_bandwidth = 0;
> +
> /* no need for further checks if the plane is being disabled */
> if (!new_plane_state->crtc)
> return 0;
> @@ -985,6 +999,12 @@ static struct drm_plane
> *tegra_dc_cursor_plane_create(struct drm_device *drm,
> num_formats = ARRAY_SIZE(tegra_cursor_plane_formats);
> formats = tegra_cursor_plane_formats;
>
> + err = tegra_plane_interconnect_init(plane);
> + if (err) {
> + kfree(plane);
> + return ERR_PTR(err);
> + }
> +
> err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
> &tegra_plane_funcs, formats,
> num_formats, NULL,
> @@ -1099,6 +1119,12 @@ static struct drm_plane
> *tegra_dc_overlay_plane_create(struct drm_device *drm,
> num_formats = dc->soc->num_overlay_formats;
> formats = dc->soc->overlay_formats;
>
> + err = tegra_plane_interconnect_init(plane);
> + if (err) {
> + kfree(plane);
> + return ERR_PTR(err);
> + }
> +
> if (!cursor)
> type = DRM_PLANE_TYPE_OVERLAY;
> else
> @@ -1216,6 +1242,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> {
> struct tegra_dc_state *state = to_dc_state(crtc->state);
> struct tegra_dc_state *copy;
> + unsigned int i;
>
> copy = kmalloc(sizeof(*copy), GFP_KERNEL);
> if (!copy)
> @@ -1227,6 +1254,9 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> copy->div = state->div;
> copy->planes = state->planes;
>
> + for (i = 0; i < ARRAY_SIZE(state->plane_peak_bw); i++)
> + copy->plane_peak_bw[i] = state->plane_peak_bw[i];
> +
> return ©->base;
> }
>
> @@ -1753,6 +1783,106 @@ static int tegra_dc_wait_idle(struct tegra_dc *dc,
> unsigned long timeout)
> return -ETIMEDOUT;
> }
>
> +static void
> +tegra_crtc_update_memory_bandwidth(struct drm_crtc *crtc,
> +struct drm_atomic_state *state,
> +bool prepare_bandwidth_transition)
> +{
> + const struct tegra_plane_state *old_tegra_state, *new_tegra_state;
> + const struct tegra_dc_state *old_dc_state, *new_dc_state;
> + u32 i, new_avg_bw, old_avg_bw, new_peak_bw, old_peak_bw;
> + const struct drm_plane_state *old_plane_state;
> + const struct drm_crtc_state *old_crtc_state;
> + struct tegra_dc_window window, old_window;
> + struct tegra_dc *dc = to_tegra_dc(crtc);
> + struct tegra_plane *tegra;
> + struct drm_plane *plane;
> +
> + if (dc->soc->has_nvdisplay)
> + return;
> +
> + old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
> + old_dc_state = to_const_dc_state(old_crtc_state);
> + new_dc_state = to_const_dc_state(crtc->state);
> +
> + if (!crtc->state->active) {
> + if (!old_crtc_state->active)
> + return;
> +
> + /*
> + * When CRTC is disabled on DPMS, the state of attached planes
> + * is kept unchanged. Hence we need to enforce removal of the
> + * bandwidths from the ICC paths.
> + */
> + drm_atomic_crtc_f
Re: [PATCH 1/3] dma-buf: add dma_fence_array_for_each (v2)
Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
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.
Is there any reason you send this patch alone out once more?
I don't see any changes compared to the last version.
Christian.
Signed-off-by: Jason Ekstrand
---
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 d3fbd950be944..2ac1afc697d0f 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -201,3 +201,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 303dd712220fd..588ac8089dd61 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -74,6 +74,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,
@@ -81,4 +94,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 */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote: > > > On 2/11/2021 7:34 AM, Daniel Vetter wrote: > > On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote: > >> > >> On 2/9/2021 2:54 AM, Daniel Vetter wrote: > >>> On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote: > This patch adds tracking of which cgroup to make charges against for a > given GEM object. We associate the current task's cgroup with GEM > objects > as they are created. First user of this is for charging DRM cgroup for > device memory allocations. The intended behavior is for device drivers > to > make the cgroup charging calls at the time that backing store is > allocated > or deallocated for the object. > > Exported functions are provided for charging memory allocations for a > GEM object to DRM cgroup. To aid in debugging, we store how many bytes > have been charged inside the GEM object. Add helpers for setting and > clearing the object's associated cgroup which will check that charges are > not being leaked. > > For shared objects, this may make the charge against a cgroup that is > potentially not the same cgroup as the process using the memory. Based > on the memory cgroup's discussion of "memory ownership", this seems > acceptable [1]. > > [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory > Ownership" > > Signed-off-by: Brian Welty > >>> > >>> Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that > >>> counts everything, why don't we also charge in these gem functions? > >> > >> I'm not sure what you mean exactly. You want to merge/move the charging > >> logic > >> proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into > >> drm_gem_object_charge_mem() ? > >> > >> Or reading below, I think you are okay keeping the logic separated as is, > >> but > >> you want much of the code in kernel/cgroup/drm.c moved to > >> drivers/gpu/cgroup ? > >> Yes, I see that should allow to reduce number of exported functions. > > > > Both. I mean we'd need to look at the code again when it's shuffled, but > > I'd say: > > > > - cgroup code and the charging for general gpu memory moves to > > drivers/gpu/cgroup, so dma-buf heaps can use it too. > > > > - the charging for gem buffers moves into core gem code, so it happens for > > all gpu drivers and all gem buffer allocations. > > Daniel, I'm not sure we're in sync on what 'charging for general gpu memory' > means. Thus far, I have been proposing to charge/uncharge when backing store > is > allocated/freed. And thus, this would be done in DRM driver (so then also in > the dma-buf exporter). > I can't see how we'd hoist this part into drm gem code. > The memory limit in this series is for VRAM usage/limit not GEM buffers... Yes this would be at gem buffer creation time. And just to get cgroups for drm up&running. > Unless you are talking about charging for GEM buffer creation? But this is > more of a 'soft resource' more along lines of Kenny's earlier GEM buffer limit > control. > I raised issue with this then, and at the time, Tejun agreed we should keep to > 'hard resource' controls, see [1] and [2]. > > [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/218071.html > [2] https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html > > > > > - this might or might not mean a bunch less exported stuff from the > > cgroups files (since you don't need separate steps for linking a gem > > object to a cgroup from the actual charging), and probably no exports > > anymore for drivers (since they charge nothing). That will change > > when we add charging for specific memory pools I guess, but we add that > > when we add tha functionality. > > ... so considering VRAM charging, then yes, we very much need to have exported > functions for drivers to do the charging. > But these can be exported from drm.ko (or new .ko?) instead of kernel. Is > that still preference? Also, if number of exported functions is concern, we > can replace some of it with use of function pointers. So the reason I suggested we drop all this is because we won't charge in drivers, we'll charge in ttm buffer management code. Which we'll adopt for dg1 in upstream. But it will take some time. > So then returning to this comment of yours: > > > - cgroup code and the charging for general gpu memory moves to > > drivers/gpu/cgroup, so dma-buf heaps can use it too. > > If you agree that we are charging just at backing-store level, then I think > logic belongs in drivers/gpu/drm/cgroup ?? As charging is done in DRM driver > (also dma-buf exporter). In other words, part of drm. > If I understand, dma-buf heaps is exporter of system memory and doesn't > need to charge against gpu controller?? > Will need some help to understand the dma-buf heap use case a bit more. Well we also need to track s
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Drop the CONTEXT_CLONE API
On 17/03/2021 23:40, Jason Ekstrand wrote:
It's never been used by any real userspace. It's used by IGT as a
short-cut for sharing VMs and other stuff between contexts.
I haven't checked if userspace uses this so assuming that is fine, the
only thing that remains is preparing the IGTs for the transition which
cannot be avoided.
Regards,
Tvrtko
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 217 +---
include/uapi/drm/i915_drm.h | 16 +-
2 files changed, 6 insertions(+), 227 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e78..92256f4e50764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2103,225 +2103,14 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
}
-static int copy_ring_size(struct intel_context *dst,
- struct intel_context *src)
+static int invalid_ext(struct i915_user_extension __user *ext, void *data)
{
- long sz;
-
- sz = intel_context_get_ring_size(src);
- if (sz < 0)
- return sz;
-
- return intel_context_set_ring_size(dst, sz);
-}
-
-static int clone_engines(struct i915_gem_context *dst,
-struct i915_gem_context *src)
-{
- struct i915_gem_engines *clone, *e;
- bool user_engines;
- unsigned long n;
-
- e = __context_engines_await(src, &user_engines);
- if (!e)
- return -ENOENT;
-
- clone = alloc_engines(e->num_engines);
- if (!clone)
- goto err_unlock;
-
- for (n = 0; n < e->num_engines; n++) {
- struct intel_engine_cs *engine;
-
- if (!e->engines[n]) {
- clone->engines[n] = NULL;
- continue;
- }
- engine = e->engines[n]->engine;
-
- /*
-* Virtual engines are singletons; they can only exist
-* inside a single context, because they embed their
-* HW context... As each virtual context implies a single
-* timeline (each engine can only dequeue a single request
-* at any time), it would be surprising for two contexts
-* to use the same engine. So let's create a copy of
-* the virtual engine instead.
-*/
- if (intel_engine_is_virtual(engine))
- clone->engines[n] =
- intel_execlists_clone_virtual(engine);
- else
- clone->engines[n] = intel_context_create(engine);
- if (IS_ERR_OR_NULL(clone->engines[n])) {
- __free_engines(clone, n);
- goto err_unlock;
- }
-
- intel_context_set_gem(clone->engines[n], dst);
-
- /* Copy across the preferred ringsize */
- if (copy_ring_size(clone->engines[n], e->engines[n])) {
- __free_engines(clone, n + 1);
- goto err_unlock;
- }
- }
- clone->num_engines = n;
- i915_sw_fence_complete(&e->fence);
-
- /* Serialised by constructor */
- engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
- if (user_engines)
- i915_gem_context_set_user_engines(dst);
- else
- i915_gem_context_clear_user_engines(dst);
- return 0;
-
-err_unlock:
- i915_sw_fence_complete(&e->fence);
- return -ENOMEM;
-}
-
-static int clone_flags(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- dst->user_flags = src->user_flags;
- return 0;
-}
-
-static int clone_schedattr(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- dst->sched = src->sched;
- return 0;
-}
-
-static int clone_sseu(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
- struct i915_gem_engines *clone;
- unsigned long n;
- int err;
-
- /* no locking required; sole access under constructor*/
- clone = __context_engines_static(dst);
- if (e->num_engines != clone->num_engines) {
- err = -EINVAL;
- goto unlock;
- }
-
- for (n = 0; n < e->num_engines; n++) {
- struct intel_context *ce = e->engines[n];
-
- if (clone->engines[n]->engine->class != ce->engine->class) {
- /* Must have compatible engine maps! */
- err = -EINVAL;
- goto unlock;
-
[PATCH] drm/i915/gt: A typo fix
s/bariers/barriers/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c index 037b0e3ccbed..25fc7f44fee0 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline.c +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c @@ -435,7 +435,7 @@ void intel_timeline_exit(struct intel_timeline *tl) spin_unlock(&timelines->lock); /* -* Since this timeline is idle, all bariers upon which we were waiting +* Since this timeline is idle, all barriers upon which we were waiting * must also be complete and so we can discard the last used barriers * without loss of information. */ -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/10] drm: Support simple-framebuffer devices and firmware fbs
This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simpledrm, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simpledrm is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simpledrm can also serve as interim solution on graphics hardware without native DRM driver. So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simpledrm. Patches 3 and 4 add a hand-over mechanism. Simpledrm acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simpledrm before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. Patches 5 to 10 add the simpledrm driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 8 and 9 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. I've also been working on fastboot support (i.e., flicker-free booting). This requires state-readout from simpledrm via generic interfaces, as outlined in [1]. I do have some prototype code, but it will take a while to get this ready. Simpledrm will then support it. I've tested simpledrm with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. I looked into X11, but couldn't see an easy way of fixing the problem. With the push towards Wayland+Xwayland I expect the problem to become a non-issue soon. Additional testing has been reported at [2]. One cosmetical issue is that simpledrm's device file is card0 and the native driver's device file is card1. After simpledrm has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover * provide bootsplash DRM client * make simplekms usable with ARM-EFI fbs v2: * rename to simpledrm, aperture helpers * reorganized patches * use hotplug helpers for removal (Daniel) * added DT match tables (Rob) * use shadow-plane helpers * lots of minor cleanups [1] https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9bwmvfu-o...@mail.gmail.com/ [2] https://lore.kernel.org/dri-devel/1761762.3HQLrFs1K7@nerdopolis/ Thomas Zimmermann (10): drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() drm/format-helper: Add blitter functions drm/aperture: Move fbdev conflict helpers into drm_aperture.h drm/aperture: Add infrastructure for aperture ownership drm: Add simpledrm driver drm/simpledrm: Add fbdev emulation drm/simpledrm: Initialize framebuffer data from device-tree node drm/simpledrm: Acquire clocks from DT device node drm/simpledrm: Acquire regulators from DT device node drm/simpledrm: Acquire memory aperture for framebuffer Documentation/gpu/drm-internals.rst| 12 + MAINTAINERS| 7 + drivers/gpu/drm/Kconfig| 7 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_aperture.c | 287 drivers/gpu/drm/drm_format_helper.c| 96 ++- drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/tiny/Kconfig | 17 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/cirrus.c | 2 +- drivers/gpu/drm/tiny/simpledrm.c | 932 + include/drm/drm_aperture.h | 96 +++ include/drm/drm_fb_helper.h| 56 +- include/drm/drm_format_helper.h| 10 +- 14 files changed, 1466 insertions(+), 60 deletions(-) create mode 100644 drivers/gpu/drm/drm_aperture.c create mode 100644 drivers/gpu/drm/tiny/simpledrm.c create mode 100644 include/drm/drm_aperture.h -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri
[PATCH v2 01/10] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
The memcpy's destination buffer might have a different pitch than the
source. Support different pitches as function argument.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/drm_format_helper.c| 9 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
include/drm/drm_format_helper.h| 2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index c043ca364c86..8d5a683afea7 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -52,6 +52,7 @@ EXPORT_SYMBOL(drm_fb_memcpy);
/**
* drm_fb_memcpy_dstclip - Copy clip buffer
* @dst: Destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
* @vaddr: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
@@ -59,12 +60,12 @@ EXPORT_SYMBOL(drm_fb_memcpy);
* This function applies clipping on dst, i.e. the destination is a
* full (iomem) framebuffer but only the clip rect content is copied over.
*/
-void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
- struct drm_framebuffer *fb,
+void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
+ void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
unsigned int cpp = fb->format->cpp[0];
- unsigned int offset = clip_offset(clip, fb->pitches[0], cpp);
+ unsigned int offset = clip_offset(clip, dst_pitch, cpp);
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y, lines = clip->y2 - clip->y1;
@@ -73,7 +74,7 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
for (y = 0; y < lines; y++) {
memcpy_toio(dst, vaddr, len);
vaddr += fb->pitches[0];
- dst += fb->pitches[0];
+ dst += dst_pitch;
}
}
EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index cece3e57fb27..9d576240faed 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1554,7 +1554,7 @@ mgag200_handle_damage(struct mga_device *mdev, struct
drm_framebuffer *fb,
{
void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
- drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
+ drm_fb_memcpy_dstclip(mdev->vram, fb->pitches[0], vmap, fb, clip);
/* Always scanout image at VRAM offset 0 */
mgag200_set_startadd(mdev, (u32)0);
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index ad922c3ec681..ae5643b0a6f4 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -323,7 +323,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
const struct dma_buf_
return -ENODEV;
if (cirrus->cpp == fb->format->cpp[0])
- drm_fb_memcpy_dstclip(cirrus->vram,
+ drm_fb_memcpy_dstclip(cirrus->vram, fb->pitches[0],
vmap, fb, rect);
else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 5f9e37032468..2b5036a5fbe7 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -11,7 +11,7 @@ struct drm_rect;
void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
-void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
+void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
*vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_swab(void *dst, void *src, struct drm_framebuffer *fb,
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership
Platform devices might operate on firmware framebuffers, such as VESA or
EFI. Before a native driver for the graphics hardware can take over the
device, it has to remove any platform driver that operates on the firmware
framebuffer. Aperture helpers provide the infrastructure for platform
drivers to acquire firmware framebuffers, and for native drivers to remove
them later on.
It works similar to the related fbdev mechanism. During initialization, the
platform driver acquires the firmware framebuffer's I/O memory and provides
a callback to be removed. The native driver later uses this information to
remove any platform driver for it's framebuffer I/O memory.
The aperture removal code is integrated into the existing code for removing
conflicting framebuffers, so native drivers use it automatically.
v2:
* rename plaform helpers to aperture helpers
* tie to device lifetime with devm_ functions
* removed unsued remove() callback
* rename kickout to detach
* make struct drm_aperture private
* rebase onto existing drm_aperture.h header file
* use MIT license only for simplicity
* documentation
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
Documentation/gpu/drm-internals.rst | 6 +
drivers/gpu/drm/Kconfig | 7 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_aperture.c | 287
include/drm/drm_aperture.h | 38 +++-
5 files changed, 338 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_aperture.c
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index 4c7642d2ca34..06af044c882f 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -78,9 +78,15 @@ DRM_IOCTL_VERSION ioctl.
Managing Ownership of the Framebuffer Aperture
--
+.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
+ :doc: overview
+
.. kernel-doc:: include/drm/drm_aperture.h
:internal:
+.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
+ :export:
+
Device Instance and Driver Handling
---
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1461652921be..b9d3fb91d22d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -221,6 +221,13 @@ config DRM_SCHED
tristate
depends on DRM
+config DRM_APERTURE
+ bool
+ depends on DRM
+ help
+ Controls ownership of graphics apertures. Required to
+ synchronize with firmware-based drivers.
+
source "drivers/gpu/drm/i2c/Kconfig"
source "drivers/gpu/drm/arm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5eb5bf7c16e3..c9ecb02df0f3 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_APERTURE) += drm_aperture.o
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
new file mode 100644
index ..4b02b5fed0a1
--- /dev/null
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: MIT
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * A graphics device might be supported by different drivers, but only one
+ * driver can be active at any given time. Many systems load a generic
+ * graphics drivers, such as EFI-GOP or VESA, early during the boot process.
+ * During later boot stages, they replace the generic driver with a dedicated,
+ * hardware-specific driver. To take over the device the dedicated driver
+ * first has to remove the generic driver. DRM aperture functions manage
+ * ownership of DRM framebuffer memory and hand-over between drivers.
+ *
+ * DRM drivers should call drm_fb_helper_remove_conflicting_framebuffers()
+ * at the top of their probe function. The function removes any generic
+ * driver that is currently associated with the given framebuffer memory.
+ * If the framebuffer is located at PCI BAR 0, the rsp code looks as in the
+ * example given below.
+ *
+ * .. code-block:: c
+ *
+ * static int remove_conflicting_framebuffers(struct pci_dev *pdev)
+ * {
+ * struct apertures_struct *ap;
+ * bool primary = false;
+ * int ret;
+ *
+ * ap = alloc_apertures(1);
+ * if (!ap)
+ * return -ENOMEM;
+ *
+ * ap->ranges[0].base = pci_resource_start(pdev, 0);
+ * ap->ranges[0].size = pci_resource_len(pdev, 0);
+ *
+ * #ifdef CONFIG_X86
+ * primary = pdev->resource[PCI_ROM_RESOURC
[PATCH v2 02/10] drm/format-helper: Add blitter functions
The blitter functions copy a framebuffer to I/O memory using one of
the existing conversion functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/drm_format_helper.c | 87 +
include/drm/drm_format_helper.h | 8 +++
2 files changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 8d5a683afea7..0e885cd34107 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -344,3 +344,90 @@ void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
+/**
+ * drm_fb_blit_rect_dstclip - Copy parts of a framebuffer to display memory
+ * @dst: The display memory to copy to
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @dst_format:FOURCC code of the display's color format
+ * @vmap: The framebuffer memory to copy from
+ * @fb:The framebuffer to copy from
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory. If the
+ * formats of the display and the framebuffer mismatch, the blit function
+ * will attempt to convert between them.
+ *
+ * Use drm_fb_blit_dstclip() to copy the full framebuffer.
+ *
+ * Returns:
+ * 0 on success, or
+ * -EINVAL if the color-format conversion failed, or
+ * a negative error code otherwise.
+ */
+int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
+uint32_t dst_format, void *vmap,
+struct drm_framebuffer *fb,
+struct drm_rect *clip)
+{
+ uint32_t fb_format = fb->format->format;
+
+ /* treat alpha channel like filler bits */
+ if (fb_format == DRM_FORMAT_ARGB)
+ fb_format = DRM_FORMAT_XRGB;
+ if (dst_format == DRM_FORMAT_ARGB)
+ dst_format = DRM_FORMAT_XRGB;
+
+ if (dst_format == fb_format) {
+ drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
+ return 0;
+
+ } else if (dst_format == DRM_FORMAT_RGB565) {
+ if (fb_format == DRM_FORMAT_XRGB) {
+ drm_fb_xrgb_to_rgb565_dstclip(dst, dst_pitch,
+ vmap, fb, clip,
+ false);
+ return 0;
+ }
+ } else if (dst_format == DRM_FORMAT_RGB888) {
+ if (fb_format == DRM_FORMAT_XRGB) {
+ drm_fb_xrgb_to_rgb888_dstclip(dst, dst_pitch,
+ vmap, fb, clip);
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(drm_fb_blit_rect_dstclip);
+
+/**
+ * drm_fb_blit_dstclip - Copy framebuffer to display memory
+ * @dst: The display memory to copy to
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @dst_format:FOURCC code of the display's color format
+ * @vmap: The framebuffer memory to copy from
+ * @fb:The framebuffer to copy from
+ *
+ * This function copies a full framebuffer to display memory. If the formats
+ * of the display and the framebuffer mismatch, the copy function will
+ * attempt to convert between them.
+ *
+ * See drm_fb_blit_rect_dstclip() for more inforamtion.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
+ uint32_t dst_format, void *vmap,
+ struct drm_framebuffer *fb)
+{
+ struct drm_rect fullscreen = {
+ .x1 = 0,
+ .x2 = fb->width,
+ .y1 = 0,
+ .y2 = fb->height,
+ };
+ return drm_fb_blit_rect_dstclip(dst, dst_pitch, dst_format, vmap, fb,
+ &fullscreen);
+}
+EXPORT_SYMBOL(drm_fb_blit_dstclip);
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 2b5036a5fbe7..4e0258a61311 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -28,4 +28,12 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst,
unsigned int dst_pitch
void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
+int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned int dst_pitch,
+uint32_t dst_format, void *vmap,
+struct drm_framebuffer *fb,
+struct drm_rect *rect);
+int drm_fb_blit_dstclip(void __iomem *dst, unsigned int dst_pitch,
+ uint32_t dst_format, void *vmap,
+
[PATCH v2 06/10] drm/simpledrm: Add fbdev emulation
This displays a console on simpledrm's framebuffer. The default framebuffer format is being used. Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Tested-by: nerdopolis --- drivers/gpu/drm/tiny/simpledrm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index 0422c549b97a..4f0d4ec0b432 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -500,6 +501,8 @@ static int simpledrm_probe(struct platform_device *pdev) if (ret) return ret; + drm_fbdev_generic_setup(dev, 0); + return 0; } -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm: Add simpledrm driver
The simpledrm driver is a DRM driver for simplefb framebuffers as
provided by the kernel's boot code. This driver enables basic
graphical output on many different graphics devices that are provided
by the platform (e.g., EFI, VESA, embedded framebuffers).
With the kernel's simplefb infrastructure, the kernel receives a
pre-configured framebuffer from the system (i.e., firmware, boot
loader). It creates a platform device to which simpledrm attaches.
The system's framebuffer consists of a memory range, size and format.
Based on these values, simpledrm creates a DRM devices. No actual
modesetting is possible.
v2:
* rename driver to simpledrm
* add dri-devel to MAINTAINERS entry
* put native format first in primary-plane format list (Daniel)
* inline simplekms_device_cleanup() (Daniel)
* use helpers for shadow-buffered planes
* fix whitespace errors
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
MAINTAINERS | 7 +
drivers/gpu/drm/tiny/Kconfig | 16 +
drivers/gpu/drm/tiny/Makefile| 1 +
drivers/gpu/drm/tiny/simpledrm.c | 527 +++
4 files changed, 551 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/simpledrm.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3dc7b57be31d..e9d53daf8b58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5744,6 +5744,13 @@ S: Orphan / Obsolete
F: drivers/gpu/drm/savage/
F: include/uapi/drm/savage_drm.h
+DRM DRIVER FOR SIMPLE FRAMEBUFFERS
+M: Thomas Zimmermann
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/tiny/simplekms.c
+
DRM DRIVER FOR SIS VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/sis/
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 9bbaa1a69050..d46f95d9196d 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -38,6 +38,22 @@ config DRM_GM12U320
This is a KMS driver for projectors which use the GM12U320 chipset
for video transfer over USB2/3, such as the Acer C120 mini projector.
+config DRM_SIMPLEDRM
+ tristate "Simple framebuffer driver"
+ depends on DRM
+ select DRM_GEM_SHMEM_HELPER
+ select DRM_KMS_HELPER
+ help
+ DRM driver for simple platform-provided framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the firmware or bootloader before the kernel boots. Scanout
+ buffer, size, and display format must be provided via device tree,
+ UEFI, VESA, etc.
+
+ On x86 and compatible, you should also select CONFIG_X86_SYSFB to
+ use UEFI and VESA framebuffers.
+
config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index bef6780bdd6f..9cc847e756da 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -3,6 +3,7 @@
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
new file mode 100644
index ..0422c549b97a
--- /dev/null
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -0,0 +1,527 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"simpledrm"
+#define DRIVER_DESC"DRM driver for simple-framebuffer platform devices"
+#define DRIVER_DATE"20200625"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+/*
+ * Assume a monitor resolution of 96 dpi to
+ * get a somewhat reasonable screen size.
+ */
+#define RES_MM(d) \
+ (((d) * 254ul) / (96ul * 10ul))
+
+#define SIMPLEDRM_MODE(hd, vd) \
+ DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
+
+/*
+ * Helpers for simplefb
+ */
+
+static int
+simplefb_get_validated_int(struct drm_device *dev, const char *name,
+ uint32_t value)
+{
+ if (value > INT_MAX) {
+ drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
+ name, value);
+ return -EINVAL;
+ }
+ return (int)value;
+}
+
+static int
+simplefb_get_validated_int0(struct drm_device *dev, const char *name,
+ uint32_t value)
+{
+ if (!value) {
+ drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
+ name, value);
[PATCH v2 03/10] drm/aperture: Move fbdev conflict helpers into drm_aperture.h
Fbdev's helpers for handling conflicting framebuffers are related to
framebuffer apertures, not console emulation. Therefore move them into a
drm_aperture.h, which will contain the interfaces for the new aperture
helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
Documentation/gpu/drm-internals.rst | 6 +++
include/drm/drm_aperture.h | 60 +
include/drm/drm_fb_helper.h | 56 ++-
3 files changed, 69 insertions(+), 53 deletions(-)
create mode 100644 include/drm/drm_aperture.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index 12272b168580..4c7642d2ca34 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -75,6 +75,12 @@ update it, its value is mostly useless. The DRM core prints
it to the
kernel log at initialization time and passes it to userspace through the
DRM_IOCTL_VERSION ioctl.
+Managing Ownership of the Framebuffer Aperture
+--
+
+.. kernel-doc:: include/drm/drm_aperture.h
+ :internal:
+
Device Instance and Driver Handling
---
diff --git a/include/drm/drm_aperture.h b/include/drm/drm_aperture.h
new file mode 100644
index ..13766efe9517
--- /dev/null
+++ b/include/drm/drm_aperture.h
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: MIT */
+
+#ifndef _DRM_APERTURE_H_
+#define _DRM_APERTURE_H_
+
+#include
+#include
+
+/**
+ * drm_fb_helper_remove_conflicting_framebuffers - remove firmware-configured
framebuffers
+ * @a: memory range, users of which are to be removed
+ * @name: requesting driver name
+ * @primary: also kick vga16fb if present
+ *
+ * This function removes framebuffer devices (initialized by
firmware/bootloader)
+ * which use memory range described by @a. If @a is NULL all such devices are
+ * removed.
+ */
+static inline int
+drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary)
+{
+#if IS_REACHABLE(CONFIG_FB)
+ return remove_conflicting_framebuffers(a, name, primary);
+#else
+ return 0;
+#endif
+}
+
+/**
+ * drm_fb_helper_remove_conflicting_pci_framebuffers - remove
firmware-configured
+ * framebuffers for PCI
devices
+ * @pdev: PCI device
+ * @name: requesting driver name
+ *
+ * This function removes framebuffer devices (eg. initialized by firmware)
+ * using memory range configured for any of @pdev's memory bars.
+ *
+ * The function assumes that PCI device with shadowed ROM drives a primary
+ * display and so kicks out vga16fb.
+ */
+static inline int
+drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
+ const char *name)
+{
+ int ret = 0;
+
+ /*
+* WARNING: Apparently we must kick fbdev drivers before vgacon,
+* otherwise the vga fbdev driver falls over.
+*/
+#if IS_REACHABLE(CONFIG_FB)
+ ret = remove_conflicting_pci_framebuffers(pdev, name);
+#endif
+ if (ret == 0)
+ ret = vga_remove_vgacon(pdev);
+ return ret;
+}
+
+#endif
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 3b273f9ca39a..d06a3942fddb 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -30,13 +30,13 @@
#ifndef DRM_FB_HELPER_H
#define DRM_FB_HELPER_H
-struct drm_fb_helper;
-
+#include
#include
#include
#include
#include
-#include
+
+struct drm_fb_helper;
enum mode_set_atomic {
LEAVE_ATOMIC_MODE_SET,
@@ -451,54 +451,4 @@ drm_fbdev_generic_setup(struct drm_device *dev, unsigned
int preferred_bpp)
#endif
-/**
- * drm_fb_helper_remove_conflicting_framebuffers - remove firmware-configured
framebuffers
- * @a: memory range, users of which are to be removed
- * @name: requesting driver name
- * @primary: also kick vga16fb if present
- *
- * This function removes framebuffer devices (initialized by
firmware/bootloader)
- * which use memory range described by @a. If @a is NULL all such devices are
- * removed.
- */
-static inline int
-drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
- const char *name, bool primary)
-{
-#if IS_REACHABLE(CONFIG_FB)
- return remove_conflicting_framebuffers(a, name, primary);
-#else
- return 0;
-#endif
-}
-
-/**
- * drm_fb_helper_remove_conflicting_pci_framebuffers - remove
firmware-configured framebuffers for PCI devices
- * @pdev: PCI device
- * @name: requesting driver name
- *
- * This function removes framebuffer devices (eg. initialized by firmware)
- * using memory range configured for any of @pdev's memory bars.
- *
- * The function assumes that PCI device with shadowed ROM drives a primary
- * display and so kicks out vga16fb.
- */
-static inline int
-drm_
[PATCH v2 08/10] drm/simpledrm: Acquire clocks from DT device node
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 108 +++
1 file changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index c9cef2b50de6..10ca3373b61f 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
#include
#include
@@ -190,6 +192,12 @@ struct simpledrm_device {
struct drm_device dev;
struct platform_device *pdev;
+ /* clocks */
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ unsigned int clk_count;
+ struct clk **clks;
+#endif
+
/* simplefb settings */
struct drm_display_mode mode;
const struct drm_format_info *format;
@@ -211,6 +219,103 @@ static struct simpledrm_device
*simpledrm_device_of_dev(struct drm_device *dev)
return container_of(dev, struct simpledrm_device, dev);
}
+/*
+ * Hardware
+ */
+
+#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simpledrm_device_release_clocks(void *res)
+{
+ struct simpledrm_device *sdev = simpledrm_device_of_dev(res);
+ unsigned int i;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ if (sdev->clks[i]) {
+ clk_disable_unprepare(sdev->clks[i]);
+ clk_put(sdev->clks[i]);
+ }
+ }
+}
+
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+ struct drm_device *dev = &sdev->dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct clk *clock;
+ unsigned int i;
+ int ret;
+
+ if (dev_get_platdata(&pdev->dev) || !of_node)
+ return 0;
+
+ sdev->clk_count = of_clk_get_parent_count(of_node);
+ if (!sdev->clk_count)
+ return 0;
+
+ sdev->clks = drmm_kzalloc(dev, sdev->clk_count * sizeof(sdev->clks[0]),
+ GFP_KERNEL);
+ if (!sdev->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ clock = of_clk_get(of_node, i);
+ if (IS_ERR(clock)) {
+ ret = PTR_ERR(clock);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "clock %u not found: %d\n", i, ret);
+ continue;
+ }
+ ret = clk_prepare_enable(clock);
+ if (ret) {
+ drm_err(dev, "failed to enable clock %u: %d\n",
+ i, ret);
+ clk_put(clock);
+ }
+ sdev->clks[i] = clock;
+ }
+
+ return devm_add_action_or_reset(&pdev->dev,
+ simpledrm_device_release_clocks,
+ sdev);
+
+err:
+ while (i) {
+ --i;
+ if (sdev->clks[i]) {
+ clk_disable_unprepare(sdev->clks[i]);
+ clk_put(sdev->clks[i]);
+ }
+ }
+ return ret;
+}
+#else
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+ return 0;
+}
+#endif
+
/*
* Simplefb settings
*/
@@ -534,6 +639,9 @@ simpledrm_device_create(struct drm_driver *drv, struct
platform_device *pdev)
return ERR_CAST(sdev);
sdev->pdev = pdev;
+ ret = simpledrm_device_init_clocks(sdev);
+ if (ret)
+ return ERR_PTR(ret);
ret = simpledrm_device_init_fb(sdev);
if (ret)
return ERR_PTR(ret);
--
2.30.1
___
dri-devel mailing list
dri-de
[PATCH v2 10/10] drm/simpledrm: Acquire memory aperture for framebuffer
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kick-out the simpledrm
driver before taking over the device.
v2:
* adapt to aperture changes
* use drm_dev_unplug() and drm_dev_enter/exit()
* don't split error string
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/simpledrm.c | 83 ++--
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d46f95d9196d..5b72dd8e93f9 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -41,6 +41,7 @@ config DRM_GM12U320
config DRM_SIMPLEDRM
tristate "Simple framebuffer driver"
depends on DRM
+ select DRM_APERTURE
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
help
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2e27eeb791a1..67d33af19086 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -5,7 +5,9 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -37,6 +39,12 @@
#define SIMPLEDRM_MODE(hd, vd) \
DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
+/*
+ * Protects the platform device's drvdata against
+ * concurrent manipulation.
+ */
+static DEFINE_SPINLOCK(simpledrm_drvdata_lock);
+
/*
* Helpers for simplefb
*/
@@ -515,16 +523,53 @@ static int simpledrm_device_init_fb(struct
simpledrm_device *sdev)
* Memory management
*/
+static void simpledrm_aperture_detach(struct drm_device *dev, resource_size_t
base,
+ resource_size_t size)
+{
+ struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
+ struct platform_device *pdev = sdev->pdev;
+
+ if (WARN_ON(drm_dev_is_unplugged(dev)))
+ return; /* BUG: driver already got detached */
+
+ /*
+* If simpledrm gets detached from the aperture, it's like unplugging
+* the device. So call drm_dev_unplug().
+*/
+ drm_dev_unplug(dev);
+
+ spin_lock(&simpledrm_drvdata_lock);
+ sdev = platform_get_drvdata(pdev);
+ platform_set_drvdata(pdev, NULL); /* required; see simpledrm_remove() */
+ spin_unlock(&simpledrm_drvdata_lock);
+}
+
+static const struct drm_aperture_funcs simpledrm_aperture_funcs = {
+ .detach = simpledrm_aperture_detach,
+};
+
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 drm_aperture *ap;
void __iomem *screen_base;
+ int ret;
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem)
return -EINVAL;
+ ap = devm_aperture_acquire(dev, mem->start, resource_size(mem),
+ &simpledrm_aperture_funcs);
+ if (IS_ERR(ap)) {
+ ret = PTR_ERR(ap);
+ drm_err(dev, "could not acquire memory range [0x%llx:0x%llx]:
error %d\n",
+ mem->start, mem->end, ret);
+ return ret;
+ }
+
screen_base = devm_ioremap_wc(&pdev->dev, mem->start,
resource_size(mem));
if (!screen_base)
@@ -625,12 +670,18 @@ simpledrm_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
void *vmap = shadow_plane_state->map[0].vaddr; /* TODO: Use mapping
abstraction properly */
+ struct drm_device *dev = &sdev->dev;
+ int idx;
if (!fb)
return;
+ if (!drm_dev_enter(dev, &idx))
+ return;
+
drm_fb_blit_dstclip(sdev->screen_base, sdev->pitch,
sdev->format->format, vmap, fb);
+ drm_dev_exit(idx);
}
static void
@@ -642,7 +693,9 @@ simpledrm_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
void *vmap = shadow_plane_state->map[0].vaddr; /* TODO: Use mapping
abstraction properly */
struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_device *dev = &sdev->dev;
struct drm_rect clip;
+ int idx;
if (!fb)
return;
@@ -650,8 +703,13 @@ simpledrm_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state,
&clip))
return;
+ if (!drm_dev_enter(dev, &idx))
+ return;
+
drm_fb_blit_rect_dstclip(sdev->screen_base, sdev->pi
[PATCH v2 07/10] drm/simpledrm: Initialize framebuffer data from device-tree node
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.
v2:
* add Device Tree match table
* clean-up parser wrappers
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 89
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 4f0d4ec0b432..c9cef2b50de6 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -114,6 +114,74 @@ simplefb_get_format_pd(struct drm_device *dev,
return simplefb_get_validated_format(dev, pd->format);
}
+static int
+simplefb_read_u32_of(struct drm_device *dev, struct device_node *of_node,
+const char *name, u32 *value)
+{
+ int ret = of_property_read_u32(of_node, name, value);
+
+ if (ret)
+ drm_err(dev, "simplefb: cannot parse framebuffer %s: error
%d\n",
+ name, ret);
+ return ret;
+}
+
+static int
+simplefb_read_string_of(struct drm_device *dev, struct device_node *of_node,
+ const char *name, const char **value)
+{
+ int ret = of_property_read_string(of_node, name, value);
+
+ if (ret)
+ drm_err(dev, "simplefb: cannot parse framebuffer %s: error
%d\n",
+ name, ret);
+ return ret;
+}
+
+static int
+simplefb_get_width_of(struct drm_device *dev, struct device_node *of_node)
+{
+ u32 width;
+ int ret = simplefb_read_u32_of(dev, of_node, "width", &width);
+
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int0(dev, "width", width);
+}
+
+static int
+simplefb_get_height_of(struct drm_device *dev, struct device_node *of_node)
+{
+ u32 height;
+ int ret = simplefb_read_u32_of(dev, of_node, "height", &height);
+
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int0(dev, "height", height);
+}
+
+static int
+simplefb_get_stride_of(struct drm_device *dev, struct device_node *of_node)
+{
+ u32 stride;
+ int ret = simplefb_read_u32_of(dev, of_node, "stride", &stride);
+
+ if (ret)
+ return ret;
+ return simplefb_get_validated_int(dev, "stride", stride);
+}
+
+static const struct drm_format_info *
+simplefb_get_format_of(struct drm_device *dev, struct device_node *of_node)
+{
+ const char *format;
+ int ret = simplefb_read_string_of(dev, of_node, "format", &format);
+
+ if (ret)
+ return ERR_PTR(ret);
+ return simplefb_get_validated_format(dev, format);
+}
+
/*
* Simple Framebuffer device
*/
@@ -166,6 +234,7 @@ static int simpledrm_device_init_fb(struct simpledrm_device
*sdev)
struct drm_device *dev = &sdev->dev;
struct platform_device *pdev = sdev->pdev;
const struct simplefb_platform_data *pd = dev_get_platdata(&pdev->dev);
+ struct device_node *of_node = pdev->dev.of_node;
if (pd) {
width = simplefb_get_width_pd(dev, pd);
@@ -180,6 +249,19 @@ static int simpledrm_device_init_fb(struct
simpledrm_device *sdev)
format = simplefb_get_format_pd(dev, pd);
if (IS_ERR(format))
return PTR_ERR(format);
+ } else if (of_node) {
+ width = simplefb_get_width_of(dev, of_node);
+ if (width < 0)
+ return width;
+ height = simplefb_get_height_of(dev, of_node);
+ if (height < 0)
+ return height;
+ stride = simplefb_get_stride_of(dev, of_node);
+ if (stride < 0)
+ return stride;
+ format = simplefb_get_format_of(dev, of_node);
+ if (IS_ERR(format))
+ return PTR_ERR(format);
} else {
drm_err(dev, "no simplefb configuration found\n");
return -ENODEV;
@@ -516,9 +598,16 @@ static int simpledrm_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id simpledrm_of_match_table[] = {
+ { .compatible = "simple-framebuffer", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, simpledrm_of_match_table);
+
static struct platform_driver simpledrm_platform_driver = {
.driver = {
.name = "simple-framebuffer", /* connect to sysfb */
+ .of_match_table = simpledrm_of_match_table,
},
.probe = simpledrm_probe,
.remove = simpledrm_remove,
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] drm/simpledrm: Acquire regulators from DT device node
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.
v2:
* use strscpy()
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 128 +++
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 10ca3373b61f..2e27eeb791a1 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
@@ -197,6 +198,11 @@ struct simpledrm_device {
unsigned int clk_count;
struct clk **clks;
#endif
+ /* regulators */
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ unsigned int regulator_count;
+ struct regulator **regulators;
+#endif
/* simplefb settings */
struct drm_display_mode mode;
@@ -316,6 +322,125 @@ static int simpledrm_device_init_clocks(struct
simpledrm_device *sdev)
}
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+
+static void simpledrm_device_release_regulators(void *res)
+{
+ struct simpledrm_device *sdev = simpledrm_device_of_dev(res);
+ unsigned int i;
+
+ for (i = 0; i < sdev->regulator_count; ++i) {
+ if (sdev->regulators[i]) {
+ regulator_disable(sdev->regulators[i]);
+ regulator_put(sdev->regulators[i]);
+ }
+ }
+}
+
+static int simpledrm_device_init_regulators(struct simpledrm_device *sdev)
+{
+ struct drm_device *dev = &sdev->dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ unsigned int count = 0, i = 0;
+ int ret;
+
+ if (dev_get_platdata(&pdev->dev) || !of_node)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(of_node, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ ++count;
+ }
+
+ if (!count)
+ return 0;
+
+ sdev->regulators = drmm_kzalloc(dev,
+ count * sizeof(sdev->regulators[0]),
+ GFP_KERNEL);
+ if (!sdev->regulators)
+ return -ENOMEM;
+
+ for_each_property_of_node(of_node, prop) {
+ char name[32]; /* 32 is max size of property name */
+ size_t len;
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p == prop->name)
+ continue;
+ len = strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1;
+ strscpy(name, prop->name, min(sizeof(name), len));
+
+ regulator = regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ ret = PTR_ERR(regulator);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "regulator %s not found: %d\n",
+ name, ret);
+ continue;
+ }
+
+ ret = regulator_enable(regulator);
+ if (ret) {
+ drm_err(dev, "failed to enable regulator %u: %d\n",
+ i, ret);
+ regulator_put(regulator);
+ }
+
+ sdev->regulators[i++] = regulator;
+ }
+ sdev->regulator_count = i;
+
+ return devm_add_action_or_reset(&pdev->dev,
+ simpledrm_device_release_regulators,
+ sdev);
+
+err:
+ w
Re: [PATCH v16 1/2] drm/tegra: dc: Support memory bandwidth management
18.03.2021 12:31, Michał Mirosław пишет:
>> static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
>> @@ -2430,6 +2781,7 @@ static const struct tegra_dc_soc_info
>> tegra194_dc_soc_info = {
>> .has_nvdisplay = true,
>> .wgrps = tegra194_dc_wgrps,
>> .num_wgrps = ARRAY_SIZE(tegra194_dc_wgrps),
>> +.plane_tiled_memory_bandwidth_x2 = false,
>> };
> For globals you will have .x = false by default; I'm not sure those entries
> add much value.
>
> Reviewed-by: Michał Mirosław
IIRC, in the past Thierry preferred to add the defaults to this driver
in order to ease reading/understanding of the code. So I added them for
consistency.
Thank you very much for helping with the review!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/10] drm/simpledrm: Acquire clocks from DT device node
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers.
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: nerdopolis
Thanks for your patch!
> --- a/drivers/gpu/drm/tiny/simpledrm.c
> +++ b/drivers/gpu/drm/tiny/simpledrm.c
> +static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
> +{
> + struct drm_device *dev = &sdev->dev;
> + struct platform_device *pdev = sdev->pdev;
> + struct device_node *of_node = pdev->dev.of_node;
> + struct clk *clock;
> + unsigned int i;
> + int ret;
> +
> + if (dev_get_platdata(&pdev->dev) || !of_node)
> + return 0;
> +
> + sdev->clk_count = of_clk_get_parent_count(of_node);
> + if (!sdev->clk_count)
> + return 0;
> +
> + sdev->clks = drmm_kzalloc(dev, sdev->clk_count *
> sizeof(sdev->clks[0]),
> + GFP_KERNEL);
> + if (!sdev->clks)
> + return -ENOMEM;
> +
> + for (i = 0; i < sdev->clk_count; ++i) {
> + clock = of_clk_get(of_node, i);
> + if (IS_ERR(clock)) {
> + ret = PTR_ERR(clock);
> + if (ret == -EPROBE_DEFER)
> + goto err;
> + drm_err(dev, "clock %u not found: %d\n", i, ret);
> + continue;
> + }
> + ret = clk_prepare_enable(clock);
> + if (ret) {
> + drm_err(dev, "failed to enable clock %u: %d\n",
> + i, ret);
> + clk_put(clock);
> + }
> + sdev->clks[i] = clock;
> + }
of_clk_bulk_get_all() + clk_bulk_prepare_enable()?
There's also devm_clk_bulk_get_all(), but not for the OF variant.
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Few typo fixes
s/instatiated/instantiated/ s/unreference/unreferenced/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/drm_property.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c index 6ee04803c362..27c824a6eb60 100644 --- a/drivers/gpu/drm/drm_property.c +++ b/drivers/gpu/drm/drm_property.c @@ -43,7 +43,7 @@ * property types and ranges. * * Properties don't store the current value directly, but need to be - * instatiated by attaching them to a &drm_mode_object with + * instantiated by attaching them to a &drm_mode_object with * drm_object_attach_property(). * * Property values are only 64bit. To support bigger piles of data (like gamma @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); * @id: id of the blob property * * If successful, this takes an additional reference to the blob property. - * callers need to make sure to eventually unreference the returned property + * callers need to make sure to eventually unreferenced the returned property * again, using drm_property_blob_put(). * * Return: -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey
Let me summarize the background of this patch:
In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,
It will submit first jobs of each ring and do guilty job re-check.
At that point, We had to make sure each job is in the mirror list(or
re-inserted back already).
But we found the current code never re-insert the job to mirror list in the
2nd, 3rd job_timeout thread(Bailing TDR thread).
This not only will cause memleak of the bailing jobs. What’s more important,
the 1st tdr thread can never iterate the bailing job and set its guilty status
to a correct status.
Therefore, we had to re-insert the job(or even not delete node) for bailing job.
For the above V3 patch, the racing condition in my mind is:
we cannot make sure all bailing jobs are finished before we do
amdgpu_device_recheck_guilty_jobs.
Based on this insight, I think we have two options to solve this issue:
1. Skip delete node in tdr thread2, thread3, 4 … (using mutex or atomic
variable)
2. Re-insert back bailing job, and meanwhile use semaphore in each tdr
thread to keep the sequence as expected and ensure each job is in the mirror
list when do resubmit step.
For Option1, logic is simpler and we need only one global atomic variable:
What do you think about this plan?
Option1 should look like the following logic:
+static atomic_t in_reset; //a global atomic var for synchronization
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb);
/**
@@ -295,6 +296,12 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* drm_sched_cleanup_jobs. It will be reinserted back after
sched->thread
* is parked at which point it's safe.
*/
+ if (atomic_cmpxchg(&in_reset, 0, 1) != 0) { //skip delete node
if it’s thead1,2,3,….
+ spin_unlock(&sched->job_list_lock);
+ drm_sched_start_timeout(sched);
+ return;
+ }
+
list_del_init(&job->node);
spin_unlock(&sched->job_list_lock);
@@ -320,6 +327,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(&sched->job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
+ atomic_set(&in_reset, 0); //reset in_reset when the first thread
finished tdr
}
Thanks,
Jack
From: amd-gfx On Behalf Of Zhang, Jack
(Jian)
Sent: Wednesday, March 17, 2021 11:11 PM
To: Christian König ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
Christian ; Liu, Monk ; Deng, Emily
; Rob Herring ; Tomeu Vizoso
; Steven Price ; Grodzovsky,
Andrey
Subject: Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
[AMD Official Use Only - Internal Distribution Only]
[AMD Official Use Only - Internal Distribution Only]
Hi，Andrey，
Good catch，I will expore this corner case and give feedback soon～
Best，
Jack
From: Grodzovsky, Andrey
mailto:andrey.grodzov...@amd.com>>
Sent: Wednesday, March 17, 2021 10:50:59 PM
To: Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>;
Zhang, Jack (Jian) mailto:jack.zha...@amd.com>>;
dri-devel@lists.freedesktop.org
mailto:dri-devel@lists.freedesktop.org>>;
amd-...@lists.freedesktop.org
mailto:amd-...@lists.freedesktop.org>>; Koenig,
Christian mailto:christian.koe...@amd.com>>; Liu,
Monk mailto:monk@amd.com>>; Deng, Emily
mailto:emily.d...@amd.com>>; Rob Herring
mailto:r...@kernel.org>>; Tomeu Vizoso
mailto:tomeu.viz...@collabora.com>>; Steven Price
mailto:steven.pr...@arm.com>>
Subject: Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
I actually have a race condition concern here - see bellow -
On 2021-03-17 3:43 a.m., Christian König wrote:
> I was hoping Andrey would take a look since I'm really busy with other
> work right now.
>
> Regards,
> Christian.
>
> Am 17.03.21 um 07:46 schrieb Zhang, Jack (Jian):
>> Hi, Andrey/Crhistian and Team,
>>
>> I didn't receive the reviewer's message from maintainers on panfrost
>> driver for several days.
>> Due to this patch is urgent for my current working project.
>> Would you please help to give some review ideas?
>>
>> Many Thanks,
>> Jack
>> -Original Message-
>> From: Zhang, Jack (Jian)
>> Sent: Tuesday, March 16, 2021 3:20 PM
>> To: dri-devel@lists.freedesktop.org;
>> amd-...@lists.freedesktop.org;
>> Koenig, Christian
>> mailto:christian.koe...@amd.com>>; Grodzovsky,
>> Andrey
>> mailto:andrey.grodzov...@amd.com>>; Liu, Monk
>> mailto:monk@amd.com>>; Deng,
>> Emily mailto:emily.d...@amd.com>>; Rob Herring
>> mailto:r...@kernel.org>>; Tomeu
>> Vizoso mailto:tomeu.viz...@collabora.com>>;
>> Steven Price
[PATCH] drm/msm/dpu: enable DPU_SSPP_QOS_8LVL for SM8250
SM8250 platform has a 8-Levels VIG QoS setting. This setting was missed
due to bad interaction with b8dab65b5ac3 ("drm/msm/dpu: Move
DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks"), which was applied in
parallel.
Fixes: d21fc5dfc3df ("drm/msm/dpu1: add support for qseed3lite used on sm8250")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index bffe5969ed7e..f21f630af476 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -22,7 +22,7 @@
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4))
#define VIG_SM8250_MASK \
- (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+ (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/10] drm/simpledrm: Acquire clocks from DT device node
Hi
Am 18.03.21 um 11:39 schrieb Geert Uytterhoeven:
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
Thanks for your patch!
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
+static int simpledrm_device_init_clocks(struct simpledrm_device *sdev)
+{
+ struct drm_device *dev = &sdev->dev;
+ struct platform_device *pdev = sdev->pdev;
+ struct device_node *of_node = pdev->dev.of_node;
+ struct clk *clock;
+ unsigned int i;
+ int ret;
+
+ if (dev_get_platdata(&pdev->dev) || !of_node)
+ return 0;
+
+ sdev->clk_count = of_clk_get_parent_count(of_node);
+ if (!sdev->clk_count)
+ return 0;
+
+ sdev->clks = drmm_kzalloc(dev, sdev->clk_count * sizeof(sdev->clks[0]),
+ GFP_KERNEL);
+ if (!sdev->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < sdev->clk_count; ++i) {
+ clock = of_clk_get(of_node, i);
+ if (IS_ERR(clock)) {
+ ret = PTR_ERR(clock);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ drm_err(dev, "clock %u not found: %d\n", i, ret);
+ continue;
+ }
+ ret = clk_prepare_enable(clock);
+ if (ret) {
+ drm_err(dev, "failed to enable clock %u: %d\n",
+ i, ret);
+ clk_put(clock);
+ }
+ sdev->clks[i] = clock;
+ }
of_clk_bulk_get_all() + clk_bulk_prepare_enable()?
There's also devm_clk_bulk_get_all(), but not for the OF variant.
Right, you mentioned this on the original patch set. I tried to use the
functions, but TBH I found them to obfuscate the overall logic of the
function. So I went back to the original code. Hopefully this is not too
much of an issue.
Best regards
Thomas
Gr{oetje,eeting}s,
Geert
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: Fix few typo
s/initialy/initially/ s/desined/designed/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/meson/meson_venc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/meson/meson_venc.c b/drivers/gpu/drm/meson/meson_venc.c index 5e2236ec189f..3c55ed003359 100644 --- a/drivers/gpu/drm/meson/meson_venc.c +++ b/drivers/gpu/drm/meson/meson_venc.c @@ -45,7 +45,7 @@ * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI. * The ENCP is designed for Progressive encoding but can also generate - * 1080i interlaced pixels, and was initialy desined to encode pixels for + * 1080i interlaced pixels, and was initially designed to encode pixels for * VDAC to output RGB ou YUV analog outputs. * It's output is only used through the ENCP_DVI encoder for HDMI. * The ENCL LVDS encoder is not implemented. -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
drm-misc-fixes-2021-03-18: drm-misc-fixes for v5.12-rc4: - Make ttm_bo_unpin() not wraparound on too many unpins. - Fix coccicheck warning in omap. The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 13:59:23 +0200) drm-misc-fixes for v5.12-rc4: - Make ttm_bo_unpin() not wraparound on too many unpins. - Fix coccicheck warning in omap. Christian König (1): drm/ttm: make ttm_bo_unpin more defensive Junlin Yang (1): drm/omap: dsi: fix unsigned expression compared with zero drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- include/drm/ttm/ttm_bo_api.h | 6 -- 2 files changed, 8 insertions(+), 5 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Fix a typo
s/traing/training/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index c325d6f53a71..db18e4f6cf5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
*psp, uint32_t ops)
if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
/*
-* Long traing will encroach certain mount of bottom VRAM,
+* Long training will encroach certain mount of bottom VRAM,
* saving the content of this bottom VRAM to system memory
* before training, and restoring it after training to avoid
* VRAM corruption.
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel - Covering for Rodrigo during his absence this week. drm-intel-fixes-2021-03-18: drm/i915 fixes for v5.12-rc4: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ BR, Jani. The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-03-18 for you to fetch changes up to 6a77c6bb7260bd5000f95df454d9f8cdb1af7132: i915/perf: Start hrtimer only if sampling the OA buffer (2021-03-17 12:51:37 +0200) drm/i915 fixes for v5.12-rc4: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ Umesh Nerlige Ramappa (1): i915/perf: Start hrtimer only if sampling the OA buffer Ville Syrjälä (1): drm/i915: Workaround async flip + VT-d corruption on HSW/BDW drivers/gpu/drm/i915/i915_perf.c | 13 + drivers/gpu/drm/i915/i915_reg.h | 23 ++- drivers/gpu/drm/i915/intel_pm.c | 16 +++- 3 files changed, 42 insertions(+), 10 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-fixes
On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst wrote: > > drm-misc-fixes-2021-03-18: > drm-misc-fixes for v5.12-rc4: > - Make ttm_bo_unpin() not wraparound on too many unpins. > - Fix coccicheck warning in omap. Still missing the 2 patches from drm-misc-next-fixes, and those being left out also means drm-misc-next isn't pushed to for-linux-next branch, which is causing a ton of confusion itself. -Daniel > The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: > > drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 > > for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: > > drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 > 13:59:23 +0200) > > > drm-misc-fixes for v5.12-rc4: > - Make ttm_bo_unpin() not wraparound on too many unpins. > - Fix coccicheck warning in omap. > > > Christian König (1): > drm/ttm: make ttm_bo_unpin more defensive > > Junlin Yang (1): > drm/omap: dsi: fix unsigned expression compared with zero > > drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- > include/drm/ttm/ttm_bo_api.h | 6 -- > 2 files changed, 8 insertions(+), 5 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 2/2] backlight: qcom-wled: Correct the sync_toggle sequence
As per the current implementation, after FSC (Full Scale Current) and brightness update the sync bits are set-then-cleared. But, the FSC and brightness sync takes place when the sync bits are set (e.g. on a rising edge). So the hardware team recommends a clear-then-set approach in order to guarantee such a transition regardless of the previous register state. Signed-off-by: Kiran Gunda Reviewed-by: Daniel Thompson --- drivers/video/backlight/qcom-wled.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index e9fbe24..7c02f87 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled) rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED3_SINK_REG_SYNC, - mask, mask); + mask, WLED3_SINK_REG_SYNC_CLEAR); if (rc < 0) return rc; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED3_SINK_REG_SYNC, - mask, WLED3_SINK_REG_SYNC_CLEAR); + mask, mask); return rc; } @@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled *wled) int rc; u8 val; - val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : -WLED5_SINK_REG_SYNC_MOD_B_BIT; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, val); + WLED5_SINK_REG_SYNC_MASK, 0); if (rc < 0) return rc; + val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : +WLED5_SINK_REG_SYNC_MOD_B_BIT; return regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, 0); + WLED5_SINK_REG_SYNC_MASK, val); } static int wled_ovp_fault_status(struct wled *wled, bool *fault_set) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adopting the common wled3_sync_toggle() for WLED5 and
introducing new code to the brightness update path to compensate.
Signed-off-by: Kiran Gunda
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index fc8b443..e9fbe24 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -348,7 +348,7 @@ static int wled3_sync_toggle(struct wled *wled)
return rc;
}
-static int wled5_sync_toggle(struct wled *wled)
+static int wled5_mod_sync_toggle(struct wled *wled)
{
int rc;
u8 val;
@@ -445,10 +445,23 @@ static int wled_update_status(struct backlight_device *bl)
goto unlock_mutex;
}
- rc = wled->wled_sync_toggle(wled);
- if (rc < 0) {
- dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- goto unlock_mutex;
+ if (wled->version < 5) {
+ rc = wled->wled_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled sync failed rc:%d\n",
rc);
+ goto unlock_mutex;
+ }
+ } else {
+ /*
+* For WLED5 toggling the MOD_SYNC_BIT updates the
+* brightness
+*/
+ rc = wled5_mod_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled mod sync failed
rc:%d\n",
+ rc);
+ goto unlock_mutex;
+ }
}
}
@@ -1459,7 +1472,7 @@ static int wled_configure(struct wled *wled)
size = ARRAY_SIZE(wled5_opts);
*cfg = wled5_config_defaults;
wled->wled_set_brightness = wled5_set_brightness;
- wled->wled_sync_toggle = wled5_sync_toggle;
+ wled->wled_sync_toggle = wled3_sync_toggle;
wled->wled_cabc_config = wled5_cabc_config;
wled->wled_ovp_delay = wled5_ovp_delay;
wled->wled_auto_detection_required =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 0/2] Fix WLED FSC Sync and brightness Sync settings
This patch series has the following two WLED fixes 1. As per the current implementation, for WLED5, after the FSC (Full Scale Current) update the driver is incorrectly toggling the MOD_SYNC register instead of toggling the SYNC register. The patch 1/2 fixes this by toggling the SYNC register after FSC update. 2. Currently, the sync bits are set-then-cleared after FSC and brightness update. As per hardware team recommendation the FSC and brightness sync takes place from clear-then-set transition of the sync bits. The patch 2/2 fies this issue. changes from V4: 1. Rebased this patch series on the below patch. "backlight-qcom-wled-Use-sink_addr-for-sync-toggle.patch". Changes from V3: 1. Updated the patch description as per Daneil's suggestion. 2. Added Daniel's "Reviewed-by" tag for patch 2/2. 3. Updated the cover letter to use "set" and "clear" properly. Changes from V2: 1. Added Daniel's "Reviewed-by" tag for patch 1/2. 2. Updated the patch 2/2 description with "set" and "clear" terminology instead of "1" and "0". 3. Updated the cover letter with "set" and "clear" terminology instead of "1" and "0". Changes from V1: 1. Updated the cover letter. 2. Updated the description of the patches as per Daniel's suggestion. Kiran Gunda (2): backlight: qcom-wled: Fix FSC update issue for WLED5 backlight: qcom-wled: Correct the sync_toggle sequence drivers/video/backlight/qcom-wled.c | 37 + 1 file changed, 25 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/ttm: move swapout logic around v2
Move the iteration of the global lru into the new function
ttm_global_swapout() and use that instead in drivers.
v2: consistently return int
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 57 -
drivers/gpu/drm/ttm/ttm_device.c| 29 +++
drivers/gpu/drm/ttm/ttm_tt.c| 2 +-
drivers/gpu/drm/vmwgfx/ttm_memory.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 3 +-
include/drm/ttm/ttm_device.h| 2 +
7 files changed, 53 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3c23e863a3f0..66e00b404ec3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1193,56 +1193,35 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_wait);
-/*
- * A buffer object shrink method that tries to swap out the first
- * buffer object on the bo_global::swap_lru list.
- */
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
+int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
+ gfp_t gfp_flags)
{
struct ttm_global *glob = &ttm_glob;
- struct ttm_buffer_object *bo;
- int ret = -EBUSY;
bool locked;
- unsigned i;
-
- spin_lock(&glob->lru_lock);
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
- list_for_each_entry(bo, &glob->swap_lru[i], swap) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked,
- NULL))
- continue;
-
- if (!ttm_bo_get_unless_zero(bo)) {
- if (locked)
- dma_resv_unlock(bo->base.resv);
- continue;
- }
+ int ret;
- ret = 0;
- break;
- }
- if (!ret)
- break;
- }
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL))
+ return -EBUSY;
- if (ret) {
- spin_unlock(&glob->lru_lock);
- return ret;
+ if (!ttm_bo_get_unless_zero(bo)) {
+ if (locked)
+ dma_resv_unlock(bo->base.resv);
+ return -EBUSY;
}
if (bo->deleted) {
- ret = ttm_bo_cleanup_refs(bo, false, false, locked);
+ ttm_bo_cleanup_refs(bo, false, false, locked);
ttm_bo_put(bo);
- return ret;
+ return 0;
}
ttm_bo_del_from_lru(bo);
+ /* TODO: Cleanup the locking */
spin_unlock(&glob->lru_lock);
- /**
+ /*
* Move to system cached
*/
-
if (bo->mem.mem_type != TTM_PL_SYSTEM) {
struct ttm_operation_ctx ctx = { false, false };
struct ttm_resource evict_mem;
@@ -1262,29 +1241,26 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
}
}
- /**
+ /*
* Make sure BO is idle.
*/
-
ret = ttm_bo_wait(bo, false, false);
if (unlikely(ret != 0))
goto out;
ttm_bo_unmap_virtual(bo);
- /**
+ /*
* Swap out. Buffer will be swapped in again as soon as
* anyone tries to access a ttm page.
*/
-
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
- /**
-*
+ /*
* Unreserve without putting on LRU to avoid swapping out an
* already swapped buffer.
*/
@@ -1293,7 +1269,6 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
ttm_bo_put(bo);
return ret;
}
-EXPORT_SYMBOL(ttm_bo_swapout);
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
{
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 95e1b7b1f2e6..b1424189fdfb 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -102,6 +102,35 @@ static int ttm_global_init(void)
return ret;
}
+/**
+ * A buffer object shrink method that tries to swap out the first
+ * buffer object on the global::swap_lru list.
+ */
+int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
+{
+ struct ttm_global *glob = &ttm_glob;
+ struct ttm_buffer_object *bo;
+ unsigned i;
+ int ret;
+
+ spin_lock(&glob->lru_lock);
+ for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
+ list_for_each_entry(bo, &glob->swap_lru[i], swap) {
+ uint32_t num_pages = bo->ttm->num_pages;
+
+ ret = ttm_bo_swapout(bo, ctx, gfp_flags);
+ /* t
[PATCH 2/3] drm/ttm: remove swap LRU v3
Instead evict round robin from each devices SYSTEM and TT domain.
v2: reorder num_pages access reported by Dan's script
v3: fix rebase fallout, num_pages should be 32bit
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 29 --
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c| 60 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 1 -
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_device.h| 7 +---
7 files changed, 48 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 66e00b404ec3..3673157527ff 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -73,7 +73,6 @@ static void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
struct ttm_device *bdev = bo->bdev;
- list_del_init(&bo->swap);
list_del_init(&bo->lru);
if (bdev->funcs->del_from_lru_notify)
@@ -105,16 +104,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
man = ttm_manager_type(bdev, mem->mem_type);
list_move_tail(&bo->lru, &man->lru[bo->priority]);
- if (man->use_tt && bo->ttm &&
- !(bo->ttm->page_flags & (TTM_PAGE_FLAG_SG |
-TTM_PAGE_FLAG_SWAPPED))) {
- struct list_head *swap;
-
- swap = &ttm_glob.swap_lru[bo->priority];
- list_move_tail(&bo->swap, swap);
- } else {
- list_del_init(&bo->swap);
- }
if (bdev->funcs->del_from_lru_notify)
bdev->funcs->del_from_lru_notify(bo);
@@ -129,9 +118,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
ttm_bo_bulk_move_set_pos(&bulk->vram[bo->priority], bo);
break;
}
- if (bo->ttm && !(bo->ttm->page_flags &
-(TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED)))
- ttm_bo_bulk_move_set_pos(&bulk->swap[bo->priority], bo);
}
}
EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
@@ -169,20 +155,6 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
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->swap[i];
- struct list_head *lru;
-
- if (!pos->first)
- continue;
-
- dma_resv_assert_held(pos->first->base.resv);
- dma_resv_assert_held(pos->last->base.resv);
-
- lru = &ttm_glob.swap_lru[i];
- list_bulk_move_tail(lru, &pos->first->swap, &pos->last->swap);
- }
}
EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
@@ -1065,7 +1037,6 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
kref_init(&bo->kref);
INIT_LIST_HEAD(&bo->lru);
INIT_LIST_HEAD(&bo->ddestroy);
- INIT_LIST_HEAD(&bo->swap);
bo->bdev = bdev;
bo->type = type;
bo->mem.mem_type = TTM_PL_SYSTEM;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e5819fec4..a2a17c84ceb3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -303,7 +303,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
atomic_inc(&ttm_glob.bo_count);
INIT_LIST_HEAD(&fbo->base.ddestroy);
INIT_LIST_HEAD(&fbo->base.lru);
- INIT_LIST_HEAD(&fbo->base.swap);
fbo->base.moving = NULL;
drm_vma_node_reset(&fbo->base.base.vma_node);
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index b1424189fdfb..2096a0fd9c35 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -67,7 +67,6 @@ static int ttm_global_init(void)
unsigned long num_pages;
struct sysinfo si;
int ret = 0;
- unsigned i;
mutex_lock(&ttm_global_mutex);
if (++ttm_glob_use_count > 1)
@@ -90,8 +89,6 @@ static int ttm_global_init(void)
goto out;
}
- for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
- INIT_LIST_HEAD(&glob->swap_lru[i]);
INIT_LIST_HEAD(&glob->device_list);
atomic_set(&glob->bo_count, 0);
@@ -109,27 +106,60 @@ static int ttm_global_init(void)
int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_global *glob = &ttm_glob;
+ struct ttm_device *bdev;
+ int ret = -EBUSY;
+
+ mutex_lock(&ttm_global_mutex);
+ list_for_each_entry(bdev, &glob->device_list, device_list) {
+ ret = ttm_device_swapout(bdev, ctx, gfp_flags);
+ if (ret > 0) {
+ list_move_tail(&bdev->device_list, &
[PATCH 3/3] drm/ttm: switch to per device LRU lock
Instead of having a global lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
include/drm/ttm/ttm_bo_driver.h| 4 +--
include/drm/ttm/ttm_device.h | 4 +--
8 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9d19078246c8..ae18c0e32347 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
*adev,
struct amdgpu_vm_bo_base *bo_base;
if (vm->bulk_moveable) {
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&adev->mman.bdev.lru_lock);
ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&adev->mman.bdev.lru_lock);
return;
}
memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&adev->mman.bdev.lru_lock);
list_for_each_entry(bo_base, &vm->idle, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
@@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
&bo->shadow->tbo.mem,
&vm->lru_bulk_move);
}
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&adev->mman.bdev.lru_lock);
vm->bulk_moveable = true;
}
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index f5845c96d414..b19f2f00b215 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(&release->base);
- spin_lock(&ttm_glob.lru_lock);
-
list_for_each_entry(entry, &release->bos, head) {
bo = entry->bo;
dma_resv_add_shared_fence(bo->base.resv, &release->base);
- ttm_bo_move_to_lru_tail(bo, &bo->mem, NULL);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
dma_resv_unlock(bo->base.resv);
}
- spin_unlock(&ttm_glob.lru_lock);
ww_acquire_fini(&release->ticket);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3673157527ff..2d2ac532987e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -243,9 +243,9 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
* reference it any more. The only tricky case is the trylock on
* the resv object while holding the lru_lock.
*/
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&bo->bdev->lru_lock);
bo->base.resv = &bo->base._resv;
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
}
return r;
@@ -304,7 +304,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
30 * HZ);
@@ -314,7 +314,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
else if (lret == 0)
return -EBUSY;
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&bo->bdev->lru_lock);
if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
/*
* We raced, and lost, someone else holds the
reservation now,
@@ -324,7 +324,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
* delayed destruction would succeed, so just return
success
* here.
*/
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
return 0;
}
ret = 0;
@@ -333,13 +333,13 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo,
if (ret || unlikely(list_empty(&bo->ddestroy))) {
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(&ttm_glob.lru_lock);
Re: [PATCH 1/3] dma-buf: add dma_fence_array_for_each (v2)
On Thu, Mar 18, 2021 at 10:38:11AM +0100, Christian König wrote:
> Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
> > 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.
>
> Is there any reason you send this patch alone out once more?
>
> I don't see any changes compared to the last version.
Last patch has changed. Also I think mail delivery is a bit wobbly right
now.
-Daniel
>
> Christian.
>
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > 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 d3fbd950be944..2ac1afc697d0f 100644
> > --- a/drivers/dma-buf/dma-fence-array.c
> > +++ b/drivers/dma-buf/dma-fence-array.c
> > @@ -201,3 +201,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 303dd712220fd..588ac8089dd61 100644
> > --- a/include/linux/dma-fence-array.h
> > +++ b/include/linux/dma-fence-array.h
> > @@ -74,6 +74,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,
> > @@ -81,4 +94,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 */
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote: > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > happened here. > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > a previous one. > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > window even during the current merge window, but need to make sure they > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > show up, and then get pulled again. > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to > > > > some > > > > confusion here. But your patches should all be in linux-next again (they > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > Sorry for the confusion here. > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > Thanks for the explanation Daniel > > > > After rebasing today, all of my GPU patches have remained. Would > > someone be kind enough to check that everything is still in order > > please? > > It's still broken somehow. I've kiced Maxime and Maarten again, > they're also on this thread. You're patches have made it into drm-next meanwhile, so they should show up in linux-next through that tree at least. Except if that one also has some trouble. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Few typo fixes
On Thu, Mar 18, 2021 at 04:07:39PM +0530, Bhaskar Chowdhury wrote: > > s/instatiated/instantiated/ > s/unreference/unreferenced/ > > Signed-off-by: Bhaskar Chowdhury Queued for 5.13 in drm-misc-next, thanks for your patch. -Daniel > --- > drivers/gpu/drm/drm_property.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c > index 6ee04803c362..27c824a6eb60 100644 > --- a/drivers/gpu/drm/drm_property.c > +++ b/drivers/gpu/drm/drm_property.c > @@ -43,7 +43,7 @@ > * property types and ranges. > * > * Properties don't store the current value directly, but need to be > - * instatiated by attaching them to a &drm_mode_object with > + * instantiated by attaching them to a &drm_mode_object with > * drm_object_attach_property(). > * > * Property values are only 64bit. To support bigger piles of data (like > gamma > @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); > * @id: id of the blob property > * > * If successful, this takes an additional reference to the blob property. > - * callers need to make sure to eventually unreference the returned property > + * callers need to make sure to eventually unreferenced the returned property > * again, using drm_property_blob_put(). > * > * Return: > -- > 2.26.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Disable pread/pwrite ioctl's for future platforms (v3)
On Wed, Mar 17, 2021 at 06:40:12PM -0500, Jason Ekstrand wrote:
> From: Ashutosh Dixit
>
> The rationale for this change is roughly as follows:
>
> 1. The functionality can be done entirely in userspace with a
> combination of mmap + memcpy
>
> 2. The only reason anyone in userspace is still using it is because
> someone implemented bo_subdata that way in libdrm ages ago and
> they're all too lazy to write the 5 lines of code to do a map.
>
> 3. This falls cleanly into the category of things which will only get
> more painful with local memory support.
>
> These ioctls aren't used much anymore by "real" userspace drivers.
> Vulkan has never used them and neither has the iris GL driver. The old
> i965 GL driver does use PWRITE for glBufferSubData but it only supports
> up through Gen11; Gen12 was never enabled in i965. The compute driver
> has never used PREAD/PWRITE. The only remaining user is the media
> driver which uses it exactly twice and they're easily removed [1] so
> expecting them to drop it going forward is reasonable.
>
> IGT changes which handle this kernel change have also been submitted [2].
>
> [1] https://github.com/intel/media-driver/pull/1160
> [2] https://patchwork.freedesktop.org/series/81384/
>
> v2 (Jason Ekstrand):
> - Improved commit message with the status of all usermode drivers
> - A more future-proof platform check
>
> v3 (Jason Ekstrand):
> - Drop the HAS_LMEM checks as they're already covered by the version
>checks
>
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Jason Ekstrand
> Reviewed-by: Jason Ekstrand
Merged the first three here. For the scheduler/context stuff I think we
should go back to normal due process with kernel patch + igt patches
tested together, then land igt first, then kernel, just to avoid hiccups
in CI.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b2e3b5cfccb4a..80915467e0d84 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -374,10 +374,17 @@ int
> i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_pread *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
>
> + /* PREAD is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if (args->size == 0)
> return 0;
>
> @@ -675,10 +682,17 @@ int
> i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_pwrite *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
>
> + /* PWRITE is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if (args->size == 0)
> return 0;
>
> --
> 2.29.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212327] New: i915 / Kernel Mode Setting - Distorts Screen
https://bugzilla.kernel.org/show_bug.cgi?id=212327 Bug ID: 212327 Summary: i915 / Kernel Mode Setting - Distorts Screen Product: Drivers Version: 2.5 Kernel Version: 5.12.0-rc3 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ros...@rkarim.xyz Regression: No Created attachment 295913 --> https://bugzilla.kernel.org/attachment.cgi?id=295913&action=edit dmesg output Hello, I have this problem seemingly with the i915 driver. When kernel mode setting is active, only half of my screen attempts to display all of the pixels, with the other half turning all various shades of colours, but not working. Will attach an image below. Not totally sure what information to provide for this, so I've provided my dmesg output. Thanks, RK -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212327] i915 / Kernel Mode Setting - Distorts Screen
https://bugzilla.kernel.org/show_bug.cgi?id=212327 --- Comment #1 from RK (ros...@rkarim.xyz) --- Created attachment 295915 --> https://bugzilla.kernel.org/attachment.cgi?id=295915&action=edit image of screen issue -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Few typo fixes
On Thu, 2021-03-18 at 16:07 +0530, Bhaskar Chowdhury wrote: > s/instatiated/instantiated/ > s/unreference/unreferenced/ []> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c [] > @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); > * @id: id of the blob property > * > * If successful, this takes an additional reference to the blob property. > - * callers need to make sure to eventually unreference the returned property > + * callers need to make sure to eventually unreferenced the returned property I think this is worse. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212137] kernel NULL pointer dereference, black screen when using two graphics cards
https://bugzilla.kernel.org/show_bug.cgi?id=212137 Dennis Foster (m...@dennisfoster.us) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #4 from Dennis Foster (m...@dennisfoster.us) --- I can confirm now that the issue is fixed in recent 5.11.7 kernel. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -297,6 +297,8 @@ struct ttm_device {
struct delayed_work wq;
};
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags);
There is a typo here, long -> int.
Thanks,
Nirmoy
+
static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212281] AMDGPU warning stack trace in dmesg (dcn20_validate_bandwidth_fp)
https://bugzilla.kernel.org/show_bug.cgi?id=212281 --- Comment #2 from Tomas Sandven (tomas@sandven.email) --- Created attachment 295919 --> https://bugzilla.kernel.org/attachment.cgi?id=295919&action=edit Full dmesg output -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212281] AMDGPU warning stack trace in dmesg (dcn20_validate_bandwidth_fp)
https://bugzilla.kernel.org/show_bug.cgi?id=212281 --- Comment #3 from Tomas Sandven (tomas@sandven.email) --- (In reply to Alex Deucher from comment #1) > Please attach your full dmesg output and xorg log (if using X). I added full dmesg output. I have rebooted since the first error, so the two stack traces you see in the dmesg output now are unrelated to the issue I had the first time, but the look the same. I haven't noticed any negative consequences of the errors. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.12-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-m021-20210318 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/a454d56ea061b53d24a62a700743e4508dd6c9b1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
git checkout a454d56ea061b53d24a62a700743e4508dd6c9b1
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/ttm/ttm_device.c:109:5: error: conflicting types for
>> 'ttm_global_swapout'
109 | int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags)
| ^~
In file included from drivers/gpu/drm/ttm/ttm_device.c:32:
include/drm/ttm/ttm_device.h:300:6: note: previous declaration of
'ttm_global_swapout' was here
300 | long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
| ^~
In file included from include/linux/linkage.h:7,
from include/linux/kernel.h:7,
from include/asm-generic/bug.h:20,
from arch/x86/include/asm/bug.h:93,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from drivers/gpu/drm/ttm/ttm_device.c:30:
drivers/gpu/drm/ttm/ttm_device.c:132:15: error: conflicting types for
'ttm_global_swapout'
132 | EXPORT_SYMBOL(ttm_global_swapout);
| ^~
include/linux/export.h:98:21: note: in definition of macro '___EXPORT_SYMBOL'
98 | extern typeof(sym) sym; \
| ^~~
include/linux/export.h:155:34: note: in expansion of macro '__EXPORT_SYMBOL'
155 | #define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, "")
| ^~~
include/linux/export.h:158:29: note: in expansion of macro '_EXPORT_SYMBOL'
158 | #define EXPORT_SYMBOL(sym) _EXPORT_SYMBOL(sym, "")
| ^~
drivers/gpu/drm/ttm/ttm_device.c:132:1: note: in expansion of macro
'EXPORT_SYMBOL'
132 | EXPORT_SYMBOL(ttm_global_swapout);
| ^
In file included from drivers/gpu/drm/ttm/ttm_device.c:32:
include/drm/ttm/ttm_device.h:300:6: note: previous declaration of
'ttm_global_swapout' was here
300 | long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
| ^~
vim +/ttm_global_swapout +109 drivers/gpu/drm/ttm/ttm_device.c
104
105 /**
106 * A buffer object shrink method that tries to swap out the first
107 * buffer object on the global::swap_lru list.
108 */
> 109 int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
110 {
111 struct ttm_global *glob = &ttm_glob;
112 struct ttm_buffer_object *bo;
113 unsigned i;
114 int ret;
115
116 spin_lock(&glob->lru_lock);
117 for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
118 list_for_each_entry(bo, &glob->swap_lru[i], swap) {
119 uint32_t num_pages = bo->ttm->num_pages;
120
121 ret = ttm_bo_swapout(bo, ctx, gfp_flags);
122 /* ttm_bo_swapout has dropped the lru_lock */
123 if (!ret)
124 return num_pages;
125 if (ret != -EBUSY)
126 return ret;
127 }
128 }
129 spin_unlock(&glob->lru_lock);
130 return 0;
131 }
132 EXPORT_SYMBOL(ttm_global_swapout);
133
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuil
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Am 18.03.21 um 15:43 schrieb Nirmoy:
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -297,6 +297,8 @@ struct ttm_device {
struct delayed_work wq;
};
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
There is a typo here, long -> int.
Ah, yes. I missed to add the change to the header file.
Thanks for pointing that out,
Christian.
Thanks,
Nirmoy
+
static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-fixes
Op 18-03-2021 om 13:31 schreef Daniel Vetter: > On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst > wrote: >> drm-misc-fixes-2021-03-18: >> drm-misc-fixes for v5.12-rc4: >> - Make ttm_bo_unpin() not wraparound on too many unpins. >> - Fix coccicheck warning in omap. > Still missing the 2 patches from drm-misc-next-fixes, and those being > left out also means drm-misc-next isn't pushed to for-linux-next > branch, which is causing a ton of confusion itself. > -Daniel We had a discussion on irc, those patches were part of the previous pull. I've reset drm-misc-next-fixes to v5.12-rc1-dontuse, to unplug drm-misc-next. >> The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: >> >> drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 >> >> for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: >> >> drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 >> 13:59:23 +0200) >> >> >> drm-misc-fixes for v5.12-rc4: >> - Make ttm_bo_unpin() not wraparound on too many unpins. >> - Fix coccicheck warning in omap. >> >> >> Christian König (1): >> drm/ttm: make ttm_bo_unpin more defensive >> >> Junlin Yang (1): >> drm/omap: dsi: fix unsigned expression compared with zero >> >> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- >> include/drm/ttm/ttm_bo_api.h | 6 -- >> 2 files changed, 8 insertions(+), 5 deletions(-) > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp_mst: Enhance DP MST topology logging
[why]
MST topology print was missing fec logging and pdt printed
as an int wasn't clear. vcpi and payload info were also logged as an
arbitrary series of ints which require the user to know the ordering
of the prints, making the logs difficult to use.
[how]
-add fec logging
-add pdt parsing into strings
-format vcpi and payload info into tables with headings
-clean up topology prints
Signed-off-by: Eryk Brol
---
drivers/gpu/drm/drm_dp_mst_topology.c | 67 ---
1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 932c4641ec3e..3afeaa59cbaa 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4720,6 +4720,24 @@ static void drm_dp_mst_kick_tx(struct
drm_dp_mst_topology_mgr *mgr)
queue_work(system_long_wq, &mgr->tx_work);
}
+static char *pdt_to_string(u8 pdt)
+{
+ switch (pdt) {
+ case DP_PEER_DEVICE_NONE:
+ return "NONE";
+ case DP_PEER_DEVICE_SOURCE_OR_SST:
+ return "SOURCE OR SST";
+ case DP_PEER_DEVICE_MST_BRANCHING:
+ return "MST BRANCHING";
+ case DP_PEER_DEVICE_SST_SINK:
+ return "SST SINK";
+ case DP_PEER_DEVICE_DP_LEGACY_CONV:
+ return "DP LEGACY CONV";
+ default:
+ return "ERR";
+ }
+}
+
static void drm_dp_mst_dump_mstb(struct seq_file *m,
struct drm_dp_mst_branch *mstb)
{
@@ -4732,9 +4750,20 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
prefix[i] = '\t';
prefix[i] = '\0';
- seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
+ seq_printf(m, "%smstb - [%p]: num_ports: %d\n", prefix, mstb,
mstb->num_ports);
list_for_each_entry(port, &mstb->ports, next) {
- seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps:
%d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input,
port->pdt, port->ddps, port->ldps, port->num_sdp_streams,
port->num_sdp_stream_sinks, port, port->connector);
+ seq_printf(m, "%sport %d - [%p] (%s - %s): ddps: %d, ldps: %d,
sdp: %d/%d, fec: %s, conn: %p\n",
+ prefix,
+ port->port_num,
+ port,
+ port->input ? "input" : "output",
+ pdt_to_string(port->pdt),
+ port->ddps,
+ port->ldps,
+ port->num_sdp_streams,
+ port->num_sdp_stream_sinks,
+ port->fec_capable ? "true" : "false",
+ port->connector);
if (port->mstb)
drm_dp_mst_dump_mstb(m, port->mstb);
}
@@ -4787,33 +4816,39 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
mutex_unlock(&mgr->lock);
mutex_lock(&mgr->payload_lock);
- seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
- mgr->max_payloads);
+ seq_printf(m, "\n *** VCPI Info ***\npayload_mask: %lx, vcpi_mask: %lx,
max_payloads: %d\n",
+ mgr->payload_mask,
+ mgr->vcpi_mask,
+ mgr->max_payloads);
+ seq_printf(m, "\n| idx | port # | vcp_id | # slots | sink
name |\n");
for (i = 0; i < mgr->max_payloads; i++) {
if (mgr->proposed_vcpis[i]) {
char name[14];
port = container_of(mgr->proposed_vcpis[i], struct
drm_dp_mst_port, vcpi);
fetch_monitor_name(mgr, port, name, sizeof(name));
- seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
- port->port_num, port->vcpi.vcpi,
- port->vcpi.num_slots,
- (*name != 0) ? name : "Unknown");
+ seq_printf(m, "%10d%10d%10d%10d%20s\n",
+ i,
+ port->port_num,
+ port->vcpi.vcpi,
+ port->vcpi.num_slots,
+ (*name != 0) ? name : "Unknown");
} else
- seq_printf(m, "vcpi %d:unused\n", i);
+ seq_printf(m, "%6d - Unused\n", i);
}
+ seq_printf(m, "\n *** Payload Info ***\n");
+ seq_printf(m, "| idx | state | start slot | # slots |\n");
for (i = 0; i < mgr->max_payloads; i++) {
- seq_printf(m, "payload %d: %d, %d, %d\n",
- i,
- mgr->payloads[i].payload_state,
- mgr->payl
[PATCH 2/3] drm/vc4: plane: Remove redundant assignment
The vc4_plane_atomic_async_update function assigns twice in a row the src_h field in the drm_plane_state structure to the same value. Remove the second one. Reviewed-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_plane.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 3fdc32244b59..0ad1862c5ad8 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -1135,7 +1135,6 @@ static void vc4_plane_atomic_async_update(struct drm_plane *plane, plane->state->src_y = new_plane_state->src_y; plane->state->src_w = new_plane_state->src_w; plane->state->src_h = new_plane_state->src_h; - plane->state->src_h = new_plane_state->src_h; plane->state->alpha = new_plane_state->alpha; plane->state->pixel_blend_mode = new_plane_state->pixel_blend_mode; plane->state->rotation = new_plane_state->rotation; -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/vc4: crtc: Reduce PV fifo threshold on hvs4
From: Dom Cobley
Experimentally have found PV on hvs4 reports fifo full
error with expected settings and does not with one less
This appears as:
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:82:crtc-3] flip_done
timed out
with bit 10 of PV_STAT set "HVS driving pixels when the PV FIFO is full"
Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 269390bc586e..76657dcdf9b0 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -210,6 +210,7 @@ static u32 vc4_get_fifo_full_level(struct vc4_crtc
*vc4_crtc, u32 format)
{
const struct vc4_crtc_data *crtc_data =
vc4_crtc_to_vc4_crtc_data(vc4_crtc);
const struct vc4_pv_data *pv_data = vc4_crtc_to_vc4_pv_data(vc4_crtc);
+ struct vc4_dev *vc4 = to_vc4_dev(vc4_crtc->base.dev);
u32 fifo_len_bytes = pv_data->fifo_depth;
/*
@@ -238,6 +239,22 @@ static u32 vc4_get_fifo_full_level(struct vc4_crtc
*vc4_crtc, u32 format)
if (crtc_data->hvs_output == 5)
return 32;
+ /*
+* It looks like in some situations, we will overflow
+* the PixelValve FIFO (with the bit 10 of PV stat being
+* set) and stall the HVS / PV, eventually resulting in
+* a page flip timeout.
+*
+* Displaying the video overlay during a playback with
+* Kodi on an RPi3 seems to be a great solution with a
+* failure rate around 50%.
+*
+* Removing 1 from the FIFO full level however
+* seems to completely remove that issue.
+*/
+ if (!vc4->hvs->hvs5)
+ return fifo_len_bytes - 3 * HVS_FIFO_LATENCY_PIX - 1;
+
return fifo_len_bytes - 3 * HVS_FIFO_LATENCY_PIX;
}
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/vc4: plane: Fix typo in scaler width and height
The vc4_plane_mode_set function still accesses the scaler target width
and height using the older register layout while it was updated with the
BCM2711, and the proper defines got introduced when we started to
support it.
Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index eb37d7f8a118..3fdc32244b59 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -912,9 +912,9 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
if (!vc4_state->is_unity) {
vc4_dlist_write(vc4_state,
VC4_SET_FIELD(vc4_state->crtc_w,
- SCALER_POS1_SCL_WIDTH) |
+ SCALER5_POS1_SCL_WIDTH) |
VC4_SET_FIELD(vc4_state->crtc_h,
- SCALER_POS1_SCL_HEIGHT));
+ SCALER5_POS1_SCL_HEIGHT));
}
/* Position Word 2: Source Image Size */
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
On 2021-03-18 6:41 a.m., Zhang, Jack (Jian) wrote:
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey
Let me summarize the background of this patch:
In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,
It will submit first jobs of each ring and do guilty job re-check.
At that point, We had to make sure each job is in the mirror list(or
re-inserted back already).
But we found the current code never re-insert the job to mirror list
in the 2^nd , 3^rd job_timeout thread(Bailing TDR thread).
This not only will cause memleak of the bailing jobs. What’s more
important, the 1^st tdr thread can never iterate the bailing job and
set its guilty status to a correct status.
Therefore, we had to re-insert the job(or even not delete node) for
bailing job.
For the above V3 patch, the racing condition in my mind is:
we cannot make sure all bailing jobs are finished before we do
amdgpu_device_recheck_guilty_jobs.
Yes,that race i missed - so you say that for 2nd, baling thread who
extracted the job, even if he reinsert it right away back after driver
callback return DRM_GPU_SCHED_STAT_BAILING, there is small time slot
where the job is not in mirror list and so the 1st TDR might miss it and
not find that 2nd job is the actual guilty job, right ? But, still this
job will get back into mirror list, and since it's really the bad job,
it will never signal completion and so on the next timeout cycle it will
be caught (of course there is a starvation scenario here if more TDRs
kick in and it bails out again but this is really unlikely).
Based on this insight, I think we have two options to solve this issue:
1. Skip delete node in tdr thread2, thread3, 4 … (using mutex or
atomic variable)
2. Re-insert back bailing job, and meanwhile use semaphore in each
tdr thread to keep the sequence as expected and ensure each job is
in the mirror list when do resubmit step.
For Option1, logic is simpler and we need only one global atomic variable:
What do you think about this plan?
Option1 should look like the following logic:
+static atomic_t in_reset; //a global atomic var for synchronization
static void drm_sched_process_job(struct dma_fence *f, struct
dma_fence_cb *cb);
/**
@@ -295,6 +296,12 @@ static void drm_sched_job_timedout(struct
work_struct *work)
* drm_sched_cleanup_jobs. It will be reinserted back
after sched->thread
* is parked at which point it's safe.
*/
+ if (atomic_cmpxchg(&in_reset, 0, 1) != 0) { //skip
delete node if it’s thead1,2,3,….
+ spin_unlock(&sched->job_list_lock);
+ drm_sched_start_timeout(sched);
+ return;
+ }
+
list_del_init(&job->node);
spin_unlock(&sched->job_list_lock);
@@ -320,6 +327,7 @@ static void drm_sched_job_timedout(struct
work_struct *work)
spin_lock(&sched->job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
+ atomic_set(&in_reset, 0); //reset in_reset when the first
thread finished tdr
}
Technically looks like it should work as you don't access the job
pointer any longer and so no risk that if signaled it will be freed by
drm_sched_get_cleanup_job but,you can't just use one global variable an
by this bailing from TDR when different drivers run their TDR threads in
parallel, and even for amdgpu, if devices in different XGMI hives or 2
independent devices in non XGMI setup. There should be defined some kind
of GPU reset group structure on drm_scheduler level for which this
variable would be used.
P.S I wonder why we can't just ref-count the job so that even if
drm_sched_get_cleanup_job would delete it before we had a chance to stop
the scheduler thread, we wouldn't crash. This would avoid all the dance
with deletion and reinsertion.
Andrey
Thanks,
Jack
*From:* amd-gfx *On Behalf Of
*Zhang, Jack (Jian)
*Sent:* Wednesday, March 17, 2021 11:11 PM
*To:* Christian König ;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
Koenig, Christian ; Liu, Monk
; Deng, Emily ; Rob Herring
; Tomeu Vizoso ; Steven
Price ; Grodzovsky, Andrey
*Subject:* Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid
memleak
[AMD Official Use Only - Internal Distribution Only]
[AMD Official Use Only - Internal Distribution Only]
Hi，Andrey，
Good catch，I will expore this corner case and give feedback soon～
Best，
Jack
*From:*Grodzovsky, Andrey >
*Sent:* Wednesday, March 17, 2021 10:50:59 PM
*To:* Christian König >; Zhang, Jack (Jian)
mailto:jack.zha...@amd.com>>;
dri-devel@lists.freedesktop.org
>;
amd-...@lists.freedesktop.org
[Bug 212333] New: Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 Bug ID: 212333 Summary: Bisected: 5.11.7 breaks amdgpu resume from S3 Product: Drivers Version: 2.5 Kernel Version: 5.11.7 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: timo.valto...@gmail.com Regression: No Created attachment 295921 --> https://bugzilla.kernel.org/attachment.cgi?id=295921&action=edit Working kernel config with CONFIG_AMD_PMC is not set After upgrading kernel 5.11.6 => 5.11.7 my Asus Vivobook S14 (Model M433I, Ryzen 5 4500U), resume from S3 suspend is broken. Asus has disabled S3 completely, it is not shown in BIOS/UEFI at all. I have modified DSDT table which works fine providing working S3. Now, after upgrade, suspend seems to happen just fine but resume gives me scrambled screen for few seconds, then screen goes completely black and mouse cursor shows up and is fully alive.I have to do a hard reboot to get away. Bisecting led to this: # first bad commit: [084b4f3304f923e39e64216a818a8bbf398dd896] drm/amdgpu: fix S0ix handling when the CONFIG_AMD_PMC=m When I change "CONFIG_AMD_PMC is not set" all is working again. CONFIG_AMD_PMC=y also breaks resume. All of this applies also to 5.12-rc3 which I tested too. Also, removing modified DSDT and using S2idle instead of deep, is broken too. It has never worked on this laptop. Now s2idle suspends, but resume scrambles screen for few seconds, then it works fine on first round. Suspending second time will end up on black screen on resume and I have to hard reboot. OS is Kubuntu 20.10 and firmware is the latest (linux-firmware package v1.195) taken from next release. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 --- Comment #1 from Timo Valtoaho (timo.valto...@gmail.com) --- Created attachment 295923 --> https://bugzilla.kernel.org/attachment.cgi?id=295923&action=edit git bisect log -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 --- Comment #2 from Timo Valtoaho (timo.valto...@gmail.com) --- Created attachment 295927 --> https://bugzilla.kernel.org/attachment.cgi?id=295927&action=edit lspci -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- See this page for more info on getting S0ix working: https://gitlab.freedesktop.org/drm/amd/-/issues/1230 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.
Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
/* Use highest possible value of Pn for more granularity of brightness
* adjustment while satifying the conditions below.
* ...
* - FxP is within 25% of desired value.
* Note: 25% is arbitrary value and may need some tweak.
*/
So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.
Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight")
Cc: Jani Nikula
Cc: Rodrigo Vivi
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 651884390137..4f8337c7fd2e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
break;
case INTEL_BACKLIGHT_DISPLAY_DDI:
try_intel_interface = true;
- try_vesa_interface = true;
break;
default:
return -ENODEV;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/6] Default request/fence expiry + watchdog
From: Tvrtko Ursulin "Watchdog" aka "restoring hangcheck" aka default request/fence expiry - second post of a somewhat controversial feature, now upgraded to patch status. I quote the "watchdog" becuase in classical sense watchdog would allow userspace to ping it and so remain alive. I quote "restoring hangcheck" because this series, contrary to the old hangcheck, is not looking at whether the workload is making any progress from the kernel side either. (Although disclaimer my memory may be leaky - Daniel suspects old hangcheck had some stricter, more indiscriminatory, angles to it. But apart from being prone to both false negatives and false positives I can't remember that myself.) Short version - ask is to fail any user submissions after a set time period. In this RFC that time is twelve seconds. Time counts from the moment user submission is "runnable" (implicit and explicit dependencies have been cleared) and keeps counting regardless of the GPU contetion caused by other users of the system. So semantics are really a bit weak, but again, I understand this is really really wanted by the DRM core even if I am not convinced it is a good idea. There are some dangers with doing this - text borrowed from a patch in the series: This can have an effect that workloads which used to work fine will suddenly start failing. Even workloads comprised of short batches but in long dependency chains can be terminated. And becuase of lack of agreement on usefulness and safety of fence error propagation this partial execution can be invisible to userspace even if it is "listening" to returned fence status. Another interaction is with hangcheck where care needs to be taken timeout is not set lower or close to three times the heartbeat interval. Otherwise a hang in any application can cause complete termination of all submissions from unrelated clients. Any users modifying the per engine heartbeat intervals therefore need to be aware of this potential denial of service to avoid inadvertently enabling it. Given all this I am personally not convinced the scheme is a good idea. Intuitively it feels object importers would be better positioned to enforce the time they are willing to wait for something to complete. v2: * Dropped context param. * Improved commit messages and Kconfig text. v3: * Log timeouts. * Bump timeout to 20s to see if it helps Tigerlake. * Fix sentinel assert. Test-with: 20210318162400.2065097-1-tvrtko.ursu...@linux.intel.com Cc: Daniel Vetter https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/i915: Individual request cancellation
From: Chris Wilson
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully considering no timeline lock and RCU.
* Fixed selftests.
v3 (Tvrtko):
* Remove error propagation to waiters for now.
Signed-off-by: Chris Wilson
Signed-off-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 9 +-
drivers/gpu/drm/i915/i915_request.c | 52 -
drivers/gpu/drm/i915/i915_request.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
5 files changed, 261 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..e2fb3ae2aaf3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
mutex_unlock(&ce->timeline->mutex);
}
+ intel_engine_flush_scheduler(engine);
intel_engine_pm_put(engine);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 85ff5fe861b4..4c2acb5a6c0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
ce->lrc.lrca = lrc_update_regs(ce, engine, head);
}
+static bool bad_request(const struct i915_request *rq)
+{
+ return rq->fence.error && i915_request_started(rq);
+}
+
static struct intel_engine_cs *
__execlists_schedule_in(struct i915_request *rq)
{
@@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
!intel_engine_has_heartbeat(engine)))
intel_context_set_banned(ce);
- if (unlikely(intel_context_is_banned(ce)))
+ if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
reset_active(rq, engine);
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct
intel_engine_cs *engine,
return 0;
/* Force a fast reset for terminated contexts (ignoring sysfs!) */
- if (unlikely(intel_context_is_banned(rq->context)))
+ if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
return 1;
return READ_ONCE(engine->props.preempt_timeout_ms);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a6..b4511ac05e9a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -33,7 +33,10 @@
#include "gem/i915_gem_context.h"
#include "gt/intel_breadcrumbs.h"
#include "gt/intel_context.h"
+#include "gt/intel_engine.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_gpu_commands.h"
+#include "gt/intel_reset.h"
#include "gt/intel_ring.h"
#include "gt/intel_rps.h"
@@ -429,20 +432,22 @@ void __i915_request_skip(struct i915_request *rq)
rq->infix = rq->postfix;
}
-void i915_request_set_error_once(struct i915_request *rq, int error)
+bool i915_request_set_error_once(struct i915_request *rq, int error)
{
int old;
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
if (i915_request_signaled(rq))
- return;
+ return false;
old = READ_ONCE(rq->fence.error);
do {
if (fatal_error(old))
- return;
+ return false;
} while (!try_cmpxchg(&rq->fence.error, &old, error));
+
+ return true;
}
struct i915_request *i915_request_mark_eio(struct i915_request *rq)
@@ -609,6 +614,47 @@ void i915_request_unsubmit(struct i915_request *request)
spin_unlock_irqrestore(&se->lock, flags);
}
+static struct intel_engine_cs *active_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(&locked->sched.lock);
+ while (unlikely(locked != (engine = READ_ONCE(rq->engine {
+ spin_unlock(&locked->sched.lock);
+ locked = engine;
+ spin_lock(&locked->sched.lock);
+ }
+
+ engine = NULL;
+ if (i915_request_is_active(rq) && !__i915_request_is_complete(rq))
+ engine = locked;
+
+ spin_unlock_irq(&locked->sched.lock);
+
+ return engine;
+}
+
+static void __cancel_request(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = active_engine(rq);
+
+ if (engine && intel_engine_pulse(engine))
+ intel_gt_handle_error(engine->gt, engine->mask, 0,
[PATCH 2/6] drm/i915: Restrict sentinel requests further
From: Tvrtko Ursulin Disallow sentinel requests follow previous sentinels to make request cancellation work better when faced with a chain of requests which have all been marked as in error. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4c2acb5a6c0a..4b870eca9693 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev, if (__i915_request_is_complete(next)) return true; - if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & + if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) & (BIT(I915_FENCE_FLAG_NOPREEMPT) | BIT(I915_FENCE_FLAG_SENTINEL return false; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/i915: Handle async cancellation in sentinel assert
From: Tvrtko Ursulin With the watchdog cancelling requests asynchronously to preempt-to-busy we need to relax one assert making it apply only to requests not in error. v2: * Check against the correct request! Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4b870eca9693..bf557290173a 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -815,6 +815,13 @@ assert_pending_valid(const struct intel_engine_execlists *execlists, spin_unlock_irqrestore(&rq->lock, flags); if (!ok) return false; + + /* +* Due async nature of preempt-to-busy and request cancellation +* we need to skip further asserts for cancelled requests. +*/ + if (READ_ONCE(rq->fence.error)) + break; } return ce; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/i915: Request watchdog infrastructure
From: Tvrtko Ursulin
Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activeted due yet missing ability to actually
configure the timer.
Outline of the basic operation:
A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.
If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.
Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().
Associated timeout value is stored in rq->context.watchdog.timeout_us.
v2:
* Log expiration.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 ++
.../drm/i915/gt/intel_execlists_submission.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 26 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +++
drivers/gpu/drm/i915/i915_request.c | 56 +++
drivers/gpu/drm/i915/i915_request.h | 8 +++
8 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0ea18c9e2aca..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,10 @@ struct intel_context {
#define CONTEXT_FORCE_SINGLE_SUBMISSION7
#define CONTEXT_NOPREEMPT 8
+ struct {
+ u64 timeout_us;
+ } watchdog;
+
u32 *lrc_reg_state;
union {
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index f7bd3fccfee8..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -6,6 +6,7 @@
#ifndef __INTEL_EXECLISTS_SUBMISSION_H__
#define __INTEL_EXECLISTS_SUBMISSION_H__
+#include
#include
struct drm_printer;
@@ -13,6 +14,7 @@ struct drm_printer;
struct i915_request;
struct intel_context;
struct intel_engine_cs;
+struct intel_gt;
enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..8d77dcbad059 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
+ init_llist_head(>->watchdog.list);
+ INIT_WORK(>->watchdog.work, intel_gt_watchdog_work);
+
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index a17bd8b3195f..7ec395cace69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -78,4 +78,6 @@ static inline bool intel_gt_is_wedged(const struct intel_gt
*gt)
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
+void intel_gt_watchdog_work(struct work_struct *work);
+
#endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 36ec97f79174..a7f7bd662fb7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -8,6 +8,7 @@
#include "i915_drv.h" /* for_each_engine() */
#include "i915_request.h"
#include "intel_engine_heartbeat.h"
+#include "intel_execlists_submission.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -242,4 +243,29 @@ void intel_gt_fini_requests(struct intel_gt *gt)
{
/* Wait until the work is marked as finished before unloading! */
cancel_delayed_work_sync(>->requests.retire_work);
+
+ flush_work(>->watchdog.work);
+}
+
+void intel_gt_watchdog_work(struct work_struct *work)
+{
+ struct intel_gt *gt =
+ container_of(work, typeof(*gt), watchdog.work);
+ struct i915_request *rq, *rn;
+ struct llist_node *first;
+
+ first = llist_del_all(>->watchdog.list);
+ if (!first)
+ return;
+
+ llist_for_each_entry_safe(rq, rn, first, watchdog.link) {
+ if (!i915_request_completed(rq)) {
+ drm_notice(>->i915->drm,
+ "Fence expiration time out %llx:%llu!\n",
+ rq->fence.context,
+
[PATCH 5/6] drm/i915: Fail too long user submissions by default
From: Tvrtko Ursulin
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 20s, and this timeout is applied to all users contexts using the
previously added watchdog facility.
Result of this is that any user submission will simply fail after this
timeout, either causing a reset (for non-preemptable), or incomplete
results.
This can have an effect that workloads which used to work fine will
suddenly start failing. Even workloads comprised of short batches but in
long dependency chains can be terminated.
And becuase of lack of agreement on usefulness and safety of fence error
propagation this partial execution can be invisible to userspace even if
it is "listening" to returned fence status.
Another interaction is with hangcheck where care needs to be taken timeout
is not set lower or close to three times the heartbeat interval. Otherwise
a hang in any application can cause complete termination of all
submissions from unrelated clients. Any users modifying the per engine
heartbeat intervals therefore need to be aware of this potential denial of
service to avoid inadvertently enabling it.
Given all this I am personally not convinced the scheme is a good idea.
Intuitively it feels object importers would be better positioned to
enforce the time they are willing to wait for something to complete.
v2:
* Improved commit message and Kconfig text.
* Pull in some helper code from patch which got dropped.
v3:
* Bump timeout to 20s to see if it helps Tigerlake.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig.profile | 14 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +-
4 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 35bbe2b80596..39328567c200 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,17 @@
+config DRM_I915_REQUEST_TIMEOUT
+ int "Default timeout for requests (ms)"
+ default 2 # milliseconds
+ help
+ Configures the default timeout after which any user submissions will
+ be forcefully terminated.
+
+ Beware setting this value lower, or close to heartbeat interval
+ rounded to whole seconds times three, in order to avoid allowing
+ misbehaving applications causing total rendering failure in unrelated
+ clients.
+
+ May be 0 to disable the timeout.
+
config DRM_I915_FENCE_TIMEOUT
int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"
default 1 # milliseconds
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e7..be71be21800b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -233,6 +233,8 @@ static void intel_context_set_gem(struct intel_context *ce,
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
+
+ intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
}
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -852,6 +854,40 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
}
+static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
+{
+ return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
+}
+
+static int
+__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
+{
+ int ret;
+
+ ret = context_apply_all(ctx, __apply_watchdog,
+ (void *)(uintptr_t)timeout_us);
+ if (!ret)
+ ctx->watchdog.timeout_us = timeout_us;
+
+ return ret;
+}
+
+static void __set_default_fence_expiry(struct i915_gem_context *ctx)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ int ret;
+
+ if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
+ return;
+
+ /* Default expiry for user fences. */
+ ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
+ if (ret)
+ drm_notice(&i915->drm,
+ "Failed to configure default fence expiry! (%d)",
+ ret);
+}
+
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
@@ -896,6 +932,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
intel_timeline_put(timeline);
}
+ __set_default_fence_expiry(ctx);
+
trace_i915_context_create(ctx);
return ctx;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context
[PATCH 6/6] drm/i915: Allow configuring default request expiry via modparam
From: Tvrtko Ursulin Module parameter is added (request_timeout_ms) to allow configuring the default request/fence expiry. Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Acked-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++-- drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/drm/i915/i915_params.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index be71be21800b..cf5b706a39b8 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -877,11 +877,12 @@ static void __set_default_fence_expiry(struct i915_gem_context *ctx) struct drm_i915_private *i915 = ctx->i915; int ret; - if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT)) + if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) || + !i915->params.request_timeout_ms) return; /* Default expiry for user fences. */ - ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000); + ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000); if (ret) drm_notice(&i915->drm, "Failed to configure default fence expiry! (%d)", diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 6939634e56ed..0320878d96b0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -197,6 +197,11 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400, "Fake LMEM start offset (default: 0)"); #endif +#if CONFIG_DRM_I915_REQUEST_TIMEOUT +i915_param_named_unsafe(request_timeout_ms, uint, 0600, + "Default request/fence/batch buffer expiration timeout."); +#endif + static __always_inline void _print_param(struct drm_printer *p, const char *name, const char *type, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 48f47e44e848..34ebb0662547 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -72,6 +72,7 @@ struct drm_printer; param(int, enable_dpcd_backlight, -1, 0600) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \ param(unsigned long, fake_lmem_start, 0, 0400) \ + param(unsigned int, request_timeout_ms, CONFIG_DRM_I915_REQUEST_TIMEOUT, 0600) \ /* leave bools at the end to not create holes */ \ param(bool, enable_hangcheck, true, 0600) \ param(bool, load_detect_test, false, 0600) \ -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Actually-NAK this. I just realized I've been misreading the bug and that this
doesn't actually seem to be fixed. Will resend once I figure out what's going on
On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> Looks like that there actually are another subset of laptops on the market
> that don't support the Intel HDR backlight interface, but do advertise
> support for the VESA DPCD backlight interface despite the fact it doesn't
> seem to work.
>
> Note though I'm not entirely clear on this - on one of the machines where
> this issue was observed, I also noticed that we appeared to be rejecting
> the VBT defined backlight frequency in
> intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
>
> /* Use highest possible value of Pn for more granularity of brightness
> * adjustment while satifying the conditions below.
> * ...
> * - FxP is within 25% of desired value.
> * Note: 25% is arbitrary value and may need some tweak.
> */
>
> So it's possible that this value might just need to be tweaked, but for now
> let's just disable the VESA backlight interface unless it's specified in
> the VBT just to be safe. We might be able to try enabling this again by
> default in the future.
>
> Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
> enable_dpcd_backlight")
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 651884390137..4f8337c7fd2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *connector)
> break;
> case INTEL_BACKLIGHT_DISPLAY_DDI:
> try_intel_interface = true;
> - try_vesa_interface = true;
> break;
> default:
> return -ENODEV;
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Few typo fixes
On 3/18/21 7:25 AM, Joe Perches wrote: > On Thu, 2021-03-18 at 16:07 +0530, Bhaskar Chowdhury wrote: >> s/instatiated/instantiated/ >> s/unreference/unreferenced/ > > []> diff --git a/drivers/gpu/drm/drm_property.c > b/drivers/gpu/drm/drm_property.c > [] >> @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); >> * @id: id of the blob property >> * >> * If successful, this takes an additional reference to the blob property. >> - * callers need to make sure to eventually unreference the returned property >> + * callers need to make sure to eventually unreferenced the returned >> property > > I think this is worse. Agreed -- not good. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a typo
On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
>
> s/traing/training/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> index c325d6f53a71..db18e4f6cf5f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> @@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
> *psp, uint32_t ops)
>
> if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
> /*
> - * Long traing will encroach certain mount of bottom VRAM,
> + * Long training will encroach certain mount of bottom VRAM,
amount
I think.
>* saving the content of this bottom VRAM to system memory
>* before training, and restoring it after training to avoid
>* VRAM corruption.
> --
> 2.26.2
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a typo
On Thu, Mar 18, 2021 at 2:08 PM Randy Dunlap wrote:
>
> On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
> >
> > s/traing/training/
> >
> > Signed-off-by: Bhaskar Chowdhury
> > ---
> > drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > index c325d6f53a71..db18e4f6cf5f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> > @@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
> > *psp, uint32_t ops)
> >
> > if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
> > /*
> > - * Long traing will encroach certain mount of bottom VRAM,
> > + * Long training will encroach certain mount of bottom VRAM,
>
>amount
> I think.
Yeah, I think it should read something like:
Long training will encroach a certain amount on the bottom of VRAM;
save the content from the bottom VRAM to system memory
before training, and restore it after training to avoid
VRAM corruption.
Alex
>
> >* saving the content of this bottom VRAM to system memory
> >* before training, and restoring it after training to avoid
> >* VRAM corruption.
> > --
> > 2.26.2
> >
>
>
> --
> ~Randy
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
linus/master v5.12-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a005-20210318 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
6db3ab2903f42712f44000afb5aa467efbd25f35)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/a454d56ea061b53d24a62a700743e4508dd6c9b1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-move-swapout-logic-around-v2/20210318-204848
git checkout a454d56ea061b53d24a62a700743e4508dd6c9b1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/ttm/ttm_device.c:109:5: error: conflicting types for
>> 'ttm_global_swapout'
int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
^
include/drm/ttm/ttm_device.h:300:6: note: previous declaration is here
long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags);
^
1 error generated.
vim +/ttm_global_swapout +109 drivers/gpu/drm/ttm/ttm_device.c
104
105 /**
106 * A buffer object shrink method that tries to swap out the first
107 * buffer object on the global::swap_lru list.
108 */
> 109 int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
110 {
111 struct ttm_global *glob = &ttm_glob;
112 struct ttm_buffer_object *bo;
113 unsigned i;
114 int ret;
115
116 spin_lock(&glob->lru_lock);
117 for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
118 list_for_each_entry(bo, &glob->swap_lru[i], swap) {
119 uint32_t num_pages = bo->ttm->num_pages;
120
121 ret = ttm_bo_swapout(bo, ctx, gfp_flags);
122 /* ttm_bo_swapout has dropped the lru_lock */
123 if (!ret)
124 return num_pages;
125 if (ret != -EBUSY)
126 return ret;
127 }
128 }
129 spin_unlock(&glob->lru_lock);
130 return 0;
131 }
132 EXPORT_SYMBOL(ttm_global_swapout);
133
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gt: A typo fix
On 3/18/21 3:19 AM, Bhaskar Chowdhury wrote: > > s/bariers/barriers/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c > b/drivers/gpu/drm/i915/gt/intel_timeline.c > index 037b0e3ccbed..25fc7f44fee0 100644 > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c > @@ -435,7 +435,7 @@ void intel_timeline_exit(struct intel_timeline *tl) > spin_unlock(&timelines->lock); > > /* > - * Since this timeline is idle, all bariers upon which we were waiting > + * Since this timeline is idle, all barriers upon which we were waiting >* must also be complete and so we can discard the last used barriers >* without loss of information. >*/ > -- > 2.26.2 > -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output
Hi! Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a): > Hi, > > Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on > the RaspberryPi4. > > I took the same approach than what dw-hdmi did already, turning a bunch of > functions found in that driver into helpers since they were fairly generic. > > However, it feels a bit clunky overall and there's a few rough edges that > should be addressed in a generic manner: > > - while the format negociation makes sense for a bridge, it feels a bit > over-engineered for a simple encoder where that setting could be a simple > switch (and possibly a property?) Property could work, but possible values should be then limited to cross section of HW and connected display capabilities. > > - more importantly, whether we're choosing an YUV output or not is completely > hidden away from the userspace even though it might have some effect on the > visual quality output (thinking about YUV420 and YUV422 here mostly). IMO driver should select highest achievable quality. So in case of YUV420 and YUV422, later should be selected. This should be the case even if the property is implemented. Best regards, Jernej > > - Similarly, the list we report is static and the userspace cannot change or > force one mode over the other. We will always pick YUV444 over RGB444 if > both are available for example. > > While the first one might just be due to a lack of helpers, the second and > third ones are also feeling a bit inconsistent with how we're handling the > 10/12 bit output for example > > Let me know what you think, > Maxime > > Maxime Ripard (18): > drm: Introduce new HDMI helpers > drm/bridge: Add HDMI output fmt helper > drm/bridge: dw-hdmi: Use helpers > drm/vc4: txp: Properly set the possible_crtcs mask > drm/vc4: crtc: Skip the TXP > drm/vc4: Rework the encoder retrieval code > drm/vc4: hdmi: Add full range RGB helper > drm/vc4: hdmi: Use full range helper in csc functions > drm/vc4: hdmi: Remove limited_rgb_range > drm/vc4: hdmi: Convert to bridge > drm/vc4: hdmi: Move XBAR setup to csc_setup > drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines > drm/vc4: hdmi: Define colorspace matrices > drm/vc4: hdmi: Change CSC callback prototype > drm/vc4: hdmi: Rework the infoframe prototype > drm/vc4: hdmi: Support HDMI YUV output > drm/vc4: hdmi: Move the pixel rate calculation to a helper > drm/vc4: hdmi: Force YUV422 if the rate is too high > > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 268 ++- > drivers/gpu/drm/drm_bridge.c | 118 +++ > drivers/gpu/drm/drm_hdmi.c| 170 + > drivers/gpu/drm/vc4/vc4_crtc.c| 59 +++- > drivers/gpu/drm/vc4/vc4_drv.c | 41 +++ > drivers/gpu/drm/vc4/vc4_drv.h | 26 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 399 +++--- > drivers/gpu/drm/vc4/vc4_hdmi.h| 13 +- > drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 + > drivers/gpu/drm/vc4/vc4_regs.h| 19 ++ > drivers/gpu/drm/vc4/vc4_txp.c | 2 +- > include/drm/drm_bridge.h | 6 + > include/drm/drm_hdmi.h| 24 ++ > 14 files changed, 770 insertions(+), 383 deletions(-) > create mode 100644 drivers/gpu/drm/drm_hdmi.c > create mode 100644 include/drm/drm_hdmi.h > > -- > 2.30.2 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: Fix few typo
On 3/18/21 4:00 AM, Bhaskar Chowdhury wrote: > > s/initialy/initially/ > s/desined/designed/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/meson/meson_venc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/meson/meson_venc.c > b/drivers/gpu/drm/meson/meson_venc.c > index 5e2236ec189f..3c55ed003359 100644 > --- a/drivers/gpu/drm/meson/meson_venc.c > +++ b/drivers/gpu/drm/meson/meson_venc.c > @@ -45,7 +45,7 @@ > * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC > * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI. > * The ENCP is designed for Progressive encoding but can also generate > - * 1080i interlaced pixels, and was initialy desined to encode pixels for > + * 1080i interlaced pixels, and was initially designed to encode pixels for > * VDAC to output RGB ou YUV analog outputs. > * It's output is only used through the ENCP_DVI encoder for HDMI. > * The ENCL LVDS encoder is not implemented. > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: Fixed couple of typos
On 3/17/21 11:26 PM, Bhaskar Chowdhury wrote: > s/modueles/modules/ two different places > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/msm/dp/dp_power.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/dp/dp_power.h > b/drivers/gpu/drm/msm/dp/dp_power.h > index 7d0327bbc0d5..e3f959ffae12 100644 > --- a/drivers/gpu/drm/msm/dp/dp_power.h > +++ b/drivers/gpu/drm/msm/dp/dp_power.h > @@ -88,7 +88,7 @@ int dp_power_client_init(struct dp_power *power); > * return: 0 for success, error for failure. > * > * This API will de-initialize the DisplayPort's clocks and regulator > - * modueles. > + * modules. > */ > void dp_power_client_deinit(struct dp_power *power); > > @@ -100,7 +100,7 @@ void dp_power_client_deinit(struct dp_power *power); > * > * This API will configure the DisplayPort's power module and provides > * methods to be called by the client to configure the power related > - * modueles. > + * modules. > */ > struct dp_power *dp_power_get(struct device *dev, struct dp_parser *parser); > > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH 02/18] drm/bridge: Add HDMI output fmt helper
Dne sreda, 17. marec 2021 ob 17:08:07 CET je Neil Armstrong napisal(a): > On 17/03/2021 16:43, Maxime Ripard wrote: > > The atomic_get_output_bus_fmts bridge callback is there to list the > > available formats for output by decreasing order of preference. > > > > On HDMI controllers, we have a fairly static list that will depend on > > what the HDMI sink is capable of and the BPC our controller can output. > > > > The dw-hdmi driver already has that code done in a fairly generic > > manner, so let's turn that code into an helper for all the HDMI > > controllers to reuse. > > This code was based on the capabilities of the DW-HDMI IP, copying it as-is > doesn't make much sense, we should be able to filter out formats the HDMI IP > doesn't support. HDMI standard has pretty strict requirements which formats should be supported, so cores should have very similar capabilities. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On 3/18/2021 3:16 AM, Daniel Vetter wrote: > On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote: >> >> >> On 2/11/2021 7:34 AM, Daniel Vetter wrote: >>> On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote: On 2/9/2021 2:54 AM, Daniel Vetter wrote: > On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote: >> This patch adds tracking of which cgroup to make charges against for a >> given GEM object. We associate the current task's cgroup with GEM >> objects >> as they are created. First user of this is for charging DRM cgroup for >> device memory allocations. The intended behavior is for device drivers >> to >> make the cgroup charging calls at the time that backing store is >> allocated >> or deallocated for the object. >> >> Exported functions are provided for charging memory allocations for a >> GEM object to DRM cgroup. To aid in debugging, we store how many bytes >> have been charged inside the GEM object. Add helpers for setting and >> clearing the object's associated cgroup which will check that charges are >> not being leaked. >> >> For shared objects, this may make the charge against a cgroup that is >> potentially not the same cgroup as the process using the memory. Based >> on the memory cgroup's discussion of "memory ownership", this seems >> acceptable [1]. >> >> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory >> Ownership" >> >> Signed-off-by: Brian Welty > > Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that > counts everything, why don't we also charge in these gem functions? I'm not sure what you mean exactly. You want to merge/move the charging logic proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into drm_gem_object_charge_mem() ? Or reading below, I think you are okay keeping the logic separated as is, but you want much of the code in kernel/cgroup/drm.c moved to drivers/gpu/cgroup ? Yes, I see that should allow to reduce number of exported functions. >>> >>> Both. I mean we'd need to look at the code again when it's shuffled, but >>> I'd say: >>> >>> - cgroup code and the charging for general gpu memory moves to >>> drivers/gpu/cgroup, so dma-buf heaps can use it too. >>> >>> - the charging for gem buffers moves into core gem code, so it happens for >>> all gpu drivers and all gem buffer allocations. >> >> Daniel, I'm not sure we're in sync on what 'charging for general gpu memory' >> means. Thus far, I have been proposing to charge/uncharge when backing >> store is >> allocated/freed. And thus, this would be done in DRM driver (so then also in >> the dma-buf exporter). >> I can't see how we'd hoist this part into drm gem code. >> The memory limit in this series is for VRAM usage/limit not GEM buffers... > > Yes this would be at gem buffer creation time. And just to get cgroups > for drm up&running. Okay, but it's not of the ones in Tejun's list to start with: https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html I hoped we would start by pursuing those (gpu.weight and gpu.memory.high) as first step. Limiting GEM buffers is essentially controlling virtual memory size, which tend to just always get set to unlimited. Would be nice to get consensus from maintainers before proceeding to implement this. > >> Unless you are talking about charging for GEM buffer creation? But this is >> more of a 'soft resource' more along lines of Kenny's earlier GEM buffer >> limit >> control. >> I raised issue with this then, and at the time, Tejun agreed we should keep >> to >> 'hard resource' controls, see [1] and [2]. >> >> [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/218071.html >> [2] https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html >> >>> >>> - this might or might not mean a bunch less exported stuff from the >>> cgroups files (since you don't need separate steps for linking a gem >>> object to a cgroup from the actual charging), and probably no exports >>> anymore for drivers (since they charge nothing). That will change >>> when we add charging for specific memory pools I guess, but we add that >>> when we add tha functionality. >> >> ... so considering VRAM charging, then yes, we very much need to have >> exported >> functions for drivers to do the charging. >> But these can be exported from drm.ko (or new .ko?) instead of kernel. Is >> that still preference? Also, if number of exported functions is concern, we >> can replace some of it with use of function pointers. > > So the reason I suggested we drop all this is because we won't charge > in drivers, we'll charge in ttm buffer management code. Which we'll > adopt for dg1 in upstream. But it will take some time. Okay, thanks for clarifying. I'm not familiar with where try_charge/uncharge
Re: [PATCH 1/3] drm/ttm: move swapout logic around v2
On 3/18/21 4:26 PM, Christian König wrote:
Am 18.03.21 um 15:43 schrieb Nirmoy:
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h
b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -297,6 +297,8 @@ struct ttm_device {
struct delayed_work wq;
};
+long ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t
gfp_flags);
There is a typo here, long -> int.
Ah, yes. I missed to add the change to the header file.
I have tested the patch series on qxl and vmwgfx.
With that typo fixed, the series is Tested-by: Nirmoy Das
Thanks for pointing that out,
Christian.
Thanks,
Nirmoy
+
static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
On 17/03/2021 19:25, Rob Clark wrote: On Mon, Mar 1, 2021 at 1:41 PM Dmitry Baryshkov wrote: if GPU components have failed to bind, shutdown callback would fail with the following backtrace. Add safeguard check to stop that oops from happening and allow the board to reboot. [skipped] diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 6a326761dc4a..2fd0cf6421ad 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -207,7 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) struct msm_kms *kms = priv->kms; struct drm_crtc *async_crtc = NULL; unsigned crtc_mask = get_crtc_mask(state); - bool async = kms->funcs->vsync_time && + bool async; + + if (!kms) + return; I think we could instead just check for null priv->kms in msm_pdev_shutdown() and not call drm_atomic_helper_shutdown()? Good idea. Sending v2. BR, -R + + async = kms->funcs->vsync_time && can_do_async(state, &async_crtc); trace_msm_atomic_commit_tail_start(async, crtc_mask); -- 2.30.1 -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
static void msm_pdev_shutdown(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_atomic_helper_shutdown(drm);
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..fd2ac54caf9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1311,6 +1311,10 @@ static int msm_pdev_remove(struct platform_device *pdev)
static void msm_pdev_shutdown(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
+
+ if (!priv || !priv->kms)
+ return;
drm_atomic_helper_shutdown(drm);
}
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a typo
On 14:12 Thu 18 Mar 2021, Alex Deucher wrote:
On Thu, Mar 18, 2021 at 2:08 PM Randy Dunlap wrote:
On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
>
> s/traing/training/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> index c325d6f53a71..db18e4f6cf5f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> @@ -661,7 +661,7 @@ static int psp_v11_0_memory_training(struct psp_context
*psp, uint32_t ops)
>
> if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
> /*
> - * Long traing will encroach certain mount of bottom VRAM,
> + * Long training will encroach certain mount of bottom VRAM,
amount
I think.
Yeah, I think it should read something like:
Long training will encroach a certain amount on the bottom of VRAM;
save the content from the bottom VRAM to system memory
before training, and restore it after training to avoid
VRAM corruption.
Alex
>* saving the content of this bottom VRAM to system memory
>* before training, and restoring it after training to avoid
>* VRAM corruption.
Thanks.
> --
> 2.26.2
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/amdgpu: Fix a typo
s/traing/training/
...Plus the entire sentence construction for better readability.
Signed-off-by: Bhaskar Chowdhury
---
Changes from V1:
Alex and Randy's suggestions incorporated.
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index c325d6f53a71..bf3857867f51 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -661,10 +661,10 @@ static int psp_v11_0_memory_training(struct psp_context
*psp, uint32_t ops)
if (ops & PSP_MEM_TRAIN_SEND_LONG_MSG) {
/*
-* Long traing will encroach certain mount of bottom VRAM,
-* saving the content of this bottom VRAM to system memory
-* before training, and restoring it after training to avoid
-* VRAM corruption.
+* Long training will encroach a certain amount on the bottom
of VRAM;
+ * save the content from the bottom VRAM to system memory
+ * before training, and restore it after training to avoid
+ * VRAM corruption.
*/
sz = GDDR6_MEM_TRAINING_ENCROACHED_SIZE;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This is actually wrong though, as we only
want to be concerned that the actual width/height of the plane are the
same. It's fine if we scan out from an fb that's slightly larger than the
cursor plane (in fact, some igt tests actually do this).
Note that I'm not entirely sure why this wasn't previously breaking
kms_cursor_crc tests - they all set up cursors with the height being one
pixel larger than the actual size of the cursor. But this seems to fix
things, and the code before was definitely incorrect - so it's not really
worth looking into further imho.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
index 54fbd6fe751d..7a7f80e51ec0 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
@@ -109,7 +109,7 @@ curs507a_acquire(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw,
if (ret || !asyh->curs.visible)
return ret;
- if (asyw->image.w != asyw->image.h)
+ if (asyw->state.crtc_w != asyw->state.crtc_h)
return -EINVAL;
ret = head->func->curs_layout(head, asyw, asyh);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
index 09b89983864b..3d230ca488c9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head507d.c
@@ -176,7 +176,7 @@ int
head507d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
- switch (asyw->image.w) {
+ switch (asyw->state.crtc_w) {
case 32: asyh->curs.layout =
NV507D_HEAD_SET_CONTROL_CURSOR_SIZE_W32_H32; break;
case 64: asyh->curs.layout =
NV507D_HEAD_SET_CONTROL_CURSOR_SIZE_W64_H64; break;
default:
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
index 4ce47b55f72c..caa7d633691b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
@@ -103,7 +103,7 @@ int
head917d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
- switch (asyw->state.fb->width) {
+ switch (asyw->state.crtc_w) {
case 32: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W32_H32; break;
case 64: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W64_H64; break;
case 128: asyh->curs.layout =
NV917D_HEAD_SET_CONTROL_CURSOR_SIZE_W128_H128; break;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
>
> Found this while trying to make some changes to the kms_cursor_crc test.
> curs507a_acquire checks that the width and height of the cursor framebuffer
> are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> want to be concerned that the actual width/height of the plane are the
> same. It's fine if we scan out from an fb that's slightly larger than the
> cursor plane (in fact, some igt tests actually do this).
How so? The scanout engine expects the data to be packed. Height can
be larger, but width has to match.
-ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size
On Thu, 2021-03-18 at 18:13 -0400, Ilia Mirkin wrote:
> On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
> >
> > Found this while trying to make some changes to the kms_cursor_crc test.
> > curs507a_acquire checks that the width and height of the cursor framebuffer
> > are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> > want to be concerned that the actual width/height of the plane are the
> > same. It's fine if we scan out from an fb that's slightly larger than the
> > cursor plane (in fact, some igt tests actually do this).
>
> How so? The scanout engine expects the data to be packed. Height can
> be larger, but width has to match.
Huh - wasn't expecting that, nice catch. I'll fix this up in a moment
>
> -ilia
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
So basically we see this warning only in case of bigjoiner when drm_atomic_check gets called without setting the state->allow_modeset flag. So do you think that in i915, in intel_atomic_check_bigjoiner() we should only steal the crtc when allow_modeset flag is set in state? If we add this check there then the affected crtc wont count the slave crtc and we wont get this warning. Ville, Danvet? Manasi On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen wrote: > > > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote: > > > > On Wed, 3 Mar 2021 12:44:33 -0800 > > > > "Navare, Manasi" wrote: > > > > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote: > > > > > > On Tue, 2 Mar 2021 12:41:32 -0800 > > > > > > Manasi Navare wrote: > > > > > > > > > > > > > In case of a modeset where a mode gets split across mutiple CRTCs > > > > > > > in the driver specific implementation (bigjoiner in i915) we > > > > > > > wrongly count > > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate the > > > > > > > stolen CRTC as > > > > > > > an affected CRTC in atomic_check_only(). > > > > > > > This triggers a warning since affected CRTCs doent match > > > > > > > requested CRTC. > > > > > > > > > > > > > > To fix this in such bigjoiner configurations, we should only > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not > > > > > > > if it is just used internally in the driver to split the mode. > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think that makes sense to me. Stealing CRTCs that are not > > > > > > currently > > > > > > used by the userspace (display server) should be ok, as long as that > > > > > > is completely invisible to userspace: meaning that it does not cause > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic > > > > > > completion events. > > > > > > > > > > Yes since we are only doing atomic_check_only() here, the stolen > > > > > > > > But the real not-test-only commit will follow if this test-only commit > > > > succeeds, and keeping the guarantees for the real commit are important. > > > > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for the display output, it is > > > used for joiner so the uapi.enable will be true after the real commit. > > > > > > so actually the assertion would fail in this case. > > > > > > @Ville @Danvet any suggestions here in that case? > > That is very bad. We can't frob uapi state like that. I think that > calls for even more checks to make sure kms drivers who try to play > clever games don't get it wrong, so we probably need to check uapi > enable and active state in another mask before/after ->atomic_check > too. Or something like that. > > > Hi, > > > > that is not what I was talking about, but sounds like you found a > > different problem. It seems like the problem you are talking about > > would be guaranteed to be hit if bigjoiner was used. Have you not > > tested this? > > > > However, I was talking about the real commit itself, not what happens > > on commits after it, see below. > > > > > > > crtc is completely invisible to the userspace and hence that is > > > > > indicated by uapi.enable which is not true for this stolen > > > > > crtc. However if allow modeset flag set, then it will do a full > > > > > modeset and indicate the uapi.enable for this stolen crtc as well > > > > > since that cannot be used for other modeset requested by userspace. > > > > > > > > > > > > > > > > > Can that also be asserted somehow, or does this already do that? > > > > > > > > > > Not clear what you want the assertion for? Could you elaborate > > > > > > > > As assertion that when the real atomic commit happens and then > > > > completion events are fired, they match exactly the affected crtcs mask. > > > > This is my concern and a question, although like I say below, only > > tangential to this patch. > > > > However, as this patch aims to allow bigjoiner usage, naturally the > > question will arise whether the completion events then match what > > userspace expects or not. Userspace does not expect completion events > > referring to the stolen CRTCs. > > Yeah we also must make sure that we don't send out events for these > additional crtc in bigjoiner usage. Sounds like igt testing didn't > catch this, I think we need a lot more igts here to make sure all > these surprises don't happen. > > Plus maybe triple-checking that drm_atomic_uapi.c makes sure we can't > send out events for stuff that userspace didn't ask for. > -Daniel > > > > > > > I understand this may be off-topic for this particular patch, but since > > > > we are discussing the topic, such checks would be really nice. I'm > > > > curious if such checks already exist. > > > > > > Thanks, > > pq > > > > > >
[PATCH v2] drm/nouveau/kms/nv50-: Correct size checks for cursors
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This isn't entirely correct though, as the
height of the cursor can be larger than the size of the cursor, as long as
the width is the same as the cursor size and there's no framebuffer offset.
Note that I'm not entirely sure why this wasn't previously breaking
kms_cursor_crc tests - they all set up cursors with the height being one
pixel larger than the actual size of the cursor. But this seems to fix
things, and the code before was definitely incorrect - so it's not really
worth looking into further imho.
Changes since v1:
* Don't use crtc_w everywhere for determining cursor layout, just use fb
size again
* Change check so that we only check that the w/h of the cursor plane is
the same, the width of the scanout surface is the same as the framebuffer
width, and that there's no offset being used for the cursor surface.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
index 54fbd6fe751d..00e19fd959ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
@@ -98,6 +98,7 @@ static int
curs507a_acquire(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw,
struct nv50_head_atom *asyh)
{
+ struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
struct nv50_head *head = nv50_head(asyw->state.crtc);
int ret;
@@ -109,8 +110,20 @@ curs507a_acquire(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw,
if (ret || !asyh->curs.visible)
return ret;
- if (asyw->image.w != asyw->image.h)
+ if (asyw->state.crtc_w != asyw->state.crtc_h) {
+ NV_ATOMIC(drm, "Plane width/height must be equal for
cursors\n");
return -EINVAL;
+ }
+
+ if (asyw->image.w != asyw->state.crtc_w) {
+ NV_ATOMIC(drm, "Plane width must be equal to fb width for
cursors (height can be larger though)\n");
+ return -EINVAL;
+ }
+
+ if (asyw->state.src_x || asyw->state.src_y) {
+ NV_ATOMIC(drm, "Cursor planes do not support framebuffer
offsets\n");
+ return -EINVAL;
+ }
ret = head->func->curs_layout(head, asyw, asyh);
if (ret)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Enhance DP MST topology logging
(going to try to take a look at this tomorrow JFYI)
On Thu, 2021-03-18 at 11:55 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info were also logged as an
> arbitrary series of ints which require the user to know the ordering
> of the prints, making the logs difficult to use.
>
> [how]
> -add fec logging
> -add pdt parsing into strings
> -format vcpi and payload info into tables with headings
> -clean up topology prints
>
> Signed-off-by: Eryk Brol
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 67 ---
> 1 file changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 932c4641ec3e..3afeaa59cbaa 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4720,6 +4720,24 @@ static void drm_dp_mst_kick_tx(struct
> drm_dp_mst_topology_mgr *mgr)
> queue_work(system_long_wq, &mgr->tx_work);
> }
>
> +static char *pdt_to_string(u8 pdt)
> +{
> + switch (pdt) {
> + case DP_PEER_DEVICE_NONE:
> + return "NONE";
> + case DP_PEER_DEVICE_SOURCE_OR_SST:
> + return "SOURCE OR SST";
> + case DP_PEER_DEVICE_MST_BRANCHING:
> + return "MST BRANCHING";
> + case DP_PEER_DEVICE_SST_SINK:
> + return "SST SINK";
> + case DP_PEER_DEVICE_DP_LEGACY_CONV:
> + return "DP LEGACY CONV";
> + default:
> + return "ERR";
> + }
> +}
> +
> static void drm_dp_mst_dump_mstb(struct seq_file *m,
> struct drm_dp_mst_branch *mstb)
> {
> @@ -4732,9 +4750,20 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
> prefix[i] = '\t';
> prefix[i] = '\0';
>
> - seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
> + seq_printf(m, "%smstb - [%p]: num_ports: %d\n", prefix, mstb, mstb-
> >num_ports);
> list_for_each_entry(port, &mstb->ports, next) {
> - seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps:
> %d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input, port-
> >pdt, port->ddps, port->ldps, port->num_sdp_streams, port-
> >num_sdp_stream_sinks, port, port->connector);
> + seq_printf(m, "%sport %d - [%p] (%s - %s): ddps: %d, ldps: %d,
> sdp: %d/%d, fec: %s, conn: %p\n",
> + prefix,
> + port->port_num,
> + port,
> + port->input ? "input" : "output",
> + pdt_to_string(port->pdt),
> + port->ddps,
> + port->ldps,
> + port->num_sdp_streams,
> + port->num_sdp_stream_sinks,
> + port->fec_capable ? "true" : "false",
> + port->connector);
> if (port->mstb)
> drm_dp_mst_dump_mstb(m, port->mstb);
> }
> @@ -4787,33 +4816,39 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> mutex_unlock(&mgr->lock);
>
> mutex_lock(&mgr->payload_lock);
> - seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
> - mgr->max_payloads);
> + seq_printf(m, "\n *** VCPI Info ***\npayload_mask: %lx, vcpi_mask:
> %lx, max_payloads: %d\n",
> + mgr->payload_mask,
> + mgr->vcpi_mask,
> + mgr->max_payloads);
>
> + seq_printf(m, "\n| idx | port # | vcp_id | # slots | sink
> name |\n");
> for (i = 0; i < mgr->max_payloads; i++) {
> if (mgr->proposed_vcpis[i]) {
> char name[14];
>
> port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
> fetch_monitor_name(mgr, port, name, sizeof(name));
> - seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
> - port->port_num, port->vcpi.vcpi,
> - port->vcpi.num_slots,
> - (*name != 0) ? name : "Unknown");
> + seq_printf(m, "%10d%10d%10d%10d%20s\n",
> + i,
> + port->port_num,
> + port->vcpi.vcpi,
> + port->vcpi.num_slots,
> + (*name != 0) ? name : "Unknown");
> } else
> - seq_printf(m, "vcpi %d:unused\n", i);
> + seq_printf(m, "%6d - Unused\n", i);
> }
> + seq_printf(m, "\n *** Payload
[PATCH] drm/amdgpu: Fix a typo
s/proces/process/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index bf3857867f51..c1d5a3085bae 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -598,7 +598,7 @@ static int psp_v11_0_memory_training_send_msg(struct
psp_context *psp, int msg)
}
/*
- * save and restore proces
+ * save and restore process
*/
static int psp_v11_0_memory_training(struct psp_context *psp, uint32_t ops)
{
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Parshuram,
Thank you for the patch.
On Thu, Mar 18, 2021 at 07:45:30AM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
>
> Signed-off-by: Parshuram Thombare
> ---
> .../display/bridge/cdns,mhdp8546.yaml | 24 +++
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> index 63427878715e..8a85768f6202 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> @@ -17,8 +17,8 @@ properties:
>- ti,j721e-mhdp8546
>
>reg:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- description:
>Register block of mhdptx apb registers up to PHY mapped area
> (AUX_CONFIG_P).
> @@ -26,13 +26,16 @@ properties:
>included in the associated PHY.
>- description:
>Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
> + - description:
> + Register block of mhdptx sapb registers.
>
>reg-names:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- const: mhdptx
>- const: j721e-intg
> + - const: mhdptx-sapb
>
>clocks:
> maxItems: 1
> @@ -98,15 +101,15 @@ allOf:
> then:
>properties:
> reg:
> - minItems: 2
> + minItems: 3
> reg-names:
> - minItems: 2
> + minItems: 3
> else:
>properties:
> reg:
> - maxItems: 1
> + maxItems: 2
> reg-names:
> - maxItems: 1
> + maxItems: 2
>
> required:
>- compatible
> @@ -129,8 +132,9 @@ examples:
>
> mhdp: dp-bridge@f0fb00 {
> compatible = "cdns,mhdp8546";
> -reg = <0xf0 0xfb00 0x0 0x100>;
> -reg-names = "mhdptx";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0x0 0x4f48000 0x0 0x74>;
> +reg-names = "mhdptx", "mhdptx-sapb";
Running
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
produces
LINTDocumentation/devicetree/bindings
CHKDT Documentation/devicetree/bindings/processed-schema-examples.json
SCHEMA Documentation/devicetree/bindings/processed-schema-examples.json
DTEX
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dts
DTC
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dt.yaml
CHECK
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dt.yaml
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.example.dt.yaml:
dp-bridge@f0fb00: reg-names:1: 'j721e-intg' was expected
From schema:
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
This is caused by the fact that reg-names is correctly limited to two
elements, but then expects the second element to be "j721e-intg". The
example is good, so it's the bindings that need to be fixed.
> clocks = <&mhdp_clock>;
> phys = <&dp_phy>;
> phy-names = "dpphy";
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
