Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On 7/13/2015 9:47 AM, Sonika Jindal wrote:
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eb52a03..760539c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,11 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/* Port C is not connected on bxt A0/A1 */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -2257,6 +2261,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status & BXT_DE_PORT_HOTPLUG_MASK;
@@ -2271,7 +2276,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd_bxt);
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3315,8 +3325,15 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
/* Now, enable HPD */
for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
- == HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
+ == HPD_ENABLED) {
+ const u32 *hpd;
+
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+ hotplug_port |= hpd[intel_encoder->hpd_pin];
+ }
}
hpd initialization can be moved out so it is done once instead of being
repeated for each encoder.
/* Mask all HPD control bits */
@@ -3324,11 +3341,14 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
/* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
- if (hotplug_port & BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port & BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) < BXT_REVID_B0 && (hotplug_port &
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
can you add a comment here stating the swap in hpd pins ?
as i am not sure not everyone will first check the commit message for
the change here.
+ else {
+ if (hotplug_port & BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port & BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
/* Unmask DDI hotplug in IMR */
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Disable DSI PLL before reconfiguring it
Reviewed-by: Sivakumar Thulasimani On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä The BIOS maybe leave the DSI PLL enabled even if the port is disabled. The PLL doesn't seem to like being reconfigured while it's enabled so make sure it's disabled before doing that. The better fix would be to expose all PLLs independently of their ports so that we could disable any unused ones during the sanitize phase. But this seems like an OK short term solution. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 92bb252..07c4bb3 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -907,6 +907,7 @@ static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder) intel_dsi_prepare(encoder); + vlv_disable_dsi_pll(encoder); vlv_enable_dsi_pll(encoder); } -- regards, Sivakumar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement WaPixelRepeatModeFixForC0:chv
On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
to either pipe B or C. So do that to make pixel repeat work on pipes
B and C. Pipe A is fine without any tricks.
Fortunately the pixel repeat propagation appears to be a oneshot
operation, so once the value has been written we can clear the
chicken bits. So it is still possible to drive pipe B and C with
different pixel multipliers simultaneosly.
Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
for this to work. But since we keep that bit always set in all
DPLLs there's no problem.
This of course means we can't reliably read out the pixel multiplier
for pipes B and C. That would make the state checker unhappy, so I
added shadow copies of those registers in to dev_priv. The other
option would have been to skip pixel multiplier, dpll_md an dotclock
checks entirely on CHV, but that feels like a serious loss of cross
checking, so just pretending that we have working DPLL MD registers
seemed better. Obviously with the shadow copies we can't detect if
the pixel multiplier was properly configured, nor can we take over
its state from the BIOS, but hopefully people won't have displays
that would be limitd to such crappy modes.
There is one strange flicker still remaining. It's visible on
pipe C/HDMID when HDMIB is enabled while driven by pipe B.
It doesn't occur if pipe A drives HDMIB, nor is there any glitch
on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
with HDMIC so not sure if it happens there too. So I'm not sure
if it's somehow tied in with this strange linkage between pipe B
and C. Sadly I was unable to find an enable sequence that would
avoid the glitch, but at least it's not fatal ie. the output
recovers afterwards.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 30 ++
3 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 37cc653..adaa656 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1851,7 +1851,14 @@ struct drm_i915_private {
u32 fdi_rx_config;
+ /* Shadow for DISPLAY_PHY_CONTROL which can't be safely read */
u32 chv_phy_control;
+ /*
+* Shadows for CHV DPLL_MD regs to keep the state
+* checker somewhat working in the presence hardware
+* crappiness (can't read out DPLL_MD for pipes B & C).
+*/
+ u32 chv_dpll_md[I915_MAX_PIPES];
u32 suspend_count;
struct i915_suspend_saved_registers regfile;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f08f729..2361347 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4580,6 +4580,9 @@ enum skl_disp_power_wells {
#define CBR1_VLV (VLV_DISPLAY_BASE + 0x70400)
#define CBR_PND_DEADLINE_DISABLE (1<<31)
+#define CBR4_VLV (VLV_DISPLAY_BASE + 0x70450)
+#define CBR_DPLLBMD_PIPE_C(1<<29)
+#define CBR_DPLLBMD_PIPE_B(1<<18)
/* FIFO watermark sizes etc */
#define G4X_FIFO_LINE_SIZE64
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dec36a2..b862307 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1667,9 +1667,27 @@ static void chv_enable_pll(struct intel_crtc *crtc,
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) ==
DPLL_LOCK_VLV), 1))
DRM_ERROR("PLL %d failed to lock\n", pipe);
- /* not sure when this should be written */
- I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
- POSTING_READ(DPLL_MD(pipe));
+ if (pipe != PIPE_A) {
+ /*
+* WaPixelRepeatModeFixForC0:chv
+*
+* DPLLCMD is AWOL. Use chicken bits to propagate
+* the value from DPLLBMD to either pipe B or C.
+*/
+ I915_WRITE(CBR4_VLV, pipe == PIPE_B ? CBR_DPLLBMD_PIPE_B :
CBR_DPLLBMD_PIPE_C);
+ I915_WRITE(DPLL_MD(PIPE_B), pipe_config->dpll_hw_state.dpll_md);
+ I915_WRITE(CBR4_VLV, 0);
+ dev_priv->chv_dpll_md[pipe] =
pipe_config->dpll_hw_state.dpll_md;
+
+ /*
+* DPLLB VGA mode also seems to cause problems.
+* We should always have it disabled.
+*/
+ WARN_ON((I915_READ(DPLL(PIPE_B)) & DPLL_VGA_MODE_DIS) == 0);
+ } else {
+ I915_WRITE(DPLL_MD(pipe), pipe_config->dpll_hw_state.dpll_md);
+ POSTING_READ(DPLL_MD(pipe));
+ }
}
static int intel_num_dvo_pip
[Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eb52a03..760539c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,11 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/* Port C is not connected on bxt A0/A1 */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -2257,6 +2261,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status & BXT_DE_PORT_HOTPLUG_MASK;
@@ -2271,7 +2276,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control,
hpd_bxt);
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3315,8 +3325,15 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
/* Now, enable HPD */
for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
- == HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
+ == HPD_ENABLED) {
+ const u32 *hpd;
+
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+ hotplug_port |= hpd[intel_encoder->hpd_pin];
+ }
}
/* Mask all HPD control bits */
@@ -3324,11 +3341,14 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
/* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
- if (hotplug_port & BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port & BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) < BXT_REVID_B0 && (hotplug_port &
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
+ else {
+ if (hotplug_port & BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port & BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
/* Unmask DDI hotplug in IMR */
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/kms_color:Color IGT
My comments inline.
Regards
Shashank
-Original Message-
From: R, Dhanya p
Sent: Monday, July 13, 2015 9:25 AM
To: intel-gfx@lists.freedesktop.org
Cc: Palleti, Avinash Reddy; Malladi, Kausal; Sharma, Shashank; Suresh, Anitha;
R, Dhanya p
Subject: [PATCH] tests/kms_color:Color IGT
From: Dhanya
This patch will verify color correction capability of a display driver.
Gamma/CSC/De-gamma supported.
Signed-off-by: Dhanya
---
tests/Makefile.sources | 3 +
tests/kms_color.c | 639 +
2 files changed, 642 insertions(+)
create mode 100644 tests/kms_color.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources index
994c31b..f49c396 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -77,9 +77,12 @@ TESTS_progs_M = \
kms_setmode \
kms_universal_plane \
kms_vblank \
+ kms_color \
+ color-correction\
kms_crtc_background_color \
kms_plane_scaling \
kms_panel_fitting \
+ kms_render_compression \
Why are we adding render compression API here ?
pm_lpsp \
pm_rpm \
pm_rps \
diff --git a/tests/kms_color.c b/tests/kms_color.c new file mode 100644 index
000..48fad7a
--- /dev/null
+++ b/tests/kms_color.c
@@ -0,0 +1,639 @@
+/*
+ * 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.
+ *
+ */
+
+#include
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "igt_core.h"
+#include "intel_chipset.h"
+#include "igt_aux.h"
+#include
+#include
+IGT_TEST_DESCRIPTION("Test Color Features at Plane/Pipe level");
+
+
+#define CHV_CSC_VALS9
+#define I915_PIPE_CSC (1<<0)
+#define I915_PLANE_CSC (1<<1)
+
+#define CSC_MANTISSA_MAX_BITS1
+#define CSC_MANTISSA_MAX_VALUE ((1 << CSC_MANTISSA_MAX_BITS) - 1)
+#define CSC_FRACTION_MAX_BITS10
+#define GAMMA_RED_SHIFT16
+#define GAMMA_GREEN_SHIFT 8
+#define STANDARD_GAMMA 2.2
+#define I915_GAMMA_FLAG_DEGAMMA(1<<0)
+#define I915_PIPE_GAMMA(1<<0)
+#define I915_PLANE_GAMMA (1<<1)
+#define I915_GAMMA_PRECISION_UNKNOWN 0
+#define I915_GAMMA_PRECISION_CURRENT 0x
+#define I915_GAMMA_PRECISION_LEGACY(1<<0)
+#define I915_GAMMA_PRECISION_10BIT (1<<1)
+#define I915_GAMMA_PRECISION_12BIT (1<<2)
+#define I915_GAMMA_PRECISION_14BIT (1<<3)
+#define I915_GAMMA_PRECISION_16BIT (1<<4)
+#define CHV_DEGAMMA_MAX_INDEX 64
+#define CHV_DEGAMMA_VALS 65
+#define CHV_8BIT_GAMMA_MAX_INDEX 256
+#define CHV_8BIT_GAMMA_MAX_VALSCHV_8BIT_GAMMA_MAX_INDEX
+#define CHV_10BIT_GAMMA_MAX_INDEX 256
+#define CHV_10BIT_GAMMA_MAX_VALS (CHV_10BIT_GAMMA_MAX_INDEX + 1)
+#define DEFAULT 0
+#define RANDOM 1
+#define DRM_IOCTL_MODE_CREATEPROPBLOB \
+ DRM_IOWR(0xBD, struct drm_mode_create_blob)
Why are we adding these definitions here ? We should reuse whatever is
available in the UAPI layer, link to appropriate header files, and then
hardcode whatever is not accessible.
I don’t see a reason to add IOCTL nos here.
+
+struct drm_intel_csc {
+ uint32_t version;
+ int csc_matrix[9];
+
+};
Same here, this should be available in drm headers.
+
+struct CURVE_SLIDER_VALUES {
+ int32_t brightness;
+ int32_t contrast;
+ float gamma;
+};
+
+struct rgb_pixel {
+ uint32_t red;
+ uint32_t green;
+ uint32_t blue;
+};
+
+struct drm_intel_gamma {
+ uint32_t version;
+ uint32_t num_samples;
+ struct rgb_pixel gamma_values[257];
+};
+struct drm_intel_degamma {
+ uint32_t version;
+ uint32_t num_samples;
+ struct rgb_pixel degamma_values[65];
+};
+
+static struct drm_mode_create_blob {
+ uint64_t data;
+ uint32_t length;
+ uint32_t blob_id;
+};
Same here, this sh
[Intel-gfx] [PATCH] tests/kms_color:Color IGT
From: Dhanya
This patch will verify color correction capability of a display driver.
Gamma/CSC/De-gamma supported.
Signed-off-by: Dhanya
---
tests/Makefile.sources | 3 +
tests/kms_color.c | 639 +
2 files changed, 642 insertions(+)
create mode 100644 tests/kms_color.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 994c31b..f49c396 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -77,9 +77,12 @@ TESTS_progs_M = \
kms_setmode \
kms_universal_plane \
kms_vblank \
+ kms_color \
+ color-correction\
kms_crtc_background_color \
kms_plane_scaling \
kms_panel_fitting \
+ kms_render_compression \
pm_lpsp \
pm_rpm \
pm_rps \
diff --git a/tests/kms_color.c b/tests/kms_color.c
new file mode 100644
index 000..48fad7a
--- /dev/null
+++ b/tests/kms_color.c
@@ -0,0 +1,639 @@
+/*
+ * 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.
+ *
+ */
+
+#include
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "igt_core.h"
+#include "intel_chipset.h"
+#include "igt_aux.h"
+#include
+#include
+IGT_TEST_DESCRIPTION("Test Color Features at Plane/Pipe level");
+
+
+#define CHV_CSC_VALS9
+#define I915_PIPE_CSC (1<<0)
+#define I915_PLANE_CSC (1<<1)
+
+#define CSC_MANTISSA_MAX_BITS1
+#define CSC_MANTISSA_MAX_VALUE ((1 << CSC_MANTISSA_MAX_BITS) - 1)
+#define CSC_FRACTION_MAX_BITS10
+#define GAMMA_RED_SHIFT16
+#define GAMMA_GREEN_SHIFT 8
+#define STANDARD_GAMMA 2.2
+#define I915_GAMMA_FLAG_DEGAMMA(1<<0)
+#define I915_PIPE_GAMMA(1<<0)
+#define I915_PLANE_GAMMA (1<<1)
+#define I915_GAMMA_PRECISION_UNKNOWN 0
+#define I915_GAMMA_PRECISION_CURRENT 0x
+#define I915_GAMMA_PRECISION_LEGACY(1<<0)
+#define I915_GAMMA_PRECISION_10BIT (1<<1)
+#define I915_GAMMA_PRECISION_12BIT (1<<2)
+#define I915_GAMMA_PRECISION_14BIT (1<<3)
+#define I915_GAMMA_PRECISION_16BIT (1<<4)
+#define CHV_DEGAMMA_MAX_INDEX 64
+#define CHV_DEGAMMA_VALS 65
+#define CHV_8BIT_GAMMA_MAX_INDEX 256
+#define CHV_8BIT_GAMMA_MAX_VALSCHV_8BIT_GAMMA_MAX_INDEX
+#define CHV_10BIT_GAMMA_MAX_INDEX 256
+#define CHV_10BIT_GAMMA_MAX_VALS (CHV_10BIT_GAMMA_MAX_INDEX + 1)
+#define DEFAULT 0
+#define RANDOM 1
+#define DRM_IOCTL_MODE_CREATEPROPBLOB \
+ DRM_IOWR(0xBD, struct drm_mode_create_blob)
+
+struct drm_intel_csc {
+ uint32_t version;
+ int csc_matrix[9];
+
+};
+
+struct CURVE_SLIDER_VALUES {
+ int32_t brightness;
+ int32_t contrast;
+ float gamma;
+};
+
+struct rgb_pixel {
+ uint32_t red;
+ uint32_t green;
+ uint32_t blue;
+};
+
+struct drm_intel_gamma {
+ uint32_t version;
+ uint32_t num_samples;
+ struct rgb_pixel gamma_values[257];
+};
+struct drm_intel_degamma {
+ uint32_t version;
+ uint32_t num_samples;
+ struct rgb_pixel degamma_values[65];
+};
+
+static struct drm_mode_create_blob {
+ uint64_t data;
+ uint32_t length;
+ uint32_t blob_id;
+};
+
+
+struct data_t {
+ int fb_initial;
+ int drm_fd;
+ int w, h;
+ igt_display_t display;
+ struct igt_fb fb_prep;
+ struct igt_fb fb, fb1;
+};
+
+ static void
+paint_color(struct data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
+{
+ cairo_t *cr;
+
+ cr = igt_get_cairo_ctx(d->drm_fd, fb);
+ igt_paint_test_pattern(cr, w, h);
+ cairo_destroy(cr);
+}
+
+int create_blob(int fd, uint64_t *data, int length)
+{
+ struct drm_mode_create_blob blob;
+ int ret = -1;
+
+ blob.data = (uint64_t)data;
+ blob.length = length;
+ blob.blob_id = -1;
+ ret = ioctl(fd, DRM_
[Intel-gfx] commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 laptop reboots or hangs at boot time
Daniel, commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 causes my laptop to hang or reboot at the moment the kernel swiches the vido mode at boot time. I also noticed a warning while compiling: CC drivers/gpu/drm/i915/i915_gem_gtt.o /usr/src/linux.bisect/drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init': /usr/src/linux.bisect/drivers/gpu/drm/i915/i915_gem_gtt.c:954:2: warning: large integer implicitly truncated to unsigned type [-Woverflow] ppgtt->base.total = 1ULL << 32; ^ It might be related, or not. -- Hans commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 Author: Daniel Vetter Date: Tue Jul 7 11:15:47 2015 +0200 drm/i915: Use crtc_state->active in primary check_plane func Since commit 8c7b5ccb729870e606321b3703e2c2e698c49a95 Author: Ander Conselvan de Oliveira Date: Tue Apr 21 17:13:19 2015 +0300 drm/i915: Use atomic helpers for computing changed flags we compute the plane state for a modeset before actually committing any changes, which means crtc->active won't be correct yet. Looking at future work in the modeset conversion targetting 4.3 the only places where crtc_state->active isn't accurate is when disabling other CRTCs than the one the modeset is for (when stealing connectors). Which isn't the case here. And that's also confirmed by an audit, we do unconditionally update crtc_state->active for the current pipe. We also don't need to update any other plane check functions since we only ever add the primary state to the modeset update right now. Cc: Ander Conselvan de Oliveira Cc: Maarten Lankhorst Cc: Jani Nikula Signed-off-by: Daniel Vetter Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
