Re: [Intel-gfx] [PATCH 22/22] drm/i915: BDW: Pipe level CSC correction
Regards
Shashank
On 10/10/2015 5:24 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 7 ++
drivers/gpu/drm/i915/intel_color_manager.c | 114 -
drivers/gpu/drm/i915/intel_color_manager.h | 12 ++-
3 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ed50f75..0e9d252 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+ (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e659382..0a6c00c 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
}
-static s16 chv_prepare_csc_coeff(s64 csc_value)
As mentioned previously, this should be part of the respective patch.
Agree. Looks like diff is messing up a bit. Will take care of this.
+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+ uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+ int32_t mantissa;
+ uint64_t abs_coeff;
+
+ coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+ coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+ abs_coeff = abs(coeff);
+ if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+ /* abs_coeff < 0.125 */
+ exponent_bits = 3;
+ ls_bit_pos = 19;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+ /* abs_coeff >= 0.125 && val < 0.25 */
+ exponent_bits = 2;
+ ls_bit_pos = 20;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+ && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+ /* abs_coeff >= 0.25 && val < 0.5 */
+ exponent_bits = 1;
+ ls_bit_pos = 21;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+ && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+ /* abs_coeff >= 0.5 && val < 1.0 */
+ exponent_bits = 0;
+ ls_bit_pos = 22;
+ } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+ /* abs_coeff >= 1.0 && val < 2.0 */
+ exponent_bits = 7;
+ ls_bit_pos = 23;
+ } else {
+ /* abs_coeff >= 2.0 && val < 4.0 */
+ exponent_bits = 6;
+ ls_bit_pos = 24;
+ }
+
+ mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
+ if (coeff < 0) {
+ sign_bit = 1;
+ mantissa = -mantissa;
+ mantissa &= ((1 << CSC_MAX_VALS) - 1);
I think there is a macro for this already ?
Thats for GAMMA_MAX, not for CSC_MAX. Or you mean the whole (1 <<
CSC_MAX_VALS -1) to be replaced with GET/SET bits ?
+ }
+
+ reg_val = 0;
+ SET_BITS(reg_val, exponent_bits, 12, 3);
+ SET_BITS(reg_val, mantissa, 3, 9);
+ SET_BITS(reg_val, sign_bit, 15, 1);
+ DRM_DEBUG_DRIVER("CSC: reg_val=0x%x\n", reg_val);
+ return reg_val;
+}
+
+int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
The function should be static ?
Agree.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/22] drm/i915: BDW: Pipe level degamma correction
Regards
Shashank
On 10/10/2015 5:19 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 59 ++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 74f8fc3..e659382 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -273,6 +273,63 @@ static int bdw_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
return 0;
}
+static int bdw_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ int num_samples, length;
+ u32 index, mode;
+ u32 pal_prec_index, pal_prec_data;
+ struct drm_palette *degamma_data;
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+
+ if (num_samples == GAMMA_DISABLE_VALS) {
+ /* Disable degamma on Pipe */
+ mode = I915_READ(GAMMA_MODE(pipe)) & ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_8BIT);
+
+ state->palette_before_ctm_blob = NULL;
+ DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
+ pipe_name(pipe));
+ return 0;
+ }
+
+ if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
+ DRM_ERROR("Invalid number of samples\n");
+ return -EINVAL;
+ }
+
Why don't you use switch statement here ?
Same as CHV degamma. Degamma has only 3 conditions (enable/disable and
invalid), and we generally try to accommodate upto 3 condition within if
... else.
+ length = num_samples * sizeof(struct drm_r32g32b32);
+ mode = I915_READ(GAMMA_MODE(pipe));
+ pal_prec_index = _PREC_PAL_INDEX(pipe);
+ pal_prec_data = _PREC_PAL_DATA(pipe);
+
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ index = I915_READ(pal_prec_index);
+ index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+ I915_WRITE(pal_prec_index, index);
+
+ bdw_write_10bit_gamma_precision(dev, correction_values,
+ pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
+
+ /* Enable DeGamma on Pipe */
+ mode &= ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+ DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
Indentation seems funny here.
Yeah, every time time we try to publish a success story, pipe_name()
ruins it :). Will fix it.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/22] drm/i915: Attach color properties to CRTC
Regards Shashank On 10/10/2015 5:15 AM, Emil Velikov wrote: On 9 October 2015 at 20:29, Shashank Sharma wrote: Function intel_attach_color_properties_to_crtc attaches a color property to its CRTC object. This patch calls this function from crtc initialization sequence. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi Maybe squash this with patch 10, following the pattern set by other patches ? As explained in the previous patch, attaching the property is like enabling the framework. It was Matt's comment to do it, only when atleast one platform is ready. That's why we added this patch after CHV implementation is completed. Regards, Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/22] drm/i915: CHV: Pipe level CSC correction
Regards
Shashank
On 10/10/2015 5:13 AM, Emil Velikov wrote:
On 9 October 2015 at 20:29, Shashank Sharma wrote:
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 8 +++
drivers/gpu/drm/i915/intel_color_manager.c | 94 ++
drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
3 files changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c32e35d..5825ab2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
#define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index bbfe185..433e50a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,93 @@
#include "intel_color_manager.h"
+static s16 chv_prepare_csc_coeff(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s16 csc_s3_12_format;
The type of csc_s3_12_format and chv_prepare_csc_coeff() does not see
correct. Seem like the fix got merged into another patch :\
Can you please elaborate this comment, I dont get it.
[snip]
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 reg;
+ enum pipe pipe;
+ s32 word = 0, temp;
+ int count = 0;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+
+ /* Disable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+ DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+ pipe_name(pipe));
+
+ reg = _PIPE_CSC_BASE(pipe);
+ while (count < CSC_MAX_VALS) {
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+
+ /*
+* Last value to be written in 1 register.
+* Otherwise, each pair of CSC values go
+* into 1 register
+*/
+ if (count != (CSC_MAX_VALS - 1)) {
+ count++;
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+ }
This looks a bit odd. Use the same approach as in
bdw_write_12bit_gamma_precision() ?
Again, can you please give little more details here ?
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction
Regards
Shashank
On 10/10/2015 5:09 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index d5315b2..74f8fc3 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -26,6 +26,252 @@
*/
#include "intel_color_manager.h"
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+ struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+ u32 no_of_coeff)
+{
+ u16 blue_fract, green_fract, red_fract;
+ u32 word = 0;
+ u32 count = 0;
+ u32 blue, green, red;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ while (count < no_of_coeff) {
Use for loop ? Here and through the rest of the patch.
Nah, I will prefer while().
[snip]
+void bdw_write_12bit_gamma_precision(struct drm_device *dev,
+ struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+ enum pipe pipe)
+{
Make the function static ?
Agree.
[snip]
+static int bdw_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
+ struct drm_crtc *crtc)
+{
+ u16 blue_fract, green_fract, red_fract;
+ enum pipe pipe;
+ int count, num_samples;
+ u32 blue, green, red;
+ u32 mode, pal_prec_index, pal_prec_data;
+ u32 index;
+ u32 word = 0;
+ struct drm_palette *gamma_data;
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ gamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+
+ pal_prec_index = _PREC_PAL_INDEX(pipe);
+ pal_prec_data = _PREC_PAL_DATA(pipe);
+
+ correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
+ index = I915_READ(pal_prec_index);
+
+ switch (num_samples) {
+ case GAMMA_DISABLE_VALS:
+
+ /* Disable Gamma functionality on Pipe */
Drop the extra newline between the case and the comment ? Here and below.
I was trying to make it look good :(
[snip]
+ mode = I915_READ(GAMMA_MODE(pipe));
+ mode &= ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | word);
+ DRM_DEBUG_DRIVER("Gamma applied on pipe %c\n",
+ pipe_name(pipe));
Indentation seems off here.
Agree.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/22] drm/i915: Commit color correction to CRTC
Regards
Shashank
On 10/10/2015 4:54 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 44 ++
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 433e50a..d5315b2 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
return ret;
}
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state)
+{
+ struct drm_property_blob *blob;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ int ret = -EINVAL;
Most places/people advise against pre-emptively initializing ret.
Just in this case, if makes sense to keep one, coz there might be
multiple blobs which we are applying in the commit action, and every
blob can return error, from the core function.
Assume that there is a situation where both palette_after_ctm(gamma) and
CTM is in place, then we will be going through multiple if() cases and
have to check the return values.
+
+ blob = crtc_state->palette_after_ctm_blob;
+ if (blob) {
+ /* Gamma correction is platform specific */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_gamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set Gamma correction failed\n");
Do we really want to spam dmesg on for each non Cherryview device ?
If you see the complete implementation, as IS_GEN8()/IS_SKL is coming up
here after IS_CHV(patch 19,20,21) which will cover BDW/SKL/BXT. Anything
else which comes here, deserves a DRM_ERROR() as this platform will not
be supported.
+ else
+ DRM_DEBUG_DRIVER("Gamma correction success\n");
+ }
+
+ blob = crtc_state->palette_before_ctm_blob;
+ if (blob) {
+ /* Degamma correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_degamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set degamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("degamma correction success\n");
+ }
+
+ blob = crtc_state->ctm_blob;
+ if (blob) {
+ /* CSC correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_csc(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set CSC correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("CSC correction success\n");
+ }
+}
+
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 98cc97a..8235341 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13528,6 +13528,8 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+ intel_color_manager_crtc_commit(dev, crtc->state);
}
static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ed66a4f..d100e81 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1469,4 +1469,7 @@ void intel_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
+/* intel_color_mnager.c */
Typo -> manager.
Oops, thanks.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/22] drm/i915: CHV: Pipe level degamma correction
Regards
Shashank
On 10/10/2015 4:41 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2. Add DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 6 ++
drivers/gpu/drm/i915/intel_color_manager.c | 93 ++
drivers/gpu/drm/i915/intel_color_manager.h | 5 ++
3 files changed, 104 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 885ac8a..c32e35d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8050,4 +8050,10 @@ enum skl_disp_power_wells {
#define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index cf381b8..bbfe185 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,93 @@
#include "intel_color_manager.h"
+static int chv_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue;
+ u32 num_samples;
+ u32 word = 0;
+ u32 count = 0;
+ u32 cgm_control_reg = 0;
+ u32 cgm_degamma_reg = 0;
+ int length;
+ int ret = 0;
+ enum pipe pipe;
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
Most of the above initializations can go.
Agree.
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
This can overflow.
Agree
+
+ if (num_samples == GAMMA_DISABLE_VALS) {
You've opted for switch statements in other patches. Why the if else
ladder in here ?
As a general programming rule, we tend to switch to switch, when no of
if-else conditions is > 3, here its just 3, enable/disable/invalid so
kept as if/else condition for simpler code.
+ /* Disable DeGamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_DEGAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+ DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
Drop the ret variable through the function ?
Agree
+ } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
+ cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+
+ count = 0;
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ while (count < CHV_DEGAMMA_MAX_VALS) {
For loop ?
Will pass, prefer while.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
Regards
Shashank
On 10/10/2015 4:37 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++
drivers/gpu/drm/i915/intel_color_manager.c | 114 +
drivers/gpu/drm/i915/intel_color_manager.h | 13
3 files changed, 139 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 60e6a73..885ac8a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8038,4 +8038,16 @@ enum skl_disp_power_wells {
#define GEN9_VEBOX_MOCS_0 0xcb00 /* Video MOCS base register*/
#define GEN9_BLT_MOCS_00xcc00 /* Blitter MOCS base register*/
+/* Color Management */
+#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e466748..cf381b8 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,112 @@
#include "intel_color_manager.h"
+static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
+ struct drm_crtc *crtc)
+{
+ bool flag = false;
+ enum pipe pipe;
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue, num_samples;
+ u32 word = 0;
+ u32 count = 0;
+ u32 cgm_gamma_reg = 0;
+ u32 cgm_control_reg = 0;
+ int ret = 0, length;
+ struct drm_r32g32b32 *correction_values = NULL;
You can drop the useless initialization of correction_values. Same
goes for patches 19 and 21.
Agree, thanks for pointing it out.
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ gamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
Calculation can overflow.
good catch, will take care of this.
+
+ switch (num_samples) {
+ case GAMMA_DISABLE_VALS:
+
+ /* Disable Gamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_GAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+ pipe_name(pipe));
Indentation looks wrong here.
Oops, bloody SI :).
+ ret = 0;
Drop the variable and return 0, at the bottom of the function ?
Let me check this out.
+ break;
+
+ case CHV_8BIT_GAMMA_MAX_VALS:
+ case CHV_10BIT_GAMMA_MAX_VALS:
+
+ count = 0;
+ cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+ correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
+
+ while (count < num_samples) {
Using for(i = 0;) loop seems the more common approach ?
Nah, we are good with while. The whole color management series prefers
while (and me too :))
[snip]
+ /*
+ * On CHV, the best supported Gamma capability is
+ * CGM block, that takes 257 samples.
+ * If user gives 256 samples (legacy mode), then
+ * duplicate the 256th value to 257th.
+ * "flag" is used to make sure it happens only once
+ */
+ if (num_samples == CHV_8BIT_GAMMA_MAX_VALS &&
+ count == CHV_8BIT_GAMMA_MAX_VALS && !flag) {
+ count--;
+ flag = true;
+ }
There is little point in going over this if statement 256 odd times.
Split it out o
Re: [Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities
Regards
Shashank
On 10/10/2015 3:51 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get applied
beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
after color transformation matrix correction.
These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
(CTM is fix to 9 coefficients across industry)
Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.
So finally, This patch does the following:
1. Add a function which loads the platform's color correction
capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
"num_samples_before_ctm" in intel_device_info as gamma and
degamma coefficients vary per platform basis.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_color_manager.c | 33 +-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad37b25..8bf1d6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -798,6 +798,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+ u16 num_samples_after_ctm;
+ u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..e466748 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -28,6 +28,37 @@
#include "intel_color_manager.h"
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
- struct drm_mode_object *mode_obj)
+ struct drm_crtc *crtc)
{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_mode_object *mode_obj = &crtc->base;
+
+ /*
+* Register:
+* =
+* Gamma correction as palette_after_ctm property
+* Degamma correction as palette_before_ctm property
+*
+* Load:
+* =
+* no. of coefficients supported on this platform for gamma
+* and degamma with the query properties. A user
+* space agent should read these query property, and prepare
+* the color correction values accordingly. Its expected from the
+* driver to load the right number of coefficients during the init
+* phase.
+*/
+ if (config->cm_coeff_after_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_after_ctm_property,
+ INTEL_INFO(dev)->num_samples_after_ctm);
+ DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+ }
+
+ if (config->cm_coeff_before_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_before_ctm_property,
+ INTEL_INFO(dev)->num_samples_before_ctm);
+ DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+ }
Shouldn't this commit be squashed with the previous ? You're also
missing the function declaration.
Please see the history of the review comments, initially this patch was
like as you suggested. But one of the previous review comments,
suggested to split that into two, as it was 'overdoing' stuff. So I had
split it into two separate ones, so I think this is ok :)
Also, one of the previous review comments was to call this function only
when the whole framework is in place, so that it would look like we are
enabling, when we have stuff ready. So this is just the body of the
function, an
Re: [Intel-gfx] [PATCH 09/22] drm/i915: Create color management files
Regards
Shashank
On 10/10/2015 4:17 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
[snip]
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+ ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+ x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */
+#define SET_BITS(target, bit_pattern, start_bit, no_bits) \
+ do { \
+ CLEAR_BITS(target, start_bit, no_bits); \
+ target |= (bit_pattern << start_bit); \
+ } while (0)
It feels suspicious that the kernel does not have macros for either
one of these.
I would invite you to take a look at include/linux/bitops.h and other
kernel headers.
Thanks for pointing this out, but if you closely observe, these macros
are well tested, and created for color management operations, which have
specific requirements, like:
- pick 8 bits from 16th bit onwards, make them LSB, and give result:
GET_BITS
- take these 8 bits and move to bit 17th of the word, clearing the
existing ones: SET_BITS
For core register programming, this was required, so we created it. I
would still have a look
at the existing ones which you pointed out to avoid any duplication, if
they fall directly in the implementation, else I would like to continue
with these.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/22] drm: Add set property support for color manager
Regards Shashank On 10/10/2015 3:55 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: As per DRM color manager design, if a userspace wants to set a correction blob, it prepares it and sends the blob_id to kernel via set_property call. DRM framework takes this blob_id, gets the blob, and saves it in the CRTC state, so that, during the atomic_commit, the color correction values from the blob can referred and applied on display controller registers. This patch adds this set_property support for color correction blobs in drm framework. Signed-off-by: Shashank Sharma Signed-off-by: Kausal malladi --- drivers/gpu/drm/drm_atomic.c | 53 ++-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 7bb3845..0b286d2 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state, EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc); /** + * drm_atomic_crtc_set_blob - find and set a blob + * @state_blob: reference pointer to the color blob in the crtc_state + * @blob_id: blob_id coming from set_property() call + * + * Set a color correction blob (originating from a set blob property) on the + * desired CRTC state. This function will take reference of the blob property + * in the CRTC state, finds the blob based on blob_id (which comes from + * set_property call) and set the blob at the proper place. + * + * RETURNS: + * Zero on success, error code on failure. + */ +int drm_atomic_crtc_set_blob(struct drm_device *dev, + struct drm_property_blob **state_blob, uint32_t blob_id) You are missing the function declaration. Set it as static perhaps ? Yes, This was meant to be used internally, I can make it static. Regards, Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/22] drm: Add color correction blobs in CRTC state
Thanks for the review comments, Emil.
Regards
Shashank
On 10/10/2015 3:53 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_atomic_helper.c | 12
include/drm/drm_crtc.h | 7 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 87a2a44..d73ca9b9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2193,6 +2193,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_reference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_reference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2238,6 +2244,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc *crtc,
{
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_unreference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_unreference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_unreference_blob(state->palette_before_ctm_blob);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6e0f177..9cd4123 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -302,6 +302,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
+ /* blob properties to hold the color properties' blobs */
+ struct drm_property_blob *palette_before_ctm_blob;
+ struct drm_property_blob *palette_after_ctm_blob;
+ struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
struct drm_atomic_state *state;
@@ -1151,7 +1156,7 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;
- /* Coor management capabilities query */
+ /* Color management capabilities query */
This should be part of the previous patch.
Agree, will do it.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] igt/kms_addfb_basic: New subtest to check for fb modifier and tiling mode mismatch
Hi Tvrtko,
On Fri, 9 Oct 2015 09:34:25 +0100
Tvrtko Ursulin wrote:
>
>
> On 08/10/15 09:55, Tvrtko Ursulin wrote:
> > On 07/10/15 22:07, Vivek Kasireddy wrote:
> >>
> >> Hi Tvrtko,
> >>
> >> On Wed, 7 Oct 2015 15:07:30 +0100
> >> Tvrtko Ursulin wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> On 07/10/15 03:35, Vivek Kasireddy wrote:
> This new subtest will validate a Y-tiled object's tiling mode
> against its associated fb modifier.
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Vivek Kasireddy
> ---
> tests/kms_addfb_basic.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
> index d466e4d..7ca1add 100644
> --- a/tests/kms_addfb_basic.c
> +++ b/tests/kms_addfb_basic.c
> @@ -373,6 +373,15 @@ static void addfb25_ytile(int fd, int gen)
> f.handles[0] = gem_bo;
> }
>
> +igt_subtest("addfb25-Y-tiled-X-modifier-mismatch") {
> +igt_require(gen >= 9);
> +igt_require_fb_modifiers(fd);
> +gem_set_tiling(fd, gem_bo, I915_TILING_Y, 1024*4);
> +
> +f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
> +igt_assert(drmIoctl(fd,
> LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) < 0 && errno == EINVAL);
> +}
> +
> igt_subtest("addfb25-Y-tiled") {
> igt_require_fb_modifiers(fd);
>
> >>>
> >>> Wasn't the original WARN triggered by Y tiled object and Y fb
> >>> modifier?
> >>
> >> Creating a new fb using a Y-tiled object and Y/X fb modifier will
> >> not trigger the original WARN. It'll be triggered only if the fb
> >> is going to be pinned -- and flipped. I am not sure how to get
> >> that WARN to be triggered with the existing suite of igt tests.
> >
> > Ah yes, you would need to attempt display it, not even necessarily
> > flip it. I am sure there are tests which do that. :) I know from
> > recent activity kms_rotation_crc for example creates a Y tiled FB
> > and displays it. So maybe borrow some code to start with from there.
>
> Even better, kms_flip_tiling does the majority of what is needed here
> already. Just drop in a subtest which will do set_tiling and that
> should be good.
Thank you for your suggestion. I am currently having problems with my
hardware. After resolving these, I'll look into kms_flip_tiling and
send out a patch soon.
Thanks and Regards,
Vivek
>
> Regards,
>
> Tvrtko
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.
Hi Rafael,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
ignore]
config: mn10300-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mn10300
All warnings (new ones prefixed by >>):
In file included from include/linux/list.h:8:0,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from drivers/gpu/drm/drm_dp_aux_dev.c:28:
drivers/gpu/drm/drm_dp_aux_dev.c: In function 'auxdev_read':
include/linux/kernel.h:722:17: warning: comparison of distinct pointer types
lacks a cast
(void) (&_min1 == &_min2); \
^
>> drivers/gpu/drm/drm_dp_aux_dev.c:180:18: note: in expansion of macro 'min'
ssize_t todo = min(bytes_pending, sizeof(localbuf));
^
drivers/gpu/drm/drm_dp_aux_dev.c: In function 'auxdev_write':
include/linux/kernel.h:722:17: warning: comparison of distinct pointer types
lacks a cast
(void) (&_min1 == &_min2); \
^
drivers/gpu/drm/drm_dp_aux_dev.c:220:18: note: in expansion of macro 'min'
ssize_t todo = min(bytes_pending, sizeof(localbuf));
^
vim +/min +180 drivers/gpu/drm/drm_dp_aux_dev.c
22 *
23 * Authors:
24 *Rafael Antognolli
25 *
26 */
27
> 28 #include
29 #include
30 #include
31 #include
32 #include
33 #include
34 #include
35 #include
36 #include
37
38 struct drm_dp_aux_dev {
39 unsigned index;
40 struct drm_dp_aux *aux;
41 struct device *dev;
42 struct kref refcount;
43 bool removed;
44 spinlock_t removed_lock;
45 };
46
47 #define DRM_AUX_MINORS 256
48 #define AUX_MAX_OFFSET (1 << 20)
49 static DEFINE_IDR(aux_idr);
50 static DEFINE_SPINLOCK(aux_idr_lock);
51 static struct class *drm_dp_aux_dev_class;
52 static int drm_dev_major = -1;
53
54 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
index)
55 {
56 struct drm_dp_aux_dev *aux_dev = NULL;
57
58 spin_lock(&aux_idr_lock);
59 aux_dev = idr_find(&aux_idr, index);
60 if (!kref_get_unless_zero(&aux_dev->refcount))
61 aux_dev = NULL;
62 spin_unlock(&aux_idr_lock);
63
64 return aux_dev;
65 }
66
67 static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct drm_dp_aux
*aux)
68 {
69 struct drm_dp_aux_dev *aux_dev;
70 int index;
71
72
73 aux_dev = kzalloc(sizeof(*aux_dev), GFP_KERNEL);
74 if (!aux_dev)
75 return ERR_PTR(-ENOMEM);
76 aux_dev->aux = aux;
77 aux_dev->removed = false;
78 spin_lock_init(&aux_dev->removed_lock);
79 kref_init(&aux_dev->refcount);
80
81 idr_preload(GFP_KERNEL);
82 spin_lock(&aux_idr_lock);
83 index = idr_alloc_cyclic(&aux_idr, aux_dev, 0, DRM_AUX_MINORS,
84 GFP_NOWAIT);
85 spin_unlock(&aux_idr_lock);
86 idr_preload_end();
87 if (index < 0) {
88 kfree(aux_dev);
89 return ERR_PTR(-ENOMEM);
90 }
91 aux_dev->index = index;
92
93 return aux_dev;
94 }
95
96 static void free_drm_dp_aux_dev(struct drm_dp_aux_dev *aux_dev)
97 {
98 spin_lock(&aux_idr_lock);
99 idr_remove(&aux_idr, aux_dev->index);
100 spin_unlock(&aux_idr_lock);
101 kfree(aux_dev);
102 }
103
104 static void release_drm_dp_aux_dev(struct kref *ref)
105 {
106 int minor;
107 struct drm_dp_aux_dev *aux_dev =
108 container_of(ref, struct drm_dp_aux_dev, refcount);
109 minor = aux_dev->index;
110 device_destroy(drm_dp_aux_dev_class, MKDEV(drm_dev_major,
minor));
111
112 free_drm_dp_aux_dev(aux_dev);
113 }
114
115 static ssize_t name_show(struct device *dev,
116 struct device_attribute *attr, char *buf)
117 {
118 ssize_t res;
119 struct drm_dp_aux_dev *aux_dev =
120 drm_dp_aux_dev_get_by_minor(MINOR(dev->devt));
121
122 if (!aux_dev)
123 return -ENODEV;
124
125 res = sprintf(buf, "%s\n", aux_dev->aux->name);
126 kref_put(&aux_dev->refcount, release_drm_dp_aux_dev);
127
128
Re: [Intel-gfx] [PATCH 22/22] drm/i915: BDW: Pipe level CSC correction
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
> that needs to be programmed into respective CSC registers.
>
> This patch does the following:
> 1. Adds the core function to program CSC correction values for
>BDW/SKL/BXT platform
> 2. Adds CSC correction macros/defines
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> Signed-off-by: Kumar, Kiran S
> ---
> drivers/gpu/drm/i915/i915_reg.h| 7 ++
> drivers/gpu/drm/i915/intel_color_manager.c | 114
> -
> drivers/gpu/drm/i915/intel_color_manager.h | 12 ++-
> 3 files changed, 129 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ed50f75..0e9d252 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
> (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
>
>
> +/* BDW CSC correction */
> +#define CSC_COEFF_A0x49010
> +#define CSC_COEFF_B0x49110
> +#define CSC_COEFF_C0x49210
> +#define _PIPE_CSC_COEFF(pipe) \
> + (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
> +
> #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index e659382..0a6c00c 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
> return 0;
> }
>
> -static s16 chv_prepare_csc_coeff(s64 csc_value)
As mentioned previously, this should be part of the respective patch.
> +static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
> +{
> + uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
> + int32_t mantissa;
> + uint64_t abs_coeff;
> +
> + coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
> + coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
> +
> + abs_coeff = abs(coeff);
> + if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
> + /* abs_coeff < 0.125 */
> + exponent_bits = 3;
> + ls_bit_pos = 19;
> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
> + abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
> + /* abs_coeff >= 0.125 && val < 0.25 */
> + exponent_bits = 2;
> + ls_bit_pos = 20;
> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
> + && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
> + /* abs_coeff >= 0.25 && val < 0.5 */
> + exponent_bits = 1;
> + ls_bit_pos = 21;
> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
> + && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
> + /* abs_coeff >= 0.5 && val < 1.0 */
> + exponent_bits = 0;
> + ls_bit_pos = 22;
> + } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
> + abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
> + /* abs_coeff >= 1.0 && val < 2.0 */
> + exponent_bits = 7;
> + ls_bit_pos = 23;
> + } else {
> + /* abs_coeff >= 2.0 && val < 4.0 */
> + exponent_bits = 6;
> + ls_bit_pos = 24;
> + }
> +
> + mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
> + if (coeff < 0) {
> + sign_bit = 1;
> + mantissa = -mantissa;
> + mantissa &= ((1 << CSC_MAX_VALS) - 1);
I think there is a macro for this already ?
> + }
> +
> + reg_val = 0;
> + SET_BITS(reg_val, exponent_bits, 12, 3);
> + SET_BITS(reg_val, mantissa, 3, 9);
> + SET_BITS(reg_val, sign_bit, 15, 1);
> + DRM_DEBUG_DRIVER("CSC: reg_val=0x%x\n", reg_val);
> + return reg_val;
> +}
> +
> +int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
> + struct drm_crtc *crtc)
> +{
The function should be static ?
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/22] drm/i915: BDW: Pipe level degamma correction
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> BDW/SKL/BXT supports Degamma color correction feature, which
> linearizes the non-linearity due to gamma encoded color values.
> This will be applied before Color Transformation.
>
> This patch does the following:
> 1. Adds the core function to program DeGamma correction values for
>BDW/SKL/BXT platform
> 2. Adds DeGamma correction macros/defines
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/intel_color_manager.c | 59
> ++
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 74f8fc3..e659382 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -273,6 +273,63 @@ static int bdw_set_gamma(struct drm_device *dev, struct
> drm_property_blob *blob,
> return 0;
> }
>
> +static int bdw_set_degamma(struct drm_device *dev,
> + struct drm_property_blob *blob, struct drm_crtc *crtc)
> +{
> + enum pipe pipe;
> + int num_samples, length;
> + u32 index, mode;
> + u32 pal_prec_index, pal_prec_data;
> + struct drm_palette *degamma_data;
> + struct drm_crtc_state *state = crtc->state;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_r32g32b32 *correction_values = NULL;
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + degamma_data = (struct drm_palette *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> + num_samples = degamma_data->num_samples;
> +
> + if (num_samples == GAMMA_DISABLE_VALS) {
> + /* Disable degamma on Pipe */
> + mode = I915_READ(GAMMA_MODE(pipe)) & ~GAMMA_MODE_MODE_MASK;
> + I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_8BIT);
> +
> + state->palette_before_ctm_blob = NULL;
> + DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
> + pipe_name(pipe));
> + return 0;
> + }
> +
> + if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
> + DRM_ERROR("Invalid number of samples\n");
> + return -EINVAL;
> + }
> +
Why don't you use switch statement here ?
> + length = num_samples * sizeof(struct drm_r32g32b32);
> + mode = I915_READ(GAMMA_MODE(pipe));
> + pal_prec_index = _PREC_PAL_INDEX(pipe);
> + pal_prec_data = _PREC_PAL_DATA(pipe);
> +
> + correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
> + index = I915_READ(pal_prec_index);
> + index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
> + I915_WRITE(pal_prec_index, index);
> +
> + bdw_write_10bit_gamma_precision(dev, correction_values,
> + pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
> +
> + /* Enable DeGamma on Pipe */
> + mode &= ~GAMMA_MODE_MODE_MASK;
> + I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
> + DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
> + pipe_name(pipe));
Indentation seems funny here.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/22] drm/i915: Attach color properties to CRTC
On 9 October 2015 at 20:29, Shashank Sharma wrote: > Function intel_attach_color_properties_to_crtc attaches a > color property to its CRTC object. This patch calls this > function from crtc initialization sequence. > > Signed-off-by: Shashank Sharma > Signed-off-by: Kausal Malladi Maybe squash this with patch 10, following the pattern set by other patches ? Regards, Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/22] drm/i915: CHV: Pipe level CSC correction
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
> that needs to be programmed into CGM (Color Gamut Mapping) registers.
>
> This patch does the following:
> 1. Attaches CSC property to CRTC
> 2. Adds the core function to program CSC correction values
> 3. Adds CSC correction macros
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> Signed-off-by: Kumar, Kiran S
> ---
> drivers/gpu/drm/i915/i915_reg.h| 8 +++
> drivers/gpu/drm/i915/intel_color_manager.c | 94
> ++
> drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
> 3 files changed, 121 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c32e35d..5825ab2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
> #define _PIPE_DEGAMMA_BASE(pipe) \
> (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
> PIPEC_CGM_DEGAMMA))
>
> +#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
> +#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
> +#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
> +#define _PIPE_CSC_BASE(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
> +
> +
> +
> #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index bbfe185..433e50a 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -27,6 +27,93 @@
>
> #include "intel_color_manager.h"
>
> +static s16 chv_prepare_csc_coeff(s64 csc_value)
> +{
> + s32 csc_int_value;
> + u32 csc_fract_value;
> + s16 csc_s3_12_format;
The type of csc_s3_12_format and chv_prepare_csc_coeff() does not see
correct. Seem like the fix got merged into another patch :\
[snip]
> +static int chv_set_csc(struct drm_device *dev, struct drm_property_blob
> *blob,
> + struct drm_crtc *crtc)
> +{
> + struct drm_ctm *csc_data;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 reg;
> + enum pipe pipe;
> + s32 word = 0, temp;
> + int count = 0;
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + if (blob->length != sizeof(struct drm_ctm)) {
> + DRM_ERROR("Invalid length of data received\n");
> + return -EINVAL;
> + }
> +
> + csc_data = (struct drm_ctm *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> +
> + /* Disable CSC functionality */
> + reg = _PIPE_CGM_CONTROL(pipe);
> + I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
> +
> + DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
> + pipe_name(pipe));
> +
> + reg = _PIPE_CSC_BASE(pipe);
> + while (count < CSC_MAX_VALS) {
> + temp = chv_prepare_csc_coeff(
> + csc_data->ctm_coeff[count]);
> + SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
> +
> + /*
> +* Last value to be written in 1 register.
> +* Otherwise, each pair of CSC values go
> +* into 1 register
> +*/
> + if (count != (CSC_MAX_VALS - 1)) {
> + count++;
> + temp = chv_prepare_csc_coeff(
> + csc_data->ctm_coeff[count]);
> + SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
> + }
This looks a bit odd. Use the same approach as in
bdw_write_12bit_gamma_precision() ?
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
[snip]
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index d5315b2..74f8fc3 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -26,6 +26,252 @@
> */
>
> #include "intel_color_manager.h"
> +static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
> + struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
> + u32 no_of_coeff)
> +{
> + u16 blue_fract, green_fract, red_fract;
> + u32 word = 0;
> + u32 count = 0;
> + u32 blue, green, red;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + while (count < no_of_coeff) {
Use for loop ? Here and through the rest of the patch.
[snip]
> +void bdw_write_12bit_gamma_precision(struct drm_device *dev,
> + struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
> + enum pipe pipe)
> +{
Make the function static ?
[snip]
> +static int bdw_set_gamma(struct drm_device *dev, struct drm_property_blob
> *blob,
> + struct drm_crtc *crtc)
> +{
> + u16 blue_fract, green_fract, red_fract;
> + enum pipe pipe;
> + int count, num_samples;
> + u32 blue, green, red;
> + u32 mode, pal_prec_index, pal_prec_data;
> + u32 index;
> + u32 word = 0;
> + struct drm_palette *gamma_data;
> + struct drm_crtc_state *state = crtc->state;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_r32g32b32 *correction_values = NULL;
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + gamma_data = (struct drm_palette *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> + num_samples = gamma_data->num_samples;
> +
> + pal_prec_index = _PREC_PAL_INDEX(pipe);
> + pal_prec_data = _PREC_PAL_DATA(pipe);
> +
> + correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
> + index = I915_READ(pal_prec_index);
> +
> + switch (num_samples) {
> + case GAMMA_DISABLE_VALS:
> +
> + /* Disable Gamma functionality on Pipe */
Drop the extra newline between the case and the comment ? Here and below.
[snip]
> + mode = I915_READ(GAMMA_MODE(pipe));
> + mode &= ~GAMMA_MODE_MODE_MASK;
> + I915_WRITE(GAMMA_MODE(pipe), mode | word);
> + DRM_DEBUG_DRIVER("Gamma applied on pipe %c\n",
> + pipe_name(pipe));
Indentation seems off here.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/22] drm/i915: Commit color correction to CRTC
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> The color correction blob values are loaded during set_property
> calls. This patch adds a function to find the blob and apply the
> correction values to the display registers, during the atomic
> commit call.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/intel_color_manager.c | 44
> ++
> drivers/gpu/drm/i915/intel_display.c | 2 ++
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 433e50a..d5315b2 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev, struct
> drm_property_blob *blob,
> return ret;
> }
>
> +void intel_color_manager_crtc_commit(struct drm_device *dev,
> + struct drm_crtc_state *crtc_state)
> +{
> + struct drm_property_blob *blob;
> + struct drm_crtc *crtc = crtc_state->crtc;
> + int ret = -EINVAL;
Most places/people advise against pre-emptively initializing ret.
> +
> + blob = crtc_state->palette_after_ctm_blob;
> + if (blob) {
> + /* Gamma correction is platform specific */
> + if (IS_CHERRYVIEW(dev))
> + ret = chv_set_gamma(dev, blob, crtc);
> +
> + if (ret)
> + DRM_ERROR("set Gamma correction failed\n");
Do we really want to spam dmesg on for each non Cherryview device ?
> + else
> + DRM_DEBUG_DRIVER("Gamma correction success\n");
> + }
> +
> + blob = crtc_state->palette_before_ctm_blob;
> + if (blob) {
> + /* Degamma correction */
> + if (IS_CHERRYVIEW(dev))
> + ret = chv_set_degamma(dev, blob, crtc);
> +
> + if (ret)
> + DRM_ERROR("set degamma correction failed\n");
> + else
> + DRM_DEBUG_DRIVER("degamma correction success\n");
> + }
> +
> + blob = crtc_state->ctm_blob;
> + if (blob) {
> + /* CSC correction */
> + if (IS_CHERRYVIEW(dev))
> + ret = chv_set_csc(dev, blob, crtc);
> +
> + if (ret)
> + DRM_ERROR("set CSC correction failed\n");
> + else
> + DRM_DEBUG_DRIVER("CSC correction success\n");
> + }
> +}
> +
> void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> struct drm_crtc *crtc)
> {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 98cc97a..8235341 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13528,6 +13528,8 @@ static void intel_begin_crtc_commit(struct drm_crtc
> *crtc,
> intel_update_pipe_config(intel_crtc, old_intel_state);
> else if (INTEL_INFO(dev)->gen >= 9)
> skl_detach_scalers(intel_crtc);
> +
> + intel_color_manager_crtc_commit(dev, crtc->state);
> }
>
> static void intel_finish_crtc_commit(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index ed66a4f..d100e81 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1469,4 +1469,7 @@ void intel_plane_destroy_state(struct drm_plane *plane,
>struct drm_plane_state *state);
> extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
>
> +/* intel_color_mnager.c */
Typo -> manager.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/22] drm/i915: CHV: Pipe level degamma correction
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> CHV/BSW supports Degamma color correction, which linearizes all
> the non-linear color values. This will be applied before Color
> Transformation.
>
> This patch does the following:
> 1. Attach deGamma property to CRTC
> 2. Add the core function to program DeGamma correction values for
>CHV/BSW platform
> 2. Add DeGamma correction macros/defines
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/i915_reg.h| 6 ++
> drivers/gpu/drm/i915/intel_color_manager.c | 93
> ++
> drivers/gpu/drm/i915/intel_color_manager.h | 5 ++
> 3 files changed, 104 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 885ac8a..c32e35d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8050,4 +8050,10 @@ enum skl_disp_power_wells {
> #define _PIPE_GAMMA_BASE(pipe) \
> (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
>
> +#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
> +#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
> +#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
> +#define _PIPE_DEGAMMA_BASE(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
> PIPEC_CGM_DEGAMMA))
> +
> #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index cf381b8..bbfe185 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -27,6 +27,93 @@
>
> #include "intel_color_manager.h"
>
> +static int chv_set_degamma(struct drm_device *dev,
> + struct drm_property_blob *blob, struct drm_crtc *crtc)
> +{
> + u16 red_fract, green_fract, blue_fract;
> + u32 red, green, blue;
> + u32 num_samples;
> + u32 word = 0;
> + u32 count = 0;
> + u32 cgm_control_reg = 0;
> + u32 cgm_degamma_reg = 0;
> + int length;
> + int ret = 0;
> + enum pipe pipe;
> + struct drm_palette *degamma_data;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_r32g32b32 *correction_values = NULL;
Most of the above initializations can go.
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + degamma_data = (struct drm_palette *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> + num_samples = degamma_data->num_samples;
> + length = num_samples * sizeof(struct drm_r32g32b32);
This can overflow.
> +
> + if (num_samples == GAMMA_DISABLE_VALS) {
You've opted for switch statements in other patches. Why the if else
ladder in here ?
> + /* Disable DeGamma functionality on Pipe - CGM Block */
> + cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
> + cgm_control_reg &= ~CGM_DEGAMMA_EN;
> + I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
> + DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
> + pipe_name(pipe));
> + ret = 0;
Drop the ret variable through the function ?
> + } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
> + cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
> +
> + count = 0;
> + correction_values = (struct drm_r32g32b32
> *)°amma_data->lut;
> + while (count < CHV_DEGAMMA_MAX_VALS) {
For loop ?
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> CHV/BSW platform supports two different pipe level gamma
> correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
>
> This patch does the following:
> 1. Attaches Gamma property to CRTC
> 3. Adds the core Gamma correction function for CHV/BSW
> 4. Adds Gamma correction macros
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/i915_reg.h| 12 +++
> drivers/gpu/drm/i915/intel_color_manager.c | 114
> +
> drivers/gpu/drm/i915/intel_color_manager.h | 13
> 3 files changed, 139 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 60e6a73..885ac8a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8038,4 +8038,16 @@ enum skl_disp_power_wells {
> #define GEN9_VEBOX_MOCS_0 0xcb00 /* Video MOCS base register*/
> #define GEN9_BLT_MOCS_00xcc00 /* Blitter MOCS base
> register*/
>
> +/* Color Management */
> +#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
> +#define PIPEB_CGM_CONTROL (VLV_DISPLAY_BASE + 0x69A00)
> +#define PIPEC_CGM_CONTROL (VLV_DISPLAY_BASE + 0x6BA00)
> +#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
> +#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
> +#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
> +#define _PIPE_CGM_CONTROL(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL,
> PIPEC_CGM_CONTROL))
> +#define _PIPE_GAMMA_BASE(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
> +
> #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index e466748..cf381b8 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -27,6 +27,112 @@
>
> #include "intel_color_manager.h"
>
> +static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob
> *blob,
> + struct drm_crtc *crtc)
> +{
> + bool flag = false;
> + enum pipe pipe;
> + u16 red_fract, green_fract, blue_fract;
> + u32 red, green, blue, num_samples;
> + u32 word = 0;
> + u32 count = 0;
> + u32 cgm_gamma_reg = 0;
> + u32 cgm_control_reg = 0;
> + int ret = 0, length;
> + struct drm_r32g32b32 *correction_values = NULL;
You can drop the useless initialization of correction_values. Same
goes for patches 19 and 21.
> + struct drm_palette *gamma_data;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + if (WARN_ON(!blob))
> + return -EINVAL;
> +
> + gamma_data = (struct drm_palette *)blob->data;
> + pipe = to_intel_crtc(crtc)->pipe;
> + num_samples = gamma_data->num_samples;
> + length = num_samples * sizeof(struct drm_r32g32b32);
Calculation can overflow.
> +
> + switch (num_samples) {
> + case GAMMA_DISABLE_VALS:
> +
> + /* Disable Gamma functionality on Pipe - CGM Block */
> + cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
> + cgm_control_reg &= ~CGM_GAMMA_EN;
> + I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
> +
> + DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
> + pipe_name(pipe));
Indentation looks wrong here.
> + ret = 0;
Drop the variable and return 0, at the bottom of the function ?
> + break;
> +
> + case CHV_8BIT_GAMMA_MAX_VALS:
> + case CHV_10BIT_GAMMA_MAX_VALS:
> +
> + count = 0;
> + cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
> + correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
> +
> + while (count < num_samples) {
Using for(i = 0;) loop seems the more common approach ?
[snip]
> + /*
> + * On CHV, the best supported Gamma capability is
> + * CGM block, that takes 257 samples.
> + * If user gives 256 samples (legacy mode), then
> + * duplicate the 256th value to 257th.
> + * "flag" is used to make sure it happens only once
> + */
> + if (num_samples == CHV_8BIT_GAMMA_MAX_VALS &&
> + count == CHV_8BIT_GAMMA_MAX_VALS && !flag) {
> + count--;
> + flag = true;
> + }
There is little point in going over this if statement 256 odd times.
Split it out of the loop ?
> + }
> +
> + /* Enable (CGM) Gamma on Pipe *
Re: [Intel-gfx] [PATCH 09/22] drm/i915: Create color management files
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
[snip]
> +
> +/* Color management bit utilities */
> +#define GET_BIT_MASK(n) ((1 << n) - 1)
> +
> +/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
> +#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
> +
> +/* Round off by adding 1 to the immediate lower bit */
> +#define GET_BITS_ROUNDOFF(x, start, nbits) \
> + ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
> +
> +/* Clear bits of a word from bit no. 'start' till nbits */
> +#define CLEAR_BITS(x, start, nbits) ( \
> + x &= ~((GET_BIT_MASK(nbits) << start)))
> +
> +/* Write bit_pattern of no_bits bits in a target word */
> +#define SET_BITS(target, bit_pattern, start_bit, no_bits) \
> + do { \
> + CLEAR_BITS(target, start_bit, no_bits); \
> + target |= (bit_pattern << start_bit); \
> + } while (0)
It feels suspicious that the kernel does not have macros for either
one of these.
I would invite you to take a look at include/linux/bitops.h and other
kernel headers.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/22] drm: Add set property support for color manager
Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: > As per DRM color manager design, if a userspace wants to set a correction > blob, it prepares it and sends the blob_id to kernel via set_property > call. DRM framework takes this blob_id, gets the blob, and saves it > in the CRTC state, so that, during the atomic_commit, the color correction > values from the blob can referred and applied on display controller > registers. > > This patch adds this set_property support for color correction blobs > in drm framework. > > Signed-off-by: Shashank Sharma > Signed-off-by: Kausal malladi > --- > drivers/gpu/drm/drm_atomic.c | 53 > ++-- > 1 file changed, 51 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 7bb3845..0b286d2 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct > drm_crtc_state *state, > EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc); > > /** > + * drm_atomic_crtc_set_blob - find and set a blob > + * @state_blob: reference pointer to the color blob in the crtc_state > + * @blob_id: blob_id coming from set_property() call > + * > + * Set a color correction blob (originating from a set blob property) on the > + * desired CRTC state. This function will take reference of the blob property > + * in the CRTC state, finds the blob based on blob_id (which comes from > + * set_property call) and set the blob at the proper place. > + * > + * RETURNS: > + * Zero on success, error code on failure. > + */ > +int drm_atomic_crtc_set_blob(struct drm_device *dev, > + struct drm_property_blob **state_blob, uint32_t blob_id) You are missing the function declaration. Set it as static perhaps ? Regards, Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/22] drm: Add color correction blobs in CRTC state
Hi Shashank,
On 9 October 2015 at 20:28, Shashank Sharma wrote:
> This patch adds new variables in CRTC state, to hold respective color
> correction blobs. These blobs will be required during the atomic commit
> for writing the color correction values in correction registers.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 12
> include/drm/drm_crtc.h | 7 ++-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 87a2a44..d73ca9b9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2193,6 +2193,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc,
>
> if (state->mode_blob)
> drm_property_reference_blob(state->mode_blob);
> + if (state->ctm_blob)
> + drm_property_reference_blob(state->ctm_blob);
> + if (state->palette_after_ctm_blob)
> + drm_property_reference_blob(state->palette_after_ctm_blob);
> + if (state->palette_before_ctm_blob)
> + drm_property_reference_blob(state->palette_before_ctm_blob);
> state->mode_changed = false;
> state->active_changed = false;
> state->planes_changed = false;
> @@ -2238,6 +2244,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct
> drm_crtc *crtc,
> {
> if (state->mode_blob)
> drm_property_unreference_blob(state->mode_blob);
> + if (state->ctm_blob)
> + drm_property_unreference_blob(state->ctm_blob);
> + if (state->palette_after_ctm_blob)
> + drm_property_unreference_blob(state->palette_after_ctm_blob);
> + if (state->palette_before_ctm_blob)
> + drm_property_unreference_blob(state->palette_before_ctm_blob);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 6e0f177..9cd4123 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -302,6 +302,11 @@ struct drm_crtc_state {
> /* blob property to expose current mode to atomic userspace */
> struct drm_property_blob *mode_blob;
>
> + /* blob properties to hold the color properties' blobs */
> + struct drm_property_blob *palette_before_ctm_blob;
> + struct drm_property_blob *palette_after_ctm_blob;
> + struct drm_property_blob *ctm_blob;
> +
> struct drm_pending_vblank_event *event;
>
> struct drm_atomic_state *state;
> @@ -1151,7 +1156,7 @@ struct drm_mode_config {
> struct drm_property *cm_palette_after_ctm_property;
> struct drm_property *cm_ctm_property;
>
> - /* Coor management capabilities query */
> + /* Color management capabilities query */
This should be part of the previous patch.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/i915/i915_debugfs.c |2 -
drivers/gpu/drm/i915/i915_drv.h | 12 +++--
drivers/gpu/drm/i915/intel_bios.c |7 +--
drivers/gpu/drm/i915/intel_opregion.c | 73 -
drivers/gpu/drm/i915/intel_panel.c|2 -
5 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3ec9049081f..15989cc16e92 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;
if (opregion->header) {
- memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+ memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1db8de52851..d8684634a31d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,14 +444,14 @@ struct opregion_swsci;
struct opregion_asle;
struct intel_opregion {
- struct opregion_header __iomem *header;
- struct opregion_acpi __iomem *acpi;
- struct opregion_swsci __iomem *swsci;
+ struct opregion_header *header;
+ struct opregion_acpi *acpi;
+ struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
- struct opregion_asle __iomem *asle;
- void __iomem *vbt;
- u32 __iomem *lid_state;
+ struct opregion_asle *asle;
+ void *vbt;
+ u32 *lid_state;
struct work_struct asle_work;
};
#define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index c19e669ffe50..1ee2f11d355d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1238,11 +1238,10 @@ static const struct bdb_header *validate_vbt(const void
__iomem *_base,
{
/*
* This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
+* (__iomem) of the BIOS/VBT. From now on everything is based on
+* 'base', and treated as regular memory.
*/
- const void *base = (const void *) _base;
+ const void *base = (const void __force *) _base;
size_t offset = _vbt - _base;
const struct vbt_header *vbt = base + offset;
const struct bdb_header *bdb;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cb1c65739425..4f65cdb38e1b 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -239,7 +239,7 @@ struct opregion_asle {
static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci;
+ struct opregion_swsci *swsci = dev_priv->opregion.swsci;
u32 main_function, sub_function, scic;
u16 pci_swsci;
u32 dslp;
@@ -264,7 +264,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* Driver sleep timeout in ms. */
- dslp = ioread32(&swsci->dslp);
+ dslp = swsci->dslp;
if (!dslp) {
/* The spec says 2ms should be the default, but it's too small
* for some machines. */
@@ -277,7 +277,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* The spec tells us to do this, but we are the only user... */
- scic = ioread32(&swsci->scic);
+ scic = swsci->scic;
if (scic & SWSCI_SCIC_INDICATOR) {
DRM_DEBUG_DRIVER("SWSCI request already in progress\n");
return -EBUSY;
@@ -285,8 +285,8 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
scic = function | SWSCI_SCIC_INDICATOR;
- iowrite32(parm, &swsci->parm);
- iowrite32(scic, &swsci->scic);
+ swsci->parm = parm;
+ swsci->scic = scic;
/* Ensure SCI event is selected and event trigger is cleared. */
pci_read_config_word(dev->pdev, PCI_SWSCI, &pci_swsci);
@@ -301,7 +301,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
pci_write_config_word(dev->pdev, PCI_SWSCI, pci
Re: [Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma wrote:
> From DRM color management:
>
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
>color transformation matrix of 9 correction values gets
>applied as correction.
> 2. "palette_before_ctm": for corrections which get applied
>beore color transformation matrix correction.
> 3. "palette_after_ctm": for corrections which get applied
>after color transformation matrix correction.
>
> These color correction capabilities may differ per platform, supporting
> various different no. of correction coefficients. So DRM color manager
> support few properties using which a user space can query the platform's
> capability, and prepare color correction accordingly.
> These query properties are:
> 1. cm_coeff_after_ctm_property
> 2. cm_coeff_before_ctm_property
> (CTM is fix to 9 coefficients across industry)
>
> Now, Intel color manager registers:
> ==
> 1. Gamma correction property as "palette_after_ctm" property
> 2. Degamma correction capability as "palette_bafore_ctm" property
>capability as "palette_after_ctm" DRM color property hook.
> 3. CSC as "ctm" property.
>
> So finally, This patch does the following:
> 1. Add a function which loads the platform's color correction
>capabilities in the cm_crtc_palette_capabilities_property structure.
> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
>getting initiaized.
> 3. Adds two new parameters "num_samples_after_ctm" and
>"num_samples_before_ctm" in intel_device_info as gamma and
>degamma coefficients vary per platform basis.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> drivers/gpu/drm/i915/intel_color_manager.c | 33
> +-
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ad37b25..8bf1d6f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -798,6 +798,8 @@ struct intel_device_info {
> u8 num_sprites[I915_MAX_PIPES];
> u8 gen;
> u8 ring_mask; /* Rings supported by the HW */
> + u16 num_samples_after_ctm;
> + u16 num_samples_before_ctm;
> DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> /* Register offsets for the various display pipes and transcoders */
> int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 7357d99..e466748 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -28,6 +28,37 @@
> #include "intel_color_manager.h"
>
> void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> - struct drm_mode_object *mode_obj)
> + struct drm_crtc *crtc)
> {
> + struct drm_mode_config *config = &dev->mode_config;
> + struct drm_mode_object *mode_obj = &crtc->base;
> +
> + /*
> +* Register:
> +* =
> +* Gamma correction as palette_after_ctm property
> +* Degamma correction as palette_before_ctm property
> +*
> +* Load:
> +* =
> +* no. of coefficients supported on this platform for gamma
> +* and degamma with the query properties. A user
> +* space agent should read these query property, and prepare
> +* the color correction values accordingly. Its expected from the
> +* driver to load the right number of coefficients during the init
> +* phase.
> +*/
> + if (config->cm_coeff_after_ctm_property) {
> + drm_object_attach_property(mode_obj,
> + config->cm_coeff_after_ctm_property,
> + INTEL_INFO(dev)->num_samples_after_ctm);
> + DRM_DEBUG_DRIVER("Gamma query property initialized\n");
> + }
> +
> + if (config->cm_coeff_before_ctm_property) {
> + drm_object_attach_property(mode_obj,
> + config->cm_coeff_before_ctm_property,
> + INTEL_INFO(dev)->num_samples_before_ctm);
> + DRM_DEBUG_DRIVER("Degamma query property initialized\n");
> + }
Shouldn't this commit be squashed with the previous ? You're also
missing the function declaration.
Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/20] tree-wide convert to memremap()
The memremap() api [1] was merged in 4.3 [2] with an initial implementation for x86 and a conversion of the pmem driver. Complete the conversion for the rest of the kernel. Feel free to either ack or directly apply a conversion-patch as I will defer the final removal patches until all the conversions have landed. [1]: https://lwn.net/Articles/653585/ [2]: commit 92281dee825f arch: introduce memremap() --- Dan Williams (20): x86: introduce arch_memremap() arm: introduce arch_memremap() ia64: introduce arch_memremap() sh: introduce arch_memremap() m68k: introduce arch_memremap() arm: switch from ioremap_cache to memremap x86: switch from ioremap_cache to memremap gma500: switch from acpi_os_ioremap to memremap i915: switch from acpi_os_ioremap to memremap acpi: switch from ioremap_cache to memremap sound, skylake: switch from ioremap_cache to memremap memconsole: fix __iomem mishandling, switch to memremap intel-iommu: switch from ioremap_cache to memremap pxa2xx-flash: switch from ioremap_cache to memremap sfi: switch from ioremap_cache to memremap fbdev: switch from ioremap_wt to memremap arch: kill ioremap_cached() arch: kill ioremap_fullcache() arch: remove ioremap_cache, replace with arch_memremap arch: remove ioremap_wt, optionally replace with arch_memremap Documentation/x86/pat.txt |6 +-- arch/arc/include/asm/io.h |1 arch/arm/Kconfig |1 arch/arm/include/asm/io.h |7 --- arch/arm/include/asm/xen/page.h |4 +- arch/arm/mm/ioremap.c | 12 - arch/arm/mm/mmu.c |2 - arch/arm/mm/nommu.c | 11 +++-- arch/arm64/Kconfig|1 arch/arm64/include/asm/acpi.h | 11 - arch/arm64/include/asm/dmi.h |8 ++-- arch/arm64/include/asm/io.h |2 - arch/arm64/kernel/efi.c |9 ++-- arch/arm64/kernel/smp_spin_table.c| 19 - arch/arm64/mm/ioremap.c | 20 +++-- arch/avr32/include/asm/io.h |1 arch/frv/include/asm/io.h | 12 - arch/ia64/Kconfig |1 arch/ia64/include/asm/io.h|6 --- arch/ia64/mm/ioremap.c| 10 + arch/m32r/include/asm/io.h|1 arch/m68k/Kconfig |1 arch/m68k/include/asm/io_mm.h | 13 -- arch/m68k/include/asm/io_no.h | 11 - arch/m68k/include/asm/raw_io.h|1 arch/m68k/mm/kmap.c | 17 +++- arch/m68k/mm/sun3kmap.c |7 +++ arch/metag/include/asm/io.h |6 --- arch/microblaze/include/asm/io.h |2 - arch/mn10300/include/asm/io.h |1 arch/nios2/include/asm/io.h |1 arch/s390/include/asm/io.h|1 arch/sh/Kconfig |1 arch/sh/include/asm/io.h |7 --- arch/sh/mm/ioremap.c |9 arch/sparc/include/asm/io_32.h|1 arch/sparc/include/asm/io_64.h|1 arch/tile/include/asm/io.h|2 - arch/unicore32/include/asm/io.h |4 -- arch/unicore32/mm/ioremap.c |8 arch/x86/Kconfig |1 arch/x86/include/asm/efi.h|3 + arch/x86/include/asm/io.h |4 -- arch/x86/kernel/crash_dump_64.c |6 +-- arch/x86/kernel/kdebugfs.c|8 ++-- arch/x86/kernel/ksysfs.c | 28 ++--- arch/x86/mm/ioremap.c | 43 --- arch/xtensa/include/asm/io.h | 12 - drivers/acpi/apei/einj.c |9 ++-- drivers/acpi/apei/erst.c |6 +-- drivers/acpi/nvs.c|6 +-- drivers/acpi/osl.c| 70 +--- drivers/firmware/google/memconsole.c |7 ++- drivers/gpu/drm/gma500/opregion.c |8 ++-- drivers/gpu/drm/gma500/psb_drv.h |2 - drivers/gpu/drm/gma500/psb_lid.c |8 ++-- drivers/gpu/drm/i915/i915_debugfs.c |2 - drivers/gpu/drm/i915/i915_drv.h | 12 +++-- drivers/gpu/drm/i915/intel_bios.c |7 +-- drivers/gpu/drm/i915/intel_opregion.c | 73 - drivers/gpu/drm/i915/intel_panel.c|2 - drivers/iommu/intel-iommu.c | 20 + drivers/iommu/intel_irq_remapping.c |8 ++-- drivers/mtd/maps/pxa2xx-flash.c |6 +-- drivers/nvdimm/Kconfig|2 - drivers/sfi/sfi_core.c|4 +- drivers/video/fbdev/Kconfig |2 - drivers/video/fbdev/amifb.c |5 +- drivers/video/fbdev/atafb.c |5 +- drivers/video/fbdev/hpfb.c|6 +-- include/acpi/acpi_io.h
Re: [Intel-gfx] [PATCH v4 1/2] drm/dp: Store the drm_connector device pointer on the helper.
On Tue, Sep 29, 2015 at 06:25:44PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote:
> > Hi Daniel,
> >
> > On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > > > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > > > This is useful to determine which connector owns this AUX channel.
> > > >
> > > > WTF? I posted a patch in August which does exactly that:
> > > > http://lists.freedesktop.org/archives/dri-devel/2015-August/088172.html
> > > >
> > > > Can also be pulled in from this git repo:
> > > > https://github.com/l1k/linux/commit/b78b38d53fc0fc4fa0f6acf699b0fcad56ec1fe6
> > > >
> > > > My patch has the advantage that it updates all the drivers which use
> > > > drm_dp_aux to fill that attribute. Yours only updates i915.
> > > >
> > > > Daniel Vetter criticized storing a drm_connector pointer in drm_dp_aux,
> > > > quote:
> > > >
> > > > "That will also clear up the confusion with drm_dp_aux, adding a
> > > > drm_connector there feels wrong since not every dp_aux line has a
> > > > connector (e.g. for dp mst). If we can lift this relation out into
> > > > drivers
> > > > (where this is known) that seems cleaner."
> > > >
> > > > So now Intel itself does precisely what Daniel criticized? Confusing!
> > > >
> > > > Source:
> > > > http://lists.freedesktop.org/archives/dri-devel/2015-August/089108.html
> > >
> > > Critism is still valid, and thinking about this again a cleaner solution
> > > would be to just have a correct parent/child relationship in the device
> > > hirarchy. I.e. add a struct device *parent to the aux channel structure
> > > which should point to the right connector.
> >
> > We already have that:
> >
> > struct drm_dp_aux {
> > const char *name;
> > struct i2c_adapter ddc;
> > struct device *dev; <---
> > struct mutex hw_mutex;
> > ssize_t (*transfer)(struct drm_dp_aux *aux,
> > struct drm_dp_aux_msg *msg);
> > unsigned i2c_nack_count, i2c_defer_count;
> > };
> >
> > What Rafael is struggling with is that you cannot unambiguously
> > get from drm_dp_aux->dev to the drm_connector. (The drm_device
> > may have multiple drm_connectors with type
> > DRM_MODE_CONNECTOR_DisplayPort.)
>
> What I meant to say is that we don't need that, if instead of filling in
> the overall dev in dp_aux->dev we fill in the connector sysfs device
> thing. The we have proper nesting, like with i2c buses. And then there's
> no need for a connector property in sysfs to show that link (which should
> be done with a proper sysfs link anyway).
OK, I sent a new version, which does not add a new *connector pointer,
and uses the dev pointer on the struct to store the drm_connector
device, instead of the drm_device device. Is that what you meant? In
any case, as I mention on the patch, it is already how some drivers do,
while others store the drm_device.
This leaves the aux device, for instance in my case, at:
/sys/class/drm/card0/card0-eDP-1/drm_dp_aux0
If this is what you wanted, I can send other patches to the proper
mailing lists, trying to update other drivers.
--
Rafael
> >
> > >
> > > Thanks for pointing out that I missed properly delayering this.
> > > -Daniel
> > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Lukas
> > > >
> > > >
> > > > >
> > > > > Signed-off-by: Rafael Antognolli
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_dp.c | 1 +
> > > > > include/drm/drm_dp_helper.h | 1 +
> > > > > 2 files changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 77f7330..f90439d 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -1079,6 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp,
> > > > > struct intel_connector *connector)
> > > > >
> > > > > intel_dp->aux.name = name;
> > > > > intel_dp->aux.dev = dev->dev;
> > > > > + intel_dp->aux.connector = connector->base.kdev;
> > > > > intel_dp->aux.transfer = intel_dp_aux_transfer;
> > > > >
> > > > > DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > > > > index 9ec4716..e009b5d 100644
> > > > > --- a/include/drm/drm_dp_helper.h
> > > > > +++ b/include/drm/drm_dp_helper.h
> > > > > @@ -702,6 +702,7 @@ struct drm_dp_aux {
> > > > > const char *name;
> > > > > struct i2c_adapter ddc;
> > > > > struct device *dev;
> > > > > + struct device *connector;
> > > > > struct mutex hw_mutex;
> > > > > ssize_t (*transfer)(struct drm_dp_aux *aux,
> > > > > struct drm_dp_aux_msg *msg);
> > > > > --
> > > > > 2.4.3
> > > > >
> > > > > ___
[Intel-gfx] [PATCH v5 0/2] Add drm_dp_aux chardev support.
This series implement support to a drm_dp_aux chardev that allows reading and writing an arbitrary amount of bytes to arbitrary dpcd register addresses using regular read, write and lseek operations. v2: - lseek is used to select the register to read/write - read/write are used instead of ioctl - no blocking_notifier is used, just a direct callback v3: - use drm_dp_aux_dev prefix for public functions - chardev is named drm_dp_auxN - read/write don't allocate a buffer anymore, and transfer up to 16 bytes a time - remove notifier list from the implementation - option on menuconfig is now a boolean - add inline stub functions to avoid breakage when this option is disabled v4: - fix build system changes - actually disable this module when not selected. v5: - Use kref to avoid device closing while still in use - Don't use list, use an idr for storing aux_dev - Remove "connector" attribute - set aux.dev to the connector drm_connector device, instead of drm_device Rafael Antognolli (2): drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers. drm/dp: Set aux.dev to the drm_connector device, instead of drm_device. drivers/gpu/drm/Kconfig | 8 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_dp_aux_dev.c | 373 +++ drivers/gpu/drm/drm_dp_helper.c | 7 + drivers/gpu/drm/i915/intel_dp.c | 14 +- include/drm/drm_dp_aux_dev.h | 50 ++ 6 files changed, 441 insertions(+), 12 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c create mode 100644 include/drm/drm_dp_aux_dev.h -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.
So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the drm_connector.
This also removes the need to add a sysfs link for the i2c device under
the connector, as it will already be there.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/i915/intel_dp.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 18bcfbe..0acdf0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1078,36 +1078,21 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
intel_connector *connector)
intel_dp->aux_ch_ctl_reg = intel_dp->output_reg + 0x10;
intel_dp->aux.name = name;
- intel_dp->aux.dev = dev->dev;
+ intel_dp->aux.dev = connector->base.kdev;
intel_dp->aux.transfer = intel_dp_aux_transfer;
DRM_DEBUG_KMS("registering %s bus for %s\n", name,
connector->base.kdev->kobj.name);
ret = drm_dp_aux_register(&intel_dp->aux);
- if (ret < 0) {
+ if (ret < 0)
DRM_ERROR("drm_dp_aux_register() for %s failed (%d)\n",
name, ret);
- return;
- }
-
- ret = sysfs_create_link(&connector->base.kdev->kobj,
- &intel_dp->aux.ddc.dev.kobj,
- intel_dp->aux.ddc.dev.kobj.name);
- if (ret < 0) {
- DRM_ERROR("sysfs_create_link() for %s failed (%d)\n", name,
ret);
- drm_dp_aux_unregister(&intel_dp->aux);
- }
}
static void
intel_dp_connector_unregister(struct intel_connector *intel_connector)
{
- struct intel_dp *intel_dp = intel_attached_dp(&intel_connector->base);
-
- if (!intel_connector->mst_port)
- sysfs_remove_link(&intel_connector->base.kdev->kobj,
- intel_dp->aux.ddc.dev.kobj.name);
intel_connector_unregister(intel_connector);
}
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.
Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/Kconfig | 8 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_aux_dev.c | 373 +++
drivers/gpu/drm/drm_dp_helper.c | 7 +
include/drm/drm_dp_aux_dev.h | 50 ++
5 files changed, 439 insertions(+)
create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c
create mode 100644 include/drm/drm_dp_aux_dev.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..64fa0f4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -25,6 +25,14 @@ config DRM_MIPI_DSI
bool
depends on DRM
+config DRM_DP_AUX_CHARDEV
+ bool "DRM DP AUX Interface"
+ depends on DRM
+ help
+ Choose this option to enable a /dev/drm_dp_auxN node that allows to
+ read and write values to arbitrary DPCD registers on the DP aux
+ channel.
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e814517..e5bc0ca 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -28,6 +28,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_probe_helper.o \
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
+drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
new file mode 100644
index 000..a2861e2
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -0,0 +1,373 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rafael Antognolli
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct drm_dp_aux_dev {
+ unsigned index;
+ struct drm_dp_aux *aux;
+ struct device *dev;
+ struct kref refcount;
+ bool removed;
+ spinlock_t removed_lock;
+};
+
+#define DRM_AUX_MINORS 256
+#define AUX_MAX_OFFSET (1 << 20)
+static DEFINE_IDR(aux_idr);
+static DEFINE_SPINLOCK(aux_idr_lock);
+static struct class *drm_dp_aux_dev_class;
+static int drm_dev_major = -1;
+
+static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index)
+{
+ struct drm_dp_aux_dev *aux_dev = NULL;
+
+ spin_lock(&aux_idr_lock);
+ aux_dev = idr_find(&aux_idr, index);
+ if (!kref_get_unless_zero(&aux_dev->refcount))
+ aux_dev = NULL;
+ spin_unlock(&aux_idr_lock);
+
+ return aux_dev;
+}
+
+static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct drm_dp_aux *aux)
+{
+ struct drm_dp_aux_dev *aux_dev;
+ int index;
+
+
+ aux_dev = kzalloc(sizeof(*aux_dev), GFP_KERNEL);
+ if (!aux_dev)
+ return ERR_PTR(-ENOMEM);
+ aux_dev->aux = aux;
+ aux_dev->removed = false;
+ spin_lock_init(&aux_dev->removed_lock);
+ kref_init(&aux_dev->refcount);
+
+ idr_preload(GFP_KERNEL);
+ spin_lock(&aux_idr_lock);
+ index = idr_alloc_cyclic(&aux_idr, aux_dev, 0, DRM_AUX_MINORS,
+GFP_NOWAIT
[Intel-gfx] [PATCH] drm/i915: revert a few more watermark commits
This is a squash of the following commits:
Revert "drm/i915: Drop intel_update_sprite_watermarks"
This reverts commit 47c99438b52d12df50e182583634a4cfede3c920.
Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check"
This reverts commit 7809e5ae35b9d8d0710f0874b2e3f10be144e38b.
Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM
(v3)"
This reverts commit 3a05f5e2e78eab7ffe816abb59b6769e331a1957.
With these reverts, SKL finally stops failing every single FBC test
with FIFO underrun error messages. After some brief testing, it also
seems that this commit prevents the machine from completely freezing
when we run igt/kms_fbc_crc (see fd.o #92355).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355
Cc: Matt Roper
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/intel_atomic.c | 1 -
drivers/gpu/drm/i915/intel_display.c | 44 +---
drivers/gpu/drm/i915/intel_drv.h | 9 +-
drivers/gpu/drm/i915/intel_pm.c | 419 +--
drivers/gpu/drm/i915/intel_sprite.c | 15 ++
6 files changed, 293 insertions(+), 199 deletions(-)
The fact that I needed more reverts after rebasing suggests that maybe the
problem is happening due to some sort of timing problem? Maybe we're missing
some lock?
The machine freezes while running igt/kms_fbc_crc/blt are also curious, but I
didn't spend too much time investigating them.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bf14096..22c8b0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -628,6 +628,10 @@ struct drm_i915_display_funcs {
struct dpll *match_clock,
struct dpll *best_clock);
void (*update_wm)(struct drm_crtc *crtc);
+ void (*update_sprite_wm)(struct drm_plane *plane,
+struct drm_crtc *crtc,
+uint32_t sprite_width, uint32_t sprite_height,
+int pixel_size, bool enable, bool scaled);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
/* Returns the active state of the crtc, and if the crtc is active,
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 05b1203..f1975f2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -94,7 +94,6 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
__drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->base);
crtc_state->update_pipe = false;
- crtc_state->disable_lp_wm = false;
return &crtc_state->base;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cddb0c6..66a37d8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4804,6 +4804,7 @@ static void intel_post_plane_update(struct intel_crtc
*crtc)
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_plane *plane;
if (atomic->wait_vblank)
intel_wait_for_vblank(dev, crtc->pipe);
@@ -4822,6 +4823,10 @@ static void intel_post_plane_update(struct intel_crtc
*crtc)
if (atomic->post_enable_primary)
intel_post_enable_primary(&crtc->base);
+ drm_for_each_plane_mask(plane, dev, atomic->update_sprite_watermarks)
+ intel_update_sprite_watermarks(plane, &crtc->base,
+ 0, 0, 0, false, false);
+
memset(atomic, 0, sizeof(*atomic));
}
@@ -11577,30 +11582,16 @@ retry:
static bool intel_wm_need_update(struct drm_plane *plane,
struct drm_plane_state *state)
{
- struct intel_plane_state *new = to_intel_plane_state(state);
- struct intel_plane_state *cur = to_intel_plane_state(plane->state);
-
- /* Update watermarks on tiling or size changes. */
+ /* Update watermarks on tiling changes. */
if (!plane->state->fb || !state->fb ||
plane->state->fb->modifier[0] != state->fb->modifier[0] ||
- plane->state->rotation != state->rotation ||
- drm_rect_width(&new->src) != drm_rect_width(&cur->src) ||
- drm_rect_height(&new->src) != drm_rect_height(&cur->src) ||
- drm_rect_width(&new->dst) != drm_rect_width(&cur->dst) ||
- drm_rect_height(&new->dst) != drm_rect_height(&cur->dst))
+ plane->state->rotation != state->rotation)
return true;
- return false;
-}
-
-static bool needs_scaling(struct intel_plane_state *state)
-{
- int src_w = drm_rect_width(&state->src) >> 16;
- int src_h = drm_rect_hei
Re: [Intel-gfx] [PATCH 04/22] drm: Add set property support for color manager
Hi Shashank, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'fmt' >> drivers/gpu/drm/drm_atomic.c:407: warning: No description found for >> parameter 'dev' include/drm/drm_crtc.h:315: warning: No description found for parameter 'mode_blob' include/drm/drm_crtc.h:315: warning: No description found for parameter 'palette_before_ctm_blob' include/drm/drm_crtc.h:315: warning: No description found for parameter 'palette_after_ctm_blob' include/drm/drm_crtc.h:315: warning: No description found for parameter 'ctm_blob' include/drm/drm_crtc.h:747: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:786: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:882: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:882: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tile_idr' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_overscan_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_saturation_property' include/drm/drm_crtc.h:1176: warni
Re: [Intel-gfx] [PATCH] drm/i915: Partial revert of atomic watermark series
Em Qui, 2015-10-08 às 15:28 -0700, Matt Roper escreveu:
> It's been reported that the atomic watermark series triggers some
> regressions on SKL, which we haven't been able to track down yet.
> Let's
> temporarily revert these patches while we track down the root cause.
>
> This commit squashes the reverts of:
> 76305b1 drm/i915: Calculate watermark configuration during atomic
> check (v2)
> a4611e4 drm/i915: Don't set plane visible during HW readout if CRTC
> is off
> a28170f drm/i915: Calculate ILK-style watermarks during atomic
> check (v3)
> de4a9f8 drm/i915: Calculate pipe watermarks into CRTC state (v3)
> de165e0 drm/i915: Refactor ilk_update_wm (v3)
I see this patch is already applied. Unfortunately it doesn't solve the
problem for me. I was carrying a revert of these patches and also of:
47c99438b52d12df50e182583634a4cfede3c920
drm/i915: Drop intel_update_sprite_watermarks
But today I did a git rebase and just nightly + revert of 47c994 is not
solving the problem anymore... I suspect that something else was merged
in the meantime that broke the tree even more, and a normal git bisect
won't help anymore since I'll have to apply tons of additional patches
on top of each bisect step... I'll try to discover what else is causing
the problem.
Anyway, thanks for the help!
>
> Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-Octob
> er/077190.html
> Cc: "Zanoni, Paulo R"
> Cc: "Vetter, Daniel"
> Signed-off-by: Matt Roper
> ---
> I just got access to BXT hardware, so I'm hoping that the SKL
> problems reported
> by Paulo will also be reproducible on BXT. However I'm not going to
> be able to
> work on this for a couple days, so it's probably better to do some
> reverts now
> so that we don't leave di-nightly in a broken state in the meantime.
>
> Also note that this is a different regression than the one reported
> by Jani
> (for which we've already reverted a couple patches); his issue
> happens on the
> ILK-style watermark path which isn't relevant for Paulo's issues
> here.
>
> drivers/gpu/drm/i915/i915_drv.h | 12 --
> drivers/gpu/drm/i915/intel_display.c | 60 +
> drivers/gpu/drm/i915/intel_drv.h | 49 +++-
> drivers/gpu/drm/i915/intel_pm.c | 232 +++--
> --
> 4 files changed, 151 insertions(+), 202 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index fbf0ae9..4b02be7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -627,8 +627,6 @@ struct drm_i915_display_funcs {
> int target, int refclk,
> struct dpll *match_clock,
> struct dpll *best_clock);
> - int (*compute_pipe_wm)(struct intel_crtc *crtc,
> -struct drm_atomic_state *state);
> void (*update_wm)(struct drm_crtc *crtc);
> int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> void (*modeset_commit_cdclk)(struct drm_atomic_state
> *state);
> @@ -1692,13 +1690,6 @@ struct i915_execbuffer_params {
> struct drm_i915_gem_request *request;
> };
>
> -/* used in computing the new watermarks state */
> -struct intel_wm_config {
> - unsigned int num_pipes_active;
> - bool sprites_enabled;
> - bool sprites_scaled;
> -};
> -
> struct drm_i915_private {
> struct drm_device *dev;
> struct kmem_cache *objects;
> @@ -1923,9 +1914,6 @@ struct drm_i915_private {
>*/
> uint16_t skl_latency[8];
>
> - /* Committed wm config */
> - struct intel_wm_config config;
> -
> /*
>* The skl_wm_values structure is a bit too big for
> stack
>* allocation, so we keep the staging struct where
> we store
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 539c373..d84d5c0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11837,12 +11837,6 @@ static int intel_crtc_atomic_check(struct
> drm_crtc *crtc,
> }
>
> ret = 0;
> - if (dev_priv->display.compute_pipe_wm) {
> - ret = dev_priv->display.compute_pipe_wm(intel_crtc,
> state);
> - if (ret)
> - return ret;
> - }
> -
> if (INTEL_INFO(dev)->gen >= 9) {
> if (mode_changed)
> ret = skl_update_scaler_crtc(pipe_config);
> @@ -13048,45 +13042,6 @@ static int intel_modeset_checks(struct
> drm_atomic_state *state)
> return 0;
> }
>
> -/*
> - * Handle calculation of various watermark data at the end of the
> atomic check
> - * phase. The code here should be run after the per-crtc and per
> -plane 'check'
> - * handlers to ensure that all derived state has been updated.
> - */
> -static void calc_watermark_data(struct drm_atomic_state *state)
> -{
> - struct drm_dev
Re: [Intel-gfx] [PATCH 03/22] drm: Add color correction blobs in CRTC state
Hi Shashank, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'fmt' include/drm/drm_crtc.h:315: warning: No description found for parameter 'mode_blob' >> include/drm/drm_crtc.h:315: warning: No description found for parameter >> 'palette_before_ctm_blob' >> include/drm/drm_crtc.h:315: warning: No description found for parameter >> 'palette_after_ctm_blob' >> include/drm/drm_crtc.h:315: warning: No description found for parameter >> 'ctm_blob' include/drm/drm_crtc.h:747: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:786: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:882: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:882: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tile_idr' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_overscan_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_saturation_property' include/drm/drm_crtc.h:1176: warning: No description found for parameter 'tv_hue_property'
Re: [Intel-gfx] [PATCH 02/22] drm: Create Color Management query properties
Hi Shashank, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'fmt' include/drm/drm_crtc.h:310: warning: No description found for parameter 'mode_blob' include/drm/drm_crtc.h:742: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:781: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:877: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:877: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tile_idr' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_overscan_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_saturation_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'tv_hue_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'scaling_mode_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'aspect_ratio_property' include/drm/drm_crtc.h:1171: warning: No description found for parameter 'dirty_info_property' include/drm/drm_crtc.h:1171: w
Re: [Intel-gfx] Weekly regressions report WW41
On 10/09/2015 08:53 PM, jairo.daniel.miramontes.ca...@linux.intel.com wrote: > This week's existing bugzilla regressions, added a bisected column which > means if the Bug > does have a bisect available. > > > BugIdSummary Created on > Bisected > <> > 92237Horrible noise (audio) via DisplayPort [regre10/2/2015 > No This issue actually IS bisected: commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d Author: Jani Nikula Date: Tue Nov 12 17:10:13 2013 +0200 drm/i915/dp: set sink to power down mode on dp disable FWIW, here is the full bisect log: $ git bisect log # bad: [52cd2b0342665668e7d3806d4a0b2ff837651690] UBUNTU: Ubuntu-3.13.0-0.2 # good: [4f57e47bab90529e40d11878ba8b5f429cfa1d95] UBUNTU: Ubuntu-3.12.0-8.16 git bisect start 'Ubuntu-3.13.0-0.2' 'Ubuntu-3.12.0-8.16' # good: [5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52] Linux 3.12 git bisect good 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52 # good: [5cbb3d216e2041700231bcfc383ee5f8b7fc8b74] Merge branch 'akpm' (patches from Andrew Morton) git bisect good 5cbb3d216e2041700231bcfc383ee5f8b7fc8b74 # good: [d8fe4acc88da8fbbe360b6592c9d0abbb85117dc] Merge branch 'akpm' (patch-bomb from Andrew Morton) git bisect good d8fe4acc88da8fbbe360b6592c9d0abbb85117dc # good: [73d75ba99e3bdd627275afd3fe48cc933723084b] Merge tag 'sound-fix-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 73d75ba99e3bdd627275afd3fe48cc933723084b # good: [e6d69a60b77a6ea8d5f9d41765c7571bb8d45531] Merge branch 'next' of git://git.infradead.org/users/vkoul/slave-dma git bisect good e6d69a60b77a6ea8d5f9d41765c7571bb8d45531 # good: [d2c2ad54c485e7ebca5c0b7e4a7b2c56103fda38] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net git bisect good d2c2ad54c485e7ebca5c0b7e4a7b2c56103fda38 # bad: [26b265cd29dde56bf0901c421eabc7ae815f38c4] Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 git bisect bad 26b265cd29dde56bf0901c421eabc7ae815f38c4 # bad: [aecde27c4fc4939f7c16ae13645f896438190567] Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux git bisect bad aecde27c4fc4939f7c16ae13645f896438190567 # good: [b0e3636f656c98bdeded5aaa78601e3256b18d6d] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending git bisect good b0e3636f656c98bdeded5aaa78601e3256b18d6d # bad: [cf969677945e6e19810d616873617320da002e32] Merge tag 'drm-intel-fixes-2013-11-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes git bisect bad cf969677945e6e19810d616873617320da002e32 # good: [7272c9d2286525d4c6bce788243cf2b6f306d15c] drm/radeon: hook up backlight functions for CI and KV family. git bisect good 7272c9d2286525d4c6bce788243cf2b6f306d15c # bad: [7a495cfd9b5f82c40608f26fe523dc9e8533dc14] drm/i915/tv: add ->get_config callback git bisect bad 7a495cfd9b5f82c40608f26fe523dc9e8533dc14 # bad: [f69e515699d8e9b1c25dcfe1c4c6f435087495d2] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7 git bisect bad f69e515699d8e9b1c25dcfe1c4c6f435087495d2 # bad: [7bd40c16ccb2cb6877dd00b0e66249c171e6fa43] x86/early quirk: use gen6 stolen detection for VLV git bisect bad 7bd40c16ccb2cb6877dd00b0e66249c171e6fa43 # bad: [fdbc3b1f639bb2cbfb32c612b2699e0ba373317d] drm/i915/dp: set sink to power down mode on dp disable git bisect bad fdbc3b1f639bb2cbfb32c612b2699e0ba373317d # first bad commit: [fdbc3b1f639bb2cbfb32c612b2699e0ba373317d] drm/i915/dp: set sink to power down mode on dp disable ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/22] drm: Create Color Management DRM properties
Hi Shashank, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'fmt' include/drm/drm_crtc.h:310: warning: No description found for parameter 'mode_blob' include/drm/drm_crtc.h:742: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:781: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:877: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:877: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tile_idr' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_overscan_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_saturation_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'tv_hue_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'scaling_mode_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'aspect_ratio_property' include/drm/drm_crtc.h:1167: warning: No description found for parameter 'dirty_info_property' include/drm/drm_crtc.h:1167: warning
[Intel-gfx] [PATCH 22/22] drm/i915: BDW: Pipe level CSC correction
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 7 ++
drivers/gpu/drm/i915/intel_color_manager.c | 114 -
drivers/gpu/drm/i915/intel_color_manager.h | 12 ++-
3 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ed50f75..0e9d252 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+ (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e659382..0a6c00c 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
}
-static s16 chv_prepare_csc_coeff(s64 csc_value)
+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+ uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+ int32_t mantissa;
+ uint64_t abs_coeff;
+
+ coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+ coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+ abs_coeff = abs(coeff);
+ if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+ /* abs_coeff < 0.125 */
+ exponent_bits = 3;
+ ls_bit_pos = 19;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+ /* abs_coeff >= 0.125 && val < 0.25 */
+ exponent_bits = 2;
+ ls_bit_pos = 20;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+ && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+ /* abs_coeff >= 0.25 && val < 0.5 */
+ exponent_bits = 1;
+ ls_bit_pos = 21;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+ && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+ /* abs_coeff >= 0.5 && val < 1.0 */
+ exponent_bits = 0;
+ ls_bit_pos = 22;
+ } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+ /* abs_coeff >= 1.0 && val < 2.0 */
+ exponent_bits = 7;
+ ls_bit_pos = 23;
+ } else {
+ /* abs_coeff >= 2.0 && val < 4.0 */
+ exponent_bits = 6;
+ ls_bit_pos = 24;
+ }
+
+ mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
+ if (coeff < 0) {
+ sign_bit = 1;
+ mantissa = -mantissa;
+ mantissa &= ((1 << CSC_MAX_VALS) - 1);
+ }
+
+ reg_val = 0;
+ SET_BITS(reg_val, exponent_bits, 12, 3);
+ SET_BITS(reg_val, mantissa, 3, 9);
+ SET_BITS(reg_val, sign_bit, 15, 1);
+ DRM_DEBUG_DRIVER("CSC: reg_val=0x%x\n", reg_val);
+ return reg_val;
+}
+
+int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ enum plane plane;
+ int i, j, temp;
+ int word = 0;
+ u32 reg, plane_ctl, mode;
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ plane = to_intel_crtc(crtc)->plane;
+
+ plane_ctl = I915_READ(PLANE_CTL(pipe, plane));
+ plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
+ I915_WRITE(PLANE_CTL(pipe, plane), plane_ctl);
+ reg = _PIPE_CSC_COEFF(pipe);
+
+ /* Write csc coeff to csc regs */
+ for (i = 0, j = 0; i < CSC_MAX_VALS; i++) {
+ if ((i % 3) == 0) {
+ temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[i]);
+ SET_BITS(word, temp, 16, 16);
+ i++;
+ temp = bdw_prepare_csc_coeff(csc_da
[Intel-gfx] [PATCH 20/22] drm/i915: BDW: Load degamma correction values
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(65) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4fa046f..ebf4910 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6c7cb08..e0c486e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -98,3 +98,6 @@
#define BDW_MAX_GAMMA ((1 << 24) - 1)
#define BDW_INDEX_AUTO_INCREMENT (1 << 15)
#define BDW_INDEX_SPLIT_MODE (1 << 31)
+
+/* Degamma on BDW */
+#define BDW_DEGAMMA_MAX_VALS 512
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/22] drm/i915: BDW: Load gamma correction values
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info structures, for all of those.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5a25a35..4fa046f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,6 +302,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -314,6 +315,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -326,6 +328,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -338,6 +341,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -363,6 +367,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -376,6 +381,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -389,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 7b96512..271246a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -89,3 +89,6 @@
#define CGM_GAMMA_EN (1 << 2)
#define CGM_CSC_EN (1 << 1)
#define CGM_DEGAMMA_EN (1 << 0)
+
+/* Gamma on BDW */
+#define BDW_SPLITGAMMA_MAX_VALS512
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/22] drm/i915: Commit color correction to CRTC
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 44 ++
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 433e50a..d5315b2 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
return ret;
}
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state)
+{
+ struct drm_property_blob *blob;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ int ret = -EINVAL;
+
+ blob = crtc_state->palette_after_ctm_blob;
+ if (blob) {
+ /* Gamma correction is platform specific */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_gamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set Gamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("Gamma correction success\n");
+ }
+
+ blob = crtc_state->palette_before_ctm_blob;
+ if (blob) {
+ /* Degamma correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_degamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set degamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("degamma correction success\n");
+ }
+
+ blob = crtc_state->ctm_blob;
+ if (blob) {
+ /* CSC correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_csc(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set CSC correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("CSC correction success\n");
+ }
+}
+
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 98cc97a..8235341 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13528,6 +13528,8 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+ intel_color_manager_crtc_commit(dev, crtc->state);
}
static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ed66a4f..d100e81 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1469,4 +1469,7 @@ void intel_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
+/* intel_color_mnager.c */
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state);
#endif /* __INTEL_DRV_H__ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/22] drm/i915: BDW: Pipe level degamma correction
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 59 ++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 74f8fc3..e659382 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -273,6 +273,63 @@ static int bdw_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
return 0;
}
+static int bdw_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ int num_samples, length;
+ u32 index, mode;
+ u32 pal_prec_index, pal_prec_data;
+ struct drm_palette *degamma_data;
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+
+ if (num_samples == GAMMA_DISABLE_VALS) {
+ /* Disable degamma on Pipe */
+ mode = I915_READ(GAMMA_MODE(pipe)) & ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_8BIT);
+
+ state->palette_before_ctm_blob = NULL;
+ DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
+ pipe_name(pipe));
+ return 0;
+ }
+
+ if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
+ DRM_ERROR("Invalid number of samples\n");
+ return -EINVAL;
+ }
+
+ length = num_samples * sizeof(struct drm_r32g32b32);
+ mode = I915_READ(GAMMA_MODE(pipe));
+ pal_prec_index = _PREC_PAL_INDEX(pipe);
+ pal_prec_data = _PREC_PAL_DATA(pipe);
+
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ index = I915_READ(pal_prec_index);
+ index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+ I915_WRITE(pal_prec_index, index);
+
+ bdw_write_10bit_gamma_precision(dev, correction_values,
+ pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
+
+ /* Enable DeGamma on Pipe */
+ mode &= ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+ DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
+
+ return 0;
+}
+
static s16 chv_prepare_csc_coeff(s64 csc_value)
{
s32 csc_int_value;
@@ -579,6 +636,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* Degamma correction */
if (IS_CHERRYVIEW(dev))
ret = chv_set_degamma(dev, blob, crtc);
+ else if (IS_BROADWELL(dev) || IS_GEN9(dev))
+ ret = bdw_set_degamma(dev, blob, crtc);
if (ret)
DRM_ERROR("set degamma correction failed\n");
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit Split Gamma mode
3. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 25 ++-
drivers/gpu/drm/i915/intel_color_manager.c | 248 +
drivers/gpu/drm/i915/intel_color_manager.h | 6 +
3 files changed, 277 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5825ab2..ed50f75 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5647,11 +5647,15 @@ enum skl_disp_power_wells {
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
-#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) +
(i) * 4)
+#define _LGC_PALETTE_C 0x4b000
+#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B, \
+_LGC_PALETTE_C) + (i) * 4)
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C 0x4b480
+#define GAMMA_MODE(pipe) \
+ _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
#define GAMMA_MODE_MODE_MASK (3 << 0)
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
@@ -8062,6 +8066,23 @@ enum skl_disp_power_wells {
#define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A 0x4A400
+#define PAL_PREC_INDEX_B 0x4AC00
+#define PAL_PREC_INDEX_C 0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GCMAX_A 0x4A410
+#define PAL_PREC_GCMAX_B 0x4AC10
+#define PAL_PREC_GCMAX_C 0x4B410
+
+#define _PREC_PAL_INDEX(pipe) \
+ (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+ (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+#define _PREC_PAL_GCMAX(pipe) \
+ (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index d5315b2..74f8fc3 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -26,6 +26,252 @@
*/
#include "intel_color_manager.h"
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+ struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+ u32 no_of_coeff)
+{
+ u16 blue_fract, green_fract, red_fract;
+ u32 word = 0;
+ u32 count = 0;
+ u32 blue, green, red;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ while (count < no_of_coeff) {
+
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ /*
+ * Maximum possible gamma correction value supported
+ * for BDW is 0x, so clip the values accordingly
+ */
+ if (blue >= BDW_MAX_GAMMA)
+ blue = BDW_MAX_GAMMA;
+ if (green >= BDW_MAX_GAMMA)
+ green = BDW_MAX_GAMMA;
+ if (red >= BDW_MAX_GAMMA)
+ red = BDW_MAX_GAMMA;
+
+ /*
+ * Gamma correction values are sent in 8.24 format
+ * with 8 int and 24 fraction bits. BDW 10 bit gamma
+ * unit expects correction registers to be programmed in
+ * 0.10 format, with 0 int and 16 fraction bits. So take
+ * MSB 10 bit values(bits 23-14) from the fraction part and
+ * prepare the correction registers.
+ */
+ blue_fract = GET_BITS(blue, 14, 10);
+ green_fract = GET_BITS(green, 14, 10);
+ red_fract = GET_BITS(red, 14, 10);
+
+ /* Arrange: Red (29:20) Green (19:10) and Blue (9:0) */
+ SET_BITS(word, red_fract, 20, 10);
+ SET_BITS(word, red_fract, 10, 10);
+ SET_BITS(word, red_fract, 0, 10);
+ I915_WRITE(pal_prec_data, word);
+ count++;
+ }
+ DRM_DEBUG_DRIVER("Gamma correction programmed\n");
+}
+
+void bdw_write_12bit_gamma_precision(struct drm_device *de
[Intel-gfx] [PATCH 15/22] drm/i915: CHV: Pipe level CSC correction
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 8 +++
drivers/gpu/drm/i915/intel_color_manager.c | 94 ++
drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
3 files changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c32e35d..5825ab2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
#define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index bbfe185..433e50a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,93 @@
#include "intel_color_manager.h"
+static s16 chv_prepare_csc_coeff(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s16 csc_s3_12_format;
+
+ if (csc_value >= 0) {
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX)
+ csc_value = CHV_CSC_COEFF_MAX;
+ } else {
+ csc_value = -csc_value;
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX + 1)
+ csc_value = CHV_CSC_COEFF_MAX + 1;
+ csc_value = -csc_value;
+ }
+
+ csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+ csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+ if (csc_value < 0)
+ csc_int_value |= CSC_COEFF_SIGN;
+
+ csc_fract_value = csc_value;
+ csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+ csc_s3_12_format = csc_int_value | csc_fract_value;
+
+ return csc_s3_12_format;
+}
+
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 reg;
+ enum pipe pipe;
+ s32 word = 0, temp;
+ int count = 0;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+
+ /* Disable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+ DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+ pipe_name(pipe));
+
+ reg = _PIPE_CSC_BASE(pipe);
+ while (count < CSC_MAX_VALS) {
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+
+ /*
+* Last value to be written in 1 register.
+* Otherwise, each pair of CSC values go
+* into 1 register
+*/
+ if (count != (CSC_MAX_VALS - 1)) {
+ count++;
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+ }
+ I915_WRITE(reg, word);
+ reg += 4;
+ count++;
+ }
+
+ /* Enable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+ DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+ return 0;
+}
+
static int chv_set_degamma(struct drm_device *dev,
struct drm_property_blob *blob, struct drm_crtc *crtc)
{
@@ -268,4 +355,11 @@ void intel_attach_color_properties_to_crtc(struct
drm_device *dev,
config->cm_palette_before_ctm_property, 0);
DRM_DEBUG_DRIVER("degamma property attached to CRTC\n");
}
+
+ /* CSC */
+ if (config->cm_ctm_property) {
+ drm_object_att
[Intel-gfx] [PATCH 11/22] drm/i915: CHV: Load gamma color correction values
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coefficitents for best gamma color correction
modes possible in CHV, in device info structure, which is:
Gamma(10 bit, CGM HW unit): 257 coeff
These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 2 ++
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1cb6b82..7466dba 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include "intel_color_manager.h"
#include
#include
@@ -349,6 +350,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index eec52a7..a378fe1 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -48,3 +48,6 @@
CLEAR_BITS(target, start_bit, no_bits); \
target |= (bit_pattern << start_bit); \
} while (0)
+
+/* CHV */
+#define CHV_10BIT_GAMMA_MAX_VALS 257
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/22] drm/i915: Attach color properties to CRTC
Function intel_attach_color_properties_to_crtc attaches a color property to its CRTC object. This patch calls this function from crtc initialization sequence. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8235341..514cd44 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13859,6 +13859,7 @@ static void intel_crtc_init(struct drm_device *dev, int pipe) intel_crtc->cursor_size = ~0; intel_crtc->wm.cxsr_allowed = true; + intel_attach_color_properties_to_crtc(dev, &intel_crtc->base); BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) || dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index d100e81..1ce4f2b 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1472,4 +1472,6 @@ extern const struct drm_plane_helper_funcs intel_plane_helper_funcs; /* intel_color_mnager.c */ void intel_color_manager_crtc_commit(struct drm_device *dev, struct drm_crtc_state *crtc_state); +void intel_attach_color_properties_to_crtc(struct drm_device *dev, + struct drm_crtc *crtc); #endif /* __INTEL_DRV_H__ */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 12 +++
drivers/gpu/drm/i915/intel_color_manager.c | 114 +
drivers/gpu/drm/i915/intel_color_manager.h | 13
3 files changed, 139 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 60e6a73..885ac8a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8038,4 +8038,16 @@ enum skl_disp_power_wells {
#define GEN9_VEBOX_MOCS_0 0xcb00 /* Video MOCS base register*/
#define GEN9_BLT_MOCS_00xcc00 /* Blitter MOCS base register*/
+/* Color Management */
+#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e466748..cf381b8 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,112 @@
#include "intel_color_manager.h"
+static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
+ struct drm_crtc *crtc)
+{
+ bool flag = false;
+ enum pipe pipe;
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue, num_samples;
+ u32 word = 0;
+ u32 count = 0;
+ u32 cgm_gamma_reg = 0;
+ u32 cgm_control_reg = 0;
+ int ret = 0, length;
+ struct drm_r32g32b32 *correction_values = NULL;
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ gamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ switch (num_samples) {
+ case GAMMA_DISABLE_VALS:
+
+ /* Disable Gamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_GAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ break;
+
+ case CHV_8BIT_GAMMA_MAX_VALS:
+ case CHV_10BIT_GAMMA_MAX_VALS:
+
+ count = 0;
+ cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+ correction_values = (struct drm_r32g32b32 *)&gamma_data->lut;
+
+ while (count < num_samples) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ if (blue > CHV_MAX_GAMMA)
+ blue = CHV_MAX_GAMMA;
+
+ if (green > CHV_MAX_GAMMA)
+ green = CHV_MAX_GAMMA;
+
+ if (red > CHV_MAX_GAMMA)
+ red = CHV_MAX_GAMMA;
+
+ /* get MSB 10 bits from fraction part (14:23) */
+ blue_fract = GET_BITS(blue, 14, 10);
+ green_fract = GET_BITS(green, 14, 10);
+ red_fract = GET_BITS(red, 14, 10);
+
+ /* Green (25:16) and Blue (9:0) to be written */
+ SET_BITS(word, green_fract, 16, 10);
+ SET_BITS(word, blue_fract, 0, 10);
+ I915_WRITE(cgm_gamma_reg, word);
+ cgm_gamma_reg += 4;
+
+ /* Red (9:0) to be written */
+ word = red_fract;
+ I915_WRITE(cgm_gamma_reg, word);
+
+ cgm_gamma_reg += 4;
+ count++;
+
+ /*
+ * On CHV, the best supported Gamma capability is
[Intel-gfx] [PATCH 12/22] drm/i915: CHV: Load degamma color correction values
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coefficitents for degamma color correction
modes possible in CHV, in device info structure, which is:
CGM Degamma(10 bit, CGM HW unit): 65 coeff
These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/intel_color_manager.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7466dba..5a25a35 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
+ .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index a378fe1..14a1309 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -51,3 +51,4 @@
/* CHV */
#define CHV_10BIT_GAMMA_MAX_VALS 257
+#define CHV_DEGAMMA_MAX_VALS 65
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/22] drm/i915: CHV: Pipe level degamma correction
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2. Add DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 6 ++
drivers/gpu/drm/i915/intel_color_manager.c | 93 ++
drivers/gpu/drm/i915/intel_color_manager.h | 5 ++
3 files changed, 104 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 885ac8a..c32e35d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8050,4 +8050,10 @@ enum skl_disp_power_wells {
#define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index cf381b8..bbfe185 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,93 @@
#include "intel_color_manager.h"
+static int chv_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue;
+ u32 num_samples;
+ u32 word = 0;
+ u32 count = 0;
+ u32 cgm_control_reg = 0;
+ u32 cgm_degamma_reg = 0;
+ int length;
+ int ret = 0;
+ enum pipe pipe;
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ if (num_samples == GAMMA_DISABLE_VALS) {
+ /* Disable DeGamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_DEGAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+ DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
+ cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+
+ count = 0;
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ while (count < CHV_DEGAMMA_MAX_VALS) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ if (blue > CHV_MAX_GAMMA)
+ blue = CHV_MAX_GAMMA;
+
+ if (green > CHV_MAX_GAMMA)
+ green = CHV_MAX_GAMMA;
+
+ if (red > CHV_MAX_GAMMA)
+ red = CHV_MAX_GAMMA;
+
+ blue_fract = GET_BITS(blue, 8, 14);
+ green_fract = GET_BITS(green, 8, 14);
+ red_fract = GET_BITS(red, 8, 14);
+
+ /* Green (29:16) and Blue (13:0) in DWORD1 */
+ SET_BITS(word, green_fract, 16, 14);
+ SET_BITS(word, green_fract, 0, 14);
+ I915_WRITE(cgm_degamma_reg, word);
+ cgm_degamma_reg += 4;
+
+ /* Red (13:0) to be written to DWORD2 */
+ word = red_fract;
+ I915_WRITE(cgm_degamma_reg, word);
+ cgm_degamma_reg += 4;
+ count++;
+ }
+
+ DRM_DEBUG_DRIVER("DeGamma LUT loaded for Pipe %c\n",
+ pipe_name(pipe));
+
+ /* Enable DeGamma on Pipe */
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+ I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_DEGAMMA_EN);
+
+ DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ } else {
+ DRM_ERROR("Invalid number of samples for DeGamma LUT\n");
+
[Intel-gfx] [PATCH 09/22] drm/i915: Create color management files
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/intel_color_manager.c | 33
drivers/gpu/drm/i915/intel_color_manager.h | 50 ++
3 files changed, 85 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44d290a..56caf9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
intel_overlay.o \
intel_psr.o \
intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..7357d99
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+
+#include "intel_color_manager.h"
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+ struct drm_mode_object *mode_obj)
+{
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..eec52a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+#include
+#include
+#include "i915_drv.h"
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+ ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+ x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */
+#define SET_BITS(target, bit_pattern, start_bit,
[Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities
From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get applied
beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
after color transformation matrix correction.
These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
(CTM is fix to 9 coefficients across industry)
Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.
So finally, This patch does the following:
1. Add a function which loads the platform's color correction
capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
"num_samples_before_ctm" in intel_device_info as gamma and
degamma coefficients vary per platform basis.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_color_manager.c | 33 +-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad37b25..8bf1d6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -798,6 +798,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+ u16 num_samples_after_ctm;
+ u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..e466748 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -28,6 +28,37 @@
#include "intel_color_manager.h"
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
- struct drm_mode_object *mode_obj)
+ struct drm_crtc *crtc)
{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_mode_object *mode_obj = &crtc->base;
+
+ /*
+* Register:
+* =
+* Gamma correction as palette_after_ctm property
+* Degamma correction as palette_before_ctm property
+*
+* Load:
+* =
+* no. of coefficients supported on this platform for gamma
+* and degamma with the query properties. A user
+* space agent should read these query property, and prepare
+* the color correction values accordingly. Its expected from the
+* driver to load the right number of coefficients during the init
+* phase.
+*/
+ if (config->cm_coeff_after_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_after_ctm_property,
+ INTEL_INFO(dev)->num_samples_after_ctm);
+ DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+ }
+
+ if (config->cm_coeff_before_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_before_ctm_property,
+ INTEL_INFO(dev)->num_samples_before_ctm);
+ DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+ }
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/22] drm/i915: Add set property interface for CRTC
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7f3c482..98cc97a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13237,6 +13237,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+ .set_property = drm_atomic_helper_crtc_set_property,
};
static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/22] drm: Add color correction blobs in CRTC state
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_atomic_helper.c | 12
include/drm/drm_crtc.h | 7 ++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 87a2a44..d73ca9b9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2193,6 +2193,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_reference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_reference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2238,6 +2244,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc *crtc,
{
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_unreference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_unreference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_unreference_blob(state->palette_before_ctm_blob);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6e0f177..9cd4123 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -302,6 +302,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
+ /* blob properties to hold the color properties' blobs */
+ struct drm_property_blob *palette_before_ctm_blob;
+ struct drm_property_blob *palette_after_ctm_blob;
+ struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
struct drm_atomic_state *state;
@@ -1151,7 +1156,7 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;
- /* Coor management capabilities query */
+ /* Color management capabilities query */
struct drm_property *cm_coeff_before_ctm_property;
struct drm_property *cm_coeff_after_ctm_property;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/22] drm: Create Color Management DRM properties
Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.
There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a correction
matrix is used for color correction.
- Palette correction: Where direct LUT values are sent to be applied
on a color palette.
This patch initializes color management framework by:
1. Introducing new pointers in DRM mode_config structure to
carry CTM and Palette color correction properties.
2. Creating these DRM properties in DRM standard properties creation
sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_crtc.c | 19 +++
include/drm/drm_crtc.h | 5 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e600a5f..30bd43d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1472,6 +1472,25 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
+ /* Color Management properties */
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_after_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_before_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_ctm_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 683f142..debd6c2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1146,6 +1146,11 @@ struct drm_mode_config {
struct drm_property *suggested_x_property;
struct drm_property *suggested_y_property;
+ /* Color Management Properties */
+ struct drm_property *cm_palette_before_ctm_property;
+ struct drm_property *cm_palette_after_ctm_property;
+ struct drm_property *cm_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/22] drm: Add drm structures for palette color property
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..681d5af 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,32 @@ struct drm_event_vblank {
__u32 reserved;
};
+struct drm_r32g32b32 {
+ /*
+* Data is in U8.24 fixed point format.
+* All platforms support values within [0, 1.0] range,
+* for Red, Green and Blue colors.
+*/
+ __u32 r32;
+ __u32 g32;
+ __u32 b32;
+ __u32 reserved;
+};
+
+struct drm_palette {
+ /*
+* This has to be a supported value during get call.
+* Feature will be disabled if this is 0 while set
+*/
+ __u32 num_samples;
+ /*
+* Starting of palette LUT in R32G32B32 format.
+* Each of RGB value is in U8.24 fixed point format.
+* Actual number of samples will depend upon num_samples
+*/
+ struct drm_r32g32b32 lut[0];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/22] drm: Add structure to set/get a CTM color property
Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for color correction.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 681d5af..f347c69 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -855,6 +855,16 @@ struct drm_palette {
struct drm_r32g32b32 lut[0];
};
+struct drm_ctm {
+ /*
+* Each value is in S31.32 format.
+* This is 3x3 matrix in row major format.
+* Integer part will be clipped to nearest
+* max/min boundary as supported by the HW platform.
+*/
+ __s64 ctm_coeff[9];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/22] drm: Add set property support for color manager
As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from the blob can referred and applied on display controller
registers.
This patch adds this set_property support for color correction blobs
in drm framework.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal malladi
---
drivers/gpu/drm/drm_atomic.c | 53 ++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..0b286d2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct
drm_crtc_state *state,
EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
/**
+ * drm_atomic_crtc_set_blob - find and set a blob
+ * @state_blob: reference pointer to the color blob in the crtc_state
+ * @blob_id: blob_id coming from set_property() call
+ *
+ * Set a color correction blob (originating from a set blob property) on the
+ * desired CRTC state. This function will take reference of the blob property
+ * in the CRTC state, finds the blob based on blob_id (which comes from
+ * set_property call) and set the blob at the proper place.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+int drm_atomic_crtc_set_blob(struct drm_device *dev,
+ struct drm_property_blob **state_blob, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_DEBUG_KMS("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (*state_blob)
+ drm_property_unreference_blob(*state_blob);
+
+ /* Attach the blob to be committed in state */
+ *state_blob = blob;
+ return 0;
+}
+
+/**
* drm_atomic_crtc_set_property - set property on CRTC
* @crtc: the drm CRTC to set a property on
* @state: the state object to update with the new property value
@@ -422,8 +454,25 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
if (mode)
drm_property_unreference_blob(mode);
return ret;
- }
- else if (crtc->funcs->atomic_set_property)
+ } else if (property == config->cm_palette_after_ctm_property) {
+ ret = drm_atomic_crtc_set_blob(dev,
+ &state->palette_after_ctm_blob, val);
+ if (ret)
+ DRM_ERROR("Failed to load blob palette_after_ctm\n");
+ return ret;
+ } else if (property == config->cm_palette_before_ctm_property) {
+ ret = drm_atomic_crtc_set_blob(dev,
+ &state->palette_before_ctm_blob, val);
+ if (ret)
+ DRM_ERROR("Failed to load blob palette_before_ctm\n");
+ return ret;
+ } else if (property == config->cm_ctm_property) {
+ ret = drm_atomic_crtc_set_blob(dev,
+ &state->ctm_blob, val);
+ if (ret)
+ DRM_ERROR("Failed to load blob ctm\n");
+ return ret;
+ } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
else
return -EINVAL;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/22] Color Management for DRM
This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color correction/enhancement. Various Hardware platforms can support several color correction capabilities. Color Manager provides abstraction of these capabilities and allows a user space UI agent to correct/enhance the display using the DRM property interface. How is this going to work? == 1. This patch series adds a few new properties in DRM framework. These properties are: a. color_capabilities property (type blob) b. Color Transformation Matrix property for corrections like CSC (called CTM, type blob) c. Palette correction properties for corrections like gamma fixup (called palette_correction, type blob) 2. Also, this patch series adds few structures to indicate specifications of a property like size, no_of_samples for correction etc. 3. These properties are present in mode_config. 4. When the platform's display driver loads, it fills up the values of color_capabilities property using the standard structures (added in step 2). For example, Intel's I915 driver adds following color correction capabilities: a. gamma correction capability as palette correction property, with 257 correction coefficients and a max/min value b. csc correction capability as CTM correction property, with 3x3 transformation matrix values and max/min values 5. Now when userspace comes up, it queries the platform's color capabilities by doing a get_property() on color_capabilities DRM property 6. Reading the blob, the userspace understands the color capabilities of the platform. For example, userspace will understand it can support: a. palette_correction with 257 coefficients b. CSC correction with 3x3 = 9 values 7. To set color correction values, userspace: a. creates a blob using the create_blob_ioctl in standard palette_correction structure format, with the correction values b. calls the set_property_ioctl with the blob_id as value for the property 8. Driver refers to the blob, gets the correction values and applies the correction in HW. 9. To get currently applied color correction values, userspace: a. calls a get_property_ioctl on that color property b. gets the blob_id for the currently applied correction from DRM infrastructure c. gets the blob using get_blob_ioctl and hence the currently applied values That's all! :) About the patch series: === The patch series first adds the color management support in DRM layer. Then it adds the color management framework in I915 layer. After that, it implements platform specific core color correction functios. Intel color manager registers color correction with DRM color manager in this way: - CSC transformation is registered as CTM DRM property - Gamma correction is registered as palette_after_ctm DRM property - Degamma correction is registered as palette_before_ctm DRM property Our thanks to all the reviewers who have given valuable comments in terms of design and implementation to our previous sets of patches. Special mention of thanks should go to Matt Roper for all his inputs/suggestions in implementation of this module, using DRM atomic CRTC commit path. V2: Worked on review comments from Matt, Jim, Thierry, Rob. V3: Worked on review comments from Matt, Jim, Rob: - Jim, Rob: Re-arranged the whole patch series in the sequence of features, currently: First 5 patches add color management support in DRM layer Next 7 patches add Intel color management framework in I915 driver Next 5 patches add color correction for CHV (gamma, degamma and CSC) Next 2 patches enable color management, by attaching the properties to CRTC(Matt) Next 4 patches add color correction for BDW (gamma, degamma) - Matt: = Patch 3: Added refernce/unreference for blob Patch 7: return -EINVAL and added debug message Patch 8: check for valid blob, from create blob moved call to intel_crtc_attach_color_prop in the end of full implementation (CHV) Patch 9: DRM_ERROR->DRM_DEBUG for NULL blob case Patch 13: Added static for internal functions Patch 20-24: renamed gen9_* functions to bdw_* Added new variables in device_info structure num_samples_after_ctm and num_samples_before_ctm Added new function in patch 8 to load capabilities based on device_info across all platforms V4: Worked on review comments from Daniel, Matt, Rob, Jim - Rob, Jim: = Patch 15, 22: Prepare CSC coeff properly(chv, bdw). Patch 13, 20: Gamma max should be (1<<24) -1(chv, bdw). - Daniel, Matt: = Patch 2: Create separate properties to query color capabilities, not a single blob. Patch 4, 5, 10: Add set/get property interface in DRM layer, not in I915 layer. Shashank Sharma (22): drm: Create Color Management DRM properties drm: Create Co
[Intel-gfx] [PATCH 05/22] drm: Add get property support for color manager
As per the DRM get_property implementation for a blob, framework is supposed to return the blob_id to the caller. All the color management blobs are saved in CRTC state during the set call. This patch adds get_property support for color management properties, by referring to the existing blob for the property and passing its blob_id. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_atomic.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 0b286d2..f9ecc49 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -499,6 +499,14 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc, *val = state->active; else if (property == config->prop_mode_id) *val = (state->mode_blob) ? state->mode_blob->base.id : 0; + else if (property == config->cm_palette_after_ctm_property) + *val = (state->palette_after_ctm_blob) ? + state->palette_after_ctm_blob->base.id : 0; + else if (property == config->cm_palette_before_ctm_property) + *val = (state->palette_before_ctm_blob) ? + state->palette_before_ctm_blob->base.id : 0; + else if (property == config->cm_ctm_property) + *val = (state->ctm_blob) ? state->ctm_blob->base.id : 0; else if (crtc->funcs->atomic_get_property) return crtc->funcs->atomic_get_property(crtc, state, property, val); else -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/22] drm: Create Color Management query properties
DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.
Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after/before color
transformation (CTM) unit in the display pipeline.
This patch adds two new read-only properties,
- cm_coeff_before_ctm_property: A platform driver should use this
property to show supported no_of_coefficients for palette correction,
which gets applied before ctm correction.
- cm_coeff_after_ctm_property: A platform driver should use this property
to show supported no_of_coefficients for palette correction, which gets
applied after ctm correction.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_crtc.c | 13 +
include/drm/drm_crtc.h | 4
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 30bd43d..76abeca 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1491,6 +1491,19 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.cm_ctm_property = prop;
+ /* DRM properties to query color capabilities */
+ prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+ "COEFFICIENTS_BEFORE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_coeff_before_ctm_property = prop;
+
+ prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+ "COEFFICIENTS_AFTER_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_coeff_after_ctm_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index debd6c2..6e0f177 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1151,6 +1151,10 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;
+ /* Coor management capabilities query */
+ struct drm_property *cm_coeff_before_ctm_property;
+ struct drm_property *cm_coeff_after_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Weekly regressions report WW41
This week's existing bugzilla regressions, added a bisected column which means if the Bug does have a bisect available. BugIdSummary Created on Bisected <> 92237Horrible noise (audio) via DisplayPort [regre10/2/2015 No 92324[Intel-gfx] [PATCH] fixup! drm/i915/skl: Elim10/7/2015 Yes 92335[HSW Regression] Null pointer deference in in10/7/2015 No 92355[SKL Regression] igt/kms_fbc_crc cause DUT cr10/9/2015 No <> 56834[ivb DP dual link DVI dongle regression] [drm11/7/2012 No 72782[945GM bisected] screen blank on S3 resume on12/17/2013 Yes 80896"[BDW Regression]dmesg error ""<3>[1.95487/4/2014 No 81537[snb dp regression] dp retry forever due to s7/19/2014 No 84855[ILK regression]igt kms_rotation_crc/sprite-r10/10/2014 No 84974[VLV eDP-LVDS bisected] powerdomains: Screen 10/14/2014 Yes 87131[PNV regression] igt/gem_exec_lut_handle take12/9/2014 No 87480[SNB/IVB/HSW/BYT bisected]igt/kms_force_conne12/19/2014 Yes 87662[ALL 3.18 Bisected] DVI --rotation inverted c12/24/2014 Yes 87725[BDW Bisected] OglBatch7 performance reduced 12/26/2014 Yes 87726[BDW Bisected] OglDrvCtx performance reduced 12/26/2014 Yes 87729[BDW/BSW/SKL PPGTT Bisected]igt/gem_close_rac12/26/2014 Yes 88012[bisected BYT] complete freeze after: drm/i911/4/2015 Yes 88081[BSW Bisected]Display show black screen when 1/6/2015 Yes 88124i915: regression: after DP connected monitor 1/6/2015 No 88325screen brightness regression on resume1/12/2015 No 88439[BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau1/15/2015 Yes 89334[945 regression] 4.0-rc1 kernel GPU hang: ec2/26/2015 No 89629[i965 regression]igt/kms_rotation_crc/sprite-3/18/2015 No 89632[i965 regression]igt/kms_universal_plane/univ3/18/2015 No 89728[HSW/BDW/BSW/SKL bisected] igt/pm_rps/ subcas3/23/2015 Yes 89872[ HSW Bisected ] VGA was white screen when re4/2/2015 Yes 90065[BSW Regression]igt/gem_userptr_blits/minor-n4/17/2015 No 90112[BSW bisected] OglGSCloth/Lightsmark/CS/ Port4/20/2015 Yes 90134[BSW Bisected]GFXBench3_gl_driver/GFXBench3_g4/22/2015 Yes 90212[BDW-Y bisected] Screen flicker when start X 4/28/2015 Yes 90368[SNB bisected igt/kms_3d has hardcoded expect5/8/2015 Yes 90394[SNB Regression]igt/kms_plane/plane-position-5/11/2015 No 90461[SKL Regression]boot system causes WARNING: C5/15/2015 No 90546[BDW/BSW/SKL bisected]igt/pm_rpm/drm-resource5/21/2015 Yes 90732[BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked5/29/2015 Yes 90808[BDW Bisected]igt/gem_ctx_param_basic/invalid6/2/2015 Yes 90994[BDW regression] pm_rpm subtests fail and giv6/16/2015 No 91138[atomic mst regression] Unable to configure 26/28/2015 No 91378[hsw dp regression] 06ea66b6 (5.4GHz link clo7/17/2015 No 91592[pnv regression] OOPS on boot8/9/2015 No 91844[HSW Regression] intel_do_flush_locked failed9/2/2015 No 91952[Bisected Regression] Blank screen from boot 9/10/2015 Yes 91959[865g 3.19 regression] Desktop image is disto9/10/2015 No 91974[bisected] unrecoverable black screen after k9/11/2015 Yes 92050[regression]/bug introduced by commit [0e572f9/19/2015 No 92083[regression] [git pull] drm for 4.3 9/23/2015 No 92096regression/bug introduced by commit [0e572fe79/24/2015 No 92097[regression] Linux 4.3-rc i915: WARNING: int9/24/2015 No 92174PROBLEM: Intel VGA output busticated on 4.3-r9/29/2015 No 92211[BDW HSW-U SKL Regression] [IGT Basic] igt/pm10/1/2015 No ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS
On 09/10/15 18:26, Chris Wilson wrote: On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote: On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote: On 09/10/15 09:55, Daniel Vetter wrote: On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote: On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: The concern is that this isn't how SIG_SEGV works, it's a signal the thread who made the invalid access gets directly. You never get a SIG_SEGV for bad access someone else has made. So essentially it's new ABI. SIGBUS. For which the answer is yes, you can and do get SIGBUS for actions taken by other processes. Oh right I always forget that SIGBUS aliases with SIGIO. Anyway if userspace wants SIGIO we just need to provide it with a pollable fd and then it can use fcntl to make that happen. That's imo a much better api than unconditionally throwing around signals. Also we already have the reset stats ioctl to tell userspace that its gpu context is toats. If anyone wants that to be pollable (or even send SIGIO) I think we should extend that, with all the usual "needs userspace&igt" stuff on top. I don't see that this notification can be optional. Process is confused about its memory map use so should die. :) This is not a GPU error/hang - this is the process doing stupid things. MMU notifiers do not support decision making otherwise we could say -ETXTBUSY or something on munmap, but we can't. Not even sure that it would help in all cases, would have to fail clone as well and who knows what. So what happens if the gpu just keeps using the memory? It'll all be horribly undefined behaviour and eventually it'll die on an -EFAULT in execbuf, but does anything else bad happen? We don't see an EFAULT unless a miracle occurs, and the stale pages continue to be read/written by other processes (as well as the client). Horribly undefined behaviour with a misinformation leak. -Chris I think SIGBUS would be a good notification. It's the sort of outcome you expect when a privileged thread on the CPU or any sort of DMA-master device incurs an access fault on physical memory or I/O mapped register space. One explanation I found suggests: Another reason where SIGBUS can generate is explained below: You are currently using a external I/O device by mapping the device memory mapping into the system memory (Memory mapped I/O). You have used it. And now, you have disconnected it gracefully. But, somehow your code is trying to use an previously used address still in your code. The result in this case will be an SIGBUS, the reason is BUS_ADRERR, "non-existent physical address". See http://cquestion.blogspot.com/2008/03/sigbus-vs-sigsegv.html In this case, (we assume that) the GPU is going to continue to access the "physical" (PPGTT?) address of the (virtual) memory that the process is trying to revoke its access to. And while it might make sense to remove a buffer from the CPU's mapping while the GPU was still accessing it, it really makes no sense to delete a GTT mapping that the GPU may still (asynchronously) be accessing. So either we have to kill the process's outstanding tasks on the GPU (context-specific reset?) or fail the unmap (and shoot the process for trying to sabotage the GPU?). Or ... could we decouple the pages? Duplicate them as for copy-on-write, and give one copy to the user process and the other to the GPU? Of course the actual content of the page might be indeterminate if the GPU were writing it while the CPU was taking a copy ... does this make any sense? .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump
On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote: > On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote: > > The error state is purposefully racy as we expect it to be called at any > > time and so have avoided any locking whilst capturing the crash dump. > > However, with multi-engine GPUs and multiple CPUs, those races can > > manifest into OOPSes as we attempt to chase dangling pointers freed on > > other CPUs. Under discussion are lots of ways to slow down normal > > operation in order to protect the post-mortem error capture, but what it > > we take the opposite approach and freeze the machine whilst the error > > catpure runs (note the GPU may still running, but as long as we don't > > process any of the results the driver's bookkeeping will be static). > > > > Signed-off-by: Chris Wilson > > One risk I see is that the list walking might still go off the rails when > we stop the machine right in the middle of a list_move. With that we might > start scanning the active list (of objects) on one engine and then midway > through get to another engine and so never see the list_head again, > looping forever. No idea yet what to do with that. A move is a del followed by an insertion, you cannot step into an entry that is the middle of moving lists - don't forget that stop_machine() is a very heavy memory barrier. Similarly, the list_add() should ensure we can't step forward into an element that will not lead back to the list. So I am not convinced that it would be suspectible to that style of hijacking. The only alternative I see to list walking, is not to do any from the error capture and rely on attaching enough information to the request (along with register state) to be able to do postmortems. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump
On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> The error state is purposefully racy as we expect it to be called at any
> time and so have avoided any locking whilst capturing the crash dump.
> However, with multi-engine GPUs and multiple CPUs, those races can
> manifest into OOPSes as we attempt to chase dangling pointers freed on
> other CPUs. Under discussion are lots of ways to slow down normal
> operation in order to protect the post-mortem error capture, but what it
> we take the opposite approach and freeze the machine whilst the error
> catpure runs (note the GPU may still running, but as long as we don't
> process any of the results the driver's bookkeeping will be static).
>
> Signed-off-by: Chris Wilson
One risk I see is that the list walking might still go off the rails when
we stop the machine right in the middle of a list_move. With that we might
start scanning the active list (of objects) on one engine and then midway
through get to another engine and so never see the list_head again,
looping forever. No idea yet what to do with that.
Intriguing approach nevertheless.
-Daniel
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gpu_error.c | 31 +--
> 3 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 99e819767204..63df28910c8f 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -7,6 +7,7 @@ config DRM_I915
> select AGP_INTEL if AGP
> select INTERVAL_TREE
> select ZLIB_DEFLATE
> + select STOP_MACHINE
> # we need shmfs for the swappable backing store, and in particular
> # the shmem_readpage() which depends upon tmpfs
> select SHMEM
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9d16fc1189d6..14a882fe486c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -488,6 +488,8 @@ struct drm_i915_error_state {
> struct kref ref;
> struct timeval time;
>
> + struct drm_i915_private *i915;
> +
> char error_msg[128];
> int iommu;
> u32 reset_count;
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 64bdffcffb50..29cbec67bcfc 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
> #include "i915_drv.h"
>
> static const char *yesno(int v)
> @@ -1352,6 +1353,24 @@ static void i915_capture_gen_state(struct
> drm_i915_private *dev_priv,
> error->suspend_count = dev_priv->suspend_count;
> }
>
> +static int capture(void *data)
> +{
> + struct drm_i915_error_state *error = data;
> +
> + i915_capture_gen_state(error->i915, error);
> + i915_capture_reg_state(error->i915, error);
> + i915_gem_capture_buffers(error->i915, error);
> + i915_gem_record_fences(error->i915->dev, error);
> + i915_gem_record_rings(error->i915->dev, error);
> +
> + do_gettimeofday(&error->time);
> +
> + error->overlay = intel_overlay_capture_error_state(error->i915->dev);
> + error->display = intel_display_capture_error_state(error->i915->dev);
> +
> + return 0;
> +}
> +
> /**
> * i915_capture_error_state - capture an error record for later analysis
> * @dev: drm device
> @@ -1377,17 +1396,9 @@ void i915_capture_error_state(struct drm_device *dev,
> bool wedged,
> }
>
> kref_init(&error->ref);
> + error->i915 = dev_priv;
>
> - i915_capture_gen_state(dev_priv, error);
> - i915_capture_reg_state(dev_priv, error);
> - i915_gem_capture_buffers(dev_priv, error);
> - i915_gem_record_fences(dev, error);
> - i915_gem_record_rings(dev, error);
> -
> - do_gettimeofday(&error->time);
> -
> - error->overlay = intel_overlay_capture_error_state(dev);
> - error->display = intel_display_capture_error_state(dev);
> + stop_machine(capture, error, NULL);
>
> i915_error_capture_msg(dev, error, wedged, error_msg);
> DRM_INFO("%s\n", error->error_msg);
> --
> 2.6.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS
On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote: > On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote: > > > > On 09/10/15 09:55, Daniel Vetter wrote: > > >On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote: > > >>On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: > > >>>On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: > > >>>The concern is that this isn't how SIG_SEGV works, it's a signal the > > >>>thread who made the invalid access gets directly. You never get a > > >>>SIG_SEGV > > >>>for bad access someone else has made. So essentially it's new ABI. > > >> > > >>SIGBUS. For which the answer is yes, you can and do get SIGBUS for > > >>actions taken by other processes. > > > > > >Oh right I always forget that SIGBUS aliases with SIGIO. Anyway if > > >userspace wants SIGIO we just need to provide it with a pollable fd and > > >then it can use fcntl to make that happen. That's imo a much better api > > >than unconditionally throwing around signals. Also we already have the > > >reset stats ioctl to tell userspace that its gpu context is toats. If > > >anyone wants that to be pollable (or even send SIGIO) I think we should > > >extend that, with all the usual "needs userspace&igt" stuff on top. > > > > I don't see that this notification can be optional. Process is confused > > about its memory map use so should die. :) > > > > This is not a GPU error/hang - this is the process doing stupid things. > > > > MMU notifiers do not support decision making otherwise we could say > > -ETXTBUSY or something on munmap, but we can't. Not even sure that it would > > help in all cases, would have to fail clone as well and who knows what. > > So what happens if the gpu just keeps using the memory? It'll all be > horribly undefined behaviour and eventually it'll die on an -EFAULT in > execbuf, but does anything else bad happen? We don't see an EFAULT unless a miracle occurs, and the stale pages continue to be read/written by other processes (as well as the client). Horribly undefined behaviour with a misinformation leak. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles
On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote: > On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote: > > On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote: > > > My idea was to create a new request for 3. which gets signalled by the > > > scheduler in intel_lrc_irq_handler. My idea was that we'd only create > > > these when a ctx switch might occur to avoid overhead, but I guess if we > > > just outright delay all requests a notch if need that might work too. But > > > I'm really not sure on the implications of that (i.e. does the hardware > > > really unlod the ctx if it's idle?), and whether that would fly still with > > > the scheduler. > > > > > > But figuring this one out here seems to be the cornestone of this reorg. > > > Without it we can't just throw contexts onto the active list. > > > > (Let me see if I understand it correctly) > > > > Basically the problem is that we can't trust the context object to be > > synchronized until after the status interrupt. The way we handled that > > for legacy is to track the currently bound context and keep the > > vma->pin_count asserted until the request containing the switch away. > > Doing the same for execlists would trivially fix the issue and if done > > smartly allows us to share more code (been there, done that). > > > > That satisfies me for keeping requests as a basic fence in the GPU > > timeline and should keep everyone happy that the context can't vanish > > until after it is complete. The only caveat is that we cannot evict the > > most recent context. For legacy, we do a switch back to the always > > pinned default context. For execlists we don't, but it still means we > > should only have one context which cannot be evicted (like legacy). But > > it does leave us with the issue that i915_gpu_idle() returns early and > > i915_gem_context_fini() must keep the explicit gpu reset to be > > absolutely sure that the pending context writes are completed before the > > final context is unbound. > > Yes, and that was what I originally had in mind. Meanwhile the scheduler > (will) happen and that means we won't have FIFO ordering. Which means when > we switch contexts (as opposed to just adding more to the ringbuffer of > the current one) we won't have any idea which context will be the next > one. Which also means we don't know which request to pick to retire the > old context. Hence why I think we need to be better. But the scheduler does - it is also in charge of making sure the retirement queue is in order. The essence is that we only actually pin engine->last_context, which is chosen as we submit stuff to the hw. > Of course we can first implement the legacy ctx scheme and then let John > Harrison deal with the mess again, but he might not like that too much ;-) > > The other upside of tracking the real ctx-no-longer-in-use with the ctx > itself is that we don't need to pin anything ever (I think), at least > conceptually. But decidedly less sure about that ... Right. There's still the reservation phase, but after that the pin just tracks the hw. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles
On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote: > On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote: > > My idea was to create a new request for 3. which gets signalled by the > > scheduler in intel_lrc_irq_handler. My idea was that we'd only create > > these when a ctx switch might occur to avoid overhead, but I guess if we > > just outright delay all requests a notch if need that might work too. But > > I'm really not sure on the implications of that (i.e. does the hardware > > really unlod the ctx if it's idle?), and whether that would fly still with > > the scheduler. > > > > But figuring this one out here seems to be the cornestone of this reorg. > > Without it we can't just throw contexts onto the active list. > > (Let me see if I understand it correctly) > > Basically the problem is that we can't trust the context object to be > synchronized until after the status interrupt. The way we handled that > for legacy is to track the currently bound context and keep the > vma->pin_count asserted until the request containing the switch away. > Doing the same for execlists would trivially fix the issue and if done > smartly allows us to share more code (been there, done that). > > That satisfies me for keeping requests as a basic fence in the GPU > timeline and should keep everyone happy that the context can't vanish > until after it is complete. The only caveat is that we cannot evict the > most recent context. For legacy, we do a switch back to the always > pinned default context. For execlists we don't, but it still means we > should only have one context which cannot be evicted (like legacy). But > it does leave us with the issue that i915_gpu_idle() returns early and > i915_gem_context_fini() must keep the explicit gpu reset to be > absolutely sure that the pending context writes are completed before the > final context is unbound. Yes, and that was what I originally had in mind. Meanwhile the scheduler (will) happen and that means we won't have FIFO ordering. Which means when we switch contexts (as opposed to just adding more to the ringbuffer of the current one) we won't have any idea which context will be the next one. Which also means we don't know which request to pick to retire the old context. Hence why I think we need to be better. Of course we can first implement the legacy ctx scheme and then let John Harrison deal with the mess again, but he might not like that too much ;-) The other upside of tracking the real ctx-no-longer-in-use with the ctx itself is that we don't need to pin anything ever (I think), at least conceptually. But decidedly less sure about that ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS
On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote: > > On 09/10/15 09:55, Daniel Vetter wrote: > >On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote: > >>On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: > >>>On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: > >>>The concern is that this isn't how SIG_SEGV works, it's a signal the > >>>thread who made the invalid access gets directly. You never get a SIG_SEGV > >>>for bad access someone else has made. So essentially it's new ABI. > >> > >>SIGBUS. For which the answer is yes, you can and do get SIGBUS for > >>actions taken by other processes. > > > >Oh right I always forget that SIGBUS aliases with SIGIO. Anyway if > >userspace wants SIGIO we just need to provide it with a pollable fd and > >then it can use fcntl to make that happen. That's imo a much better api > >than unconditionally throwing around signals. Also we already have the > >reset stats ioctl to tell userspace that its gpu context is toats. If > >anyone wants that to be pollable (or even send SIGIO) I think we should > >extend that, with all the usual "needs userspace&igt" stuff on top. > > I don't see that this notification can be optional. Process is confused > about its memory map use so should die. :) > > This is not a GPU error/hang - this is the process doing stupid things. > > MMU notifiers do not support decision making otherwise we could say > -ETXTBUSY or something on munmap, but we can't. Not even sure that it would > help in all cases, would have to fail clone as well and who knows what. So what happens if the gpu just keeps using the memory? It'll all be horribly undefined behaviour and eventually it'll die on an -EFAULT in execbuf, but does anything else bad happen? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 7/7] Replace __gem_mmap__{cpu, gtt, wc}() + igt_assert() with gem_mmap__{cpu, gtt, wc}()
On Fri, Oct 09, 2015 at 07:19:16PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> gem_mmap__{cpu,gtt,wc}() already has the assert built in, so replace
> __gem_mmap__{cpu,gtt,wc}() + igt_assert() with it.
>
> Mostly done with coccinelle, with some manual help:
> @@
> identifier I;
> expression E1, E2, E3, E4, E5, E6;
> @@
> (
> - I = __gem_mmap__gtt(E1, E2, E3, E4);
> + I = gem_mmap__gtt(E1, E2, E3, E4);
> ...
> - igt_assert(I);
> |
> - I = __gem_mmap__cpu(E1, E2, E3, E4, E5);
> + I = gem_mmap__cpu(E1, E2, E3, E4, E5);
> ...
> - igt_assert(I);
> |
> - I = __gem_mmap__wc(E1, E2, E3, E4, E5);
> + I = gem_mmap__wc(E1, E2, E3, E4, E5);
> ...
> - igt_assert(I);
> )
>
> Signed-off-by: Ville Syrjälä
Looks like by the end we miss a few asserts (a few too many __gem_mmap
left over), but that is just a continuation of the state of affairs.
Series lgtm,
Stochastically-reviwewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 7/7] Replace __gem_mmap__{cpu, gtt, wc}() + igt_assert() with gem_mmap__{cpu, gtt, wc}()
From: Ville Syrjälä
gem_mmap__{cpu,gtt,wc}() already has the assert built in, so replace
__gem_mmap__{cpu,gtt,wc}() + igt_assert() with it.
Mostly done with coccinelle, with some manual help:
@@
identifier I;
expression E1, E2, E3, E4, E5, E6;
@@
(
- I = __gem_mmap__gtt(E1, E2, E3, E4);
+ I = gem_mmap__gtt(E1, E2, E3, E4);
...
- igt_assert(I);
|
- I = __gem_mmap__cpu(E1, E2, E3, E4, E5);
+ I = gem_mmap__cpu(E1, E2, E3, E4, E5);
...
- igt_assert(I);
|
- I = __gem_mmap__wc(E1, E2, E3, E4, E5);
+ I = gem_mmap__wc(E1, E2, E3, E4, E5);
...
- igt_assert(I);
)
Signed-off-by: Ville Syrjälä
---
benchmarks/gem_blt.c | 3 +--
benchmarks/gem_mmap.c | 9 +++
lib/igt_draw.c | 9 +++
lib/igt_fb.c | 6 ++---
tests/drv_suspend.c| 10 +++
tests/gem_concurrent_all.c | 18 +
tests/gem_cs_tlb.c | 3 +--
tests/gem_evict_everything.c | 3 +--
tests/gem_exec_faulting_reloc.c| 5 ++--
tests/gem_exec_lut_handle.c| 3 +--
tests/gem_fence_thrash.c | 7 +++--
tests/gem_fence_upload.c | 12 +++--
tests/gem_gtt_cpu_tlb.c| 6 ++---
tests/gem_gtt_hog.c| 7 +++--
tests/gem_gtt_speed.c | 55 +++---
tests/gem_largeobject.c| 4 +--
tests/gem_mmap.c | 3 +--
tests/gem_mmap_gtt.c | 26 +++---
tests/gem_mmap_offset_exhaustion.c | 3 +--
tests/gem_mmap_wc.c| 21 +--
tests/gem_persistent_relocs.c | 6 ++---
tests/gem_pwrite.c | 3 +--
tests/gem_pwrite_pread.c | 24 ++---
tests/gem_reloc_vs_gpu.c | 5 ++--
tests/gem_set_tiling_vs_gtt.c | 3 +--
tests/gem_set_tiling_vs_pwrite.c | 3 +--
tests/gem_streaming_writes.c | 36 +++--
tests/gem_tiled_pread_basic.c | 4 +--
tests/gem_tiled_pread_pwrite.c | 7 +++--
tests/gem_tiled_swapping.c | 7 +++--
tests/gem_tiled_wb.c | 7 ++---
tests/gem_tiled_wc.c | 6 ++---
tests/gem_tiling_max_stride.c | 3 +--
tests/gem_userptr_blits.c | 11
tests/gen3_mixed_blits.c | 7 +++--
tests/gen3_render_mixed_blits.c| 7 +++--
tests/gen3_render_tiledx_blits.c | 7 +++--
tests/gen3_render_tiledy_blits.c | 7 +++--
tests/gen7_forcewake_mt.c | 3 +--
tests/kms_fbc_crc.c| 6 ++---
tests/kms_fence_pin_leak.c | 3 +--
tests/kms_psr_sink_crc.c | 10 +++
tests/pm_rpm.c | 20 +-
tests/prime_self_import.c | 6 ++---
tests/testdisplay.c| 5 ++--
45 files changed, 158 insertions(+), 261 deletions(-)
diff --git a/benchmarks/gem_blt.c b/benchmarks/gem_blt.c
index e722541..181a5f1 100644
--- a/benchmarks/gem_blt.c
+++ b/benchmarks/gem_blt.c
@@ -177,8 +177,7 @@ static int run(int object, int batch, int count, int reps)
fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, size);
- buf = __gem_mmap__cpu(fd, handle, 0, size, PROT_WRITE);
- igt_assert(buf);
+ buf = gem_mmap__cpu(fd, handle, 0, size, PROT_WRITE);
gen = intel_gen(intel_get_drm_devid(fd));
has_64bit_reloc = gen >= 8;
diff --git a/benchmarks/gem_mmap.c b/benchmarks/gem_mmap.c
index 571f757..bc26d31 100644
--- a/benchmarks/gem_mmap.c
+++ b/benchmarks/gem_mmap.c
@@ -115,18 +115,15 @@ int main(int argc, char **argv)
handle = gem_create(fd, OBJECT_SIZE);
switch (map) {
case CPU:
- ptr = __gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_WRITE);
- igt_assert(ptr);
+ ptr = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_WRITE);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_CPU,
I915_GEM_DOMAIN_CPU);
break;
case GTT:
- ptr = __gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_WRITE);
- igt_assert(ptr);
+ ptr = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_WRITE);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
break;
case WC:
- ptr = __gem_mmap__wc(fd, handle, 0, OBJECT_SIZE, PROT_WRITE);
- igt_assert(ptr);
+ ptr = gem_mmap__wc(fd, handle, 0, OBJECT_SIZE, PROT_WRITE);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
break;
default:
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 07aa812..f85e376 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -252,8 +252,7 @@ static void draw_rect_mmap_cpu(int fd, struct buf_data
*buf, struct rect *rect,
if (tiling != I915_TILING_NONE)
igt_require(intel_gen(intel_get_drm_devid(fd)) >= 5);
- ptr = __gem_mmap__cpu(
[Intel-gfx] [PATCH i-g-t 6/7] Make gem_mmap__{cpu, gtt, wc}() assert on failure
From: Ville Syrjälä
Rename the current gem_mmap__{cpu,gtt,wc}() functions into
__gem_mmap__{cpu,gtt,wc}(), and add back wrappers with the original name
that assert that the pointer is valid. Most callers will expect a valid
pointer and shouldn't have to bother with failures.
To avoid changing anything (yet), sed 's/gem_mmap__/__gem_mmap__/g'
over the entire codebase.
Signed-off-by: Ville Syrjälä
---
benchmarks/gem_blt.c | 2 +-
benchmarks/gem_exec_reloc.c| 6 ++--
benchmarks/gem_mmap.c | 6 ++--
demos/intel_sprite_on.c| 4 +--
lib/igt_draw.c | 6 ++--
lib/igt_fb.c | 4 +--
lib/ioctl_wrappers.c | 68 ++
lib/ioctl_wrappers.h | 4 +++
tests/drv_suspend.c| 6 ++--
tests/gem_concurrent_all.c | 14
tests/gem_cs_tlb.c | 2 +-
tests/gem_evict_everything.c | 2 +-
tests/gem_exec_big.c | 4 +--
tests/gem_exec_faulting_reloc.c| 2 +-
tests/gem_exec_lut_handle.c| 8 ++---
tests/gem_fence_thrash.c | 4 +--
tests/gem_fence_upload.c | 8 ++---
tests/gem_gtt_cpu_tlb.c| 4 +--
tests/gem_gtt_hog.c| 4 +--
tests/gem_gtt_speed.c | 30 -
tests/gem_largeobject.c| 2 +-
tests/gem_madvise.c| 4 +--
tests/gem_mmap.c | 4 +--
tests/gem_mmap_gtt.c | 24 +++---
tests/gem_mmap_offset_exhaustion.c | 2 +-
tests/gem_mmap_wc.c| 14
tests/gem_persistent_relocs.c | 2 +-
tests/gem_pwrite.c | 2 +-
tests/gem_pwrite_pread.c | 16 -
tests/gem_reloc_overflow.c | 2 +-
tests/gem_reloc_vs_gpu.c | 2 +-
tests/gem_set_tiling_vs_gtt.c | 2 +-
tests/gem_set_tiling_vs_pwrite.c | 2 +-
tests/gem_streaming_writes.c | 20 +--
tests/gem_tiled_pread_basic.c | 2 +-
tests/gem_tiled_pread_pwrite.c | 4 +--
tests/gem_tiled_swapping.c | 6 ++--
tests/gem_tiled_wb.c | 4 +--
tests/gem_tiled_wc.c | 4 +--
tests/gem_tiling_max_stride.c | 2 +-
tests/gem_userptr_blits.c | 8 ++---
tests/gen3_mixed_blits.c | 4 +--
tests/gen3_render_mixed_blits.c| 4 +--
tests/gen3_render_tiledx_blits.c | 4 +--
tests/gen3_render_tiledy_blits.c | 4 +--
tests/gen7_forcewake_mt.c | 2 +-
tests/kms_fbc_crc.c| 4 +--
tests/kms_fence_pin_leak.c | 2 +-
tests/kms_psr_sink_crc.c | 6 ++--
tests/pm_rpm.c | 12 +++
tests/prime_self_import.c | 4 +--
tests/testdisplay.c| 2 +-
52 files changed, 212 insertions(+), 152 deletions(-)
diff --git a/benchmarks/gem_blt.c b/benchmarks/gem_blt.c
index 3ed2300..e722541 100644
--- a/benchmarks/gem_blt.c
+++ b/benchmarks/gem_blt.c
@@ -177,7 +177,7 @@ static int run(int object, int batch, int count, int reps)
fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, size);
- buf = gem_mmap__cpu(fd, handle, 0, size, PROT_WRITE);
+ buf = __gem_mmap__cpu(fd, handle, 0, size, PROT_WRITE);
igt_assert(buf);
gen = intel_gen(intel_get_drm_devid(fd));
diff --git a/benchmarks/gem_exec_reloc.c b/benchmarks/gem_exec_reloc.c
index 274ce41..5be482a 100644
--- a/benchmarks/gem_exec_reloc.c
+++ b/benchmarks/gem_exec_reloc.c
@@ -115,13 +115,13 @@ static int run(unsigned batch_size,
if (num_relocs) {
size = ALIGN(sizeof(*mem_reloc)*num_relocs, 4096);
reloc_handle = gem_create(fd, size);
- reloc = gem_mmap__cpu(fd, reloc_handle, 0, size, PROT_READ |
PROT_WRITE);
+ reloc = __gem_mmap__cpu(fd, reloc_handle, 0, size, PROT_READ |
PROT_WRITE);
memcpy(reloc, mem_reloc, sizeof(*mem_reloc)*num_relocs);
munmap(reloc, size);
if (flags & FAULT) {
igt_disable_prefault();
- reloc = gem_mmap__cpu(fd, reloc_handle, 0, size,
PROT_READ | PROT_WRITE);
+ reloc = __gem_mmap__cpu(fd, reloc_handle, 0, size,
PROT_READ | PROT_WRITE);
} else
reloc = mem_reloc;
}
@@ -162,7 +162,7 @@ static int run(unsigned batch_size,
}
if (flags & FAULT && reloc) {
munmap(reloc, size);
- reloc = gem_mmap__cpu(fd, reloc_handle, 0,
size, PROT_READ | PROT_WRITE);
+ reloc = __gem_mmap__cpu(fd, reloc_handle, 0,
size, PROT_READ | PROT_WRITE);
gem_exec[num_objects].relocs_ptr =
(uintptr_t)reloc;
}
gem_execbuf(fd, &execbuf);
diff -
Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling
On 10/09/2015 02:07 AM, David Woodhouse wrote: > On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote: >> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote: >>> On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote: Hm if this still works the same way as on older platforms then pagefaults just read all 0 and writes go nowhere from the gpu. That generally also explains ever-increasing numbers of the CS execution pointer since it's busy churning through 48b worth of address space filled with MI_NOP. I'd have hoped our hw would do better than that with svm ... >>> >>> I'm looking at simple cases like Jesse's 'gem_svm_fault' test. If the >>> access to process address space (a single dword write) does nothing, >>> I'm not sure why it would then churn through MI_NOOPs; why would the >>> batch still not complete? >> >> Yeah that testcase doesn't fit, the one I had in mind is where the batch >> itself faults and the CS just reads MI_NOP forever. No idea why the gpu >> just keeps walking through the address space here. Puzzling. > > Does it just keep walking through the address space? > > When I hacked my page request handler to *not* service the fault and > just say it failed, the batch did seem to complete as normal. Just > without doing the write, as you described. My understanding is that this behavior will depend on how we submit the work. We have to faulting modes: halt and stream. In either case, the context that faults will be switched out, and the hardware will either wait for a resubmit (the halt case) to restart the context, or switch to the next context in the execlist queue. If the fault is then serviced by the IOMMU layer, potentially as an error, I'd expect the faulting context to simply fault again. I don't think we'd see a GPU hang in the same way we do today, where we get an indication in the GPU private fault regs and such; they go through the IOMMU in advanced context mode. So I think we'll need a callback in the fatal case; we can just kick off a private i915 worker for that, just like we do for the recoverable case that's now hidden in the IOMMU layer. Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/7] s/gem_mmap/gem_mmap__gtt/
From: Ville Syrjälä
Get rid of the gem_mmap() alias of gem_mmap__gtt(). I don't see any
point in having it.
Signed-off-by: Ville Syrjälä
---
demos/intel_sprite_on.c| 4 ++--
lib/igt_fb.c | 2 +-
lib/ioctl_wrappers.h | 16
tests/drv_suspend.c| 6 +++---
tests/gem_exec_faulting_reloc.c| 2 +-
tests/gem_fence_thrash.c | 2 +-
tests/gem_fence_upload.c | 6 +++---
tests/gem_gtt_cpu_tlb.c| 4 ++--
tests/gem_gtt_hog.c| 4 ++--
tests/gem_gtt_speed.c | 12 ++--
tests/gem_madvise.c| 4 ++--
tests/gem_mmap_gtt.c | 10 +-
tests/gem_mmap_offset_exhaustion.c | 2 +-
tests/gem_persistent_relocs.c | 2 +-
tests/gem_reloc_overflow.c | 2 +-
tests/gem_reloc_vs_gpu.c | 2 +-
tests/gem_set_tiling_vs_gtt.c | 2 +-
tests/gem_set_tiling_vs_pwrite.c | 2 +-
tests/gem_tiled_pread_basic.c | 2 +-
tests/gem_tiled_pread_pwrite.c | 4 ++--
tests/gem_tiled_swapping.c | 6 +++---
tests/gem_tiling_max_stride.c | 2 +-
tests/gem_userptr_blits.c | 2 +-
tests/gen3_mixed_blits.c | 4 ++--
tests/gen3_render_mixed_blits.c| 4 ++--
tests/gen3_render_tiledx_blits.c | 4 ++--
tests/gen3_render_tiledy_blits.c | 4 ++--
tests/gen7_forcewake_mt.c | 2 +-
tests/prime_self_import.c | 4 ++--
tests/testdisplay.c| 2 +-
30 files changed, 54 insertions(+), 70 deletions(-)
diff --git a/demos/intel_sprite_on.c b/demos/intel_sprite_on.c
index 23fc56c..4083070 100644
--- a/demos/intel_sprite_on.c
+++ b/demos/intel_sprite_on.c
@@ -359,7 +359,7 @@ static int prepare_primary_surface(int fd, int prim_width,
int prim_height,
if (tiled)
gem_set_tiling(fd, *prim_handle, I915_TILING_X, *prim_stride);
- prim_fb_ptr = gem_mmap(fd, *prim_handle, *prim_size, PROT_READ |
PROT_WRITE);
+ prim_fb_ptr = gem_mmap__gtt(fd, *prim_handle, *prim_size, PROT_READ |
PROT_WRITE);
if (prim_fb_ptr != NULL) {
// Write primary surface with gray background
@@ -454,7 +454,7 @@ static int prepare_sprite_surfaces(int fd, int
sprite_width, int sprite_height,
gem_set_tiling(fd, sprite_handles[i], I915_TILING_X,
*sprite_stride);
// Get pointer to the surface
- sprite_fb_ptr = gem_mmap(fd,
+ sprite_fb_ptr = gem_mmap__gtt(fd,
sprite_handles[i], *sprite_size,
PROT_READ | PROT_WRITE);
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index d04f02c..713bd50 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -775,7 +775,7 @@ static void destroy_cairo_surface__gtt(void *arg)
static void create_cairo_surface__gtt(int fd, struct igt_fb *fb)
{
fb->cairo_surface =
- cairo_image_surface_create_for_data(gem_mmap(fd,
fb->gem_handle, fb->size, PROT_READ | PROT_WRITE),
+ cairo_image_surface_create_for_data(gem_mmap__gtt(fd,
fb->gem_handle, fb->size, PROT_READ | PROT_WRITE),
drm_format_to_cairo(fb->drm_format),
fb->width, fb->height,
fb->stride);
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index f4deca6..7c607a2 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -76,22 +76,6 @@ void *gem_mmap__wc(int fd, uint32_t handle, uint64_t offset,
uint64_t size, unsi
*/
#define gem_require_mmap_wc(fd) igt_require(gem_mmap__has_wc(fd))
-/**
- * gem_mmap:
- * @fd: open i915 drm file descriptor
- * @handle: gem buffer object handle
- * @size: size of the gem buffer
- * @prot: memory protection bits as used by mmap()
- *
- * This functions wraps up procedure to establish a memory mapping through the
- * GTT.
- *
- * This is a simple convenience alias to gem_mmap__gtt()
- *
- * Returns: A pointer to the created memory mapping.
- */
-#define gem_mmap(fd, handle, size, prot) gem_mmap__gtt(fd, handle, size, prot)
-
int gem_madvise(int fd, uint32_t handle, int state);
uint32_t gem_context_create(int fd);
diff --git a/tests/drv_suspend.c b/tests/drv_suspend.c
index c8af46b..4014241 100644
--- a/tests/drv_suspend.c
+++ b/tests/drv_suspend.c
@@ -56,19 +56,19 @@ test_fence_restore(int fd, bool tiled2untiled, bool
hibernate)
handle_tiled = gem_create(fd, OBJECT_SIZE);
/* Access the buffer objects in the order we want to have the laid out.
*/
- ptr1 = gem_mmap(fd, handle1, OBJECT_SIZE, PROT_READ | PROT_WRITE);
+ ptr1 = gem_mmap__gtt(fd, handle1, OBJECT_SIZE, PROT_READ | PROT_WRITE);
igt_assert(ptr1 != MAP_FAILED);
for (i = 0; i < OBJECT_SIZE/sizeof(uint32_t); i++)
ptr1[i] = i;
- ptr_tiled = gem_mmap(fd, handle_tiled, OBJECT_SIZE, PROT_READ |
PROT_WRITE);
+
[Intel-gfx] [PATCH i-g-t 2/7] lib: Document that gem_mmap__{cpu, gtt, wc} return NULL on failure
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
lib/ioctl_wrappers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 80e1ec6..eb745bc 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -456,7 +456,7 @@ void gem_execbuf(int fd, struct drm_i915_gem_execbuffer2
*execbuf)
* This functions wraps up procedure to establish a memory mapping through the
* GTT.
*
- * Returns: A pointer to the created memory mapping.
+ * Returns: A pointer to the created memory mapping, NULL on failure.
*/
void *gem_mmap__gtt(int fd, uint32_t handle, uint64_t size, unsigned prot)
{
@@ -535,7 +535,7 @@ bool gem_mmap__has_wc(int fd)
* bypassing the GTT system agent (i.e. there is no automatic tiling of
* the mmapping through the fence registers).
*
- * Returns: A pointer to the created memory mapping.
+ * Returns: A pointer to the created memory mapping, NULL on failure.
*/
void *gem_mmap__wc(int fd, uint32_t handle, uint64_t offset, uint64_t size,
unsigned prot)
{
@@ -569,7 +569,7 @@ void *gem_mmap__wc(int fd, uint32_t handle, uint64_t
offset, uint64_t size, unsi
* This functions wraps up procedure to establish a memory mapping through
* direct cpu access, bypassing the gpu completely.
*
- * Returns: A pointer to the created memory mapping.
+ * Returns: A pointer to the created memory mapping, NULL on failure.
*/
void *gem_mmap__cpu(int fd, uint32_t handle, uint64_t offset, uint64_t size,
unsigned prot)
{
--
2.4.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/7] Sprinkle igt_assert(ptr) after gem_mmap__{cpu, gtt, wc}
From: Ville Syrjälä
Do the following
ptr = gem_mmap__{cpu,gtt,wc}()
+igt_assert(ptr);
whenever the code doesn't handle the NULL ptr in any kind of
specific way.
Makes it easier to move the assert into gem_mmap__{cpu,gtt,wc}() itself.
Mostly done with coccinelle, with some manual cleanups:
@@
identifier I;
@@
<... when != igt_assert(I)
when != igt_require(I)
when != igt_require_f(I, ...)
when != I != NULL
when != I == NULL
(
I = gem_mmap__gtt(...);
+ igt_assert(I);
|
I = gem_mmap__cpu(...);
+ igt_assert(I);
|
I = gem_mmap__wc(...);
+ igt_assert(I);
)
...>
Signed-off-by: Ville Syrjälä
---
benchmarks/gem_blt.c | 1 +
benchmarks/gem_mmap.c | 3 +++
tests/gem_cs_tlb.c | 1 +
tests/gem_exec_lut_handle.c| 1 +
tests/gem_gtt_cpu_tlb.c| 2 ++
tests/gem_gtt_hog.c| 5 -
tests/gem_gtt_speed.c | 18 ++
tests/gem_largeobject.c| 1 +
tests/gem_mmap.c | 1 +
tests/gem_pwrite_pread.c | 8
tests/gem_streaming_writes.c | 8 ++--
tests/gem_tiled_pread_basic.c | 1 +
tests/gem_tiled_pread_pwrite.c | 2 ++
tests/gem_tiled_swapping.c | 1 +
tests/gem_tiled_wb.c | 1 +
tests/gem_tiled_wc.c | 1 +
tests/gem_userptr_blits.c | 2 ++
tests/gen7_forcewake_mt.c | 1 +
tests/kms_fbc_crc.c| 2 ++
tests/kms_fence_pin_leak.c | 1 +
tests/kms_psr_sink_crc.c | 3 +++
tests/pm_rpm.c | 18 ++
tests/prime_self_import.c | 4 ++--
23 files changed, 77 insertions(+), 9 deletions(-)
diff --git a/benchmarks/gem_blt.c b/benchmarks/gem_blt.c
index 181a5f1..3ed2300 100644
--- a/benchmarks/gem_blt.c
+++ b/benchmarks/gem_blt.c
@@ -178,6 +178,7 @@ static int run(int object, int batch, int count, int reps)
fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, size);
buf = gem_mmap__cpu(fd, handle, 0, size, PROT_WRITE);
+ igt_assert(buf);
gen = intel_gen(intel_get_drm_devid(fd));
has_64bit_reloc = gen >= 8;
diff --git a/benchmarks/gem_mmap.c b/benchmarks/gem_mmap.c
index bc26d31..6bf7fd3 100644
--- a/benchmarks/gem_mmap.c
+++ b/benchmarks/gem_mmap.c
@@ -116,14 +116,17 @@ int main(int argc, char **argv)
switch (map) {
case CPU:
ptr = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_WRITE);
+ igt_assert(ptr);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_CPU,
I915_GEM_DOMAIN_CPU);
break;
case GTT:
ptr = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_WRITE);
+ igt_assert(ptr);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
break;
case WC:
ptr = gem_mmap__wc(fd, handle, 0, OBJECT_SIZE, PROT_WRITE);
+ igt_assert(ptr);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
break;
default:
diff --git a/tests/gem_cs_tlb.c b/tests/gem_cs_tlb.c
index 8b640fa..a647ddf 100644
--- a/tests/gem_cs_tlb.c
+++ b/tests/gem_cs_tlb.c
@@ -117,6 +117,7 @@ static void run_on_ring(int fd, unsigned ring_id, const
char *ring_name)
handle_new = gem_create(fd, BATCH_SIZE);
batch_ptr = gem_mmap__cpu(fd, handle_new, 0, BATCH_SIZE,
PROT_READ | PROT_WRITE);
+ igt_assert(batch_ptr);
batch_ptr[split*2] = MI_BATCH_BUFFER_END;
for (i = split*2 + 2; i < BATCH_SIZE/8; i++)
diff --git a/tests/gem_exec_lut_handle.c b/tests/gem_exec_lut_handle.c
index 875fea2..282fccf 100644
--- a/tests/gem_exec_lut_handle.c
+++ b/tests/gem_exec_lut_handle.c
@@ -124,6 +124,7 @@ igt_simple_main
size = ALIGN(sizeof(mem_reloc), 4096);
reloc_handle = gem_create(fd, size);
reloc = gem_mmap__cpu(fd, reloc_handle, 0, size, PROT_READ |
PROT_WRITE);
+ igt_assert(reloc);
for (n = 0; n < MAX_NUM_RELOC; n++) {
reloc[n].offset = 1024;
reloc[n].read_domains = I915_GEM_DOMAIN_RENDER;
diff --git a/tests/gem_gtt_cpu_tlb.c b/tests/gem_gtt_cpu_tlb.c
index 8ceef44..75c3d04 100644
--- a/tests/gem_gtt_cpu_tlb.c
+++ b/tests/gem_gtt_cpu_tlb.c
@@ -60,6 +60,7 @@ create_bo(int fd)
/* Fill the BO with dwords starting at start_val */
data = gem_mmap__gtt(fd, handle, OBJ_SIZE, PROT_READ | PROT_WRITE);
+ igt_assert(data);
for (i = 0; i < OBJ_SIZE/4; i++)
data[i] = i;
munmap(data, OBJ_SIZE);
@@ -83,6 +84,7 @@ igt_simple_main
/* touch one page */
ptr = gem_mmap__gtt(fd, handle, OBJ_SIZE, PROT_READ | PROT_WRITE);
+ igt_assert(ptr);
*ptr = 0xdeadbeef;
munmap(ptr, OBJ_SIZE);
diff --git a/tests/gem_gtt_hog.c b/tests/gem_gtt_hog.c
index b0673a4..cbb7016 100644
--- a/tests/gem_gtt_hog.c
[Intel-gfx] [PATCH i-g-t 3/7] Remove gem_mmap__{cpu, gtt, wc} return value MAP_FAILED asserts
From: Ville Syrjälä
gem_mmap__{cpu,gtt,wc} never return MAP_FAILED, it gets converted to
NULL internally. So don't go asserting that the returned value is
not MAP_FAILED.
Done with coccinelle:
@@
type T;
identifier I;
@@
(
I = gem_mmap__gtt(...);
|
I = gem_mmap__cpu(...);
|
I = gem_mmap__wc(...);
)
...
(
- igt_assert(I != MAP_FAILED);
+ igt_assert(I);
|
- igt_assert(I && I != MAP_FAILED);
+ igt_assert(I);
|
- igt_assert(I != (T *) MAP_FAILED);
+ igt_assert(I);
|
- igt_assert(I != NULL);
+ igt_assert(I);
)
Signed-off-by: Ville Syrjälä
---
tests/drv_suspend.c| 6 +++---
tests/gem_concurrent_all.c | 12 ++--
tests/gem_madvise.c| 2 +-
tests/gem_mmap_gtt.c | 12 ++--
tests/gem_mmap_wc.c| 14 +++---
tests/gem_userptr_blits.c | 2 +-
6 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/tests/drv_suspend.c b/tests/drv_suspend.c
index 4014241..4e84d1c 100644
--- a/tests/drv_suspend.c
+++ b/tests/drv_suspend.c
@@ -57,19 +57,19 @@ test_fence_restore(int fd, bool tiled2untiled, bool
hibernate)
/* Access the buffer objects in the order we want to have the laid out.
*/
ptr1 = gem_mmap__gtt(fd, handle1, OBJECT_SIZE, PROT_READ | PROT_WRITE);
- igt_assert(ptr1 != MAP_FAILED);
+ igt_assert(ptr1);
for (i = 0; i < OBJECT_SIZE/sizeof(uint32_t); i++)
ptr1[i] = i;
ptr_tiled = gem_mmap__gtt(fd, handle_tiled, OBJECT_SIZE, PROT_READ |
PROT_WRITE);
- igt_assert(ptr_tiled != MAP_FAILED);
+ igt_assert(ptr_tiled);
if (tiled2untiled)
gem_set_tiling(fd, handle_tiled, I915_TILING_X, 2048);
for (i = 0; i < OBJECT_SIZE/sizeof(uint32_t); i++)
ptr_tiled[i] = i;
ptr2 = gem_mmap__gtt(fd, handle2, OBJECT_SIZE, PROT_READ | PROT_WRITE);
- igt_assert(ptr2 != MAP_FAILED);
+ igt_assert(ptr2);
for (i = 0; i < OBJECT_SIZE/sizeof(uint32_t); i++)
ptr2[i] = i;
diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
index 167f383..6efb977 100644
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -472,9 +472,9 @@ static void cpu_copy_bo(drm_intel_bo *dst, drm_intel_bo
*src)
gem_set_domain(fd, src->handle, I915_GEM_DOMAIN_CPU, 0);
gem_set_domain(fd, dst->handle, I915_GEM_DOMAIN_CPU,
I915_GEM_DOMAIN_CPU);
s = gem_mmap__cpu(fd, src->handle, 0, size, PROT_READ);
- igt_assert(s != NULL);
+ igt_assert(s);
d = gem_mmap__cpu(fd, dst->handle, 0, size, PROT_WRITE);
- igt_assert(d != NULL);
+ igt_assert(d);
memcpy(d, s, size);
@@ -491,9 +491,9 @@ static void gtt_copy_bo(drm_intel_bo *dst, drm_intel_bo
*src)
gem_set_domain(fd, dst->handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
s = gem_mmap__gtt(fd, src->handle, size, PROT_READ);
- igt_assert(s != NULL);
+ igt_assert(s);
d = gem_mmap__gtt(fd, dst->handle, size, PROT_WRITE);
- igt_assert(d != NULL);
+ igt_assert(d);
memcpy(d, s, size);
@@ -510,9 +510,9 @@ static void wc_copy_bo(drm_intel_bo *dst, drm_intel_bo *src)
gem_set_domain(fd, dst->handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
s = gem_mmap__wc(fd, src->handle, 0, size, PROT_READ);
- igt_assert(s != NULL);
+ igt_assert(s);
d = gem_mmap__wc(fd, dst->handle, 0, size, PROT_WRITE);
- igt_assert(d != NULL);
+ igt_assert(d);
memcpy(d, s, size);
diff --git a/tests/gem_madvise.c b/tests/gem_madvise.c
index 359f490..d0f378e 100644
--- a/tests/gem_madvise.c
+++ b/tests/gem_madvise.c
@@ -78,7 +78,7 @@ dontneed_after_mmap(void)
handle = gem_create(fd, OBJECT_SIZE);
ptr = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_READ | PROT_WRITE);
- igt_assert(ptr != NULL);
+ igt_assert(ptr);
gem_madvise(fd, handle, I915_MADV_DONTNEED);
close(fd);
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 1624a6b..5b782c9 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -57,7 +57,7 @@ mmap_bo(int fd, uint32_t handle)
void *ptr;
ptr = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_READ | PROT_WRITE);
- igt_assert(ptr != MAP_FAILED);
+ igt_assert(ptr);
return ptr;
}
@@ -180,7 +180,7 @@ test_read_write(int fd, enum test_read_write order)
handle = gem_create(fd, OBJECT_SIZE);
ptr = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_READ | PROT_WRITE);
- igt_assert(ptr != MAP_FAILED);
+ igt_assert(ptr);
if (order == READ_BEFORE_WRITE) {
val = *(uint32_t *)ptr;
@@ -204,10 +204,10 @@ test_read_write2(int fd, enum test_read_write order)
handle = gem_create(fd, OBJECT_SIZE);
r = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_READ);
- igt_assert(r != MAP_FAILED);
+ igt_assert(r);
w = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_R
[Intel-gfx] [PATCH i-g-t 5/7] lib: Die if framebuffer GTT mapping fails
From: Ville Syrjälä
Cairo helpfully allocates a new buffer for us when
cairo_image_surface_create_for_data() is called with a NULL ptr. That
means if gem_mmap__gtt() fails, we get a totally silent failure and
nothing ever drawn into the framebuffer. Very confusing.
Put in an igt_assert() to make sure we managed to mmap something.
Signed-off-by: Ville Syrjälä
---
lib/igt_fb.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 713bd50..e225f8a 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -774,8 +774,11 @@ static void destroy_cairo_surface__gtt(void *arg)
static void create_cairo_surface__gtt(int fd, struct igt_fb *fb)
{
+ void *ptr = gem_mmap__gtt(fd, fb->gem_handle, fb->size, PROT_READ |
PROT_WRITE);
+ igt_assert(ptr);
+
fb->cairo_surface =
- cairo_image_surface_create_for_data(gem_mmap__gtt(fd,
fb->gem_handle, fb->size, PROT_READ | PROT_WRITE),
+ cairo_image_surface_create_for_data(ptr,
drm_format_to_cairo(fb->drm_format),
fb->width, fb->height,
fb->stride);
--
2.4.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/i915: add fences to the request struct
On 10/09/2015 06:29 AM, David Woodhouse wrote:
> On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
>>
>> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
>> /** Execlists no. of times this request has been sent to the ELSP */
>> int elsp_submitted;
>>
>> + /* core fence obj for this request, may be exported */
>> + struct fence fence;
>
> As discussed, this doesn't work as-is. The final fence_put() will
> attempt to free(&req->fence). Unless you have a .release method in your
> fence ops, which you don't.
>
> I suppose we could tie up a .release method with the existing release
> method for the drm_i915_gem_request.
>
> As things stand, though, bad things are happening. This makes it go
> away and at least lets me get on with testing.
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8ef19e2..2d0c93c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2297,7 +2298,7 @@ struct drm_i915_gem_request {
> int elsp_submitted;
>
> /* core fence obj for this request, may be exported */
> - struct fence fence;
> + struct fence *fence;
>
> wait_queue_t wait;
> };
> diff --git a/drivers/gpu/drm/i915/i915_sync.c
> b/drivers/gpu/drm/i915/i915_sync.c
> index 085f1f9..6ffe273 100644
> --- a/drivers/gpu/drm/i915/i915_sync.c
> +++ b/drivers/gpu/drm/i915/i915_sync.c
> @@ -58,7 +58,12 @@ struct i915_sync_timeline {
> * allow non-RCS fences (need ring/context association)
> */
>
> -#define to_i915_request(x) container_of(x, struct drm_i915_gem_request,
> fence)
> +struct foo {
> + struct fence fence;
> + struct drm_i915_gem_request *req;
> +};
> +
> +#define to_i915_request(x) (((struct foo *)(x))->req)
>
> static const char *i915_fence_get_driver_name(struct fence *fence)
> {
> @@ -81,10 +86,10 @@ static int i915_fence_ring_check(wait_queue_t *wait,
> unsigned mode, int flags,
> if (!i915_gem_request_completed(req, false))
> return 0;
>
> - fence_signal_locked(&req->fence);
> + fence_signal_locked(req->fence);
>
> __remove_wait_queue(&ring->irq_queue, wait);
> - fence_put(&req->fence);
> + fence_put(req->fence);
> ring->irq_put(ring);
>
> return 0;
> @@ -200,6 +205,15 @@ struct fence *i915_fence_create_ring(struct
> intel_engine_cs *ring,
> if (ret)
> return ERR_PTR(ret);
>
> + request->fence = kmalloc(sizeof(struct foo), GFP_KERNEL);
> + if (!request->fence) {
> + ret = -ENOMEM;
> + goto err_cancel;
> + }
> + /* I have no clue how this is *supposed* to work and no real interest
> +in finding out. Just stop hurting me please. */
> + ((struct foo *)request->fence)->req = request;
> +
> if (i915.enable_execlists) {
> ringbuf = ctx->engine[ring->id].ringbuf;
> } else
> @@ -270,10 +284,10 @@ struct fence *i915_fence_create_ring(struct
> intel_engine_cs *ring,
> round_jiffies_up_relative(HZ));
> intel_mark_busy(dev_priv->dev);
>
> - fence_init(&request->fence, &i915_fence_ring_ops, &fence_lock,
> + fence_init(request->fence, &i915_fence_ring_ops, &fence_lock,
> ctx->user_handle, request->seqno);
>
> - return &request->fence;
> + return request->fence;
>
> err_cancel:
> i915_gem_request_cancel(request);
> @@ -306,10 +320,10 @@ static struct fence *i915_fence_create_display(struct
> intel_context *ctx)
>
> req = ring->outstanding_lazy_request;
>
> - fence_init(&req->fence, &i915_fence_ops, &fence_lock,
> + fence_init(req->fence, &i915_fence_ops, &fence_lock,
> ctx->user_handle, req->seqno);
>
> - return &req->fence;
> + return req->fence;
> }
> #endif
Yeah this is definitely better than what I had (untested code and all
that). But the actual signaling and such still needs work. I had a
question for Maarten on that actually; today it doesn't look like the
fence would enabling signaling at the right point, so I had to add
something. But I'll look and see what the latest is here from John H; I
know his Android code worked, so it would probably be best to just use that.
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Propagating correct error codes to the userspace
On 08/10/15 11:22, Tvrtko Ursulin wrote: Hi, On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Propagating correct error codes to userspace by using ERR_PTR and PTR_ERR macros for stolen memory based object allocation. We generally return -ENOMEM to the user whenever there is a failure in object allocation. This patch helps user to identify the correct reason for the failure and not just -ENOMEM each time. v2: Moved the patch up in the series, added error propagation for i915_gem_alloc_object too (Chris) Signed-off-by: Ankitprasad Sharma --- drivers/gpu/drm/i915/i915_gem.c | 15 +- drivers/gpu/drm/i915/i915_gem_batch_pool.c | 4 +-- drivers/gpu/drm/i915/i915_gem_context.c | 4 +-- drivers/gpu/drm/i915/i915_gem_render_state.c | 4 +-- drivers/gpu/drm/i915/i915_gem_stolen.c | 43 drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_fbdev.c | 6 ++-- drivers/gpu/drm/i915/intel_lrc.c | 8 +++--- drivers/gpu/drm/i915/intel_overlay.c | 4 +-- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++--- 12 files changed, 61 insertions(+), 55 deletions(-) [snip] diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 792d0b9..3901698 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -646,8 +646,8 @@ static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev, struct drm_i915_gem_object *obj; obj = i915_gem_alloc_object(dev, size); -if (!obj) -return NULL; +if (IS_ERR(obj)) +return obj; You have to change kerneldoc for this function now. And even more importantly update error handling in the callers! Or more simply, stop propagating the specific error at this level (it doesn't really help and probably can't even happen here), making this: >> obj = i915_gem_alloc_object(dev, size); >> -if (!obj) >> +if (IS_ERR(obj)) leaving the "return NULL;" unchanged. .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] Deciding on #!/bin/bash or #!/bin/sh
On 09/10/15 15:04, Joonas Lahtinen wrote:
Currently the shell scripts (+ a couple of 'execl') in intel-gpu-tools
are are using a mix of #!/bin/bash (13) or #!/bin/sh shebangs (6). Also
5 of the #!/bin/bash scripts do source a #!/bin/sh script.
I think we should have it unified, either drop Bash dependency
completely or convert all scripts (and execl) to use it.
Most of the scripts are not using any features at all that they would
require a #!/bin/bash shebang or could not be trivially converted to be
#!/bin/sh compliant. Most have actually been written with #!/bin/bash
shebang but still with constructs like 'if [ "x${FOO}" = "x" ]' which
basically are used for compatability with ancient shells. Explained at
http://stackoverflow.com/a/6853353 .
I'd say the bash shebang is there just because author wrote it by
habit.
In favor of #!/bin/bash there is the point made by Damien (CC'd) that
it'll rule out the incoming bug reports that are due to alternative
shell environments.
In favor of #!/bin/sh NetBSD people (CC'd) informed they'll be glad to
see bash requirement go.
How about Android, does it make a difference there?
My view on this is that converting everything to #!/bin/sh allows using
BusyBox shell which makes the minimal testing build less complex. So
I'm in favor of converting to #!/bin/sh.
I'll just mention "#!/usr/bin/env sh" as potentially more portable
option, for even more confusion. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] Deciding on #!/bin/bash or #!/bin/sh
Hi Joonas,
On android /bin does not exist. It is /system/bin/sh (there is no
/system/bin/bash) so the script needs to be executed specifying the shell to
override the shebang anyway. e.g. '/system/bin/sh script.sh'
Currently the script type tests are not run on android as the build system does
not copy them to the target file system. However I was planning on trying to
fix that at some point.
So the android vote would be for #!/bin/sh as using bash would preclude ever
being able to run the scripts on android.
//Derek
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Joonas Lahtinen
Sent: Friday, October 9, 2015 3:04 PM
To: Intel graphics driver community testing & development
Cc: c...@netbsd.org; Wood, Thomas; riastr...@netbsd.org
Subject: [Intel-gfx] [RFC i-g-t] Deciding on #!/bin/bash or #!/bin/sh
Currently the shell scripts (+ a couple of 'execl') in intel-gpu-tools are are
using a mix of #!/bin/bash (13) or #!/bin/sh shebangs (6). Also
5 of the #!/bin/bash scripts do source a #!/bin/sh script.
I think we should have it unified, either drop Bash dependency completely or
convert all scripts (and execl) to use it.
Most of the scripts are not using any features at all that they would require a
#!/bin/bash shebang or could not be trivially converted to be #!/bin/sh
compliant. Most have actually been written with #!/bin/bash shebang but still
with constructs like 'if [ "x${FOO}" = "x" ]' which basically are used for
compatability with ancient shells. Explained at
http://stackoverflow.com/a/6853353 .
I'd say the bash shebang is there just because author wrote it by habit.
In favor of #!/bin/bash there is the point made by Damien (CC'd) that it'll
rule out the incoming bug reports that are due to alternative shell
environments.
In favor of #!/bin/sh NetBSD people (CC'd) informed they'll be glad to see bash
requirement go.
How about Android, does it make a difference there?
My view on this is that converting everything to #!/bin/sh allows using BusyBox
shell which makes the minimal testing build less complex. So I'm in favor of
converting to #!/bin/sh.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t] Deciding on #!/bin/bash or #!/bin/sh
Currently the shell scripts (+ a couple of 'execl') in intel-gpu-tools
are are using a mix of #!/bin/bash (13) or #!/bin/sh shebangs (6). Also
5 of the #!/bin/bash scripts do source a #!/bin/sh script.
I think we should have it unified, either drop Bash dependency
completely or convert all scripts (and execl) to use it.
Most of the scripts are not using any features at all that they would
require a #!/bin/bash shebang or could not be trivially converted to be
#!/bin/sh compliant. Most have actually been written with #!/bin/bash
shebang but still with constructs like 'if [ "x${FOO}" = "x" ]' which
basically are used for compatability with ancient shells. Explained at
http://stackoverflow.com/a/6853353 .
I'd say the bash shebang is there just because author wrote it by
habit.
In favor of #!/bin/bash there is the point made by Damien (CC'd) that
it'll rule out the incoming bug reports that are due to alternative
shell environments.
In favor of #!/bin/sh NetBSD people (CC'd) informed they'll be glad to
see bash requirement go.
How about Android, does it make a difference there?
My view on this is that converting everything to #!/bin/sh allows using
BusyBox shell which makes the minimal testing build less complex. So
I'm in favor of converting to #!/bin/sh.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [DMC_BUGFIX_SKL_V2 0/5] pc10 entry fixes for skl.
After discussions with Art, Ville and others internally on how DC5/6 should normally work and existing open issues related to the HW automatic DC5/6 functionality, I have the following understanding. In the future we will require the firmware for any display side runtime power management (and possibly some power savings during system power states like S0ix and S3), so in the following we can ignore the case when the firmware is not available. Normally we need to run the BSpec display init sequence only when loading the driver and resuming from S4 if the BIOS hasn't done so already. PW1 and CDCLK is enabled as part of this sequence and will be toggled by the DMC firmware on demand, so we must not toggle these manually during runtime, since that would race with the FW. The same goes goes for other resources enabled/reset in the init sequence: PCH reset handshake, DBUF, Misc IO. The manual controls are DC5, DC6 and PW2 which the driver needs to toggle based on the active outputs. We also need to disable DC5/6 while doing modeset and according to our tests DPAUX transfers. When HW enters DC6 and the GT side is idle too (in RC6) the system as a whole can enter a deeper power state (PC9/10). Due to a HW issue atm we cannot rely on the HW transitioning automatically to DC6 and we need to use a manual way instead. We do this by keeping DC6 disabled all the time and running a special deinitialization sequence when both the display and GT side is idle, and the reverse when something becomes active. (that is in the driver's runtime suspend/resume hooks). Currently the driver is not following the normal HW assisted flow, since it toggles DBUF, CDCLK and PW1 manually during runtime. It also lacks the manual sequence to enable PC9/10. This patchset solves some of the above issues, by removing the manual CDCLK and PW1 control and disabling DC6. This will solve some of the stability issues, but leave PC9/10 disabled. As a follow-up we need to - move the rest of the display init/uninit sequence out of the power_well/suspend/resume path and call it only during driver loading/S4 resume as necessary - add separate DC5/DC6 power wells - add the manual sequence to enable PC9/10 - add a module parameter to enable either HW assisted DC6, or the manual way, or disable DC6 - disable DC5/6 during modeset and other places like DPAUX as needed I'll comment on the individual patches based on the above. I think with those addressed we could merge this patchset and do the rest as a follow-up. --Imre On ke, 2015-08-26 at 01:36 +0530, Animesh Manna wrote: > The following patches helps to solve PC10 entry issue for SKL. > Detailed description about the changes done to solve the issue > is mentioned in commit message of each patch. > > v1: http://lists.freedesktop.org/archives/intel-gfx/2015-August/072870.html > > v2: Based on review comments from Daniel, changes made in the current version. > > DMC redesign patch series has dependencies with current patch series. Need > to rework on few patches, planning to send after initial review feedback > of the current patch series. > http://lists.freedesktop.org/archives/intel-gfx/2015-August/072921.html > > > Animesh Manna (5): > drm/i915/skl: Added a check for the hardware status of csr fw before > loading. > drm/i915/skl Remove the call for csr uninitialization from suspend > path > drm/i915/skl: Making DC6 entry is the last call in suspend flow. > drm/i915/skl: Do not disable cdclk PLL if csr firmware is present > drm/i915/skl: Block disable call for pw1 if dmc firmware is present. > > drivers/gpu/drm/i915/i915_drv.c | 19 +-- > drivers/gpu/drm/i915/intel_csr.c| 9 + > drivers/gpu/drm/i915/intel_display.c| 14 ++ > drivers/gpu/drm/i915/intel_drv.h| 2 ++ > drivers/gpu/drm/i915/intel_runtime_pm.c | 31 --- > 5 files changed, 50 insertions(+), 25 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
On 09/10/15 14:11, Chris Wilson wrote: Since the remove of the pin-ioctl, we only care about not changing the cache level on buffers pinned to the hardware as indicated by obj->pin_display. By knowing that only objects pinned to the hardware will have an elevated vma->pin_count, so we can coallesce many of the linear walks over the obj->vma_list. v2: Try and retrospectively add comments explaining the steps in rebinding the active VMA. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Very nice! Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
Hi Chris, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): include/drm/drm_crtc.h:1162: warning: No description found for parameter 'dirty_info_property' include/drm/drm_crtc.h:1162: warning: No description found for parameter 'suggested_x_property' include/drm/drm_crtc.h:1162: warning: No description found for parameter 'suggested_y_property' include/drm/drm_crtc.h:1162: warning: No description found for parameter 'allow_fb_modifiers' include/drm/drm_fb_helper.h:148: warning: No description found for parameter 'connector_info' include/drm/drm_dp_helper.h:713: warning: No description found for parameter 'i2c_nack_count' include/drm/drm_dp_helper.h:713: warning: No description found for parameter 'i2c_defer_count' drivers/gpu/drm/drm_dp_mst_topology.c:2226: warning: No description found for parameter 'connector' include/drm/drm_dp_mst_helper.h:97: warning: No description found for parameter 'cached_edid' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'max_dpcd_transaction_bytes' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'sink_count' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'total_slots' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'avail_slots' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'total_pbn' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'qlock' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'tx_msg_downq' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'tx_msg_upq' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'tx_down_in_progress' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'tx_up_in_progress' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'payload_lock' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'proposed_vcpis' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'payloads' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'payload_mask' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'vcpi_mask' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'tx_waitq' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'work' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'tx_work' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'destroy_connector_list' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'destroy_connector_lock' include/drm/drm_dp_mst_helper.h:471: warning: No description found for parameter 'destroy_connector_work' drivers/gpu/drm/drm_dp_mst_topology.c:2226: warning: No description found for parameter 'connector' drivers/gpu/drm/drm_irq.c:173: warning: No description found for parameter 'flags' include/drm/drmP.h:164: warning: No description found for parameter 'fmt' include/drm/drmP.h:180: warning: No description found for parameter 'fmt' include/drm/drmP.h:198: warning: No description found for parameter 'fmt' include/drm/drmP.h:238: warning: No description found for parameter 'dev' include/drm/drmP.h:238: warning: No description found for parameter 'data' include/drm/drmP.h:238: warning: No description found for parameter 'file_priv' include/drm/drmP.h:271: warning: No description found for parameter 'ioctl' include/drm/drmP.h:271: warning: No description found for parameter '_func' include/drm/drmP.h:271: warning: No description found for parameter '_flags' include/drm/drmP.h:344: warning: cannot understand function prototype: 'struct drm_lock_data ' include/drm/drmP.h:397: warning: cannot understand function prototype: 'struct drm_driver ' include/drm/drmP.h:647: warning: cannot understand function prototype: 'struct drm_info_list ' include/drm/drmP.h:657: warning: cannot understand function prototype: 'struct drm_info_node ' include/drm/drmP.h:667: warning: cannot understand function p
Re: [Intel-gfx] [PATCH 7/9] drm/i915: add fences to the request struct
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
>
> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
> /** Execlists no. of times this request has been sent to the ELSP */
> int elsp_submitted;
>
> + /* core fence obj for this request, may be exported */
> + struct fence fence;
As discussed, this doesn't work as-is. The final fence_put() will
attempt to free(&req->fence). Unless you have a .release method in your
fence ops, which you don't.
I suppose we could tie up a .release method with the existing release
method for the drm_i915_gem_request.
As things stand, though, bad things are happening. This makes it go
away and at least lets me get on with testing.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8ef19e2..2d0c93c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2297,7 +2298,7 @@ struct drm_i915_gem_request {
int elsp_submitted;
/* core fence obj for this request, may be exported */
- struct fence fence;
+ struct fence *fence;
wait_queue_t wait;
};
diff --git a/drivers/gpu/drm/i915/i915_sync.c b/drivers/gpu/drm/i915/i915_sync.c
index 085f1f9..6ffe273 100644
--- a/drivers/gpu/drm/i915/i915_sync.c
+++ b/drivers/gpu/drm/i915/i915_sync.c
@@ -58,7 +58,12 @@ struct i915_sync_timeline {
* allow non-RCS fences (need ring/context association)
*/
-#define to_i915_request(x) container_of(x, struct drm_i915_gem_request, fence)
+struct foo {
+ struct fence fence;
+ struct drm_i915_gem_request *req;
+};
+
+#define to_i915_request(x) (((struct foo *)(x))->req)
static const char *i915_fence_get_driver_name(struct fence *fence)
{
@@ -81,10 +86,10 @@ static int i915_fence_ring_check(wait_queue_t *wait,
unsigned mode, int flags,
if (!i915_gem_request_completed(req, false))
return 0;
- fence_signal_locked(&req->fence);
+ fence_signal_locked(req->fence);
__remove_wait_queue(&ring->irq_queue, wait);
- fence_put(&req->fence);
+ fence_put(req->fence);
ring->irq_put(ring);
return 0;
@@ -200,6 +205,15 @@ struct fence *i915_fence_create_ring(struct
intel_engine_cs *ring,
if (ret)
return ERR_PTR(ret);
+ request->fence = kmalloc(sizeof(struct foo), GFP_KERNEL);
+ if (!request->fence) {
+ ret = -ENOMEM;
+ goto err_cancel;
+ }
+ /* I have no clue how this is *supposed* to work and no real interest
+ in finding out. Just stop hurting me please. */
+ ((struct foo *)request->fence)->req = request;
+
if (i915.enable_execlists) {
ringbuf = ctx->engine[ring->id].ringbuf;
} else
@@ -270,10 +284,10 @@ struct fence *i915_fence_create_ring(struct
intel_engine_cs *ring,
round_jiffies_up_relative(HZ));
intel_mark_busy(dev_priv->dev);
- fence_init(&request->fence, &i915_fence_ring_ops, &fence_lock,
+ fence_init(request->fence, &i915_fence_ring_ops, &fence_lock,
ctx->user_handle, request->seqno);
- return &request->fence;
+ return request->fence;
err_cancel:
i915_gem_request_cancel(request);
@@ -306,10 +320,10 @@ static struct fence *i915_fence_create_display(struct
intel_context *ctx)
req = ring->outstanding_lazy_request;
- fence_init(&req->fence, &i915_fence_ops, &fence_lock,
+ fence_init(req->fence, &i915_fence_ops, &fence_lock,
ctx->user_handle, req->seqno);
- return &req->fence;
+ return req->fence;
}
#endif
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. By knowing that only objects pinned to the hardware
will have an elevated vma->pin_count, so we can coallesce many of the
linear walks over the obj->vma_list.
v2: Try and retrospectively add comments explaining the steps in
rebinding the active VMA.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 99 -
1 file changed, 78 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d4a3bdf0c5b6..fb4cf0ab8c18 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3624,53 +3624,106 @@ i915_gem_object_set_to_gtt_domain(struct
drm_i915_gem_object *obj, bool write)
return 0;
}
+/**
+ * Changes the cache-level of an object across all VMA.
+ *
+ * After this function returns, the object will be in the new cache-level
+ * across all GTT and the contents of the backing storage will be coherent,
+ * with respect to the new cache-level. In order to keep the backing storage
+ * coherent for all users, we only allow a single cache level to be set
+ * globally on the object and prevent it from being changed whilst the
+ * hardware is reading from the object. That is if the object is currently
+ * on the scanout it will be set to uncached (or equivalent display
+ * cache coherency) and all non-MOCS GPU access will also be uncached so
+ * that all direct access to the scanout remains coherent.
+ */
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level)
{
struct drm_device *dev = obj->base.dev;
struct i915_vma *vma, *next;
+ bool bound = false;
int ret = 0;
if (obj->cache_level == cache_level)
goto out;
- if (i915_gem_obj_is_pinned(obj)) {
- DRM_DEBUG("can not change the cache level of pinned objects\n");
- return -EBUSY;
- }
-
+ /* Inspect the list of currently bound VMA and unbind any that would
+* be invalid given the new cache-level. This is principally to
+* catch the issue of the CS prefetch crossing page boundaries and
+* reading an invalid PTE on older architectures.
+*/
list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
+ if (!drm_mm_node_allocated(&vma->node))
+ continue;
+
+ if (vma->pin_count) {
+ DRM_DEBUG("can not change the cache level of pinned
objects\n");
+ return -EBUSY;
+ }
+
if (!i915_gem_valid_gtt_space(vma, cache_level)) {
ret = i915_vma_unbind(vma);
if (ret)
return ret;
- }
+ } else
+ bound = true;
}
- if (i915_gem_obj_bound_any(obj)) {
+ /* We can reuse the existing drm_mm nodes but need to change the
+* cache-level on the PTE. We could simply unbind them all and
+* rebind with the correct cache-level on next use. However since
+* we already have a valid slot, dma mapping, pages etc, we may as
+* rewrite the PTE in the belief that doing so tramples upon less
+* state and so involves less work.
+*/
+ if (bound) {
+ /* Before we change the PTE, the GPU must not be accessing it.
+* If we wait upon the object, we know that all the bound
+* VMA are no longer active.
+*/
ret = i915_gem_object_wait_rendering(obj, false);
if (ret)
return ret;
- i915_gem_object_finish_gtt(obj);
-
- /* Before SandyBridge, you could not use tiling or fence
-* registers with snooped memory, so relinquish any fences
-* currently pointing to our region in the aperture.
-*/
- if (INTEL_INFO(dev)->gen < 6) {
+ if (!HAS_LLC(dev) && cache_level != I915_CACHE_NONE) {
+ /* Access to snoopable pages through the GTT is
+* incoherent and on some machines causes a hard
+* lockup. Relinquish the CPU mmaping to force
+* userspace to refault in the pages and we can
+* then double check if the GTT mapping is still
+* valid for that pointer access.
+*/
+ i915_gem_release_mmap(obj);
+
+ /* As we no longer need a fence for GTT access,
+* we can relinquish it now (and so prevent having
+
Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level
On Fri, Oct 09, 2015 at 01:37:19PM +0100, Tvrtko Ursulin wrote: > > On 09/10/15 13:19, Chris Wilson wrote: > >On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote: > >> > >>On 09/10/15 12:51, Chris Wilson wrote: > >>>If the impossible happens and we fail to rebind a VMA in the middle of > >>>rebinding all VMA for an object we currently bail out and leave the > >>>object in an inconsistent state. Attempt to unwind the incomplete update > >>>by reverting all updated VMA back to the original cache-level, and WARN > >>>if that fails. > >> > >>Hey a BUG_ON would have been more your style! ;) > > > >Propagating error returns trumps throwing a tantrum and then as we are > >on the the error path we've already proved the impossible could happen, > >so presume it could happen again. > > No no, just a BUG_ON(i915_bind_vma()) on the original call site > would suffice since it cannot happen anyway. ;> > > For the same reason it is safe to skip the current entry when > reversing I suppose. > > But it is still code to handle something which can't happen. If you > want to stuff it under future proofing you can have my r-b, but hope > someone who doesn't like future proofing notices. :) Maybe I should say nothing is impossible with i915_gem_gtt.c :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level
On 09/10/15 13:19, Chris Wilson wrote: On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote: On 09/10/15 12:51, Chris Wilson wrote: If the impossible happens and we fail to rebind a VMA in the middle of rebinding all VMA for an object we currently bail out and leave the object in an inconsistent state. Attempt to unwind the incomplete update by reverting all updated VMA back to the original cache-level, and WARN if that fails. Hey a BUG_ON would have been more your style! ;) Propagating error returns trumps throwing a tantrum and then as we are on the the error path we've already proved the impossible could happen, so presume it could happen again. No no, just a BUG_ON(i915_bind_vma()) on the original call site would suffice since it cannot happen anyway. ;> For the same reason it is safe to skip the current entry when reversing I suppose. But it is still code to handle something which can't happen. If you want to stuff it under future proofing you can have my r-b, but hope someone who doesn't like future proofing notices. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under discussion are lots of ways to slow down normal
operation in order to protect the post-mortem error capture, but what it
we take the opposite approach and freeze the machine whilst the error
catpure runs (note the GPU may still running, but as long as we don't
process any of the results the driver's bookkeeping will be static).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 31 +--
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 99e819767204..63df28910c8f 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -7,6 +7,7 @@ config DRM_I915
select AGP_INTEL if AGP
select INTERVAL_TREE
select ZLIB_DEFLATE
+ select STOP_MACHINE
# we need shmfs for the swappable backing store, and in particular
# the shmem_readpage() which depends upon tmpfs
select SHMEM
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d16fc1189d6..14a882fe486c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -488,6 +488,8 @@ struct drm_i915_error_state {
struct kref ref;
struct timeval time;
+ struct drm_i915_private *i915;
+
char error_msg[128];
int iommu;
u32 reset_count;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 64bdffcffb50..29cbec67bcfc 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -29,6 +29,7 @@
#include
#include
+#include
#include "i915_drv.h"
static const char *yesno(int v)
@@ -1352,6 +1353,24 @@ static void i915_capture_gen_state(struct
drm_i915_private *dev_priv,
error->suspend_count = dev_priv->suspend_count;
}
+static int capture(void *data)
+{
+ struct drm_i915_error_state *error = data;
+
+ i915_capture_gen_state(error->i915, error);
+ i915_capture_reg_state(error->i915, error);
+ i915_gem_capture_buffers(error->i915, error);
+ i915_gem_record_fences(error->i915->dev, error);
+ i915_gem_record_rings(error->i915->dev, error);
+
+ do_gettimeofday(&error->time);
+
+ error->overlay = intel_overlay_capture_error_state(error->i915->dev);
+ error->display = intel_display_capture_error_state(error->i915->dev);
+
+ return 0;
+}
+
/**
* i915_capture_error_state - capture an error record for later analysis
* @dev: drm device
@@ -1377,17 +1396,9 @@ void i915_capture_error_state(struct drm_device *dev,
bool wedged,
}
kref_init(&error->ref);
+ error->i915 = dev_priv;
- i915_capture_gen_state(dev_priv, error);
- i915_capture_reg_state(dev_priv, error);
- i915_gem_capture_buffers(dev_priv, error);
- i915_gem_record_fences(dev, error);
- i915_gem_record_rings(dev, error);
-
- do_gettimeofday(&error->time);
-
- error->overlay = intel_overlay_capture_error_state(dev);
- error->display = intel_display_capture_error_state(dev);
+ stop_machine(capture, error, NULL);
i915_error_capture_msg(dev, error, wedged, error_msg);
DRM_INFO("%s\n", error->error_msg);
--
2.6.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level
On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote: > > On 09/10/15 12:51, Chris Wilson wrote: > >If the impossible happens and we fail to rebind a VMA in the middle of > >rebinding all VMA for an object we currently bail out and leave the > >object in an inconsistent state. Attempt to unwind the incomplete update > >by reverting all updated VMA back to the original cache-level, and WARN > >if that fails. > > Hey a BUG_ON would have been more your style! ;) Propagating error returns trumps throwing a tantrum and then as we are on the the error path we've already proved the impossible could happen, so presume it could happen again. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level
On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote:
>
> On 09/10/15 12:51, Chris Wilson wrote:
> >If the impossible happens and we fail to rebind a VMA in the middle of
> >rebinding all VMA for an object we currently bail out and leave the
> >object in an inconsistent state. Attempt to unwind the incomplete update
> >by reverting all updated VMA back to the original cache-level, and WARN
> >if that fails.
>
> Hey a BUG_ON would have been more your style! ;)
>
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/i915_gem.c | 35 ++-
> > 1 file changed, 26 insertions(+), 9 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 1e67484fd5dc..24ba47a22260 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -3664,6 +3664,12 @@ int i915_gem_object_set_cache_level(struct
> >drm_i915_gem_object *obj,
> > struct i915_vma *vma, *next;
> > int ret = 0;
> >
> >+/* We manipulate all the PTEs in the various GTT associated with
> >+ * this object which requires that the caller takes the
> >+ * struct_mutex on our behalf.
> >+ */
> >+lockdep_assert_held(&dev->struct_mutex);
> >+
> > if (obj->cache_level == cache_level)
> > goto out;
> >
> >@@ -3697,17 +3703,18 @@ int i915_gem_object_set_cache_level(struct
> >drm_i915_gem_object *obj,
> > return ret;
> > }
> >
> >-list_for_each_entry(vma, &obj->vma_list, vma_link)
> >-if (drm_mm_node_allocated(&vma->node)) {
> >-ret = i915_vma_bind(vma, cache_level,
> >-PIN_UPDATE);
> >-if (ret)
> >-return ret;
> >-}
> >+list_for_each_entry(vma, &obj->vma_list, vma_link) {
> >+if (!drm_mm_node_allocated(&vma->node))
> >+continue;
> >+
> >+ret = i915_vma_bind(vma, cache_level, PIN_UPDATE);
> >+if (ret)
> >+goto unwind;
> >+
> >+vma->node.color = cache_level;
> >+}
> > }
> >
> >-list_for_each_entry(vma, &obj->vma_list, vma_link)
> >-vma->node.color = cache_level;
> > obj->cache_level = cache_level;
> >
> > out:
> >@@ -3719,6 +3726,16 @@ out:
> > }
> >
> > return 0;
> >+
> >+unwind:
> >+list_for_each_entry_continue_reverse(vma, &obj->vma_list, vma_link) {
>
> I did not know of this one! But it confuses me (emphasis mine):
>
> """
> list_for_each_entry_continue_reverse - iterate backwards _from the
> given point_
> """
>
> or
>
> """
> * Start to iterate over list of given type backwards, continuing _after
> * the current position_.
> """
>
> Code is "for (pos = list_prev_entry(pos, member); " though, so I
> think you'll miss rebinding the one it failed on.
Correct, but we didn't change the one we failed upon. If i915_vma_bind()
itself doesn't unwind, we have another bug to fix! :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level
On 09/10/15 12:51, Chris Wilson wrote:
If the impossible happens and we fail to rebind a VMA in the middle of
rebinding all VMA for an object we currently bail out and leave the
object in an inconsistent state. Attempt to unwind the incomplete update
by reverting all updated VMA back to the original cache-level, and WARN
if that fails.
Hey a BUG_ON would have been more your style! ;)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1e67484fd5dc..24ba47a22260 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3664,6 +3664,12 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
struct i915_vma *vma, *next;
int ret = 0;
+ /* We manipulate all the PTEs in the various GTT associated with
+* this object which requires that the caller takes the
+* struct_mutex on our behalf.
+*/
+ lockdep_assert_held(&dev->struct_mutex);
+
if (obj->cache_level == cache_level)
goto out;
@@ -3697,17 +3703,18 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
return ret;
}
- list_for_each_entry(vma, &obj->vma_list, vma_link)
- if (drm_mm_node_allocated(&vma->node)) {
- ret = i915_vma_bind(vma, cache_level,
- PIN_UPDATE);
- if (ret)
- return ret;
- }
+ list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ if (!drm_mm_node_allocated(&vma->node))
+ continue;
+
+ ret = i915_vma_bind(vma, cache_level, PIN_UPDATE);
+ if (ret)
+ goto unwind;
+
+ vma->node.color = cache_level;
+ }
}
- list_for_each_entry(vma, &obj->vma_list, vma_link)
- vma->node.color = cache_level;
obj->cache_level = cache_level;
out:
@@ -3719,6 +3726,16 @@ out:
}
return 0;
+
+unwind:
+ list_for_each_entry_continue_reverse(vma, &obj->vma_list, vma_link) {
I did not know of this one! But it confuses me (emphasis mine):
"""
list_for_each_entry_continue_reverse - iterate backwards _from the given
point_
"""
or
"""
* Start to iterate over list of given type backwards, continuing _after
* the current position_.
"""
Code is "for (pos = list_prev_entry(pos, member); " though, so I think
you'll miss rebinding the one it failed on.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: NULL check of unpin_work
On 09/10/2015 11:44, Chris Wilson wrote: On Fri, Oct 09, 2015 at 11:30:34AM +0100, Tomas Elf wrote: On 09/10/2015 08:46, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote: Avoid NULL pointer exceptions in the display driver for certain critical cases when unpin_work has turned out to be NULL. Nope, the machine reached a point where it cannot possibly reach, we want the OOPS. -Chris Really? Because if I have this in there I can actually run the long-duration stability tests for 12+ hours rather than just a few hours (it doesn't happen all the time but I've seen it at least once). But, hey, if you want to investigate the reason why we have a NULL there then go ahead. I guess I'll just have to carry this patch for as long as my machine crashes during my TDR testing. You've sat on a critical bug for how long? There's been one recent report that appears to be fallout from Tvrtko's context cleanup, but nothing older, in public at least. -Chris Do people typically try to actively hang their machines several times a minute for a 12+ hours at a time? If not then maybe that's why they haven't seen this. I haven't sat on anything, this has been part of my error state capture improvement patches which I've intended to upstream for several months now. I consider this part of the overall stability issue and grouped it together with all the other patches necessary to make the machine not crash for the duration of my test. I would've upstreamed this series a long time ago if I had actually been given time to work on it but that's another discussion. Thanks, Tomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
On 09/10/15 11:34, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 11:17:19AM +0100, Tvrtko Ursulin wrote:
- list_for_each_entry(vma, &obj->vma_list, vma_link)
- if (drm_mm_node_allocated(&vma->node)) {
- ret = i915_vma_bind(vma, cache_level,
- PIN_UPDATE);
- if (ret)
- return ret;
- }
+ /* Access to snoopable pages through the GTT is incoherent. */
+ if (cache_level != I915_CACHE_NONE && !HAS_LLC(dev))
+ i915_gem_release_mmap(obj);
Don't fully understand this one - but my question is this.
Previously userspace would lose mappings on cache level changes any
time, after this only on !LLC when turning on caching mode. So this
means userspace needs to know about this change and modify it's
behavior? Or what exactly would happen in practice?
No. Userspace has no knowledge of the kernel handling the PTEs, its
mapping is persistent (i.e. the obj->mmap_offset inside the dev->mappping).
Otoh, we are improving the situation so even if userspace tries to avoid
set-cache-level nothing is lost.
Hm so if a VMA is re-bound in this process and it could have gotten
a new GGTT address, why it is not necessary to always release mmaps
and so to update CPU PTEs?
The VMA are not moved by this function, only the PTEs are rewritten. The
GTT ignores the bits we are changing on llc architectures. On !llc using
the GTT to access snoopable PTE is verboten and does cause machine hangs.
How come they are not moved when they can be unbound and then bound again?
The only relevant vma here are rebound with PIN_UPDATE. If we have to
unbind any due to subsequent placement errors, the behaviour doesn't
change in this patch. So I'm not understanding your concern and can't
address it adequately. :(
I started to understand how this works after a chat on IRC. Before I had
a completely wrong assumptions.
(This also demonstrates this code should really have a good high level
comment.)
Unless I missed something it really looks the behaviour is unchanged,
just a trip to the fault handler is avoided if not needed.
But I still think you need to improve the commit message to be clearer
on pin_display (un)usage and SandyBridge referencing.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Use safe list iterators
On 09/10/2015 11:38, Chris Wilson wrote: On Fri, Oct 09, 2015 at 11:27:48AM +0100, Tomas Elf wrote: On 09/10/2015 08:41, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:38PM +0100, Tomas Elf wrote: Error state capture is dependent on i915_gem_active_request() and i915_gem_obj_is_pinned(). Since there is no synchronization between error state capture and the driver state we at least need to use safe list iterators in these functions to alleviate the problem of request/vma lists changing during error state capture. Does not make it safe. -Chris I know it doesn't make it safe, I didn't say this patch makes it safe. Maybe I was unclear but I chose the word "alleviate" rather than "solve" to indicate that there are still problems but this change reduces the problem scope and makes crashes less likely to occur. I also used the formulation "at least" to indicate that we're not solving everything but we can do certain things to improve things somewhat. The problems I've been seeing has been that the list state changes during iteration and that the error capture tries to read elements that are no longer part of the list - not that elements that the error capture code is dereferencing are deallocated by the driver or whatever. Using a safe iterator helps with that very particular problem. Or maybe I guess I've just been incredibly lucky for the last 2 months when I've been running this code as I've been able to get 12+ hours of stability during my tests instead of less than one hour in between crashes that was the case before I introduced these changes. You have been incredibily lucky (probably due to how the requests are being cached now), but that the requests can be modified whilst error capture runs and oops is well known. Just pretending the list iterator is safe does nothing. -Chris Does nothing except consistently extend meantime between failures from less than one hour to more than 12 hours during my TDR tests. That's a lot of luck right there. On a consistent and predictable basis. Also, I'm not trying to pretend, I thought I communicated clearly that this is not a solution but rather an improvement that makes certain types of tests actually possible to run, tests that are needed for the TDR validation. But if you have another solution then let's go with that. Thanks, Tomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: vma NULL pointer check
On Fri, Oct 09, 2015 at 12:30:29PM +0100, Tomas Elf wrote: > On 09/10/2015 08:48, Chris Wilson wrote: > >On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote: > >>Sometimes the iterated vma objects are NULL apparently. Be aware of this > >>while > >>iterating and do early exit instead of causing a NULL pointer exception. > > > >Wrong. > >-Chris > > > > So the NULL pointer exception that I ran into multiple times during > several different test runs on the line that says "vma->pin_count" > was not because the vma pointer was NULL. Would you mind sharing > your explanation to how this might have happened? Is it because > we're not synchronizing and there's no protection against the driver > deallocating vmas while we're trying to capture them? If this all > ties into the aforementioned RCU-based solution then maybe we should > go with that then. Correct. The driver is retiring requests whilst the hang check worker is running. And you chased a stale pointer, you could have equally chased a stale vma->obj, vma->ctx etc pointers. What I have done in the past is to serialise the retirement and the hangcheck using a spinlock (as adding to the end of the list is safe), but there are still weak spots when walking the list of bound vma. What I would actually feel more comfortable with is to only record the request->batch_vma, at the cost of losing information about the currently bound buffers. Or we could just stop_machine() whilst running the capture and have the machine unresponsive for a few 100ms. I don't think simply RCU the lists is enough (VM active_list, request list, bound list) as eventually we chase a pointer from obj itself (which means we need to RCU pretty much everything). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping
On Fri, 09 Oct 2015, Chris Wilson wrote: > On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote: >> From: Chris Wilson >> >> A long time ago (before 3.14) we relied on a permanent pinning of the >> ifbdev to lock the fb in place inside the GGTT. However, the >> introduction of stealing the BIOS framebuffer and reusing its address in >> the GGTT for the fbdev has muddied waters and we use an inherited fb. >> However, the inherited fb is only pinned whilst it is active and we no >> longer have an explicit pin for the info->system_base mmapping used by >> the fbdev. The result is that after some aperture pressure the fbdev may >> be evicted, but we continue to write the fbcon into the same GGTT >> address - overwriting anything else that may be put into that offset. >> The effect is most pronounced across suspend/resume as >> intel_fbdev_set_suspend() does a full clear over the whole scanout. >> >> v2: rebased on latest nightly (Wayne) >> v3: changed i915_gem_object_ggtt_pin() to i915_gem_obj_ggtt_pin() based >> on Chris' review. (Wayne) > > Note that this patch also depends on the > > drm/i915: Set the map-and-fenceable flag for preallocated objects > > fix as well > http://patchwork.freedesktop.org/patch/58026/ Jesse, please provide your Tested-by on that plus this patch, since you reported the breakage [1] that got the two patches reverted in the first place. Thanks, Jani. [1] http://mid.gmane.org/55df3886.1060...@virtuousgeek.org > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
