From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
drm_mode_validate_size() does *not* modify the passed in mode's
status (in fact it is passed in as const). Also this operates
on a single mode, so the reference to some list is just confusing.
Remove the nonsense docs.
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/drm_modes.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/…
[View More]drm/drm_modes.c
index 1c72208d8133..425a56a976a1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1136,16 +1136,14 @@ EXPORT_SYMBOL(drm_mode_validate_driver);
/**
* drm_mode_validate_size - make sure modes adhere to size constraints
* @mode: mode to check
* @maxX: maximum width
* @maxY: maximum height
*
- * This function is a helper which can be used to validate modes against size
- * limitations of the DRM device/connector. If a mode is too big its status
- * member is updated with the appropriate validation failure code. The list
- * itself is not changed.
+ * This function is a helper which can be used to validate
+ * modes against size limitations of the DRM device/connector.
*
* Returns:
* The mode status
*/
enum drm_mode_status
drm_mode_validate_size(const struct drm_display_mode *mode,
--
2.34.1
[View Less]
The below patches add support for data flow metering
as mentioned in the section 6.5.6 FRL data flow metering
of HDMI 2.1 specification.
Add functions to calclulate the DFM parameters
for the given frl config, which is further used to evaluate the
data flow metering requirement as specified in the spec.
As per the spec the below patches implement the frl capacity computation
functions for both compressed and uncompressed video.
Finally exposing 1 function each for compressed and uncompressed …
[View More]video
to figure out if the data flow metering requirement is met or not.
Ankit Nautiyal (1):
drm/hdmi21: Add support for DFM calculation with DSC
Vandita Kulkarni (4):
drm/hdmi21: Define frl_dfm structure
drm/hdmi21: Add non dsc frl capacity computation helpers
drm/hdmi21: Add helpers to verify non-dsc DFM requirements
drm/hdmi21: Add frl_dfm_helper to Makefile
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_frl_dfm_helper.c | 855 +++++++++++++++++++++++++++
include/drm/drm_frl_dfm_helper.h | 131 ++++
3 files changed, 987 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_frl_dfm_helper.c
create mode 100644 include/drm/drm_frl_dfm_helper.h
--
2.32.0
[View Less]
Hi Dave, Daniel,
Fixes for 5.17.
The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c:
Linux 5.17-rc2 (2022-01-30 15:37:07 +0200)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.17-2022-02-02
for you to fetch changes up to e8ae38720e1a685fd98cfa5ae118c9d07b45ca79:
drm/amdgpu: fix logic inversion in check (2022-02-02 18:35:00 -0500)
----------------------------------------------------------------
amd-…
[View More]drm-fixes-5.17-2022-02-02:
amdgpu:
- mGPU fan boost fix for beige goby
- S0ix fixes
- Cyan skillfish hang fix
- DCN fixes for DCN 3.1
- DCN fixes for DCN 3.01
- Apple retina panel fix
- ttm logic inversion fix
----------------------------------------------------------------
Agustin Gutierrez (1):
drm/amd/display: Update watermark values for DCN301
Aun-Ali Zaidi (1):
drm/amd/display: Force link_rate as LINK_RATE_RBR2 for 2018 15" Apple Retina panels
Christian König (1):
drm/amdgpu: fix logic inversion in check
Evan Quan (1):
drm/amd/pm: correct the MGpuFanBoost support for Beige Goby
Lang Yu (1):
drm/amdgpu: fix a potential GPU hang on cyan skillfish
Mario Limonciello (4):
drm/amd: Warn users about potential s0ix problems
drm/amd: add support to check whether the system is set to s3
drm/amd: Only run s3 or s0ix if system is configured properly
drm/amd: avoid suspend on dGPUs w/ s2idle support when runtime PM enabled
Paul Hsieh (1):
drm/amd/display: watermark latencies is not enough on DCN31
Zhan Liu (1):
drm/amd/display: revert "Reset fifo after enable otg"
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 10 ++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 37 +++++++++++++++++++---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++
.../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 16 +++++-----
.../amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 20 ++++++------
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 20 ++++++++++++
.../amd/display/dc/dce110/dce110_hw_sequencer.c | 5 ---
.../amd/display/dc/dcn10/dcn10_stream_encoder.c | 15 ---------
.../amd/display/dc/dcn10/dcn10_stream_encoder.h | 3 --
.../amd/display/dc/dcn20/dcn20_stream_encoder.c | 2 --
.../display/dc/dcn30/dcn30_dio_stream_encoder.c | 2 --
.../gpu/drm/amd/display/dc/inc/hw/stream_encoder.h | 4 ---
.../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 6 ++--
15 files changed, 94 insertions(+), 62 deletions(-)
[View Less]
Hi all,
Today's linux-next merge of the drm-intel-gt tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
0d6419e9c855 ("drm/i915: Move GT registers to their own header file")
from the drm-intel tree and commit:
270677026261 ("drm/i915/dg2: Add Wa_14015227452")
from the drm-intel-gt tree.
I fixed it up (I used the former version and then added the following
merge fix patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, …
[View More]but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
It would be nice if you synced up these 2 trees (by merging one into
the other) as I am carrying several merge fix patches due to the
splitting up of i915_reg.h.
From: Stephen Rothwell <sfr(a)canb.auug.org.au>
Date: Thu, 3 Feb 2022 11:09:02 +1100
Subject: [PATCH] fix up for "drm/i915: Move GT registers to their own header file"
Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 16d98ebee687..a6f0220c2e9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1482,6 +1482,7 @@ enum {
#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
#define GEN12_DISABLE_GRF_CLEAR REG_BIT(13)
+#define XEHP_DIS_BBL_SYSPIPE REG_BIT(11)
#define GEN12_DISABLE_TDL_PUSH REG_BIT(9)
#define GEN11_DIS_PICK_2ND_EU REG_BIT(7)
#define GEN12_DISABLE_HDR_PAST_PAYLOAD_HOLD_FIX REG_BIT(4)
--
2.34.1
--
Cheers,
Stephen Rothwell
[View Less]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
b3f74938d656 ("drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for reference")
from the drm-intel-fixes tree and commit:
22ba60f617bd ("drm/i915: Move [more] GT registers to their own header file")
from the drm-intel tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is …
[View More]concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[View Less]
In function do_fb_ioctl(), the "arg" is the type of unsigned long,
and in "case FBIOBLANK:" this argument is casted into an int before
passig to fb_blank(). In fb_blank(), the comparision
if (blank > FB_BLANK_POWERDOWN) would be bypass if the original
"arg" is a large number, which is possible because it comes from
the user input.
Signed-off-by: Yizhuo Zhai <yzhai003(a)ucr.edu>
---
drivers/video/fbdev/core/fbmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/…
[View More]drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..a5f71c191122 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1064,7 +1064,7 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
EXPORT_SYMBOL(fb_set_var);
int
-fb_blank(struct fb_info *info, int blank)
+fb_blank(struct fb_info *info, unsigned long blank)
{
struct fb_event event;
int ret = -EINVAL;
--
2.25.1
[View Less]
Assigning 0L to a pointer variable caused the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/rc_calc_fpu.c:71:40:
warning: Using plain integer as NULL pointer
In order to remove this warning, this commit assigns a NULL pointer to
the pointer variable that caused this issue.
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Magali Lemes <magalilemes00(a)gmail.com>
---
drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c | 2 +-
1 file changed, 1 …
[View More]insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
index ec636d06e18c..ef75eb7d5adc 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
@@ -68,7 +68,7 @@ static void get_qp_set(qp_set qps, enum colour_mode cm, enum bits_per_comp bpc,
int sel = table_hash(mode, bpc, max_min);
int table_size = 0;
int index;
- const struct qp_entry *table = 0L;
+ const struct qp_entry *table = NULL;
// alias enum
enum { min = DAL_MM_MIN, max = DAL_MM_MAX };
--
2.25.1
[View Less]
From: Rob Clark <robdclark(a)chromium.org>
Currently, for GL_EXT_robustness userspace uses the global and per-
submitqueue fault counters to determine GUILTY_CONTEXT_RESET_EXT vs
INNOCENT_CONTEXT_RESET_EXT. But that is a bit overly paranoid, in
that a fault in a different process's context (when it has it's own
isolated address space) should not hurt anything.
This is particularly annoying with CrOS and chrome's exit_on_context_lost quirk,
while running deqp in the android container, …
[View More]as the deqp-egl suite has
tests that intentionally trigger gpu hangs (for the purpose of testing
the robustness extension), which triggers chrome to restart, which
restarts the android container!
But chrome doesn't need to know about these faults, thanks to address
space isolation.
Applies on top of https://patchwork.freedesktop.org/series/98907/
Rob Clark (2):
drm/msm/gpu: Add ctx to get_param()
drm/msm/gpu: Track global faults per address-space
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 +++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
drivers/gpu/drm/msm/msm_gem.h | 3 +++
drivers/gpu/drm/msm/msm_gpu.c | 8 +++++++-
drivers/gpu/drm/msm/msm_gpu.h | 8 ++++++--
drivers/gpu/drm/msm/msm_rd.c | 6 ++++--
7 files changed, 27 insertions(+), 9 deletions(-)
--
2.34.1
[View Less]