Re: [Intel-gfx] [PATCH v2] drm/i915: Check require bandwidth did not exceed LSPCON limitation
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: Sharma, Shashank
Sent: Tuesday, January 21, 2020 11:44 AM
To: Lee Shawn C ; intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: RE: [Intel-gfx] [PATCH v2] drm/i915: Check require bandwidth did not
exceed LSPCON limitation
[AMD Official Use Only - Internal Distribution Only]
Hello Shawn,
-Original Message-
From: Intel-gfx On Behalf Of Lee
Shawn C
Sent: Tuesday, January 21, 2020 6:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: [Intel-gfx] [PATCH v2] drm/i915: Check require bandwidth did not
exceed LSPCON limitation
While mode setting, driver would calculate mode rate based on resolution and
bpp. And choose the best bpp that did not exceed DP bandwidtd.
But LSPCON had more restriction due to it convert DP to HDMI.
Driver should respect HDMI's bandwidth limitation if LSPCON was active. This
change would ignore the bpp when its required output bandwidth already over
HDMI 2.0 or 1.4 spec.
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Jani Nikula
Cc: Cooper Chiou
Cc: Sam McNally
Signed-off-by: Lee Shawn C
v2: move lspcon_max_rate() into intel_lspcon.c.
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
drivers/gpu/drm/i915/display/intel_lspcon.c | 10 ++
drivers/gpu/drm/i915/display/intel_lspcon.h | 1 +
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7424e2a04a3..6796055ace69 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1983,6 +1983,7 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
const struct link_config_limits *limits) {
struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
+ struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
int bpp, clock, lane_count;
int mode_rate, link_clock, link_avail;
@@ -1992,6 +1993,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
output_bpp);
+ /* Bypass this mode if require bandwidth over HDMI spec when
LSPCON active */
+ if (lspcon->active && mode_rate > lspcon_max_rate(lspcon))
+ continue;
+
for (clock = limits->min_clock; clock <= limits->max_clock;
clock++) {
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count; diff --git
a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index d807c5648c87..5657e949aabf 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -518,6 +518,16 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
buf, ret);
}
+int lspcon_max_rate(struct intel_lspcon *lspcon) {
+ enum drm_lspcon_mode current_mode = lspcon_get_current_mode(lspcon);
+
+ if (lspcon_current_mode == DRM_LSPCON_MODE_LS)
Also, if I recall correctly, we are driving always on PCON mode. So if LSPCON
is active, it would be in PCON mode. Do you see scenarios where you are finding
it in LS mode ?
- Shashank
+ return DIV_ROUND_UP(34 * 24, 8);
+
+ return DIV_ROUND_UP(60 * 24, 8);
Instead of assuming max clock 340 or 600, my suggestion would be to introduce a
new variable in struct intel_lspcon called max_rate, and then initialize that
properly at lspcon_probe/init, this will make the solution generic for any
LSPCON type dongle on Intel board. We have seen few dp->hdmi type2 convertors
also on-board on ICL chips, which behave like LSPCON, but can be HDMI 1.4 or
HDMI 2.0 depending on the board config.
- Shashank
+}
+
u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config) {
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 37cfddf8a9c5..b584c02ab33b 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -18,6 +18,7 @@ struct intel_lspcon;
bool lspcon_init(struct intel_digital_port *intel_dig_port); void
lspcon_resume(struct intel_lspcon *lspcon); void lspcon_wait_pcon_mode(struct
intel_lspcon *lspcon);
+int lspcon_max_rate(struct intel_lspcon *lspcon);
void lspcon_write_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
--
2.17.1
___
Intel-gfx mailing list
Inte
Re: [Intel-gfx] [PATCH v2] drm/i915: Check require bandwidth did not exceed LSPCON limitation
[AMD Official Use Only - Internal Distribution Only]
Hello Shawn,
-Original Message-
From: Intel-gfx On Behalf Of Lee
Shawn C
Sent: Tuesday, January 21, 2020 6:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: [Intel-gfx] [PATCH v2] drm/i915: Check require bandwidth did not
exceed LSPCON limitation
While mode setting, driver would calculate mode rate based on resolution and
bpp. And choose the best bpp that did not exceed DP bandwidtd.
But LSPCON had more restriction due to it convert DP to HDMI.
Driver should respect HDMI's bandwidth limitation if LSPCON was active. This
change would ignore the bpp when its required output bandwidth already over
HDMI 2.0 or 1.4 spec.
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Jani Nikula
Cc: Cooper Chiou
Cc: Sam McNally
Signed-off-by: Lee Shawn C
v2: move lspcon_max_rate() into intel_lspcon.c.
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
drivers/gpu/drm/i915/display/intel_lspcon.c | 10 ++
drivers/gpu/drm/i915/display/intel_lspcon.h | 1 +
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7424e2a04a3..6796055ace69 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1983,6 +1983,7 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
const struct link_config_limits *limits) {
struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
+ struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
int bpp, clock, lane_count;
int mode_rate, link_clock, link_avail;
@@ -1992,6 +1993,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
output_bpp);
+ /* Bypass this mode if require bandwidth over HDMI spec when
LSPCON active */
+ if (lspcon->active && mode_rate > lspcon_max_rate(lspcon))
+ continue;
+
for (clock = limits->min_clock; clock <= limits->max_clock;
clock++) {
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count; diff --git
a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index d807c5648c87..5657e949aabf 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -518,6 +518,16 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
buf, ret);
}
+int lspcon_max_rate(struct intel_lspcon *lspcon) {
+ enum drm_lspcon_mode current_mode = lspcon_get_current_mode(lspcon);
+
+ if (lspcon_current_mode == DRM_LSPCON_MODE_LS)
+ return DIV_ROUND_UP(34 * 24, 8);
+
+ return DIV_ROUND_UP(60 * 24, 8);
Instead of assuming max clock 340 or 600, my suggestion would be to introduce a
new variable in struct intel_lspcon called max_rate, and then initialize that
properly at lspcon_probe/init, this will make the solution generic for any
LSPCON type dongle on Intel board. We have seen few dp->hdmi type2 convertors
also on-board on ICL chips, which behave like LSPCON, but can be HDMI 1.4 or
HDMI 2.0 depending on the board config.
- Shashank
+}
+
u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config) {
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 37cfddf8a9c5..b584c02ab33b 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -18,6 +18,7 @@ struct intel_lspcon;
bool lspcon_init(struct intel_digital_port *intel_dig_port); void
lspcon_resume(struct intel_lspcon *lspcon); void lspcon_wait_pcon_mode(struct
intel_lspcon *lspcon);
+int lspcon_max_rate(struct intel_lspcon *lspcon);
void lspcon_write_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fintel-gfxdata=02%7C01%7Cshashank.sharma%40amd.com%7C147795054978408a3a0408d79e32b3b8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637151812914284227sdata=E8qG9P4ABBaF9P8HmW4NgpO4oSbf1lvBHjkHhp3hEX8%3Dreserved=0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property
Hello Harry,
Thanks for your comments, please find mine inline.
On 10/22/2019 7:36 PM, Harry Wentland wrote:
On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
Please use real words.
+ DRM_SCALING_FILTER_NN_IS_ONLY,
Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
+ DRM_SCALING_FILTER_INVALID,
That invalid enum value seems entirely pointless.
This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.
FWIW, AMD HW allows us to specify a number of horizontal and vertical
taps for scaling. Number of taps are limited by our linebuffer size. The
default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
if your're running a large horizontal resolution on some ASICs.
I'm not sure it makes sense to define filters here that aren't used. It
sounds like default and nearest neighbour would suffice for now in order
to support integer scaling.
Agree, this seems to be a consistent feedback from the community, I will
probably start with a smaller set of most popular/used ones.
- Shashank
Harry
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+ u32 scaling_filter;
We have an enum so should use it. The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property
Hello Mihail,
Thanks for your review, my comments inline.
On 10/22/2019 6:56 PM, Mihail Atanassov wrote:
Hi Shashank,
On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
+ DRM_SCALING_FILTER_NN_IS_ONLY,
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
This one looks to be missing a stringified version below.
Oh yes, it did. Thanks for pointing this out.
Just wanted
to jump in early and suggest dropping it from the scaling filter enum.
Edge enhancement is orthogonal to the mode used for scaling, at least
on komeda HW, so we wouldn't be able to make the best use of the
property in its current form.
Yes, Ville also suggested similar, I guess we can start with the smaller
set.
+ DRM_SCALING_FILTER_INVALID,
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+ * @scaling_filter:
+ *
+ * Scaling filter mode to be applied
+ */
+ u32 scaling_filter;
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
*/
struct drm_property *modifiers_property;
+ /**
+ * @scaling_filter_property: CRTC property to apply a particular filter
A scaling filter option can also be useful for scaling individual
planes, do you have any plans to extend the property's applications
in that direction?
Yes, the second stage of development should contain the plane level
filtering too, but as you know, that would be a complex thing to handle,
as planes apply filter pre-blending. We need to discus that (in a
parallel thread :)) how should that look like.
- Shashank
+ * while scaling in panel fitter mode.
+ */
+ struct drm_property *scaling_filter_property;
+
/* cursor size */
uint32_t cursor_width, cursor_height;
--
Mihail
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property
On 10/22/2019 5:56 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
+ DRM_SCALING_FILTER_NN_IS_ONLY,
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
+ DRM_SCALING_FILTER_INVALID,
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+ u32 scaling_filter;
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
*/
struct drm_property *modifiers_property;
+ /**
+* @scaling_filter_property: CRTC property to apply a particular filter
+* while scaling in panel fitter mode.
+*/
+ struct drm_property *scaling_filter_property;
This needs to per-crtc/plane.
I am not getting this, why ? It's not different than any other CRTC
property like gamma/CSC etc, where we just attach them to corresponding
CRTC, isn't it ?
- Shashank
+
/* cursor size */
uint32_t cursor_width, cursor_height;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property
Hello Ville,
Thanks for the comments, mine inline.
On 10/22/2019 5:50 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
Please use real words.
Yes, I saw that coming. It was getting difficult with the 80 char stuff,
it was even more difficult while using it :). But let me see how better
can I do here.
+ DRM_SCALING_FILTER_NN_IS_ONLY,
Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.
Agree, that's also one option. I was thinking to make it convenient for
userspace, For example if a compositor just want to checkout NN only
when its beneficial (like old gaming scenarios) but doesn't have enough
information (or intent), it can leave it to kernel too. But I agree,
this can cause corner cases. Let's discuss and see if we need it at all,
as you mentioned.
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
+ DRM_SCALING_FILTER_INVALID,
That invalid enum value seems entirely pointless.
I was thinking about loops and all, but yeah, we can remove it.
This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.
Sure, lets start with smaller set.
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+ u32 scaling_filter;
We have an enum so should use it.
Got it.
The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.
The comment is actually with the property, Here I think its clear that
it's for CRTC scaling, as its a part of CRTC state.
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
---
Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property
Hey Daniel,
> -Original Message-
> From: Daniel Vetter On Behalf Of Daniel Vetter
> Sent: Tuesday, October 22, 2019 3:39 PM
> To: Sharma, Shashank
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode
> property
>
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> > This patch adds a scaling filter mode porperty to allow:
> > - A driver/HW to showcase it's scaling filter capabilities.
> > - A userspace to pick a desired effect while scaling.
> >
> > This option will be particularly useful in the scenarios where Integer
> > mode scaling is possible, and a UI client wants to pick filters like
> > Nearest-neighbor applied for non-blurry outputs.
> >
> > There was a RFC patch series published, to discus the request to
> > enable Integer mode scaling by some of the gaming communities, which
> > can be found here:
> > https://patchwork.freedesktop.org/series/66175/
> >
> > Signed-off-by: Shashank Sharma
>
> Two things:
>
> - needs real property docs for this in the kms property chapter
Got it,
> - would be good if we could somehow subsume the panel fitter prop into
> this? Or at least document possible interactions with that.
>
Sure, let me see what can I do here.
> Plus userspace ofc, recommended best practices is to add a Link: tag pointing
> at the
> userspace patch series/merge request directly to the patch that adds the new
> uapi.
>
Yep, WIP, will soon drop a link here.
- Shashank
> Cheers, Daniel
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4
> > include/drm/drm_crtc.h| 26 ++
> > include/drm/drm_mode_config.h | 6 ++
> > 3 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 0d466d3b0809..883329453a86 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> > return ret;
> > } else if (property == config->prop_vrr_enabled) {
> > state->vrr_enabled = val;
> > + } else if (property == config->scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (property == config->degamma_lut_property) {
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >degamma_lut,
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > + else if (property == config->scaling_filter_property)
> > + *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> > val);
> > else
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 5e9b15a0e8c5..94c5509474a8 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -58,6 +58,25 @@ struct device_node; struct dma_fence; struct
> > edid;
> >
> > +enum drm_scaling_filters {
> > + DRM_SCALING_FILTER_DEFAULT,
> > + DRM_SCALING_FILTER_MEDIUM,
> > + DRM_SCALING_FILTER_BILINEAR,
> > + DRM_SCALING_FILTER_NN,
> > + DRM_SCALING_FILTER_NN_IS_ONLY,
> > + DRM_SCALING_FILTER_EDGE_ENHANCE,
> > + DRM_SCALING_FILTER_INVALID,
> > +};
> > +
> > +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> > + { DRM_SCALING_FILTER_DEFAULT, "Default" },
> > + { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> > + { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> > + { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> > + { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> > + { DRM_SCALING_FILTER_INVALID, "Invalid" }, };
> > +
> > static inline int64_t U642I64(uint64_t val) {
> > return (int64_t)*((int64_t *));
> > @@ -283,6 +302,13 @@ struct drm_crtc_state {
> > */
> > u32 target_vblank;
> >
> > + /**
> > +* @scaling_filter:
> > +*
> > +* Scaling filter mode to be applied
> > +*/
> > + u32 scaling_filter;
> > +
>
Re: [Intel-gfx] [PATCH v3 3/4] drm/edid: Throw away the dummy VIC 0 cea mode
On 9/25/2019 7:25 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Now that the cea mode handling is not 100% tied to the single
array the dummy VIC 0 mode is pretty much pointles. Throw it
out.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9f6996323efa..0007004d3221 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -709,11 +709,9 @@ static const struct minimode extra_modes[] = {
/*
* From CEA/CTA-861 spec.
*
- * Index with VIC.
+ * Index with VIC-1.
Do we want to really do this ? Till now, due to dummy VIC, indexing was
pretty direct as per VIC, which was making the code easy to read and
understand. I would still think that keeping the dummy VIC and adjusting
the size of cea_modes_0[] in the size function, would be something
neater to do, do you think so ?
- Shashank
*/
-static const struct drm_display_mode edid_cea_modes_0[] = {
- /* 0 - dummy, VICs start at 1 */
- { },
+static const struct drm_display_mode edid_cea_modes_1[] = {
/* 1 - 640x480@60Hz 4:3 */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
752, 800, 0, 480, 490, 492, 525, 0,
@@ -3211,10 +3209,8 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
{
- if (!vic)
- return NULL;
- if (vic < ARRAY_SIZE(edid_cea_modes_0))
- return _cea_modes_0[vic];
+ if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
+ return _cea_modes_1[vic - 1];
if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
return _cea_modes_193[vic - 193];
return NULL;
@@ -3227,7 +3223,7 @@ static u8 cea_num_vics(void)
static u8 cea_next_vic(u8 vic)
{
- if (++vic == ARRAY_SIZE(edid_cea_modes_0))
+ if (++vic == 1 + ARRAY_SIZE(edid_cea_modes_1))
vic = 193;
return vic;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/4] drm/edid: Add CTA-861-G modes with VIC >= 193
On 9/25/2019 7:25 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Add a second table to the cea modes with VIC >= 193.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 151 -
1 file changed, 149 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b700fc075257..9f6996323efa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1376,6 +1376,149 @@ static const struct drm_display_mode edid_cea_modes_0[]
= {
.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
};
+/*
+ * From CEA/CTA-861 spec.
+ *
+ * Index with VIC-193.
+ */
+static const struct drm_display_mode edid_cea_modes_193[] = {
just like previous patch, should we call it edid_cea_861_g_modes ?
+ /* 193 - 5120x2160@120Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 1485000, 5120, 5284,
+ 5372, 5500, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 194 - 7680x4320@24Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 195 - 7680x4320@25Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
+ 10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 196 - 7680x4320@30Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
+ 8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 197 - 7680x4320@48Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 198 - 7680x4320@50Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10032,
+ 10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 199 - 7680x4320@60Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 8232,
+ 8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 200 - 7680x4320@100Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 9792,
+ 9968, 10560, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 201 - 7680x4320@120Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 8032,
+ 8208, 8800, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 202 - 7680x4320@24Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 203 - 7680x4320@25Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
+ 10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 204 - 7680x4320@30Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
+ 8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 205 - 7680x4320@48Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+
Re: [Intel-gfx] [PATCH v3 1/4] drm/edid: Abstract away cea_edid_modes[]
Hello Ville,
On 9/25/2019 7:24 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We're going to need two cea mode tables (on for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to indicathe how it's to be
Should we call it something which indicates the spec version, instead of
a random '0', like edid_cea_861_F_modes[] and the next one as _G_modes
or CTA_3 modes ?
indexed.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 80 +++---
1 file changed, 58 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3c9703b08491..b700fc075257 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -707,12 +707,11 @@ static const struct minimode extra_modes[] = {
};
/*
- * Probably taken from CEA-861 spec.
- * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
+ * From CEA/CTA-861 spec.
*
- * Index using the VIC.
+ * Index with VIC.
*/
-static const struct drm_display_mode edid_cea_modes[] = {
+static const struct drm_display_mode edid_cea_modes_0[] = {
/* 0 - dummy, VICs start at 1 */
{ },
/* 1 - 640x480@60Hz 4:3 */
@@ -3067,6 +3066,25 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
return cea;
}
+static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
+{
+ if (!vic)
+ return NULL;
+ if (vic < ARRAY_SIZE(edid_cea_modes_0))
+ return _cea_modes_0[vic];
+ return NULL;
+}
+
+static u8 cea_num_vics(void)
+{
+ return ARRAY_SIZE(edid_cea_modes_0);
+}
+
+static u8 cea_next_vic(u8 vic)
+{
+ return vic + 1;
Is there any specific reason for adding a new helper function, just to
return vic + 1 ?
+}
+
/*
* Calculate the alternate clock for the CEA mode
* (60Hz vs. 59.94Hz etc.)
@@ -3104,14 +3122,14 @@ cea_mode_alternate_timings(u8 vic, struct
drm_display_mode *mode)
* get the other variants by simply increasing the
* vertical front porch length.
*/
- BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
-edid_cea_modes[9].vtotal != 262 ||
-edid_cea_modes[12].vtotal != 262 ||
-edid_cea_modes[13].vtotal != 262 ||
-edid_cea_modes[23].vtotal != 312 ||
-edid_cea_modes[24].vtotal != 312 ||
-edid_cea_modes[27].vtotal != 312 ||
-edid_cea_modes[28].vtotal != 312);
+ BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262 ||
+cea_mode_for_vic(9)->vtotal != 262 ||
+cea_mode_for_vic(12)->vtotal != 262 ||
+cea_mode_for_vic(13)->vtotal != 262 ||
+cea_mode_for_vic(23)->vtotal != 312 ||
+cea_mode_for_vic(24)->vtotal != 312 ||
+cea_mode_for_vic(27)->vtotal != 312 ||
+cea_mode_for_vic(28)->vtotal != 312);
if (((vic == 8 || vic == 9 ||
vic == 12 || vic == 13) && mode->vtotal < 263) ||
@@ -3139,10 +3157,16 @@ static u8 drm_match_cea_mode_clock_tolerance(const
struct drm_display_mode *to_m
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
- for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
- struct drm_display_mode cea_mode = edid_cea_modes[vic];
+ for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+ const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+ struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
+ if (!mode)
+ continue;
+
+ cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3178,10 +3202,16 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
- for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
- struct drm_display_mode cea_mode = edid_cea_modes[vic];
+ for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
Again, why not just vic+=1 :) ?
+ const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+ struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
+ if (!mode)
+ continue;
+
+ cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3202,7 +3232,7 @@ EXPORT_SYMBOL(drm_match_cea_mode);
static
Re: [Intel-gfx] [PATCH v7 04/10] drm/i915/dsb: Indexed register write function for DSB.
On 9/19/2019 10:08 PM, Jani Nikula wrote:
On Wed, 18 Sep 2019, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code comment. (Shashank)
v4: cosmetic changes done. (Shashank)
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 66
drivers/gpu/drm/i915/display/intel_dsb.h | 8 +++
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index f94cd6dc98b6..2d80e452e284 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -12,8 +12,10 @@
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_BYTE_EN 0xF
#define DSB_BYTE_EN_SHIFT 20
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -86,6 +88,70 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
+ return;
+ }
+
+ /*
+* For example the buffer will look like below for 3 dwords for auto
+* increment register:
+* ++
+* | size = 3 | offset &| value1 | value2 | value3 | zero |
+* | | opcode |||||
+* ++
+* + + +++++
+* 0 4 812 16 20 24
+* Byte
+*
+* As every instruction is 8 byte aligned the index of dsb instruction
+* will start always from even number while dealing with u32 array. If
+* we are writing odd no of dwords, Zeros will be added in the end for
+* padding.
+*/
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
dsb->ins_start_offset is never reset anywhere.
Imagine you do:
intel_dsb_indexed_reg_write(dsb, FOO, 0);
intel_dsb_indexed_reg_write(dsb, FOO, 0);
intel_dsb_reg_write(dsb, BAR, 0);
intel_dsb_indexed_reg_write(dsb, FOO, 0);
The last one will screw up the previous indexed writes.
BR,
Jani.
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+ dsb->ins_start_offset = dsb->free_pos;
+
Not sure if I got your point correctly, but here is the ins_start_offset
getting reset, with the new free_pos aligned with 2
- Shashank
+ /* Update the size. */
+ buf[dsb->free_pos++] = 1;
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 0686d67b34d5..d6ced4422814 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -30,11 +30,19 @@ struct intel_dsb {
* and help in calculating tail of command buffer.
*/
int free_pos;
+
+ /*
+* ins_start_offset will help to store start address
+* of the dsb instuction of auto-increment register.
+
Re: [Intel-gfx] [PATCH v7 10/10] drm/i915/dsb: Documentation for DSB.
On 9/18/2019 1:27 PM, Animesh Manna wrote:
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
Documentation/gpu/i915.rst | 9
drivers/gpu/drm/i915/display/intel_dsb.c | 68
2 files changed, 77 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index e249ea7b0ec7..465779670fd4 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -246,6 +246,15 @@ Display PLLs
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h
:internal:
+Display State Buffer
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
+ :doc: DSB
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
+ :internal:
+
Memory Management and Command Submission
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
index cbf7f2c3300c..5b5278c94ca7 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,23 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/**
+ * DOC: DSB
+ *
+ * A DSB (Display State Buffer) is a queue of MMIO instructions in the memory
+ * which can be offloaded to DSB HW in Display Controller. DSB HW is a DMA
+ * engine that can be programmed to download the DSB from memory.
+ * It allows driver to batch submit display HW programming. This helps to
+ * reduce loading time and CPU activity, thereby making the context switch
+ * faster. DSB Support added from Gen12 Intel graphics based platform.
+ *
+ * DSB's can access only the pipe, plane, and transcoder Data Island Packet
+ * registers.
+ *
+ * DSB HW can support only register writes (both indexed and direct MMIO
+ * writes). There are no registers reads possible with DSB HW engine.
+ */
+
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_MMIO_WRITE 0x1
@@ -66,6 +83,17 @@ static inline bool intel_dsb_disable_engine(struct intel_dsb
*dsb)
return true;
}
+/**
+ * intel_dsb_get() - Allocate dsb context and return a dsb instance.
we are using 'dsb' and 'DSB' both. Please use one of these, and make it
uniform across the doc. I will prefer DSB (expect function names of
course :))
+ * @crtc: intel_crtc structure to get pipe info.
+ *
+ * This function will give handle of the DSB instance which
+ * user want to operate on.
Little re-arrangement: This function provides handle of a DSB instance,
for the further DSB operations.
+ *
+ * Return : address of Intel_dsb instance requested for.
Returns:
+ * In failure case, the dsb instance will not have any command buffer.
Failure: Returns the same DSB instance, but without a command buffer.
+ */
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -116,6 +144,14 @@ intel_dsb_get(struct intel_crtc *crtc)
return dsb;
}
+/**
+ * intel_dsb_put() - To destroy DSB context.
+ * @dsb: intel_dsb structure.
+ *
+ * This function is used to destroy the dsb-context by doing unpin
+ * and release the vma object.
This function destroys the DSB context allocated by a dsb_get(), by
unpinning and releasing the VMA object associated with it.
+ */
+
void intel_dsb_put(struct intel_dsb *dsb)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
@@ -137,6 +173,19 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+/**
+ * intel_dsb_indexed_reg_write() -Write to the dsb context for auto
+ * increment register.
+ * @dsb: intel_dsb structure.
+ * @reg: register address.
+ * @val: value.
+ *
+ * This function is used for auto-increment register and intel_dsb_reg_write()
+ * is used for normal register.
I am not able to get the message out of this line. why are we adding the
description of intel_dsb_reg_write() here ?
Please keep this simple and explain only function under description.
During command buffer overflow, a warning
+ * is thrown and rest all erroneous condition register programming is done
+ * through mmio write.
+ */
+
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val)
{
@@ -201,6 +250,18 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
i915_reg_t reg,
buf[dsb->free_pos] = 0;
}
+/**
+ * intel_dsb_reg_write() -Write to the dsb context for normal
+ * register.
+ * @dsb: intel_dsb structure.
+ * @reg: register address.
+ * @val: value.
+ *
+ * This function is used for writing register-value pair in command
+ * buffer of DSB. During command buffer overflow, a warning
+ * is thrown and rest all erroneous condition register programming is done
+ * through mmio write.
+ */
void intel_dsb_reg_write(struct intel_dsb *dsb,
Re: [Intel-gfx] [PATCH v7 07/10] drm/i915/dsb: function to trigger workload execution of DSB.
On 9/18/2019 1:27 PM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 1d6ce36dbad4..cbf7f2c3300c 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -222,3 +222,45 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
+ return;
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
+ intel_dsb_disable_engine(dsb);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index d6ced4422814..dca4e632dd3c 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -44,5 +44,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dbaa49f5c74..c77b5066d8dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11687,6 +11687,8 @@ enum skl_power_gate {
#define _DSBSL_INSTANCE_BASE 0x70B00
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
+#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
#define DSB_CTRL(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
As discussed with Jani, I would expect some changes here, but we can do
those in a staged manner. For now, LGTM,
Please feel free to use: Reviewed-by: Shashank Sharma
Regards
Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 09/10] drm/i915/dsb: Enable DSB for gen12.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
Enabling DSB by setting 1 to has_dsb flag for gen12.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b3cc8560696b..1fd2a364891a 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -787,7 +787,8 @@ static const struct intel_device_info
intel_elkhartlake_info = {
[TRANSCODER_DSI_0] = TRANSCODER_DSI0_OFFSET, \
[TRANSCODER_DSI_1] = TRANSCODER_DSI1_OFFSET, \
}, \
- .has_global_mocs = 1
+ .has_global_mocs = 1, \
+ .display.has_dsb = 1
Looks good to me, feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
static const struct intel_device_info intel_tigerlake_12_info = {
GEN12_FEATURES,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/dsb: function to trigger workload execution of DSB.
On 9/12/2019 7:09 PM, Jani Nikula wrote:
On Thu, 12 Sep 2019, "Sharma, Shashank" wrote:
On 9/12/2019 12:41 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2b0ffc0afb74..eea86afb0583 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -212,3 +212,45 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
+ return;
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
+ intel_dsb_disable_engine(dsb);
I am still not very convince if a commit function should be void, I
would still want it to return success or failure, so that we would know
if the last operation was successful or not.
I would wait Jani N to comment here, on what he feels about this.
The question becomes, what do you *do* with the return value? If none of
the callers are going to use it, don't return it.
I was thinking we should check the return value of the DSB commit (if
not writes), so that we would be aware that the register programming
failed, and later even can think about a fallback method. Too ambitious ?
- Shashank
BR,
Jani.
- Shashank
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 9b2522f20bfb..7389c8c5b665 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -43,5 +43,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dbaa49f5c74..c77b5066d8dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11687,6 +11687,8 @@ enum skl_power_gate {
#define _DSBSL_INSTANCE_BASE 0x70B00
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
+#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/dsb: function to trigger workload execution of DSB.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2b0ffc0afb74..eea86afb0583 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -212,3 +212,45 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
+ return;
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
+ intel_dsb_disable_engine(dsb);
I am still not very convince if a commit function should be void, I
would still want it to return success or failure, so that we would know
if the last operation was successful or not.
I would wait Jani N to comment here, on what he feels about this.
- Shashank
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 9b2522f20bfb..7389c8c5b665 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -43,5 +43,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dbaa49f5c74..c77b5066d8dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11687,6 +11687,8 @@ enum skl_power_gate {
#define _DSBSL_INSTANCE_BASE 0x70B00
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
+#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
#define DSB_CTRL(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 06/10] drm/i915/dsb: functions to enable/disable DSB engine.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
v2: POSTING_READ added after writing control register. (Shashank)
v3: cosmetic changes done. (Shashank)
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 40
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index b1da2b06263a..2b0ffc0afb74 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -26,6 +26,46 @@ static inline bool is_dsb_busy(struct intel_dsb *dsb)
return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
}
+static inline bool intel_dsb_enable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl |= DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
+ POSTING_READ(DSB_CTRL(pipe, dsb->id));
+ return true;
+}
+
+static inline bool intel_dsb_disable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl &= ~DSB_ENABLE;
Do we really need to care about reading the reg val first and then
disabling it ? I can understand that for enable().
How about this:
if (!dsb_is_busy()) {
I915_WRITE(DSB_CTRL(pipe, dsb->id), 0);
POSTING_READ();
return true;
}
DRM_DEBUG_KMS("DSB engine is busy.\n");
return false;
But this is optional suggestion, you can take a call on this.
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
+ POSTING_READ(DSB_CTRL(pipe, dsb->id));
+ return true;
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9188a0b53538..2dbaa49f5c74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11688,6 +11688,7 @@ enum skl_power_gate {
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
#define DSB_CTRL(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
With or without suggested change above: Feel free to use
Reviewed-by: Shashank Sharma
- Shashank
#endif /* _I915_REG_H_ */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 05/10] drm/i915/dsb: Check DSB engine status.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 7 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 9e2927f869b9..b1da2b06263a 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -17,6 +17,15 @@
#define DSB_BYTE_EN_SHIFT 20
#define DSB_REG_VALUE_MASK0xf
+static inline bool is_dsb_busy(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bf37ecebc82f..9188a0b53538 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11683,4 +11683,11 @@ enum skl_power_gate {
#define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia), 0x00894)
#define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)(1 << (tc_port))
+/* This register controls the Display State Buffer (DSB) engines. */
+#define _DSBSL_INSTANCE_BASE 0x70B00
+#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
+(pipe) * 0x1000 + (id) * 100)
+#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_STATUS (1 << 0)
+
#endif /* _I915_REG_H_ */
Looks good to me,
Please feel free to use Reviewed-by: Shashank Sharma
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 03/10] drm/i915/dsb: single register write function for DSB.
On 9/12/2019 6:37 PM, Animesh Manna wrote:
On 9/12/2019 6:30 PM, Sharma, Shashank wrote:
On 9/12/2019 6:21 PM, Jani Nikula wrote:
On Thu, 12 Sep 2019, "Sharma, Shashank"
wrote:
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro removed and cosmetic changes done. (Shashank)
v3: set free_pos to zero in dsb-put() instead dsb-get() and
a cosmetic change. (Shashank)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 30
drivers/gpu/drm/i915/display/intel_dsb.h | 9 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 7c1b1574788c..e2c383352145 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,13 @@
#define DSB_BUF_SIZE (2 * PAGE_SIZE)
+/* DSB opcodes. */
+#define DSB_OPCODE_SHIFT 24
+#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
We are not using this macro here, this should go to the Batch
/INDEXED_WRITE patch.
+#define DSB_BYTE_EN 0xF
+#define DSB_BYTE_EN_SHIFT 20
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -66,5 +73,28 @@ void intel_dsb_put(struct intel_dsb *dsb)
i915_vma_unpin_and_release(>vma, 0);
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
+ dsb->free_pos = 0;
+ }
+}
+
I hope this addition of braces are due to diff's adjustment.
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
why shouldn't we do a I915_WRITE(reg, val) here too? This is single
register write, and we can handle this.
That would assume it's okay to directly mmio write this and the
subsequent values, and write the batch already stored in the buffer
afterwards.
This is single write API, so I won't expect this to be called in an
indexed context, also, we have exceeded the buffer size already, so
no subsequent DSB write would be possible anyways. But I can still
see it would be some kind of mess only, so doesn't really matter if
we do this I915_write or not :).
Adding I915_WRITE can be done, but I feel better to break the
functionality where we have buffer overflow and based on that we can
fine tune the buffer size.
If a set of register is targetted to write through DSB then some
writing through MMIO and and rest writing though DSB may not a nice
thing.
So added only debug log to capture the issue.
Regards,
Animesh
Yeah, broken this way or other, better to warn as soon as possible.
With the above macro comment fixed,
Please feel free to use Reviewed-by: Shashank Sharma
- Shashank
- Shashank
BR,
Jani.
+ return;
}
+
+ buf[dsb->free_pos++] = val;
+ buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE <<
DSB_OPCODE_SHIFT) |
+ (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
+ i915_mmio_reg_offset(reg);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 27eb68eb5392..31b87dcfe160 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_DSB_H
#define _INTEL_DSB_H
+#include "i915_reg.h"
+
struct intel_crtc;
struct i915_vma;
@@ -21,10 +23,17 @@ struct intel_dsb {
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
+
+ /*
+ * free_pos will point the first free entry position
+ * and help in calculating tail of command buffer.
+ */
+ int free_pos;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 04/10] drm/i915/dsb: Indexed register write function for DSB.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code comment. (Shashank)
v4: cosmetic changes done. (Shashank)
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 65
drivers/gpu/drm/i915/display/intel_dsb.h | 8 +++
2 files changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index e2c383352145..9e2927f869b9 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -15,6 +15,7 @@
#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_BYTE_EN 0xF
#define DSB_BYTE_EN_SHIFT 20
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -77,6 +78,70 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
+ return;
+ }
+
+ /*
+* For example the buffer will look like below for 3 dwords for auto
+* increment register:
+* ++
+* | size = 3 | offset &| value1 | value2 | value3 | zero |
+* | | opcode |||||
+* ++
+* + + +++++
+* 0 4 812 16 20 24
+* Byte
+*
+* As every instruction is 8 byte aligned the index of dsb instruction
+* will start always from even number while dealing with u32 array. If
+* we are writing odd no of dwords, Zeros will be added in the end for
+* padding.
+*/
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+ dsb->ins_start_offset = dsb->free_pos;
+
+ /* Update the size. */
+ buf[dsb->free_pos++] = 1;
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
So we are adding 0 on every even position while writing buffer and
letting the next write to overwrite it. Can be done in commit() in the
end too, but I think its more or less same.
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 31b87dcfe160..9b2522f20bfb 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -29,11 +29,19 @@ struct intel_dsb {
* and help in calculating tail of command buffer.
*/
int free_pos;
+
+ /*
+* ins_start_offset will help to store start address
+* of the dsb instuction of auto-increment register.
+*/
+ u32 ins_start_offset;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val);
#end
Re: [Intel-gfx] [PATCH v6 03/10] drm/i915/dsb: single register write function for DSB.
On 9/12/2019 6:21 PM, Jani Nikula wrote:
On Thu, 12 Sep 2019, "Sharma, Shashank" wrote:
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro removed and cosmetic changes done. (Shashank)
v3: set free_pos to zero in dsb-put() instead dsb-get() and
a cosmetic change. (Shashank)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 30
drivers/gpu/drm/i915/display/intel_dsb.h | 9 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 7c1b1574788c..e2c383352145 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,13 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/* DSB opcodes. */
+#define DSB_OPCODE_SHIFT 24
+#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
We are not using this macro here, this should go to the Batch
/INDEXED_WRITE patch.
+#define DSB_BYTE_EN0xF
+#define DSB_BYTE_EN_SHIFT 20
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -66,5 +73,28 @@ void intel_dsb_put(struct intel_dsb *dsb)
i915_vma_unpin_and_release(>vma, 0);
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
+ dsb->free_pos = 0;
+ }
+}
+
I hope this addition of braces are due to diff's adjustment.
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
why shouldn't we do a I915_WRITE(reg, val) here too? This is single
register write, and we can handle this.
That would assume it's okay to directly mmio write this and the
subsequent values, and write the batch already stored in the buffer
afterwards.
This is single write API, so I won't expect this to be called in an
indexed context, also, we have exceeded the buffer size already, so no
subsequent DSB write would be possible anyways. But I can still see it
would be some kind of mess only, so doesn't really matter if we do this
I915_write or not :).
- Shashank
BR,
Jani.
+ return;
}
+
+ buf[dsb->free_pos++] = val;
+ buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
+ (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
+ i915_mmio_reg_offset(reg);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 27eb68eb5392..31b87dcfe160 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_DSB_H
#define _INTEL_DSB_H
+#include "i915_reg.h"
+
struct intel_crtc;
struct i915_vma;
@@ -21,10 +23,17 @@ struct intel_dsb {
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
+
+ /*
+* free_pos will point the first free entry position
+* and help in calculating tail of command buffer.
+*/
+ int free_pos;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 03/10] drm/i915/dsb: single register write function for DSB.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro removed and cosmetic changes done. (Shashank)
v3: set free_pos to zero in dsb-put() instead dsb-get() and
a cosmetic change. (Shashank)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 30
drivers/gpu/drm/i915/display/intel_dsb.h | 9 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 7c1b1574788c..e2c383352145 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,13 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/* DSB opcodes. */
+#define DSB_OPCODE_SHIFT 24
+#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
We are not using this macro here, this should go to the Batch
/INDEXED_WRITE patch.
+#define DSB_BYTE_EN0xF
+#define DSB_BYTE_EN_SHIFT 20
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -66,5 +73,28 @@ void intel_dsb_put(struct intel_dsb *dsb)
i915_vma_unpin_and_release(>vma, 0);
mutex_unlock(>drm.struct_mutex);
dsb->cmd_buf = NULL;
+ dsb->free_pos = 0;
+ }
+}
+
I hope this addition of braces are due to diff's adjustment.
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow\n");
why shouldn't we do a I915_WRITE(reg, val) here too? This is single
register write, and we can handle this.
+ return;
}
+
+ buf[dsb->free_pos++] = val;
+ buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
+ (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
+ i915_mmio_reg_offset(reg);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 27eb68eb5392..31b87dcfe160 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_DSB_H
#define _INTEL_DSB_H
+#include "i915_reg.h"
+
struct intel_crtc;
struct i915_vma;
@@ -21,10 +23,17 @@ struct intel_dsb {
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
+
+ /*
+* free_pos will point the first free entry position
+* and help in calculating tail of command buffer.
+*/
+ int free_pos;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/10] drm/i915/dsb: DSB context creation.
fier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef _INTEL_DSB_H
+#define _INTEL_DSB_H
+
+struct intel_crtc;
+struct i915_vma;
+
+enum dsb_id {
+ INVALID_DSB = -1,
+ DSB1,
+ DSB2,
+ DSB3,
+ MAX_DSB_PER_PIPE
+};
+
+struct intel_dsb {
+ enum dsb_id id;
+ u32 *cmd_buf;
+ struct i915_vma *vma;
+};
+
+struct intel_dsb *
+intel_dsb_get(struct intel_crtc *crtc);
+void intel_dsb_put(struct intel_dsb *dsb);
+
+#endif
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6c6af007f29d..069a06edb5c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,6 +67,7 @@
#include "display/intel_display.h"
#include "display/intel_display_power.h"
#include "display/intel_dpll_mgr.h"
+#include "display/intel_dsb.h"
#include "display/intel_frontbuffer.h"
#include "display/intel_gmbus.h"
#include "display/intel_opregion.h"
With the minor comments fixed, please feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 01/10] drm/i915/dsb: feature flag added for display state buffer.
On 9/12/2019 12:41 AM, Animesh Manna wrote:
Display State Buffer(DSB) is a new hardware capability, introduced
in GEN12 display. DSB allows a driver to batch-program display HW
registers.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ea11123e933..6c6af007f29d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1863,6 +1863,8 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
(BUILD_BUG_ON_ZERO(!__builtin_constant_p(n)) + \
INTEL_INFO(dev_priv)->gen == (n))
+#define HAS_DSB(dev_priv) (INTEL_INFO(dev_priv)->display.has_dsb)
+
/*
* Return true if revision is in range [since,until] inclusive.
*
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 92e0c2e0954c..e206f298f48e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -135,6 +135,7 @@ enum intel_ppgtt_type {
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
+ func(has_dsb); \
func(has_fbc); \
func(has_gmch); \
func(has_hotplug); \
Looks good to me,
Feel free to use: Reviewed-by: Shashank Sharma
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/11] drm/i915/dsb: Check DSB engine status.
> -Original Message-
> From: Manna, Animesh
> Sent: Monday, September 9, 2019 10:27 PM
> To: Sharma, Shashank ; intel-
> g...@lists.freedesktop.org
> Cc: Thierry, Michel ; Nikula, Jani
> ;
> Vivi, Rodrigo
> Subject: Re: [PATCH v5 05/11] drm/i915/dsb: Check DSB engine status.
>
>
>
> On 9/9/2019 6:43 PM, Sharma, Shashank wrote:
> >
> > On 9/7/2019 4:37 PM, Animesh Manna wrote:
> >> As per bspec check for DSB status before programming any of its
> >> register. Inline function added to check the dsb status.
> >>
> >> Cc: Michel Thierry
> >> Cc: Jani Nikula
> >> Cc: Rodrigo Vivi
> >> Cc: Shashank Sharma
> >> Signed-off-by: Animesh Manna
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dsb.c | 9 +
> >> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> >> 2 files changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> >> b/drivers/gpu/drm/i915/display/intel_dsb.c
> >> index 0f55ed683d41..2c8415518c65 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> >> @@ -17,6 +17,15 @@
> >> #define DSB_BYTE_EN_SHIFT20
> >> #define DSB_REG_VALUE_MASK0xf
> >> +static inline bool is_dsb_busy(struct intel_dsb *dsb)
> >> +{
> >> +struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
> >> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> +enum pipe pipe = crtc->pipe;
> >> +
> >> +return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id)); }
> >> +
> >> struct intel_dsb *
> >> intel_dsb_get(struct intel_crtc *crtc)
> >> {
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h index 006cffd56be2..a3099f712ae6
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -11676,4 +11676,11 @@ enum skl_power_gate {
> >> #define PORT_TX_DFLEXDPCSSS(fia)_MMIO_FIA((fia), 0x00894)
> >> #define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)(1 << (tc_port))
> >> +/* This register controls the Display State Buffer (DSB) engines.
> >> */
> >> +#define _DSBSL_INSTANCE_BASE0x70B00
> >> +#define DSBSL_INSTANCE(pipe, id)(_DSBSL_INSTANCE_BASE + \
> >> + (pipe) * 0x1000 + (id) * 100)
> >
> > Why is pipe in () ?
>
> mmio offset per DSB depend on pipe and dsb-id (3 DSB per pipe.) offset of
> PIPE_A
> DSB1-> 70B00 offset of PIPE_B DSB1-> 71B00 and so on...
>
The question here is why is the 'pipe' in braces ? why is it '(pipe)', instead
of 'pipe'. I don’t see a reason.
- Shashank
> Regards,
> Animesh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/11] drm/i915/dsb: added dsb refcount to synchronize between get/put.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
The lifetime of command buffer can be controlled by the dsb user
throuh refcount. Added refcount mechanism is dsb get/put call
which create/destroy dsb context.
Cc: Jani Nikula
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 22 --
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 853685751540..b951a6b5264a 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -78,7 +78,12 @@ intel_dsb_get(struct intel_crtc *crtc)
struct intel_dsb *dsb = >dsb;
intel_wakeref_t wakeref;
- if ((!HAS_DSB(i915)) || dsb->cmd_buf)
+ if (!HAS_DSB(i915))
+ return dsb;
+
+ atomic_inc(>refcount);
+
As discussed we are not solving any problem with reference counting,
rather, we are adding a complexity here. It may be useful, when we are
extending single instance of DSB to DSB pool but not right now.
I would say we drop this patch all together, and just have the simple
implementation now.
- Shashank
+ if (dsb->cmd_buf)
return dsb;
dsb->id = DSB1;
@@ -94,6 +99,7 @@ intel_dsb_get(struct intel_crtc *crtc)
if (IS_ERR(vma)) {
DRM_ERROR("Vma creation failed.\n");
i915_gem_object_put(obj);
+ atomic_dec(>refcount);
goto err;
}
@@ -102,6 +108,7 @@ intel_dsb_get(struct intel_crtc *crtc)
DRM_ERROR("Command buffer creation failed.\n");
i915_vma_unpin_and_release(, 0);
dsb->cmd_buf = NULL;
+ atomic_dec(>refcount);
goto err;
}
dsb->vma = vma;
@@ -121,11 +128,14 @@ void intel_dsb_put(struct intel_dsb *dsb)
return;
if (dsb->cmd_buf) {
- mutex_lock(>drm.struct_mutex);
- i915_gem_object_unpin_map(dsb->vma->obj);
- i915_vma_unpin_and_release(>vma, 0);
- dsb->cmd_buf = NULL;
- mutex_unlock(>drm.struct_mutex);
+ atomic_dec(>refcount);
+ if (!atomic_read(>refcount)) {
+ mutex_lock(>drm.struct_mutex);
+ i915_gem_object_unpin_map(dsb->vma->obj);
+ i915_vma_unpin_and_release(>vma, 0);
+ dsb->cmd_buf = NULL;
+ mutex_unlock(>drm.struct_mutex);
+ }
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h b/drivers/gpu/drm/i915/display/intel_dsb.h
index 7389c8c5b665..dca4e632dd3c 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -20,6 +20,7 @@ enum dsb_id {
};
struct intel_dsb {
+ atomic_t refcount;
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 07/11] drm/i915/dsb: function to trigger workload execution of DSB.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 56bf41b00f62..853685751540 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -213,3 +213,45 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
I am seeing that in both success and failure cases, we are not returning
anything. We have some error messages, but I would still like the caller
to know if the commit was successful or not, with a return value. Do you
think so Jani?
- Shashank
+ return;
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
+ intel_dsb_disable_engine(dsb);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 9b2522f20bfb..7389c8c5b665 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -43,5 +43,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2df01386e3de..cfb78a2f94fe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11680,6 +11680,8 @@ enum skl_power_gate {
#define _DSBSL_INSTANCE_BASE 0x70B00
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
+#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
#define DSB_CTRL(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 06/11] drm/i915/dsb: functions to enable/disable DSB engine.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
v2: POSTING_READ added after writing control register. (Shashank)
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2c8415518c65..56bf41b00f62 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -26,6 +26,48 @@ static inline bool is_dsb_busy(struct intel_dsb *dsb)
return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
}
+static inline bool intel_dsb_enable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+
This space not required.
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl |= DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
+ POSTING_READ(DSB_CTRL(pipe, dsb->id));
+ return true;
+}
+
+static inline bool intel_dsb_disable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+
Same here.
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl &= ~DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
+ POSTING_READ(DSB_CTRL(pipe, dsb->id));
+ return true;
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a3099f712ae6..2df01386e3de 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11681,6 +11681,7 @@ enum skl_power_gate {
#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
#define DSB_CTRL(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
#endif /* _I915_REG_H_ */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/11] drm/i915/dsb: Check DSB engine status.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 7 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 0f55ed683d41..2c8415518c65 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -17,6 +17,15 @@
#define DSB_BYTE_EN_SHIFT 20
#define DSB_REG_VALUE_MASK0xf
+static inline bool is_dsb_busy(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 006cffd56be2..a3099f712ae6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11676,4 +11676,11 @@ enum skl_power_gate {
#define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia), 0x00894)
#define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)(1 << (tc_port))
+/* This register controls the Display State Buffer (DSB) engines. */
+#define _DSBSL_INSTANCE_BASE 0x70B00
+#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
+(pipe) * 0x1000 + (id) * 100)
Why is pipe in () ?
- Shashank
+#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_STATUS (1 << 0)
+
#endif /* _I915_REG_H_ */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 04/11] drm/i915/dsb: Indexed register write function for DSB.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code comment. (Shashank)
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 64
drivers/gpu/drm/i915/display/intel_dsb.h | 8 +++
2 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 150be81fdfb3..0f55ed683d41 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -15,6 +15,7 @@
#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_BYTE_EN 0xF
#define DSB_BYTE_EN_SHIFT 20
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -77,6 +78,69 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow.\n");
Again, '.' in the end can be removed
+ return;
+ }
+
+ /*
+* For example the buffer will look like below for 3 dwords for auto
+* increment register:
+* ++
+* | size = 3 | offset &| value1 | value2 | value3 | zero |
+* | | opcode |||||
+* ++
+* + + +++++
+* 0 4 812 16 20 24
+* Byte
+*
+* As every instruction is 8 byte aligned the index of dsb instruction
+* will start always from even number while dealing with u32 array and
+* zero to be added for odd number of dwords at the last.
Let's split this comment in two parts, to make even more useful, like:
"As every instruction . array". "If we are
writing odd no of dwords, Zeros will be added in the end for padding."
- Shashank
+*/
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+ dsb->ins_start_offset = dsb->free_pos;
+
+ /* Update the size. */
+ buf[dsb->free_pos++] = 1;
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 31b87dcfe160..9b2522f20bfb 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -29,11 +29,19 @@ struct intel_dsb {
* and help in calculating tail of command buffer.
*/
int free_pos;
+
+ /*
+* ins_start_offset will help to store start address
+* of the dsb instuction of auto-increment register.
+*/
+ u32 ins_start_offset;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val);
#endif
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH v5 03/11] drm/i915/dsb: single register write function for DSB.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro removed and cosmetic changes done. (Shashank)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 30
drivers/gpu/drm/i915/display/intel_dsb.h | 9 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index cba5c8d37659..150be81fdfb3 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,13 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/* DSB opcodes. */
+#define DSB_OPCODE_SHIFT 24
+#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_INDEXED_WRITE 0x9
+#define DSB_BYTE_EN0xF
+#define DSB_BYTE_EN_SHIFT 20
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -46,6 +53,7 @@ intel_dsb_get(struct intel_crtc *crtc)
goto err;
}
dsb->vma = vma;
+ dsb->free_pos = 0;
This should be done in dsb_put();
err:
intel_runtime_pm_put(>runtime_pm, wakeref);
@@ -68,3 +76,25 @@ void intel_dsb_put(struct intel_dsb *dsb)
mutex_unlock(>drm.struct_mutex);
}
}
+
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+
+ if (!buf) {
+ I915_WRITE(reg, val);
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow.\n");
Lets remove this '.' in the end, to maintain consistency in the log.
- Shashank
+ return;
+ }
+
+ buf[dsb->free_pos++] = val;
+ buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
+ (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
+ i915_mmio_reg_offset(reg);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 27eb68eb5392..31b87dcfe160 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_DSB_H
#define _INTEL_DSB_H
+#include "i915_reg.h"
+
struct intel_crtc;
struct i915_vma;
@@ -21,10 +23,17 @@ struct intel_dsb {
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
+
+ /*
+* free_pos will point the first free entry position
+* and help in calculating tail of command buffer.
+*/
+ int free_pos;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 02/11] drm/i915/dsb: DSB context creation.
On 9/7/2019 4:37 PM, Animesh Manna wrote:
This patch adds a function, which will internally get the gem buffer
for DSB engine. The GEM buffer is from global GTT, and is mapped into
CPU domain, contains the data + opcode to be feed to DSB engine.
v1: Initial version.
v2:
- removed some unwanted code. (Chris)
- Used i915_gem_object_create_internal instead of _shmem. (Chris)
- cmd_buf_tail removed and can be derived through vma object. (Chris)
v3: vma realeased if i915_gem_object_pin_map() failed. (Shashank)
v4: for simplification and based on current usage added single dsb
object in intel_crtc. (Shashank)
Cc: Imre Deak
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/display/intel_dsb.c | 70 +++
drivers/gpu/drm/i915/display/intel_dsb.h | 30
drivers/gpu/drm/i915/i915_drv.h | 1 +
5 files changed, 105 insertions(+)
create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 658b930d34a8..6313e7b4bd78 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -172,6 +172,7 @@ i915-y += \
display/intel_display_power.o \
display/intel_dpio_phy.o \
display/intel_dpll_mgr.o \
+ display/intel_dsb.o \
display/intel_fbc.o \
display/intel_fifo_underrun.o \
display/intel_frontbuffer.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d5cc4b810d9e..49c902b00484 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1033,6 +1033,9 @@ struct intel_crtc {
/* scalers available on this crtc */
int num_scalers;
+
+ /* per pipe DSB related info */
+ struct intel_dsb dsb;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
new file mode 100644
index ..cba5c8d37659
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ */
+
+#include "i915_drv.h"
+#include "intel_display_types.h"
+
+#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+
+struct intel_dsb *
+intel_dsb_get(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ struct intel_dsb *dsb = >dsb;
+ intel_wakeref_t wakeref;
+
+ if ((!HAS_DSB(i915)) || dsb->cmd_buf)
+ return dsb;
+
+ dsb->id = DSB1;
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
+ if (IS_ERR(obj))
+ goto err;
+
+ mutex_lock(>drm.struct_mutex);
+ vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(vma)) {
+ DRM_ERROR("Vma creation failed.\n");
+ i915_gem_object_put(obj);
+ goto err;
+ }
+
+ dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+ if (IS_ERR(dsb->cmd_buf)) {
+ DRM_ERROR("Command buffer creation failed.\n");
+ i915_vma_unpin_and_release(, 0);
+ dsb->cmd_buf = NULL;
+ goto err;
+ }
+ dsb->vma = vma;
+
+err:
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+ return dsb;
+}
+
+void intel_dsb_put(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+ if (!dsb)
+ return;
+
+ if (dsb->cmd_buf) {
+ mutex_lock(>drm.struct_mutex);
+ i915_gem_object_unpin_map(dsb->vma->obj);
+ i915_vma_unpin_and_release(>vma, 0);
+ dsb->cmd_buf = NULL;
This can be done outside mutex_unlock();
- Shashank
+ mutex_unlock(>drm.struct_mutex);
+ }
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
new file mode 100644
index ..27eb68eb5392
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef _INTEL_DSB_H
+#define _INTEL_DSB_H
+
+struct intel_crtc;
+struct i915_vma;
+
+enum dsb_id {
+ INVALID_DSB = -1,
+ DSB1,
+ DSB2,
+ DSB3,
+ MAX_DSB_PER_PIPE
+};
+
+struct intel_dsb {
+ enum
Re: [Intel-gfx] [RFC 0/2] Enable Nearest-neighbor for Integer mode scaling
On 9/4/2019 5:56 PM, Ville Syrjälä wrote: On Wed, Sep 04, 2019 at 08:32:09AM +0530, Sharma, Shashank wrote: Hello Ville, On 9/3/2019 10:50 PM, Ville Syrjälä wrote: On Tue, Sep 03, 2019 at 10:22:25PM +0530, Shashank Sharma wrote: Blurry outputs during upscaling the buffer, is a generic problem of gfx industry. One of the major reason behind this blurriness is the interpolation of pixel values used by most of the upscaling hardwares. Nearest-neighbor is a scaling mode, which works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Nearest-neighbor can produce (almost) non-blurry scaling outputs when the scaling ratio is complete integer. For example: - input buffer resolution: 1280x720(HD) - output buffer resolution: 3840x2160(UHD/4K) - scaling ratio (h) = 3840/1280 = 3 scaling ratio (v) = 2160/720 = 3 In such scenarios, we should try to pick Nearest-neighbor as scaling method when possible. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ This patch series enables NN scaling on Intel display (ICL), when the upscaling ratio is integer. I think we'd probably want a property for this sort of stuff. igt could perhaps also use it to enable crc based scaling tests. I was initially planning to attach this to scaling mode property, probably create a new option in there called "Integer mode scaling" or we can use the "maintain aspect ratio" sub-option too. Do you think it would make sense ? Or should we create a new property altogether ? I was thinking a new prop. It would also expose the possibility of adding even more filter/window functions. Maybe someone wants a linear filter for instance. Sounds good. Another problem is that we currently don't expose the panel fitter for external displays so this would be limited to eDP/DSI only. I have a branch that implements borders (for underscan) for DP/HDMI which is at least moving the code a little bit into a direction where we could consider exposing the panel fitter for external displays. This would be very interesting, do you have any plans to publish this soon ? I can send it out. Been hanging on to it because there's other pending stuff on the list as well, but a few more patches probably won't hurt :) Looking forward to it, then :) - Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/2] drm/i915: Indicate integer up-scaling ratios
On 9/4/2019 1:08 PM, Ramalingam C wrote:
On 2019-09-03 at 22:22:26 +0530, Shashank Sharma wrote:
If the upscaling ratio is a complete integer, Intel display HW can
pickup special scaling mode, which can produce better non-blurry
outputs. This patch adds a check to indicate if this is such an upscaling
opportunity, while calculating the scaler config, and stores it into scaler
state.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Vivi, Rodrigo
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/display/intel_display.c | 21 +++
.../drm/i915/display/intel_display_types.h| 7 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee54d9659c99..613130db3c05 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5388,6 +5388,19 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool
chroma_cosited)
#define SKL_MIN_YUV_420_SRC_W 16
#define SKL_MIN_YUV_420_SRC_H 16
+static inline bool
+scaling_ratio_integer(int src_w, int dst_w, int src_h, int dst_h)
Just a suggestion: scaling_ratio_is_integer() might sound better here!?
Agree, certainly sounds better.
+{
+ /* Integer mode scaling is applicable only for upscaling scenarios */
+ if (dst_w < src_w || dst_h < src_h)
+ return false;
+
+ if (dst_w % src_w == 0 && dst_h % src_h == 0)
+ return true;
+
+ return false;
+}
+
static int
skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
unsigned int scaler_user, int *scaler_id,
@@ -5422,6 +5435,14 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return -EINVAL;
}
+ /*
+* If we are upscaling, and the scaling ratios are integer, we can
+* pick nearest-neighbour method in HW for scaling, which produces
+* blurless outputs in such scenarios.
+*/
+ if (scaling_ratio_integer(src_w, dst_w, src_h, dst_h))
+ scaler_state->integer_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3c1a5f3e1d22..6bb32fbf3153 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -613,6 +613,13 @@ struct intel_crtc_scaler_state {
/* scaler used by crtc for panel fitting purpose */
int scaler_id;
+
+ /*
+* Nearest-neighbor method of upscaling gieves blurless output if
Typo: Gives.
got it.
-Ram
+* the upscaling ratio is a complete integer. This bool is to indicate
+* such an opportunity.
+*/
+ bool integer_scaling;
};
/* drm_mode->private_flags */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/2] drm/i915: Indicate integer up-scaling ratios
On 9/4/2019 12:58 PM, Jani Nikula wrote:
On Tue, 03 Sep 2019, Shashank Sharma wrote:
If the upscaling ratio is a complete integer, Intel display HW can
pickup special scaling mode, which can produce better non-blurry
outputs. This patch adds a check to indicate if this is such an upscaling
opportunity, while calculating the scaler config, and stores it into scaler
state.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Vivi, Rodrigo
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/display/intel_display.c | 21 +++
.../drm/i915/display/intel_display_types.h| 7 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee54d9659c99..613130db3c05 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5388,6 +5388,19 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool
chroma_cosited)
#define SKL_MIN_YUV_420_SRC_W 16
#define SKL_MIN_YUV_420_SRC_H 16
+static inline bool
Please don't add superfluous inlines to static functions in .c
files. Let the compiler do its job.
Sure, got it !
BR,
Jani.
+scaling_ratio_integer(int src_w, int dst_w, int src_h, int dst_h)
+{
+ /* Integer mode scaling is applicable only for upscaling scenarios */
+ if (dst_w < src_w || dst_h < src_h)
+ return false;
+
+ if (dst_w % src_w == 0 && dst_h % src_h == 0)
+ return true;
+
+ return false;
+}
+
static int
skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
unsigned int scaler_user, int *scaler_id,
@@ -5422,6 +5435,14 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return -EINVAL;
}
+ /*
+* If we are upscaling, and the scaling ratios are integer, we can
+* pick nearest-neighbour method in HW for scaling, which produces
+* blurless outputs in such scenarios.
+*/
+ if (scaling_ratio_integer(src_w, dst_w, src_h, dst_h))
+ scaler_state->integer_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3c1a5f3e1d22..6bb32fbf3153 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -613,6 +613,13 @@ struct intel_crtc_scaler_state {
/* scaler used by crtc for panel fitting purpose */
int scaler_id;
+
+ /*
+* Nearest-neighbor method of upscaling gieves blurless output if
+* the upscaling ratio is a complete integer. This bool is to indicate
+* such an opportunity.
+*/
+ bool integer_scaling;
};
/* drm_mode->private_flags */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/2] Enable Nearest-neighbor for Integer mode scaling
Hello Ville, On 9/3/2019 10:50 PM, Ville Syrjälä wrote: On Tue, Sep 03, 2019 at 10:22:25PM +0530, Shashank Sharma wrote: Blurry outputs during upscaling the buffer, is a generic problem of gfx industry. One of the major reason behind this blurriness is the interpolation of pixel values used by most of the upscaling hardwares. Nearest-neighbor is a scaling mode, which works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Nearest-neighbor can produce (almost) non-blurry scaling outputs when the scaling ratio is complete integer. For example: - input buffer resolution: 1280x720(HD) - output buffer resolution: 3840x2160(UHD/4K) - scaling ratio (h) = 3840/1280 = 3 scaling ratio (v) = 2160/720 = 3 In such scenarios, we should try to pick Nearest-neighbor as scaling method when possible. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ This patch series enables NN scaling on Intel display (ICL), when the upscaling ratio is integer. I think we'd probably want a property for this sort of stuff. igt could perhaps also use it to enable crc based scaling tests. I was initially planning to attach this to scaling mode property, probably create a new option in there called "Integer mode scaling" or we can use the "maintain aspect ratio" sub-option too. Do you think it would make sense ? Or should we create a new property altogether ? Another problem is that we currently don't expose the panel fitter for external displays so this would be limited to eDP/DSI only. I have a branch that implements borders (for underscan) for DP/HDMI which is at least moving the code a little bit into a direction where we could consider exposing the panel fitter for external displays. This would be very interesting, do you have any plans to publish this soon ? - Shashank ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut programming using DSB.
On 9/3/2019 1:29 PM, Jani Nikula wrote: On Tue, 03 Sep 2019, "Sharma, Shashank" wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Jani Nikula Sent: Friday, August 30, 2019 7:02 PM To: Manna, Animesh ; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut programming using DSB. You have tons of functions here that will never have a DSB engine, it makes no sense to convert all of them to use the DSB. Jani, I was thinking even among the 3 engines available per pipe, would it make more sense to keep them reserve on the basis of user ? like DSB0 for all pipe operations, DSB1 for all plane, and DSB2 for all encoder related stuff. We can create a DSB user (like we have for scaler) and index these engines based on that. Do you think so ? And perhaps use some DSB engines to write immediately, some to write at vblank. However, all of this should be postponed to follow-up work. For now, if we use intel_dsb_write and friends with the dsb parameter as local variable passed in, converting to use a different engine is a metter of changing the preceding intel_dsb_get call to fetch the dsb pointer. Considering the progress of a patch series, the focus should be on getting patches merged. Getting the minimum sebsible enabling of DSB merged should be the focus here. The further iteration should happen in-tree, not out-of-tree. Sure, it makes sense to simplify this in steps. - Shashank BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut programming using DSB.
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani
> Nikula
> Sent: Friday, August 30, 2019 7:02 PM
> To: Manna, Animesh ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut
> programming using DSB.
>
> On Fri, 30 Aug 2019, Animesh Manna wrote:
> > Gamma lut programming can be programmed using DSB where bulk register
> > programming can be done using indexed register write which takes
> > number of data and the mmio offset to be written.
> >
> > v1: Initial version.
> > v2: Directly call dsb-api at callsites. (Jani)
> >
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Signed-off-by: Animesh Manna
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 64 ++
> > drivers/gpu/drm/i915/i915_drv.h| 2 +
> > 2 files changed, 43 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 71a0201437a9..e4090d8e4547 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -589,34 +589,38 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
> > const struct drm_color_lut *lut = blob->data;
> > int i, lut_size = drm_color_lut_size(blob);
> > enum pipe pipe = crtc->pipe;
> > + struct intel_dsb *dsb = dev_priv->dsb;
>
> No. Don't put dsb in dev_priv. You have 12 DSB engines, 3 per pipe. You have
> intel_crtc for that.
>
> Was this not clear from my previous review?
>
> You have tons of functions here that will never have a DSB engine, it makes
> no sense
> to convert all of them to use the DSB.
>
Jani,
I was thinking even among the 3 engines available per pipe, would it make more
sense to keep them reserve on the basis of user ? like DSB0 for all pipe
operations, DSB1 for all plane, and DSB2 for all encoder related stuff. We can
create a DSB user (like we have for scaler) and index these engines based on
that. Do you think so ?
> >
> > - I915_WRITE(PREC_PAL_INDEX(pipe), prec_index |
> > - PAL_PREC_AUTO_INCREMENT);
> > + intel_dsb_reg_write(dsb, PREC_PAL_INDEX(pipe),
> > + prec_index | PAL_PREC_AUTO_INCREMENT);
> >
> > for (i = 0; i < hw_lut_size; i++) {
> > /* We discard half the user entries in split gamma mode */
> > const struct drm_color_lut *entry =
> > [i * (lut_size - 1) / (hw_lut_size - 1)];
> >
> > - I915_WRITE(PREC_PAL_DATA(pipe), ilk_lut_10(entry));
> > + intel_dsb_indexed_reg_write(dsb, PREC_PAL_DATA(pipe),
> > + ilk_lut_10(entry));
> > }
> >
> > /*
> > * Reset the index, otherwise it prevents the legacy palette to be
> > * written properly.
> > */
> > - I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> > + intel_dsb_reg_write(dsb, PREC_PAL_INDEX(pipe), 0);
> > }
> >
> > static void ivb_load_lut_ext_max(struct intel_crtc *crtc) {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + struct intel_dsb *dsb = dev_priv->dsb;
> > enum pipe pipe = crtc->pipe;
> >
> > /* Program the max register to clamp values > 1.0. */
> > - I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
> > - I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
> > - I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
> > + intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
> > + intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
> > + intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
> > +
> >
> > /*
> > * Program the gc max 2 register to clamp values > 1.0.
> > @@ -624,9 +628,12 @@ static void ivb_load_lut_ext_max(struct intel_crtc
> > *crtc)
> > * from 3.0 to 7.0
> > */
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> > - I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 0), 1 << 16);
> > - I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 1), 1 << 16);
> > - I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 2), 1 << 16);
> > + intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 0),
> > + 1 << 16);
> > + intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 1),
> > + 1 << 16);
> > + intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 2),
> > + 1 << 16);
> > }
> > }
> >
> > @@ -788,12 +795,13 @@ icl_load_gcmax(const struct intel_crtc_state
> > *crtc_state, {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + struct intel_dsb *dsb = dev_priv->dsb;
> > enum pipe pipe = crtc->pipe;
> >
> > /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> > - I915_WRITE(PREC_PAL_GC_MAX(pipe,
Re: [Intel-gfx] [PATCH v4 02/10] drm/i915/dsb: DSB context creation.
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani
> Nikula
> Sent: Friday, August 30, 2019 7:06 PM
> To: Manna, Animesh ; intel-gfx@lists.freedesktop.org
> Cc: Thierry, Michel
> Subject: Re: [Intel-gfx] [PATCH v4 02/10] drm/i915/dsb: DSB context creation.
>
> On Fri, 30 Aug 2019, Animesh Manna wrote:
> > This patch adds a function, which will internally get the gem buffer
> > for DSB engine. The GEM buffer is from global GTT, and is mapped into
> > CPU domain, contains the data + opcode to be feed to DSB engine.
> >
> > v1: Initial version.
> >
> > v2:
> > - removed some unwanted code. (Chris)
> > - Used i915_gem_object_create_internal instead of _shmem. (Chris)
> > - cmd_buf_tail removed and can be derived through vma object. (Chris)
> >
> > v3: vma realeased if i915_gem_object_pin_map() failed. (Shashank)
> >
> > Cc: Imre Deak
> > Cc: Michel Thierry
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Signed-off-by: Animesh Manna
> > ---
> > drivers/gpu/drm/i915/Makefile | 1 +
> > .../drm/i915/display/intel_display_types.h| 3 +
> > drivers/gpu/drm/i915/display/intel_dsb.c | 83 +++
> > drivers/gpu/drm/i915/display/intel_dsb.h | 31 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 5 files changed, 119 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
> > create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile index 658b930d34a8..6313e7b4bd78
> > 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -172,6 +172,7 @@ i915-y += \
> > display/intel_display_power.o \
> > display/intel_dpio_phy.o \
> > display/intel_dpll_mgr.o \
> > + display/intel_dsb.o \
> > display/intel_fbc.o \
> > display/intel_fifo_underrun.o \
> > display/intel_frontbuffer.o \
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 61277a87dbe7..da36867189cb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1033,6 +1033,9 @@ struct intel_crtc {
> >
> > /* scalers available on this crtc */
> > int num_scalers;
> > +
> > + /* per pipe DSB related info */
> > + struct intel_dsb dsb[MAX_DSB_PER_PIPE];
> > };
> >
> > struct intel_plane {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > new file mode 100644
> > index ..007ef13481d5
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -0,0 +1,83 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2019 Intel Corporation
> > + *
> > + */
> > +
> > +#include "i915_drv.h"
> > +#include "intel_display_types.h"
> > +
> > +#define DSB_BUF_SIZE(2 * PAGE_SIZE)
> > +
> > +struct intel_dsb *
> > +intel_dsb_get(struct intel_crtc *crtc) {
> > + struct drm_device *dev = crtc->base.dev;
> > + struct drm_i915_private *i915 = to_i915(dev);
> > + struct drm_i915_gem_object *obj;
> > + struct i915_vma *vma;
> > + struct intel_dsb *dsb;
> > + intel_wakeref_t wakeref;
> > + int i;
> > +
> > + for (i = 0; i < MAX_DSB_PER_PIPE; i++)
> > + if (!crtc->dsb[i].cmd_buf)
> > + break;
> > +
> > + if (WARN_ON(i == MAX_DSB_PER_PIPE))
> > + return NULL;
> > +
> > + dsb = >dsb[i];
> > + dsb->id = i;
> > + dsb->crtc = crtc;
> > + if (!HAS_DSB(i915))
> > + return dsb;
>
> Why do you go through any of the trouble if there is no DSB? Just early
> return NULL,
> and make the write functions handle NULL dsb pointer.
>
I agree on this. Even I thought it would be better if we populate the DSB ptr
only when we find a valid DSB support on the platform. And the caller of get()
can understand this and act accordingly.
> > +
> > + wakeref = intel_runtime_pm_get(>runtime_pm);
> > +
> > + obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
> > + if (IS_ERR(obj))
> > + goto err;
> > +
> > + mutex_lock(>drm.struct_mutex);
> > + vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
> > + mutex_unlock(>drm.struct_mutex);
> > + if (IS_ERR(vma)) {
> > + DRM_ERROR("Vma creation failed.\n");
> > + i915_gem_object_put(obj);
> > + goto err;
> > + }
> > +
> > + dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
> > + if (IS_ERR(dsb->cmd_buf)) {
> > + DRM_ERROR("Command buffer creation failed.\n");
> > + i915_vma_unpin_and_release(, 0);
> > + dsb->cmd_buf = NULL;
> > + goto err;
> > + }
> > + dsb->vma = vma;
> > +
> > +err:
> > + intel_runtime_pm_put(>runtime_pm, wakeref);
> > + return dsb;
> > +}
> > +
> > +void
Re: [Intel-gfx] [PATCH v3 10/11] drm/i915/dsb: Enable gamma lut programming using DSB.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Gamma lut programming can be programmed using DSB
where bulk register programming can be done using indexed
register write which takes number of data and the mmio offset
to be written.
v1: Initial version.
v2: Directly call dsb-api at callsites. (Jani)
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_color.c | 64 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
2 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 71a0201437a9..e4090d8e4547 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -589,34 +589,38 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
const struct drm_color_lut *lut = blob->data;
int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
+ struct intel_dsb *dsb = dev_priv->dsb;
- I915_WRITE(PREC_PAL_INDEX(pipe), prec_index |
- PAL_PREC_AUTO_INCREMENT);
I dont see any gen check in any of the functions before calling dsb()
functions.
+ intel_dsb_reg_write(dsb, PREC_PAL_INDEX(pipe),
+ prec_index | PAL_PREC_AUTO_INCREMENT);
for (i = 0; i < hw_lut_size; i++) {
/* We discard half the user entries in split gamma mode */
const struct drm_color_lut *entry =
[i * (lut_size - 1) / (hw_lut_size - 1)];
- I915_WRITE(PREC_PAL_DATA(pipe), ilk_lut_10(entry));
+ intel_dsb_indexed_reg_write(dsb, PREC_PAL_DATA(pipe),
+ ilk_lut_10(entry));
}
/*
* Reset the index, otherwise it prevents the legacy palette to be
* written properly.
*/
- I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+ intel_dsb_reg_write(dsb, PREC_PAL_INDEX(pipe), 0);
}
static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_dsb *dsb = dev_priv->dsb;
enum pipe pipe = crtc->pipe;
/* Program the max register to clamp values > 1.0. */
- I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
- I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
- I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
+
/*
* Program the gc max 2 register to clamp values > 1.0.
@@ -624,9 +628,12 @@ static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
* from 3.0 to 7.0
*/
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
- I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 0), 1 << 16);
- I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 1), 1 << 16);
- I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 2), 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 0),
+ 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 1),
+ 1 << 16);
+ intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 2),
+ 1 << 16);
}
}
@@ -788,12 +795,13 @@ icl_load_gcmax(const struct intel_crtc_state *crtc_state,
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_dsb *dsb = dev_priv->dsb;
enum pipe pipe = crtc->pipe;
/* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
- I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), color->red);
- I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), color->green);
- I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), color->blue);
+ intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 0), color->red);
+ intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 1), color->green);
+ intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 2), color->blue);
}
static void
@@ -803,6 +811,7 @@ icl_program_gamma_superfine_segment(const struct
intel_crtc_state *crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
const struct drm_color_lut *lut = blob->data;
+ struct intel_dsb *dsb = dev_priv->dsb;
enum pipe pipe = crtc->pipe;
u32 i;
@@ -813,15 +822,16 @@ icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
* Superfine segment has 9 entries, corresponding to values
* 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 * 256).
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/dsb: Documentation for DSB.
So here is the documentation, this resolves atleast one review comment
from me :)
- Shashank
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Acked-by: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
Documentation/gpu/i915.rst | 9
drivers/gpu/drm/i915/display/intel_dsb.c | 68
2 files changed, 77 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 3415255ad3dc..38e31223a24c 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -246,6 +246,15 @@ Display PLLs
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h
:internal:
+Display State Buffer
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
+ :doc: DSB
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
+ :internal:
+
Memory Management and Command Submission
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
index bc1734072f34..501ff7f5db8c 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,23 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/**
+ * DOC: DSB
+ *
+ * A DSB (Display State Buffer) is a queue of MMIO instructions in the memory
+ * which can be offloaded to DSB HW in Display Controller. DSB HW is a DMA
+ * engine that can be programmed to download the DSB from memory.
+ * It allows driver to batch submit display HW programming. This helps to
+ * reduce loading time and CPU activity, thereby making the context switch
+ * faster. DSB Support added from Gen12 Intel graphics based platform.
+ *
+ * DSB's can access only the pipe, plane, and transcoder Data Island Packet
+ * registers.
+ *
+ * DSB HW can support only register writes (both indexed and direct MMIO
+ * writes). There are no registers reads possible with DSB HW engine.
+ */
+
/* DSB opcodes. */
#define DSB_OPCODE_SHIFT 24
#define DSB_OPCODE_NOOP 0x0
@@ -73,6 +90,17 @@ static bool intel_dsb_disable_engine(struct intel_dsb *dsb)
return true;
}
+/**
+ * intel_dsb_get() - Allocate dsb context and return a dsb instance.
+ * @crtc: intel_crtc structure to get pipe info.
+ *
+ * This function will give handle of the DSB instance which
+ * user want to operate on.
+ *
+ * Return : address of Intel_dsb instance requested for.
+ * In failure case, the dsb instance will not have any command buffer.
+ */
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -124,6 +152,14 @@ intel_dsb_get(struct intel_crtc *crtc)
return dsb;
}
+/**
+ * intel_dsb_put() - To destroy DSB context.
+ * @dsb: intel_dsb structure.
+ *
+ * This function is used to destroy the dsb-context by doing unpin
+ * and release the vma object.
+ */
+
void intel_dsb_put(struct intel_dsb *dsb)
{
struct intel_crtc *crtc;
@@ -146,6 +182,19 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+/**
+ * intel_dsb_indexed_reg_write() -Write to the dsb context for auto
+ * increment register.
+ * @dsb: intel_dsb structure.
+ * @reg: register address.
+ * @val: value.
+ *
+ * This function is used for auto-increment register and intel_dsb_reg_write()
+ * is used for normal register. During command buffer overflow, a warning
+ * is thrown and rest all erroneous condition register programming is done
+ * through mmio write.
+ */
+
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val)
{
@@ -193,6 +242,18 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
i915_reg_t reg,
buf[dsb->free_pos] = 0;
}
+/**
+ * intel_dsb_reg_write() -Write to the dsb context for normal
+ * register.
+ * @dsb: intel_dsb structure.
+ * @reg: register address.
+ * @val: value.
+ *
+ * This function is used for writing register-value pair in command
+ * buffer of DSB. During command buffer overflow, a warning
+ * is thrown and rest all erroneous condition register programming is done
+ * through mmio write.
+ */
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = dsb->crtc;
@@ -215,6 +276,13 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
i915_mmio_reg_offset(reg);
}
+/**
+ * intel_dsb_commit() - Trigger workload execution of DSB.
+ * @dsb: intel_dsb structure.
+ *
+ * This function is used to do actual write to hardware using DSB.
+ * On errors, fall back to MMIO. Also this function help to reset the context.
+ */
void intel_dsb_commit(struct intel_dsb *dsb)
{
struct intel_crtc *crtc = dsb->crtc;
Re: [Intel-gfx] [PATCH v3 08/11] drm/i915/dsb: function to trigger workload execution of DSB.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2d6e78868f2d..bc1734072f34 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -214,3 +214,45 @@ void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t
reg, u32 val)
DSB_OPCODE_SHIFT) | DSB_BYTE_EN |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = dsb->crtc;
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
+ return;
How would the user know if DSB commit failed, and it has to retry ?
should we add a return value ?
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_DEBUG_KMS("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_DEBUG_KMS("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
a space here will look good, and aligned to above.
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+ i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
This time limit of 1 is bspec recommended, or its by experience ?
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
reset is just doing dsb->free_pos = 0; is that enough ? I think we need
to do a complete reset of the buffer memset(dsb->buffer, 0) or something
similar, else batch buffer will contain garbage values from previous
weites.
+ intel_dsb_disable_engine(dsb);
We still want to return a -ve value to indicate the write failed.
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index c848747f52d9..f5d1f1bedc12 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -44,5 +44,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 07/11] drm/i915/dsb: functions to enable/disable DSB engine.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index d36ee8244427..2d6e78868f2d 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -33,6 +33,46 @@ static inline bool is_dsb_busy(struct intel_dsb *dsb)
return DSB_STATUS & I915_READ(DSB_CTRL(pipe, dsb->id));
}
+static bool intel_dsb_enable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = dsb->crtc;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl |= DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
readback DSB status and confirm if that's really enabled ?
+
+ return true;
+}
+
+static bool intel_dsb_disable_engine(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = dsb->crtc;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 dsb_ctrl;
+
+ dsb_ctrl = I915_READ(DSB_CTRL(pipe, dsb->id));
+
+ if (DSB_STATUS & dsb_ctrl) {
+ DRM_DEBUG_KMS("DSB engine is busy.\n");
+ return false;
+ }
+
+ dsb_ctrl &= ~DSB_ENABLE;
+ I915_WRITE(DSB_CTRL(pipe, dsb->id), dsb_ctrl);
+
Same as above.
- Shashank
+ return true;
+}
+
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/dsb: Register definition of DSB registers.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
Added key register definitions of DSB.
dsb-ctrl register is required to enable dsb-engine.
head-ptr register hold the head of buffer address from where the
execution will start.
Programming tail-ptr register is a trigger point to start execution.
Cc: Uma Shankar
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_reg.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02e1ef10c47e..71c6c2380443 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11564,4 +11564,19 @@ enum skl_power_gate {
#define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia), 0x00894)
#define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)(1 << (tc_port))
+/* This register controls the Display State Buffer (DSB) engines. */
+#define _DSBSL_INSTANCE_BASE 0x70B00
+#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \
+(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
+#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
+#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
+#define DSB_ENABLE (1 << 31)
+#define DSB_BUFFER_REITERATE (1 << 29)
+#define DSB_WAIT_FOR_VBLANK (1 << 28)
+#define DSB_WAIT_FOR_LINE_IN_RANGE (1 << 27)
+#define DSB_HALT (1 << 16)
+#define DSB_NON_POSTED_ENABLE(1 << 8)
+#define DSB_STATUS (1 << 0)
+
Again, this patch is just adding the header definitions, please merge
this patch in the patch where these definitions are being used.
- Shashank
#endif /* _I915_REG_H_ */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/11] drm/i915/dsb: Indexed register write function for DSB.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. Will be using for bulk register programming
Reshuffle-> This feature can be used for bulk register programming e.g.
e.g. gamma lut programming, HDR meta data programming.
v1: Initial version.
v2: simplified code by using ALIGN(). (Chris)
Cc: Shashank Sharma
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 48
drivers/gpu/drm/i915/display/intel_dsb.h | 8
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index df288446caeb..520f2bbcc8ae 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -22,6 +22,7 @@
#define DSB_OPCODE_INDEXED_WRITE 0x9
#define DSB_OPCODE_POLL 0xA
#define DSB_BYTE_EN (0xf << 20)
+#define DSB_REG_VALUE_MASK 0xf
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
@@ -96,6 +97,53 @@ void intel_dsb_put(struct intel_dsb *dsb)
}
}
+void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
+u32 val)
We might need one space here, to get this aligned to start of the line
above (or is this due to my mail client ?).
+{
+ struct intel_crtc *crtc = dsb->crtc;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+ u32 reg_val;
+
- Do we need a HAS_DSB check at start or the caller will take care of it ?
+ if (!buf) {
+ I915_WRITE(reg, val);
I am under the assumption that indexed reg write is to write multiple
registers, and 'reg' is the base value of the register set. I dont think
it makes sense to write a single register here in case of DSB failure ?
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow.\n");
+ return;
+ }
+ reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
Why do we have this +1 here ? on the very first run (when
ins_start_offset is 0), this will fetch reg_val = buf[1]; Is this what
we want to do ?
+ if (reg_val != i915_mmio_reg_offset(reg)) {
+ /* Every instruction should be 8 byte aligned. */
+ dsb->free_pos = ALIGN(dsb->free_pos, 2);
The comment says that you want the position to be 8 bytes align, but the
factor sent to the macro is 2 ?
+
+ /* Update the size. */
+ dsb->ins_start_offset = dsb->free_pos;
This comment is irrelevant, you are not updating the size, you are
caching the base memory location.
+ buf[dsb->free_pos++] = 1;
What does this indicate ? What is 1 ?
It would be great if you can add an aski graph/table and explain what
does this DSB command buffer actually contains as per your design.
+
+ /* Update the opcode and reg. */
+ buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
+ DSB_OPCODE_SHIFT) |
+ i915_mmio_reg_offset(reg);
+
+ /* Update the value. */
+ buf[dsb->free_pos++] = val;
+ } else {
+ /* Update the new value. */
+ buf[dsb->free_pos++] = val;
+
+ /* Update the size. */
+ buf[dsb->ins_start_offset]++;
+ }
The code is looking unnecessarily complicated as ins_start_offset and
free_pos are being used for multiple reasons. I guess you can use some
local variables like:
u32 base = count = ALIGN();
{
buf [count++] = size;
buf [count++] = command;
buf [count++] = value;
}
dsb->start_offset = base;
dsb->free_pos = count;
+
+ /* if number of data words is odd, then the last dword should be 0.*/
+ if (dsb->free_pos & 0x1)
+ buf[dsb->free_pos] = 0;
+}
+
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
{
struct intel_crtc *crtc = dsb->crtc;
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 1b33ab118640..c848747f52d9 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -30,11 +30,19 @@ struct intel_dsb {
* and help in calculating cmd_buf_tail.
*/
int free_pos;
+
+ /*
+* ins_start_offset will help to store start address
+* of the dsb instuction of auto-increment register.
+*/
+ u32 ins_start_offset;
How about the variable to be named as base_offset ? Also, do we need to
keep this saved, even when the writing is done ?
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void
Re: [Intel-gfx] [PATCH v3 03/11] drm/i915/dsb: single register write function for DSB.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 36
drivers/gpu/drm/i915/display/intel_dsb.h | 9 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index a2845df90573..df288446caeb 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -9,6 +9,20 @@
#define DSB_BUF_SIZE(2 * PAGE_SIZE)
+/* DSB opcodes. */
+#define DSB_OPCODE_SHIFT 24
+#define DSB_OPCODE_NOOP0x0
+#define DSB_OPCODE_MMIO_WRITE 0x1
+#define DSB_OPCODE_WAIT_FOR_US 0x2
+#define DSB_OPCODE_WAIT_FOR_LINES 0x3
+#define DSB_OPCODE_WAIT_FOR_VBLANK 0x4
+#define DSB_OPCODE_WAIT_FOR_SL_IN 0x5
May be SL_IR (to indicate in range)
+#define DSB_OPCODE_WAIT_FOR_SL_OUT 0x6
May be SL_OOR (out of range) or _OR
+#define DSB_OPCODE_GENERATE_INT0x7
+#define DSB_OPCODE_INDEXED_WRITE 0x9
+#define DSB_OPCODE_POLL0xA
+#define DSB_BYTE_EN(0xf << 20)
But its a nitpick but as we are going by shifts for OPCODE, may be would look
consistent to create 2 different macros for enable also.
#define DSB_BYTE_EN 0xF
#define DSB_BYTE_EN_SHIFT 20
+
This patch is using only 3 of the defined commands:
DSB_OPCODE_MMIO_WRITE, DSB_OPCODE_SHIFT, DSB_BYTE_EN
All other definitions are unused. Please add them only in the patch
where they are being used.
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc)
{
@@ -81,3 +95,25 @@ void intel_dsb_put(struct intel_dsb *dsb)
mutex_unlock(>drm.struct_mutex);
}
}
+
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val)
+{
+ struct intel_crtc *crtc = dsb->crtc;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 *buf = dsb->cmd_buf;
+
Do we need a HAS_DSB() check here ? Or would it be taken care in the
caller ?
+ if (!buf) {
+ I915_WRITE(reg, val);
We can debate on if this is a good idea to fallback to I915_write() if
DSB is not available. May be we should think about why are we seeing
this condition (!buf), and that can be checked only when I see the caller.
For now, lets assume we will fallback to I915_WRITE();
+ return;
+ }
+
+ if (WARN_ON(dsb->free_pos >= DSB_BUF_SIZE)) {
+ DRM_DEBUG_KMS("DSB buffer overflow.\n");
Wouldn't it make sense to do a I915_WRITE(reg, val) here also, like above ?
+ return;
+ }
+
+ buf[dsb->free_pos++] = val;
+ buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE <<
+ DSB_OPCODE_SHIFT) | DSB_BYTE_EN |
+ i915_mmio_reg_offset(reg);
Once the write is done, are we planning to reset this free_pos ? May be
in some upcoming patch in the series ?
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 4a4091cadc1e..1b33ab118640 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_DSB_H
#define _INTEL_DSB_H
+#include "i915_reg.h"
+
struct intel_crtc;
struct i915_vma;
@@ -22,10 +24,17 @@ struct intel_dsb {
enum dsb_id id;
u32 *cmd_buf;
struct i915_vma *vma;
+
+ /*
+* free_pos will point the first free entry position
+* and help in calculating cmd_buf_tail.
+*/
+ int free_pos;
};
struct intel_dsb *
intel_dsb_get(struct intel_crtc *crtc);
void intel_dsb_put(struct intel_dsb *dsb);
+void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32 val);
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/11] drm/i915/dsb: DSB context creation.
On 8/28/2019 12:40 AM, Animesh Manna wrote:
The function will internally get the gem buffer from global GTT
This patch adds a function, which will internally get the gem buffer for
DSB engine.
which is mapped in cpu domain to feed the data + opcode for DSB engine.
This GEM buffer is from global GTT, and is mapped into CPU domain,
contains the data + opcode to be fed to DSB engine.
v1: initial version.
v2:
- removed some unwanted code. (Chris)
- Used i915_gem_object_create_internal instead of _shmem. (Chris)
- cmd_buf_tail removed and can be derived through vma object. (Chris)
Cc: Imre Deak
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/display/intel_dsb.c | 83 +++
drivers/gpu/drm/i915/display/intel_dsb.h | 31 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
5 files changed, 119 insertions(+)
create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 658b930d34a8..6313e7b4bd78 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -172,6 +172,7 @@ i915-y += \
display/intel_display_power.o \
display/intel_dpio_phy.o \
display/intel_dpll_mgr.o \
+ display/intel_dsb.o \
display/intel_fbc.o \
display/intel_fifo_underrun.o \
display/intel_frontbuffer.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 96514dcc7812..0ab3516b0044 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1026,6 +1026,9 @@ struct intel_crtc {
/* scalers available on this crtc */
int num_scalers;
+
+ /* per pipe DSB related info */
+ struct intel_dsb dsb[MAX_DSB_PER_PIPE];
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
new file mode 100644
index ..a2845df90573
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ */
+
Any particular reason we don't have the traditional license here, like
other files ?
+#include "../i915_drv.h"
This is not the way you should include this header. Take example from
other files in display folder.
+#include "intel_display_types.h"
+
+#define DSB_BUF_SIZE(2 * PAGE_SIZE)
Any particular reason for this size ?
+
+struct intel_dsb *
+intel_dsb_get(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ struct intel_dsb *dsb;
+ intel_wakeref_t wakeref;
+ int i;
+
+ for (i = 0; i < MAX_DSB_PER_PIPE; i++)
+ if (!crtc->dsb[i].cmd_buf)
+ break;
+
+ WARN_ON(i >= MAX_DSB_PER_PIPE);
Its not possible to have i > MAX_DSB_PER_PIPE as per above logic, so it
should be WARN_ON(i == MAX_DSB_PER_PIPE);
Also, shouldn't we stop operation here (along with the warning) as
clearly the cmd_buf and dsb we are going to get, is garbage ? On
negative testing this may cause kernel panic also.
+
+ dsb = >dsb[i];
+ dsb->id = i;
+ dsb->crtc = crtc;
+ if (!HAS_DSB(i915))
+ return dsb;
This check should be the first line in this function. I am not sure why
do we want to extract dsb ptr if the platform doesn't even support DSB.
+
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
+ if (IS_ERR(obj))
+ goto err;
+
+ mutex_lock(>drm.struct_mutex);
+ vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(vma)) {
+ DRM_DEBUG_KMS("Vma creation failed.\n");
+ i915_gem_object_put(obj);
Shouldn't gem_object_put() be inside mutex ?
+ goto err;
+ }
+
+ dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
+ if (IS_ERR(dsb->cmd_buf)) {
+ DRM_DEBUG_KMS("Command buffer creation failed.\n");
+ dsb->cmd_buf = NULL;
Why don't we have a i915_gem_object_put(obj) here ?
+ goto err;
+ }
+ dsb->vma = vma;
+
+err:
I think we should have a i915_gem_object_put(obj) for all error cases here.
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+ return dsb;
Again, we are returning a dsb ptr in all cases. As this patch doesn't
have the caller function, I can't understand why are we
Re: [Intel-gfx] [PATCH v3 01/11] drm/i915/dsb: feature flag added for display state buffer.
Hello Animesh
On 8/28/2019 12:40 AM, Animesh Manna wrote:
From gen12 onwards Display State Buffer(DSB) is hardware capability
added which allows driver to batch submit display HW programming.
Let's rephrase this line a bit, how about:
DSB is a new hardware capability, introduced in GEN12 display.
It allows a driver to batch-program display HW registers.
Feature flag has_dsb added to identify the driver/platform support
at runtime.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b42651a387d9..d32cfdb78b74 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1856,6 +1856,8 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
(BUILD_BUG_ON_ZERO(!__builtin_constant_p(n)) + \
INTEL_INFO(dev_priv)->gen == (n))
+#define HAS_DSB(dev_priv) (INTEL_INFO(dev_priv)->display.has_dsb)
+
/*
* Return true if revision is in range [since,until] inclusive.
*
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 92e0c2e0954c..e206f298f48e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -135,6 +135,7 @@ enum intel_ppgtt_type {
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
+ func(has_dsb); \
func(has_fbc); \
func(has_gmch); \
func(has_hotplug); \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 3/6] drm: Extend I915 mei interface for transcoder info
Looks good to me,
From display side, Please feel free to use Reviewed-by: Shashank Sharma
Regards
Shashank
> -Original Message-
> From: Winkler, Tomas
> Sent: Wednesday, August 28, 2019 1:49 PM
> To: C, Ramalingam
> Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sharma, Shashank ;
> Daniel Vetter ; Nikula, Jani
> Subject: RE: [PATCH v11 3/6] drm: Extend I915 mei interface for transcoder
> info
>
>
>
> >
> > On 2019-08-28 at 13:28:06 +0530, Winkler, Tomas wrote:
> > > > I915 needs to send the index of the transcoder as per ME FW.
> > > >
> > > > To support this, define enum mei_fw_tc and add as a member into
> > > > the struct hdcp_port_data.
> > > >
> > > > v2:
> > > > Typo in commit msg is fixed [Shashank]
> > > > v3:
> > > > kdoc is added for mei_fw_tc [Tomas]
> > > > s/MEI_TC_x/MEI_TRANSCODER_x
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > Acked-by: Jani Nikula
> > >
> > > LGTM, just need to updated the copyright year.
> > Tomas,
> >
> > Copyright year for this i915_mei_hdcp_interface.h is updated in the
> > 1st patch itself.
>
> Okay.
> >
> > -Ram
> > >
> > > > ---
> > > > include/drm/i915_mei_hdcp_interface.h | 24
> >
> > > > 1 file changed, 24 insertions(+)
> > > >
> > > > diff --git a/include/drm/i915_mei_hdcp_interface.h
> > > > b/include/drm/i915_mei_hdcp_interface.h
> > > > index 08670aa650d4..4d48de8890ca 100644
> > > > --- a/include/drm/i915_mei_hdcp_interface.h
> > > > +++ b/include/drm/i915_mei_hdcp_interface.h
> > > > @@ -54,9 +54,32 @@ enum mei_fw_ddi {
> > > > MEI_DDI_RANGE_END = MEI_DDI_A,
> > > > };
> > > >
> > > > +/**
> > > > + * enum mei_fw_tc - ME Firmware defined index for transcoders
> > > > + * @MEI_INVALID_TRANSCODER: Index for Invalid transcoder
> > > > + * @MEI_TRANSCODER_EDP: Index for EDP Transcoder
> > > > + * @MEI_TRANSCODER_DSI0: Index for DSI0 Transcoder
> > > > + * @MEI_TRANSCODER_DSI1: Index for DSI1 Transcoder
> > > > + * @MEI_TRANSCODER_A: Index for Transcoder A
> > > > + * @MEI_TRANSCODER_B: Index for Transcoder B
> > > > + * @MEI_TRANSCODER_C: Index for Transcoder C
> > > > + * @MEI_TRANSCODER_D: Index for Transcoder D */ enum mei_fw_tc {
> > > > + MEI_INVALID_TRANSCODER = 0x00,
> > > > + MEI_TRANSCODER_EDP,
> > > > + MEI_TRANSCODER_DSI0,
> > > > + MEI_TRANSCODER_DSI1,
> > > > + MEI_TRANSCODER_A = 0x10,
> > > > + MEI_TRANSCODER_B,
> > > > + MEI_TRANSCODER_C,
> > > > + MEI_TRANSCODER_D
> > > > +};
> > > > +
> > > > /**
> > > > * struct hdcp_port_data - intel specific HDCP port data
> > > > * @fw_ddi: ddi index as per ME FW
> > > > + * @fw_tc: transcoder index as per ME FW
> > > > * @port_type: HDCP port type as per ME FW classification
> > > > * @protocol: HDCP adaptation as per ME FW
> > > > * @k: No of streams transmitted on a port. Only on DP MST this
> > > > is != 1 @@ -
> > > > 69,6 +92,7 @@ enum mei_fw_ddi {
> > > > */
> > > > struct hdcp_port_data {
> > > > enum mei_fw_ddi fw_ddi;
> > > > + enum mei_fw_tc fw_tc;
> > > > u8 port_type;
> > > > u8 protocol;
> > > > u16 k;
> > > > --
> > > > 2.20.1
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
Looks good to me,
From display side, Please feel free to use Reviewed-by: Shashank Sharma
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, August 28, 2019 2:28 PM
> To: Winkler, Tomas
> Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sharma, Shashank ;
> Daniel Vetter ; Nikula, Jani
> Subject: Re: [PATCH v11 5/6] drm/i915/hdcp: update current transcoder into
> intel_hdcp
>
> On 2019-08-28 at 14:09:01 +0530, Winkler, Tomas wrote:
> > >
> > > On 2019-08-28 at 13:56:06 +0530, Winkler, Tomas wrote:
> > > >
> > > > > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > > > > Hence on every modeset update associated transcoder into the
> > > > > intel_hdcp of the port.
> > > > >
> > > > > v2:
> > > > > s/trans/cpu_transcoder [Jani]
> > > > > v3:
> > > > > comment is added for fw_ddi init for gen12+ [Shashank]
> > > > > only hdcp capable transcoder is translated into fw_tc
> > > > > [Shashank]
> > > > > v4:
> > > > > fw_tc initialization is kept for modeset. [Tomas]
> > > > > few extra doc is added at port_data init [Tomas]
> > > > >
> > > > > Signed-off-by: Ramalingam C
> > > > > Acked-by: Jani Nikula
> > > > > ---
> > > > > .../drm/i915/display/intel_display_types.h| 7 +++
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 48
> > > > > ++-
> > > > > drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> > > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> > > > > 5 files changed, 63 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index 96514dcc7812..61277a87dbe7 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -388,6 +388,13 @@ struct intel_hdcp {
> > > > > wait_queue_head_t cp_irq_queue;
> > > > > atomic_t cp_irq_count;
> > > > > int cp_irq_count_cached;
> > > > > +
> > > > > + /*
> > > > > + * HDCP register access for gen12+ need the transcoder
> > > > > associated.
> > > > > + * Transcoder attached to the connector could be changed at
> > > > > modeset.
> > > > > + * Hence caching the transcoder here.
> > > > > + */
> > > > > + enum transcoder cpu_transcoder;
> > > > > };
> > > > >
> > > > > struct intel_connector {
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 23908da1cd5d..e8471689f785 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -2248,6 +2248,9 @@ intel_dp_compute_config(struct
> > > > > intel_encoder *encoder,
> > > > >
> > > > > intel_psr_compute_config(intel_dp, pipe_config);
> > > > >
> > > > > + intel_hdcp_transcoder_config(intel_connector,
> > > > > + pipe_config->cpu_transcoder);
> > > > > +
> > > > > return 0;
> > > > > }
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > index e8b04cc8fcb1..988d675f9f69 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > @@ -1764,13 +1764,59 @@ enum mei_fw_ddi
> > > > > intel_get_mei_fw_ddi_index(enum port port)
> > > > > }
> > > > > }
> > > > >
> > > > > +static inline
> > > > > +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder) {
> > > > > + switch (cpu_transcoder) {
> > > > > + cas
Re: [Intel-gfx] [PATCH v9 6/6] drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data.
v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check is moved into the caller [Lucas]
v3:
platform check is moved into a macro [Shashank]
v4:
Few optimizations in the coding [Shashank]
v5:
Fixed alignment in macro definition in i915_reg.h [Shashank]
unused variables "reg" is removed.
v6:
Configuring the transcoder at compute_config.
transcoder is used instead of pipe in macros.
Rebased.
v7:
transcoder is cached at intel_hdcp
hdcp_port_data is configured with transcoder index asper ME FW.
v8:
s/trans/cpu_transcoder
s/tc/cpu_transcoder
Signed-off-by: Ramalingam C
Reviewed-by: Shashank Sharma [v5]
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 148 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
drivers/gpu/drm/i915/i915_reg.h | 124 --
3 files changed, 219 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1e5548833e8f..e2084403db27 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -18,6 +18,7 @@
#include "intel_display_types.h"
#include "intel_hdcp.h"
#include "intel_sideband.h"
+#include "intel_connector.h"
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
@@ -105,24 +106,20 @@ bool intel_hdcp2_capable(struct intel_connector
*connector)
return capable;
}
-static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+static inline
+bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
- u32 reg;
-
- reg = I915_READ(PORT_HDCP_STATUS(port));
- return reg & HDCP_STATUS_ENC;
+ return I915_READ(HDCP_STATUS(dev_priv, cpu_transcoder, port)) &
+ HDCP_STATUS_ENC;
}
-static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+static inline
+bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
- u32 reg;
-
- reg = I915_READ(HDCP2_STATUS_DDI(port));
- return reg & LINK_ENCRYPTION_STATUS;
+ return I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
+ LINK_ENCRYPTION_STATUS;
}
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -253,9 +250,28 @@ static int intel_write_sha_text(struct drm_i915_private
*dev_priv, u32 sha_text)
}
static
-u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
+u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder, enum port port)
{
- enum port port = intel_dig_port->base.port;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ switch (cpu_transcoder) {
+ case TRANSCODER_A:
+ return HDCP_TRANSA_REP_PRESENT |
+ HDCP_TRANSA_SHA1_M0;
+ case TRANSCODER_B:
+ return HDCP_TRANSB_REP_PRESENT |
+ HDCP_TRANSB_SHA1_M0;
+ case TRANSCODER_C:
+ return HDCP_TRANSC_REP_PRESENT |
+ HDCP_TRANSC_SHA1_M0;
+ /* FIXME: Add a case for PIPE_D */
+ default:
+ DRM_ERROR("Unknown transcoder %d\n", cpu_transcoder);
+ break;
+ }
+ return -EINVAL;
It doesn't make sense to have this return statement along sitting here,
it should be up in with the default case; in place of break.
+ }
+
switch (port) {
case PORT_A:
return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
@@ -268,18 +284,21 @@ u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port
*intel_dig_port)
case PORT_E:
return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
default:
+ DRM_ERROR("Unknown port %d\n", port);
break;
}
- DRM_ERROR("Unknown port %d\n", port);
return -EINVAL;
}
static
-int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+int intel_hdcp_validate_v_prime(struct
Re: [Intel-gfx] [PATCH] drm/i915: Prune 2560x2880 mode for 5K tiled dual DP monitors
Hello Ankit, On 8/27/2019 11:59 AM, Nautiyal, Ankit K wrote: From: Ankit Nautiyal Currently, the transcoder port sync feature is not available, due to which the 5K-tiled dual DP monitors experience corruption when 2560x2880 mode is applied for both of the tiled DP connectors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97244 There is a patch series to enable transcode port sync feature for tiled display for ICL+, which is under review: https://patchwork.kernel.org/project/intel-gfx/list/?series=137339 For the older platforms, we need to remove the 2560x2880 mode to avoid a possibility of userspace choosing 2560x2880 mode for both tiled displays, resulting in corruption. This patch prunes 2560x2880 mode for one of the tiled DP connector. Since both the tiled DP connectors have different tile_h_loc and tile_v_loc, the tiled connector with tile_h_loc and tile_v_loc as '0', is chosen, for which the given resolution is removed. Signed-off-by: Ankit Nautiyal CC: Manasi Navare --- drivers/gpu/drm/i915/display/intel_dp.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 5c45a3b..aa43a3b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -564,6 +564,17 @@ intel_dp_mode_valid(struct drm_connector *connector, if (mode->flags & DRM_MODE_FLAG_DBLCLK) return MODE_H_ILLEGAL; + /* +* For 5K tiled dual DP monitors, dual-DP sync is not yet supported. +* This results in display sync issues, when both tiled connectors run +* on 2560x2880 resolution. Therefore prune the 2560x2880 mode on one +* of the tiled connector, to avoid such a case. +*/ + if (connector->has_tile && + (connector->tile_h_loc == 0 && connector->tile_v_loc == 0) && + (mode->hdisplay == 2560 && mode->vdisplay == 2880)) Shouldn't this be for >= 2560/2880 than == ? Also, do we want (mode->hdisplay >= 2560 *||* mode->vdisplay >= 2880 ) - Shashank + return MODE_PANEL; + return MODE_OK; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
Regards
Shashank
On 8/27/2019 10:57 AM, Ramalingam C wrote:
On 2019-08-27 at 10:49:25 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+ enum transcoder cpu_transcoder;
attached_transcoder to be inline with MEI counterpart of the code ?
This is needed so that we can use this to get the offset of register.
Need not be inline with MEI.
:) I meant in the MEI side we are using name "attached_transcoder" so
using the same in I915 also would be easy to understand. But this is not
important, I will leave it to you.
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_psr_compute_config(intel_dp, pipe_config);
+ intel_hdcp_transcoder_config(intel_connector,
+pipe_config->cpu_transcoder);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port
port)
}
}
+static inline
+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+ switch (cpu_transcoder) {
+ case TRANSCODER_A ... TRANSCODER_D:
+ return (enum mei_fw_tc)(cpu_transcoder | 0x10);
Again, as this is in context of HDCP, we should not entertain transcoders
below. Or we should move this function in a more generic file like
intel_display.c or intel_ddi.c
This is specific to hdcp. So let it be here. We will fill invalid
TRANSCODER for all non HDCO capable transcoders. Hope that works for
you.
Sure.
+ case TRANSCODER_EDP:
+ return MEI_TC_EDP;
+ case TRANSCODER_DSI_0:
+ return MEI_TC_DSI0;
+ case TRANSCODER_DSI_1:
+ return MEI_TC_DSI1;
+ default:
+ return MEI_INVALID_TRANSCODER;
+ }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+
+ if (!hdcp->shim)
+ return;
+
+ if (INTEL_GEN(dev_priv) >= 12) {
Ah, so this is the gen_check which I was talking about in previous patch :-)
+ mutex_lock(>mutex);
+ hdcp->cpu_transcoder = cpu_transcoder;
+ hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ mutex_unlock(>mutex);
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector
*connector,
const struct intel_hdcp_shim *shim)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
+ struct intel_crtc *crtc;
+
+ if (INTEL_GEN(dev_priv) < 12) {
+ data->fw_ddi =
+ intel_get_mei_fw_ddi_index(connector->encoder->port);
+ } else {
+ crtc = to_intel_crtc(connector->base.state->crtc);
+ if (crtc) {
+ hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+ data->fw_tc = intel_get_mei
Re: [Intel-gfx] [PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info
On 8/27/2019 10:47 AM, Ramalingam C wrote:
On 2019-08-27 at 10:42:33 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3638c77eba26..93027fd96c71 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
session_init_in.port.integrated_port_type = data->port_type;
session_init_in.port.physical_port = (u8)data->fw_ddi;
As this entry is only valid till GEN11.5, don't we need GEN_CHECK here, say
(INTEL_GEN() < 12). Is that possible in MEI_FW ?
Shashank,
Not needed, as I915 checks the GEN# while loading the transcoder detail
into hdcp_port_data. So here we can assign whatever passed as part of
hdcp_port_data.
-Ram
Yep, just saw this in the next patch,
Please feel free to use: Reviewed-by: Shashank Sharma
If not, probably we have to add this gen_check while filling the fw_tc part
in I915.
Applies for all the changes below too.
- Shashank
+ session_init_in.port.attached_transcoder = (u8)data->fw_tc;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
verify_rxcert_in.port.integrated_port_type = data->port_type;
verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
+ verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.port.integrated_port_type = data->port_type;
send_hprime_in.port.physical_port = (u8)data->fw_ddi;
+ send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
pairing_info_in.port.integrated_port_type = data->port_type;
pairing_info_in.port.physical_port = (u8)data->fw_ddi;
+ pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.port.integrated_port_type = data->port_type;
lc_init_in.port.physical_port = (u8)data->fw_ddi;
+ lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
verify_lprime_in.port.integrated_port_type = data->port_type;
verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
HDCP_2_2_L_PRIME_LEN);
@@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
get_skey_in.port.integrated_port_type = data->port_type;
get_skey_in.port.physical_port = (u8)data->fw_ddi;
+ get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
if (byte < 0) {
@@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
verify_repeater_in.port.integrated_port_type = data->port_type;
verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
+ verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
HDCP_2_2_RXINFO_LEN);
@@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
verify_mprime_in.port.integrated_port_type = data->port_type;
verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
HDCP_2_2_MPRIME_LEN);
@@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device
*dev,
enable
Re: [Intel-gfx] [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+ enum transcoder cpu_transcoder;
attached_transcoder to be inline with MEI counterpart of the code ?
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_psr_compute_config(intel_dp, pipe_config);
+ intel_hdcp_transcoder_config(intel_connector,
+pipe_config->cpu_transcoder);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port
port)
}
}
+static inline
+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+ switch (cpu_transcoder) {
+ case TRANSCODER_A ... TRANSCODER_D:
+ return (enum mei_fw_tc)(cpu_transcoder | 0x10);
Again, as this is in context of HDCP, we should not entertain
transcoders below. Or we should move this function in a more generic
file like intel_display.c or intel_ddi.c
+ case TRANSCODER_EDP:
+ return MEI_TC_EDP;
+ case TRANSCODER_DSI_0:
+ return MEI_TC_DSI0;
+ case TRANSCODER_DSI_1:
+ return MEI_TC_DSI1;
+ default:
+ return MEI_INVALID_TRANSCODER;
+ }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+
+ if (!hdcp->shim)
+ return;
+
+ if (INTEL_GEN(dev_priv) >= 12) {
Ah, so this is the gen_check which I was talking about in previous patch :-)
+ mutex_lock(>mutex);
+ hdcp->cpu_transcoder = cpu_transcoder;
+ hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ mutex_unlock(>mutex);
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
+ struct intel_crtc *crtc;
+
+ if (INTEL_GEN(dev_priv) < 12) {
+ data->fw_ddi =
+ intel_get_mei_fw_ddi_index(connector->encoder->port);
+ } else {
+ crtc = to_intel_crtc(connector->base.state->crtc);
+ if (crtc) {
+ hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+ data->fw_tc = intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+ }
+ data->fw_ddi = intel_get_mei_fw_ddi_index(PORT_NONE);
I dint understand this, why PORT_NONE ?
- Shashank
+ }
- data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 59a2b40405cc..41c1053d9e38 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -16,10 +16,13 @@ struct
Re: [Intel-gfx] [PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3638c77eba26..93027fd96c71 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
session_init_in.port.integrated_port_type = data->port_type;
session_init_in.port.physical_port = (u8)data->fw_ddi;
As this entry is only valid till GEN11.5, don't we need GEN_CHECK here,
say (INTEL_GEN() < 12). Is that possible in MEI_FW ?
If not, probably we have to add this gen_check while filling the fw_tc
part in I915.
Applies for all the changes below too.
- Shashank
+ session_init_in.port.attached_transcoder = (u8)data->fw_tc;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
verify_rxcert_in.port.integrated_port_type = data->port_type;
verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
+ verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.port.integrated_port_type = data->port_type;
send_hprime_in.port.physical_port = (u8)data->fw_ddi;
+ send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
pairing_info_in.port.integrated_port_type = data->port_type;
pairing_info_in.port.physical_port = (u8)data->fw_ddi;
+ pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.port.integrated_port_type = data->port_type;
lc_init_in.port.physical_port = (u8)data->fw_ddi;
+ lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
verify_lprime_in.port.integrated_port_type = data->port_type;
verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
HDCP_2_2_L_PRIME_LEN);
@@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
get_skey_in.port.integrated_port_type = data->port_type;
get_skey_in.port.physical_port = (u8)data->fw_ddi;
+ get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
if (byte < 0) {
@@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
verify_repeater_in.port.integrated_port_type = data->port_type;
verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
+ verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
HDCP_2_2_RXINFO_LEN);
@@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
verify_mprime_in.port.integrated_port_type = data->port_type;
verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
HDCP_2_2_MPRIME_LEN);
@@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device
*dev,
enable_auth_in.port.integrated_port_type = data->port_type;
enable_auth_in.port.physical_port = (u8)data->fw_ddi;
+ enable_auth_in.port.attached_transcoder = (u8)data->fw_tc;
enable_auth_in.stream_type = data->streams[0].stream_type;
byte = mei_cldev_send(cldev, (u8 *)_auth_in,
@@ -673,6 +683,7 @@ mei_hdcp_close_session(struct device *dev, struct
hdcp_port_data *data)
session_close_in.port.integrated_port_type = data->port_type;
session_close_in.port.physical_port = (u8)data->fw_ddi;
+
Re: [Intel-gfx] [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
On 8/22/2019 8:49 PM, Ramalingam C wrote:
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
};
+enum mei_fw_tc {
+ MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
+ MEI_TC_EDP, /* Transcoder for eDP */
+ MEI_TC_DSI0,/* Transcoder for DSI0 */
+ MEI_TC_DSI1,/* Transcoder for DSI1 */
Also, this is a bit odd, coz ports above can't do HDCP, so it doesn't
make sense to have them here. But seems like we want to be in sync with
MEI FW definitions, so we should change the function
intel_get_mei_fw_ddi_index to accept only from ports A to D, not above
or below.
- Shashank
+ MEI_TC_A = 0x10,/* Transcoder TCA */
+ MEI_TC_B, /* Transcoder TCB */
+ MEI_TC_C, /* Transcoder TCC */
+ MEI_TC_D/* Transcoder TCD */
+};
+
/**
* struct hdcp_port_data - intel specific HDCP port data
* @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
* @port_type: HDCP port type as per ME FW classification
* @protocol: HDCP adaptation as per ME FW
* @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
*/
struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+ enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
On 8/22/2019 8:49 PM, Ramalingam C wrote:
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
The commit message says you are defining enum mei_fw_ddi, but you are
actually defining enum mei_fw_tc;
- Shashank
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
};
+enum mei_fw_tc {
+ MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
+ MEI_TC_EDP, /* Transcoder for eDP */
+ MEI_TC_DSI0,/* Transcoder for DSI0 */
+ MEI_TC_DSI1,/* Transcoder for DSI1 */
+ MEI_TC_A = 0x10,/* Transcoder TCA */
+ MEI_TC_B, /* Transcoder TCB */
+ MEI_TC_C, /* Transcoder TCC */
+ MEI_TC_D/* Transcoder TCD */
+};
+
/**
* struct hdcp_port_data - intel specific HDCP port data
* @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
* @port_type: HDCP port type as per ME FW classification
* @protocol: HDCP adaptation as per ME FW
* @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
*/
struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+ enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
Regards
Shashank
On 8/27/2019 10:03 AM, Ramalingam C wrote:
On 2019-08-27 at 09:54:18 +0530, Sharma, Shashank wrote:
Hello Ram,
On 8/22/2019 8:48 PM, Ramalingam C wrote:
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
drivers/misc/mei/hdcp/mei_hdcp.h | 12
include/drm/i915_mei_hdcp_interface.h | 16 +--
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return MEI_DDI_A;
+ case PORT_B ... PORT_F:
+ return (enum mei_fw_ddi)port;
+ default:
+ return MEI_DDI_INVALID_PORT;
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector
*connector,
const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
- data->port = connector->encoder->port;
+ data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
#include "mei_hdcp.h"
-static inline u8 mei_get_ddi_index(enum port port)
-{
- switch (port) {
- case PORT_A:
- return MEI_DDI_A;
- case PORT_B ... PORT_F:
- return (u8)port;
- default:
- return MEI_DDI_INVALID_PORT;
- }
-}
-
/**
* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
session_init_in.port.integrated_port_type = data->port_type;
- session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
verify_rxcert_in.port.integrated_port_type = data->port_type;
- verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+ verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
- send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+ send_hprime_in.port.physical_port = (u8)data->fw_ddi;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
pairing_info_in.port.integrated_port_type = data->port_type;
- pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+ pairing_info_in.port.physical_port = (u8)data->fw_ddi;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
lc_init_in.port.integrated_port_type = data->port_type;
- lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ lc_init_in.port.physical_port = (u8)data->fw_ddi;
byte = mei_cldev_send(cldev, (u8 *)_
Re: [Intel-gfx] [PATCH v9 2/6] drm: Move port definition back to i915 header
tern struct resource intel_graphics_stolen_res;
#define INTEL_GEN11_BSM_DW1 0xc4
#define INTEL_BSM_MASK (-(1u << 20))
-enum port {
- PORT_NONE = -1,
-
- PORT_A = 0,
- PORT_B,
- PORT_C,
- PORT_D,
- PORT_E,
- PORT_F,
- PORT_G,
- PORT_H,
- PORT_I,
-
- I915_MAX_PORTS
-};
-
-#define port_name(p) ((p) + 'A')
-
#endif/* _I915_DRM_H_ */
Otherwise patch looks good to me.
With(or without) above mentioned suggestion, Feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
Hello Ram,
On 8/22/2019 8:48 PM, Ramalingam C wrote:
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
drivers/misc/mei/hdcp/mei_hdcp.h | 12
include/drm/i915_mei_hdcp_interface.h | 16 +--
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return MEI_DDI_A;
+ case PORT_B ... PORT_F:
+ return (enum mei_fw_ddi)port;
+ default:
+ return MEI_DDI_INVALID_PORT;
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
- data->port = connector->encoder->port;
+ data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
#include "mei_hdcp.h"
-static inline u8 mei_get_ddi_index(enum port port)
-{
- switch (port) {
- case PORT_A:
- return MEI_DDI_A;
- case PORT_B ... PORT_F:
- return (u8)port;
- default:
- return MEI_DDI_INVALID_PORT;
- }
-}
-
/**
* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
session_init_in.port.integrated_port_type = data->port_type;
- session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
verify_rxcert_in.port.integrated_port_type = data->port_type;
- verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+ verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
- send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+ send_hprime_in.port.physical_port = (u8)data->fw_ddi;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
pairing_info_in.port.integrated_port_type = data->port_type;
- pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+ pairing_info_in.port.physical_port = (u8)data->fw_ddi;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
lc_init_in.port.integrated_port_type = data->port_type;
- lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ lc_init_in.port.physical_port = (u8)data->fw_ddi;
byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -378,7 +366,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
Re: [Intel-gfx] [PATCH v10 6/6] drm/hdcp: reference for srm file format
Hi Ram, Just a minor nitpick. Regards Shashank > -Original Message- > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of > Ramalingam C > Sent: Friday, July 12, 2019 12:30 PM > To: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Pekka Paalanen ; Daniel > Vetter > Subject: [PATCH v10 6/6] drm/hdcp: reference for srm file format > > In the kernel documentation, HDCP specifications links are shared as a > reference for > SRM table format. > > Signed-off-by: Ramalingam C > --- > drivers/gpu/drm/drm_hdcp.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c index > 77433ee3d652..803bf8283b83 100644 > --- a/drivers/gpu/drm/drm_hdcp.c > +++ b/drivers/gpu/drm/drm_hdcp.c > @@ -271,6 +271,13 @@ static void drm_hdcp_request_srm(struct drm_device > *drm_dev) > * > * SRM should be presented in the name of "display_hdcp_srm.bin". > * > + * Format of the SRM table that userspace needs to write into the > + binary file > + * is defined at I would just prefer addition of 2 ',' and a ':', something like: Format of the SRM table, that the userspace needs to write into the binary file, is defined at: With this change, please feel free to use: Reviewed-by: Shashank Sharma > + * 1. Renewability chapter on 55th page of HDCP 1.4 specification > + * > + https://www.digital-cp.com/sites/default/files/specifications/HDCP%20S > + pecification%20Rev1_4_Secure.pdf > + * 2. Renewability chapter on 63rd page of HDCP 2.2 specification > + * > + https://www.digital-cp.com/sites/default/files/specifications/HDCP%20o > + n%20HDMI%20Specification%20Rev2_2_Final1.pdf > + * > * Returns: > * TRUE on any of the KSV is revoked, else FALSE. > */ > -- > 2.19.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/edid: Abstract away cea_edid_modes[]
Hi Ville,
On 7/11/2019 4:02 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We're going to need two cea mode tables (on for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to indicathe how it's to be
indexed.
I am not very sure if its a good idea to split into two different
tables, or adding multiple dummy placeholder modes (like VIC 0) for the
modes not available. It could give us continuity and we can keep on
using almost the same functions. We can just add some checks for range
between VIC 128 - 193. Just a thought.
- Shashank
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 80 +++---
1 file changed, 58 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcd9ed569d64..703d2bc26fd9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -707,12 +707,11 @@ static const struct minimode extra_modes[] = {
};
/*
- * Probably taken from CEA-861 spec.
- * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
+ * From CEA/CTA-861 spec.
*
- * Index using the VIC.
+ * Index with VIC.
*/
-static const struct drm_display_mode edid_cea_modes[] = {
+static const struct drm_display_mode edid_cea_modes_0[] = {
/* 0 - dummy, VICs start at 1 */
{ },
/* 1 - 640x480@60Hz 4:3 */
@@ -3067,6 +3066,25 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
return cea;
}
+static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
+{
+ if (!vic)
+ return NULL;
+ if (vic < ARRAY_SIZE(edid_cea_modes_0))
+ return _cea_modes_0[vic];
+ return NULL;
+}
+
+static u8 cea_num_vics(void)
+{
+ return ARRAY_SIZE(edid_cea_modes_0);
+}
+
+static u8 cea_next_vic(u8 vic)
+{
+ return vic + 1;
+}
+
/*
* Calculate the alternate clock for the CEA mode
* (60Hz vs. 59.94Hz etc.)
@@ -3104,14 +3122,14 @@ cea_mode_alternate_timings(u8 vic, struct
drm_display_mode *mode)
* get the other variants by simply increasing the
* vertical front porch length.
*/
- BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
-edid_cea_modes[9].vtotal != 262 ||
-edid_cea_modes[12].vtotal != 262 ||
-edid_cea_modes[13].vtotal != 262 ||
-edid_cea_modes[23].vtotal != 312 ||
-edid_cea_modes[24].vtotal != 312 ||
-edid_cea_modes[27].vtotal != 312 ||
-edid_cea_modes[28].vtotal != 312);
+ BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262 ||
+cea_mode_for_vic(9)->vtotal != 262 ||
+cea_mode_for_vic(12)->vtotal != 262 ||
+cea_mode_for_vic(13)->vtotal != 262 ||
+cea_mode_for_vic(23)->vtotal != 312 ||
+cea_mode_for_vic(24)->vtotal != 312 ||
+cea_mode_for_vic(27)->vtotal != 312 ||
+cea_mode_for_vic(28)->vtotal != 312);
if (((vic == 8 || vic == 9 ||
vic == 12 || vic == 13) && mode->vtotal < 263) ||
@@ -3139,10 +3157,16 @@ static u8 drm_match_cea_mode_clock_tolerance(const
struct drm_display_mode *to_m
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
- for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
- struct drm_display_mode cea_mode = edid_cea_modes[vic];
+ for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+ const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+ struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
+ if (!mode)
+ continue;
+
+ cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3178,10 +3202,16 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
- for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
- struct drm_display_mode cea_mode = edid_cea_modes[vic];
+ for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+ const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+ struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
+ if (!mode)
+ continue;
+
+ cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3202,7 +3232,7 @@
Re: [Intel-gfx] [PATCH v2 1/5] drm/edid: Add CTA-861-G modes with VIC < 128
40, 4016,
+ 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 121 - 5120x2160@24Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 396000, 5120, 7116,
+ 7204, 7500, 0, 2160, 2168, 2178, 2200, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 122 - 5120x2160@25Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 396000, 5120, 6816,
+ 6904, 7200, 0, 2160, 2168, 2178, 2200, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 123 - 5120x2160@30Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 396000, 5120, 5784,
+ 5872, 6000, 0, 2160, 2168, 2178, 2200, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 124 - 5120x2160@48Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 742500, 5120, 5866,
+ 5954, 6250, 0, 2160, 2168, 2178, 2475, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 125 - 5120x2160@50Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 742500, 5120, 6216,
+ 6304, 6600, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 126 - 5120x2160@60Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 742500, 5120, 5284,
+ 5372, 5500, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 127 - 5120x2160@100Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 1485000, 5120, 6216,
+ 6304, 6600, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
};
Cross checked all timings with CEA-861-G spec. Feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+
Regards
Shashank
On 7/9/2019 7:39 AM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check is moved into the caller [Lucas]
v3:
platform check is moved into a macro [Shashank]
v4:
Few optimizations in the coding [Shashank]
v5:
Fixed alignment in macro definition in i915_reg.h [Shashank]
unused variables "reg" is removed.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 133 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +-
drivers/gpu/drm/i915/i915_reg.h | 120 +--
drivers/gpu/drm/i915/intel_drv.h | 8 ++
4 files changed, 207 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index bc3a94d491c4..23dc3ad4ba4c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -17,6 +17,7 @@
#include "intel_drv.h"
#include "intel_hdcp.h"
#include "intel_sideband.h"
+#include "intel_connector.h"
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
@@ -104,24 +105,17 @@ bool intel_hdcp2_capable(struct intel_connector
*connector)
return capable;
}
-static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+static inline bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
+enum pipe pipe, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
- u32 reg;
-
- reg = I915_READ(PORT_HDCP_STATUS(port));
- return reg & HDCP_STATUS_ENC;
+ return I915_READ(HDCP_STATUS(dev_priv, pipe, port)) & HDCP_STATUS_ENC;
}
-static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+static inline bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
- u32 reg;
-
- reg = I915_READ(HDCP2_STATUS_DDI(port));
- return reg & LINK_ENCRYPTION_STATUS;
+ return I915_READ(HDCP2_STATUS(dev_priv, pipe, port)) &
+ LINK_ENCRYPTION_STATUS;
}
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -253,9 +247,28 @@ static int intel_write_sha_text(struct drm_i915_private
*dev_priv, u32 sha_text)
}
static
-u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
+u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum port port)
{
- enum port port = intel_dig_port->base.port;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ switch (pipe) {
+ case PIPE_A:
+ return HDCP_TRANSA_REP_PRESENT |
+ HDCP_TRANSA_SHA1_M0;
+ case PIPE_B:
+ return HDCP_TRANSB_REP_PRESENT |
+ HDCP_TRANSB_SHA1_M0;
+ case PIPE_C:
+ return HDCP_TRANSC_REP_PRESENT |
+ HDCP_TRANSC_SHA1_M0;
+ /* FIXME: Add a case for PIPE_D */
+ default:
+ DRM_ERROR("Unknown pipe %d\n", pipe);
+ break;
+ }
+ return -EINVAL;
+ }
+
switch (port) {
case PORT_A:
return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
@@ -268,18 +281,21 @@ u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port
*intel_dig_port)
case PORT_E:
return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
default:
+ DRM_ERROR("Unknown port %d\n", port);
break;
}
- DRM_ERROR("Unknown port %d\n", port);
return -EINVAL;
}
static
-int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+int intel_hdcp_validate_v_prime(struct intel_connector *connector,
const struct intel_hdcp_shim *shim,
u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct drm_i915_private *dev_priv;
+ enum pipe pipe = connector->hdcp.pipe;
+ enum port port = intel_dig_port->base.port;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
int ret, i, j, sha_idx;
@@ -306,7 +322,7 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
sha_idx = 0;
sha_text = 0;
sha_leftovers = 0;
-
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enable HDCP 1.4 and 2.2 on Gen12+
Hello Ram,
On 7/2/2019 11:24 AM, Ramalingam C wrote:
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
v2:
_MMIO_TRANS is used [Lucas and Daniel]
platform check is moved into the caller [Lucas]
v3:
platform check is moved into a macro [Shashank]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 155 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +-
drivers/gpu/drm/i915/i915_reg.h | 120 +++--
drivers/gpu/drm/i915/intel_drv.h | 8 ++
4 files changed, 221 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index bc3a94d491c4..14ba723a3561 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -17,6 +17,7 @@
#include "intel_drv.h"
#include "intel_hdcp.h"
#include "intel_sideband.h"
+#include "intel_connector.h"
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
@@ -104,23 +105,21 @@ bool intel_hdcp2_capable(struct intel_connector
*connector)
return capable;
}
-static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+static inline bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
+enum pipe pipe, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
u32 reg;
- reg = I915_READ(PORT_HDCP_STATUS(port));
+ reg = I915_READ(HDCP_STATUS(dev_priv, pipe, port));
return reg & HDCP_STATUS_ENC;
directly return I915_READ(HDCP_STATUS(dev_priv, pipe, port)) &
HDCP_STATUS_ENC; ?
}
-static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+static inline bool intel_hdcp2_in_use(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum port port)
{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- enum port port = connector->encoder->port;
u32 reg;
- reg = I915_READ(HDCP2_STATUS_DDI(port));
+ reg = I915_READ(HDCP2_STATUS(dev_priv, pipe, port));
return reg & LINK_ENCRYPTION_STATUS;
same here
}
@@ -253,37 +252,59 @@ static int intel_write_sha_text(struct drm_i915_private *dev_priv, u32 sha_text)
}
static
-u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port *intel_dig_port)
+u32 intel_hdcp_get_repeater_ctl(struct drm_i915_private *dev_priv,
+ enum pipe pipe, enum port port)
{
- enum port port = intel_dig_port->base.port;
- switch (port) {
- case PORT_A:
- return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
- case PORT_B:
- return HDCP_DDIB_REP_PRESENT | HDCP_DDIB_SHA1_M0;
- case PORT_C:
- return HDCP_DDIC_REP_PRESENT | HDCP_DDIC_SHA1_M0;
- case PORT_D:
- return HDCP_DDID_REP_PRESENT | HDCP_DDID_SHA1_M0;
- case PORT_E:
- return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
- default:
- break;
- }
- DRM_ERROR("Unknown port %d\n", port);
+ if (INTEL_GEN(dev_priv) >= 12) {
+ switch (pipe) {
+ case PIPE_A:
+ return HDCP_TRANSA_REP_PRESENT |
+ HDCP_TRANSA_SHA1_M0;
+ case PIPE_B:
+ return HDCP_TRANSB_REP_PRESENT |
+ HDCP_TRANSB_SHA1_M0;
+ case PIPE_C:
+ return HDCP_TRANSC_REP_PRESENT |
+ HDCP_TRANSC_SHA1_M0;
+ /* FIXME: Add a case for PIPE_D */
+ default:
+ DRM_ERROR("Unknown pipe %d\n", pipe);
+ break;
+ }
return -EINVAL here, then we don't need the else condition
may be something like:
ret = -EINVAL
if (GEN >=12) {
switch(pipe) {
case PIPEA: ret = ; break;
case PIPE_B: ret =; break;
default: DRM_ERROR(); break;
}
return ret;
}
switch (port) {
case PORT_A: ret = ;
case PORT_B: ret =;
default: DRM_ERROR();
}
return ret;
+ } else {
+ switch (port) {
+ case PORT_A:
+ return HDCP_DDIA_REP_PRESENT | HDCP_DDIA_SHA1_M0;
+ case PORT_B:
+ return HDCP_DDIB_REP_PRESENT | HDCP_DDIB_SHA1_M0;
+ case PORT_C:
+ return HDCP_DDIC_REP_PRESENT | HDCP_DDIC_SHA1_M0;
+ case PORT_D:
+ return HDCP_DDID_REP_PRESENT | HDCP_DDID_SHA1_M0;
+ case PORT_E:
+ return HDCP_DDIE_REP_PRESENT | HDCP_DDIE_SHA1_M0;
+
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/icl: Add Multi-segmented gamma support
We (Me and Uma) confirmed the ICL register programming sequence, by
dumping the registers.
The correct sequence should be:
ilk_lut_12p4_udw
ilk_lut_12p4_ldw
We passed maximum value LUT (1.0) and saw only blue output, if
programmed in opposite sequence.
Programming in above mentioned sequence gives a proper white output.
Regards
Shashank
On 5/8/2019 6:35 PM, Sharma, Shashank wrote:
On 5/7/2019 7:57 PM, Ville Syrjälä wrote:
On Tue, May 07, 2019 at 07:26:44PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to
1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 *
256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma
mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
V3: Addressed review comments from Ville
- extra newline
- s/entry/color/
- remove LUT size checks
- program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
- Change the comments in description of fine and coarse segments,
and try to make more sense.
- use 8 * 128 instead of 1024
- add 1 entry in LUT for GCMAX
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_color.c | 127
-
2 files changed, 124 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c
b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..2f99b585d44b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,7 @@ static const struct intel_device_info
intel_cannonlake_info = {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..c1a9506fd069 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,8 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
Unused.
Got it
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32
fixed point
* format). This macro takes the coefficient we want transformed
and the
@@ -767,6 +769,116 @@ static void glk_load_luts(const struct
intel_crtc_state *crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
Blue is missing the shift.
Ok,
I'm not 100% sure if the ldw vs. udw are the right way around. The spec
has at times been inconsistent with the odd vs. even descriptions,
sometimes even contradicting itself. Also it never really defines
whether it starts counting dwords from from 0 or 1, so not sure what
odd and even actually mean. Can I presume someone has checked this
on actual hardware?
Well, the property was getting set properly, and the display looked
ok, but dint dump the values in registers. Can check it now.
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *color)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT ent
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/icl: Add Multi-segmented gamma support
On 5/7/2019 7:57 PM, Ville Syrjälä wrote:
On Tue, May 07, 2019 at 07:26:44PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
V3: Addressed review comments from Ville
- extra newline
- s/entry/color/
- remove LUT size checks
- program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
- Change the comments in description of fine and coarse segments,
and try to make more sense.
- use 8 * 128 instead of 1024
- add 1 entry in LUT for GCMAX
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/intel_color.c | 127 -
2 files changed, 124 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..2f99b585d44b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,7 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 }
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..c1a9506fd069 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,8 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
Unused.
Got it
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +769,116 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
Blue is missing the shift.
Ok,
I'm not 100% sure if the ldw vs. udw are the right way around. The spec
has at times been inconsistent with the odd vs. even descriptions,
sometimes even contradicting itself. Also it never really defines
whether it starts counting dwords from from 0 or 1, so not sure what
odd and even actually mean. Can I presume someone has checked this
on actual hardware?
Well, the property was getting set properly, and the display looked ok,
but dint dump the values in registers. Can check it now.
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *color)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), color->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), color->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), color->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv =
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
Regards
Shashank
On 5/6/2019 6:41 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 06:25:19PM +0530, Sharma, Shashank wrote:
On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 125 -
2 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
+
Bogus newline.
Got it.
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..49831e8d02fb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,9 @@
#define CTM_COEFF_ABS(coeff)((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
Sure.
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ if (!lut || drm_color_lut_size(blob) <
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 125 -
2 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
+
Bogus newline.
Got it.
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..49831e8d02fb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,9 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
Sure.
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ if (!lut || drm_color_lut_size(blob) < ICL_GAMMA_SUPERFINE_SEG_LENGTH)
+ return;
These checks aren't needed. Just dead code.
Will remove this and similars.
+
+
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 125 -
2 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
+
Bogus newline.
Got it.
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..49831e8d02fb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,9 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
Sure.
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ if (!lut || drm_color_lut_size(blob) < ICL_GAMMA_SUPERFINE_SEG_LENGTH)
+ return;
These checks aren't needed. Just dead code.
Will remove this and similars.
+
+ /*
+* Every entry in the multi-segment LUT is corresponding to a superfine
+* segment step which is 1/(8 * 128 * 256).
+*
+* Superfine segment has 9 entries, corresponding to values
+* 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 *
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Add register definitions for Multi Segmented gamma
On 5/3/2019 8:35 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:06PM +0530, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
- Use REG_GENMASK() and REG_BIT()
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Maarten Lankhorst
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6f0a0866c802..7d10b8d00d64 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7198,7 +7198,10 @@ enum {
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT(1 << 0)
#define GAMMA_MODE_MODE_12BIT(2 << 0)
+/* ivb-bdw */
#define GAMMA_MODE_MODE_SPLIT(3 << 0)
+/* icl + */
+#define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0)
I would put the comments at the end of the line
#define ... /* ivb-bdw */
/* DMC/CSR */
#define CSR_PROGRAM(i)_MMIO(0x8 + (i) * 4)
@@ -10145,6 +10148,22 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* Add registers for Gen11 Multi Segmented Gamma Mode */
Weird comment. 's/Add registers for //' might make it somewhat useful.
And no point in capitalizing every word. This isn't a movie title/etc.
With those sorted this is
Reviewed-by: Ville Syrjälä
Thanks for the review, will do the changes as suggested.
- Shashank
+#define _PAL_PREC_MULTI_SEG_INDEX_A0x4A408
+#define _PAL_PREC_MULTI_SEG_INDEX_B0x4AC08
+#define PAL_PREC_MULTI_SEGMENT_AUTO_INCREMENT REG_BIT(15)
+#define PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK REG_GENMASK(4, 0)
+
+#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
+#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
+
+#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_INDEX_A, \
+ _PAL_PREC_MULTI_SEG_INDEX_B)
+#define PREC_PAL_MULTI_SEG_DATA(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_DATA_A, \
+ _PAL_PREC_MULTI_SEG_DATA_B)
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, May 2, 2019 3:45 PM
> To: Sharma, Shashank
> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> ; Lankhorst,
> Maarten
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for
> BT2020 framebuffers
>
> On Thu, May 02, 2019 at 03:19:42PM +0530, Shashank Sharma wrote:
> > Framebuffer formats P01x are supported by GLK, but the function which
> > handles CSC on plane color control register, still expectes the input
> > buffer to be REC709. This can cause inaccurate output for direct P01x
> > flips.
> >
> > This patch checks if the color_encoding property is set to YCBCR_2020,
> > and enables the corresponding color conversion mode on plane CSC.
> >
> > PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
> >
> > Cc: Ville Syrjala
> > Cc: Maarten Lankhorst
> > Cc: Uma Shankar
> > Signed-off-by: Shashank Sharma
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 26 --
> > 1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index dd65d7c521c1..2d4d3128bf1f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct
> > intel_crtc_state
> *crtc_state,
> > to_i915(plane_state->base.plane->dev);
> > const struct drm_framebuffer *fb = plane_state->base.fb;
> > struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > - u32 plane_color_ctl = 0;
> > + u32 color_ctl = 0;
> >
> > - plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > - plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > + color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > + color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> >
> > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > - if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
> > - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > - else
> > - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > + switch (plane_state->base.color_encoding) {
> > + case DRM_COLOR_YCBCR_BT709:
> > + color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > + break;
> > + case DRM_COLOR_YCBCR_BT2020:
> > + color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > + break;
> > + default:
> > + color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > + }
>
> This isn't going to do anything without adjusting the property supported
> encodings as
> well.
>
I might have not understood this comment properly, but, AFAIK, if userspace
sets this property well, and we set this color_ctl bit properly, driver is
setting PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020 bits in GLK color control
register. As GLK has a fix function plane CSC, HW will apply a different matrix
internally to convert input buffer to RGB_2020 from YCBCR_2020 (earlier this
would have been YCBCR_709). So I think we should see visible changes in
output. Do you think otherwise ?
- Shashank
> >
> > if (plane_state->base.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
> > - plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > + color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > } else if (fb->format->is_yuv) {
> > - plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > + color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > }
> >
> > - return plane_color_ctl;
> > + return color_ctl;
> > }
> >
> > static int
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used
On 4/30/2019 4:09 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 10:22:40AM +0530, Sharma, Shashank wrote:
On 4/26/2019 8:07 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 06:40:11PM +0530, Sharma, Shashank wrote:
On 4/13/2019 12:00 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The pipe has a special HDR mode with higher precision when only
HDR planes are active. Let's use it.
Curiously this fixes the kms_color gamma/degamma tests when
using a HDR plane, which is always the case unless one hacks
the test to use an SDR plane. If one does hack the test to use
an SDR plane it does pass already.
I have no actual explanation how the output after the gamma
LUT can be different between the two modes. The way the tests
are written should mean that the output should be identical
between the solid color vs. the gradient. But clearly that
somehow doesn't hold true for the HDR planes in non-HDR pipe
mode. Anyways, as long as we stick to one type of plane the
test should produce sensible results now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 7 +++
drivers/gpu/drm/i915/intel_sprite.h | 12
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8ad2f0a03f28..90d60ecd3317 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5767,6 +5767,7 @@ enum {
#define _PIPE_MISC_B0x71030
#define PIPEMISC_YUV420_ENABLE(1 << 27)
#define PIPEMISC_YUV420_MODE_FULL_BLEND (1 << 26)
+#define PIPEMISC_HDR_MODE(1 << 23) /* icl+ */
#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1 << 11)
#define PIPEMISC_DITHER_BPC_MASK (7 << 5)
#define PIPEMISC_DITHER_8_BPC (0 << 5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 490bd49ff42a..d0dbdbd5db3f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4055,6 +4055,9 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
+ if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
+ bdw_set_pipemisc(new_crtc_state);
+
if (INTEL_GEN(dev_priv) >= 11)
icl_set_pipe_chicken(crtc);
}
@@ -8869,6 +8872,10 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
val |= PIPEMISC_YUV420_ENABLE |
PIPEMISC_YUV420_MODE_FULL_BLEND;
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ (crtc_state->active_planes & ~icl_hdr_plane_mask()) == 0)
+ val |= PIPEMISC_HDR_MODE;
+
Shouldn't we check if the content being played on plane is HDR before
enabling this bit (even though I am not sure if there is any harm in
doing that)? Or maybe check the connector->output_hdr_metadata ? Most of
the times we would be sending SDR buffers on this plane. What happens
exactly when we set this bit ? The bspec says:
"This field enables the HDR mode, allowing for higher precision output
from the HDR supporting planes and bypassing the SDR planes in blending. "
I think the bit is just misnamed (like most things with "HDR" in their
name). It's just a "gimme moar precision" bit.
Lets make this a bit more clear, may be rename the bit to
PIPEMISC_HDR_PRECISION_MODE instead?
Then it won't match the spec.
Well we are keeping HDR_MODE aren't we ? may be
PIPEMISC_HDR_MODE_PRECISION if that makes us closer to spec ?
- Shashank
With that change, this patch is
Reviewed-by: Shashank Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/icl: Add register definitions for Multi Segmented gamma
On 4/29/2019 7:42 PM, Jani Nikula wrote:
On Fri, 26 Apr 2019, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b74824f0b5b1..fc50e85ca895 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7198,6 +7198,7 @@ enum {
#define GAMMA_MODE_MODE_10BIT(1 << 0)
#define GAMMA_MODE_MODE_12BIT(2 << 0)
#define GAMMA_MODE_MODE_SPLIT(3 << 0)
+#define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0)
/* DMC/CSR */
#define CSR_PROGRAM(i)_MMIO(0x8 + (i) * 4)
@@ -10144,6 +10145,22 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* Add registers for Gen11 Multi Segmented Gamma Mode */
+#define _PAL_PREC_MULTI_SEG_INDEX_A0x4A408
+#define _PAL_PREC_MULTI_SEG_INDEX_B0x4AC08
+#define PAL_PREC_MULTI_SEGMENT_AUTO_INCREMENT BIT(15)
+#define PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK (0x1f << 0)
See REG_BIT() and REG_FIELD_PREP() at the top of the file.
BR,
Jani.
Got it Jani, Thanks !
Regards
Shashank
+
+#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
+#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
+
+#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_INDEX_A, \
+ _PAL_PREC_MULTI_SEG_INDEX_B)
+#define PREC_PAL_MULTI_SEG_DATA(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_DATA_A, \
+ _PAL_PREC_MULTI_SEG_DATA_B)
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used
On 4/26/2019 8:07 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 06:40:11PM +0530, Sharma, Shashank wrote:
On 4/13/2019 12:00 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The pipe has a special HDR mode with higher precision when only
HDR planes are active. Let's use it.
Curiously this fixes the kms_color gamma/degamma tests when
using a HDR plane, which is always the case unless one hacks
the test to use an SDR plane. If one does hack the test to use
an SDR plane it does pass already.
I have no actual explanation how the output after the gamma
LUT can be different between the two modes. The way the tests
are written should mean that the output should be identical
between the solid color vs. the gradient. But clearly that
somehow doesn't hold true for the HDR planes in non-HDR pipe
mode. Anyways, as long as we stick to one type of plane the
test should produce sensible results now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 7 +++
drivers/gpu/drm/i915/intel_sprite.h | 12
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8ad2f0a03f28..90d60ecd3317 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5767,6 +5767,7 @@ enum {
#define _PIPE_MISC_B 0x71030
#define PIPEMISC_YUV420_ENABLE (1 << 27)
#define PIPEMISC_YUV420_MODE_FULL_BLEND (1 << 26)
+#define PIPEMISC_HDR_MODE(1 << 23) /* icl+ */
#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1 << 11)
#define PIPEMISC_DITHER_BPC_MASK (7 << 5)
#define PIPEMISC_DITHER_8_BPC (0 << 5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 490bd49ff42a..d0dbdbd5db3f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4055,6 +4055,9 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
+ if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
+ bdw_set_pipemisc(new_crtc_state);
+
if (INTEL_GEN(dev_priv) >= 11)
icl_set_pipe_chicken(crtc);
}
@@ -8869,6 +8872,10 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
val |= PIPEMISC_YUV420_ENABLE |
PIPEMISC_YUV420_MODE_FULL_BLEND;
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ (crtc_state->active_planes & ~icl_hdr_plane_mask()) == 0)
+ val |= PIPEMISC_HDR_MODE;
+
Shouldn't we check if the content being played on plane is HDR before
enabling this bit (even though I am not sure if there is any harm in
doing that)? Or maybe check the connector->output_hdr_metadata ? Most of
the times we would be sending SDR buffers on this plane. What happens
exactly when we set this bit ? The bspec says:
"This field enables the HDR mode, allowing for higher precision output
from the HDR supporting planes and bypassing the SDR planes in blending. "
I think the bit is just misnamed (like most things with "HDR" in their
name). It's just a "gimme moar precision" bit.
Lets make this a bit more clear, may be rename the bit to
PIPEMISC_HDR_PRECISION_MODE instead?
With that change, this patch is
Reviewed-by: Shashank Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: Add Multi-segmented gamma support
On 4/29/2019 5:19 PM, Ville Syrjälä wrote:
On Mon, Apr 29, 2019 at 05:00:21PM +0530, Sharma, Shashank wrote:
On 4/26/2019 11:59 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 11:31:51PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 155 -
2 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
+
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index ca341a9e47e6..d1fb79a5d764 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,7 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_MULTISEG_LUT_LENGTH(256 * 128 * 8)
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -58,6 +59,12 @@
#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
+enum icl_ms_gamma_segments {
+ ICL_MS_GAMMA_SEG_SUPERFINE,
+ ICL_MS_GAMMA_SEG_FINE,
+ ICL_MS_GAMMA_SEG_COARSE,
+};
+
static const u16 ilk_csc_off_zero[3] = {};
static const u16 ilk_csc_coeff_identity[9] = {
@@ -767,6 +774,149 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_program_gamma_gcmax(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /*
+* Program the max register to clamp values > 1.0.
+* ToDo: Extend the ABI to be able to program values
+* from 1.0
+*/
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), (1 << 16));
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), (1 << 16));
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), (1 << 16));
This one I think we want to program based on the provide LUT. It's the
last entry that still gets used in interpolation for <1.0 values.
Or at least that's the way it works with the 12p4 mode IIRC. I don't
actually remember how it goes with the multi segment mode.
I am a bit skeptical if its a good idea to program from the LUT, as you
know, the drm_color_lut elements are 16bit per channel, and in order to
program 1.0 we need 17 bits. So even if userspace wants, it cant set the
value of 1.0 as of now. Also, wouldn't it would be good for the
interpolation to have the accurate max value (1.0) of the curve ?
If userspace doesn't want the max to be 1.0 then we will do the wrong
thing here. But I suppose that wouldn't be a very common thing to do.
My point exactly. Most of the time userspac
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: Add Multi-segmented gamma support
On 4/26/2019 11:59 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 11:31:51PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 155 -
2 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
+
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index ca341a9e47e6..d1fb79a5d764 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,7 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_MULTISEG_LUT_LENGTH(256 * 128 * 8)
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -58,6 +59,12 @@
#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
+enum icl_ms_gamma_segments {
+ ICL_MS_GAMMA_SEG_SUPERFINE,
+ ICL_MS_GAMMA_SEG_FINE,
+ ICL_MS_GAMMA_SEG_COARSE,
+};
+
static const u16 ilk_csc_off_zero[3] = {};
static const u16 ilk_csc_coeff_identity[9] = {
@@ -767,6 +774,149 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_program_gamma_gcmax(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /*
+* Program the max register to clamp values > 1.0.
+* ToDo: Extend the ABI to be able to program values
+* from 1.0
+*/
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), (1 << 16));
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), (1 << 16));
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), (1 << 16));
This one I think we want to program based on the provide LUT. It's the
last entry that still gets used in interpolation for <1.0 values.
Or at least that's the way it works with the 12p4 mode IIRC. I don't
actually remember how it goes with the multi segment mode.
I am a bit skeptical if its a good idea to program from the LUT, as you
know, the drm_color_lut elements are 16bit per channel, and in order to
program 1.0 we need 17 bits. So even if userspace wants, it cant set the
value of 1.0 as of now. Also, wouldn't it would be good for the
interpolation to have the accurate max value (1.0) of the curve ?
+
+ /*
+* Program the max register to clamp values > 1.0.
+* ToDo: Extend the ABI to be able to program values
+* from 1.0 to 3.0
+*/
+ I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 0), (1 << 16));
+ I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 1), (1 << 16));
+ I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 2), (1 << 16));
+
+ /*
+* Program the gc max 2 register to clamp values > 1.0.
+* ToDo:
Re: [Intel-gfx] [PATCH 2/3] drm/i915/icl: Add register definitions for Multi Segmented gamma
On 4/26/2019 11:46 PM, Ville Syrjälä wrote:
On Fri, Apr 26, 2019 at 11:31:50PM +0530, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b74824f0b5b1..fc50e85ca895 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7198,6 +7198,7 @@ enum {
#define GAMMA_MODE_MODE_10BIT(1 << 0)
#define GAMMA_MODE_MODE_12BIT(2 << 0)
#define GAMMA_MODE_MODE_SPLIT(3 << 0)
+ /* ivb-bdw */
+#define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0)
+ /* icl+ */
So people don't get super confused about the conflicting values.
- Sure.
Regards
Shashank
/* DMC/CSR */
#define CSR_PROGRAM(i)_MMIO(0x8 + (i) * 4)
@@ -10144,6 +10145,22 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* Add registers for Gen11 Multi Segmented Gamma Mode */
+#define _PAL_PREC_MULTI_SEG_INDEX_A0x4A408
+#define _PAL_PREC_MULTI_SEG_INDEX_B0x4AC08
+#define PAL_PREC_MULTI_SEGMENT_AUTO_INCREMENT BIT(15)
+#define PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK (0x1f << 0)
+
+#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
+#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
+
+#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_INDEX_A, \
+ _PAL_PREC_MULTI_SEG_INDEX_B)
+#define PREC_PAL_MULTI_SEG_DATA(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_DATA_A, \
+ _PAL_PREC_MULTI_SEG_DATA_B)
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used
On 4/13/2019 12:00 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The pipe has a special HDR mode with higher precision when only
HDR planes are active. Let's use it.
Curiously this fixes the kms_color gamma/degamma tests when
using a HDR plane, which is always the case unless one hacks
the test to use an SDR plane. If one does hack the test to use
an SDR plane it does pass already.
I have no actual explanation how the output after the gamma
LUT can be different between the two modes. The way the tests
are written should mean that the output should be identical
between the solid color vs. the gradient. But clearly that
somehow doesn't hold true for the HDR planes in non-HDR pipe
mode. Anyways, as long as we stick to one type of plane the
test should produce sensible results now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 7 +++
drivers/gpu/drm/i915/intel_sprite.h | 12
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8ad2f0a03f28..90d60ecd3317 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5767,6 +5767,7 @@ enum {
#define _PIPE_MISC_B 0x71030
#define PIPEMISC_YUV420_ENABLE (1 << 27)
#define PIPEMISC_YUV420_MODE_FULL_BLEND (1 << 26)
+#define PIPEMISC_HDR_MODE(1 << 23) /* icl+ */
#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1 << 11)
#define PIPEMISC_DITHER_BPC_MASK(7 << 5)
#define PIPEMISC_DITHER_8_BPC (0 << 5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 490bd49ff42a..d0dbdbd5db3f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4055,6 +4055,9 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
+ if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
+ bdw_set_pipemisc(new_crtc_state);
+
if (INTEL_GEN(dev_priv) >= 11)
icl_set_pipe_chicken(crtc);
}
@@ -8869,6 +8872,10 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
val |= PIPEMISC_YUV420_ENABLE |
PIPEMISC_YUV420_MODE_FULL_BLEND;
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ (crtc_state->active_planes & ~icl_hdr_plane_mask()) == 0)
+ val |= PIPEMISC_HDR_MODE;
+
Shouldn't we check if the content being played on plane is HDR before
enabling this bit (even though I am not sure if there is any harm in
doing that)? Or maybe check the connector->output_hdr_metadata ? Most of
the times we would be sending SDR buffers on this plane. What happens
exactly when we set this bit ? The bspec says:
"This field enables the HDR mode, allowing for higher precision output
from the HDR supporting planes and bypassing the SDR planes in blending. "
- Shashank
I915_WRITE(PIPEMISC(crtc->pipe), val);
}
diff --git a/drivers/gpu/drm/i915/intel_sprite.h b/drivers/gpu/drm/i915/intel_sprite.h
index 84be8686be16..500f6bffb139 100644
--- a/drivers/gpu/drm/i915/intel_sprite.h
+++ b/drivers/gpu/drm/i915/intel_sprite.h
@@ -43,13 +43,17 @@ static inline bool icl_is_nv12_y_plane(enum plane_id id)
return false;
}
+static inline u8 icl_hdr_plane_mask(void)
+{
+ return BIT(PLANE_PRIMARY) |
+ BIT(PLANE_SPRITE0) | BIT(PLANE_SPRITE1);
+}
+
static inline bool icl_is_hdr_plane(struct drm_i915_private *dev_priv,
enum plane_id plane_id)
{
- if (INTEL_GEN(dev_priv) < 11)
- return false;
-
- return plane_id < PLANE_SPRITE2;
+ return INTEL_GEN(dev_priv) >= 11 &&
+ icl_hdr_plane_mask() & BIT(plane_id);
}
#endif /* __INTEL_SPRITE_H__ */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/7] drm: Add Client Cap for advance gamma mode
On 4/15/2019 7:42 PM, Lankhorst, Maarten wrote: mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank: -Original Message- From: Lankhorst, Maarten Sent: Monday, April 15, 2019 4:28 PM To: Shankar, Uma ; intel-gfx@lists.freedeskt op.org; dri- de...@lists.freedesktop.org Cc: Syrjala, Ville ; emil.l.velikov@gmail. com; s...@ravnborg.org; Roper, Matthew D ; seanp...@chromium.org; brian.star...@arm.com; dcasta...@chromium.or g; Sharma, Shashank Subject: Re: [v3 6/7] drm: Add Client Cap for advance gamma mode fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar: Introduced a client cap for advance cap mode capability. Userspace should set this to get to be able to use the new gamma_mode property. If this is not set, driver will work in legacy mode. Suggested-by: Ville Syrjälä Signed-off-by: Uma Shankar Nack, this doesn't seem like a sensible idea. We already guard it behind the gamma mode property. Userspace shouldn't set the gamma mode to a value it doesn't understand. ~Maarten Hey Maarten, In that case, what do you suggest should be the right way to do this ? @Ville, any comments here ? I would say drop this patch, and just enable segmented gamma unconditionally, it's not the first property that can cause trouble when not understood. Honestly, I kindof like this simple approach suggestion, which makes the property focused, and easy to use. But one of the benefits I see for this new gamma mode property was, that we can handle other advanced gamma modes like 10/12/split and multi-segmented gamma modes too, using this. So even though the single property is easy to use, but if we try to cover each of the gamma modes per single property, it might get confusing to see 4 different gamma mode properties, and how to set one of this. Another problem I see is, the precision and no of entries in the LUT, for multi-segment gamma is different than traditional gamma, and we might break some (most ?) of the old userspaces. Do you think is there any way in which we can avoid this ? - Shashank ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/7] drm: Add Client Cap for advance gamma mode
> -Original Message-
> From: Lankhorst, Maarten
> Sent: Monday, April 15, 2019 4:28 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Syrjala, Ville ; emil.l.veli...@gmail.com;
> s...@ravnborg.org; Roper, Matthew D ;
> seanp...@chromium.org; brian.star...@arm.com; dcasta...@chromium.org;
> Sharma, Shashank
> Subject: Re: [v3 6/7] drm: Add Client Cap for advance gamma mode
>
> fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar:
> > Introduced a client cap for advance cap mode
> > capability. Userspace should set this to get
> > to be able to use the new gamma_mode property.
> >
> > If this is not set, driver will work in legacy
> > mode.
> >
> > Suggested-by: Ville Syrjälä
> > Signed-off-by: Uma Shankar
>
> Nack, this doesn't seem like a sensible idea. We already guard it
> behind the gamma mode property. Userspace shouldn't set the gamma mode
> to a value it doesn't understand.
>
> ~Maarten
Hey Maarten,
In that case, what do you suggest should be the right way to do this ?
@Ville, any comments here ?
Regards
Shashank
>
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_ioctl.c | 5 +
> > include/drm/drm_atomic.h | 1 +
> > include/drm/drm_crtc.h| 7 +++
> > include/drm/drm_file.h| 8
> > include/uapi/drm/drm.h| 2 ++
> > 6 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index d85e0c9..590c87a 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -974,6 +974,8 @@ int drm_atomic_set_property(struct
> > drm_atomic_state *state,
> > break;
> > }
> >
> > + crtc_state->advance_gamma_mode_active =
> > + state-
> > >advance_gamma_mode_active;
> > ret = drm_atomic_crtc_set_property(crtc,
> > crtc_state, prop, prop_value);
> > break;
> > @@ -1297,6 +1299,7 @@ int drm_mode_atomic_ioctl(struct drm_device
> > *dev,
> > drm_modeset_acquire_init(,
> > DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > state->acquire_ctx =
> > state->allow_modeset = !!(arg->flags &
> > DRM_MODE_ATOMIC_ALLOW_MODESET);
> > + state->advance_gamma_mode_active = file_priv-
> > >advance_gamma_mode_active;
> >
> > retry:
> > copied_objs = 0;
> > diff --git a/drivers/gpu/drm/drm_ioctl.c
> > b/drivers/gpu/drm/drm_ioctl.c
> > index d337f16..e593a4c 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -348,6 +348,11 @@ static int drm_getcap(struct drm_device *dev,
> > void *data, struct drm_file *file_
> > return -EINVAL;
> > file_priv->writeback_connectors = req->value;
> > break;
> > + case DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES:
> > + if (req->value > 1)
> > + return -EINVAL;
> > + file_priv->advance_gamma_mode_active = req->value;
> > + break;
> > default:
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index 824a5ed..02c1a68 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -338,6 +338,7 @@ struct drm_atomic_state {
> > * states.
> > */
> > bool duplicated : 1;
> > + bool advance_gamma_mode_active : 1;
> > struct __drm_planes_state *planes;
> > struct __drm_crtcs_state *crtcs;
> > int num_connector;
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index f789359..f11dc25 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -170,6 +170,11 @@ struct drm_crtc_state {
> > bool color_mgmt_changed : 1;
> >
> > /**
> > +* This is to indicate advance gamma mode support
> > +*/
> > + bool advance_gamma_mode_active : 1;
> > +
> > + /**
> > * @no_vblank:
> > *
> > * Reflects the ability of a CRTC to send VBLANK events.
> > This state
> > @@ -952,6 +957,8 @@ struct drm_crtc {
> > */
> > bool enabled;
> >
> > + bool advance_gamma_mode_active : 1;
> > +
> > /**
> > * @mode:
> >
Re: [Intel-gfx] [v7 0/9] Add HDR Metadata Parsing and handling in DRM layer
Hello Uma, V7 looks good to me, please feel free to use for the whole series: Reviewed-by: Shashank Sharma Regards Shashank On 4/3/2019 1:50 AM, Uma Shankar wrote: This patch series enables HDR support in drm. It basically defines HDR metadata structures, property to pass content (after blending) metadata from user space compositors to driver. Dynamic Range and Mastering infoframe creation and sending. ToDo: 1. We need to get the color framework in place for all planes which support HDR content in hardware. This is already in progres and patches are out for review in mailing list. 2. UserSpace/Compositors: Blending policies and metadata blob creation and passing to driver. Work is already in progress by Intel's middleware teams on wayland and the patches for the same are in review. Please review and share your feedbacks/suggestions. Note: The intention for these patches is to get a design feedback on the uapi changes, generic property design and infoframe handling. This cannot get merged as of now without the userspace support in place. A POC has already been developed by Ville based on wayland. Please refer below link to see the component interactions and usage: https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html v2: Updated Ville's POC changes to the patch series.Incorporated cleanups and fixes from Ville. Rebase on latest drm-tip. v3: Fixed a warning causing builds to break on CI. No major change. v4: Addressed Shashank's review comments. v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset case for HDR metadata update. Dropped a redundant patch. v6: Addressed Shashank's review comments and added RB's received. v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and Shashank's review comments. Note: Media driver and VAAPI changes for HDR are already out, with compositors changes also expected to land soon. Weston changes already floated and reviews started in community and is in active development along with GL efforts. Uma Shankar (7): drm: Add HDR source metadata property drm: Parse HDR metadata info from EDID drm: Enable HDR infoframe support drm/i915: Attach HDR metadata property to connector drm/i915: Write HDR infoframe and send to panel drm/i915:Enabled Modeset when HDR Infoframe changes drm/i915: Set Infoframe for non modeset case for HDR Ville Syrjälä (2): drm/i915: Add HLG EOTF drm/i915: Enable infoframes on GLK+ for HDR drivers/gpu/drm/drm_atomic.c| 2 + drivers/gpu/drm/drm_atomic_uapi.c | 13 +++ drivers/gpu/drm/drm_connector.c | 6 ++ drivers/gpu/drm/drm_edid.c | 102 drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_atomic.c | 14 ++- drivers/gpu/drm/i915/intel_ddi.c| 13 +++ drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 79 ++- drivers/video/hdmi.c| 186 include/drm/drm_connector.h | 10 ++ include/drm/drm_edid.h | 5 + include/drm/drm_mode_config.h | 6 ++ include/linux/hdmi.h| 38 include/uapi/drm/drm_mode.h | 22 + 15 files changed, 496 insertions(+), 5 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 11/13] drm/i915:Enabled Modeset when HDR Infoframe changes
On 3/20/2019 4:18 PM, Uma Shankar wrote:
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic.c | 15 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 4
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b844e88..4ff6042 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -102,6 +102,16 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return -EINVAL;
}
+static bool blob_equal(const struct drm_property_blob *a,
+ const struct drm_property_blob *b)
+{
+ if (a && b)
+ return a->length == b->length &&
+ !memcmp(a->data, b->data, a->length);
+
+ return !a == !b;
+}
+
int intel_digital_connector_atomic_check(struct drm_connector *conn,
struct drm_connector_state *new_state)
{
@@ -129,7 +139,10 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
- new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
+ new_conn_state->base.scaling_mode !=
+ old_conn_state->base.scaling_mode ||
+ !blob_equal(new_conn_state->base.hdr_output_metadata_blob_ptr,
If you are keeping this line ahead of the upper one due to 80 char
limit, please pull that one also two tabs back, right now this is not
even looking good.
+ old_conn_state->base.hdr_output_metadata_blob_ptr))
crtc_state->mode_changed = true;
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 8decafd..4d06734 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -792,6 +792,10 @@ void intel_read_infoframe(struct intel_encoder *encoder,
struct hdr_static_metadata *hdr_metadata;
int ret;
+ if (!conn_state->hdr_output_metadata_blob_ptr ||
+ conn_state->hdr_output_metadata_blob_ptr->length == 0)
+ return true;
+
This patch needs a rebase on the latest code, as this is definitely not
where we want this code :-)
- Shashank
hdr_metadata = (struct hdr_static_metadata *)
conn_state->hdr_output_metadata_blob_ptr->data;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 10/13] drm/i915: Enable infoframes on GLK+ for HDR
On 3/20/2019 4:18 PM, Uma Shankar wrote:
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 18 +-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 31a3020..fe931e7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4718,6 +4718,7 @@ enum {
#define VIDEO_DIP_FREQ_MASK (3 << 16)
/* HSW and later: */
#define DRM_DIP_ENABLE (1 << 28)
+#define VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
#define PSR_VSC_BIT_7_SET (1 << 27)
#define VSC_SELECT_MASK (0x3 << 25)
#define VSC_SELECT_SHIFT25
@@ -8156,6 +8157,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
#define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
#define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A 0x60440
#define _HSW_VIDEO_DIP_AVI_ECC_A 0x60240
#define _HSW_VIDEO_DIP_VS_ECC_A 0x60280
#define _HSW_VIDEO_DIP_SPD_ECC_A 0x602C0
@@ -8169,6 +8171,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
#define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
#define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B 0x61440
#define _HSW_VIDEO_DIP_BVI_ECC_B 0x61240
#define _HSW_VIDEO_DIP_VS_ECC_B 0x61280
#define _HSW_VIDEO_DIP_SPD_ECC_B 0x612C0
@@ -8194,6 +8197,7 @@ enum {
#define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_ECC(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index e4bc7fc..8decafd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -134,6 +134,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -159,6 +161,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -545,7 +549,8 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+ VIDEO_DIP_ENABLE_DRM_GLK);
I think this should also be GEN check protected, as
hsw_infoframes_enabled will be called by many platforms, and before GLK
they cant support DRM_IF.
}
static const u8 infoframe_type_to_idx[] = {
@@ -1177,7 +1182,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);
Same here.
- Shashank
if (!enable) {
I915_WRITE(reg, val);
@@ -1200,9 +1206,11 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
_state->infoframes.hdmi);
- intel_write_infoframe(encoder, crtc_state,
- HDMI_INFOFRAME_TYPE_DRM,
- _state->infoframes.drm);
+ if ((INTEL_GEN(dev_priv) >= 10 ||
Re: [Intel-gfx] [v6 13/13] video/hdmi: Add const variants for drm infoframe
On 3/20/2019 4:18 PM, Uma Shankar wrote:
Added the const version of infoframe for DRM metadata
for HDR.
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 63 ++--
include/linux/hdmi.h | 5 +
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 80bb0ee..f9ca555 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -668,6 +668,30 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe
*frame)
}
EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe *frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
+ frame->version != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
This comment doesn't match what's being done in this function, as,
hdmi_drm_infoframe_check_only() doesn't validate length.
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame)
+{
+ return hdmi_drm_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_check);
+
/**
* hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
* @frame: HDMI DRM infoframe
@@ -682,8 +706,8 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe
*frame)
* Returns the number of bytes packed into the binary buffer or a negative
* error code on failure.
*/
-ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
- size_t size)
+ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe *frame,
+void *buffer, size_t size)
{
u8 *ptr = buffer;
size_t length;
@@ -736,6 +760,37 @@ ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe
*frame, void *buffer,
return length;
}
+EXPORT_SYMBOL(hdmi_drm_infoframe_pack_only);
+
+/**
+ * hdmi_drm_infoframe_pack() - check a HDMI DRM infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which it packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame,
+ void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_drm_infoframe_check(frame);
+ if (ret)
+ return ret;
+
+ return hdmi_drm_infoframe_pack_only(frame, buffer, size);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_pack);
/*
* hdmi_vendor_any_infoframe_check() - check a vendor infoframe
@@ -845,6 +900,10 @@ ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe
*frame, void *buffer,
length = hdmi_avi_infoframe_pack_only(>avi,
buffer, size);
break;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ length = hdmi_drm_infoframe_pack_only(>drm,
+ buffer, size);
+ break;
case HDMI_INFOFRAME_TYPE_SPD:
length = hdmi_spd_infoframe_pack_only(>spd,
buffer, size);
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 202ed4a..fd8e534 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -213,6 +213,11 @@ ssize_t hdmi_avi_infoframe_pack_only(const struct
hdmi_avi_infoframe *frame,
void *buffer, size_t size);
int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame);
int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame);
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
+ size_t size);
+ssize_t hdmi_drm_infoframe_pack_only(const struct hdmi_drm_infoframe *frame,
+void *buffer, size_t size);
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame);
enum hdmi_spd_sdi {
HDMI_SPD_SDI_UNKNOWN,
With that minor comment related to description fixed, this patch looks
good to me. Please feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
__
Re: [Intel-gfx] [v6 12/13] drm/i915: Set Infoframe for non modeset case for HDR
On 3/20/2019 4:18 PM, Uma Shankar wrote:
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 69aa0d1..a27aab9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3566,6 +3566,10 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_digital_port *intel_dig_port =
+ enc_to_dig_port(>base);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
@@ -3575,6 +3579,15 @@ static void intel_ddi_update_pipe(struct intel_encoder *encoder,
else if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
+
+ /* Set the infoframe for NON modeset cases as well */
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
+ conn_state->hdr_metadata_changed)
+ intel_dig_port->set_infoframes(encoder,
+
crtc_state->has_infoframe,
+ crtc_state, conn_state);
+ }
}
Looks good to me, Please feel free to use:
Reviewed-by: Shashank Sharma
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 07/13] drm/i915: Write HDR infoframe and send to panel
On 3/20/2019 4:18 PM, Uma Shankar wrote:
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation in compute config.
v6: Addressed Shashank's review comment. Added HDR metadata
support from GEN10 onwards as per Shashank's recommendation.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 41 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d9f188e..c6c3cc7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1043,6 +1043,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+ union hdmi_infoframe drm;
} infoframes;
/* HDMI scrambling status */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5f06237..e4bc7fc 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -555,6 +555,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+ HDMI_INFOFRAME_TYPE_DRM,
};
u32 intel_hdmi_infoframe_enable(unsigned int type)
@@ -777,6 +778,30 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool
+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+ struct hdr_static_metadata *hdr_metadata;
+ int ret;
+
+ hdr_metadata = (struct hdr_static_metadata *)
+ conn_state->hdr_output_metadata_blob_ptr->data;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1175,6 +1200,9 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
_state->infoframes.hdmi);
+ intel_write_infoframe(encoder, crtc_state,
We should have a GEN check here also, else, there could be case where we
dint compute infoframes <=10 but wrote it, which will write garbage.
- Shashank
+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
@@ -2381,6 +2409,19 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
+ /*
+* Support HDR Metadata from Gen10 onwards
+* ToDo: Gen9 also can support HDR with LSPCON.
+* Support for the same to be enabled later.
+*/
+ if (INTEL_GEN(dev_priv) >= 10) {
+ if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config,
+ conn_state)) {
+ DRM_DEBUG_KMS("bad DRM infoframe\n");
+ return -EINVAL;
+ }
+ }
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 02/13] drm: Parse HDR metadata info from EDID
On 3/20/2019 4:18 PM, Uma Shankar wrote:
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 49 ++
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fa39592..fd8a621a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2840,6 +2840,7 @@ static int drm_cvt_modes(struct drm_connector *connector,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
#define EXT_VIDEO_DATA_BLOCK_420 0x0E
@@ -3587,6 +3588,12 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
}
static int
+cea_db_payload_len_ext(const u8 *db)
+{
+ return (db[0] & 0x1f) - 1;
+}
+
+static int
cea_db_extended_tag(const u8 *db)
{
return db[1];
@@ -3822,6 +3829,46 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint8_t eotf_supported(const u8 *edid_ext)
+{
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+}
+
+static uint8_t hdr_metadata_type(const u8 *edid_ext)
+{
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+ u16 len;
+
+ len = cea_db_payload_len_ext(db);
+ connector->hdr_metadata.eotf = eotf_supported(db);
+ connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
+
+ if (len >= 5)
+ connector->hdr_metadata.max_fall = db[5];
+ if (len >= 4)
Little bike shed, If we pass >=5 we need not to compare >= 4, or we
should check >=4 first and then >=5 in sequence.
With that change ( and assuming you fixed the checkpatch stuff already),
please feel free to use:
Reviewed-by: Shashank Sharma
+ connector->hdr_metadata.max_cll = db[4];
+}
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -4449,6 +4496,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
drm_parse_vcdb(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 03/13] drm: Parse Colorimetry data block from EDID
On 3/20/2019 12:47 PM, Shankar, Uma wrote:
-Original Message-
From: Sharma, Shashank
Sent: Friday, March 15, 2019 1:01 PM
To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; dri-
de...@lists.freedesktop.org
Cc: Lankhorst, Maarten ; Syrjala, Ville
; emil.l.veli...@gmail.com; brian.star...@arm.com;
liviu.du...@arm.com
Subject: RE: [v5 03/13] drm: Parse Colorimetry data block from EDID
-Original Message-
From: Shankar, Uma
Sent: Monday, March 11, 2019 9:28 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Lankhorst, Maarten ; Syrjala, Ville
; Sharma, Shashank
; emil.l.veli...@gmail.com;
brian.star...@arm.com; liviu.du...@arm.com; Shankar, Uma
Subject: [v5 03/13] drm: Parse Colorimetry data block from EDID
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from panel.
v2: Rebase
v3: No Change
v4: Addressed Shashank's review comments. Updated colorimetry field to
16 bit as
DCI-P3 got added in CEA 861-G spec, as pointed out by Shashank.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 26 ++
include/drm/drm_connector.h | 3 +++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
c5a81b8..0470845 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
*connector,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00 @@ -3823,6 +3824,29 @@ static
void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
Same comment for the opening brace above ?
Again this looks like mail client issue.
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
Space before '!' ?
Same here.
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector,
+const
+u8 *db) {
+ struct drm_hdmi_info *info = >display_info.hdmi;
+ uint16_t len;
+
+ len = cea_db_payload_len_ext(db);
+ /* As per CEA 861-G spec */
+ info->colorimetry = ((db[3] & (0x1 << 7)) << 1) | db[2]; }
This means we are setting the 15th bit for DCI-P3 then there is a gap of 7
bits, and
then there are other bits. Do we want to make DCI-P3 as bit 8 ? Anyways this
can be
differed for a discussion later.
This is at 8th position only. We are shifting the db[3] which is 8 bit by 1
and keeping the 7th bit (DCI-P3)
at the 8th position (if we count from 0).
Regards,
Uma Shankar
My bad, its 8th bit only.
If those above alignment problems are checked already, feel free to use
Reviewed-by: Shashank Sharma
- Shashank
+
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
if (cea_db_tag(db) != USE_EXTENDED_TAG) @@ -4495,6 +4519,8 @@ static
void drm_parse_cea_ext(struct drm_connector *connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 29388bd..94f926e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -206,6 +206,9 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /* @colorimetry: bitmap of supported colorimetry modes */
+ u16 colorimetry;
- Shashank
};
/**
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 09/13] drm/i915: Add HLG EOTF
On 3/11/2019 9:28 AM, Uma Shankar wrote:
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 4 ++--
include/linux/hdmi.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 49f8340..4cd22e8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3864,8 +3864,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
return edid_ext[2] &
(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
-BIT(HDMI_EOTF_SMPTE_ST2084));
-
+BIT(HDMI_EOTF_SMPTE_ST2084) |
+BIT(HDMI_EOTF_BT_2100_HLG));
}
static uint8_t hdr_metadata_type(const u8 *edid_ext)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 33243b2..ad652e6 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -161,6 +161,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+ HDMI_EOTF_BT_2100_HLG,
};
Looks good to me,
Feel free to use: Reviewed-by: Shashank Sharma
struct hdmi_avi_infoframe {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 07/13] drm/i915: Write HDR infoframe and send to panel
On 3/11/2019 9:27 AM, Uma Shankar wrote:
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation in compute config.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 33 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 58483f8..a5ee124 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1037,6 +1037,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+ union hdmi_infoframe drm;
} infoframes;
/* HDMI scrambling status */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0952475..ea7afa0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -555,6 +555,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+ HDMI_INFOFRAME_TYPE_DRM,
};
u32 intel_hdmi_infoframe_enable(unsigned int type)
@@ -777,6 +778,30 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool
+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+ struct hdr_static_metadata *hdr_metadata;
+ int ret;
+
Don't we need a GEN/monitor check before going ahead with HDR metadata ?
- Shashank
+ hdr_metadata = (struct hdr_static_metadata *)
+ conn_state->hdr_output_metadata_blob_ptr->data;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1175,6 +1200,9 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
_state->infoframes.hdmi);
+ intel_write_infoframe(encoder, crtc_state,
+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
@@ -2381,6 +2409,11 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
+ if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config, conn_state)) {
+ DRM_DEBUG_KMS("bad DRM infoframe\n");
+ return -EINVAL;
+ }
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 06/13] drm: Enable HDR infoframe support
ct drm_connector *connector,
const struct drm_display_mode *mode,
enum hdmi_quantization_range
rgb_quant_range);
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+ void *hdr_source_metadata);
+
/**
* drm_eld_mnl - Get ELD monitor name length in bytes.
* @eld: pointer to an eld memory structure with mnl set
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index a065194..33243b2 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -47,6 +47,7 @@ enum hdmi_infoframe_type {
HDMI_INFOFRAME_TYPE_AVI = 0x82,
HDMI_INFOFRAME_TYPE_SPD = 0x83,
HDMI_INFOFRAME_TYPE_AUDIO = 0x84,
+ HDMI_INFOFRAME_TYPE_DRM = 0x87,
};
#define HDMI_IEEE_OUI 0x000c03
@@ -185,12 +186,32 @@ struct hdmi_avi_infoframe {
unsigned short right_bar;
};
+struct hdmi_drm_infoframe {
+ enum hdmi_infoframe_type type;
+ unsigned char version;
+ unsigned char length;
+ enum hdmi_eotf eotf;
+ enum hdmi_metadata_type metadata_type;
+ struct {
+ uint16_t x, y;
+ } display_primaries[3];
+ struct {
+ uint16_t x, y;
+ } white_point;
+ uint16_t max_mastering_display_luminance;
+ uint16_t min_mastering_display_luminance;
+ uint16_t max_fall;
+ uint16_t max_cll;
+ uint16_t min_cll;
+};
+
int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame);
ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
*buffer,
size_t size);
ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
void *buffer, size_t size);
int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame);
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame);
enum hdmi_spd_sdi {
HDMI_SPD_SDI_UNKNOWN,
@@ -365,6 +386,7 @@ ssize_t hdmi_vendor_infoframe_pack_only(const struct
hdmi_vendor_infoframe *fram
struct hdmi_spd_infoframe spd;
union hdmi_vendor_any_infoframe vendor;
struct hdmi_audio_infoframe audio;
+ struct hdmi_drm_infoframe drm;
};
With the minor issues pointed above fixed, feel free to use:
Reviewed-by: Shashank Sharma
- Shashank
ssize_t hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 04/13] drm/i915: Attach HDR metadata property to connector
> -Original Message- > From: Shankar, Uma > Sent: Monday, March 11, 2019 9:28 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Lankhorst, Maarten ; Syrjala, Ville > ; Sharma, Shashank ; > emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar, > Uma > Subject: [v5 04/13] drm/i915: Attach HDR metadata property to connector > > Attach HDR metadata property to connector object. > > v2: Rebase > > v3: Updated the property name as per updated name while creating hdr metadata > property > > Signed-off-by: Uma Shankar > --- > drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index cd422a7..0952475 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -2719,6 +2719,8 @@ static void intel_hdmi_destroy(struct drm_connector > *connector) > > drm_connector_attach_content_type_property(connector); > connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > + drm_object_attach_property(>base, > + connector->dev->mode_config.hdr_output_metadata_property, 0); 'connector->dev' should be aligned to the line above, but seems like you have done this to meet the 80 char limit. May be a local ptr variable will help with 80 char. Apart from that, looks good to me, and feel free to use: Reviewed-by: Shashank Sharma > > if (!HAS_GMCH(dev_priv)) > drm_connector_attach_max_bpc_property(connector, 8, 12); > -- > 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 03/13] drm: Parse Colorimetry data block from EDID
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma
> Subject: [v5 03/13] drm: Parse Colorimetry data block from EDID
>
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from panel.
>
> v2: Rebase
>
> v3: No Change
>
> v4: Addressed Shashank's review comments. Updated colorimetry field to 16 bit
> as
> DCI-P3 got added in CEA 861-G spec, as pointed out by Shashank.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_edid.c | 26 ++
> include/drm/drm_connector.h | 3 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> c5a81b8..0470845 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00 @@ -3823,6 +3824,29 @@ static
> void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
Same comment for the opening brace above ?
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
Space before '!' ?
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const
> +u8 *db) {
> + struct drm_hdmi_info *info = >display_info.hdmi;
> + uint16_t len;
> +
> + len = cea_db_payload_len_ext(db);
> + /* As per CEA 861-G spec */
> + info->colorimetry = ((db[3] & (0x1 << 7)) << 1) | db[2]; }
This means we are setting the 15th bit for DCI-P3 then there is a gap of 7
bits, and then there are other bits. Do we want to make DCI-P3 as bit 8 ?
Anyways this can be differed for a discussion later.
> +
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
> if (cea_db_tag(db) != USE_EXTENDED_TAG) @@ -4495,6 +4519,8 @@ static
> void drm_parse_cea_ext(struct drm_connector *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> 29388bd..94f926e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -206,6 +206,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
- Shashank
> };
>
> /**
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 02/13] drm: Parse HDR metadata info from EDID
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma
> Subject: [v5 02/13] drm: Parse HDR metadata info from EDID
>
> HDR metadata block is introduced in CEA-861.3 spec.
> Parsing the same to get the panel's HDR metadata.
>
> v2: Rebase and added Ville's POC changes to the patch.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_edid.c | 52
> ++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 5f14253..c5a81b8 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> #define EXT_VIDEO_DATA_BLOCK_420 0x0E
> @@ -3581,6 +3582,12 @@ static int add_3d_struct_modes(struct drm_connector
> *connector, u16 structure, }
>
> static int
> +cea_db_payload_len_ext(const u8 *db)
> +{
> + return (db[0] & 0x1f) - 1;
You might have already checked with checkpatch, but can we cross check the
space before '-' ?
> +}
> +
> +static int
> cea_db_extended_tag(const u8 *db)
> {
> return db[1];
> @@ -3816,6 +3823,49 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != HDR_STATIC_METADATA_BLOCK)
same here, looks like we need spaces around !=, or may be this is due to my
mail client ?
> + return false;
> +
> + return true;
> +}
> +
> +static uint8_t eotf_supported(const u8 *edid_ext) {
> +
> + return edid_ext[2] &
> + (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
> + BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
Again, space before the '|' sign, please excuse me if this is false alarm ...
> + BIT(HDMI_EOTF_SMPTE_ST2084));
> +
> +}
> +
> +static uint8_t hdr_metadata_type(const u8 *edid_ext) {
> +
> + return edid_ext[3] &
> + BIT(HDMI_STATIC_METADATA_TYPE1);
> +}
> +
> +static void
> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8
> +*db) {
Shouldn't this variable go to line above ?
> + uint16_t len;
> +
> + len = cea_db_payload_len_ext(db);
> + connector->hdr_metadata.eotf = eotf_supported(db);
> + connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
> +
> + if (len >= 5)
> + connector->hdr_metadata.max_fall = db[5];
> + if (len >= 4)
> + connector->hdr_metadata.max_cll = db[4]; }
This '}' certainly should not be here.
> +
> static void
> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db) {
> @@
> -4443,6 +4493,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> drm_parse_y420cmdb_bitmap(connector, db);
> if (cea_db_is_vcdb(db))
> drm_parse_vcdb(connector, db);
> + if (cea_db_is_hdmi_hdr_metadata_block(db))
> + drm_parse_hdr_metadata_block(connector, db);
- Shashank
> }
> }
>
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 01/13] drm: Add HDR source metadata property
Hello Uma,
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma
> Subject: [v5 01/13] drm: Add HDR source metadata property
>
> This patch adds a blob property to get HDR metadata information from
> userspace.
> This will be send as part of AVI Infoframe to panel.
>
> v2: Rebase and modified the metadata structure elements as per Ville's POC
> changes.
>
> v3: No Change
>
> v4: Addressed Shashank's review comments
>
> v5: Rebase.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_connector.c | 6 ++
> include/drm/drm_connector.h | 10 ++
> include/drm/drm_mode_config.h | 6 ++
> include/linux/hdmi.h| 10 ++
> include/uapi/drm/drm_mode.h | 16
> 5 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 07d65a1..b031079 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1054,6 +1054,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.non_desktop_property = prop;
>
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
Needs alignment with the line above.
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_output_metadata_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> c806199..29388bd 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -561,6 +561,13 @@ struct drm_connector_state {
>* and the connector bpc limitations obtained from edid.
>*/
> u8 max_bpc;
> +
> + /**
> + * @metadata_blob_ptr:
> + * DRM blob property for HDR output metadata
> + */
> + struct drm_property_blob *hdr_output_metadata_blob_ptr;
> + u8 hdr_metadata_changed : 1;
> };
>
> /**
> @@ -1201,6 +1208,9 @@ struct drm_connector {
>* _mode_config.connector_free_work.
>*/
> struct llist_node free_node;
> +
> + /* HDR metdata */
> + struct hdr_static_metadata hdr_metadata;
I was under the assumption that we are not parsing the hdr_metadata from the
EDID, and the userspace needs to parse it from the EDID. If that's the case, we
might not even need this pointer. Are we even using this or am I missing
something here ?
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base) diff
> --git
> a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index
> 7f60e8e..ef2656b 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -836,6 +836,12 @@ struct drm_mode_config {
>*/
> struct drm_property *writeback_out_fence_ptr_property;
>
> + /*
> + * hdr_metadata_property: Connector property containing hdr metatda
> + * This will be provided by userspace compositors based on HDR content
> + */
> + struct drm_property *hdr_output_metadata_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index
> 927ad64..a065194
> 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -152,6 +152,16 @@ enum hdmi_content_type {
> HDMI_CONTENT_TYPE_GAME,
> };
>
> +enum hdmi_metadata_type {
> + HDMI_STATIC_METADATA_TYPE1 = 1,
> +};
> +
> +enum hdmi_eotf {
> + HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
> + HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
> + HDMI_EOTF_SMPTE_ST2084,
> +};
> +
> struct hdmi_avi_infoframe {
> enum hdmi_infoframe_type type;
> unsigned char version;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index
> a439c2e..5012af2 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -630,6 +630,22 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/* HDR Metadata */
> +struct hdr_static_metadata {
> + uint8_t eotf;
> + uint8_t metadata_type;
> + struct {
> + uint16_t x, y;
> + } display_primaries[3];
> + struct {
> + uint16_t x, y;
> + } white_point;
>
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:
Regards
Shashank
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Shankar, Uma
Sent: Friday, February 8, 2019 5:45 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
dri-
de...@lists.freedesktop.org; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, February 5, 2019 10:02 PM
To: Shankar, Uma
Cc: intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
property
On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like
601, 709, BT2020 etc. This helps to switch based on content
type which is to be displayed. The decision lies with
compositors as to in which scenarios, a particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut
colorspaces like
BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to
the one supported. Sink supported colorspaces should be
retrieved by userspace from EDID and driver will not explicitly
expose
them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported
colorspaces.
Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the
colorspace is not chosen by user, suggested by Ville and
Maarten. Addressed other misc review comments from Maarten.
Split the changes to have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated
HDMI and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian
Starkey's suggestion in order to go with string matching at userspace.
Updated the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and
Daniel Stone's comments and moved to drm include file. Moved
back to older design with exposing all HDMI colorspaces to
userspace since infoframe capability is there even on legacy
platforms, as per Ville's review comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro
naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78
+++
include/drm/drm_connector.h | 50 +
3 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb =
drm_framebuffer_lookup(dev,
NULL, val);
int ret =
drm_atomic_set_writeback_fb_for_connector(state,
fb); @@
-814,6 +816,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->con
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:
Regards
Shashank
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Shankar, Uma
Sent: Friday, February 8, 2019 5:45 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
dri-
de...@lists.freedesktop.org; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, February 5, 2019 10:02 PM
To: Shankar, Uma
Cc: intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
property
On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like
601, 709, BT2020 etc. This helps to switch based on content
type which is to be displayed. The decision lies with
compositors as to in which scenarios, a particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut
colorspaces like
BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to
the one supported. Sink supported colorspaces should be
retrieved by userspace from EDID and driver will not explicitly
expose
them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported
colorspaces.
Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the
colorspace is not chosen by user, suggested by Ville and
Maarten. Addressed other misc review comments from Maarten.
Split the changes to have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated
HDMI and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian
Starkey's suggestion in order to go with string matching at userspace.
Updated the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and
Daniel Stone's comments and moved to drm include file. Moved
back to older design with exposing all HDMI colorspaces to
userspace since infoframe capability is there even on legacy
platforms, as per Ville's review comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro
naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78
+++
include/drm/drm_connector.h | 50 +
3 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb =
drm_framebuffer_lookup(dev,
NULL, val);
int ret =
drm_atomic_set_writeback_fb_for_connector(state,
fb); @@
-814,6 +816,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
Regards Shashank > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Shankar, Uma > Sent: Friday, February 8, 2019 5:45 PM > To: Ville Syrjälä > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > ; dri- > de...@lists.freedesktop.org; Lankhorst, Maarten > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > > >> >> >-Original Message- > >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> >> >Sent: Tuesday, February 5, 2019 10:02 PM > >> >> >To: Shankar, Uma > >> >> >Cc: intel-gfx@lists.freedesktop.org; > >> >> >dri-de...@lists.freedesktop.org; Syrjala, Ville > >> >> >; Lankhorst, Maarten > >> >> > > >> >> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > >> >> >property > >> >> > > >> >> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: > >> >> >> Create a new connector property to program colorspace to sink > >> >> >> devices. > >> >> >> Modern sink devices support more than 1 type of colorspace like > >> >> >> 601, 709, BT2020 etc. This helps to switch based on content > >> >> >> type which is to be displayed. The decision lies with > >> >> >> compositors as to in which scenarios, a particular colorspace will > >> >> >> be picked. > >> >> >> > >> >> >> This will be helpful mostly to switch to higher gamut > >> >> >> colorspaces like > >> >> >> BT2020 when the media content is encoded as BT2020. Thereby > >> >> >> giving a good visual experience to users. > >> >> >> > >> >> >> The expectation from userspace is that it should parse the EDID > >> >> >> and get supported colorspaces. Use this property and switch to > >> >> >> the one supported. Sink supported colorspaces should be > >> >> >> retrieved by userspace from EDID and driver will not explicitly > >> >> >> expose > >them. > >> >> >> > >> >> >> Basically the expectation from userspace is: > >> >> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > >> >> >>colorspace > >> >> >> - Set this new property to let the sink know what it > >> >> >>converted the CRTC output to. > >> >> >> > >> >> >> v2: Addressed Maarten and Ville's review comments. Enhanced the > >> >> >> colorspace enum to incorporate both HDMI and DP supported > >colorspaces. > >> >> >> Also, added a default option for colorspace. > >> >> >> > >> >> >> v3: Removed Adobe references from enum definitions as per > >> >> >> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed > >> >> >> Default to an unset state where driver will assign the > >> >> >> colorspace is not chosen by user, suggested by Ville and > >> >> >> Maarten. Addressed other misc review comments from Maarten. > >> >> >> Split the changes to have separate colorspace property for DP and > >> >> >> HDMI. > >> >> >> > >> >> >> v4: Addressed Chris and Ville's review comments, and created a > >> >> >> common colorspace property for DP and HDMI, filtered the list > >> >> >> based on the colorspaces supported by the respective protocol > >> >> >> standard. > >> >> >> > >> >> >> v5: Made the property creation helper accept enum list based on > >> >> >> platform capabilties as suggested by Shashank. Consolidated > >> >> >> HDMI and DP property creation in the common helper. > >> >> >> > >> >> >> v6: Addressed Shashank's review comments. > >> >> >> > >> >> >> v7: Added defines instead of enum in uapi as per Brian > >> >> >> Starkey's suggestion in order to go with string matching at > >> >> >> userspace. > >> >> >> Updated the commit message to add more details as well kernel docs. > >> >> >> > >> >> >> v8: Addressed Maarten's review comments. > >> >> >> > >> >> >> v9: Removed macro defines from uapi as per Brian Starkey and > >> >> >> Daniel Stone's comments and moved to drm include file. Moved > >> >> >> back to older design with exposing all HDMI colorspaces to > >> >> >> userspace since infoframe capability is there even on legacy > >> >> >> platforms, as per Ville's review comments. > >> >> >> > >> >> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's > >> >> >> ack. > >> >> >> > >> >> >> v11: Addressed Ville's review comments. Updated the Macro > >> >> >> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. > >> >> >> > >> >> >> Signed-off-by: Uma Shankar > >> >> >> Acked-by: Jani Nikula > >> >> >> Reviewed-by: Shashank Sharma > >> >> >> Reviewed-by: Maarten Lankhorst > >> >> >> > >> >> >> --- > >> >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > >> >> >> drivers/gpu/drm/drm_connector.c | 78 > >> >> >+++ > >> >> >> include/drm/drm_connector.h | 50 + > >> >> >> 3 files changed, 132 insertions(+) > >> >> >> > >> >> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c > >> >> >> b/drivers/gpu/drm/drm_atomic_uapi.c > >> >> >> index 9a1f41a..9b5d44f 100644 > >> >> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c > >> >> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c > >>
