Re: [PATCH v2 2/2] fbcon: Defer console takeover for splash screens to first switch
On 9/2/24 18:58, Daniel Vetter wrote: > On Thu, Feb 08, 2024 at 09:16:50AM +0800, Daniel van Vugt wrote: >> On 8/2/24 04:21, Mario Limonciello wrote: >>> On 2/7/2024 03:51, Daniel Vetter wrote: On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote: > On 6/2/24 23:41, Mario Limonciello wrote: >> On 2/6/2024 08:21, Daniel Vetter wrote: >>> On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel van Vugt wrote: Until now, deferred console takeover only meant defer until there is output. But that risks stepping on the toes of userspace splash screens, as console messages may appear before the splash screen. So check the command line for the expectation of userspace splash and if present then extend the deferral until after the first switch. V2: Added Kconfig option instead of hard coding "splash". Closes: https://bugs.launchpad.net/bugs/1970069 Cc: Mario Limonciello Signed-off-by: Daniel van Vugt --- drivers/video/console/Kconfig | 13 +++ drivers/video/fbdev/core/fbcon.c | 38 ++-- 2 files changed, 49 insertions(+), 2 deletions(-) diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig index bc31db6ef7..a6e371bfb4 100644 --- a/drivers/video/console/Kconfig +++ b/drivers/video/console/Kconfig @@ -138,6 +138,19 @@ config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER by the firmware in place, rather then replacing the contents with a black screen as soon as fbcon loads. +config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION + string "Framebuffer Console Deferred Takeover Condition" + depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER + default "splash" + help + If enabled this defers further the framebuffer console taking over + until the first console switch has occurred. And even then only if + text has been output, and only if the specified parameter is found + on the command line. This ensures fbcon does not interrupt userspace + splash screens such as Plymouth which may be yet to start rendering + at the time of the first console output. "splash" is the simplest + distro-agnostic condition for this that Plymouth checks for. >>> >>> Hm this seems a bit strange since a lot of complexity that no one needs, >>> also my impression is that it's rather distro specific how you want this >>> to work. So why not just a Kconfig option that lets you choose how much >>> you want to delay fbcon setup, with the following options: >>> >>> - no delay at all >>> - dely until first output from the console (which then works for distros >>> which set a log-level to suppress unwanted stuff) >>> - delay until first vt-switch. In that case I don't think we also need >>> to >>> delay for first output, since vt switch usually means you'll get >>> first >>> output right away (if it's a vt terminal) or you switch to a >>> different >>> graphical console (which will keep fbcon fully suppressed on the drm >>> side). >>> > > I had similar thoughts, and had prototyped some of this already. But in > the end > it felt like extra complexity there was no demand for. For me this one is a bit too complex, since if you enable the vt switch delay you also get the output delay on top. That seems one too much and I can't come up with a use-case where you actually want that. So just a choice of one or the other or none feels cleaner. >> >> Remember the output "delay" goes to zero if any putc has occurred prior to >> registration (see dummycon.c). >> >> My current reason for using both is that in theory it prevents fbcon from >> taking over *earlier* than it did before, in case there was never any output. >> But I don't think there is "never any output" by the time you've tried to >> manually VT switch so maybe that's unnecessary. > > Yeah, but I'm not sure that's like a choice anyone needs, just these > three: > > - no delay > - wait until first output, and set debuglevel appropriately (what fedora > and other distros do) > - wait until first vt switch (what ubuntu wants) Come to think of it, an enum or Kconfig "choice" isn't necessary if I change the default for CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION to blank/disabled. Then the default behaviour is unchanged and you've still got the choice of all three modes: - No delay: fbcon=nodefer - Wait until first output: Already happens when
[PATCH 28/28] drm/i915/color: Enable Plane Color Pipelines
From: Chaitanya Kumar Borah
Expose color pipeline and add capability to program it.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 7096ea8a3454..64e70cc34ddb 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -11,6 +11,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
#include "intel_atomic_plane.h"
+#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_irq.h"
#include "intel_display_types.h"
@@ -1279,6 +1280,8 @@ icl_plane_update_noarm(struct intel_plane *plane,
plane_color_ctl = plane_state->color_ctl |
glk_plane_color_ctl_crtc(crtc_state);
+ intel_program_pipeline(_state->uapi, _color_ctl);
+
/* The scaler will handle the output position */
if (plane_state->scaler_id >= 0) {
crtc_x = 0;
@@ -2432,6 +2435,8 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
BIT(DRM_COLOR_YCBCR_FULL_RANGE),
DRM_COLOR_YCBCR_BT709,
DRM_COLOR_YCBCR_LIMITED_RANGE);
+ else
+ intel_plane_color_init(>base);
drm_plane_create_alpha_property(>base);
drm_plane_create_blend_mode_property(>base,
--
2.42.0
[PATCH 27/28] FIXME: force disable legacy plane color properties for TGL and beyond
From: Chaitanya Kumar Borah The decision should be made based on the DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE. Right now the value of this cap is not passed on to the driver. Signed-off-by: Chaitanya Kumar Borah --- drivers/gpu/drm/i915/display/skl_universal_plane.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c index e941e2e4fd14..7096ea8a3454 100644 --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c @@ -2424,12 +2424,14 @@ skl_universal_plane_create(struct drm_i915_private *dev_priv, if (DISPLAY_VER(dev_priv) >= 10) supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020); - drm_plane_create_color_properties(>base, - supported_csc, - BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | - BIT(DRM_COLOR_YCBCR_FULL_RANGE), - DRM_COLOR_YCBCR_BT709, - DRM_COLOR_YCBCR_LIMITED_RANGE); + /* TODO: Make it based on client cap */ + if (DISPLAY_VER(dev_priv) <= 11) + drm_plane_create_color_properties(>base, + supported_csc, + BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | + BIT(DRM_COLOR_YCBCR_FULL_RANGE), + DRM_COLOR_YCBCR_BT709, + DRM_COLOR_YCBCR_LIMITED_RANGE); drm_plane_create_alpha_property(>base); drm_plane_create_blend_mode_property(>base, -- 2.42.0
[PATCH 26/28] drm/i915/xelpd: Program Plane Post CSC Registers
Extract the LUT and program plane post csc registers.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/intel_color.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 6dd9b8e43352..68e1c91a2b39 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3863,6 +3863,92 @@ static void xelpd_program_plane_pre_csc_lut(const struct
drm_plane_state *state,
}
}
+static void xelpd_program_plane_post_csc_lut(const struct drm_plane_state
*state,
+const struct drm_color_lut_ext
*post_csc_lut,
+u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ u32 i, lut_size;
+
+ if (icl_is_hdr_plane(dev_priv, plane)) {
+ intel_de_write_fw(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe,
plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+ if (post_csc_lut) {
+ lut_size = 32;
+ for (i = 0; i < lut_size; i++) {
+ u64 word =
drm_color_lut_extract_ext(post_csc_lut[i].green, 24);
+ u32 lut_val = (word & 0xff);
+
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ lut_val);
+ }
+
+ do {
+ /* Program the max register to clamp values >
1.0. */
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ post_csc_lut[i].green);
+ } while (i++ < 34);
+ } else {
+ lut_size = 32;
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ 1 << 24);
+ } while (i++ < 34);
+ }
+
+ intel_de_write_fw(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe,
plane, 0), 0);
+ } else {
+ lut_size = 32;
+ /*
+* First 3 planes are HDR, so reduce by 3 to get to the right
+* SDR plane offset
+*/
+ plane = plane - 3;
+
+ intel_de_write_fw(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe,
plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (post_csc_lut) {
+ for (i = 0; i < lut_size; i++)
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ post_csc_lut[i].green &
0x);
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 35)
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ post_csc_lut[i++].green &
0x3);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write_fw(dev_priv,
+
PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ (1 << 16));
+ } while (i++ < 34);
+ }
+
+ intel_de_write_fw(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe,
plane, 0), 0);
+ }
+}
+
static void xelpd_plane_load_luts(const struct drm_plane_state *plane_state,
const struct drm_property_blob
[PATCH 25/28] drm/i915/color: Program Pre-CSC registers
Add callback for programming Pre-CSC LUT for TGL and beyond
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 0d68f8303502..6dd9b8e43352 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3779,9 +3779,97 @@ void intel_color_load_plane_csc_matrix(const struct
drm_plane_state *plane_state
i915->display.funcs.color->load_plane_csc_matrix(plane_state,
blob);
}
+static void xelpd_program_plane_pre_csc_lut(const struct drm_plane_state
*state,
+ const struct drm_color_lut_ext
*pre_csc_lut,
+ u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ u32 i, lut_size;
+
+ if (icl_is_hdr_plane(dev_priv, plane)) {
+ lut_size = 128;
+
+ intel_de_write_fw(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe,
plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (pre_csc_lut) {
+ for (i = 0; i < lut_size; i++) {
+ u64 word =
drm_color_lut_extract_ext(pre_csc_lut[i].green, 24);
+ u32 lut_val = (word & 0xff);
+
+ intel_de_write_fw(dev_priv,
+
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ lut_val);
+ }
+
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 131)
+ intel_de_write_fw(dev_priv,
+
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ pre_csc_lut[i++].green);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+ intel_de_write_fw(dev_priv,
+
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write_fw(dev_priv,
+
PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ 1 << 24);
+ } while (i++ < 130);
+ }
+
+ intel_de_write_fw(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe,
plane, 0), 0);
+ } else {
+ lut_size = 32;
+
+ /*
+* First 3 planes are HDR, so reduce by 3 to get to the right
+* SDR plane offset
+*/
+ plane = plane - 3;
+
+ intel_de_write_fw(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe,
plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (pre_csc_lut) {
+ for (i = 0; i < lut_size; i++)
+ intel_de_write_fw(dev_priv,
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ pre_csc_lut[i].green);
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 35)
+ intel_de_write_fw(dev_priv,
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ pre_csc_lut[i++].green);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ intel_de_write_fw(dev_priv,
+ PLANE_PRE_CSC_GAMC_DATA(pipe,
plane, 0), v);
+ }
+
+ do {
+ intel_de_write_fw(dev_priv,
PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ 1 << 16);
+ } while (i++ < 34);
+ }
+
+ intel_de_write_fw(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe,
plane, 0), 0);
+ }
+}
+
static void xelpd_plane_load_luts(const struct drm_plane_state *plane_state,
const struct drm_property_blob *blob, bool
is_pre_csc)
{
+ struct drm_color_lut_ext *lut = blob->data;
+
+ if (is_pre_csc)
+ xelpd_program_plane_pre_csc_lut(plane_state, lut, 0);
}
void
[PATCH 24/28] drm/i915: Add register definitions for Plane Post CSC
Add macros to define Plane Post CSC registers
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/i915_reg.h | 73 +
1 file changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 633c0d0cb8f4..ea711be031e7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6244,6 +6244,79 @@ enum skl_power_gate {
#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+/* Display13 Plane Gamma Reg */
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A0x70160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B0x71160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A0x70260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B0x71260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe)_PIPE(pipe,
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A, \
+
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe)_PIPE(pipe,
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A, \
+
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i,
_PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A 0x70164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B 0x71164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A 0x70264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B 0x71264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A, \
+
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A, \
+
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i,
_PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_A 0x701d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_B 0x711d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_A 0x702d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_B 0x712d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_INDEX_ENH_1_A, \
+
_PLANE_POST_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_INDEX_ENH_2_A, \
+
_PLANE_POST_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i,
_PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_A 0x701dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_B 0x711dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_A 0x702dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_B 0x712dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_DATA_ENH_1_A, \
+
_PLANE_POST_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_DATA_ENH_2_A, \
+
_PLANE_POST_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i,
_PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_1_A 0x704d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1_B 0x714d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_A 0x705d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_B 0x715d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_INDEX_1_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_INDEX_2_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_1_A 0x704dc
+#define _PLANE_POST_CSC_GAMC_DATA_1_B 0x714dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_A 0x705dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_B 0x715dc
+#define _PLANE_POST_CSC_GAMC_DATA_1(pipe) _PIPE(pipe,
_PLANE_POST_CSC_GAMC_DATA_1_A, \
+
[PATCH 23/28] drm/i915/color: Add framework to program PRE/POST CSC LUT
From: Chaitanya Kumar Borah
Add framework that will help in loading LUT to Pre/Post CSC color
blocks.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 27 ++
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 85c4b6a9d5f9..0d68f8303502 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -85,6 +85,10 @@ struct intel_color_funcs {
/* Plane CSC*/
void (*load_plane_csc_matrix)(const struct drm_plane_state *plane_state,
const struct drm_property_blob *blob);
+
+ /* Plane Pre/Post CSC */
+ void (*load_plane_luts)(const struct drm_plane_state *plane_state,
+ const struct drm_property_blob *blob, bool
is_pre_csc);
};
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -3775,6 +3779,20 @@ void intel_color_load_plane_csc_matrix(const struct
drm_plane_state *plane_state
i915->display.funcs.color->load_plane_csc_matrix(plane_state,
blob);
}
+static void xelpd_plane_load_luts(const struct drm_plane_state *plane_state,
+ const struct drm_property_blob *blob, bool
is_pre_csc)
+{
+}
+
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state,
+const struct drm_property_blob *blob, bool
is_pre_csc)
+{
+ struct drm_i915_private *i915 = to_i915(plane_state->plane->dev);
+
+ if (i915->display.funcs.color->load_plane_luts)
+ i915->display.funcs.color->load_plane_luts(plane_state, blob,
is_pre_csc);
+}
+
static const struct intel_color_funcs chv_color_funcs = {
.color_check = chv_color_check,
.color_commit_arm = i9xx_color_commit_arm,
@@ -3823,6 +3841,7 @@ static const struct intel_color_funcs tgl_color_funcs = {
.read_csc = icl_read_csc,
.get_config = skl_get_config,
.load_plane_csc_matrix = xelpd_load_plane_csc_matrix,
+ .load_plane_luts = xelpd_plane_load_luts,
};
static const struct intel_color_funcs icl_color_funcs = {
@@ -4053,6 +4072,14 @@ static void apply_colorop(const struct drm_plane_state
*plane_state,
(*plane_color_ctl) |= PLANE_COLOR_PLANE_CSC_ENABLE;
if (state->data && intel_colorop->id == CB_PLANE_CSC)
intel_color_load_plane_csc_matrix(plane_state,
state->data);
+ } else if (colorop->type == DRM_COLOROP_1D_LUT) {
+ if (state->data && intel_colorop->id == CB_PLANE_PRE_CSC_LUT) {
+ (*plane_color_ctl) |= PLANE_COLOR_PRE_CSC_GAMMA_ENABLE;
+ intel_color_load_plane_luts(plane_state, state->data,
true);
+ } else if (state->data && intel_colorop->id ==
CB_PLANE_POST_CSC_LUT) {
+ (*plane_color_ctl) &= ~PLANE_COLOR_PLANE_GAMMA_DISABLE;
+ intel_color_load_plane_luts(plane_state, state->data,
false);
+ }
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index 3f1466f88c11..1830a85a696b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -45,5 +45,7 @@ void intel_program_pipeline(const struct drm_plane_state
*plane_state,
u32 *plane_color_ctl);
void intel_color_load_plane_csc_matrix(const struct drm_plane_state
*plane_state,
const struct drm_property_blob *blob);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state,
+const struct drm_property_blob *blob, bool
is_pre_csc);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 22/28] drm/i915: Add register definitions for Plane Degamma
Add macros to define Plane Degamma registers
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/i915_reg.h | 51 +
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e00557e1a57f..633c0d0cb8f4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3732,6 +3732,7 @@
#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
REG_FIELD_PREP(PLANE_COLOR_CSC_MODE_MASK, 2)
#define PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020
REG_FIELD_PREP(PLANE_COLOR_CSC_MODE_MASK, 3)
#define PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020
REG_FIELD_PREP(PLANE_COLOR_CSC_MODE_MASK, 4)
+#define PLANE_COLOR_PRE_CSC_GAMMA_ENABLE REG_BIT(14)
#define PLANE_COLOR_PLANE_GAMMA_DISABLE REG_BIT(13)
#define PLANE_COLOR_ALPHA_MASK REG_GENMASK(5, 4)
#define PLANE_COLOR_ALPHA_DISABLE
REG_FIELD_PREP(PLANE_COLOR_ALPHA_MASK, 0)
@@ -6243,6 +6244,56 @@ enum skl_power_gate {
#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+/* Display13 Plane Degmma Reg */
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A 0x701d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B 0x711d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A 0x702d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B 0x712d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A, \
+
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A, \
+
_PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i,
_PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
+#define PLANE_PAL_PREC_AUTO_INCREMENT REG_BIT(10)
+
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A 0x701d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B 0x711d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_A 0x702d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_B 0x712d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_DATA_ENH_1_A, \
+
_PLANE_PRE_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_DATA_ENH_2_A, \
+
_PLANE_PRE_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, i)\
+ _MMIO_PLANE_GAMC(plane, i,
_PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_A 0x704d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_B 0x714d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_A 0x705d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_B 0x715d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_INDEX_1_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_INDEX_2_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_1_A 0x704d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1_B 0x714d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_A 0x705d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_B 0x715d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_DATA_1_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_2(pipe) _PIPE(pipe,
_PLANE_PRE_CSC_GAMC_DATA_2_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA(pipe, plane, i)\
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_2(pipe))
+
/* Plane CSC Registers */
#define _PLANE_CSC_RY_GY_1_A 0x70210
#define _PLANE_CSC_RY_GY_2_A 0x70310
--
2.42.0
[PATCH 21/28] drm/i915/color: Add plane CTM callback for TGL and beyond
Add callback for setting CTM block in platforms TGL and beyond
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 79 ++
1 file changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 8dc72ad25700..85c4b6a9d5f9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3688,6 +3688,84 @@ static void icl_read_luts(struct intel_crtc_state
*crtc_state)
}
}
+static void xelpd_load_plane_csc_matrix(const struct drm_plane_state *state,
+ const struct drm_property_blob *blob)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ struct drm_color_ctm *ctm;
+ const u64 *input;
+ u16 coeffs[9] = {};
+ u16 postoff = 0;
+ int i;
+
+ if (!icl_is_hdr_plane(dev_priv, plane) || !blob)
+ return;
+
+ ctm = blob->data;
+ input = ctm->matrix;
+
+ /*
+* Convert fixed point S31.32 input to format supported by the
+* hardware.
+*/
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
+ u64 abs_coeff = ((1ULL << 63) - 1) & input[i];
+
+ /*
+* Clamp input value to min/max supported by
+* hardware.
+*/
+ abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_4_0 - 1);
+
+ /* sign bit */
+ if (CTM_COEFF_NEGATIVE(input[i]))
+ coeffs[i] |= 1 << 15;
+
+ if (abs_coeff < CTM_COEFF_0_125)
+ coeffs[i] |= (3 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 12);
+ else if (abs_coeff < CTM_COEFF_0_25)
+ coeffs[i] |= (2 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 11);
+ else if (abs_coeff < CTM_COEFF_0_5)
+ coeffs[i] |= (1 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 10);
+ else if (abs_coeff < CTM_COEFF_1_0)
+ coeffs[i] |= ILK_CSC_COEFF_FP(abs_coeff, 9);
+ else if (abs_coeff < CTM_COEFF_2_0)
+ coeffs[i] |= (7 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 8);
+ else
+ coeffs[i] |= (6 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 7);
+ }
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0),
+ coeffs[0] << 16 | coeffs[1]);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1),
+ coeffs[2] << 16);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2),
+ coeffs[3] << 16 | coeffs[4]);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3),
+ coeffs[5] << 16);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4),
+ coeffs[6] << 16 | coeffs[7]);
+ intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5),
+ coeffs[8] << 16);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
+ intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
+
+ intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
+ intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
+ intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
+}
+
void intel_color_load_plane_csc_matrix(const struct drm_plane_state
*plane_state,
const struct drm_property_blob *blob)
{
@@ -3744,6 +3822,7 @@ static const struct intel_color_funcs tgl_color_funcs = {
.lut_equal = icl_lut_equal,
.read_csc = icl_read_csc,
.get_config = skl_get_config,
+ .load_plane_csc_matrix = xelpd_load_plane_csc_matrix,
};
static const struct intel_color_funcs icl_color_funcs = {
--
2.42.0
[PATCH 20/28] drm/i915/color: Add callbacks to set plane CTM
From: Chaitanya Kumar Borah
Add callback to intel color functions for setting plane CTM.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 22 ++
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 06268e89125e..8dc72ad25700 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -81,6 +81,10 @@ struct intel_color_funcs {
* Read config other than LUTs and CSCs, before them. Optional.
*/
void (*get_config)(struct intel_crtc_state *crtc_state);
+
+ /* Plane CSC*/
+ void (*load_plane_csc_matrix)(const struct drm_plane_state *plane_state,
+ const struct drm_property_blob *blob);
};
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -3684,6 +3688,15 @@ static void icl_read_luts(struct intel_crtc_state
*crtc_state)
}
}
+void intel_color_load_plane_csc_matrix(const struct drm_plane_state
*plane_state,
+ const struct drm_property_blob *blob)
+{
+ struct drm_i915_private *i915 = to_i915(plane_state->plane->dev);
+
+ if (i915->display.funcs.color->load_plane_csc_matrix)
+ i915->display.funcs.color->load_plane_csc_matrix(plane_state,
blob);
+}
+
static const struct intel_color_funcs chv_color_funcs = {
.color_check = chv_color_check,
.color_commit_arm = i9xx_color_commit_arm,
@@ -3953,6 +3966,15 @@ static void apply_colorop(const struct drm_plane_state
*plane_state,
struct drm_colorop *colorop,
u32 *plane_color_ctl)
{
+ struct drm_colorop_state *state = colorop->state;
+ struct intel_plane_colorop *intel_colorop =
to_intel_plane_colorop(colorop);
+
+ if (colorop->type == DRM_COLOROP_CTM_3X3) {
+ /* TODO: use intel_color_op state data */
+ (*plane_color_ctl) |= PLANE_COLOR_PLANE_CSC_ENABLE;
+ if (state->data && intel_colorop->id == CB_PLANE_CSC)
+ intel_color_load_plane_csc_matrix(plane_state,
state->data);
+ }
}
void intel_program_pipeline(const struct drm_plane_state *plane_state, u32
*plane_color_ctl)
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index bde880370ecc..3f1466f88c11 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -43,5 +43,7 @@ int intel_plane_tf_pipeline_init(struct drm_plane *plane,
struct drm_prop_enum_l
int intel_plane_color_init(struct drm_plane *plane);
void intel_program_pipeline(const struct drm_plane_state *plane_state,
u32 *plane_color_ctl);
+void intel_color_load_plane_csc_matrix(const struct drm_plane_state
*plane_state,
+ const struct drm_property_blob *blob);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 19/28] drm/i915/color: Add framework to set colorop
From: Chaitanya Kumar Borah
Add infrastructure to set colorop. We iterate through all the color ops
in a selected COLOR PIPELINE and set them one by one.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 31 ++
drivers/gpu/drm/i915/display/intel_color.h | 3 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index d6d5e56b4f2c..06268e89125e 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3949,6 +3949,37 @@ struct intel_plane_colorop
*intel_plane_colorop_create(enum intel_color_block id
return colorop;
}
+static void apply_colorop(const struct drm_plane_state *plane_state,
+ struct drm_colorop *colorop,
+ u32 *plane_color_ctl)
+{
+}
+
+void intel_program_pipeline(const struct drm_plane_state *plane_state, u32
*plane_color_ctl)
+{
+ struct drm_colorop *colorop;
+
+ colorop = plane_state->color_pipeline;
+
+ while (colorop) {
+ struct drm_colorop_state *colorop_state;
+
+ if (!colorop)
+ return;
+
+ /* TODO this is probably wrong */
+ colorop_state = colorop->state;
+
+ if (!colorop_state)
+ return;
+
+ if (!colorop_state->bypass)
+ apply_colorop(plane_state, colorop, plane_color_ctl);
+
+ colorop = colorop->next;
+ }
+}
+
int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
drm_prop_enum_list *list)
{
struct intel_plane *intel_plane = to_intel_plane(plane);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index df0e1f6be067..bde880370ecc 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -13,6 +13,7 @@ struct intel_crtc;
struct drm_i915_private;
struct drm_property_blob;
struct drm_plane;
+struct drm_plane_state;
struct drm_prop_enum_list;
enum intel_color_block;
@@ -40,5 +41,7 @@ struct intel_plane_colorop *intel_colorop_alloc(void);
struct intel_plane_colorop *intel_plane_colorop_create(enum intel_color_block
id);
int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
drm_prop_enum_list *list);
int intel_plane_color_init(struct drm_plane *plane);
+void intel_program_pipeline(const struct drm_plane_state *plane_state,
+ u32 *plane_color_ctl);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 18/28] drm/i915/color: Add and attach COLORPIPELINE plane property
From: Chaitanya Kumar Borah
Add supported color pipelines and attach it to plane.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 37 ++
drivers/gpu/drm/i915/display/intel_color.h | 3 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 223cd1ff7291..d6d5e56b4f2c 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -4000,6 +4000,43 @@ int intel_plane_tf_pipeline_init(struct drm_plane
*plane, struct drm_prop_enum_l
return 0;
}
+int intel_plane_color_init(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_property *prop;
+ struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
+ int len = 0;
+ int ret;
+
+ /* Add "Bypass" (i.e. NULL) pipeline */
+ pipelines[len].type = 0;
+ pipelines[len].name = "Bypass";
+ len++;
+
+ /* Add pipeline consisting of transfer functions */
+ ret = intel_plane_tf_pipeline_init(plane, [len]);
+ if (ret)
+ return ret;
+ len++;
+
+ /* Create COLOR_PIPELINE property and attach */
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
+ "COLOR_PIPELINE",
+ pipelines, len);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->color_pipeline_property = prop;
+
+ drm_object_attach_property(>base, prop, 0);
+
+ /* TODO check if needed */
+ if (plane->state)
+ plane->state->color_pipeline = NULL;
+
+ return 0;
+}
+
void intel_color_crtc_init(struct intel_crtc *crtc)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index e0b75dcb1b65..df0e1f6be067 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -16,6 +16,8 @@ struct drm_plane;
struct drm_prop_enum_list;
enum intel_color_block;
+#define MAX_COLOR_PIPELINES 5
+
void intel_color_init_hooks(struct drm_i915_private *i915);
int intel_color_init(struct drm_i915_private *i915);
void intel_color_crtc_init(struct intel_crtc *crtc);
@@ -37,5 +39,6 @@ void intel_color_assert_luts(const struct intel_crtc_state
*crtc_state);
struct intel_plane_colorop *intel_colorop_alloc(void);
struct intel_plane_colorop *intel_plane_colorop_create(enum intel_color_block
id);
int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
drm_prop_enum_list *list);
+int intel_plane_color_init(struct drm_plane *plane);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 17/28] drm/i915: Define segmented Lut and add capabilities to colorop
This defines the lut segments and create the color pipeline
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/intel_color.c | 109 +
1 file changed, 109 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index e223edbe4c13..223cd1ff7291 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3811,6 +3811,105 @@ static const struct intel_color_funcs ilk_color_funcs =
{
.get_config = ilk_get_config,
};
+static const struct drm_color_lut_range xelpd_degamma_hdr[] = {
+ /* segment 1 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 128,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 0, .end = (1 << 24) - 1,
+ .min = 0, .max = (1 << 24) - 1,
+ },
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = (1 << 24) - 1, .end = 1 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+ /* Segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 1 << 24, .end = 3 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 3 << 24, .end = 7 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ }
+};
+
+/* FIXME input bpc? */
+static const struct drm_color_lut_range xelpd_gamma_hdr[] = {
+ /*
+* ToDo: Add Segment 1
+* There is an optional fine segment added with 9 lut values
+* Will be added later
+*/
+
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 32,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 0, .end = (1 << 24) - 1,
+ .min = 0, .max = (1 << 24) - 1,
+ },
+ /* segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = (1 << 24) - 1, .end = 1 << 24,
+ .min = 0, .max = 1 << 24,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 1 << 24, .end = 3 << 24,
+ .min = 0, .max = (3 << 24),
+ },
+ /* Segment 5 */
+ {
+ .flags = (DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 3 << 24, .end = 7 << 24,
+ .min = 0, .max = (7 << 24),
+ },
+};
+
/* TODO: Move to another file */
struct intel_plane_colorop *intel_colorop_alloc(void)
{
@@ -3865,6 +3964,11 @@ int intel_plane_tf_pipeline_init(struct drm_plane
*plane, struct drm_prop_enum_l
if (ret)
return ret;
+ if (icl_is_hdr_plane(i915, to_intel_plane(plane)->id)) {
+ drm_colorop_lutcaps_init(>base, plane,
xelpd_degamma_hdr,
+sizeof(xelpd_degamma_hdr));
+ }
+
list->type = colorop->base.base.id;
[PATCH 16/28] drm/i915/color: Create a transfer function color pipeline
From: Chaitanya Kumar Borah
Add a color pipeline with three colorops in the sequence
1D LUT - CTM - 1D LUT
This pipeline can be used to do any color space conversion or HDR
tone mapping
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 42 ++
drivers/gpu/drm/i915/display/intel_color.h | 3 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index e187135d4363..e223edbe4c13 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -28,6 +28,7 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_dsb.h"
+#include "skl_universal_plane.h"
struct intel_color_funcs {
int (*color_check)(struct intel_crtc_state *crtc_state);
@@ -3849,6 +3850,47 @@ struct intel_plane_colorop
*intel_plane_colorop_create(enum intel_color_block id
return colorop;
}
+int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
drm_prop_enum_list *list)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct intel_plane_colorop *colorop;
+ struct drm_device *dev = plane->dev;
+ struct drm_i915_private *i915 = to_i915(dev);
+ int ret;
+ struct drm_colorop *prev_op;
+
+ colorop = intel_plane_colorop_create(CB_PLANE_PRE_CSC_LUT);
+
+ ret = drm_colorop_init(dev, >base, plane, DRM_COLOROP_1D_LUT);
+ if (ret)
+ return ret;
+
+ list->type = colorop->base.base.id;
+ list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d",
colorop->base.base.id);
+
+ /* TODO: handle failures and clean up*/
+ prev_op = >base;
+
+ if (icl_is_hdr_plane(i915, intel_plane->id)) {
+ colorop = intel_plane_colorop_create(CB_PLANE_CSC);
+ ret = drm_colorop_init(dev, >base, plane,
DRM_COLOROP_CTM_3X3);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, >base);
+ prev_op = >base;
+ }
+
+ colorop = intel_plane_colorop_create(CB_PLANE_POST_CSC_LUT);
+ ret = drm_colorop_init(dev, >base, plane, DRM_COLOROP_1D_LUT);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, >base);
+
+ return 0;
+}
+
void intel_color_crtc_init(struct intel_crtc *crtc)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index d03dad425671..e0b75dcb1b65 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -12,6 +12,8 @@ struct intel_crtc_state;
struct intel_crtc;
struct drm_i915_private;
struct drm_property_blob;
+struct drm_plane;
+struct drm_prop_enum_list;
enum intel_color_block;
void intel_color_init_hooks(struct drm_i915_private *i915);
@@ -34,5 +36,6 @@ bool intel_color_lut_equal(const struct intel_crtc_state
*crtc_state,
void intel_color_assert_luts(const struct intel_crtc_state *crtc_state);
struct intel_plane_colorop *intel_colorop_alloc(void);
struct intel_plane_colorop *intel_plane_colorop_create(enum intel_color_block
id);
+int intel_plane_tf_pipeline_init(struct drm_plane *plane, struct
drm_prop_enum_list *list);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 15/28] drm/i915/color: Add helper to create intel colorop
From: Chaitanya Kumar Borah
Add intel colorop create helper
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 14 ++
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 949c2efe105f..e187135d4363 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3835,6 +3835,20 @@ struct intel_plane_colorop *intel_colorop_alloc(void)
return colorop;
}
+struct intel_plane_colorop *intel_plane_colorop_create(enum intel_color_block
id)
+{
+ struct intel_plane_colorop *colorop;
+
+ colorop = intel_colorop_alloc();
+
+ if (IS_ERR(colorop))
+ return colorop;
+
+ colorop->id = id;
+
+ return colorop;
+}
+
void intel_color_crtc_init(struct intel_crtc *crtc)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index e111d115724c..d03dad425671 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -12,6 +12,7 @@ struct intel_crtc_state;
struct intel_crtc;
struct drm_i915_private;
struct drm_property_blob;
+enum intel_color_block;
void intel_color_init_hooks(struct drm_i915_private *i915);
int intel_color_init(struct drm_i915_private *i915);
@@ -32,5 +33,6 @@ bool intel_color_lut_equal(const struct intel_crtc_state
*crtc_state,
bool is_pre_csc_lut);
void intel_color_assert_luts(const struct intel_crtc_state *crtc_state);
struct intel_plane_colorop *intel_colorop_alloc(void);
+struct intel_plane_colorop *intel_plane_colorop_create(enum intel_color_block
id);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 14/28] drm/i915/color: Add helper to allocate intel colorop
From: Chaitanya Kumar Borah
Add helper to allocate memory for intel colorop
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_color.c | 25 ++
drivers/gpu/drm/i915/display/intel_color.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index ca7112b32cb3..949c2efe105f 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3810,6 +3810,31 @@ static const struct intel_color_funcs ilk_color_funcs = {
.get_config = ilk_get_config,
};
+/* TODO: Move to another file */
+struct intel_plane_colorop *intel_colorop_alloc(void)
+{
+ struct intel_plane_colorop *colorop;
+ struct intel_plane_colorop_state *colorop_state;
+
+ colorop = kzalloc(sizeof(*colorop), GFP_KERNEL);
+ if (!colorop)
+ return ERR_PTR(-ENOMEM);
+
+ colorop_state = kzalloc(sizeof(*colorop_state), GFP_KERNEL);
+ if (!colorop_state) {
+ kfree(colorop);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* TODO: Add color op reset
+* intel_colorop_state_reset(plane_state, plane);
+*/
+
+ colorop->base.state = _state->uapi;
+
+ return colorop;
+}
+
void intel_color_crtc_init(struct intel_crtc *crtc)
{
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h
b/drivers/gpu/drm/i915/display/intel_color.h
index 8ecd36149def..e111d115724c 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -31,5 +31,6 @@ bool intel_color_lut_equal(const struct intel_crtc_state
*crtc_state,
const struct drm_property_blob *blob2,
bool is_pre_csc_lut);
void intel_color_assert_luts(const struct intel_crtc_state *crtc_state);
+struct intel_plane_colorop *intel_colorop_alloc(void);
#endif /* __INTEL_COLOR_H__ */
--
2.42.0
[PATCH 13/28] drm/i915: Add intel_color_op
From: Chaitanya Kumar Borah
Add data structure to store intel specific details of colorop
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
.../gpu/drm/i915/display/intel_display_types.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 01eb6e4e6049..edc61ea0fe29 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1606,6 +1606,8 @@ struct intel_watermark_params {
#define to_intel_plane(x) container_of(x, struct intel_plane, base)
#define to_intel_plane_state(x) container_of(x, struct intel_plane_state, uapi)
#define intel_fb_obj(x) ((x) ? to_intel_bo((x)->obj[0]) : NULL)
+#define to_intel_plane_colorop(x) container_of(x, struct intel_plane_colorop,
base)
+#define to_intel_colorop_state(x) container_of(x, struct
intel_plane_colorop_state, uapi)
struct intel_hdmi {
i915_reg_t hdmi_reg;
@@ -1915,6 +1917,21 @@ struct intel_dp_mst_encoder {
struct intel_connector *connector;
};
+struct intel_plane_colorop {
+ struct drm_colorop base;
+ enum intel_color_block id;
+};
+
+struct intel_plane_colorop_state {
+ struct drm_colorop_state uapi;
+
+ /* TODO: Add hw implementation */
+ struct {
+ bool active, enable;
+ struct drm_property_blob *data;
+ } hw;
+};
+
static inline struct intel_encoder *
intel_attached_encoder(struct intel_connector *connector)
{
--
2.42.0
[PATCH 12/28] drm/i915: Add identifiers for intel color blocks
From: Chaitanya Kumar Borah
Add macros to identify intel color blocks. It will help
in mapping drm_color_ops to intel color HW blocks
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display_limits.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_limits.h
b/drivers/gpu/drm/i915/display/intel_display_limits.h
index 5126d0b5ae5d..67ceb79309f2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_limits.h
+++ b/drivers/gpu/drm/i915/display/intel_display_limits.h
@@ -121,4 +121,17 @@ enum hpd_pin {
HPD_NUM_PINS
};
+/*
+ * Intel Color Blocks
+ *
+ */
+
+enum intel_color_block {
+ CB_PLANE_PRE_CSC_LUT,
+ CB_PLANE_CSC,
+ CB_PLANE_POST_CSC_LUT,
+
+ I915_MAX_CB
+};
+
#endif /* __INTEL_DISPLAY_LIMITS_H__ */
--
2.42.0
[PATCH 11/28] drm: Define helper for adding capability property for 1D LUT
This adds helper functions to create 1D Lut color block
capabilities. It exposes the hardware block as segments
which are converted to blob and passed in the property.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_colorop.c | 24 +++-
include/drm/drm_colorop.h | 4 +++-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index cfdc8e751012..98aef26c0c55 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -43,7 +43,6 @@ static const struct drm_prop_enum_list
drm_colorop_curve_1d_type_enum_list[] = {
};
/* Init Helpers */
-__maybe_unused
static int drm_create_colorop_capability_prop(struct drm_device *dev,
struct drm_colorop *colorop,
struct drm_property_blob *blob)
@@ -65,6 +64,29 @@ static int drm_create_colorop_capability_prop(struct
drm_device *dev,
return 0;
}
+int drm_colorop_lutcaps_init(struct drm_colorop *colorop,
+struct drm_plane *plane,
+const struct drm_color_lut_range *ranges,
+size_t length)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_property_blob *blob;
+
+ /* Create Color Caps property for 1D LUT */
+ if (colorop->type != DRM_COLOROP_1D_LUT)
+ return -EINVAL;
+
+ if (WARN_ON(length == 0 || length % sizeof(ranges[0]) != 0))
+ return -EINVAL;
+
+ blob = drm_property_create_blob(plane->dev, length, ranges);
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
+
+ return drm_create_colorop_capability_prop(dev, colorop, blob);
+}
+EXPORT_SYMBOL(drm_colorop_lutcaps_init);
+
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
struct drm_plane *plane, enum drm_colorop_type type)
{
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index f417e109c40a..d15d5b489401 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -233,7 +233,9 @@ static inline struct drm_colorop *drm_colorop_find(struct
drm_device *dev,
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
struct drm_plane *plane, enum drm_colorop_type type);
-
+int drm_colorop_lutcaps_init(struct drm_colorop *colorop, struct drm_plane
*plane,
+const struct drm_color_lut_range *ranges,
+size_t length);
struct drm_colorop_state *
drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
--
2.42.0
[PATCH 10/28] drm: Define helper to create color ops capability property
Add a helper to create capability property for a colorop
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/drm_colorop.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 4d57eaef04aa..cfdc8e751012 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -43,6 +43,27 @@ static const struct drm_prop_enum_list
drm_colorop_curve_1d_type_enum_list[] = {
};
/* Init Helpers */
+__maybe_unused
+static int drm_create_colorop_capability_prop(struct drm_device *dev,
+ struct drm_colorop *colorop,
+ struct drm_property_blob *blob)
+{
+ struct drm_property *prop = NULL;
+
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB |
+ DRM_MODE_PROP_ATOMIC |
+ DRM_MODE_PROP_IMMUTABLE,
+ "HW_CAPS", 1);
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->hw_caps_property = prop;
+ drm_object_attach_property(>base,
+ colorop->hw_caps_property,
+ blob->base.id);
+
+ return 0;
+}
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
struct drm_plane *plane, enum drm_colorop_type type)
--
2.42.0
[PATCH 09/28] drm: Add Color ops capability property
Add capability property which a colorop can expose it's
hardware's abilities. It's a blob property that can be
filled with respective data structures depending on the
colorop. The user space is expected to read this property
and program the colorop accordingly.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
include/drm/drm_colorop.h | 13 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9f6a3a1c8020..95f1df73209c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -770,6 +770,9 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->curve_1d_type;
} else if (property == colorop->data_property) {
*val = (state->data) ? state->data->base.id : 0;
+ } else if (property == colorop->hw_caps_property) {
+ *val = state->hw_caps ?
+ state->hw_caps->base.id : 0;
} else {
return -EINVAL;
}
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 5b8c36538491..f417e109c40a 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -59,6 +59,12 @@ struct drm_colorop_state {
*/
enum drm_colorop_curve_1d_type curve_1d_type;
+ /**
+* @hw_caps:
+*
+*/
+ struct drm_property_blob *hw_caps;
+
/**
* @data:
*
@@ -167,6 +173,13 @@ struct drm_colorop {
*/
struct drm_property *bypass_property;
+ /**
+* @hwlut_caps_property:
+*
+* Property to expose hardware lut capbilities.
+*/
+ struct drm_property *hw_caps_property;
+
/**
* @curve_1d_type:
*
--
2.42.0
[PATCH 08/28] drm: Add Color lut range attributes
This defines a new structure to define color lut ranges,
along with related macro definitions and enums. This will help
describe segmented lut ranges/PWL LUTs in the hardware.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
include/uapi/drm/drm_mode.h | 58 +
1 file changed, 58 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index af67f32e0087..376498715d0e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1014,6 +1014,64 @@ struct hdr_output_metadata {
DRM_MODE_PAGE_FLIP_ASYNC | \
DRM_MODE_PAGE_FLIP_TARGET)
+/**
+ * DRM_MODE_LUT_INTERPOLATE
+ *
+ * linearly interpolate between the points
+ */
+#define DRM_MODE_LUT_INTERPOLATE BIT(0)
+
+/**
+ * DRM_MODE_LUT_REUSE_LAST
+ *
+ * the last value of the previous range is the
+ * first value of the current range.
+ */
+#define DRM_MODE_LUT_REUSE_LAST BIT(1)
+
+/**
+ * DRM_MODE_LUT_NON_DECREASING
+ *
+ * the curve must be non-decreasing
+ */
+#define DRM_MODE_LUT_NON_DECREASING BIT(2)
+
+/**
+ * DRM_MODE_LUT_REFLECT_NEGATIVE
+ *
+ * the curve is reflected across origin for negative inputs
+ */
+#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(3)
+
+/**
+ * DRM_MODE_LUT_SINGLE_CHANNEL
+ *
+ * the same curve (red) is used for blue and green channels as well
+ */
+#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(4)
+
+/**
+ * struct drm_color_lut_range
+ *
+ * structure to advertise capability of a color hardware
+ * block that accepts LUT values. It can represent LUTs with
+ * varied number of entries and distributions
+ * (Multi segmented, Logarithmic etc).
+ */
+
+struct drm_color_lut_range {
+ /* DRM_MODE_LUT_* */
+ __u32 flags;
+ /* number of points on the curve */
+ __u16 count;
+ /* input/output bits per component */
+ __u8 input_bpc, output_bpc;
+ /* input start/end values */
+ __s32 start, end;
+ /* output min/max values */
+ __s32 min, max;
+};
+
/*
* Request a page flip on the specified crtc.
*
--
2.42.0
[PATCH 07/28] drm: Add 1D LUT color op
From: Chaitanya Kumar Borah
Add support for color ops that can be programmed
by 1 dimensional Look Up Tables.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
drivers/gpu/drm/drm_colorop.c | 2 +-
include/uapi/drm/drm_mode.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c54b0d6c133e..9f6a3a1c8020 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -719,6 +719,9 @@ static int drm_atomic_color_set_data_property(struct
drm_colorop *colorop,
case DRM_COLOROP_CTM_3X3:
size = sizeof(struct drm_color_ctm);
break;
+ case DRM_COLOROP_1D_LUT:
+ elem_size = sizeof(struct drm_color_lut_ext);
+ break;
default:
/* should never get here */
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 6bae6dc8e54b..4d57eaef04aa 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
0);
/* data */
- if (type == DRM_COLOROP_CTM_3X4 || type == DRM_COLOROP_CTM_3X3) {
+ if (type == DRM_COLOROP_CTM_3X4 || type == DRM_COLOROP_CTM_3X3 ||
DRM_COLOROP_1D_LUT) {
prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
DRM_MODE_PROP_BLOB,
"DATA", 0);
if (!prop)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index bbc5be97c80f..af67f32e0087 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -885,6 +885,7 @@ struct drm_color_lut_ext {
enum drm_colorop_type {
DRM_COLOROP_1D_CURVE,
+ DRM_COLOROP_1D_LUT,
DRM_COLOROP_CTM_3X3,
DRM_COLOROP_CTM_3X4,
};
--
2.42.0
[PATCH 06/28] drm: Add Enhanced LUT precision structure
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values.
Signed-off-by: Uma Shankar
Signed-off-by: Chaitanya Kumar Borah
---
include/drm/drm_color_mgmt.h | 23 +++
include/uapi/drm/drm_mode.h | 17 +
2 files changed, 40 insertions(+)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index ed81741036d7..72a08b5f7d14 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -50,6 +50,29 @@ static inline u32 drm_color_lut_extract(u32 user_input, int
bit_precision)
(1 << 16) - 1);
}
+/* TODO: Add uapi documentation
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+static inline u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision)
+{
+ u64 val = user_input & 0x;
+ u32 max;
+
+ if (bit_precision > 32)
+ return 0;
+
+ max = 0x >> (32 - bit_precision);
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 32) {
+ val += 1UL << (32 - bit_precision - 1);
+ val >>= 32 - bit_precision;
+ }
+
+ return ((user_input & 0x) |
+ clamp_val(val, 0, max));
+}
+
u64 drm_color_ctm_s31_32_to_qm_n(u64 user_input, u32 m, u32 n);
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 68696253867e..bbc5be97c80f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -866,6 +866,23 @@ struct drm_color_lut {
__u16 reserved;
};
+/**
+ * struct drm_color_lut_ext - Represents high precision lut values
+ *
+ * Creating 64 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+ /*
+* Data is U32.32 fixed point format.
+*/
+ __u64 red;
+ __u64 green;
+ __u64 blue;
+ __u64 reserved;
+};
+
enum drm_colorop_type {
DRM_COLOROP_1D_CURVE,
DRM_COLOROP_CTM_3X3,
--
2.42.0
[PATCH 05/28] drm: Add support for 3x3 CTM
From: Chaitanya Kumar Borah
Add support for 3x3 Color Transformation Matrices in Color Pipeline.
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
drivers/gpu/drm/drm_colorop.c | 2 +-
include/uapi/drm/drm_mode.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index e7bf1fb054af..c54b0d6c133e 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -716,6 +716,9 @@ static int drm_atomic_color_set_data_property(struct
drm_colorop *colorop,
case DRM_COLOROP_CTM_3X4:
size = sizeof(struct drm_color_ctm_3x4);
break;
+ case DRM_COLOROP_CTM_3X3:
+ size = sizeof(struct drm_color_ctm);
+ break;
default:
/* should never get here */
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 462ffec42cdf..6bae6dc8e54b 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -107,7 +107,7 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
0);
/* data */
- if (type == DRM_COLOROP_CTM_3X4) {
+ if (type == DRM_COLOROP_CTM_3X4 || type == DRM_COLOROP_CTM_3X3) {
prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
DRM_MODE_PROP_BLOB,
"DATA", 0);
if (!prop)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f16318f1785f..68696253867e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -868,6 +868,7 @@ struct drm_color_lut {
enum drm_colorop_type {
DRM_COLOROP_1D_CURVE,
+ DRM_COLOROP_CTM_3X3,
DRM_COLOROP_CTM_3X4,
};
--
2.42.0
[PATCH 04/28] drm: Fix error logging in set Color Pipeline
From: Chaitanya Kumar Borah
Fix error logging in set Color Pipeline
Note: This patch can be squashed with the following patch
("drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE") [1]
[1] https://patchwork.freedesktop.org/patch/566623/?series=123446=3
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 64657d961755..e7bf1fb054af 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -570,14 +570,14 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == plane->color_encoding_property) {
if (file_priv->plane_color_pipeline) {
drm_dbg_atomic(dev,
- "Setting COLOR_PIPELINE plane property
not permitted when DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set\n");
+ "Setting COLOR_ENCODING plane property
not permitted when DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set\n");
return -EINVAL;
}
state->color_encoding = val;
} else if (property == plane->color_range_property) {
if (file_priv->plane_color_pipeline) {
drm_dbg_atomic(dev,
- "Setting COLOR_PIPELINE plane property
not permitted when DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set\n");
+ "Setting COLOR_RANGE plane property not
permitted when DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set\n");
return -EINVAL;
}
state->color_range = val;
--
2.42.0
[PATCH 03/28] drm: handle NULL next colorop in drm_colorop_set_next_property
From: Chaitanya Kumar Borah
In scenarios, where there is only one colorop in a colorpipeline,
the user of the helper drm_colorop_set_next_property could use it
to set the next colorop as NULL explicitly. Make the helper handle
this case.
Note: This patch can be squashed with following patch
("drm/colorop: Add NEXT property") [1]
[1] https://patchwork.freedesktop.org/patch/566588/?series=123446=3
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/drm_colorop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 67e6efc90803..462ffec42cdf 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -286,7 +286,7 @@ void drm_colorop_set_next_property(struct drm_colorop
*colorop, struct drm_color
drm_object_property_set_value(>base,
colorop->next_property,
- next->base.id);
+ next ? next->base.id : 0);
colorop->next = next;
}
EXPORT_SYMBOL(drm_colorop_set_next_property);
--
2.42.0
[PATCH 02/28] drm: Add missing function declarations
From: Chaitanya Kumar Borah
add missing declarations to avoid warnings.
Note: This patch should be squashed with patches it fixes
in the colorop series by Harry [1]
("drm/colorop: Introduce new drm_colorop mode object") [2]
("drm/plane: Add COLOR PIPELINE property") [3]
[1] https://patchwork.freedesktop.org/series/123446/
[2] https://patchwork.freedesktop.org/patch/566617/?series=123446=3
[3] https://patchwork.freedesktop.org/patch/566616/?series=123446=3
Signed-off-by: Chaitanya Kumar Borah
---
include/drm/drm_atomic.h | 3 +++
include/drm/drm_colorop.h | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 898b02689d6d..5cf025895baf 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -847,6 +847,9 @@ drm_atomic_add_affected_connectors(struct drm_atomic_state
*state,
int __must_check
drm_atomic_add_affected_planes(struct drm_atomic_state *state,
struct drm_crtc *crtc);
+int __must_check
+drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
+struct drm_plane *plane);
int __must_check drm_atomic_check_only(struct drm_atomic_state *state);
int __must_check drm_atomic_commit(struct drm_atomic_state *state);
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index faca6eba10e1..5b8c36538491 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -249,7 +249,8 @@ const char *drm_get_color_pipeline_name(struct drm_colorop
*colorop);
const char *drm_get_colorop_type_name(enum drm_colorop_type type);
const char *drm_get_colorop_curve_1d_type_name(enum drm_colorop_curve_1d_type
type);
-
+void drm_colorop_destroy_state(struct drm_colorop *colorop,
+ struct drm_colorop_state *state);
void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next);
uint32_t drm_colorop_get_next_property(struct drm_colorop *colorop);
struct drm_colorop *drm_colorop_get_next(struct drm_colorop *colorop);
--
2.42.0
[PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
From: Harry Wentland This is a squashed patch based on a series sent out by Harry wentland. It contains all the changes in the series(v3) currently under review below. https://patchwork.freedesktop.org/patch/566614/?series=123446=3 This patch lays the ground work for incremental changes and Intel specific pipeline changes. NOTE: This patch is not meant for review. Any review related to this patch should be done on the original series. In order not to diverge the discussion from the main series. Signed-off-by: Harry Wentland Signed-off-by: Chaitanya Kumar Borah Signed-off-by: Uma Shankar --- Documentation/gpu/rfc/color_pipeline.rst | 352 drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_atomic.c | 147 drivers/gpu/drm/drm_atomic_helper.c | 12 + drivers/gpu/drm/drm_atomic_state_helper.c | 5 + drivers/gpu/drm/drm_atomic_uapi.c | 161 drivers/gpu/drm/drm_colorop.c | 292 +++ drivers/gpu/drm/drm_ioctl.c | 7 + drivers/gpu/drm/drm_mode_config.c | 7 + drivers/gpu/drm/tests/Makefile| 4 +- drivers/gpu/drm/tests/drm_fixp_test.c | 69 ++ drivers/gpu/drm/vkms/Kconfig | 5 + drivers/gpu/drm/vkms/Makefile | 4 +- drivers/gpu/drm/vkms/tests/.kunitconfig | 4 + drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 355 drivers/gpu/drm/vkms/vkms_colorop.c | 115 +++ drivers/gpu/drm/vkms/vkms_composer.c | 117 ++- drivers/gpu/drm/vkms/vkms_drv.h | 8 + drivers/gpu/drm/vkms/vkms_luts.c | 802 ++ drivers/gpu/drm/vkms/vkms_luts.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 2 + include/drm/drm_atomic.h | 84 ++ include/drm/drm_atomic_uapi.h | 3 + include/drm/drm_colorop.h | 258 ++ include/drm/drm_file.h| 7 + include/drm/drm_fixed.h | 18 + include/drm/drm_mode_config.h | 18 + include/drm/drm_plane.h | 10 + include/uapi/drm/drm.h| 18 + include/uapi/drm/drm_mode.h | 6 + 30 files changed, 2899 insertions(+), 4 deletions(-) create mode 100644 Documentation/gpu/rfc/color_pipeline.rst create mode 100644 drivers/gpu/drm/drm_colorop.c create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h create mode 100644 include/drm/drm_colorop.h diff --git a/Documentation/gpu/rfc/color_pipeline.rst b/Documentation/gpu/rfc/color_pipeline.rst new file mode 100644 index ..efc70570a592 --- /dev/null +++ b/Documentation/gpu/rfc/color_pipeline.rst @@ -0,0 +1,352 @@ + +Linux Color Pipeline API + + +What problem are we solving? + + +We would like to support pre-, and post-blending complex color +transformations in display controller hardware in order to allow for +HW-supported HDR use-cases, as well as to provide support to +color-managed applications, such as video or image editors. + +It is possible to support an HDR output on HW supporting the Colorspace +and HDR Metadata drm_connector properties, but that requires the +compositor or application to render and compose the content into one +final buffer intended for display. Doing so is costly. + +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other +operations to support color transformations. These operations are often +implemented in fixed-function HW and therefore much more power efficient than +performing similar operations via shaders or CPU. + +We would like to make use of this HW functionality to support complex color +transformations with no, or minimal CPU or shader load. + + +How are other OSes solving this problem? + + +The most widely supported use-cases regard HDR content, whether video or +gaming. + +Most OSes will specify the source content format (color gamut, encoding transfer +function, and other metadata, such as max and average light levels) to a driver. +Drivers will then program their fixed-function HW accordingly to map from a +source content buffer's space to a display's space. + +When fixed-function HW is not available the compositor will assemble a shader to +ask the GPU to perform the transformation from the source content format to the +display's format. + +A compositor's mapping function and a driver's mapping function are usually +entirely separate concepts. On OSes where a HW vendor has no insight into
[PATCH 00/28] Plane Color Pipeline support for Intel platforms
This series intends to add support for Plane Color Management for Intel platforms. This is based on the design which has been agreed upon by the community. Series implementing the design for generic DRM core has been sent out by Harry Wentland and is under review below: https://patchwork.freedesktop.org/series/123446/ The base work of above series is squashed under 1 patch and support for Intel platform is added on top of it. Any reviews on the original core design is expected to be done in Harry's series to avoid any forking of the discussion. We have added some changes/fixes to the Harry's core DRM changes, being put up as separate patches on top of squashed patch. These are expected to get included in the main series from Harry once agreed upon. Changes added on core design: 1. Below patches implement some fixes on original series drm: Add missing function declarations drm: handle NULL next colorop in drm_colorop_set_next_property drm: Fix error logging in set Color Pipeline 2. Implemented a HW capability property to expose segmented luts. drm: Add Color lut range attributes drm: Add Color ops capability property drm: Define helper to create color ops capability property drm: Define helper for adding capability property for 1D LUT This helps in generically defining the hardware lut capabilities, lut distribution, precision, segmented or PWL LUTS. 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: drm: Add Enhanced LUT precision structure drm: Add support for 3x3 CTM drm: Add 1D LUT color op On top of this base work for DRM core plane color pipeline design, implementation is done for Intel hardware platforms. Below patches include the same: drm/i915: Add identifiers for intel color blocks drm/i915: Add intel_color_op drm/i915/color: Add helper to allocate intel colorop drm/i915/color: Add helper to create intel colorop drm/i915/color: Create a transfer function color pipeline drm/i915/color: Add and attach COLORPIPELINE plane property drm/i915/color: Add framework to set colorop drm/i915/color: Add callbacks to set plane CTM drm/i915/color: Add framework to program PRE/POST CSC LUT FIXME: force disable legacy plane color properties for TGL and beyond drm/i915/color: Enable Plane Color Pipelines drm/i915: Define segmented Lut and add capabilities to colorop drm/i915/color: Add plane CTM callback for TGL and beyond drm/i915: Add register definitions for Plane Degamma drm/i915: Add register definitions for Plane Post CSC drm/i915/color: Program Pre-CSC registers drm/i915/xelpd: Program Plane Post CSC Registers Bhanu from Intel will be sending out the igt changes to help test the color pipeline implementation based on the current igt changes sent out by Harry. https://patchwork.freedesktop.org/series/123448/ Planned Next Steps: 1. Work with Harry and community and get DRM core changes for color pipeline merged. 2. Implement pipe color management (post blending) based on the current color pipeline design. 3. Work with compositor maintainers to get color processing implemented using display hardware, thereby avoid any GL or GPU shaders. Thanks to all the community maintainers and contributors who have helped to get this support in upstream Linux. Looking forward to collaborate, work together and get this merged. Cc: Ville Syrjala Cc: Pekka Paalanen Cc: Simon Ser Cc: Harry Wentland Cc: Melissa Wen Cc: Jonas Ådahl Cc: Sebastian Wick Cc: Shashank Sharma Cc: Alexander Goins Cc: Joshua Ashton Cc: Michel Dänzer Cc: Aleix Pol Cc: Xaver Hugl Cc: Victoria Brekenfeld Cc: Sima Cc: Naseer Ahmed Cc: Christopher Braga Cc: Abhinav Kumar Cc: Arthur Grillo Cc: Hector Martin Cc: Liviu Dudau Cc: Sasha McIntosh Cc: Chaitanya Kumar Borah Chaitanya Kumar Borah (16): drm: Add missing function declarations drm: handle NULL next colorop in drm_colorop_set_next_property drm: Fix error logging in set Color Pipeline drm: Add support for 3x3 CTM drm: Add 1D LUT color op drm/i915: Add identifiers for intel color blocks drm/i915: Add intel_color_op drm/i915/color: Add helper to allocate intel colorop drm/i915/color: Add helper to create intel colorop drm/i915/color: Create a transfer function color pipeline drm/i915/color: Add and attach COLORPIPELINE plane property drm/i915/color: Add framework to set colorop drm/i915/color: Add callbacks to set plane CTM drm/i915/color: Add framework to program PRE/POST CSC LUT FIXME: force disable legacy plane color properties for TGL and beyond drm/i915/color: Enable Plane Color Pipelines Harry Wentland (1): [NOT FOR REVIEW] drm: color pipeline base work Uma Shankar (11): drm: Add Enhanced LUT precision structure drm: Add Color lut range attributes drm: Add Color ops capability property drm: Define helper to create color ops capability property drm: Define helper for adding capability property for 1D LUT drm/i915: Define segmented Lut and add capabilities to colorop drm/i915/color: Add plane CTM
[PATCH v3] drm: drm_crtc: correct some comments
Fix some typos and punctuation. Signed-off-by: Randy Dunlap Cc: Alex Deucher Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann --- v2: s/instances/instance/ (Alex) v3: rebase and resend; add more Cc:s drivers/gpu/drm/drm_crtc.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff -- a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -61,13 +61,13 @@ * to one or more _encoder, which are then each connected to one * _connector. * - * To create a CRTC, a KMS drivers allocates and zeroes an instances of + * To create a CRTC, a KMS driver allocates and zeroes an instance of * drm_crtc (possibly as part of a larger structure) and registers it * with a call to drm_crtc_init_with_planes(). * - * The CRTC is also the entry point for legacy modeset operations, see - * _crtc_funcs.set_config, legacy plane operations, see - * _crtc_funcs.page_flip and _crtc_funcs.cursor_set2, and other legacy + * The CRTC is also the entry point for legacy modeset operations (see + * _crtc_funcs.set_config), legacy plane operations (see + * _crtc_funcs.page_flip and _crtc_funcs.cursor_set2), and other legacy * operations like _crtc_funcs.gamma_set. For atomic drivers all these * features are controlled through _property and * _mode_config_funcs.atomic_check.
Re: [PATCH v3 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
* Rob Herring [240212 13:51]:
> On Mon, Feb 12, 2024 at 12:30:12PM +0100, Krzysztof Kozlowski wrote:
> > On 12/02/2024 09:17, Tony Lindgren wrote:
> > > usage: yamllint [-h] [-] [-c CONFIG_FILE | -d CONFIG_DATA] [--list-files]
> > > [-f {parsable,standard,colored,github,auto}] [-s] [--no-warnings] [-v]
> > > [FILE_OR_DIR ...]
> > > yamllint: error: one of the arguments FILE_OR_DIR - is required
> > > CHKDT Documentation/devicetree/bindings/processed-schema.json
> > > SCHEMA Documentation/devicetree/bindings/processed-schema.json
> > >
> > > After removing the ">2&1" from the Makefile, there's some more info:
> > >
> > > yamllint: error: one of the arguments FILE_OR_DIR - is required
> > >
> > > Where DT_SCHEMA_FILES ends up empty. I guess dt_binding_check needs
> > > to be now run with just:
> > >
> > > $ make dt_binding_check DT_SCHEMA_FILES=toshiba,tc358775.yaml
> > >
> >
> > Yes, since June last year. Rob later brought (in July) backwards
> > compatible way, but apparently something changed now in Makefile.
>
> It broke in 6.8-rc1. I have a fix in my tree which I'll send to Linus
> this week.
OK good to hear, thanks!
Tony
Re: [PATCH 2/7] fbdev: Do not include in header
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.8-rc4 next-20240212]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/drm-nouveau-Include-linux-backlight-h/20240212-181930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240212101712.23675-3-tzimmermann%40suse.de
patch subject: [PATCH 2/7] fbdev: Do not include in header
config: powerpc-ppc6xx_defconfig
(https://download.01.org/0day-ci/archive/20240213/202402131349.eg8dj3mb-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240213/202402131349.eg8dj3mb-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402131349.eg8dj3mb-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/macintosh/via-pmu-backlight.c: In function
'__pmu_backlight_update_status':
drivers/macintosh/via-pmu-backlight.c:74:21: error: implicit declaration of
function 'backlight_get_brightness'; did you mean
'pmu_backlight_get_level_brightness'? [-Werror=implicit-function-declaration]
74 | int level = backlight_get_brightness(bd);
| ^~~~
| pmu_backlight_get_level_brightness
drivers/macintosh/via-pmu-backlight.c: At top level:
drivers/macintosh/via-pmu-backlight.c:108:21: error: variable
'pmu_backlight_data' has initializer but incomplete type
108 | static const struct backlight_ops pmu_backlight_data = {
| ^
drivers/macintosh/via-pmu-backlight.c:109:10: error: 'const struct
backlight_ops' has no member named 'update_status'
109 | .update_status = pmu_backlight_update_status,
| ^
>> drivers/macintosh/via-pmu-backlight.c:109:27: warning: excess elements in
>> struct initializer
109 | .update_status = pmu_backlight_update_status,
| ^~~
drivers/macintosh/via-pmu-backlight.c:109:27: note: (near initialization for
'pmu_backlight_data')
drivers/macintosh/via-pmu-backlight.c: In function 'pmu_backlight_init':
drivers/macintosh/via-pmu-backlight.c:136:37: error: storage size of 'props'
isn't known
136 | struct backlight_properties props;
| ^
drivers/macintosh/via-pmu-backlight.c:154:34: error: invalid application of
'sizeof' to incomplete type 'struct backlight_properties'
154 | memset(, 0, sizeof(struct backlight_properties));
| ^~
drivers/macintosh/via-pmu-backlight.c:155:22: error: 'BACKLIGHT_PLATFORM'
undeclared (first use in this function)
155 | props.type = BACKLIGHT_PLATFORM;
| ^~
drivers/macintosh/via-pmu-backlight.c:155:22: note: each undeclared
identifier is reported only once for each function it appears in
drivers/macintosh/via-pmu-backlight.c:157:14: error: implicit declaration of
function 'backlight_device_register'; did you mean 'root_device_register'?
[-Werror=implicit-function-declaration]
157 | bd = backlight_device_register(name, NULL, NULL,
_backlight_data,
| ^
| root_device_register
drivers/macintosh/via-pmu-backlight.c:166:19: error: invalid use of
undefined type 'struct backlight_device'
166 | level = bd->props.max_brightness;
| ^~
drivers/macintosh/via-pmu-backlight.c:176:35: error: invalid use of
undefined type 'struct backlight_device'
176 | bd->props.max_brightness / 15);
| ^~
drivers/macintosh/via-pmu-backlight.c:179:11: error: invalid use of
undefined type 'struct backlight_device'
179 | bd->props.brightness = level;
| ^~
drivers/macintosh/via-pmu-backlight.c:180:11: error: invalid use of
undefined type 'struct backlight_device'
180 | bd->props.power = FB_BLANK_UNBLANK;
| ^~
drivers/macintosh/via-pmu-backlight.c:181:9: error: implicit declaration of
function 'backlight_update_status'; did you mean 'pmu_backlight_update_status'?
[-Werror=implicit-function-declaration]
181 |
[linux-next:master] BUILD REGRESSION ae00c445390b349e070a64dc62f08aa878db7248
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: ae00c445390b349e070a64dc62f08aa878db7248 Add linux-next specific files for 20240212 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202402122047.ydhrzmm4-...@intel.com https://lore.kernel.org/oe-kbuild-all/202402130633.bfncwveh-...@intel.com https://lore.kernel.org/oe-kbuild-all/202402131351.a0fzogeg-...@intel.com Error/Warning: (recently discovered and may have been fixed) drivers/md/dm.c:2131:(.text+0x9f34): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `set_dax_nocache' drivers/md/dm.c:2131:(.text+0x9f34): undefined reference to `set_dax_nocache' drivers/md/dm.c:2132:(.text+0x9f3c): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `set_dax_nomc' misc.c:(.text+0x14f0): undefined reference to `__ubsan_handle_load_invalid_value' or1k-linux-ld: drivers/md/dm.c:2132:(.text+0x9f3c): undefined reference to `set_dax_nomc' sh4-linux-ld: misc.c:(.text+0x1698): undefined reference to `__ubsan_handle_load_invalid_value' Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arc-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arc-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arc-randconfig-002-20240212 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- arm-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arm-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arm-randconfig-001-20240212 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- arm64-defconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- csky-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- csky-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- csky-randconfig-001-20240212 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- csky-randconfig-002-20240212 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- csky-randconfig-r061-20240212 | |-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- i386-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-buildonly-randconfig-002-20240212 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- i386-randconfig-013-20240212 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- i386-randconfig-015-20240212 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- loongarch-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- loongarch-randconfig-002-20240212 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- microblaze-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- microblaze-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- mips-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg |-- nios2-randconfig-001-20240212 | `-- fs-ntfs3-frecord.c:warning:unused-variable-i_size |-- openrisc-allyesconfig | `-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-parameter-or-struct-member-gsp-not-described
Re: [PATCH v11 14/26] locking/lockdep, cpu/hotplus: Use a weaker annotation in AP thread
On Mon, Feb 12, 2024 at 04:16:41PM +0100, Thomas Gleixner wrote:
> On Tue, Jan 30 2024 at 11:58, Byungchul Park wrote:
> > On Fri, Jan 26, 2024 at 06:30:02PM +0100, Thomas Gleixner wrote:
> >> On Wed, Jan 24 2024 at 20:59, Byungchul Park wrote:
> >>
> >> Why is lockdep in the subsystem prefix here? You are changing the CPU
> >> hotplug (not hotplus) code, right?
> >>
> >> > cb92173d1f0 ("locking/lockdep, cpu/hotplug: Annotate AP thread") was
> >> > introduced to make lockdep_assert_cpus_held() work in AP thread.
> >> >
> >> > However, the annotation is too strong for that purpose. We don't have to
> >> > use more than try lock annotation for that.
> >>
> >> This lacks a proper explanation why this is too strong.
> >>
> >> > Furthermore, now that Dept was introduced, false positive alarms was
> >> > reported by that. Replaced it with try lock annotation.
> >>
> >> I still have zero idea what this is about.
> >
> > 1. can track PG_locked that is a potential deadlock trigger.
> >
> >
> > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.p...@lge.com/
>
> Sure, but that wants to be explicitely explained in the changelog and
> not with a link. 'Now that Dept was introduced ...' is not an
> explanation.
Admit. I will fix it from the next spin. Thanks.
Byungchul
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/xe/xe_guc_submit.c: In function 'simple_error_capture':
drivers/gpu/drm/xe/xe_guc_submit.c:814:48: error: passing argument 1 of
'drm_err_printer' from incompatible pointer type
[-Werror=incompatible-pointer-types]
814 | struct drm_printer p = drm_err_printer("");
|^~
||
|char *
In file included from drivers/gpu/drm/xe/xe_assert.h:11,
from drivers/gpu/drm/xe/xe_guc_submit.c:19:
include/drm/drm_print.h:349:69: note: expected 'struct drm_device *' but
argument is of type 'char *'
349 | static inline struct drm_printer drm_err_printer(struct drm_device *drm,
| ~~~^~~
drivers/gpu/drm/xe/xe_guc_submit.c:814:32: error: too few arguments to function
'drm_err_printer'
814 | struct drm_printer p = drm_err_printer("");
|^~~
include/drm/drm_print.h:349:34: note: declared here
349 | static inline struct drm_printer drm_err_printer(struct drm_device *drm,
| ^~~
cc1: all warnings being treated as errors
Caused by commit
5e0c04c8c40b ("drm/print: make drm_err_printer() device specific by using
drm_err()")
I have used the drm-misc tree from next-20240209 again today.
--
Cheers,
Stephen Rothwell
pgpIRM_9Hnhjz.pgp
Description: OpenPGP digital signature
[PATCH] drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:
unreferenced object 0x896302b45800 (size 1024):
comm "(udev-worker)", pid 222, jiffies 4294894636
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace (crc 6265fd77):
[] kmalloc_trace+0x29d/0x340
[] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
[] dm_sw_init+0x15/0x2b0 [amdgpu]
[] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
[] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
[] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
[] local_pci_probe+0x3e/0x90
[] pci_device_probe+0xc3/0x230
[] really_probe+0xe2/0x480
[] __driver_probe_device+0x78/0x160
[] driver_probe_device+0x1f/0x90
[] __driver_attach+0xce/0x1c0
[] bus_for_each_dev+0x70/0xc0
[] bus_add_driver+0x112/0x210
[] driver_register+0x55/0x100
[] do_one_initcall+0x41/0x300
Fix this by freeing dmub_srv after destroying it.
Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
Signed-off-by: Armin Wolf
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 59d2eee72a32..9cbfc8d39dee 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2287,6 +2287,7 @@ static int dm_sw_fini(void *handle)
if (adev->dm.dmub_srv) {
dmub_srv_destroy(adev->dm.dmub_srv);
+ kfree(adev->dm.dmub_srv);
adev->dm.dmub_srv = NULL;
}
--
2.39.2
Re: [PATCH] drm/i915/gt: Restart the heartbeat timer when forcing a pulse
Hi John, On Wed, Jan 10, 2024 at 01:02:16PM -0800, john.c.harri...@intel.com wrote: > From: John Harrison > > The context persistence code does things like send super high priority > heartbeat pulses to ensure any leaked context can still be pre-empted > and thus isn't a total denial of service but only a minor denial of > service. Unfortunately, it wasn't bothering to restart the heatbeat /heatbeat/heartbeat/ > worker with a fresh timeout. Thus, if a persistent context happened to > be closed just before the heartbeat was going to go ping anyway then > the forced pulse would get a negligble execution time. And as the > forced pulse is super high priority, the worker thread's next step is > a reset. Which means a potentially innocent system randomly goes boom > when attempting to close a context. So, force a re-schedule of the > worker thread with the appropriate timeout. > > Signed-off-by: John Harrison > --- > drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c > b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c > index 1a8e2b7db0138..4ae2fa0b61dd4 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c > +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c > @@ -290,6 +290,9 @@ static int __intel_engine_pulse(struct intel_engine_cs > *engine) > heartbeat_commit(rq, ); > GEM_BUG_ON(rq->sched.attr.priority < I915_PRIORITY_BARRIER); > > + /* Ensure the forced pulse gets a full period to execute */ > + next_heartbeat(engine); I think it makes sense to have this extra heardbeat here and, as I've been mulling over it, I don't any harm. The failure doesn't look related, either. Reviewed-by: Andi Shyti Thanks, Andi > return 0; > } > > -- > 2.43.0
[PATCH AUTOSEL 5.15 21/22] drm/amdgpu: reset gpu for s3 suspend abort case
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
device.
Signed-off-by: Prike Liang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index e8c0e77e1b01..6a3486f52d69 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1490,10 +1490,32 @@ static int soc15_common_suspend(void *handle)
return soc15_common_hw_fini(adev);
}
+static bool soc15_need_reset_on_resume(struct amdgpu_device *adev)
+{
+ u32 sol_reg;
+
+ sol_reg = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81);
+
+ /* Will reset for the following suspend abort cases.
+* 1) Only reset limit on APU side, dGPU hasn't checked yet.
+* 2) S3 suspend abort and TOS already launched.
+*/
+ if (adev->flags & AMD_IS_APU && adev->in_s3 &&
+ !adev->suspend_complete &&
+ sol_reg)
+ return true;
+
+ return false;
+}
+
static int soc15_common_resume(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ if (soc15_need_reset_on_resume(adev)) {
+ dev_info(adev->dev, "S3 suspend abort case, let's reset
ASIC.\n");
+ soc15_asic_reset(adev);
+ }
return soc15_common_hw_init(adev);
}
--
2.43.0
[PATCH AUTOSEL 5.15 20/22] drm/amdgpu: skip to program GFXDEC registers for suspend abort
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip those program sequence for the suspend abort case.
Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 1f1e7966beb5..dbef22f56482 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1045,6 +1045,8 @@ struct amdgpu_device {
boolin_s3;
boolin_s4;
boolin_s0ix;
+ /* indicate amdgpu suspension status */
+ boolsuspend_complete;
atomic_tin_gpu_reset;
enum pp_mp1_state mp1_state;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index deae92fde3b8..57943e900871 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2252,6 +2252,7 @@ static int amdgpu_pmops_suspend(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = false;
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
else
@@ -2264,6 +2265,7 @@ static int amdgpu_pmops_suspend_noirq(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = true;
if (amdgpu_acpi_should_gpu_reset(adev))
return amdgpu_asic_reset(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index de1fab165041..fb37c0d4b35b 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3268,6 +3268,14 @@ static int gfx_v9_0_cp_gfx_start(struct amdgpu_device
*adev)
gfx_v9_0_cp_gfx_enable(adev, true);
+ /* Now only limit the quirk on the APU gfx9 series and already
+* confirmed that the APU gfx10/gfx11 needn't such update.
+*/
+ if (adev->flags & AMD_IS_APU &&
+ adev->in_s3 && !adev->suspend_complete) {
+ DRM_INFO(" Will skip the CSB packet resubmit\n");
+ return 0;
+ }
r = amdgpu_ring_alloc(ring, gfx_v9_0_get_csb_size(adev) + 4 + 3);
if (r) {
DRM_ERROR("amdgpu: cp failed to lock ring (%d).\n", r);
--
2.43.0
[PATCH AUTOSEL 6.1 25/28] drm/amdgpu: reset gpu for s3 suspend abort case
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
device.
Signed-off-by: Prike Liang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 811dd3ea6362..489c89465c78 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1285,10 +1285,32 @@ static int soc15_common_suspend(void *handle)
return soc15_common_hw_fini(adev);
}
+static bool soc15_need_reset_on_resume(struct amdgpu_device *adev)
+{
+ u32 sol_reg;
+
+ sol_reg = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81);
+
+ /* Will reset for the following suspend abort cases.
+* 1) Only reset limit on APU side, dGPU hasn't checked yet.
+* 2) S3 suspend abort and TOS already launched.
+*/
+ if (adev->flags & AMD_IS_APU && adev->in_s3 &&
+ !adev->suspend_complete &&
+ sol_reg)
+ return true;
+
+ return false;
+}
+
static int soc15_common_resume(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ if (soc15_need_reset_on_resume(adev)) {
+ dev_info(adev->dev, "S3 suspend abort case, let's reset
ASIC.\n");
+ soc15_asic_reset(adev);
+ }
return soc15_common_hw_init(adev);
}
--
2.43.0
[PATCH AUTOSEL 6.1 24/28] drm/amdgpu: skip to program GFXDEC registers for suspend abort
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip those program sequence for the suspend abort case.
Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c46c6fbd235e..e636c7850f77 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -999,6 +999,8 @@ struct amdgpu_device {
boolin_s3;
boolin_s4;
boolin_s0ix;
+ /* indicate amdgpu suspension status */
+ boolsuspend_complete;
enum pp_mp1_state mp1_state;
struct amdgpu_doorbell_index doorbell_index;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b9983ca99eb7..f24c3a20e901 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2414,6 +2414,7 @@ static int amdgpu_pmops_suspend(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = false;
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
else if (amdgpu_acpi_is_s3_active(adev))
@@ -2428,6 +2429,7 @@ static int amdgpu_pmops_suspend_noirq(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = true;
if (amdgpu_acpi_should_gpu_reset(adev))
return amdgpu_asic_reset(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 84ca601f7d5f..195b29892354 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3064,6 +3064,14 @@ static int gfx_v9_0_cp_gfx_start(struct amdgpu_device
*adev)
gfx_v9_0_cp_gfx_enable(adev, true);
+ /* Now only limit the quirk on the APU gfx9 series and already
+* confirmed that the APU gfx10/gfx11 needn't such update.
+*/
+ if (adev->flags & AMD_IS_APU &&
+ adev->in_s3 && !adev->suspend_complete) {
+ DRM_INFO(" Will skip the CSB packet resubmit\n");
+ return 0;
+ }
r = amdgpu_ring_alloc(ring, gfx_v9_0_get_csb_size(adev) + 4 + 3);
if (r) {
DRM_ERROR("amdgpu: cp failed to lock ring (%d).\n", r);
--
2.43.0
[PATCH AUTOSEL 6.6 46/51] drm/amdgpu: Fix HDP flush for VFs on nbio v7.9
From: Lijo Lazar [ Upstream commit 534c8a5b9d5d41d30cdcac93cfa1bca5e17be009 ] HDP flush remapping is not done for VFs. Keep the original offsets in VF environment. Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c index ae45656eb877..0a601336cf69 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c @@ -426,6 +426,12 @@ static void nbio_v7_9_init_registers(struct amdgpu_device *adev) u32 inst_mask; int i; + if (amdgpu_sriov_vf(adev)) + adev->rmmio_remap.reg_offset = + SOC15_REG_OFFSET( + NBIO, 0, + regBIF_BX_DEV0_EPF0_VF0_HDP_MEM_COHERENCY_FLUSH_CNTL) + << 2; WREG32_SOC15(NBIO, 0, regXCC_DOORBELL_FENCE, 0xff & ~(adev->gfx.xcc_mask)); -- 2.43.0
[PATCH AUTOSEL 6.6 45/51] drm/amdgpu: Fix shared buff copy to user
From: "Stanley.Yang" [ Upstream commit 2dcf82a8e8dc930655787797ef8a3692b527c7a9 ] ta if invoke node buffer | ta type --| | ta id --| | cmd id --| |-- shared buf len -| |-- shared buffer --| ta if invoke node buffer is as above, copy shared buffer data to correct location Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c index 468a67b302d4..ca5c86e5f7cd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c @@ -362,7 +362,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size } } - if (copy_to_user((char *)buf, context->mem_context.shared_buf, shared_buf_len)) + if (copy_to_user((char *)[copy_pos], context->mem_context.shared_buf, shared_buf_len)) ret = -EFAULT; err_free_shared_buf: -- 2.43.0
[PATCH AUTOSEL 6.6 44/51] drm/amdgpu: reset gpu for s3 suspend abort case
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
device.
Signed-off-by: Prike Liang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 3667f9a54841..2a7c606d1d19 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1296,10 +1296,32 @@ static int soc15_common_suspend(void *handle)
return soc15_common_hw_fini(adev);
}
+static bool soc15_need_reset_on_resume(struct amdgpu_device *adev)
+{
+ u32 sol_reg;
+
+ sol_reg = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81);
+
+ /* Will reset for the following suspend abort cases.
+* 1) Only reset limit on APU side, dGPU hasn't checked yet.
+* 2) S3 suspend abort and TOS already launched.
+*/
+ if (adev->flags & AMD_IS_APU && adev->in_s3 &&
+ !adev->suspend_complete &&
+ sol_reg)
+ return true;
+
+ return false;
+}
+
static int soc15_common_resume(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ if (soc15_need_reset_on_resume(adev)) {
+ dev_info(adev->dev, "S3 suspend abort case, let's reset
ASIC.\n");
+ soc15_asic_reset(adev);
+ }
return soc15_common_hw_init(adev);
}
--
2.43.0
[PATCH AUTOSEL 6.6 43/51] drm/amdgpu: skip to program GFXDEC registers for suspend abort
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip those program sequence for the suspend abort case.
Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index a79d53bdbe13..85efd686e538 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1009,6 +1009,8 @@ struct amdgpu_device {
boolin_s3;
boolin_s4;
boolin_s0ix;
+ /* indicate amdgpu suspension status */
+ boolsuspend_complete;
enum pp_mp1_state mp1_state;
struct amdgpu_doorbell_index doorbell_index;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 2c35036e4ba2..3204c3a42f2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2409,6 +2409,7 @@ static int amdgpu_pmops_suspend(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = false;
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
else if (amdgpu_acpi_is_s3_active(adev))
@@ -2423,6 +2424,7 @@ static int amdgpu_pmops_suspend_noirq(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = true;
if (amdgpu_acpi_should_gpu_reset(adev))
return amdgpu_asic_reset(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 2e23d08b45f4..d7d15b618c37 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3033,6 +3033,14 @@ static int gfx_v9_0_cp_gfx_start(struct amdgpu_device
*adev)
gfx_v9_0_cp_gfx_enable(adev, true);
+ /* Now only limit the quirk on the APU gfx9 series and already
+* confirmed that the APU gfx10/gfx11 needn't such update.
+*/
+ if (adev->flags & AMD_IS_APU &&
+ adev->in_s3 && !adev->suspend_complete) {
+ DRM_INFO(" Will skip the CSB packet resubmit\n");
+ return 0;
+ }
r = amdgpu_ring_alloc(ring, gfx_v9_0_get_csb_size(adev) + 4 + 3);
if (r) {
DRM_ERROR("amdgpu: cp failed to lock ring (%d).\n", r);
--
2.43.0
[PATCH AUTOSEL 6.6 39/51] accel/ivpu/40xx: Stop passing SKU boot parameters to FW
From: Krystian Pradzynski
[ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
This parameter was never used by the 40xx FW.
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-7-jacek.lawrynow...@linux.intel.com
Signed-off-by: Sasha Levin
---
drivers/accel/ivpu/ivpu_hw_40xx.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c
b/drivers/accel/ivpu/ivpu_hw_40xx.c
index 65c6a82bb13f..ae6be0d5aacc 100644
--- a/drivers/accel/ivpu/ivpu_hw_40xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_40xx.c
@@ -697,7 +697,6 @@ static int ivpu_hw_40xx_info_init(struct ivpu_device *vdev)
{
struct ivpu_hw_info *hw = vdev->hw;
u32 tile_disable;
- u32 tile_enable;
u32 fuse;
fuse = REGB_RD32(VPU_40XX_BUTTRESS_TILE_FUSE);
@@ -718,10 +717,6 @@ static int ivpu_hw_40xx_info_init(struct ivpu_device *vdev)
else
ivpu_dbg(vdev, MISC, "Fuse: All %d tiles enabled\n",
TILE_MAX_NUM);
- tile_enable = (~tile_disable) & TILE_MAX_MASK;
-
- hw->sku = REG_SET_FLD_NUM(SKU, HW_ID, LNL_HW_ID, hw->sku);
- hw->sku = REG_SET_FLD_NUM(SKU, TILE, tile_enable, hw->sku);
hw->tile_fuse = tile_disable;
hw->pll.profiling_freq = PLL_PROFILING_FREQ_DEFAULT;
--
2.43.0
[PATCH AUTOSEL 6.6 38/51] accel/ivpu: Disable d3hot_delay on all NPU generations
From: Jacek Lawrynowicz
[ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
NPU does not require this delay regardless of the generation.
All generations are integrated into the SOC.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-4-jacek.lawrynow...@linux.intel.com
Signed-off-by: Sasha Levin
---
drivers/accel/ivpu/ivpu_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 7e9359611d69..8fb70e3c7b9c 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -467,9 +467,8 @@ static int ivpu_pci_init(struct ivpu_device *vdev)
/* Clear any pending errors */
pcie_capability_clear_word(pdev, PCI_EXP_DEVSTA, 0x3f);
- /* VPU 37XX does not require 10m D3hot delay */
- if (ivpu_hw_gen(vdev) == IVPU_HW_37XX)
- pdev->d3hot_delay = 0;
+ /* NPU does not require 10m D3hot delay */
+ pdev->d3hot_delay = 0;
ret = pcim_enable_device(pdev);
if (ret) {
--
2.43.0
[PATCH AUTOSEL 6.6 37/51] accel/ivpu: Force snooping for MMU writes
From: "Wachowski, Karol" [ Upstream commit c9da9a1f17bf4fa96b115950fd389c917b583c1c ] Set AW_SNOOP_OVERRIDE bit in VPU_37/40XX_HOST_IF_TCU_PTW_OVERRIDES to force snooping for MMU write accesses (setting event queue events). MMU event queue buffer is the only buffer written by MMU and mapped as write-back which break cache coherency. Force write transactions to be snooped solving the problem. Signed-off-by: Wachowski, Karol Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-2-jacek.lawrynow...@linux.intel.com Signed-off-by: Sasha Levin --- drivers/accel/ivpu/ivpu_hw_37xx.c | 2 +- drivers/accel/ivpu/ivpu_hw_40xx.c | 2 +- drivers/accel/ivpu/ivpu_mmu.c | 3 --- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c b/drivers/accel/ivpu/ivpu_hw_37xx.c index ddf03498fd4c..c0de7c0c991f 100644 --- a/drivers/accel/ivpu/ivpu_hw_37xx.c +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c @@ -562,7 +562,7 @@ static void ivpu_boot_no_snoop_enable(struct ivpu_device *vdev) u32 val = REGV_RD32(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES); val = REG_SET_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, NOSNOOP_OVERRIDE_EN, val); - val = REG_SET_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, AW_NOSNOOP_OVERRIDE, val); + val = REG_CLR_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, AW_NOSNOOP_OVERRIDE, val); val = REG_SET_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, AR_NOSNOOP_OVERRIDE, val); REGV_WR32(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, val); diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c b/drivers/accel/ivpu/ivpu_hw_40xx.c index 03600a7a5aca..65c6a82bb13f 100644 --- a/drivers/accel/ivpu/ivpu_hw_40xx.c +++ b/drivers/accel/ivpu/ivpu_hw_40xx.c @@ -523,7 +523,7 @@ static void ivpu_boot_no_snoop_enable(struct ivpu_device *vdev) u32 val = REGV_RD32(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES); val = REG_SET_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, SNOOP_OVERRIDE_EN, val); - val = REG_CLR_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, AW_SNOOP_OVERRIDE, val); + val = REG_SET_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, AW_SNOOP_OVERRIDE, val); val = REG_CLR_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, AR_SNOOP_OVERRIDE, val); REGV_WR32(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, val); diff --git a/drivers/accel/ivpu/ivpu_mmu.c b/drivers/accel/ivpu/ivpu_mmu.c index baefaf7bb3cb..d04a28e05248 100644 --- a/drivers/accel/ivpu/ivpu_mmu.c +++ b/drivers/accel/ivpu/ivpu_mmu.c @@ -491,7 +491,6 @@ static int ivpu_mmu_reset(struct ivpu_device *vdev) mmu->cmdq.cons = 0; memset(mmu->evtq.base, 0, IVPU_MMU_EVTQ_SIZE); - clflush_cache_range(mmu->evtq.base, IVPU_MMU_EVTQ_SIZE); mmu->evtq.prod = 0; mmu->evtq.cons = 0; @@ -805,8 +804,6 @@ static u32 *ivpu_mmu_get_event(struct ivpu_device *vdev) if (!CIRC_CNT(IVPU_MMU_Q_IDX(evtq->prod), IVPU_MMU_Q_IDX(evtq->cons), IVPU_MMU_Q_COUNT)) return NULL; - clflush_cache_range(evt, IVPU_MMU_EVTQ_CMD_SIZE); - evtq->cons = (evtq->cons + 1) & IVPU_MMU_Q_WRAP_MASK; REGV_WR32(VPU_37XX_HOST_MMU_EVTQ_CONS_SEC, evtq->cons); -- 2.43.0
[PATCH AUTOSEL 6.7 53/58] drm/amdgpu: Fix HDP flush for VFs on nbio v7.9
From: Lijo Lazar [ Upstream commit 534c8a5b9d5d41d30cdcac93cfa1bca5e17be009 ] HDP flush remapping is not done for VFs. Keep the original offsets in VF environment. Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c index 25a3da83e0fb..db013f86147a 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c @@ -431,6 +431,12 @@ static void nbio_v7_9_init_registers(struct amdgpu_device *adev) u32 inst_mask; int i; + if (amdgpu_sriov_vf(adev)) + adev->rmmio_remap.reg_offset = + SOC15_REG_OFFSET( + NBIO, 0, + regBIF_BX_DEV0_EPF0_VF0_HDP_MEM_COHERENCY_FLUSH_CNTL) + << 2; WREG32_SOC15(NBIO, 0, regXCC_DOORBELL_FENCE, 0xff & ~(adev->gfx.xcc_mask)); -- 2.43.0
[PATCH AUTOSEL 6.7 52/58] drm/amdgpu: Fix shared buff copy to user
From: "Stanley.Yang" [ Upstream commit 2dcf82a8e8dc930655787797ef8a3692b527c7a9 ] ta if invoke node buffer | ta type --| | ta id --| | cmd id --| |-- shared buf len -| |-- shared buffer --| ta if invoke node buffer is as above, copy shared buffer data to correct location Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c index 468a67b302d4..ca5c86e5f7cd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c @@ -362,7 +362,7 @@ static ssize_t ta_if_invoke_debugfs_write(struct file *fp, const char *buf, size } } - if (copy_to_user((char *)buf, context->mem_context.shared_buf, shared_buf_len)) + if (copy_to_user((char *)[copy_pos], context->mem_context.shared_buf, shared_buf_len)) ret = -EFAULT; err_free_shared_buf: -- 2.43.0
[PATCH AUTOSEL 6.7 51/58] drm/amdgpu: reset gpu for s3 suspend abort case
From: Prike Liang
[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
device.
Signed-off-by: Prike Liang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 51342809af03..9b5af3f1383a 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1297,10 +1297,32 @@ static int soc15_common_suspend(void *handle)
return soc15_common_hw_fini(adev);
}
+static bool soc15_need_reset_on_resume(struct amdgpu_device *adev)
+{
+ u32 sol_reg;
+
+ sol_reg = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81);
+
+ /* Will reset for the following suspend abort cases.
+* 1) Only reset limit on APU side, dGPU hasn't checked yet.
+* 2) S3 suspend abort and TOS already launched.
+*/
+ if (adev->flags & AMD_IS_APU && adev->in_s3 &&
+ !adev->suspend_complete &&
+ sol_reg)
+ return true;
+
+ return false;
+}
+
static int soc15_common_resume(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ if (soc15_need_reset_on_resume(adev)) {
+ dev_info(adev->dev, "S3 suspend abort case, let's reset
ASIC.\n");
+ soc15_asic_reset(adev);
+ }
return soc15_common_hw_init(adev);
}
--
2.43.0
[PATCH AUTOSEL 6.7 50/58] drm/amdgpu: skip to program GFXDEC registers for suspend abort
From: Prike Liang
[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip those program sequence for the suspend abort case.
Signed-off-by: Prike Liang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 8
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 50f57d4dfd8f..be12ed96eb96 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1041,6 +1041,8 @@ struct amdgpu_device {
boolin_s3;
boolin_s4;
boolin_s0ix;
+ /* indicate amdgpu suspension status */
+ boolsuspend_complete;
enum pp_mp1_state mp1_state;
struct amdgpu_doorbell_index doorbell_index;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a7ad77ed09ca..10c4a8cfa18a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2449,6 +2449,7 @@ static int amdgpu_pmops_suspend(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = false;
if (amdgpu_acpi_is_s0ix_active(adev))
adev->in_s0ix = true;
else if (amdgpu_acpi_is_s3_active(adev))
@@ -2463,6 +2464,7 @@ static int amdgpu_pmops_suspend_noirq(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
+ adev->suspend_complete = true;
if (amdgpu_acpi_should_gpu_reset(adev))
return amdgpu_asic_reset(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 69c500910746..3bc6943365a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3034,6 +3034,14 @@ static int gfx_v9_0_cp_gfx_start(struct amdgpu_device
*adev)
gfx_v9_0_cp_gfx_enable(adev, true);
+ /* Now only limit the quirk on the APU gfx9 series and already
+* confirmed that the APU gfx10/gfx11 needn't such update.
+*/
+ if (adev->flags & AMD_IS_APU &&
+ adev->in_s3 && !adev->suspend_complete) {
+ DRM_INFO(" Will skip the CSB packet resubmit\n");
+ return 0;
+ }
r = amdgpu_ring_alloc(ring, gfx_v9_0_get_csb_size(adev) + 4 + 3);
if (r) {
DRM_ERROR("amdgpu: cp failed to lock ring (%d).\n", r);
--
2.43.0
[PATCH AUTOSEL 6.7 43/58] accel/ivpu: Force snooping for MMU writes
From: "Wachowski, Karol" [ Upstream commit c9da9a1f17bf4fa96b115950fd389c917b583c1c ] Set AW_SNOOP_OVERRIDE bit in VPU_37/40XX_HOST_IF_TCU_PTW_OVERRIDES to force snooping for MMU write accesses (setting event queue events). MMU event queue buffer is the only buffer written by MMU and mapped as write-back which break cache coherency. Force write transactions to be snooped solving the problem. Signed-off-by: Wachowski, Karol Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-2-jacek.lawrynow...@linux.intel.com Signed-off-by: Sasha Levin --- drivers/accel/ivpu/ivpu_hw_37xx.c | 2 +- drivers/accel/ivpu/ivpu_hw_40xx.c | 2 +- drivers/accel/ivpu/ivpu_mmu.c | 3 --- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c b/drivers/accel/ivpu/ivpu_hw_37xx.c index d530384f8d60..e658fcf849f7 100644 --- a/drivers/accel/ivpu/ivpu_hw_37xx.c +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c @@ -523,7 +523,7 @@ static void ivpu_boot_no_snoop_enable(struct ivpu_device *vdev) u32 val = REGV_RD32(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES); val = REG_SET_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, NOSNOOP_OVERRIDE_EN, val); - val = REG_SET_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, AW_NOSNOOP_OVERRIDE, val); + val = REG_CLR_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, AW_NOSNOOP_OVERRIDE, val); val = REG_SET_FLD(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, AR_NOSNOOP_OVERRIDE, val); REGV_WR32(VPU_37XX_HOST_IF_TCU_PTW_OVERRIDES, val); diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c b/drivers/accel/ivpu/ivpu_hw_40xx.c index e691c49c9841..8a7440bcd6df 100644 --- a/drivers/accel/ivpu/ivpu_hw_40xx.c +++ b/drivers/accel/ivpu/ivpu_hw_40xx.c @@ -526,7 +526,7 @@ static void ivpu_boot_no_snoop_enable(struct ivpu_device *vdev) u32 val = REGV_RD32(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES); val = REG_SET_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, SNOOP_OVERRIDE_EN, val); - val = REG_CLR_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, AW_SNOOP_OVERRIDE, val); + val = REG_SET_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, AW_SNOOP_OVERRIDE, val); val = REG_CLR_FLD(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, AR_SNOOP_OVERRIDE, val); REGV_WR32(VPU_40XX_HOST_IF_TCU_PTW_OVERRIDES, val); diff --git a/drivers/accel/ivpu/ivpu_mmu.c b/drivers/accel/ivpu/ivpu_mmu.c index 2538c78fbebe..9898946174fd 100644 --- a/drivers/accel/ivpu/ivpu_mmu.c +++ b/drivers/accel/ivpu/ivpu_mmu.c @@ -533,7 +533,6 @@ static int ivpu_mmu_reset(struct ivpu_device *vdev) mmu->cmdq.cons = 0; memset(mmu->evtq.base, 0, IVPU_MMU_EVTQ_SIZE); - clflush_cache_range(mmu->evtq.base, IVPU_MMU_EVTQ_SIZE); mmu->evtq.prod = 0; mmu->evtq.cons = 0; @@ -847,8 +846,6 @@ static u32 *ivpu_mmu_get_event(struct ivpu_device *vdev) if (!CIRC_CNT(IVPU_MMU_Q_IDX(evtq->prod), IVPU_MMU_Q_IDX(evtq->cons), IVPU_MMU_Q_COUNT)) return NULL; - clflush_cache_range(evt, IVPU_MMU_EVTQ_CMD_SIZE); - evtq->cons = (evtq->cons + 1) & IVPU_MMU_Q_WRAP_MASK; REGV_WR32(IVPU_MMU_REG_EVTQ_CONS_SEC, evtq->cons); -- 2.43.0
[PATCH AUTOSEL 6.7 45/58] accel/ivpu/40xx: Stop passing SKU boot parameters to FW
From: Krystian Pradzynski
[ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
This parameter was never used by the 40xx FW.
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-7-jacek.lawrynow...@linux.intel.com
Signed-off-by: Sasha Levin
---
drivers/accel/ivpu/ivpu_hw_40xx.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c
b/drivers/accel/ivpu/ivpu_hw_40xx.c
index 8a7440bcd6df..a7c976256ed3 100644
--- a/drivers/accel/ivpu/ivpu_hw_40xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_40xx.c
@@ -700,7 +700,6 @@ static int ivpu_hw_40xx_info_init(struct ivpu_device *vdev)
{
struct ivpu_hw_info *hw = vdev->hw;
u32 tile_disable;
- u32 tile_enable;
u32 fuse;
fuse = REGB_RD32(VPU_40XX_BUTTRESS_TILE_FUSE);
@@ -721,10 +720,6 @@ static int ivpu_hw_40xx_info_init(struct ivpu_device *vdev)
else
ivpu_dbg(vdev, MISC, "Fuse: All %d tiles enabled\n",
TILE_MAX_NUM);
- tile_enable = (~tile_disable) & TILE_MAX_MASK;
-
- hw->sku = REG_SET_FLD_NUM(SKU, HW_ID, LNL_HW_ID, hw->sku);
- hw->sku = REG_SET_FLD_NUM(SKU, TILE, tile_enable, hw->sku);
hw->tile_fuse = tile_disable;
hw->pll.profiling_freq = PLL_PROFILING_FREQ_DEFAULT;
--
2.43.0
[PATCH AUTOSEL 6.7 44/58] accel/ivpu: Disable d3hot_delay on all NPU generations
From: Jacek Lawrynowicz
[ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
NPU does not require this delay regardless of the generation.
All generations are integrated into the SOC.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Link:
https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-4-jacek.lawrynow...@linux.intel.com
Signed-off-by: Sasha Levin
---
drivers/accel/ivpu/ivpu_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 790603017653..c856c417a145 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -479,9 +479,8 @@ static int ivpu_pci_init(struct ivpu_device *vdev)
/* Clear any pending errors */
pcie_capability_clear_word(pdev, PCI_EXP_DEVSTA, 0x3f);
- /* VPU 37XX does not require 10m D3hot delay */
- if (ivpu_hw_gen(vdev) == IVPU_HW_37XX)
- pdev->d3hot_delay = 0;
+ /* NPU does not require 10m D3hot delay */
+ pdev->d3hot_delay = 0;
ret = pcim_enable_device(pdev);
if (ret) {
--
2.43.0
[PATCH AUTOSEL 6.7 35/58] drm/nouveau: nvkm_gsp_radix3_sg() should use nvkm_gsp_mem_ctor()
From: Timur Tabi
[ Upstream commit 34e659f34a7559ecfd9c1f5b24d4c291f3f54711 ]
Function nvkm_gsp_radix3_sg() uses nvkm_gsp_mem objects to allocate the
radix3 tables, but it unnecessarily creates those objects manually
instead of using the standard nvkm_gsp_mem_ctor() function like the
rest of the code does.
Signed-off-by: Timur Tabi
Signed-off-by: Danilo Krummrich
Link:
https://patchwork.freedesktop.org/patch/msgid/20240202230608.1981026-2-tt...@nvidia.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 9ee58e2a0eb2..09e2eb1369cb 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1938,20 +1938,20 @@ nvkm_gsp_radix3_dtor(struct nvkm_gsp *gsp, struct
nvkm_gsp_radix3 *rx3)
* See kgspCreateRadix3_IMPL
*/
static int
-nvkm_gsp_radix3_sg(struct nvkm_device *device, struct sg_table *sgt, u64 size,
+nvkm_gsp_radix3_sg(struct nvkm_gsp *gsp, struct sg_table *sgt, u64 size,
struct nvkm_gsp_radix3 *rx3)
{
u64 addr;
for (int i = ARRAY_SIZE(rx3->mem) - 1; i >= 0; i--) {
u64 *ptes;
- int idx;
+ size_t bufsize;
+ int ret, idx;
- rx3->mem[i].size = ALIGN((size / GSP_PAGE_SIZE) * sizeof(u64),
GSP_PAGE_SIZE);
- rx3->mem[i].data = dma_alloc_coherent(device->dev,
rx3->mem[i].size,
- >mem[i].addr,
GFP_KERNEL);
- if (WARN_ON(!rx3->mem[i].data))
- return -ENOMEM;
+ bufsize = ALIGN((size / GSP_PAGE_SIZE) * sizeof(u64),
GSP_PAGE_SIZE);
+ ret = nvkm_gsp_mem_ctor(gsp, bufsize, >mem[i]);
+ if (ret)
+ return ret;
ptes = rx3->mem[i].data;
if (i == 2) {
@@ -1991,7 +1991,7 @@ r535_gsp_fini(struct nvkm_gsp *gsp, bool suspend)
if (ret)
return ret;
- ret = nvkm_gsp_radix3_sg(gsp->subdev.device, >sr.sgt, len,
>sr.radix3);
+ ret = nvkm_gsp_radix3_sg(gsp, >sr.sgt, len,
>sr.radix3);
if (ret)
return ret;
@@ -2194,7 +2194,7 @@ r535_gsp_oneinit(struct nvkm_gsp *gsp)
memcpy(gsp->sig.data, data, size);
/* Build radix3 page table for ELF image. */
- ret = nvkm_gsp_radix3_sg(device, >fw.mem.sgt, gsp->fw.len,
>radix3);
+ ret = nvkm_gsp_radix3_sg(gsp, >fw.mem.sgt, gsp->fw.len,
>radix3);
if (ret)
return ret;
--
2.43.0
Re: [PATCH v2 19/19] drm/msm/dp: allow YUV420 mode for DP connector when CDM available
On 2/12/2024 1:20 PM, Dmitry Baryshkov wrote:
On Mon, 12 Feb 2024 at 23:13, Abhinav Kumar wrote:
On 2/10/2024 1:17 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 21:19, Abhinav Kumar wrote:
On 2/10/2024 3:33 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote:
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v2:
- Check for if dp_catalog has a CDM block available instead of
checking if VSC SDP is allowed when setting the dp connector's
ycbcr_420_allowed parameter
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++-
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_drm.c | 8 ++--
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.h | 5 +++--
5 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 723cc1d821431..beeaabe499abf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -565,6 +565,7 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
{
struct drm_encoder *encoder = NULL;
struct msm_display_info info;
+ bool yuv_supported;
int rc;
int i;
@@ -583,7 +584,8 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
return PTR_ERR(encoder);
}
- rc = msm_dp_modeset_init(priv->dp[i], dev, encoder);
+ yuv_supported = !!(dpu_kms->catalog->cdm);
Drop parentheses please.
+ rc = msm_dp_modeset_init(priv->dp[i], dev, encoder,
yuv_supported);
if (rc) {
DPU_ERROR("modeset_init failed for DP, rc = %d\n",
rc);
return rc;
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index ebcc76ef1d590..9b9f5f2921903 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1471,7 +1471,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
}
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder, bool yuv_supported)
{
struct dp_display_private *dp_priv;
int ret;
@@ -1487,7 +1487,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return ret;
}
- dp_display->connector = dp_drm_connector_init(dp_display, encoder);
+ dp_display->connector = dp_drm_connector_init(dp_display, encoder,
yuv_supported);
if (IS_ERR(dp_display->connector)) {
ret = PTR_ERR(dp_display->connector);
DRM_DEV_ERROR(dev->dev,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 46e6889037e88..ab0d0d13b5e2c 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -353,7 +353,8 @@ int dp_bridge_init(struct msm_dp *dp_display, struct
drm_device *dev,
}
/* connector initialization */
-struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder)
+struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder,
+ bool yuv_supported)
{
struct drm_connector *connector = NULL;
@@ -361,8 +362,11 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display, struct dr
if (IS_ERR(connector))
return connector;
- if (!dp_display->is_edp)
+ if (!dp_display->is_edp) {
drm_connector_attach_dp_subconnector_property(connector);
+ if (yuv_supported)
+ connector->ycbcr_420_allowed = true;
Is there any reason to disallow YUV420 for eDP connectors?
+ }
Major reason was certainly validation but thinking about it more
closely, I need to check whether CDM over eDP is even possible.
Historically, CDM could output only to HDMI OR WB using the bit we
program while setting up CDM and the same HDMI path is being used by DP
as well. But I need to check whether CDM can even output to eDP with the
same DP path. I dont have any documentation on this part yet.
I had the feeling that the DP / eDP difference on the chips is mostly
on the PHY and software side. So I assumed that it should be possible
to output YUV data to the eDP port in the same way as it is done for
the DP port.
This is true. I was not worried about DP / eDP controller but mostly
whether eDP
Re: [PATCH] drm/crtc: fix uninitialized variable use even harder
On 2/12/2024 1:55 PM, Rob Clark wrote:
From: Rob Clark
DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
which means we can't rely too much on variable initializers.
Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
Signed-off-by: Rob Clark
---
I have mixed feelings about DRM_MODESET_LOCK_ALL_BEGIN() (and friends)
magic. On one hand it simplifies the deadlock/back dance. OTOH it
conceals a nasty sharp edge. Maybe it is better to have the complicated
restart path a bit more explicit, like it was originally.
drivers/gpu/drm/drm_crtc.c | 1 +
1 file changed, 1 insertion(+)
Nice catch !!
Reviewed-by: Abhinav Kumar
Re: [PATCH] drm/crtc: fix uninitialized variable use even harder
On Mon, Feb 12, 2024 at 1:55 PM Rob Clark wrote:
>
> From: Rob Clark
>
> DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
> which means we can't rely too much on variable initializers.
>
> Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
> Signed-off-by: Rob Clark
> ---
> I have mixed feelings about DRM_MODESET_LOCK_ALL_BEGIN() (and friends)
> magic. On one hand it simplifies the deadlock/back dance. OTOH it
> conceals a nasty sharp edge. Maybe it is better to have the complicated
> restart path a bit more explicit, like it was originally.
I should also point out, had drm-misc-next been using gitlab MRs and
gitlab CI, we would have caught this ;-)
BR,
-R
> drivers/gpu/drm/drm_crtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index cb90e70d85e8..65f9f66933bb 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -904,6 +904,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> connector_set = NULL;
> fb = NULL;
> mode = NULL;
> + num_connectors = 0;
>
> DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
>
> --
> 2.43.0
>
[PATCH] drm/crtc: fix uninitialized variable use even harder
From: Rob Clark
DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
which means we can't rely too much on variable initializers.
Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
Signed-off-by: Rob Clark
---
I have mixed feelings about DRM_MODESET_LOCK_ALL_BEGIN() (and friends)
magic. On one hand it simplifies the deadlock/back dance. OTOH it
conceals a nasty sharp edge. Maybe it is better to have the complicated
restart path a bit more explicit, like it was originally.
drivers/gpu/drm/drm_crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cb90e70d85e8..65f9f66933bb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -904,6 +904,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector_set = NULL;
fb = NULL;
mode = NULL;
+ num_connectors = 0;
DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
--
2.43.0
Re: [PATCH v2 19/19] drm/msm/dp: allow YUV420 mode for DP connector when CDM available
On Mon, 12 Feb 2024 at 23:13, Abhinav Kumar wrote:
>
>
>
> On 2/10/2024 1:17 PM, Dmitry Baryshkov wrote:
> > On Sat, 10 Feb 2024 at 21:19, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/10/2024 3:33 AM, Dmitry Baryshkov wrote:
> >>> On Sat, 10 Feb 2024 at 03:52, Paloma Arellano
> >>> wrote:
>
> All the components of YUV420 over DP are added. Therefore, let's mark the
> connector property as true for DP connector when the DP type is not eDP
> and when there is a CDM block available.
>
> Changes in v2:
> - Check for if dp_catalog has a CDM block available instead of
> checking if VSC SDP is allowed when setting the dp
> connector's
> ycbcr_420_allowed parameter
>
> Signed-off-by: Paloma Arellano
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++-
> drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
> drivers/gpu/drm/msm/dp/dp_drm.c | 8 ++--
> drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
> drivers/gpu/drm/msm/msm_drv.h | 5 +++--
> 5 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 723cc1d821431..beeaabe499abf 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -565,6 +565,7 @@ static int _dpu_kms_initialize_displayport(struct
> drm_device *dev,
> {
> struct drm_encoder *encoder = NULL;
> struct msm_display_info info;
> + bool yuv_supported;
> int rc;
> int i;
>
> @@ -583,7 +584,8 @@ static int _dpu_kms_initialize_displayport(struct
> drm_device *dev,
> return PTR_ERR(encoder);
> }
>
> - rc = msm_dp_modeset_init(priv->dp[i], dev, encoder);
> + yuv_supported = !!(dpu_kms->catalog->cdm);
> >>>
> >>> Drop parentheses please.
> >>>
> + rc = msm_dp_modeset_init(priv->dp[i], dev, encoder,
> yuv_supported);
> if (rc) {
> DPU_ERROR("modeset_init failed for DP, rc =
> %d\n", rc);
> return rc;
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index ebcc76ef1d590..9b9f5f2921903 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1471,7 +1471,7 @@ static int dp_display_get_next_bridge(struct
> msm_dp *dp)
> }
>
> int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device
> *dev,
> - struct drm_encoder *encoder)
> + struct drm_encoder *encoder, bool yuv_supported)
> {
> struct dp_display_private *dp_priv;
> int ret;
> @@ -1487,7 +1487,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
> struct drm_device *dev,
> return ret;
> }
>
> - dp_display->connector = dp_drm_connector_init(dp_display,
> encoder);
> + dp_display->connector = dp_drm_connector_init(dp_display,
> encoder, yuv_supported);
> if (IS_ERR(dp_display->connector)) {
> ret = PTR_ERR(dp_display->connector);
> DRM_DEV_ERROR(dev->dev,
> diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c
> b/drivers/gpu/drm/msm/dp/dp_drm.c
> index 46e6889037e88..ab0d0d13b5e2c 100644
> --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> @@ -353,7 +353,8 @@ int dp_bridge_init(struct msm_dp *dp_display, struct
> drm_device *dev,
> }
>
> /* connector initialization */
> -struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display,
> struct drm_encoder *encoder)
> +struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display,
> struct drm_encoder *encoder,
> + bool yuv_supported)
> {
> struct drm_connector *connector = NULL;
>
> @@ -361,8 +362,11 @@ struct drm_connector *dp_drm_connector_init(struct
> msm_dp *dp_display, struct dr
> if (IS_ERR(connector))
> return connector;
>
> - if (!dp_display->is_edp)
> + if (!dp_display->is_edp) {
>
> drm_connector_attach_dp_subconnector_property(connector);
> + if (yuv_supported)
> + connector->ycbcr_420_allowed = true;
> >>>
> >>> Is there any reason to disallow YUV420 for eDP connectors?
> >>>
> + }
>
Re: [PATCH v5 1/3] drm: Add support to get EDID from ACPI
On 2/12/2024 10:31, Mario Limonciello wrote:
On 2/10/2024 23:50, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by: Mario Limonciello
---
v1->v2:
* Split code from previous amdgpu specific helper to generic drm
helper.
v2->v3:
* Add an extra select to fix a variety of randconfig errors found from
LKP robot.
v3->v4:
* Return struct drm_edid
v4->v5:
* Rename to drm_edid_read_acpi
* Drop selects
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/drm_edid.c | 113 +---
include/drm/drm_connector.h | 6 ++
include/drm/drm_edid.h | 1 +
4 files changed, 119 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2520db0b776e..a49740c528b9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -103,6 +103,13 @@ config DRM_KMS_HELPER
help
CRTC helpers for KMS drivers.
+config DRM_ACPI_HELPER
+ tristate "ACPI support in DRM"
+ depends on DRM
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
+ help
+ ACPI helpers for DRM drivers.
+
Unfortunately in my wider testing this still fails with a few combinations.
This combination fails to link:
CONFIG_ACPI_VIDEO=m
CONFIG_DRM_ACPI_HELPER=y
CONFIG_DRM=y
This combination links but doesn't work because the IS_REACHABLE() fails
(-EOPNOTSUPP):
CONFIG_ACPI_VIDEO=m
CONFIG_DRM_ACPI_HELPER=M
CONFIG_DRM=y
I'm tempted to split off all of drm_edid to it's own module instead of
CONFIG_DRM_ACPI_HELPER which has a depends on (ACPI_VIDEO ||
ACPI_VIDEIO=n).
Or Daniel, any better ideas?
I've come up with a solution that undoes all the select mess in
preceding patches.
This patch will be swapped around to
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -8,6 +8,7 @@
menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher
DRI support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
select DRM_PANEL_ORIENTATION_QUIRKS
select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
select FB_CORE if DRM_FBDEV_EMULATION
I'll wait a little for any other feedback and then post the updated
series. None of the other patches change in any material way.
config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
bool "Enable refcount backtrace history in the DP MST helpers"
depends on STACKTRACE_SUPPORT
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 69c68804023f..096c278b6f66 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -2188,6 +2189,62 @@ drm_do_probe_ddc_edid(void *data, u8 *buf,
unsigned int block, size_t len)
return ret == xfers ? 0 : -1;
}
+/**
+ * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
+ * @data: struct drm_connector
+ * @buf: EDID data buffer to be filled
+ * @block: 128 byte EDID block to start fetching from
+ * @len: EDID data buffer length to fetch
+ *
+ * Try to fetch EDID information by calling acpi_video_get_edid()
function.
+ *
+ * Return: 0 on success or error code on failure.
+ */
+static int
+drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block,
size_t len)
+{
+ struct drm_connector *connector = data;
+ struct drm_device *ddev = connector->dev;
+ struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
+ unsigned char start = block * EDID_LENGTH;
+ void *edid;
+ int r;
+
+ if (!acpidev)
+ return -ENODEV;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* fetch the entire edid from BIOS */
+ if (IS_REACHABLE(CONFIG_DRM_ACPI_HELPER)) {
+ r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1,
);
+ if (r < 0) {
+ DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+ return -EINVAL;
+ }
+ } else {
+ r = -EOPNOTSUPP;
+ }
+ if (len > r || start > r || start + len > r) {
+ r = -EINVAL;
+ goto cleanup;
+ }
+
+ memcpy(buf, edid + start, len);
+ r = 0;
+
+cleanup:
+ kfree(edid);
+
+ return r;
+}
+
static void connector_bad_edid(struct drm_connector *connector,
const struct edid *edid, int num_blocks)
{
@@ -2621,7 +2678,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
* @connector: connector we're probing
* @adapter: I2C adapter to use for DDC
*
- * Poke the given I2C channel to grab EDID data if possible. If found,
+ * If the connector allows it, try
[PATCH 2/2] [v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
that have printf-like logs from GSP-RM and PMU encoded in them.
LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA
addresses are passed to GSP-RM during initialization. The buffers are
required for GSP-RM to initialize properly.
LOGPMU is also allocated by Nouveau, but its contents are updated
when Nouveau receives an NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT RPC from
GSP-RM. Nouveau then copies the RPC to the buffer.
The messages are encoded as an array of variable-length structures that
contain the parameters to an NV_PRINTF call. The format string and
parameter count are stored in a special ELF image that contains only
logging strings. This image is not currently shipped with the Nvidia
driver.
There are two methods to extract the logs.
OpenRM tries to load the logging ELF, and if present, parses the log
buffers in real time and outputs the strings to the kernel console.
Alternatively, and this is the method used by this patch, the buffers
can be exposed to user space, and a user-space tool (along with the
logging ELF image) can parse the buffer and dump the logs.
This method has the advantage that it allows the buffers to be parsed
even when the logging ELF file is not available to the user. However,
it has the disadvantage the debubfs entries need to remain until the
driver is unloaded.
The buffers are exposed via debugfs. The debugfs entries must be
created before GSP-RM is started, to ensure that they are available
during GSP-RM initialization.
If GSP-RM fails to initialize, then Nouveau immediately shuts down
the GSP interface. This would normally also deallocate the logging
buffers, thereby preventing the user from capturing the debug logs.
To avoid this, the keep-gsp-logging command line parameter can be
specified. This parmater is marked as *unsafe* (thereby taining the
kernel) because the DMA buffer and debugfs entries are never
deallocated, even if the driver unloads. This gives the user the
time to capture the logs, but it also means that resources can only
be recovered by a reboot.
An end-user can capture the logs using the following commands:
cp /sys/kernel/debug/dri//loginit loginit
cp /sys/kernel/debug/dri//logrm logrm
cp /sys/kernel/debug/dri//logintr logintr
cp /sys/kernel/debug/dri//logpmu logpmu
where is the PCI ID of the GPU (e.g. :65:00.0). If
keep-gsp-logging is specified, then the is the same but with
-debug appended (e.g. :65:00.0-debug).
Since LOGPMU is not needed for normal GSP-RM operation, it is only
created if debugfs is available. Otherwise, the
NV_VGPU_MSG_EVENT_UCODE_LIBOS_PRINT RPCs are ignored.
Signed-off-by: Timur Tabi
---
v3: reworked r535_gsp_libos_debugfs_init, rebased for drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 12 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 215 +-
2 files changed, 223 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 3fbc57b16a05..2ee44bdf8be7 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -5,6 +5,8 @@
#include
#include
+#include
+
#define GSP_PAGE_SHIFT 12
#define GSP_PAGE_SIZE BIT(GSP_PAGE_SHIFT)
@@ -217,6 +219,16 @@ struct nvkm_gsp {
/* The size of the registry RPC */
size_t registry_rpc_size;
+
+ /*
+* Logging buffers in debugfs. The wrapper objects need to remain
+* in memory until the dentry is deleted.
+*/
+ struct debugfs_blob_wrapper blob_init;
+ struct debugfs_blob_wrapper blob_intr;
+ struct debugfs_blob_wrapper blob_rm;
+ struct debugfs_blob_wrapper blob_pmu;
+ struct dentry *debugfs_logging_dir;
};
static inline bool
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 86b62c7e1229..56209bf81360 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -1979,6 +1980,196 @@ r535_gsp_rmargs_init(struct nvkm_gsp *gsp, bool resume)
return 0;
}
+#define NV_GSP_MSG_EVENT_UCODE_LIBOS_CLASS_PMU 0xf3d722
+
+/**
+ * r535_gsp_msg_libos_print - capture log message from the PMU
+ * @priv: gsp pointer
+ * @fn: function number (ignored)
+ * @repv: pointer to libos print RPC
+ * @repc: message size
+ *
+ * See _kgspRpcUcodeLibosPrint
+ */
+static int r535_gsp_msg_libos_print(void *priv, u32 fn, void *repv, u32 repc)
+{
+ struct nvkm_gsp *gsp = priv;
+ struct nvkm_subdev *subdev = >subdev;
+ struct {
+ u32 ucodeEngDesc;
+ u32 libosPrintBufSize;
+ u8 libosPrintBuf[];
+ } *rpc = repv;
+ unsigned int class = rpc->ucodeEngDesc >> 8;
[PATCH 1/2] [v3] nouveau: add command-line GSP-RM registry support
Add the NVreg_RegistryDwords command line parameter, which allows
specifying additional registry keys to be sent to GSP-RM. This
allows additional configuration, debugging, and experimentation
with GSP-RM, which uses these keys to alter its behavior.
Note that these keys are passed as-is to GSP-RM, and Nouveau does
not parse them. This is in contrast to the Nvidia driver, which may
parse some of the keys to configure some functionality in concert with
GSP-RM. Therefore, any keys which also require action by the driver
may not function correctly when passed by Nouveau. Caveat emptor.
The name and format of NVreg_RegistryDwords is the same as used by
the Nvidia driver, to maintain compatibility.
Signed-off-by: Timur Tabi
---
v3: rebased to drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 279 --
2 files changed, 261 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index 6f5d376d8fcc..3fbc57b16a05 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -211,6 +211,12 @@ struct nvkm_gsp {
struct mutex mutex;;
struct idr idr;
} client_id;
+
+ /* A linked list of registry items. The registry RPC will be built from
it. */
+ struct list_head registry_list;
+
+ /* The size of the registry RPC */
+ size_t registry_rpc_size;
};
static inline bool
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 1c46e3f919be..86b62c7e1229 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -54,6 +54,8 @@
#include
#include
+#include
+#include
#define GSP_MSG_MIN_SIZE GSP_PAGE_SIZE
#define GSP_MSG_MAX_SIZE GSP_PAGE_MIN_SIZE * 16
@@ -1082,51 +1084,280 @@ r535_gsp_rpc_unloading_guest_driver(struct nvkm_gsp
*gsp, bool suspend)
return nvkm_gsp_rpc_wr(gsp, rpc, true);
}
+struct registry_list_entry {
+ struct list_head list;
+ size_t name_len;
+ u32 type;
+ u32 data;
+ u32 length;
+ char name[];
+};
+
+/**
+ * add_registry -- adds a registry entry
+ * @gsp: gsp pointer
+ * @name: name of the registry key
+ * @type: type of data (1 = integer)
+ * @data: value
+ * @length: size of data, in bytes
+ *
+ * Adds a registry key/value pair to the registry database.
+ *
+ * Currently, only 32-bit integers (type == 1, length == 4) are supported.
+ *
+ * This function collects the registry information in a linked list. After
+ * all registry keys have been added, build_registry() is used to create the
+ * RPC data structure.
+ *
+ * registry_rpc_size is a running total of the size of all registry keys.
+ * It's used to avoid an O(n) calculation of the size when the RPC is built.
+ *
+ * Returns 0 on success, or negative error code on error.
+ */
+static int add_registry(struct nvkm_gsp *gsp, const char *name, u32 type, u32
data, u32 length)
+{
+ struct registry_list_entry *reg;
+ size_t nlen = strlen(name) + 1;
+
+ /* Set an arbitrary limit to avoid problems with broken command lines */
+ if (strlen(name) > 64)
+ return -EFBIG;
+
+ reg = kmalloc(sizeof(struct registry_list_entry) + nlen, GFP_KERNEL);
+ if (!reg)
+ return -ENOMEM;
+
+ memcpy(reg->name, name, nlen);
+ reg->name_len = nlen;
+ reg->type = type;
+ reg->data = data;
+ reg->length = length;
+
+ nvkm_debug(>subdev, "adding GSP-RM registry '%s=%u'\n", name,
data);
+ list_add_tail(>list, >registry_list);
+ gsp->registry_rpc_size += sizeof(PACKED_REGISTRY_ENTRY) + nlen;
+
+ return 0;
+}
+
+static int add_registry_num(struct nvkm_gsp *gsp, const char *name, u32 value)
+{
+ return add_registry(gsp, name, 1, value, sizeof(u32));
+}
+
+/**
+ * build_registry -- create the registry RPC data
+ * @gsp: gsp pointer
+ * @registry: pointer to the RPC payload to fill
+ *
+ * After all registry key/value pairs have been added, call this function to
+ * build the RPC.
+ *
+ * The registry RPC looks like this:
+ *
+ * +-+
+ * |NvU32 size; |
+ * |NvU32 numEntries;|
+ * +-+
+ * +-+
+ * |PACKED_REGISTRY_ENTRY|
+ * +-+
+ * |PACKED_REGISTRY_ENTRY|
+ * +-+
+ * ... (one copy for each entry)
+ *
+ * +--+
+ * |Null-terminated string for entry 0|
+ * +--+
+ * |Null-terminated string for entry 1|
+ * +--+
+ * ... (one copy for each entry)
+ *
+ * All memory allocated by add_registry() is released.
+ */
+static void build_registry(struct nvkm_gsp *gsp, PACKED_REGISTRY_TABLE
*registry)
+{
+ struct
[drm-next][PATCH 0/2] command-line registry and gsp-rm logging
Two patches that were previosly posted, but now updated for drm-next. Timur Tabi (2): [v3] nouveau: add command-line GSP-RM registry support [v3] drm/nouveau: expose GSP-RM logging buffers via debugfs .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 18 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 494 +- 2 files changed, 484 insertions(+), 28 deletions(-) -- 2.34.1
Re: [PATCH 2/7] drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support
On 2/12/2024 10:49 AM, Chris Morgan wrote:
From: Chris Morgan
The Powkiddy RGB10MAX3 is a handheld device with a 5 inch 720x1280
display panel with a Sitronix ST7703 display controller. The panel
is installed rotated 270 degrees.
Signed-off-by: Chris Morgan
Hi Chris,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 91 +++
1 file changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b55bafd1a8be..939ba05c9b58 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -521,6 +521,96 @@ static const struct st7703_panel_desc rgb30panel_desc = {
.init_sequence = rgb30panel_init_sequence,
};
+static int rgb10max3_panel_init_sequence(struct st7703 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ /* Init sequence extracted from Powkiddy RGB10MAX3 BSP kernel. */
+
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xf1, 0x12, 0x83);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETAPID, 0x00, 0x00, 0x00, 0xda,
+ 0x80);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0xc8, 0x02, 0x30);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, 0x10, 0x10, 0x28,
+ 0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x04, 0x04);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x78, 0x78);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22, 0xf0,
+ 0x63);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, 0x33, 0x81, 0x05, 0xf9,
+ 0x0e, 0x0e, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x44, 0x25, 0x00, 0x90, 0x0a, 0x00,
+ 0x00, 0x01, 0x4f, 0x01, 0x00, 0x00, 0x37);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x47);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, 0x73, 0x73, 0x50, 0x50,
+ 0x00, 0x00, 0x12, 0x70, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, 0x25, 0x00, 0x32,
+ 0x32, 0x77, 0xe1, 0xff, 0xff, 0xcc, 0xcc, 0x77,
+ 0x77);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x82, 0x00, 0xbf, 0xff,
+ 0x00, 0xff);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETIO, 0xb8, 0x00, 0x0a, 0x00,
+ 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCABC, 0x10, 0x40, 0x1e,
+ 0x02);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0b);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, 0x00, 0x04, 0x07,
+ 0x2a, 0x39, 0x3f, 0x36, 0x31, 0x06, 0x0b, 0x0e,
+ 0x12, 0x14, 0x12, 0x13, 0x0f, 0x17, 0x00, 0x04,
+ 0x07, 0x2a, 0x39, 0x3f, 0x36, 0x31, 0x06, 0x0b,
+ 0x0e, 0x12, 0x14, 0x12, 0x13, 0x0f, 0x17);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ, 0x03, 0x03, 0x03, 0x03,
+ 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0xff, 0x80,
+ 0xc0, 0x10);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, 0xc8, 0x10, 0x08, 0x00,
+ 0x00, 0x41, 0xf8, 0x12, 0x31, 0x23, 0x37, 0x86,
+ 0x11, 0xc8, 0x37, 0x2a, 0x00, 0x00, 0x0c, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00,
+ 0x88, 0x20, 0x46, 0x02, 0x88, 0x88, 0x88, 0x88,
+ 0x88, 0x88, 0xff, 0x88, 0x31, 0x57, 0x13, 0x88,
+ 0x88, 0x88, 0x88, 0x88, 0x88, 0xff, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, 0x00, 0x1a, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x8f, 0x13, 0x31, 0x75, 0x88, 0x88, 0x88, 0x88,
+ 0x88, 0x88, 0xf8, 0x8f, 0x02, 0x20, 0x64, 0x88,
+ 0x88, 0x88, 0x88, 0x88, 0x88, 0xf8, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_EF, 0xff,
Re: [PATCH v2 19/19] drm/msm/dp: allow YUV420 mode for DP connector when CDM available
On 2/10/2024 1:17 PM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 21:19, Abhinav Kumar wrote:
On 2/10/2024 3:33 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote:
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v2:
- Check for if dp_catalog has a CDM block available instead of
checking if VSC SDP is allowed when setting the dp connector's
ycbcr_420_allowed parameter
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++-
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_drm.c | 8 ++--
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.h | 5 +++--
5 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 723cc1d821431..beeaabe499abf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -565,6 +565,7 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
{
struct drm_encoder *encoder = NULL;
struct msm_display_info info;
+ bool yuv_supported;
int rc;
int i;
@@ -583,7 +584,8 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
return PTR_ERR(encoder);
}
- rc = msm_dp_modeset_init(priv->dp[i], dev, encoder);
+ yuv_supported = !!(dpu_kms->catalog->cdm);
Drop parentheses please.
+ rc = msm_dp_modeset_init(priv->dp[i], dev, encoder,
yuv_supported);
if (rc) {
DPU_ERROR("modeset_init failed for DP, rc = %d\n",
rc);
return rc;
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index ebcc76ef1d590..9b9f5f2921903 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1471,7 +1471,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
}
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder, bool yuv_supported)
{
struct dp_display_private *dp_priv;
int ret;
@@ -1487,7 +1487,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return ret;
}
- dp_display->connector = dp_drm_connector_init(dp_display, encoder);
+ dp_display->connector = dp_drm_connector_init(dp_display, encoder,
yuv_supported);
if (IS_ERR(dp_display->connector)) {
ret = PTR_ERR(dp_display->connector);
DRM_DEV_ERROR(dev->dev,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 46e6889037e88..ab0d0d13b5e2c 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -353,7 +353,8 @@ int dp_bridge_init(struct msm_dp *dp_display, struct
drm_device *dev,
}
/* connector initialization */
-struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder)
+struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder,
+ bool yuv_supported)
{
struct drm_connector *connector = NULL;
@@ -361,8 +362,11 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display, struct dr
if (IS_ERR(connector))
return connector;
- if (!dp_display->is_edp)
+ if (!dp_display->is_edp) {
drm_connector_attach_dp_subconnector_property(connector);
+ if (yuv_supported)
+ connector->ycbcr_420_allowed = true;
Is there any reason to disallow YUV420 for eDP connectors?
+ }
Major reason was certainly validation but thinking about it more
closely, I need to check whether CDM over eDP is even possible.
Historically, CDM could output only to HDMI OR WB using the bit we
program while setting up CDM and the same HDMI path is being used by DP
as well. But I need to check whether CDM can even output to eDP with the
same DP path. I dont have any documentation on this part yet.
I had the feeling that the DP / eDP difference on the chips is mostly
on the PHY and software side. So I assumed that it should be possible
to output YUV data to the eDP port in the same way as it is done for
the DP port.
This is true. I was not worried about DP / eDP controller but mostly
whether eDP spec really allows YUV. From what I can read, it does.
So this check shall remain only because CDM has not been validated with eDP.
Do
[PATCH 4/6] drm/amdgpu: add shared fdinfo stats
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
v3: use the new gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 6 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 5706b282a0c7..c7df7fa3459f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p, struct
drm_file *file)
stats.requested_visible_vram/1024UL);
drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
stats.requested_gtt/1024UL);
+ drm_printf(p, "drm-shared-vram:\t%llu KiB\n", stats.vram_shared/1024UL);
+ drm_printf(p, "drm-shared-gtt:\t%llu KiB\n", stats.gtt_shared/1024UL);
+ drm_printf(p, "drm-shared-cpu:\t%llu KiB\n", stats.cpu_shared/1024UL);
+
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 425cebcc5cbf..e6f69fce539b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1276,25 +1276,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
struct amdgpu_mem_stats *stats)
{
uint64_t size = amdgpu_bo_size(bo);
+ struct drm_gem_object *obj;
unsigned int domain;
+ bool shared;
/* Abort if the BO doesn't currently have a backing store */
if (!bo->tbo.resource)
return;
+ obj = >tbo.base;
+ shared = drm_gem_object_is_shared_for_memory_stats(obj);
+
domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
switch (domain) {
case AMDGPU_GEM_DOMAIN_VRAM:
stats->vram += size;
if (amdgpu_bo_in_cpu_visible_vram(bo))
stats->visible_vram += size;
+ if (shared)
+ stats->vram_shared += size;
break;
case AMDGPU_GEM_DOMAIN_GTT:
stats->gtt += size;
+ if (shared)
+ stats->gtt_shared += size;
break;
case AMDGPU_GEM_DOMAIN_CPU:
default:
stats->cpu += size;
+ if (shared)
+ stats->cpu_shared += size;
break;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index a3ea8a82db23..be679c42b0b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
struct amdgpu_mem_stats {
/* current VRAM usage, includes visible VRAM */
uint64_t vram;
+ /* current shared VRAM usage, includes visible VRAM */
+ uint64_t vram_shared;
/* current visible VRAM usage */
uint64_t visible_vram;
/* current GTT usage */
uint64_t gtt;
+ /* current shared GTT usage */
+ uint64_t gtt_shared;
/* current system memory usage */
uint64_t cpu;
+ /* current shared system memory usage */
+ uint64_t cpu_shared;
/* sum of evicted buffers, includes visible VRAM */
uint64_t evicted_vram;
/* sum of evicted buffers due to CPU access */
--
2.42.0
[PATCH 6/6] drm/xe: Update shared stats to use the new gem helper
Switch to using the new gem shared memory stats helper rather than hand rolling it. Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/ Signed-off-by: Alex Deucher --- drivers/gpu/drm/xe/xe_drm_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_drm_client.c b/drivers/gpu/drm/xe/xe_drm_client.c index 82d1305e831f..ecf2eb67d310 100644 --- a/drivers/gpu/drm/xe/xe_drm_client.c +++ b/drivers/gpu/drm/xe/xe_drm_client.c @@ -113,7 +113,7 @@ static void bo_meminfo(struct xe_bo *bo, else mem_type = XE_PL_TT; - if (bo->ttm.base.handle_count > 1) + if (drm_gem_object_is_shared_for_memory_stats(>ttm.base)) stats[mem_type].shared += sz; else stats[mem_type].private += sz; -- 2.42.0
[PATCH 2/6] drm: add drm_gem_object_is_shared_for_memory_stats() helper
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
v2: switch to inline function
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Tvrtko Ursulin (v1)
Signed-off-by: Alex Deucher
---
include/drm/drm_gem.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 369505447acd..2ebec3984cd4 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -553,6 +553,19 @@ unsigned long drm_gem_lru_scan(struct drm_gem_lru *lru,
int drm_gem_evict(struct drm_gem_object *obj);
+/**
+ * drm_gem_object_is_shared_for_memory_stats - helper for shared memory stats
+ *
+ * This helper should only be used for fdinfo shared memory stats to determine
+ * if a GEM object is shared.
+ *
+ * @obj: obj in question
+ */
+static inline bool drm_gem_object_is_shared_for_memory_stats(struct
drm_gem_object *obj)
+{
+ return (obj->handle_count > 1) || obj->dma_buf;
+}
+
#ifdef CONFIG_LOCKDEP
/**
* drm_gem_gpuva_set_lock() - Set the lock protecting accesses to the gpuva
list.
--
2.42.0
[PATCH 5/6] drm/i915: Update shared stats to use the new gem helper
Switch to using the new gem shared memory stats helper rather than hand rolling it. Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/ Reviewed-by: Tvrtko Ursulin Signed-off-by: Alex Deucher --- drivers/gpu/drm/i915/i915_drm_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c index fa6852713bee..f58682505491 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.c +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -53,7 +53,7 @@ obj_meminfo(struct drm_i915_gem_object *obj, obj->mm.region->id : INTEL_REGION_SMEM; const u64 sz = obj->base.size; - if (obj->base.handle_count > 1) + if (drm_gem_object_is_shared_for_memory_stats(>base)) stats[id].shared += sz; else stats[id].private += sz; -- 2.42.0
[PATCH 1/6] Documentation/gpu: Update documentation on drm-shared-*
Clarify the documentation in preparation for updated helpers which check the handle count as well as whether a dma-buf has been attached. Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/ Reviewed-by: Tvrtko Ursulin Signed-off-by: Alex Deucher --- Documentation/gpu/drm-usage-stats.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 7aca5c7a7b1d..6dc299343b48 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -138,7 +138,7 @@ indicating kibi- or mebi-bytes. - drm-shared-: [KiB|MiB] -The total size of buffers that are shared with another file (ie. have more +The total size of buffers that are shared with another file (e.g., have more than a single handle). - drm-total-: [KiB|MiB] -- 2.42.0
[PATCH 3/6] drm: update drm_show_memory_stats() for dma-bufs
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
v2: switch to gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Rob Clark (v1)
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/drm_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 8c87287c3e16..638ffaf5 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -913,7 +913,7 @@ void drm_show_memory_stats(struct drm_printer *p, struct
drm_file *file)
DRM_GEM_OBJECT_PURGEABLE;
}
- if (obj->handle_count > 1) {
+ if (drm_gem_object_is_shared_for_memory_stats(obj)) {
status.shared += obj->size;
} else {
status.private += obj->size;
--
2.42.0
[PATCH 0/6 V4] fdinfo shared stats
We had a request to add shared buffer stats to fdinfo for amdgpu and while implementing that, Christian mentioned that just looking at the GEM handle count doesn't take into account buffers shared with other subsystems like V4L or RDMA. Those subsystems don't use GEM, so it doesn't really matter from a GPU top perspective, but it's more correct if you actually want to see shared buffers. After further discussions, add a helper and update all fdinfo implementations to use that helper for consistency. v4: switch drm_gem_object_is_shared_for_memory_stats() to an inline function Alex Deucher (6): Documentation/gpu: Update documentation on drm-shared-* drm: add drm_gem_object_is_shared_for_memory_stats() helper drm: update drm_show_memory_stats() for dma-bufs drm/amdgpu: add shared fdinfo stats drm/i915: Update shared stats to use the new gem helper drm/xe: Update shared stats to use the new gem helper Documentation/gpu/drm-usage-stats.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 6 ++ drivers/gpu/drm/drm_file.c | 2 +- drivers/gpu/drm/i915/i915_drm_client.c | 2 +- drivers/gpu/drm/xe/xe_drm_client.c | 2 +- include/drm/drm_gem.h | 13 + 8 files changed, 38 insertions(+), 4 deletions(-) -- 2.42.0
[drm-misc:for-linux-next 40/49] drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c:317:48: error: passing argument 1 of 'drm_err_printer' from incompatible pointer type
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 247f2ee4498cfcaf18b3c3486dffd2302d56fc17
commit: 5e0c04c8c40b69ab165d52964433859d8b666376 [40/49] drm/print: make
drm_err_printer() device specific by using drm_err()
config: alpha-allyesconfig
(https://download.01.org/0day-ci/archive/20240213/202402130446.4sbrcdzh-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240213/202402130446.4sbrcdzh-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402130446.4sbrcdzh-...@intel.com/
Note: the drm-misc/for-linux-next HEAD 247f2ee4498cfcaf18b3c3486dffd2302d56fc17
builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c: In function
'xe_gt_tlb_invalidation_wait':
>> drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c:317:48: error: passing argument
>> 1 of 'drm_err_printer' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
317 | struct drm_printer p = drm_err_printer(__func__);
|^~~~
||
|const char *
In file included from include/drm/ttm/ttm_resource.h:34,
from include/drm/ttm/ttm_device.h:30,
from drivers/gpu/drm/xe/xe_device_types.h:13,
from drivers/gpu/drm/xe/xe_device.h:15,
from drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c:9:
include/drm/drm_print.h:247:69: note: expected 'struct drm_device *' but
argument is of type 'const char *'
247 | static inline struct drm_printer drm_err_printer(struct drm_device
*drm,
|
~~~^~~
>> drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c:317:32: error: too few arguments
>> to function 'drm_err_printer'
317 | struct drm_printer p = drm_err_printer(__func__);
|^~~
include/drm/drm_print.h:247:34: note: declared here
247 | static inline struct drm_printer drm_err_printer(struct drm_device
*drm,
| ^~~
cc1: some warnings being treated as errors
vim +/drm_err_printer +317 drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
a9351846d94568 Matthew Brost 2023-01-17 302
c6b0948ff8d084 Matthew Brost 2023-01-20 303 /**
c6b0948ff8d084 Matthew Brost 2023-01-20 304 * xe_gt_tlb_invalidation_wait -
Wait for TLB to complete
c6b0948ff8d084 Matthew Brost 2023-01-20 305 * @gt: graphics tile
c6b0948ff8d084 Matthew Brost 2023-01-20 306 * @seqno: seqno to wait which
was returned from xe_gt_tlb_invalidation
c6b0948ff8d084 Matthew Brost 2023-01-20 307 *
c6b0948ff8d084 Matthew Brost 2023-01-20 308 * Wait for 200ms for a TLB
invalidation to complete, in practice we always
c6b0948ff8d084 Matthew Brost 2023-01-20 309 * should receive the TLB
invalidation within 200ms.
c6b0948ff8d084 Matthew Brost 2023-01-20 310 *
c6b0948ff8d084 Matthew Brost 2023-01-20 311 * Return: 0 on success, -ETIME
on TLB invalidation timeout
c6b0948ff8d084 Matthew Brost 2023-01-20 312 */
a9351846d94568 Matthew Brost 2023-01-17 313 int
xe_gt_tlb_invalidation_wait(struct xe_gt *gt, int seqno)
a9351846d94568 Matthew Brost 2023-01-17 314 {
a9351846d94568 Matthew Brost 2023-01-17 315 struct xe_device *xe =
gt_to_xe(gt);
a9351846d94568 Matthew Brost 2023-01-17 316 struct xe_guc *guc =
>uc.guc;
ebb00b285bef8b Pallavi Mishra 2023-11-01 @317 struct drm_printer p =
drm_err_printer(__func__);
a9351846d94568 Matthew Brost 2023-01-17 318 int ret;
a9351846d94568 Matthew Brost 2023-01-17 319
a9351846d94568 Matthew Brost 2023-01-17 320 /*
a9351846d94568 Matthew Brost 2023-01-17 321* XXX: See above, this
algorithm only works if seqno are always in
a9351846d94568 Matthew Brost 2023-01-17 322* order
a9351846d94568 Matthew Brost 2023-01-17 323*/
a9351846d94568 Matthew Brost 2023-01-17 324 ret =
wait_event_timeout(guc->ct.wq,
a9351846d94568 Matthew Brost 2023-01-17 325
tlb_invalidation_seqno_past(gt, seqno),
38224c00d9c284 Matthew Brost 2023-01-24 326
TLB_TIMEOUT);
a9351846d94568 Matthew Brost 2023-01-17 327 if (!ret) {
a5cecbac92d5a5 Nirmoy Das 2023-05-05 328 drm_err(>drm,
"gt%d: TLB invalidation time'd out, seqno=%d, recv=%d\n",
a5cecbac92d5a5 Nirmoy Das 2023-05-05 329 gt->info.id,
seqno, gt->tlb_invalidation.seqno_recv);
ebb00b285bef8b Pallavi Mishra 2023-11-01 330
[PATCH 0/2] leds: expresswire: Fix dependencies
LEDS_EXPRESSWIRE does not depend on NEW_LEDS in practice but still does in Kconfig. Fix up its Kconfig entry to reflect this and fix a Kconfig warning. Signed-off-by: Duje Mihanović --- Duje Mihanović (2): Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set" leds: expresswire: don't depend on NEW_LEDS drivers/Makefile | 2 +- drivers/leds/Kconfig | 10 ++ 2 files changed, 7 insertions(+), 5 deletions(-) --- base-commit: ae00c445390b349e070a64dc62f08aa878db7248 change-id: 20240212-expresswire-deps-e895e8da8ea3 Best regards, -- Duje Mihanović
[PATCH 1/2] Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set"
This reverts commit b1ae40a5db6191c42e2e45d726407096f030ee08.
The ExpressWire library introduced in 25ae5f5f4168 ("leds: Introduce
ExpressWire library") does not depend on NEW_LEDS, but without this
revert it would never get compiled if NEW_LEDS is not enabled. Revert
this commit to allow the library to be compiled.
Link:
https://lore.kernel.org/2cacd8dc-6150-4aa2-af9e-830a202fb...@app.fastmail.com
Suggested-by: Arnd Bergmann
Signed-off-by: Duje Mihanović
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index 37fd6ce3bd7f..3bf5cab4b451 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -135,7 +135,7 @@ obj-$(CONFIG_CPU_IDLE) += cpuidle/
obj-y += mmc/
obj-y += ufs/
obj-$(CONFIG_MEMSTICK) += memstick/
-obj-$(CONFIG_NEW_LEDS) += leds/
+obj-y += leds/
obj-$(CONFIG_INFINIBAND) += infiniband/
obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
--
2.43.1
[PATCH 2/2] leds: expresswire: don't depend on NEW_LEDS
The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
Move it out of the "if NEW_LEDS" block to allow selection from other
subsystems (in particular backlight) without raising this warning.
Link: https://lore.kernel.org/20240212111819.936815-1-a...@kernel.org
Reported-by: Arnd Bergmann
Suggested-by: Daniel Thompson
Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library")
Signed-off-by: Duje Mihanović
---
drivers/leds/Kconfig | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 52328d295b4e..66998b938ed3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -6,6 +6,12 @@ config LEDS_GPIO_REGISTER
As this function is used by arch code it must not be compiled as a
module.
+# This library does not depend on NEW_LEDS and must be independent so it can be
+# selected from other subsystems (specifically backlight).
+config LEDS_EXPRESSWIRE
+ bool
+ depends on GPIOLIB
+
menuconfig NEW_LEDS
bool "LED Support"
help
@@ -186,10 +192,6 @@ config LEDS_EL15203000
To compile this driver as a module, choose M here: the module
will be called leds-el15203000.
-config LEDS_EXPRESSWIRE
- bool
- depends on GPIOLIB
-
config LEDS_TURRIS_OMNIA
tristate "LED support for CZ.NIC's Turris Omnia"
depends on LEDS_CLASS_MULTICOLOR
--
2.43.1
Re: [PATCH 2/7] fbdev: Do not include in header
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.8-rc4 next-20240212]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/drm-nouveau-Include-linux-backlight-h/20240212-181930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240212101712.23675-3-tzimmermann%40suse.de
patch subject: [PATCH 2/7] fbdev: Do not include in header
config: riscv-allmodconfig
(https://download.01.org/0day-ci/archive/20240213/202402130346.2ignwgde-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
c08b90c50bcac9f3f563c79491c8dbcbe7c3b574)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240213/202402130346.2ignwgde-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402130346.2ignwgde-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fb_ssd1351.c:192:26: error: call to undeclared
>> function 'bl_get_data'; ISO C99 and later do not support implicit function
>> declarations [-Wimplicit-function-declaration]
192 | struct fbtft_par *par = bl_get_data(bd);
| ^
>> drivers/staging/fbtft/fb_ssd1351.c:192:20: error: incompatible integer to
>> pointer conversion initializing 'struct fbtft_par *' with an expression of
>> type 'int' [-Wint-conversion]
192 | struct fbtft_par *par = bl_get_data(bd);
| ^ ~~~
>> drivers/staging/fbtft/fb_ssd1351.c:197:21: error: incomplete definition of
>> type 'struct backlight_device'
197 | __func__, bd->props.power, bd->props.fb_blank);
| ~~^
drivers/staging/fbtft/fbtft.h:433:43: note: expanded from macro
'fbtft_par_dbg'
433 | dev_info((par)->info->device, format, ##arg); \
| ^~~
include/linux/dev_printk.h:150:67: note: expanded from macro 'dev_info'
150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev,
dev_fmt(fmt), ##__VA_ARGS__)
|
^~~
include/linux/dev_printk.h:110:23: note: expanded from macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
include/linux/fb.h:20:8: note: forward declaration of 'struct
backlight_device'
20 | struct backlight_device;
|^
drivers/staging/fbtft/fb_ssd1351.c:197:38: error: incomplete definition of
type 'struct backlight_device'
197 | __func__, bd->props.power, bd->props.fb_blank);
| ~~^
drivers/staging/fbtft/fbtft.h:433:43: note: expanded from macro
'fbtft_par_dbg'
433 | dev_info((par)->info->device, format, ##arg); \
| ^~~
include/linux/dev_printk.h:150:67: note: expanded from macro 'dev_info'
150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev,
dev_fmt(fmt), ##__VA_ARGS__)
|
^~~
include/linux/dev_printk.h:110:23: note: expanded from macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
include/linux/fb.h:20:8: note: forward declaration of 'struct
backlight_device'
20 | struct backlight_device;
|^
>> drivers/staging/fbtft/fb_ssd1351.c:199:8: error: call to undeclared function
>> 'backlight_is_blank'; ISO C99 and later do not support implicit function
>> declarations [-Wimplicit-function-declaration]
199 | on = !backlight_is_blank(bd);
| ^
>> drivers/staging/fbtft/fb_ssd1351.c:206:35: error: variable has incomplete
>> type 'const struct backlight_ops'
206 | static const struct backlight_ops bl_ops = {
| ^
drivers/staging/fbtft/fb_ssd1351.c:206:21: note: forward declaration of
'struct backlight_ops'
206 | static const struct b
Re: [PATCH 2/7] fbdev: Do not include in header
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.8-rc4 next-20240212]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/drm-nouveau-Include-linux-backlight-h/20240212-181930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240212101712.23675-3-tzimmermann%40suse.de
patch subject: [PATCH 2/7] fbdev: Do not include in header
config: openrisc-allyesconfig
(https://download.01.org/0day-ci/archive/20240213/202402130207.8zfxceys-...@intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240213/202402130207.8zfxceys-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402130207.8zfxceys-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/staging/fbtft/fb_ssd1351.c: In function 'update_onboard_backlight':
drivers/staging/fbtft/fb_ssd1351.c:192:33: error: implicit declaration of
function 'bl_get_data'; did you mean 'acpi_get_data'?
[-Werror=implicit-function-declaration]
192 | struct fbtft_par *par = bl_get_data(bd);
| ^~~
| acpi_get_data
>> drivers/staging/fbtft/fb_ssd1351.c:192:33: warning: initialization of
>> 'struct fbtft_par *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
In file included from include/linux/device.h:15,
from include/linux/acpi.h:14,
from include/linux/spi/spi.h:9,
from drivers/staging/fbtft/fb_ssd1351.c:5:
drivers/staging/fbtft/fb_ssd1351.c:197:35: error: invalid use of undefined
type 'struct backlight_device'
197 | __func__, bd->props.power, bd->props.fb_blank);
| ^~
include/linux/dev_printk.h:110:37: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
drivers/staging/fbtft/fbtft.h:433:17: note: in expansion of macro 'dev_info'
433 | dev_info((par)->info->device, format, ##arg); \
| ^~~~
drivers/staging/fbtft/fb_ssd1351.c:195:9: note: in expansion of macro
'fbtft_par_dbg'
195 | fbtft_par_dbg(DEBUG_BACKLIGHT, par,
| ^
drivers/staging/fbtft/fb_ssd1351.c:197:52: error: invalid use of undefined
type 'struct backlight_device'
197 | __func__, bd->props.power, bd->props.fb_blank);
|^~
include/linux/dev_printk.h:110:37: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
drivers/staging/fbtft/fbtft.h:433:17: note: in expansion of macro 'dev_info'
433 | dev_info((par)->info->device, format, ##arg); \
| ^~~~
drivers/staging/fbtft/fb_ssd1351.c:195:9: note: in expansion of macro
'fbtft_par_dbg'
195 | fbtft_par_dbg(DEBUG_BACKLIGHT, par,
| ^
drivers/staging/fbtft/fb_ssd1351.c:199:15: error: implicit declaration of
function 'backlight_is_blank' [-Werror=implicit-function-declaration]
199 | on = !backlight_is_blank(bd);
| ^~
drivers/staging/fbtft/fb_ssd1351.c: At top level:
drivers/staging/fbtft/fb_ssd1351.c:206:21: error: variable 'bl_ops' has
initializer but incomplete type
206 | static const struct backlight_ops bl_ops = {
| ^
drivers/staging/fbtft/fb_ssd1351.c:207:10: error: 'const struct
backlight_ops' has no member named 'update_status'
207 | .update_status = update_onboard_backlight,
| ^
>> drivers/staging/fbtft/fb_ssd1351.c:207:26: warning: excess elements in
>> struct initializer
207 | .update_status = update_onboard_backlight,
| ^~~~
drivers/staging/fbtft/fb_ssd1351.c:207:26: note: (near initialization for
'bl_ops')
drivers/staging/fbtft/fb_ssd1351.c: In function 'register_onbo
Re: [PATCH] backlight: ktd2801: fix LED dependency
On Mon, Feb 12, 2024, at 15:31, Duje Mihanović wrote: > On Monday, February 12, 2024 1:44:28 PM CET Daniel Thompson wrote: >> On Mon, Feb 12, 2024 at 12:18:12PM +0100, Arnd Bergmann wrote: > I believe this would be the best thing to do here. Making LEDS_EXPRESSWIRE > user selectable doesn't make much sense to me as the library is rather low- > level (a quick grep turns up BTREE as an example of something similar) and > IMO > the GPIOLIB dependency should be handled by LEDS_EXPRESSWIRE as it's the one > actually using the GPIO interface (except maybe for KTD2692 as it has some > extra GPIOs not present in the other one and thus handles them itself). Agree, let's do it this way. Maybe the leds-expresswire.c file should not be in drivers/leds either, but it's already there and I can't think of a better place for it.so just adapting Kconfig should be enough. Please add the corresponding Makefile change as well though: --- a/drivers/Makefile +++ b/drivers/Makefile @@ -135,7 +135,7 @@ obj-$(CONFIG_CPU_IDLE) += cpuidle/ obj-y += mmc/ obj-y += ufs/ obj-$(CONFIG_MEMSTICK) += memstick/ -obj-$(CONFIG_NEW_LEDS) += leds/ +obj-y += leds/ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-y += firmware/ obj-$(CONFIG_CRYPTO) += crypto/ Without this, the expresswire library module won't get built unless NEW_LEDS is enabled. Arnd
Re: [PATCH RESEND] iosys-map: fix typos
On 2/11/24 23:13, Thomas Zimmermann wrote: > Hi > > Am 12.02.24 um 05:28 schrieb Randy Dunlap: >> Correct spellos/typos in comments. >> >> Signed-off-by: Randy Dunlap >> Cc: Thomas Zimmermann >> Cc: dri-devel@lists.freedesktop.org >> --- >> include/linux/iosys-map.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff -- a/include/linux/iosys-map.h b/include/linux/iosys-map.h >> --- a/include/linux/iosys-map.h >> +++ b/include/linux/iosys-map.h >> @@ -34,7 +34,7 @@ >> * the same driver for allocation, read and write operations. >> * >> * Open-coding access to :c:type:`struct iosys_map ` is >> considered >> - * bad style. Rather then accessing its fields directly, use one of the >> provided >> + * bad style. Rather than accessing its fields directly, use one of the >> provided > Ok. >> * helper functions, or implement your own. For example, instances of >> * :c:type:`struct iosys_map ` can be initialized statically >> with >> * IOSYS_MAP_INIT_VADDR(), or at runtime with iosys_map_set_vaddr(). These >> @@ -85,7 +85,7 @@ >> * if (iosys_map_is_equal(_map, _map)) >> * // always false >> * >> - * A set up instance of struct iosys_map can be used to access or >> manipulate the >> + * A setup instance of struct iosys_map can be used to access or manipulate >> the > That's not a typo. This refers to "an instance that has been set up". > Thanks. I'll drop that part and resend the other. > >> * buffer memory. Depending on the location of the memory, the provided >> helpers >> * will pick the correct operations. Data can be copied into the memory >> with >> * iosys_map_memcpy_to(). The address can be manipulated with >> iosys_map_incr(). > -- #Randy
[PATCH 2/7] drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support
From: Chris Morgan
The Powkiddy RGB10MAX3 is a handheld device with a 5 inch 720x1280
display panel with a Sitronix ST7703 display controller. The panel
is installed rotated 270 degrees.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 91 +++
1 file changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b55bafd1a8be..939ba05c9b58 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -521,6 +521,96 @@ static const struct st7703_panel_desc rgb30panel_desc = {
.init_sequence = rgb30panel_init_sequence,
};
+static int rgb10max3_panel_init_sequence(struct st7703 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ /* Init sequence extracted from Powkiddy RGB10MAX3 BSP kernel. */
+
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xf1, 0x12, 0x83);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETAPID, 0x00, 0x00, 0x00, 0xda,
+ 0x80);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0xc8, 0x02, 0x30);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, 0x10, 0x10, 0x28,
+ 0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x04, 0x04);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x78, 0x78);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22, 0xf0,
+ 0x63);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, 0x33, 0x81, 0x05, 0xf9,
+ 0x0e, 0x0e, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x44, 0x25, 0x00, 0x90, 0x0a, 0x00,
+ 0x00, 0x01, 0x4f, 0x01, 0x00, 0x00, 0x37);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x47);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, 0x73, 0x73, 0x50, 0x50,
+ 0x00, 0x00, 0x12, 0x70, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, 0x25, 0x00, 0x32,
+ 0x32, 0x77, 0xe1, 0xff, 0xff, 0xcc, 0xcc, 0x77,
+ 0x77);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x82, 0x00, 0xbf, 0xff,
+ 0x00, 0xff);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETIO, 0xb8, 0x00, 0x0a, 0x00,
+ 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCABC, 0x10, 0x40, 0x1e,
+ 0x02);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0b);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, 0x00, 0x04, 0x07,
+ 0x2a, 0x39, 0x3f, 0x36, 0x31, 0x06, 0x0b, 0x0e,
+ 0x12, 0x14, 0x12, 0x13, 0x0f, 0x17, 0x00, 0x04,
+ 0x07, 0x2a, 0x39, 0x3f, 0x36, 0x31, 0x06, 0x0b,
+ 0x0e, 0x12, 0x14, 0x12, 0x13, 0x0f, 0x17);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ, 0x03, 0x03, 0x03, 0x03,
+ 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0xff, 0x80,
+ 0xc0, 0x10);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, 0xc8, 0x10, 0x08, 0x00,
+ 0x00, 0x41, 0xf8, 0x12, 0x31, 0x23, 0x37, 0x86,
+ 0x11, 0xc8, 0x37, 0x2a, 0x00, 0x00, 0x0c, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00,
+ 0x88, 0x20, 0x46, 0x02, 0x88, 0x88, 0x88, 0x88,
+ 0x88, 0x88, 0xff, 0x88, 0x31, 0x57, 0x13, 0x88,
+ 0x88, 0x88, 0x88, 0x88, 0x88, 0xff, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, 0x00, 0x1a, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x8f, 0x13, 0x31, 0x75, 0x88, 0x88, 0x88, 0x88,
+ 0x88, 0x88, 0xf8, 0x8f, 0x02, 0x20, 0x64, 0x88,
+ 0x88, 0x88, 0x88, 0x88, 0x88, 0xf8, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00);
+ mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_EF, 0xff, 0xff, 0x01);
+
+ return 0;
+}
+
+static const struct drm_display_mode rgb10max3_panel_mode = {
+ .hdisplay
[PATCH 4/7] drm/panel: st7703: Add Panel Rotation Support
From: Chris Morgan
Add support for panel rotation to ST7703 based devices.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index 939ba05c9b58..a3e142f156d5 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -62,6 +62,7 @@ struct st7703 {
struct dentry *debugfs;
const struct st7703_panel_desc *desc;
+ enum drm_panel_orientation orientation;
};
struct st7703_panel_desc {
@@ -743,12 +744,20 @@ static int st7703_get_modes(struct drm_panel *panel,
return 1;
}
+static enum drm_panel_orientation st7703_get_orientation(struct drm_panel
*panel)
+{
+ struct st7703 *st7703 = panel_to_st7703(panel);
+
+ return st7703->orientation;
+}
+
static const struct drm_panel_funcs st7703_drm_funcs = {
.disable = st7703_disable,
.unprepare = st7703_unprepare,
.prepare = st7703_prepare,
.enable= st7703_enable,
.get_modes = st7703_get_modes,
+ .get_orientation = st7703_get_orientation,
};
static int allpixelson_set(void *data, u64 val)
@@ -817,6 +826,10 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
return dev_err_probe(dev, PTR_ERR(ctx->iovcc),
"Failed to request iovcc regulator\n");
+ ret = of_drm_get_panel_orientation(dsi->dev.of_node, >orientation);
+ if (ret < 0)
+ return dev_err_probe(>dev, ret, "Failed to get
orientation\n");
+
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.34.1
[PATCH 5/7] arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3
From: Chris Morgan
Move the vdd_cpu regulator to the device specific dts. This is in
preparation of adding the Powkiddy RGB10MAX3 device, which uses
a different vendor for the CPU regulator at a different i2c address.
Also add an alias to the bluetooth device so that we can change the
compatible string for the RGB10MAX3. This device uses the same pinouts
but a different bluetooth device.
Signed-off-by: Chris Morgan
---
.../dts/rockchip/rk3566-powkiddy-rgb30.dts | 18 ++
.../dts/rockchip/rk3566-powkiddy-rk2023.dts| 18 ++
.../dts/rockchip/rk3566-powkiddy-rk2023.dtsi | 18 +-
3 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
index 0ac64f043b80..1f567a14ac84 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
@@ -37,3 +37,21 @@ mipi_in_panel: endpoint {
};
};
};
+
+ {
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <139>;
+ regulator-name = "vdd_cpu";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
index ba32d0793dca..bc9933d9e262 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
@@ -36,3 +36,21 @@ mipi_in_panel: endpoint {
};
};
};
+
+ {
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <139>;
+ regulator-name = "vdd_cpu";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
index 0fa8f06f94cd..3ab751a01cb2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
@@ -614,22 +614,6 @@ rk817_charger: charger {
rockchip,sleep-filter-current-microamp = <10>;
};
};
-
- vdd_cpu: regulator@1c {
- compatible = "tcs,tcs4525";
- reg = <0x1c>;
- fcs,suspend-voltage-selector = <1>;
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <139>;
- regulator-name = "vdd_cpu";
- regulator-ramp-delay = <2300>;
- vin-supply = <_sys>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
};
{
@@ -805,7 +789,7 @@ {
uart-has-rtscts;
status = "okay";
- bluetooth {
+ bluetooth: bluetooth {
compatible = "realtek,rtl8821cs-bt", "realtek,rtl8723bs-bt";
device-wake-gpios = < 4 GPIO_ACTIVE_HIGH>;
enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
--
2.34.1
[PATCH 1/7] dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel
From: Chris Morgan The RGB10MAX3 panel is a panel specific to the Powkiddy RGB10MAX3 handheld device that measures 5 inches diagonally with a resolution of 720x1280. Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index 97cccd8a8479..8dfe8951bf5b 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -22,6 +22,8 @@ properties: enum: # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel - anbernic,rg353v-panel-v2 + # Powkiddy RGB10MAX3 5.0" 720x1280 TFT LCD panel + - powkiddy,rgb10max3-panel # Powkiddy RGB30 3.0" 720x720 TFT LCD panel - powkiddy,rgb30-panel # Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel -- 2.34.1
[PATCH 0/7] Add Support for RK3566 Powkiddy RGB10MAX3
From: Chris Morgan Add support for the Powkiddy RGB10MAX3 handheld gaming console. [1] https://powkiddy.com/products/pre-sale-powkiddy-rgb10max3-handheld-game-console Chris Morgan (7): dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support dt-bindings: display: Document ST7703 panel rotation drm/panel: st7703: Add Panel Rotation Support arm64: dts: rockchip: Update powkiddy rk2023 dtsi for RGB10MAX3 dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3 arm64: dts: rockchip: Add Powkiddy RGB10MAX3 .../devicetree/bindings/arm/rockchip.yaml | 1 + .../display/panel/rocktech,jh057n00900.yaml | 4 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../rockchip/rk3566-powkiddy-rgb10max3.dts| 87 +++ .../dts/rockchip/rk3566-powkiddy-rgb30.dts| 18 +++ .../dts/rockchip/rk3566-powkiddy-rk2023.dts | 18 +++ .../dts/rockchip/rk3566-powkiddy-rk2023.dtsi | 18 +-- drivers/gpu/drm/panel/panel-sitronix-st7703.c | 104 ++ 8 files changed, 234 insertions(+), 17 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts -- 2.34.1
[PATCH 3/7] dt-bindings: display: Document ST7703 panel rotation
From: Chris Morgan Document the rotation property for ST7703 based panels. Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index 8dfe8951bf5b..97e0d14790e3 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -46,6 +46,8 @@ properties: backlight: true + rotation: true + required: - compatible - reg -- 2.34.1
[PATCH 7/7] arm64: dts: rockchip: Add Powkiddy RGB10MAX3
From: Chris Morgan
Add support for the Powkiddy RGB10MAX3. The Powkiddy RGB10MAX3 is a
handheld gaming device with a 720p 5.0 inch screen powered by the
Rockchip RK3566 SoC. It includes a Realtek 8723ds WiFi/BT module, 2 ADC
joysticks powered by a 4-way muxed ADC channel, and several GPIO
face buttons. There are 2 SDMMC slots (sdmmc1 and sdmmc3), 3 pwm
controlled LEDs, and the device includes 1GB of RAM.
Signed-off-by: Chris Morgan
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../rockchip/rk3566-powkiddy-rgb10max3.dts| 87 +++
2 files changed, 88 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index a7b30e11beaf..3c4f87e4db61 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb10max3.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-x55.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
new file mode 100644
index ..fd1a01744a25
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb10max3.dts
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3566-powkiddy-rk2023.dtsi"
+
+/ {
+ model = "Powkiddy RGB10MAX3";
+ compatible = "powkiddy,rgb10max3", "rockchip,rk3566";
+};
+
+ {
+ compatible = "realtek,rtl8723ds-bt";
+};
+
+ {
+ assigned-clocks = < CLK_RTC_32K>, < PLL_GPLL>,
+ < PLL_PPLL>, < PLL_VPLL>;
+ assigned-clock-rates = <32768>, <12>,
+ <2>, <12640>;
+};
+
+ {
+ panel: panel@0 {
+ compatible = "powkiddy,rgb10max3-panel";
+ reg = <0>;
+ backlight = <>;
+ iovcc-supply = <_lcd0_n>;
+ pinctrl-0 = <_rst>;
+ pinctrl-names = "default";
+ reset-gpios = < RK_PA0 GPIO_ACTIVE_LOW>;
+ rotation = <270>;
+ vcc-supply = <_lcd0_n>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+};
+
+_led {
+ default-state = "on";
+ function = LED_FUNCTION_POWER;
+};
+
+ {
+ vdd_cpu: regulator@40 {
+ compatible = "fcs,fan53555";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <139>;
+ regulator-name = "vdd_cpu";
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+ {
+ amber_led: led-2 {
+ color = ;
+ function = LED_FUNCTION_CHARGING;
+ max-brightness = <255>;
+ pwms = < 0 25000 0>;
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+_led {
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+};
--
2.34.1
[PATCH 6/7] dt-bindings: arm: rockchip: Add Powkiddy RGB10MAX3
From: Chris Morgan The Powkiddy RGB10MAX3 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC. Signed-off-by: Chris Morgan --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5cf5cbef2cf5..4ab0b92cf241 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -692,6 +692,7 @@ properties: - description: Powkiddy RK3566 Handheld Gaming Console items: - enum: + - powkiddy,rgb10max3 - powkiddy,rgb30 - powkiddy,rk2023 - powkiddy,x55 -- 2.34.1
Re: [PATCH v2 17/19] drm/msm/dpu: modify timing engine programming for YUV420 over DP
On 2/10/2024 2:50 AM, Dmitry Baryshkov wrote:
On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote:
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v2:
- Move timing engine programming to this patch
Signed-off-by: Paloma Arellano
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 3f102b2813ca8..fb46d907312a7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -235,8 +235,9 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
{
struct drm_display_mode mode;
struct dpu_hw_intf_timing_params timing_params = { 0 };
+ struct dpu_hw_cdm *hw_cdm;
const struct dpu_format *fmt = NULL;
- u32 fmt_fourcc = DRM_FORMAT_RGB888;
+ u32 fmt_fourcc;
unsigned long lock_flags;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
@@ -255,17 +256,21 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
DPU_DEBUG_VIDENC(phys_enc, "enabling mode:\n");
drm_mode_debug_printmodeline();
- if (phys_enc->split_role != ENC_ROLE_SOLO) {
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+
+ if (phys_enc->split_role != ENC_ROLE_SOLO || fmt_fourcc ==
DRM_FORMAT_YUV420) {
mode.hdisplay >>= 1;
mode.htotal >>= 1;
mode.hsync_start >>= 1;
mode.hsync_end >>= 1;
+ mode.hskew >>= 1;
hskew change seems to warrant a separate patch with Fixes for
25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Ack
DPU_DEBUG_VIDENC(phys_enc,
- "split_role %d, halve horizontal %d %d %d %d\n",
+ "split_role %d, halve horizontal %d %d %d %d %d\n",
phys_enc->split_role,
mode.hdisplay, mode.htotal,
- mode.hsync_start, mode.hsync_end);
+ mode.hsync_start, mode.hsync_end,
+ mode.hskew);
}
drm_mode_to_intf_timing_params(phys_enc, , _params);
@@ -273,6 +278,9 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc, "fmt_fourcc 0x%X\n", fmt_fourcc);
+ hw_cdm = phys_enc->hw_cdm;
+ if (hw_cdm)
+ intf_cfg.cdm = hw_cdm->idx;
No need for a separate local variable.
Ack
intf_cfg.intf = phys_enc->hw_intf->idx;
intf_cfg.intf_mode_sel = DPU_CTL_MODE_SEL_VID;
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
--
2.39.2
Re: [PATCH v2 15/19] drm/msm/dp: enable SDP and SDE periph flush update
On 2/10/2024 10:15 PM, Dmitry Baryshkov wrote: On Sun, 11 Feb 2024 at 06:12, Abhinav Kumar wrote: On 2/10/2024 2:11 PM, Dmitry Baryshkov wrote: On Sat, 10 Feb 2024 at 23:49, Abhinav Kumar wrote: On 2/10/2024 2:16 AM, Dmitry Baryshkov wrote: On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote: DP controller can be setup to operate in either SDP update flush mode or peripheral flush mode based on the DP controller hardware version. Starting in DP v1.2, the hardware documents require the use of peripheral flush mode for SDP packets such as PPS OR VSC SDP packets. In-line with this guidance, lets program the DP controller to use peripheral flush mode starting DP v1.2 Changes in v2: - Use the original dp_catalog_hw_revision() function to correctly check the DP HW version Signed-off-by: Paloma Arellano --- drivers/gpu/drm/msm/dp/dp_catalog.c | 17 + drivers/gpu/drm/msm/dp/dp_catalog.h | 1 + drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 + drivers/gpu/drm/msm/dp/dp_reg.h | 2 ++ 4 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h index 2983756c125cd..6ac66532b47a4 100644 --- a/drivers/gpu/drm/msm/dp/dp_reg.h +++ b/drivers/gpu/drm/msm/dp/dp_reg.h @@ -102,6 +102,8 @@ #define DP_MAINLINK_CTRL_ENABLE(0x0001) #define DP_MAINLINK_CTRL_RESET (0x0002) #define DP_MAINLINK_CTRL_SW_BYPASS_SCRAMBLER (0x0010) +#define DP_MAINLINK_FLUSH_MODE_UPDATE_SDP (0x0080) +#define DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE (0x0180) Just one bit here, please. hmm so the periph flush bits are 24:23 and we need a value of 3 to select peripheral flush which translates to 0x0180. How do you suggest to break this up? Then FIELD_PREP(something_mask, 3). Otherwise it is too easy to consider it to be DP_MAINLINK_FLUSH_MODE_UPDATE_SDP | BIT(24) Sure, FIELD_PREP() works. I was confused when you said one bit :) I was also confused, as I wrote, thus I thought that there are one-bit values in this reg. Ack, will change -Paloma #define DP_MAINLINK_FB_BOUNDARY_SEL(0x0200) #define REG_DP_STATE_CTRL (0x0004) -- 2.39.2
Re: [PATCH v2 12/19] drm/msm/dp: move parity calculation to dp_utils
On 2/10/2024 1:55 AM, Dmitry Baryshkov wrote: On Sat, 10 Feb 2024 at 03:52, Paloma Arellano wrote: Parity calculation is necessary for VSC SDP implementation. Therefore create new files dp_utils.c and dp_utils.h and move the parity calculating functions here. This ensures that they are usable by SDP programming in both dp_catalog.c and dp_audio.c Changes in v2: - Create new files dp_utils.c and dp_utils.h - Move the parity calculation to these new files instead of having them in dp_catalog.c and dp_catalog.h Signed-off-by: Paloma Arellano --- drivers/gpu/drm/msm/Makefile | 3 +- drivers/gpu/drm/msm/dp/dp_audio.c | 101 +- drivers/gpu/drm/msm/dp/dp_utils.c | 71 + drivers/gpu/drm/msm/dp/dp_utils.h | 22 +++ 4 files changed, 110 insertions(+), 87 deletions(-) create mode 100644 drivers/gpu/drm/msm/dp/dp_utils.c create mode 100644 drivers/gpu/drm/msm/dp/dp_utils.h [skipped] diff --git a/drivers/gpu/drm/msm/dp/dp_utils.h b/drivers/gpu/drm/msm/dp/dp_utils.h new file mode 100644 index 0..c062e29d07898 --- /dev/null +++ b/drivers/gpu/drm/msm/dp/dp_utils.h @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2024, The Linux Foundation. All rights reserved. + */ + +#ifndef _DP_UTILS_H_ +#define _DP_UTILS_H_ + +#define HEADER_BYTE_0_BIT 0 +#define PARITY_BYTE_0_BIT 8 +#define HEADER_BYTE_2_BIT 0 +#define PARITY_BYTE_2_BIT 8 +#define HEADER_BYTE_1_BIT 16 +#define PARITY_BYTE_1_BIT 24 +#define HEADER_BYTE_3_BIT 16 +#define PARITY_BYTE_3_BIT 24 Nit: it is usually 0-1-2-3 rather than 0-2-1-3. With that fixed: Reviewed-by: Dmitry Baryshkov Ack. + +u8 dp_utils_get_g0_value(u8 data); +u8 dp_utils_get_g1_value(u8 data); +u8 dp_utils_calculate_parity(u32 data); + +#endif /* _DP_UTILS_H_ */ -- 2.39.2
[PATCH v4] drm/dp: add an API to indicate if sink supports VSC SDP
From: Paloma Arellano
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
changes in v4:
- bail out early if dpcd rev check fails
changes in v3:
- fix the commit title prefix to drm/dp
- get rid of redundant !!
- break out this change from series [1] to get acks from drm core
maintainers
Changes in v2:
- Move VSC SDP support check API from dp_panel.c to
drm_dp_helper.c
[1]: https://patchwork.freedesktop.org/series/129180/
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Paloma Arellano
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 23 +++
include/drm/display/drm_dp_helper.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index b1ca3a1100da..b10fb2be837e 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2916,6 +2916,29 @@ void drm_dp_vsc_sdp_log(const char *level, struct device
*dev,
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_supported() - check if vsc sdp is supported
+ * @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
+ *
+ * Returns true if vsc sdp is supported, else returns false
+ */
+bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 rx_feature;
+
+ if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_13)
+ return false;
+
+ if (drm_dp_dpcd_readb(aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
_feature) != 1) {
+ drm_dbg_dp(aux->drm_dev, "failed to read
DP_DPRX_FEATURE_ENUMERATION_LIST\n");
+ return false;
+ }
+
+ return (rx_feature & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED);
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_supported);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index 863b2e7add29..948381b2b0b1 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -100,6 +100,7 @@ struct drm_dp_vsc_sdp {
void drm_dp_vsc_sdp_log(const char *level, struct device *dev,
const struct drm_dp_vsc_sdp *vsc);
+bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
--
2.34.1
Re: [PATCH 06/10] backlight/pwm-backlight: Remove struct backlight_ops.check_fb
Hello Thomas, On Mon, Feb 12, 2024 at 05:16:39PM +0100, Thomas Zimmermann wrote: > The internal check_fb callback from struct pwm_bl_data is never > implemented. thus the driver's implementation of check_fb always > returns true, which is the backlight core's default if no > implementation has been set. So remove the code from the driver. > > Signed-off-by: Thomas Zimmermann > Cc: "Uwe Kleine-König" Looks reasonable. Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[Bug 218483] Blank screen on Cezanne/Barcelo APU with amdgpu.seamless=1
https://bugzilla.kernel.org/show_bug.cgi?id=218483 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- please report here instead: https://gitlab.freedesktop.org/drm/amd/-/issues -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > wrote: > > > > > > > > > > > > /** > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > * > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full vs > > > > > > > > > > > > Limited) used. > > > > > > > > > > > > + * Infoframes will be generated according to that > > > > > > > > > > > > value. > > > > > > > > > > > > + * > > > > > > > > > > > > + * The value of this property can be one of the > > > > > > > > > > > > following: > > > > > > > > > > > > + * > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > + * RGB Range is selected automatically > > > > > > > > > > > > based on the mode > > > > > > > > > > > > + * according to the HDMI specifications. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Full: > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > + * Limited RGB Range is forced. Unlike > > > > > > > > > > > > the name suggests, > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > + * > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > There might be two > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color > > > > > > > > > > > pipeline processing > > > > > > > > > > > such that a full-range input to the CRTC is converted to > > > > > > > > > > > either full- or > > > > > > > > > > > limited-range, depending on what the monitor is supposed > > > > > > > > > > > to accept. > > > > > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there is > > > > > > > > > > > no signalling, > > > > > > > > > > > or that the signalling matches what the monitor is > > > > > > > > > > > supposed to accept > > > > > > > > > > > according to the spec? Also, is this really HDMI specific? > > > > > > > > > > > > > > > > > > > > > > When full or limited is selected and the monitor doesn't > > > > > > > > > > > support the > > > > > > > > > > > signalling, what happens? > > > > > > > > > > > > > > > > > > > > Forgot to mention: user-space still has no control over RGB > > > > > > > > > > vs YCbCr on > > > > > > > > > > the cable, so is this only affecting RGB? If not, how does > > > > > > > > > > it affect > > > > > > > > > > YCbCr? > > > > > > > > > > > > > > > > > > So I dug a bit into both the i915 and vc4 drivers, and it > > > > > > > > > looks like if > > > > > > > > > we're using a YCbCr format, i915 will always use a limited > > > > > > > > > range while > > > > > > > > > vc4 will follow the value of the property. > > > > > > > > > > > > > > > > The property is literally called "Broadcast *RGB*". > > > > > > > > That should explain why it's only affecting RGB. > > > > > > > > > > > > > > Right. And the limited range option is called "Limited 16:235" > > > > > > > despite > > > > > > > being usable on bpc > 8 bits. Naming errors occurs, and history > > > > > > > happens > > > > > > > to make names inconsistent too, that's fine and not an argument in > > > > > > > itself. > > > > > > > > > > > > > > > Full range YCbCr is a much rarer beast so we've never bothered > > > > > > > > to enable it. > > > > > > > > > > > > > > vc4 supports it. > > > > > > > > > > > > Someone implemented it incorrectly then. > > > > > > > > > > Incorrectly according to what documentation / specification? I'm > > > > > sorry, > > > > > but I find it super ironic that i915 gets to do its own thing, not > > > > > document any of it, and when people try to clean things up they
Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 12, 2024 at 05:39:03PM +0100, Hans Verkuil wrote: > On 12/02/2024 16:49, Ville Syrjälä wrote: > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > >> On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > >>> On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > >> On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > >>> On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > Hi, > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote: > >>> /** > >>> * DOC: HDMI connector properties > >>> * > >>> + * Broadcast RGB > >>> + * Indicates the RGB Quantization Range (Full vs Limited) > >>> used. > >>> + * Infoframes will be generated according to that value. > >>> + * > >>> + * The value of this property can be one of the following: > >>> + * > >>> + * Automatic: > >>> + * RGB Range is selected automatically based on the > >>> mode > >>> + * according to the HDMI specifications. > >>> + * > >>> + * Full: > >>> + * Full RGB Range is forced. > >>> + * > >>> + * Limited 16:235: > >>> + * Limited RGB Range is forced. Unlike the name > >>> suggests, > >>> + * this works for any number of bits-per-component. > >>> + * > >>> + * Drivers can set up this property by calling > >>> + * drm_connector_attach_broadcast_rgb_property(). > >>> + * > >> > >> This is a good time to document this in more detail. There might > >> be two > >> different things being affected: > >> > >> 1. The signalling (InfoFrame/SDP/...) > >> 2. The color pipeline processing > >> > >> All values of Broadcast RGB always affect the color pipeline > >> processing > >> such that a full-range input to the CRTC is converted to either > >> full- or > >> limited-range, depending on what the monitor is supposed to accept. > >> > >> When automatic is selected, does that mean that there is no > >> signalling, > >> or that the signalling matches what the monitor is supposed to > >> accept > >> according to the spec? Also, is this really HDMI specific? > >> > >> When full or limited is selected and the monitor doesn't support > >> the > >> signalling, what happens? > > > > Forgot to mention: user-space still has no control over RGB vs > > YCbCr on > > the cable, so is this only affecting RGB? If not, how does it affect > > YCbCr? > > So I dug a bit into both the i915 and vc4 drivers, and it looks like > if > we're using a YCbCr format, i915 will always use a limited range > while > vc4 will follow the value of the property. > >>> > >>> The property is literally called "Broadcast *RGB*". > >>> That should explain why it's only affecting RGB. > >> > >> Right. And the limited range option is called "Limited 16:235" despite > >> being usable on bpc > 8 bits. Naming errors occurs, and history happens > >> to make names inconsistent too, that's fine and not an argument in > >> itself. > >> > >>> Full range YCbCr is a much rarer beast so we've never bothered > >>> to enable it. > >> > >> vc4 supports it. > > > > Someone implemented it incorrectly then. > > Incorrectly according to what documentation / specification? I'm sorry, > but I find it super ironic that i915 gets to do its own thing, not > document any of it, and when people try to clean things up they get told > that we got it all wrong. > >>> > >>> FWIW, this was an i915 property and if another driver uses the same > >>> property name it must have the same behavior. Yes, it isn't standardized > >>> and yes, it's not documented (hence this effort here) but it's still on > >>> vc4 to make the property compatible. > >> > >> How is it not compatible? It's a superset of what i915 provides, but > >> it's strictly compatible with it. > > > > No it is not. Eg. what happens if you set the thing to full range for > > RGB (which you must on many broken monitors), and then the kernel > > automagically switches to YCbCr (for whatever reason) but the monitor > > doesn't support full range YCbCr? Answer: you get crap output. > > The Broadcast RGB setting is really specific to RGB output. That's where > you need it, since due to messed up standards in the past it is common to > have to
Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick wrote: > > > > > > > > > > > /** > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > * > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full vs > > > > > > > > > > > Limited) used. > > > > > > > > > > > + * Infoframes will be generated according to that > > > > > > > > > > > value. > > > > > > > > > > > + * > > > > > > > > > > > + * The value of this property can be one of the > > > > > > > > > > > following: > > > > > > > > > > > + * > > > > > > > > > > > + * Automatic: > > > > > > > > > > > + * RGB Range is selected automatically > > > > > > > > > > > based on the mode > > > > > > > > > > > + * according to the HDMI specifications. > > > > > > > > > > > + * > > > > > > > > > > > + * Full: > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > + * > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > + * Limited RGB Range is forced. Unlike the > > > > > > > > > > > name suggests, > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > bits-per-component. > > > > > > > > > > > + * > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > + * drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. There > > > > > > > > > > might be two > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color > > > > > > > > > > pipeline processing > > > > > > > > > > such that a full-range input to the CRTC is converted to > > > > > > > > > > either full- or > > > > > > > > > > limited-range, depending on what the monitor is supposed to > > > > > > > > > > accept. > > > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there is no > > > > > > > > > > signalling, > > > > > > > > > > or that the signalling matches what the monitor is supposed > > > > > > > > > > to accept > > > > > > > > > > according to the spec? Also, is this really HDMI specific? > > > > > > > > > > > > > > > > > > > > When full or limited is selected and the monitor doesn't > > > > > > > > > > support the > > > > > > > > > > signalling, what happens? > > > > > > > > > > > > > > > > > > Forgot to mention: user-space still has no control over RGB > > > > > > > > > vs YCbCr on > > > > > > > > > the cable, so is this only affecting RGB? If not, how does it > > > > > > > > > affect > > > > > > > > > YCbCr? > > > > > > > > > > > > > > > > So I dug a bit into both the i915 and vc4 drivers, and it looks > > > > > > > > like if > > > > > > > > we're using a YCbCr format, i915 will always use a limited > > > > > > > > range while > > > > > > > > vc4 will follow the value of the property. > > > > > > > > > > > > > > The property is literally called "Broadcast *RGB*". > > > > > > > That should explain why it's only affecting RGB. > > > > > > > > > > > > Right. And the limited range option is called "Limited 16:235" > > > > > > despite > > > > > > being usable on bpc > 8 bits. Naming errors occurs, and history > > > > > > happens > > > > > > to make names inconsistent too, that's fine and not an argument in > > > > > > itself. > > > > > > > > > > > > > Full range YCbCr is a much rarer beast so we've never bothered > > > > > > > to enable it. > > > > > > > > > > > > vc4 supports it. > > > > > > > > > > Someone implemented it incorrectly then. > > > > > > > > Incorrectly according to what documentation / specification? I'm sorry, > > > > but I find it super ironic that i915 gets to do its own thing, not > > > > document any of it, and when people try to clean things up they get told > > > > that we got it all wrong. > > > > > > FWIW, this was an i915 property and if another driver uses the same > > > property name it must have the same behavior. Yes, it isn't standardized > > > and yes, it's not documented (hence this effort here) but it's still on > > >
