Re: [Intel-gfx] [PATCH] drm/i915: Android sync points for i915
Hey,
On 31-07-14 20:58, Jesse Barnes wrote:
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow applications and libraries to create fences without an
associated buffer
2) re-use a common API so userspace doesn't have to impedance mismatch
between different driver implementations too much
3) allow applications and libraries to use explicit synchronization if
they choose by exposing fences directly
Do you really need to use android timelines here? I think you should be
able to use fence directly, and export android userspace fences anyway,
you could easily wrap them.
~Maarten
Untested uncompiled patch for that below, looking from the documentation I may
have
caused a memory leak by taking a reference on the sync_pt..
---
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index ba0d69e..201b088 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -179,7 +179,7 @@ static void fence_check_cb_func(struct fence *f, struct
fence_cb *cb)
}
/* TODO: implement a create which takes more that one sync_pt */
-struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt)
{
struct sync_fence *fence;
@@ -190,16 +190,21 @@ struct sync_fence *sync_fence_create(const char *name,
struct sync_pt *pt)
fence-num_fences = 1;
atomic_set(fence-status, 1);
- fence_get(pt-base);
- fence-cbs[0].sync_pt = pt-base;
+ fence-cbs[0].sync_pt = fence_get(pt);
fence-cbs[0].fence = fence;
- if (fence_add_callback(pt-base, fence-cbs[0].cb,
fence_check_cb_func))
+ if (fence_add_callback(pt, fence-cbs[0].cb, fence_check_cb_func))
atomic_dec(fence-status);
sync_fence_debug_add(fence);
return fence;
}
+EXPORT_SYMBOL(sync_fence_create_dma);
+
+struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+{
+ return sync_fence_create_dma(name, pt-base);
+}
EXPORT_SYMBOL(sync_fence_create);
struct sync_fence *sync_fence_fdget(int fd)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index bcdd119..6d1682a 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -242,8 +242,9 @@ void sync_pt_free(struct sync_pt *pt);
* @pt:sync_pt to add to the fence
*
* Creates a fence containg @pt. Once this is called, the fence takes
- * ownership of @pt.
+ * a reference on @pt.
*/
+struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt);
struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt);
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: Adding Gfx Clock, Wake and Gunit save/restore logic in PM suspend/resume paths.
From: Sagar Kamble sagar.a.kam...@intel.com
Sequence to get gfx clocks on/off, allow/disallow wake and save/restore of
gunit registers need to be followed in
PM suspend and resume path similar to runtime suspend and resume.
v2:
1. Keeping GT access, wake, gunit save/restore related helpers static.
2. Moved GT access check, Wake Control, Gunit state save to end of
i915_drm_freeze.
3. Reusing the sequence in runtime_suspend/resume path at macro level.
Cc: Imre Deak imre.deak at intel.com
Cc: Paulo Zanoni paulo.r.zanoni at intel.com
Cc: Daniel Vetter daniel.vetter at ffwll.ch
Cc: Jani Nikula jani.nikula at linux.intel.com
Cc: Goel, Akash akash.g...@intel.com
Change-Id: I15cfdeeec9c976d9839bb281f809664f4a0c78a2
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 39 +--
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c4b25c..385dc74 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -490,11 +490,16 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return true;
}
+static int vlv_runtime_suspend(struct drm_i915_private *dev_priv);
+static int vlv_runtime_resume(struct drm_i915_private *dev_priv,
+ bool resume_from_s0ix);
+
static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc;
pci_power_t opregion_target_state;
+ int ret = 0;
/* ignore lid events during suspend */
mutex_lock(dev_priv-modeset_restore_lock);
@@ -562,7 +567,12 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_display_set_init_power(dev_priv, false);
- return 0;
+ /* Save Gunit State and clear wake - Need to make sure
+* changes in vlv_runtime_suspend path don't impact this path */
+ if (IS_VALLEYVIEW(dev))
+ ret = vlv_runtime_suspend(dev_priv);
+
+ return ret;
}
int i915_suspend(struct drm_device *dev, pm_message_t state)
@@ -610,6 +620,12 @@ void intel_console_resume(struct work_struct *work)
static int i915_drm_thaw_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
+
+ /* Restore Gunit State and allow wake - Need to make sure
+* changes in vlv_runtime_resume path don't impact this path */
+ if (IS_VALLEYVIEW(dev))
+ ret = vlv_runtime_resume(dev_priv, true);
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
hsw_disable_pc8(dev_priv);
@@ -618,7 +634,7 @@ static int i915_drm_thaw_early(struct drm_device *dev)
intel_uncore_sanitize(dev);
intel_power_domains_init_hw(dev_priv);
- return 0;
+ return ret;
}
static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings)
@@ -1098,6 +1114,7 @@ static void vlv_save_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
s-gu_ctl0 = I915_READ(VLV_GU_CTL0);
s-gu_ctl1 = I915_READ(VLV_GU_CTL1);
s-clock_gate_dis2 = I915_READ(VLV_GUNIT_CLOCK_GATE2);
+ s-dpio_cfg_data= I915_READ(DPIO_CTL);
/*
* Not saving any of:
@@ -1192,6 +1209,7 @@ static void vlv_restore_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
I915_WRITE(VLV_GU_CTL0, s-gu_ctl0);
I915_WRITE(VLV_GU_CTL1, s-gu_ctl1);
I915_WRITE(VLV_GUNIT_CLOCK_GATE2, s-clock_gate_dis2);
+ I915_WRITE(DPIO_CTL,s-dpio_cfg_data);
}
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
@@ -1291,6 +1309,8 @@ static void vlv_check_no_gt_access(struct
drm_i915_private *dev_priv)
I915_WRITE(VLV_GTLC_PW_STATUS, VLV_GTLC_ALLOWWAKEERR);
}
+/* This function is used in system suspend path as well to utilize
+ * Gfx clock, Wake control, Gunit state save related functionaility */
static int vlv_runtime_suspend(struct drm_i915_private *dev_priv)
{
u32 mask;
@@ -1331,7 +1351,12 @@ err1:
return err;
}
-static int vlv_runtime_resume(struct drm_i915_private *dev_priv)
+/* This function is used in system resume path as well to utilize
+ * Gfx clock, Wake control, Gunit state restore related functionaility.
+ * GEM and other initialization will differ which will be controlled by
+ * resume_from_s0ix variable */
+static int vlv_runtime_resume(struct drm_i915_private *dev_priv,
+ bool resume_from_s0ix)
{
struct drm_device *dev = dev_priv-dev;
int err;
@@ -1356,8 +1381,10 @@ static int vlv_runtime_resume(struct drm_i915_private
*dev_priv)
vlv_check_no_gt_access(dev_priv);
- intel_init_clock_gating(dev);
- i915_gem_restore_fences(dev);
+ if
Re: [Intel-gfx] [PATCH] drm/i915: Android sync points for i915
Hi Jesse,
On 07/31/2014 07:58 PM, Jesse Barnes wrote:
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow applications and libraries to create fences without an
associated buffer
2) re-use a common API so userspace doesn't have to impedance mismatch
between different driver implementations too much
3) allow applications and libraries to use explicit synchronization if
they choose by exposing fences directly
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
[snip]
+
+/*
+ * i915 fences on sync timelines
+ *
+ * We implement sync points in terms of i915 seqnos. They're exposed
+ * through the new DRM_I915_GEM_FENCE ioctl, and can be mixed and matched
+ * with other Android timelines and aggregated into sync_fences, etc.
+ *
+ * TODO:
+ * rebase on top of Chris's seqno/request stuff and use requests
+ * allow non-RCS fences (need ring/context association)
+ */
+
+struct i915_sync_timeline {
+ struct sync_timeline obj;
+ struct intel_engine_cs *ring;
+ struct drm_i915_private *dev_priv;
+};
+
+struct i915_sync_pt {
+ struct sync_pt pt;
+ u32 seqno;
+};
In case one day more than seqno needs to be exported to userspace,
perhaps it would be handy to version the driver data somehow to allow
for some forward/backward compatibility? Unless kernel/libdrm are
supposed to be updated in lock-step already.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Initialize the aliasing ppgtt as part of global gtt
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Ville Syrjälä
Sent: Thursday, July 31, 2014 5:16 PM
To: Daniel Vetter
Cc: Intel Graphics Development
Subject: Re: [Intel-gfx] [PATCH 5/7] drm/i915: Initialize the aliasing
ppgtt as
part of global gtt
On Wed, Jul 30, 2014 at 09:42:02PM +0200, Daniel Vetter wrote:
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 31
+--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device
*dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL,
USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4fa7807ed4d5..cb9bb13ff20a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1191,23 +1191,27 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt
*ppgtt)
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt
*ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt
*ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt
*ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
+ ret = __hw_ppgtt_init(dev, ppgtt);
if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
@@ -1728,6 +1732,7 @@ int i915_gem_setup_global_gtt(struct
drm_device *dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1739,7 +1744,7 @@ int i915_gem_setup_global_gtt(struct
drm_device *dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj,
ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx +
%zx\n,
i915_gem_obj_ggtt_offset(obj),
obj-base.size);
@@ -1766,6 +1771,20 @@ int i915_gem_setup_global_gtt(struct
drm_device *dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+ if (HAS_ALIASING_PPGTT(dev) USES_FULL_PPGTT(dev)) {
Should that be !USES_FULL_PPGTT ?
I think we need this for aliasing full ppgtt (the global default ctx)...
so it should be USES_PPGTT.
+ struct i915_hw_ppgtt *ppgtt;
+
+ ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
+ if (!ppgtt)
[Intel-gfx] [PATCH 0/4] BDW DDI buffer level shifters for HDMI/DVI
While cruising through the specs, I noticed that we were missing the BDW HDMI DDI buffer tables. Patch 1: re-factor how we handle the VBT entry as the parsing code made HSW-specific assumptions about the level tables Patch 2: The actual BDW tables Pathes 3 4 are trivial clean ups on top. (Paulo is signed up for rewiew) -- Damien Damien Lespiau (4): drm/i915: Gather the HDMI level shifter logic into one place drm/i915/bdw: Provide the BDW specific HDMI buffer translation table drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables drm/i915: Remove now useless comments about the translation values drivers/gpu/drm/i915/i915_drv.h | 6 + drivers/gpu/drm/i915/intel_bios.c | 13 +-- drivers/gpu/drm/i915/intel_ddi.c | 47 ++- 3 files changed, 48 insertions(+), 18 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/bdw: Provide the BDW specific HDMI buffer translation table
Among the changes, the tables has only 10 entries instead of 12 on HSW
and the index the the 800mV/0dB entry has changed.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 80e2a42..67feea2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -111,6 +111,20 @@ static const u32 bdw_ddi_translations_fdi[] = {
0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
+static const u32 bdw_ddi_translations_hdmi[] = {
+ /* Idx NT mV diff T mV diff db */
+ 0x00FF, 0x0007000E, /* 0: 400 400 0 */
+ 0x00D75FFF, 0x000E000A, /* 1: 400 600 3.5 */
+ 0x00BE, 0x00140006, /* 2: 400 800 6 */
+ 0x00FF, 0x0009000D, /* 3: 450 450 0 */
+ 0x00FF, 0x000E000A, /* 4: 600 600 0 */
+ 0x00D7, 0x00140006, /* 5: 600 800 2.5 */
+ 0x80CB2FFF, 0x001B0002, /* 6: 600 10004.5 */
+ 0x00FF, 0x00140006, /* 7: 800 800 0 */
+ 0x80E79FFF, 0x001B0002, /* 8: 800 10002 */
+ 0x80FF, 0x001B0002, /* 9: 100010000 */
+};
+
enum port intel_ddi_get_encoder_port(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
@@ -150,18 +164,21 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
const u32 *ddi_translations_fdi;
const u32 *ddi_translations_dp;
const u32 *ddi_translations_edp;
+ const u32 *ddi_translations_hdmi;
const u32 *ddi_translations;
if (IS_BROADWELL(dev)) {
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
ddi_translations_edp = bdw_ddi_translations_edp;
- n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
- hdmi_800mV_0dB = 6;
+ ddi_translations_hdmi = bdw_ddi_translations_hdmi;
+ n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 7;
} else if (IS_HASWELL(dev)) {
ddi_translations_fdi = hsw_ddi_translations_fdi;
ddi_translations_dp = hsw_ddi_translations_dp;
ddi_translations_edp = hsw_ddi_translations_dp;
+ ddi_translations_hdmi = hsw_ddi_translations_hdmi;
n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
hdmi_800mV_0dB = 6;
} else {
@@ -169,8 +186,9 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
ddi_translations_edp = bdw_ddi_translations_dp;
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
- n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
- hdmi_800mV_0dB = 6;
+ ddi_translations_hdmi = bdw_ddi_translations_hdmi;
+ n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 7;
}
switch (port) {
@@ -207,7 +225,7 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
/* Entry 9 is for HDMI: */
for (i = 0; i 2; i++) {
- I915_WRITE(reg, hsw_ddi_translations_hdmi[hdmi_level * 2 + i]);
+ I915_WRITE(reg, ddi_translations_hdmi[hdmi_level * 2 + i]);
reg += 4;
}
}
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Remove now useless comments about the translation values
We used to carry a default HDMI value in entry 9, but this entry got
removed for both HSW and BDW.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 80526ab..ab5f65f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -33,7 +33,7 @@
* automatically adapt to HDMI connections as well
*/
static const u32 hsw_ddi_translations_dp[] = {
- 0x00FF, 0x0006000E, /* DP parameters */
+ 0x00FF, 0x0006000E,
0x00D75FFF, 0x0005000A,
0x00C30FFF, 0x00040006,
0x80AAAFFF, 0x000B,
@@ -45,7 +45,7 @@ static const u32 hsw_ddi_translations_dp[] = {
};
static const u32 hsw_ddi_translations_fdi[] = {
- 0x00FF, 0x0007000E, /* FDI parameters */
+ 0x00FF, 0x0007000E,
0x00D75FFF, 0x000F000A,
0x00C30FFF, 0x00060006,
0x00AAAFFF, 0x001E,
@@ -73,7 +73,7 @@ static const u32 hsw_ddi_translations_hdmi[] = {
};
static const u32 bdw_ddi_translations_edp[] = {
- 0x00FF, 0x0012, /* eDP parameters */
+ 0x00FF, 0x0012,
0x00EBAFFF, 0x00020011,
0x00C71FFF, 0x0006000F,
0x00AAAFFF, 0x000E000A,
@@ -85,7 +85,7 @@ static const u32 bdw_ddi_translations_edp[] = {
};
static const u32 bdw_ddi_translations_dp[] = {
- 0x00FF, 0x0007000E, /* DP parameters */
+ 0x00FF, 0x0007000E,
0x00D75FFF, 0x000E000A,
0x00BE, 0x00140006,
0x80B2CFFF, 0x001B0002,
@@ -97,7 +97,7 @@ static const u32 bdw_ddi_translations_dp[] = {
};
static const u32 bdw_ddi_translations_fdi[] = {
- 0x00FF, 0x0001000E, /* FDI parameters */
+ 0x00FF, 0x0001000E,
0x00D75FFF, 0x0004000A,
0x00C30FFF, 0x00070006,
0x00AAAFFF, 0x000C,
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Gather the HDMI level shifter logic into one place
The knowledge about the HDMI/DVI DDI translation table was scattered
around.
- info-hdmi_level_shift was initialized with 6, the index of the 800
mV, 0dB translation
- A check on the VBT value was done to ensure it wasn't overflowing
the translation table ( 0xC)
- The actual programming was done in intel_ddi.c
As we need to change that knowledge for Broadwell, let's gather
everything into one place.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_bios.c | 13 +
drivers/gpu/drm/i915/intel_ddi.c | 14 +-
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..2e41616 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1229,6 +1229,12 @@ enum modeset_restore {
};
struct ddi_vbt_port_info {
+ /*
+* This is an index in the HDMI/DVI DDI buffer translation table.
+* The special value HDMI_LEVEL_SHIFT_UNKNOWN means the VBT didn't
+* populate this field.
+*/
+#define HDMI_LEVEL_SHIFT_UNKNOWN 0xff
uint8_t hdmi_level_shift;
uint8_t supports_dvi:1;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index a669550..031c565 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -976,12 +976,10 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
if (bdb-version = 158) {
/* The VBT HDMI level shift values match the table we have. */
hdmi_level_shift = child-raw[7] 0xF;
- if (hdmi_level_shift 0xC) {
- DRM_DEBUG_KMS(VBT HDMI level shift for port %c: %d\n,
- port_name(port),
- hdmi_level_shift);
- info-hdmi_level_shift = hdmi_level_shift;
- }
+ DRM_DEBUG_KMS(VBT HDMI level shift for port %c: %d\n,
+ port_name(port),
+ hdmi_level_shift);
+ info-hdmi_level_shift = hdmi_level_shift;
}
}
@@ -1114,8 +1112,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
struct ddi_vbt_port_info *info =
dev_priv-vbt.ddi_port_info[port];
- /* Recommended BSpec default: 800mV 0dB. */
- info-hdmi_level_shift = 6;
+ info-hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN;
info-supports_dvi = (port != PORT_A port != PORT_E);
info-supports_hdmi = info-supports_dvi;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6024de..80e2a42 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -145,7 +145,7 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u32 reg;
- int i;
+ int i, n_hdmi_entries, hdmi_800mV_0dB;
int hdmi_level = dev_priv-vbt.ddi_port_info[port].hdmi_level_shift;
const u32 *ddi_translations_fdi;
const u32 *ddi_translations_dp;
@@ -156,15 +156,21 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
ddi_translations_edp = bdw_ddi_translations_edp;
+ n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 6;
} else if (IS_HASWELL(dev)) {
ddi_translations_fdi = hsw_ddi_translations_fdi;
ddi_translations_dp = hsw_ddi_translations_dp;
ddi_translations_edp = hsw_ddi_translations_dp;
+ n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 6;
} else {
WARN(1, ddi translation table missing\n);
ddi_translations_edp = bdw_ddi_translations_dp;
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
+ n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 6;
}
switch (port) {
@@ -193,6 +199,12 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
I915_WRITE(reg, ddi_translations[i]);
reg += 4;
}
+
+ /* Choose a good default if VBT is badly populated */
+ if (hdmi_level == HDMI_LEVEL_SHIFT_UNKNOWN ||
+ hdmi_level = n_hdmi_entries)
+ hdmi_level = hdmi_800mV_0dB;
+
/* Entry 9 is for HDMI: */
for (i = 0; i 2; i++) {
[Intel-gfx] [PATCH 3/4] drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables
We always write entries 0 to 8 from the DDI translation tables and then
entry 9 for HDMI/DVI with the help of the VBT. We then don't need the
failsafe HDMI entry in the DP/eDP/FDI tables.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 67feea2..80526ab 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -82,7 +82,6 @@ static const u32 bdw_ddi_translations_edp[] = {
0x00BEEFFF, 0x000A000C,
0x00FF, 0x0005000F,
0x00DB6FFF, 0x000A000C,
- 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
static const u32 bdw_ddi_translations_dp[] = {
@@ -95,7 +94,6 @@ static const u32 bdw_ddi_translations_dp[] = {
0x80CB2FFF, 0x001B0002,
0x00F7DFFF, 0x00180004,
0x80D75FFF, 0x001B0002,
- 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
static const u32 bdw_ddi_translations_fdi[] = {
@@ -108,7 +106,6 @@ static const u32 bdw_ddi_translations_fdi[] = {
0x00C30FFF, 0x000C,
0x00FF, 0x00070006,
0x00D75FFF, 0x000C,
- 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
static const u32 bdw_ddi_translations_hdmi[] = {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Introduce FBC False Color for debug purposes.
On Thu, Jul 31, 2014 at 12:07:22PM -0700, Rodrigo Vivi wrote:
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this patch
introduces a persistent way to enable false color over debugfs.
v2: Use DEFINE_SIMPLE_ATTRIBUTE as Daniel suggested
v3: (Ville) only do false color for IVB+ since according to spec bit is
MBZ before IVB.
v4: We don't have FBC on valleyview nor on cherryview (Ben)
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 42
+
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +++
4 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..2147b41 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1433,6 +1433,47 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_fbc_fc_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen 7 || !HAS_PCH_SPLIT(dev))
Better use HAS_FBC()
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+ *val = dev_priv-fbc.false_color;
+ drm_modeset_unlock_all(dev);
+
+ return 0;
+}
+
+static int i915_fbc_fc_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 reg;
+
+ if (INTEL_INFO(dev)-gen 7 || !HAS_PCH_SPLIT(dev))
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+
+ reg = I915_READ(ILK_DPFC_CONTROL);
+ dev_priv-fbc.false_color = val;
+
+ I915_WRITE(ILK_DPFC_CONTROL, val ?
+(reg | FBC_CTL_FALSE_COLOR) :
+(reg ~FBC_CTL_FALSE_COLOR));
+
+ drm_modeset_unlock_all(dev);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_fbc_fc_fops,
+ i915_fbc_fc_get, i915_fbc_fc_set,
+ %llu\n);
+
static int i915_ips_status(struct seq_file *m, void *unused)
{
struct drm_info_node *node = m-private;
@@ -3957,6 +3998,7 @@ static const struct i915_debugfs_files {
{i915_pri_wm_latency, i915_pri_wm_latency_fops},
{i915_spr_wm_latency, i915_spr_wm_latency_fops},
{i915_cur_wm_latency, i915_cur_wm_latency_fops},
+ {i915_fbc_false_color, i915_fbc_fc_fops},
};
void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..3a29f9e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -636,6 +636,8 @@ struct i915_fbc {
struct drm_mm_node compressed_fb;
struct drm_mm_node *compressed_llb;
+ bool false_color;
+
struct intel_fbc_work {
struct delayed_work work;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 28e21ed..b5d295a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1540,6 +1540,7 @@ enum punit_power_well {
/* Framebuffer compression for Ironlake */
#define ILK_DPFC_CB_BASE 0x43200
#define ILK_DPFC_CONTROL 0x43208
+#define FBC_CTL_FALSE_COLOR(110)
/* The bit 28-8 is reserved */
#define DPFC_RESERVED (0x1F00)
#define ILK_DPFC_RECOMP_CTL 0x4320c
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1ddd4df..338a80b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -309,6 +309,9 @@ static void gen7_enable_fbc(struct drm_crtc *crtc)
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
+ if (dev_priv-fbc.false_color)
+ dpfc_ctl |= FBC_CTL_FALSE_COLOR;
+
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
if (IS_IVYBRIDGE(dev)) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: don't try and probe dpcd if we have no dp configured
On hsw/bdw VBT can signal no DP on a digital connector, so when we
get a hotplug irq in that situation, don't continue if we haven't
actually got a DP output register configured.
This fixes an oops where the aux mutex isn't initialised.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856
Reported-by: lei.a@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e7a7953..691d169 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3966,6 +3966,9 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
goto mst_fail;
+ if (!intel_dp-output_reg)
+ goto mst_fail;
+
if (!intel_dp_get_dpcd(intel_dp)) {
goto mst_fail;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: don't try and probe dpcd if we have no dp configured
On Fri, Aug 01, 2014 at 08:47:13PM +1000, Dave Airlie wrote:
On hsw/bdw VBT can signal no DP on a digital connector, so when we
get a hotplug irq in that situation, don't continue if we haven't
actually got a DP output register configured.
This fixes an oops where the aux mutex isn't initialised.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856
Reported-by: lei.a@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e7a7953..691d169 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3966,6 +3966,9 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
goto mst_fail;
+ if (!intel_dp-output_reg)
+ goto mst_fail;
+
What about just not setting the hpd_pulse function pointer when it's
not a DP connector?
if (!intel_dp_get_dpcd(intel_dp)) {
goto mst_fail;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/40] drm/i915: Fill out the FWx watermark register defines
On Thu, Jul 31, 2014 at 05:16:21PM -0300, Paulo Zanoni wrote:
2014-06-27 20:04 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add defines for all the watermark registers on modernish gmch platforms.
VLV has increased the number of bits available for certain watermaks so
expand the masks appropriately. Also vlv and chv have added some extra
FW registers.
Not sure what happened on chv because a new register called FW9 is now
at the offset where FW7 was on vlv, while FW7 and FW8 (another new
register) have been moved off somewhere else. Oh well, well just need
two defines for FW7 then.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 138
+++-
drivers/gpu/drm/i915/intel_pm.c | 11 ++--
2 files changed, 130 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 7ab5a03..9fab647 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3884,28 +3884,136 @@ enum punit_power_well {
#define DSPARB_BEND_SHIFT9 /* on 855 */
#define DSPARB_AEND_SHIFT0
+/* pnv/gen4/g4x/vlv/chv */
#define DSPFW1 (dev_priv-info.display_mmio_offset +
0x70034)
-#define DSPFW_SR_SHIFT 23
-#define DSPFW_SR_MASK(0x1ff23)
-#define DSPFW_CURSORB_SHIFT 16
-#define DSPFW_CURSORB_MASK (0x3f16)
-#define DSPFW_PLANEB_SHIFT 8
-#define DSPFW_PLANEB_MASK(0x7f8)
-#define DSPFW_PLANEA_MASK(0x7f)
+#define DSPFW_SR_SHIFT 23
+#define DSPFW_SR_MASK(0x1ff23)
+#define DSPFW_CURSORB_SHIFT 16
+#define DSPFW_CURSORB_MASK (0x3f16)
+#define DSPFW_PLANEB_SHIFT 8
+#define DSPFW_PLANEB_MASK(0x7f8)
+#define DSPFW_PLANEB_MASK_VLV(0xff8) /* vlv/chv */
+#define DSPFW_PLANEA_SHIFT 0
+#define DSPFW_PLANEA_MASK(0x7f0)
+#define DSPFW_PLANEA_MASK_VLV(0xff0) /* vlv/chv */
#define DSPFW2 (dev_priv-info.display_mmio_offset +
0x70038)
-#define DSPFW_CURSORA_MASK 0x3f00
-#define DSPFW_CURSORA_SHIFT 8
-#define DSPFW_PLANEC_MASK(0x7f)
+#define DSPFW_FBC_SR_EN (131) /* g4x */
+#define DSPFW_FBC_SR_SHIFT 28
+#define DSPFW_FBC_SR_MASK(0x728) /* g4x */
+#define DSPFW_FBC_HPLL_SR_SHIFT 24
+#define DSPFW_FBC_HPLL_SR_MASK (0xf24) /* g4x */
+#define DSPFW_SPRITEB_SHIFT (16)
+#define DSPFW_SPRITEB_MASK (0x7f16) /* g4x */
+#define DSPFW_SPRITEB_MASK_VLV (0xff16) /* vlv/chv */
+#define DSPFW_CURSORA_SHIFT 8
+#define DSPFW_CURSORA_MASK (0x3f8)
+#define DSPFW_PLANEC_SHIFT_OLD 0
+#define DSPFW_PLANEC_MASK_OLD(0x7f0) /* pre-gen4
sprite C */
+#define DSPFW_SPRITEA_SHIFT 0
+#define DSPFW_SPRITEA_MASK (0x7f0) /* g4x */
+#define DSPFW_SPRITEA_MASK_VLV (0xff0) /* vlv/chv */
#define DSPFW3 (dev_priv-info.display_mmio_offset +
0x7003c)
-#define DSPFW_HPLL_SR_EN (131)
-#define DSPFW_CURSOR_SR_SHIFT24
+#define DSPFW_HPLL_SR_EN (131)
#define PINEVIEW_SELF_REFRESH_EN (130)
+#define DSPFW_CURSOR_SR_SHIFT24
#define DSPFW_CURSOR_SR_MASK (0x3f24)
#define DSPFW_HPLL_CURSOR_SHIFT 16
#define DSPFW_HPLL_CURSOR_MASK (0x3f16)
-#define DSPFW_HPLL_SR_MASK (0x1ff)
-#define DSPFW4 (dev_priv-info.display_mmio_offset +
0x70070)
-#define DSPFW7 (dev_priv-info.display_mmio_offset +
0x7007c)
+#define DSPFW_HPLL_SR_SHIFT 0
+#define DSPFW_HPLL_SR_MASK (0x1ff0)
+
+/* vlv/chv */
+#define DSPFW4 (VLV_DISPLAY_BASE + 0x70070)
+#define DSPFW_SPRITEB_WM1_SHIFT 16
+#define DSPFW_SPRITEB_WM1_MASK (0xff16)
+#define DSPFW_CURSORA_WM1_SHIFT 8
+#define DSPFW_CURSORA_WM1_MASK (0x3f8)
+#define DSPFW_SPRITEA_WM1_SHIFT 0
+#define DSPFW_SPRITEA_WM1_MASK (0xff0)
+#define DSPFW5 (VLV_DISPLAY_BASE + 0x70074)
+#define DSPFW_PLANEB_WM1_SHIFT 24
+#define DSPFW_PLANEB_WM1_MASK(0xff24)
+#define DSPFW_PLANEA_WM1_SHIFT 16
+#define DSPFW_PLANEA_WM1_MASK(0xff16)
+#define DSPFW_CURSORB_WM1_SHIFT 8
+#define DSPFW_CURSORB_WM1_MASK (0x3f8)
+#define DSPFW_CURSOR_SR_WM1_SHIFT0
+#define DSPFW_CURSOR_SR_WM1_MASK (0x3f0)
+#define DSPFW6 (VLV_DISPLAY_BASE + 0x70078)
+#define DSPFW_SR_WM1_SHIFT 0
+#define DSPFW_SR_WM1_MASK(0x1ff0)
+#define
Re: [Intel-gfx] [PATCH 28/40] drm/i915: Add cherryview_update_wm()
On Thu, Jul 31, 2014 at 05:57:33PM -0300, Paulo Zanoni wrote:
2014-06-27 20:04 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV has a third pipe so we need to compute the watermarks for its
planes. Add cherryview_update_wm() to do just that.
Ok, so basically the only real difference between this code and VLV's
code is when you enable CXSR: on VLV you just enable CXSR after the
other WM registers are already written. I wonder if this is to prevent
any intermediate situations where the previous WM values did not allow
CXSR, so enabling it first would result in errors/underruns. On this
case, the CHV function would need to do the same thing as VLV, right?
Do you have any specific reason for keeping the CXSR code different on
CHV?
I think the difference is just due to me copy pasting the VLV function
before Imre's cxsr fixes went in. I'll respin the patch based on the
latest VLV code.
Also, instead of adding a new function, you could probably just
rewrite vlv_update_wm to use for_each_pipe() instead of the current
method. You'd define plane_wm[num_pipes] arrays instead of one
variable per pipe, then you would be able to use the same function for
both VLV and CHV. Anyway, I don't think we should block your patch
based on this suggestion, so if you just provide a good explanation
for the CXSR question - or a new patch - I'll give a R-B tag.
I did consider it, but I didn't want to start refactoring too much in
this patch. We might be able to unify more of the gmch watermark code
using your suggestion, or even making it just recompute the watermarks
for the current pipe. But that's better left for another patch/series.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 77
-
1 file changed, 76 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index cb0b4b4..346dced 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1364,6 +1364,81 @@ static void valleyview_update_wm(struct drm_crtc
*crtc)
(cursor_sr DSPFW_CURSOR_SR_SHIFT));
}
+static void cherryview_update_wm(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ static const int sr_latency_ns = 12000;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int planea_wm, planeb_wm, planec_wm;
+ int cursora_wm, cursorb_wm, cursorc_wm;
+ int plane_sr, cursor_sr;
+ int ignore_plane_sr, ignore_cursor_sr;
+ unsigned int enabled = 0;
+
+ vlv_update_drain_latency(dev);
+
+ if (g4x_compute_wm0(dev, PIPE_A,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planea_wm, cursora_wm))
+ enabled |= 1 PIPE_A;
+
+ if (g4x_compute_wm0(dev, PIPE_B,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planeb_wm, cursorb_wm))
+ enabled |= 1 PIPE_B;
+
+ if (g4x_compute_wm0(dev, PIPE_C,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planec_wm, cursorc_wm))
+ enabled |= 1 PIPE_C;
+
+ if (single_plane_enabled(enabled)
+ g4x_compute_srwm(dev, ffs(enabled) - 1,
+sr_latency_ns,
+valleyview_wm_info,
+valleyview_cursor_wm_info,
+plane_sr, ignore_cursor_sr)
+ g4x_compute_srwm(dev, ffs(enabled) - 1,
+2*sr_latency_ns,
+valleyview_wm_info,
+valleyview_cursor_wm_info,
+ignore_plane_sr, cursor_sr)) {
+ I915_WRITE(FW_BLC_SELF_VLV, FW_CSPWRDWNEN);
+ } else {
+ I915_WRITE(FW_BLC_SELF_VLV,
+ I915_READ(FW_BLC_SELF_VLV) ~FW_CSPWRDWNEN);
+ plane_sr = cursor_sr = 0;
+ }
+
+ DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d,
+ B: plane=%d, cursor=%d, C: plane=%d, cursor=%d,
+ SR: plane=%d, cursor=%d\n,
+ planea_wm, cursora_wm,
+ planeb_wm, cursorb_wm,
+ planec_wm, cursorc_wm,
+ plane_sr, cursor_sr);
+
+ I915_WRITE(DSPFW1,
+ (plane_sr DSPFW_SR_SHIFT) |
+ (cursorb_wm DSPFW_CURSORB_SHIFT) |
+ (planeb_wm
Re: [Intel-gfx] [PATCH] drm/i915: Add a bit of locking to intel_dp_hpd_pulse()
On Thu, Jul 31, 2014 at 08:59:08PM +1000, Dave Airlie wrote: On 31 July 2014 17:37, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Jul 31, 2014 at 1:49 AM, Dave Airlie airl...@gmail.com wrote: Daniel, the only way intel_dp-is_mst can get reset is inside this path. Ok, so that one should be safe. Then I guess we can just push the locking down into the respective non-mst leafs (since atm we do link-retraining without any locking, which isn't good). And it needs to be dev-mode_config.mutex, not connection mutex. Why that? We can't be doing a modeset w/o connection_mutex so that seems like it should be enough. Well, there's also dpms which leaves the crtc-encoder-connector links intact but that too takes connection_mutex currently. I'd like to know why we do link training at this point though as well, adding locking is required of course, I was just going to wrap the short irq call to the link status check with the lock, but I think it should be possible to push it down further, I don't really know why the sink generates the hpd when we turn off the port, but that doesn't really matter I think. We need to be prepared for hpds at any time. intel_dp_check_link_status() just checks if there's a crtc, which there is (either the old one or the new one, depending on how far along the modeset path we are I guess), and then it just checks drm_dp_channel_eq_ok() which says false since the link was turned off, and then it proceeds to retrain the link. Maybe it should also check crtc-active? Though that itself won't eliminate the problem unless the locking gets fixed somehow. I'm not sure how vague the spec is on what should happen on HPDs, but if we drop the port clock we obviously will lose the link, but we should also know not to be retraining it at that point anyways. Dave. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: fix VDD state tracking after system resume
On Thu, Jul 31, 2014 at 02:03:36PM +0300, Imre Deak wrote:
Just like during booting the BIOS can leave the VDD bit enabled after
system resume. So apply the same state sanitization there too. This
fixes a problem where after resume the port power domain refcount gets
unbalanced.
v2:
- unchanged
v3:
- call edp sanitizing from the encoder reset handler (Daniel)
It happens a bit earlier than with the earlier attempt, but if
it works it works.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reported-and-tested-by: Jarkko Nikula jarkko.nik...@linux.intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 71294b5..8741439 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4002,6 +4002,11 @@ void intel_dp_encoder_destroy(struct drm_encoder
*encoder)
kfree(intel_dig_port);
}
+static void intel_dp_encoder_reset(struct drm_encoder *encoder)
+{
+ intel_edp_panel_vdd_sanitize(to_intel_encoder(encoder));
+}
+
static const struct drm_connector_funcs intel_dp_connector_funcs = {
.dpms = intel_connector_dpms,
.detect = intel_dp_detect,
@@ -4017,6 +4022,7 @@ static const struct drm_connector_helper_funcs
intel_dp_connector_helper_funcs =
};
static const struct drm_encoder_funcs intel_dp_enc_funcs = {
+ .reset = intel_dp_encoder_reset,
.destroy = intel_dp_encoder_destroy,
};
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 25/40] drm/i915: Fill out the FWx watermark register defines
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add defines for all the watermark registers on modernish gmch platforms.
VLV has increased the number of bits available for certain watermaks so
expand the masks appropriately. Also vlv and chv have added some extra
FW registers.
Not sure what happened on chv because a new register called FW9 is now
at the offset where FW7 was on vlv, while FW7 and FW8 (another new
register) have been moved off somewhere else. Oh well, well just need
two defines for FW7 then.
v2: Fix DSPHOWM1 offset (Paulo)
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 138 +++-
drivers/gpu/drm/i915/intel_pm.c | 11 ++--
2 files changed, 130 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 53117a9..e4163fe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3901,28 +3901,136 @@ enum punit_power_well {
#define DSPARB_BEND_SHIFT9 /* on 855 */
#define DSPARB_AEND_SHIFT0
+/* pnv/gen4/g4x/vlv/chv */
#define DSPFW1 (dev_priv-info.display_mmio_offset + 0x70034)
-#define DSPFW_SR_SHIFT 23
-#define DSPFW_SR_MASK(0x1ff23)
-#define DSPFW_CURSORB_SHIFT 16
-#define DSPFW_CURSORB_MASK (0x3f16)
-#define DSPFW_PLANEB_SHIFT 8
-#define DSPFW_PLANEB_MASK(0x7f8)
-#define DSPFW_PLANEA_MASK(0x7f)
+#define DSPFW_SR_SHIFT 23
+#define DSPFW_SR_MASK(0x1ff23)
+#define DSPFW_CURSORB_SHIFT 16
+#define DSPFW_CURSORB_MASK (0x3f16)
+#define DSPFW_PLANEB_SHIFT 8
+#define DSPFW_PLANEB_MASK(0x7f8)
+#define DSPFW_PLANEB_MASK_VLV(0xff8) /* vlv/chv */
+#define DSPFW_PLANEA_SHIFT 0
+#define DSPFW_PLANEA_MASK(0x7f0)
+#define DSPFW_PLANEA_MASK_VLV(0xff0) /* vlv/chv */
#define DSPFW2 (dev_priv-info.display_mmio_offset + 0x70038)
-#define DSPFW_CURSORA_MASK 0x3f00
-#define DSPFW_CURSORA_SHIFT 8
-#define DSPFW_PLANEC_MASK(0x7f)
+#define DSPFW_FBC_SR_EN (131) /* g4x */
+#define DSPFW_FBC_SR_SHIFT 28
+#define DSPFW_FBC_SR_MASK(0x728) /* g4x */
+#define DSPFW_FBC_HPLL_SR_SHIFT 24
+#define DSPFW_FBC_HPLL_SR_MASK (0xf24) /* g4x */
+#define DSPFW_SPRITEB_SHIFT (16)
+#define DSPFW_SPRITEB_MASK (0x7f16) /* g4x */
+#define DSPFW_SPRITEB_MASK_VLV (0xff16) /* vlv/chv */
+#define DSPFW_CURSORA_SHIFT 8
+#define DSPFW_CURSORA_MASK (0x3f8)
+#define DSPFW_PLANEC_SHIFT_OLD 0
+#define DSPFW_PLANEC_MASK_OLD(0x7f0) /* pre-gen4 sprite C
*/
+#define DSPFW_SPRITEA_SHIFT 0
+#define DSPFW_SPRITEA_MASK (0x7f0) /* g4x */
+#define DSPFW_SPRITEA_MASK_VLV (0xff0) /* vlv/chv */
#define DSPFW3 (dev_priv-info.display_mmio_offset + 0x7003c)
-#define DSPFW_HPLL_SR_EN (131)
-#define DSPFW_CURSOR_SR_SHIFT24
+#define DSPFW_HPLL_SR_EN (131)
#define PINEVIEW_SELF_REFRESH_EN (130)
+#define DSPFW_CURSOR_SR_SHIFT24
#define DSPFW_CURSOR_SR_MASK (0x3f24)
#define DSPFW_HPLL_CURSOR_SHIFT 16
#define DSPFW_HPLL_CURSOR_MASK (0x3f16)
-#define DSPFW_HPLL_SR_MASK (0x1ff)
-#define DSPFW4 (dev_priv-info.display_mmio_offset + 0x70070)
-#define DSPFW7 (dev_priv-info.display_mmio_offset + 0x7007c)
+#define DSPFW_HPLL_SR_SHIFT 0
+#define DSPFW_HPLL_SR_MASK (0x1ff0)
+
+/* vlv/chv */
+#define DSPFW4 (VLV_DISPLAY_BASE + 0x70070)
+#define DSPFW_SPRITEB_WM1_SHIFT 16
+#define DSPFW_SPRITEB_WM1_MASK (0xff16)
+#define DSPFW_CURSORA_WM1_SHIFT 8
+#define DSPFW_CURSORA_WM1_MASK (0x3f8)
+#define DSPFW_SPRITEA_WM1_SHIFT 0
+#define DSPFW_SPRITEA_WM1_MASK (0xff0)
+#define DSPFW5 (VLV_DISPLAY_BASE + 0x70074)
+#define DSPFW_PLANEB_WM1_SHIFT 24
+#define DSPFW_PLANEB_WM1_MASK(0xff24)
+#define DSPFW_PLANEA_WM1_SHIFT 16
+#define DSPFW_PLANEA_WM1_MASK(0xff16)
+#define DSPFW_CURSORB_WM1_SHIFT 8
+#define DSPFW_CURSORB_WM1_MASK (0x3f8)
+#define DSPFW_CURSOR_SR_WM1_SHIFT0
+#define DSPFW_CURSOR_SR_WM1_MASK (0x3f0)
+#define DSPFW6 (VLV_DISPLAY_BASE + 0x70078)
+#define DSPFW_SR_WM1_SHIFT 0
+#define DSPFW_SR_WM1_MASK(0x1ff0)
+#define DSPFW7 (VLV_DISPLAY_BASE + 0x7007c)
+#define DSPFW7_CHV (VLV_DISPLAY_BASE + 0x700b4) /* wtf #1? */
+#define DSPFW_SPRITED_WM1_SHIFT 24
+#define DSPFW_SPRITED_WM1_MASK (0xff24)
+#define DSPFW_SPRITED_SHIFT
Re: [Intel-gfx] [PATCH 24/40] drm/i915: Fix threshold for choosing 32 vs. 64 precisions for VLV DDL values
On Thu, Jul 31, 2014 at 03:08:29PM -0300, Paulo Zanoni wrote: 2014-06-27 20:04 GMT-03:00 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com The DDL registers can hold 7bit numbers. Make the most of those seven bits by adjusting the threshold where we switch between the 64 vs. 32 precision multipliers. Also we compute 'entries' to make the decision about precision, and then we recompute the same value to calculate the actual drain latency. Just use the already calculate 'entries' there. Just an addition: don't we also want to WARN in case entires 64 (or in case the final result exceeds 7 bits, which is equivalent)? Could be a separate patch too. Yeah we could WARN when things go south. But there are some patches from Gajanan pending that touch this code too, so probably best to wait until those have gone in to avoid too much rebase pain. With or without that: Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 9413184..3aa7959 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1252,15 +1252,14 @@ static bool vlv_compute_drain_latency(struct drm_device *dev, pixel_size = crtc-primary-fb-bits_per_pixel / 8; /* BPP */ entries = (clock / 1000) * pixel_size; - *plane_prec_mult = (entries 256) ? + *plane_prec_mult = (entries 128) ? DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32; - *plane_dl = (64 * (*plane_prec_mult) * 4) / ((clock / 1000) * -pixel_size); + *plane_dl = (64 * (*plane_prec_mult) * 4) / entries; entries = (clock / 1000) * 4; /* BPP is always 4 for cursor */ - *cursor_prec_mult = (entries 256) ? + *cursor_prec_mult = (entries 128) ? DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32; - *cursor_dl = (64 * (*cursor_prec_mult) * 4) / ((clock / 1000) * 4); + *cursor_dl = (64 * (*cursor_prec_mult) * 4) / entries; return true; } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 28/40] drm/i915: Add cherryview_update_wm()
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV has a third pipe so we need to compute the watermarks for its
planes. Add cherryview_update_wm() to do just that.
v2: Rebase on top of Imre's cxsr changes (Paulo)
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 81 -
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 69a099e..a8fc474 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1403,6 +1403,85 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
intel_set_memory_cxsr(dev_priv, true);
}
+static void cherryview_update_wm(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ static const int sr_latency_ns = 12000;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int planea_wm, planeb_wm, planec_wm;
+ int cursora_wm, cursorb_wm, cursorc_wm;
+ int plane_sr, cursor_sr;
+ int ignore_plane_sr, ignore_cursor_sr;
+ unsigned int enabled = 0;
+ bool cxsr_enabled;
+
+ vlv_update_drain_latency(dev);
+
+ if (g4x_compute_wm0(dev, PIPE_A,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planea_wm, cursora_wm))
+ enabled |= 1 PIPE_A;
+
+ if (g4x_compute_wm0(dev, PIPE_B,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planeb_wm, cursorb_wm))
+ enabled |= 1 PIPE_B;
+
+ if (g4x_compute_wm0(dev, PIPE_C,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planec_wm, cursorc_wm))
+ enabled |= 1 PIPE_C;
+
+ if (single_plane_enabled(enabled)
+ g4x_compute_srwm(dev, ffs(enabled) - 1,
+sr_latency_ns,
+valleyview_wm_info,
+valleyview_cursor_wm_info,
+plane_sr, ignore_cursor_sr)
+ g4x_compute_srwm(dev, ffs(enabled) - 1,
+2*sr_latency_ns,
+valleyview_wm_info,
+valleyview_cursor_wm_info,
+ignore_plane_sr, cursor_sr)) {
+ cxsr_enabled = true;
+ } else {
+ cxsr_enabled = false;
+ intel_set_memory_cxsr(dev_priv, false);
+ plane_sr = cursor_sr = 0;
+ }
+
+ DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d,
+ B: plane=%d, cursor=%d, C: plane=%d, cursor=%d,
+ SR: plane=%d, cursor=%d\n,
+ planea_wm, cursora_wm,
+ planeb_wm, cursorb_wm,
+ planec_wm, cursorc_wm,
+ plane_sr, cursor_sr);
+
+ I915_WRITE(DSPFW1,
+ (plane_sr DSPFW_SR_SHIFT) |
+ (cursorb_wm DSPFW_CURSORB_SHIFT) |
+ (planeb_wm DSPFW_PLANEB_SHIFT) |
+ (planea_wm DSPFW_PLANEA_SHIFT));
+ I915_WRITE(DSPFW2,
+ (I915_READ(DSPFW2) ~DSPFW_CURSORA_MASK) |
+ (cursora_wm DSPFW_CURSORA_SHIFT));
+ I915_WRITE(DSPFW3,
+ (I915_READ(DSPFW3) ~DSPFW_CURSOR_SR_MASK) |
+ (cursor_sr DSPFW_CURSOR_SR_SHIFT));
+ I915_WRITE(DSPFW9_CHV,
+ (I915_READ(DSPFW9_CHV) ~(DSPFW_PLANEC_MASK |
+ DSPFW_CURSORC_MASK)) |
+ (planec_wm DSPFW_PLANEC_SHIFT) |
+ (cursorc_wm DSPFW_CURSORC_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
+}
+
static void g4x_update_wm(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -7170,7 +7249,7 @@ void intel_init_pm(struct drm_device *dev)
else if (INTEL_INFO(dev)-gen == 8)
dev_priv-display.init_clock_gating =
gen8_init_clock_gating;
} else if (IS_CHERRYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = cherryview_update_wm;
dev_priv-display.init_clock_gating =
cherryview_init_clock_gating;
} else if (IS_VALLEYVIEW(dev)) {
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
Hi Randy, On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: On 05/12/14 11:04, Randy Dunlap wrote: On 05/12/2014 08:54 AM, Daniel Vetter wrote: On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: On 05/12/2014 01:58 AM, Daniel Vetter wrote: On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: If we decide to go for property documentation inside the source code then I believe we'll have to create our own format, as creating a properties table from kerneldoc information extracted from comments is probably not possible. Can comeone pick up the ball here and figure out what needs to be done? The reason why I want a central place for the documentation is to force people to collaborate outside their own sandbox when adding properties. Whether that's docbook or some text file I don't care so much at this point. The fact that it's a central place should mandate that the patches changing it will go through dri-devel and so everyone should se them, and when adding new properties it would make the patch author more likely to look around a bit before adding another slighty incompatible version of the same property. If someone has a better suggestion how to encforce this I'm all ears. Of course this idea can still fail if our esteemed maintainer merges stuff without checking for violations of this policy. Dave, any thoughts on the subject? Yeah I'm happy to block merging stuff, if we can spot new properties when stuff is posted on dri-devel, so much the better, most drivers still send everything via dri-devel anyways, its only really Intel I have to worry about so far, I'll enforce that all prop stuff gets cc: dri-devel and that it has updates for the prop docs. But we should definitely add it to the new driver review checklist as well. I'm also on the side of this patch is ugly and makes my eyes burn, please please get a plan to use something else ASAP, I'm willing to merge this but I'm tempted to give it a lifetime of a kernel or two before I burn it. Ok, I'll try to move make kerneldoc suck less up the task list and maybe find someone to do it for me internally ;-) I certainly have no objections to making kerneldoc suck less. There was already an attempt to use asciidoc (like git uses) for kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that effort. Hm, do you have pointers to those? My google-fu seems lacking ... I googled for /kernel doc asciidoc ravnborg/ and found several hits for them. Ok, let's move this to the top and start discussions. The past few months I've written piles of kerneldoc comments for the DRM DocBook (all pulled in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: sections are really useful to pull all the actual documentation out of the docbook xml into kerneldoc. But I've also done piles of docs for intel-gpu-tools, which is using gtkdoc. And there are some clear deficiencies: - No markdown for inline coments. Lack of lists and tables is hurting especially badly. If we add this (and I don't care one iota whether it's Yes, I've tried to add lists to kernel-doc notation but have failed so far. markdown or asciidoc or something else as long as it's readable plain text in comments) we should be able to move all the existing docbook xml paragraphs/lists/tables into kerneldoc comments. - Automatic cross-referencing of functions. If you place e.g. function() or #struct anywhere in a documentation comment gtk-doc automatically inserts a hyperlink to the relevant documentation page across the entire project. Really powerful and makes overview sections much more useful entry points for beginners since they can easily jump backforth betweeen the high-level overview and low-level per-function documentation. That's a nice-to-have IMO, but a really nice one. - In a really perfect world it would help if kerneldoc could collect structure member kerneldoc from per-member comments. Especially for large structures with lots of comments this would bring the kerneldoc and struct member much closer together. So that's my wishlist. OTOH, I would only want to add another way to do kernel-doc if it can be a full replacement for all of our docbook usage, i.e., it should provide a way that we can eliminate docbook and stop using it completely. Hm, I don't mind docbook at all, as long as all the real content is embedded into source files as kerneldoc and the docbook template just pulls in all the right bits and pieces. Even gtkdoc allos you to do that and pull in the different libararies (== header files with declarations for C) in the order you want. So imo the docbook toolchain is good enough for my needs. Or what do you mean by getting rid of all docbook usage? I meant no docbook style sheets, no
Re: [Intel-gfx] [PATCH 14/40] drm/i915: Override display PHY TX FIFO reset master on chv
On Tue, Jul 29, 2014 at 09:57:09AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:05 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Just an attempt to frob these bits. Apparently we should not need to
touch them (apart from maybe making sure the override is disabled so
that the hardware automagically does the right thing).
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_dp.c | 23 +++
drivers/gpu/drm/i915/intel_hdmi.c | 23 +++
3 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 2a7bc22..d246609 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -758,6 +758,8 @@ enum punit_power_well {
#define _VLV_PCS_DW0_CH1 0x8400
#define DPIO_PCS_TX_LANE2_RESET (116)
#define DPIO_PCS_TX_LANE1_RESET (17)
+#define DPIO_LEFT_TXFIFO_RST_MASTER2 (14)
+#define DPIO_RIGHT_TXFIFO_RST_MASTER2(13)
#define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
#define _VLV_PCS01_DW0_CH0 0x200
@@ -834,8 +836,18 @@ enum punit_power_well {
#define _VLV_PCS_DW11_CH0 0x822c
#define _VLV_PCS_DW11_CH1 0x842c
+#define DPIO_LANEDESKEW_STRAP_OVRD (13)
+#define DPIO_LEFT_TXFIFO_RST_MASTER (11)
+#define DPIO_RIGHT_TXFIFO_RST_MASTER (10)
#define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
+#define _VLV_PCS01_DW11_CH00x022c
+#define _VLV_PCS23_DW11_CH00x042c
+#define _VLV_PCS01_DW11_CH10x262c
+#define _VLV_PCS23_DW11_CH10x282c
+#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW0_CH0,
_VLV_PCS01_DW0_CH1)
+#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW0_CH0,
_VLV_PCS23_DW0_CH1)
+
#define _VLV_PCS_DW12_CH0 0x8230
#define _VLV_PCS_DW12_CH1 0x8430
#define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index c59e8fc..814a950 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2139,6 +2139,29 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+ val |= DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index cda6506..47430d5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1358,6 +1358,29 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+ val |= DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data
Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On Thu, 2014-07-31 at 23:47 +0200, Ian Kumlien wrote: On tor, 2014-07-31 at 14:39 +0300, Imre Deak wrote: On Wed, 2014-07-30 at 22:52 +0200, Ian Kumlien wrote: Sorry for the delay, it's been damned hot - vacation is over and overtime has been all the rage at work... No problem, thanks for the feedback. On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote: On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote: Try four, now including CC lists for the intel driver... Could you give a try to the 2 patches at: https://patchwork.kernel.org/patch/4437061/ Didn't quite get that it was two separate patches at first, but when i did i also spotted a v2 of the patch set. I applied: https://patchwork.kernel.org/patch/4648961/ https://patchwork.kernel.org/patch/4648951/ On to 3.16-rc7 (there was some fuzz but it applied fine) I didn't see any OOPS:es (didn't scroll around too much) but otoh the screen never turned off? (it's one of those silly mac things, the apple is still lit) and the machine doesn't suspend/sleep anymore. AFAIR it does, after some coaxing, on the unpatched kernel (ie, not the first time but the second time i turn down the lid, i tried three times and play:ed with brightness as i assume you can see in the log) Hm, I can't see how these patches could prevent system suspend. Also according to the dmesg you sent suspend didn't even start, so I guess you're seeing a separate issue. Maybe the lid notification isn't properly handled, but I can't really help tracking that down. It works without the drm.debug=14 so it might be something else... In any case to reproduce the particular bug in question (or see if the fix works) you need to get the machine to suspend/resume somehow. One way is to 'echo mem /sys/power/state' as root and resume by pressing power button or similar; could you still try this, again sending the dmesg? You'll find it attached ;) Ok, I see the trace of suspend/resume now, but the bug has vanished.. I can't see the WARN backtrace in your original report, nor the debug message from the above fix, that would indicate that it had fixed anything (VDD left on by BIOS, adjusting state tracking). So I'm a bit lost, I would need a full dmesg with either the WARN or this debug message. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 15/40] drm/i915: Clear TX FIFO reset master override bits on chv
From: Ville Syrjälä ville.syrj...@linux.intel.com
Clear the override bits to make sure the hardware maanages
the TX FIFO reset master on its own.
v2: Squash with the earlier attempt at forcing the override bits
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Note to maintainer: This supersedes both 14/40 and 15/40 of the original patches
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_dp.c | 9 +
drivers/gpu/drm/i915/intel_hdmi.c | 9 +
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6e3b13a..1e0b0e6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -787,6 +787,8 @@ enum punit_power_well {
#define _VLV_PCS_DW0_CH1 0x8400
#define DPIO_PCS_TX_LANE2_RESET (116)
#define DPIO_PCS_TX_LANE1_RESET (17)
+#define DPIO_LEFT_TXFIFO_RST_MASTER2 (14)
+#define DPIO_RIGHT_TXFIFO_RST_MASTER2(13)
#define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
#define _VLV_PCS01_DW0_CH0 0x200
@@ -863,8 +865,18 @@ enum punit_power_well {
#define _VLV_PCS_DW11_CH0 0x822c
#define _VLV_PCS_DW11_CH1 0x842c
+#define DPIO_LANEDESKEW_STRAP_OVRD (13)
+#define DPIO_LEFT_TXFIFO_RST_MASTER (11)
+#define DPIO_RIGHT_TXFIFO_RST_MASTER (10)
#define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
+#define _VLV_PCS01_DW11_CH00x022c
+#define _VLV_PCS23_DW11_CH00x042c
+#define _VLV_PCS01_DW11_CH10x262c
+#define _VLV_PCS23_DW11_CH10x282c
+#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW0_CH0, _VLV_PCS01_DW0_CH1)
+#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW0_CH0, _VLV_PCS23_DW0_CH1)
+
#define _VLV_PCS_DW12_CH0 0x8230
#define _VLV_PCS_DW12_CH1 0x8430
#define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 96e5dba..e7700df 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2236,6 +2236,15 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* allow hardware to manage TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val = ~DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val = ~DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 63c577d..8449066 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1378,6 +1378,15 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* allow hardware to manage TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val = ~DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val = ~DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak imre.d...@intel.com wrote: [--8--] Ok, I see the trace of suspend/resume now, but the bug has vanished.. I can't see the WARN backtrace in your original report, nor the debug message from the above fix, that would indicate that it had fixed anything (VDD left on by BIOS, adjusting state tracking). So I'm a bit lost, I would need a full dmesg with either the WARN or this debug message. Well the bug seemed to be a unbalanced _put _get thing. At least that's the impression i got when reading the code, so what i did, which is part of the original patch, is to make sure that the _put happens so that the mode isn't '0' and thus triggers a warn_on. What we can say is that due to the patch you sent these are now balanced in that code... Actually reading the patches again i can't see how that happened, esp without the debug message... I think I'll have to play some more with this and get back to you when $clue has increased by at least one =) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/43] drm/i915/bdw: Don't write PDP in the legacy way when using LRCs
On Thu, Jul 24, 2014 at 05:04:20PM +0100, Thomas Daniel wrote: From: Oscar Mateo oscar.ma...@intel.com This is mostly for correctness so that we know we are running the LR context correctly (this is, the PDPs are contained inside the context object). v2: Move the check to inside the enable PPGTT function. The switch happens in two places: the legacy context switch (that we won't hit when Execlists are enabled) and the PPGTT enable, which unfortunately we need. This would look much nicer if the ppgtt-enable was part of the ring init, where it logically belongs. Signed-off-by: Oscar Mateo oscar.ma...@intel.com --- drivers/gpu/drm/i915/i915_gem_gtt.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 5188936..ccd70f5 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -852,6 +852,11 @@ static int gen8_ppgtt_enable(struct i915_hw_ppgtt *ppgtt) if (USES_FULL_PPGTT(dev)) continue; + /* In the case of Execlists, we don't want to write the PDPs + * in the legacy way (they live inside the context now) */ + if (i915.enable_execlists) + return 0; This looks like it should be a continue to enable PPGTT on more rings then the render ring? -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: FBC flush nuke for BDW
On Thu, Jul 31, 2014 at 12:07:44PM -0700, Rodrigo Vivi wrote:
According to spec FBC on BDW and HSW are identical without any gaps.
So let's copy the nuke and let FBC really start compressing stuff.
Without this patch we can verify with false color that nothing is being
compressed. With the nuke in place and false color it is possible
to see false color debugs.
v2: Fix rebase conflict.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2908896..4ba3db1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -406,6 +406,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
{
u32 flags = 0;
u32 scratch_addr = ring-scratch.gtt_offset + 2 * CACHELINE_BYTES;
+ int ret;
flags |= PIPE_CONTROL_CS_STALL;
@@ -424,7 +425,14 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- return gen8_emit_pipe_control(ring, flags, scratch_addr);
+ ret = gen8_emit_pipe_control(ring, flags, scratch_addr);
+ if (ret)
+ return ret;
+
+ if (!invalidate_domains flush_domains)
+ return gen7_ring_fbc_flush(ring, FBC_REND_NUKE);
+
+ return 0;
}
static void ring_write_tail(struct intel_engine_cs *ring,
@@ -2065,7 +2073,7 @@ static int gen6_ring_flush(struct intel_engine_cs *ring,
}
intel_ring_advance(ring);
- if (IS_GEN7(dev) !invalidate flush)
+ if (INTEL_INFO(dev)-gen = 7 !invalidate flush)
return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN);
Apparently BDW has problems with LRIs to certain register offsets on
!RCS and this here would hit that. The suggested workaround is to emit
such LRIs only from RCS. Doing that would also involve tossing in a
semaphore, so it feels like something that ought to be handled
somewhere a bit higher up.
return 0;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 28/40] drm/i915: Add cherryview_update_wm()
2014-08-01 9:36 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV has a third pipe so we need to compute the watermarks for its
planes. Add cherryview_update_wm() to do just that.
v2: Rebase on top of Imre's cxsr changes (Paulo)
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 81
-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 69a099e..a8fc474 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1403,6 +1403,85 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
intel_set_memory_cxsr(dev_priv, true);
}
+static void cherryview_update_wm(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ static const int sr_latency_ns = 12000;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int planea_wm, planeb_wm, planec_wm;
+ int cursora_wm, cursorb_wm, cursorc_wm;
+ int plane_sr, cursor_sr;
+ int ignore_plane_sr, ignore_cursor_sr;
+ unsigned int enabled = 0;
+ bool cxsr_enabled;
+
+ vlv_update_drain_latency(dev);
+
+ if (g4x_compute_wm0(dev, PIPE_A,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planea_wm, cursora_wm))
+ enabled |= 1 PIPE_A;
+
+ if (g4x_compute_wm0(dev, PIPE_B,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planeb_wm, cursorb_wm))
+ enabled |= 1 PIPE_B;
+
+ if (g4x_compute_wm0(dev, PIPE_C,
+ valleyview_wm_info, latency_ns,
+ valleyview_cursor_wm_info, latency_ns,
+ planec_wm, cursorc_wm))
+ enabled |= 1 PIPE_C;
+
+ if (single_plane_enabled(enabled)
+ g4x_compute_srwm(dev, ffs(enabled) - 1,
+sr_latency_ns,
+valleyview_wm_info,
+valleyview_cursor_wm_info,
+plane_sr, ignore_cursor_sr)
+ g4x_compute_srwm(dev, ffs(enabled) - 1,
+2*sr_latency_ns,
+valleyview_wm_info,
+valleyview_cursor_wm_info,
+ignore_plane_sr, cursor_sr)) {
+ cxsr_enabled = true;
+ } else {
+ cxsr_enabled = false;
+ intel_set_memory_cxsr(dev_priv, false);
+ plane_sr = cursor_sr = 0;
+ }
+
+ DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d,
+ B: plane=%d, cursor=%d, C: plane=%d, cursor=%d,
+ SR: plane=%d, cursor=%d\n,
+ planea_wm, cursora_wm,
+ planeb_wm, cursorb_wm,
+ planec_wm, cursorc_wm,
+ plane_sr, cursor_sr);
+
+ I915_WRITE(DSPFW1,
+ (plane_sr DSPFW_SR_SHIFT) |
+ (cursorb_wm DSPFW_CURSORB_SHIFT) |
+ (planeb_wm DSPFW_PLANEB_SHIFT) |
+ (planea_wm DSPFW_PLANEA_SHIFT));
+ I915_WRITE(DSPFW2,
+ (I915_READ(DSPFW2) ~DSPFW_CURSORA_MASK) |
+ (cursora_wm DSPFW_CURSORA_SHIFT));
+ I915_WRITE(DSPFW3,
+ (I915_READ(DSPFW3) ~DSPFW_CURSOR_SR_MASK) |
+ (cursor_sr DSPFW_CURSOR_SR_SHIFT));
+ I915_WRITE(DSPFW9_CHV,
+ (I915_READ(DSPFW9_CHV) ~(DSPFW_PLANEC_MASK |
+ DSPFW_CURSORC_MASK)) |
+ (planec_wm DSPFW_PLANEC_SHIFT) |
+ (cursorc_wm DSPFW_CURSORC_SHIFT));
+
+ if (cxsr_enabled)
+ intel_set_memory_cxsr(dev_priv, true);
+}
+
static void g4x_update_wm(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -7170,7 +7249,7 @@ void intel_init_pm(struct drm_device *dev)
else if (INTEL_INFO(dev)-gen == 8)
dev_priv-display.init_clock_gating =
gen8_init_clock_gating;
} else if (IS_CHERRYVIEW(dev)) {
- dev_priv-display.update_wm = valleyview_update_wm;
+ dev_priv-display.update_wm = cherryview_update_wm;
dev_priv-display.init_clock_gating =
cherryview_init_clock_gating;
} else if (IS_VALLEYVIEW(dev)) {
--
1.8.5.5
--
Paulo Zanoni
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH 29/43] drm/i915/bdw: Write the tail pointer, LRC style
On Thu, Jul 24, 2014 at 05:04:37PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
Each logical ring context has the tail pointer in the context object,
so update it before submission.
v2: New namespace.
I believe we could just leave the context object mapped for its whole
lifetime. Something to thing about at a later point.
--
Damien
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 535ef98..5b6f416 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -176,6 +176,21 @@ static void execlists_elsp_write(struct intel_engine_cs
*ring,
gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
}
+static int execlists_ctx_write_tail(struct drm_i915_gem_object *ctx_obj, u32
tail)
+{
+ struct page *page;
+ uint32_t *reg_state;
+
+ page = i915_gem_object_get_page(ctx_obj, 1);
+ reg_state = kmap_atomic(page);
+
+ reg_state[CTX_RING_TAIL+1] = tail;
+
+ kunmap_atomic(reg_state);
+
+ return 0;
+}
+
static int execlists_submit_context(struct intel_engine_cs *ring,
struct intel_context *to0, u32 tail0,
struct intel_context *to1, u32 tail1)
@@ -187,10 +202,14 @@ static int execlists_submit_context(struct
intel_engine_cs *ring,
BUG_ON(!ctx_obj0);
BUG_ON(!i915_gem_obj_is_pinned(ctx_obj0));
+ execlists_ctx_write_tail(ctx_obj0, tail0);
+
if (to1) {
ctx_obj1 = to1-engine[ring-id].state;
BUG_ON(!ctx_obj1);
BUG_ON(!i915_gem_obj_is_pinned(ctx_obj1));
+
+ execlists_ctx_write_tail(ctx_obj1, tail1);
}
execlists_elsp_write(ring, ctx_obj0, ctx_obj1);
--
1.7.9.5
___
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
Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists
On Thu, Jul 24, 2014 at 05:04:42PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests.
v2: The ring is, at this point, already being correctly re-programmed
for Execlists, and the hangcheck counters cleared.
v3: Daniel suggests to drop the if (execlists) because the Execlists
queue should be empty in legacy mode (which is true, if we do the
INIT_LIST_HEAD).
v4: Do the pending intel_runtime_pm_put
I don't see a intel_runtime_pm_get() that put() would correspond to.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 12
drivers/gpu/drm/i915/intel_ringbuffer.c |1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1c83b9c..143cff7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2567,6 +2567,18 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
i915_gem_free_request(request);
}
+ while (!list_empty(ring-execlist_queue)) {
+ struct intel_ctx_submit_request *submit_req;
+
+ submit_req = list_first_entry(ring-execlist_queue,
+ struct intel_ctx_submit_request,
+ execlist_link);
+ list_del(submit_req-execlist_link);
+ intel_runtime_pm_put(dev_priv);
+ i915_gem_context_unreference(submit_req-ctx);
+ kfree(submit_req);
+ }
+
/* These may not have been flush before the reset, do so now */
kfree(ring-preallocated_lazy_request);
ring-preallocated_lazy_request = NULL;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3188403..6e604c9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1587,6 +1587,7 @@ static int intel_init_ring_buffer(struct drm_device
*dev,
ring-dev = dev;
INIT_LIST_HEAD(ring-active_list);
INIT_LIST_HEAD(ring-request_list);
+ INIT_LIST_HEAD(ring-execlist_queue);
ringbuf-size = 32 * PAGE_SIZE;
ringbuf-ring = ring;
ringbuf-ctx = ring-default_context;
--
1.7.9.5
___
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
Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists
On Thu, Jul 24, 2014 at 05:04:42PM +0100, Thomas Daniel wrote: diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 3188403..6e604c9 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1587,6 +1587,7 @@ static int intel_init_ring_buffer(struct drm_device *dev, ring-dev = dev; INIT_LIST_HEAD(ring-active_list); INIT_LIST_HEAD(ring-request_list); + INIT_LIST_HEAD(ring-execlist_queue); It's also a bit weird to now have sites where we initialize this list. or I'm missing something? -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/43] drm/i915/bdw: Display execlists info in debugfs
On Thu, Jul 24, 2014 at 05:04:45PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
v2: Warn and return if LRCs are not enabled.
v3: Grab the Execlists spinlock (noticed by Daniel Vetter).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
This looks like it may be missing a struct_mutex lock to grab a state
atomically.
--
Damien
---
drivers/gpu/drm/i915/i915_debugfs.c | 73
+++
drivers/gpu/drm/i915/intel_lrc.c|6 ---
drivers/gpu/drm/i915/intel_lrc.h|7
3 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fc39610..903ed67 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1674,6 +1674,78 @@ static int i915_context_status(struct seq_file *m,
void *unused)
return 0;
}
+static int i915_execlists(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_engine_cs *ring;
+ u32 status_pointer;
+ u8 read_pointer;
+ u8 write_pointer;
+ u32 status;
+ u32 ctx_id;
+ struct list_head *cursor;
+ int ring_id, i;
+
+ if (!i915.enable_execlists) {
+ seq_printf(m, Logical Ring Contexts are disabled\n);
+ return 0;
+ }
+
+ for_each_ring(ring, dev_priv, ring_id) {
+ struct intel_ctx_submit_request *head_req = NULL;
+ int count = 0;
+ unsigned long flags;
+
+ seq_printf(m, %s\n, ring-name);
+
+ status = I915_READ(RING_EXECLIST_STATUS(ring));
+ ctx_id = I915_READ(RING_EXECLIST_STATUS(ring) + 4);
+ seq_printf(m, \tExeclist status: 0x%08X, context: %u\n,
+ status, ctx_id);
+
+ status_pointer = I915_READ(RING_CONTEXT_STATUS_PTR(ring));
+ seq_printf(m, \tStatus pointer: 0x%08X\n, status_pointer);
+
+ read_pointer = ring-next_context_status_buffer;
+ write_pointer = status_pointer 0x07;
+ if (read_pointer write_pointer)
+ write_pointer += 6;
+ seq_printf(m, \tRead pointer: 0x%08X, write pointer 0x%08X\n,
+ read_pointer, write_pointer);
+
+ for (i = 0; i 6; i++) {
+ status = I915_READ(RING_CONTEXT_STATUS_BUF(ring) + 8*i);
+ ctx_id = I915_READ(RING_CONTEXT_STATUS_BUF(ring) + 8*i
+ 4);
+
+ seq_printf(m, \tStatus buffer %d: 0x%08X, context:
%u\n,
+ i, status, ctx_id);
+ }
+
+ spin_lock_irqsave(ring-execlist_lock, flags);
+ list_for_each(cursor, ring-execlist_queue)
+ count++;
+ head_req = list_first_entry_or_null(ring-execlist_queue,
+ struct intel_ctx_submit_request, execlist_link);
+ spin_unlock_irqrestore(ring-execlist_lock, flags);
+
+ seq_printf(m, \t%d requests in queue\n, count);
+ if (head_req) {
+ struct drm_i915_gem_object *ctx_obj;
+
+ ctx_obj = head_req-ctx-engine[ring_id].state;
+ seq_printf(m, \tHead request id: %u\n,
+ intel_execlists_ctx_id(ctx_obj));
+ seq_printf(m, \tHead request tail: %u\n,
head_req-tail);
+ }
+
+ seq_putc(m, '\n');
+ }
+
+ return 0;
+}
+
static int i915_gen6_forcewake_count_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m-private;
@@ -3899,6 +3971,7 @@ static const struct drm_info_list i915_debugfs_list[] =
{
{i915_opregion, i915_opregion, 0},
{i915_gem_framebuffer, i915_gem_framebuffer_info, 0},
{i915_context_status, i915_context_status, 0},
+ {i915_execlists, i915_execlists, 0},
{i915_gen6_forcewake_count, i915_gen6_forcewake_count_info, 0},
{i915_swizzle_info, i915_swizzle_info, 0},
{i915_ppgtt_info, i915_ppgtt_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 829b15d..8056fa4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -46,12 +46,6 @@
#define GEN8_LR_CONTEXT_ALIGN 4096
-#define RING_ELSP(ring) ((ring)-mmio_base+0x230)
-#define RING_EXECLIST_STATUS(ring) ((ring)-mmio_base+0x234)
-#define RING_CONTEXT_CONTROL(ring) ((ring)-mmio_base+0x244)
-#define RING_CONTEXT_STATUS_BUF(ring)((ring)-mmio_base+0x370)
-#define RING_CONTEXT_STATUS_PTR(ring)((ring)-mmio_base+0x3a0)
-
#define RING_EXECLIST_QFULL
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Gather the HDMI level shifter logic into one place
2014-08-01 7:07 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
The knowledge about the HDMI/DVI DDI translation table was scattered
around.
- info-hdmi_level_shift was initialized with 6, the index of the 800
mV, 0dB translation
- A check on the VBT value was done to ensure it wasn't overflowing
the translation table ( 0xC)
- The actual programming was done in intel_ddi.c
As we need to change that knowledge for Broadwell, let's gather
everything into one place.
Yeah, it's much better this way.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_bios.c | 13 +
drivers/gpu/drm/i915/intel_ddi.c | 14 +-
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..2e41616 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1229,6 +1229,12 @@ enum modeset_restore {
};
struct ddi_vbt_port_info {
+ /*
+* This is an index in the HDMI/DVI DDI buffer translation table.
+* The special value HDMI_LEVEL_SHIFT_UNKNOWN means the VBT didn't
+* populate this field.
+*/
+#define HDMI_LEVEL_SHIFT_UNKNOWN 0xff
uint8_t hdmi_level_shift;
uint8_t supports_dvi:1;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index a669550..031c565 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -976,12 +976,10 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
if (bdb-version = 158) {
/* The VBT HDMI level shift values match the table we have. */
hdmi_level_shift = child-raw[7] 0xF;
- if (hdmi_level_shift 0xC) {
- DRM_DEBUG_KMS(VBT HDMI level shift for port %c:
%d\n,
- port_name(port),
- hdmi_level_shift);
- info-hdmi_level_shift = hdmi_level_shift;
- }
+ DRM_DEBUG_KMS(VBT HDMI level shift for port %c: %d\n,
+ port_name(port),
+ hdmi_level_shift);
+ info-hdmi_level_shift = hdmi_level_shift;
}
}
@@ -1114,8 +1112,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
struct ddi_vbt_port_info *info =
dev_priv-vbt.ddi_port_info[port];
- /* Recommended BSpec default: 800mV 0dB. */
- info-hdmi_level_shift = 6;
+ info-hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN;
info-supports_dvi = (port != PORT_A port != PORT_E);
info-supports_hdmi = info-supports_dvi;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index a6024de..80e2a42 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -145,7 +145,7 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u32 reg;
- int i;
+ int i, n_hdmi_entries, hdmi_800mV_0dB;
int hdmi_level = dev_priv-vbt.ddi_port_info[port].hdmi_level_shift;
const u32 *ddi_translations_fdi;
const u32 *ddi_translations_dp;
@@ -156,15 +156,21 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
ddi_translations_edp = bdw_ddi_translations_edp;
+ n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 6;
} else if (IS_HASWELL(dev)) {
ddi_translations_fdi = hsw_ddi_translations_fdi;
ddi_translations_dp = hsw_ddi_translations_dp;
ddi_translations_edp = hsw_ddi_translations_dp;
+ n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 6;
} else {
WARN(1, ddi translation table missing\n);
ddi_translations_edp = bdw_ddi_translations_dp;
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
+ n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 6;
}
switch (port) {
@@ -193,6 +199,12 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
I915_WRITE(reg, ddi_translations[i]);
reg += 4;
}
+
+ /* Choose a good default if VBT is
Re: [Intel-gfx] [PATCH 2/4] drm/i915/bdw: Provide the BDW specific HDMI buffer translation table
2014-08-01 7:07 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
Among the changes, the tables has only 10 entries instead of 12 on HSW
and the index the the 800mV/0dB entry has changed.
And now your HDMI monitors on BDW will look better if you have eagle eyes.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 80e2a42..67feea2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -111,6 +111,20 @@ static const u32 bdw_ddi_translations_fdi[] = {
0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
+static const u32 bdw_ddi_translations_hdmi[] = {
+ /* Idx NT mV diff T mV diff db */
+ 0x00FF, 0x0007000E, /* 0: 400 400 0 */
+ 0x00D75FFF, 0x000E000A, /* 1: 400 600 3.5 */
+ 0x00BE, 0x00140006, /* 2: 400 800 6 */
+ 0x00FF, 0x0009000D, /* 3: 450 450 0 */
+ 0x00FF, 0x000E000A, /* 4: 600 600 0 */
+ 0x00D7, 0x00140006, /* 5: 600 800 2.5 */
+ 0x80CB2FFF, 0x001B0002, /* 6: 600 10004.5 */
+ 0x00FF, 0x00140006, /* 7: 800 800 0 */
+ 0x80E79FFF, 0x001B0002, /* 8: 800 10002 */
+ 0x80FF, 0x001B0002, /* 9: 100010000 */
+};
+
enum port intel_ddi_get_encoder_port(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
@@ -150,18 +164,21 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
const u32 *ddi_translations_fdi;
const u32 *ddi_translations_dp;
const u32 *ddi_translations_edp;
+ const u32 *ddi_translations_hdmi;
const u32 *ddi_translations;
if (IS_BROADWELL(dev)) {
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
ddi_translations_edp = bdw_ddi_translations_edp;
- n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
- hdmi_800mV_0dB = 6;
+ ddi_translations_hdmi = bdw_ddi_translations_hdmi;
+ n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 7;
} else if (IS_HASWELL(dev)) {
ddi_translations_fdi = hsw_ddi_translations_fdi;
ddi_translations_dp = hsw_ddi_translations_dp;
ddi_translations_edp = hsw_ddi_translations_dp;
+ ddi_translations_hdmi = hsw_ddi_translations_hdmi;
n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
hdmi_800mV_0dB = 6;
} else {
@@ -169,8 +186,9 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
ddi_translations_edp = bdw_ddi_translations_dp;
ddi_translations_fdi = bdw_ddi_translations_fdi;
ddi_translations_dp = bdw_ddi_translations_dp;
- n_hdmi_entries = ARRAY_SIZE(hsw_ddi_translations_hdmi);
- hdmi_800mV_0dB = 6;
+ ddi_translations_hdmi = bdw_ddi_translations_hdmi;
+ n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
+ hdmi_800mV_0dB = 7;
}
switch (port) {
@@ -207,7 +225,7 @@ static void intel_prepare_ddi_buffers(struct drm_device
*dev, enum port port)
/* Entry 9 is for HDMI: */
for (i = 0; i 2; i++) {
- I915_WRITE(reg, hsw_ddi_translations_hdmi[hdmi_level * 2 +
i]);
+ I915_WRITE(reg, ddi_translations_hdmi[hdmi_level * 2 + i]);
reg += 4;
}
}
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables
2014-08-01 7:07 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
We always write entries 0 to 8 from the DDI translation tables and then
entry 9 for HDMI/DVI with the help of the VBT. We then don't need the
failsafe HDMI entry in the DP/eDP/FDI tables.
And it seems we were not even using these values anyway...
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 67feea2..80526ab 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -82,7 +82,6 @@ static const u32 bdw_ddi_translations_edp[] = {
0x00BEEFFF, 0x000A000C,
0x00FF, 0x0005000F,
0x00DB6FFF, 0x000A000C,
- 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
static const u32 bdw_ddi_translations_dp[] = {
@@ -95,7 +94,6 @@ static const u32 bdw_ddi_translations_dp[] = {
0x80CB2FFF, 0x001B0002,
0x00F7DFFF, 0x00180004,
0x80D75FFF, 0x001B0002,
- 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
static const u32 bdw_ddi_translations_fdi[] = {
@@ -108,7 +106,6 @@ static const u32 bdw_ddi_translations_fdi[] = {
0x00C30FFF, 0x000C,
0x00FF, 0x00070006,
0x00D75FFF, 0x000C,
- 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
};
static const u32 bdw_ddi_translations_hdmi[] = {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Remove now useless comments about the translation values
2014-08-01 7:07 GMT-03:00 Damien Lespiau damien.lesp...@intel.com:
We used to carry a default HDMI value in entry 9, but this entry got
removed for both HSW and BDW.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 80526ab..ab5f65f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -33,7 +33,7 @@
* automatically adapt to HDMI connections as well
*/
static const u32 hsw_ddi_translations_dp[] = {
- 0x00FF, 0x0006000E, /* DP parameters */
+ 0x00FF, 0x0006000E,
0x00D75FFF, 0x0005000A,
0x00C30FFF, 0x00040006,
0x80AAAFFF, 0x000B,
@@ -45,7 +45,7 @@ static const u32 hsw_ddi_translations_dp[] = {
};
static const u32 hsw_ddi_translations_fdi[] = {
- 0x00FF, 0x0007000E, /* FDI parameters */
+ 0x00FF, 0x0007000E,
0x00D75FFF, 0x000F000A,
0x00C30FFF, 0x00060006,
0x00AAAFFF, 0x001E,
@@ -73,7 +73,7 @@ static const u32 hsw_ddi_translations_hdmi[] = {
};
static const u32 bdw_ddi_translations_edp[] = {
- 0x00FF, 0x0012, /* eDP parameters */
+ 0x00FF, 0x0012,
0x00EBAFFF, 0x00020011,
0x00C71FFF, 0x0006000F,
0x00AAAFFF, 0x000E000A,
@@ -85,7 +85,7 @@ static const u32 bdw_ddi_translations_edp[] = {
};
static const u32 bdw_ddi_translations_dp[] = {
- 0x00FF, 0x0007000E, /* DP parameters */
+ 0x00FF, 0x0007000E,
0x00D75FFF, 0x000E000A,
0x00BE, 0x00140006,
0x80B2CFFF, 0x001B0002,
@@ -97,7 +97,7 @@ static const u32 bdw_ddi_translations_dp[] = {
};
static const u32 bdw_ddi_translations_fdi[] = {
- 0x00FF, 0x0001000E, /* FDI parameters */
+ 0x00FF, 0x0001000E,
0x00D75FFF, 0x0004000A,
0x00C30FFF, 0x00070006,
0x00AAAFFF, 0x000C,
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 39/43] drm/i915/bdw: Print context state in debugfs
On Thu, Jul 24, 2014 at 05:04:47PM +0100, Thomas Daniel wrote:
From: Ben Widawsky b...@bwidawsk.net
This has turned out to be really handy in debug so far.
Update:
Since writing this patch, I've gotten similar code upstream for error
state. I've used it quite a bit in debugfs however, and I'd like to keep
it here at least until preemption is working.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
This patch was accidentally dropped in the first Execlists version, and
it has been very useful indeed. Put it back again, but as a standalone
debugfs file.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
It looks like the locking should be on struct_mutex and not
mode_config.mutex?
--
Damien
---
drivers/gpu/drm/i915/i915_debugfs.c | 52
+++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0980cdd..968c3c0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1695,6 +1695,57 @@ static int i915_context_status(struct seq_file *m,
void *unused)
return 0;
}
+static int i915_dump_lrc(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_engine_cs *ring;
+ struct intel_context *ctx;
+ int ret, i;
+
+ if (!i915.enable_execlists) {
+ seq_printf(m, Logical Ring Contexts are disabled\n);
+ return 0;
+ }
+
+ ret = mutex_lock_interruptible(dev-mode_config.mutex);
+ if (ret)
+ return ret;
+
+ list_for_each_entry(ctx, dev_priv-context_list, link) {
+ for_each_ring(ring, dev_priv, i) {
+ struct drm_i915_gem_object *ctx_obj =
ctx-engine[i].state;
+
+ if (ring-default_context == ctx)
+ continue;
+
+ if (ctx_obj) {
+ struct page *page =
i915_gem_object_get_page(ctx_obj, 1);
+ uint32_t *reg_state = kmap_atomic(page);
+ int j;
+
+ seq_printf(m, CONTEXT: %s %u\n, ring-name,
+
intel_execlists_ctx_id(ctx_obj));
+
+ for (j = 0; j 0x600 / sizeof(u32) / 4; j +=
4) {
+ seq_printf(m, \t[0x%08lx] 0x%08x
0x%08x 0x%08x 0x%08x\n,
+ i915_gem_obj_ggtt_offset(ctx_obj) +
4096 + (j * 4),
+ reg_state[j], reg_state[j + 1],
+ reg_state[j + 2], reg_state[j + 3]);
+ }
+ kunmap_atomic(reg_state);
+
+ seq_putc(m, '\n');
+ }
+ }
+ }
+
+ mutex_unlock(dev-mode_config.mutex);
+
+ return 0;
+}
+
static int i915_execlists(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -3992,6 +4043,7 @@ static const struct drm_info_list i915_debugfs_list[] =
{
{i915_opregion, i915_opregion, 0},
{i915_gem_framebuffer, i915_gem_framebuffer_info, 0},
{i915_context_status, i915_context_status, 0},
+ {i915_dump_lrc, i915_dump_lrc, 0},
{i915_execlists, i915_execlists, 0},
{i915_gen6_forcewake_count, i915_gen6_forcewake_count_info, 0},
{i915_swizzle_info, i915_swizzle_info, 0},
--
1.7.9.5
___
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
Re: [Intel-gfx] [PATCH] drm/i915: Android sync points for i915
On Fri, 01 Aug 2014 10:04:55 +0100
Tvrtko Ursulin tvrtko.ursu...@linux.intel.com wrote:
Hi Jesse,
On 07/31/2014 07:58 PM, Jesse Barnes wrote:
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow applications and libraries to create fences without an
associated buffer
2) re-use a common API so userspace doesn't have to impedance mismatch
between different driver implementations too much
3) allow applications and libraries to use explicit synchronization if
they choose by exposing fences directly
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
[snip]
+
+/*
+ * i915 fences on sync timelines
+ *
+ * We implement sync points in terms of i915 seqnos. They're exposed
+ * through the new DRM_I915_GEM_FENCE ioctl, and can be mixed and matched
+ * with other Android timelines and aggregated into sync_fences, etc.
+ *
+ * TODO:
+ * rebase on top of Chris's seqno/request stuff and use requests
+ * allow non-RCS fences (need ring/context association)
+ */
+
+struct i915_sync_timeline {
+ struct sync_timeline obj;
+ struct intel_engine_cs *ring;
+ struct drm_i915_private *dev_priv;
+};
+
+struct i915_sync_pt {
+ struct sync_pt pt;
+ u32 seqno;
+};
In case one day more than seqno needs to be exported to userspace,
perhaps it would be handy to version the driver data somehow to allow
for some forward/backward compatibility? Unless kernel/libdrm are
supposed to be updated in lock-step already.
This is the structure we expose to userspace:
struct drm_i915_gem_fence {
__s32 fd;
__u32 ctx_id;
__u32 flags;
__u32 pad;
char name[32];
};
It might be good to version it, but fundamentally we're talking about
fences on a given context's command stream, with an opaque fd, so this
seems sufficient, even if we did want to add additional seqnos in the
internals later on.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Introduce FBC False Color for debug purposes.
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this patch
introduces a persistent way to enable false color over debugfs.
v2: Use DEFINE_SIMPLE_ATTRIBUTE as Daniel suggested
v3: (Ville) only do false color for IVB+ since according to spec bit is
MBZ before IVB.
v4: We don't have FBC on valleyview nor on cherryview (Ben)
v5: s/!HAS_PCH_SPLIT/!HAS_FBC (Ville)
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +++
4 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..aea1a81 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1433,6 +1433,47 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_fbc_fc_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen 7 || !HAS_FBC(dev))
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+ *val = dev_priv-fbc.false_color;
+ drm_modeset_unlock_all(dev);
+
+ return 0;
+}
+
+static int i915_fbc_fc_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 reg;
+
+ if (INTEL_INFO(dev)-gen 7 || !HAS_FBC(dev))
+ return -ENODEV;
+
+ drm_modeset_lock_all(dev);
+
+ reg = I915_READ(ILK_DPFC_CONTROL);
+ dev_priv-fbc.false_color = val;
+
+ I915_WRITE(ILK_DPFC_CONTROL, val ?
+ (reg | FBC_CTL_FALSE_COLOR) :
+ (reg ~FBC_CTL_FALSE_COLOR));
+
+ drm_modeset_unlock_all(dev);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_fbc_fc_fops,
+ i915_fbc_fc_get, i915_fbc_fc_set,
+ %llu\n);
+
static int i915_ips_status(struct seq_file *m, void *unused)
{
struct drm_info_node *node = m-private;
@@ -3957,6 +3998,7 @@ static const struct i915_debugfs_files {
{i915_pri_wm_latency, i915_pri_wm_latency_fops},
{i915_spr_wm_latency, i915_spr_wm_latency_fops},
{i915_cur_wm_latency, i915_cur_wm_latency_fops},
+ {i915_fbc_false_color, i915_fbc_fc_fops},
};
void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..3a29f9e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -636,6 +636,8 @@ struct i915_fbc {
struct drm_mm_node compressed_fb;
struct drm_mm_node *compressed_llb;
+ bool false_color;
+
struct intel_fbc_work {
struct delayed_work work;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 28e21ed..b5d295a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1540,6 +1540,7 @@ enum punit_power_well {
/* Framebuffer compression for Ironlake */
#define ILK_DPFC_CB_BASE 0x43200
#define ILK_DPFC_CONTROL 0x43208
+#define FBC_CTL_FALSE_COLOR (110)
/* The bit 28-8 is reserved */
#define DPFC_RESERVED(0x1F00)
#define ILK_DPFC_RECOMP_CTL0x4320c
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1ddd4df..338a80b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -309,6 +309,9 @@ static void gen7_enable_fbc(struct drm_crtc *crtc)
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
+ if (dev_priv-fbc.false_color)
+ dpfc_ctl |= FBC_CTL_FALSE_COLOR;
+
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
if (IS_IVYBRIDGE(dev)) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/43] Execlists v5
On Thu, Jul 24, 2014 at 05:04:08PM +0100, Thomas Daniel wrote: All patches can have my r-b tag but patches 12, 34, 37, 39 which have minor comments (in terms of code changes) to address. I did look more at the low-level stuff (Vs the higher level abstractions). At this point, I believe the way forward is to merge that series to allow more people to beat on it. Step 1 is to make sure we don't regress the legacy ring buffers and now is a good time to land it as we start a new kernel cycle. Whether to enable it by default for BDW is an interesting question that may depend on the first round of QA. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Collect gtier properly on HSW.
GTIER and DEIER doesn't have same interface on HSW so this or operation
makes the information provided useless.
v2: since we have gtier variable already let's split for everybody
and avoid the strange | op.
Also avoid overriding the value that was set for vlv. In this case I
believe that we should reorganize the whole function, but I'll respect
the comment that ask to not touch the order and let this organization
work to be done later.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 24 ++--
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..60227b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,6 +317,7 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 gtier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..76c67dd 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,6 +359,8 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
+ err_printf(m, GTIER: 0x%08x\n, error-gtier);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1102,7 +1104,8 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-ier = I915_READ(GTIER) | I915_READ(VLV_IER);
+ error-gtier = I915_READ(GTIER);
+ error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1135,17 +1138,18 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
- error-ier = I915_READ(DEIER) | I915_READ(GTIER);
- else {
- if (IS_GEN2(dev))
- error-ier = I915_READ16(IER);
- else
- error-ier = I915_READ(IER);
+ if (HAS_PCH_SPLIT(dev)) {
+ error-ier = I915_READ(DEIER);
+ error-gtier = I915_READ(GTIER);
+ } else if (IS_GEN2(dev)) {
+ error-ier = I915_READ16(IER);
+ } else {
+ error-ier = I915_READ(IER);
}
- /* 4: Everything else */
- error-eir = I915_READ(EIR);
+ /* do not override what was set above for VLV */
+ if (!IS_VALLEYVIEW(dev))
+ error-eir = I915_READ(EIR);
error-pgtbl_er = I915_READ(PGTBL_ER);
i915_get_extra_instdone(dev, error-extra_instdone);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Fix DEIER and GTIER collecting for BDW.
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
v2: Fix small issues of first version and don't read DEIER regs when pipe's
power well is disabled
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 29 +
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..b3493d3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -703,6 +703,10 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
}
for_each_pipe(pipe) {
+ if (!intel_display_power_enabled(dev_priv,
+
POWER_DOMAIN_PIPE(pipe)))
+ continue;
+
seq_printf(m, Pipe %c IMR:\t%08x\n,
pipe_name(pipe),
I915_READ(GEN8_DE_PIPE_IMR(pipe)));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60227b2..d1ae952 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,7 +317,9 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
+ u32 deier[3];
+ u32 de_misc_ier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 76c67dd..088b535 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,8 +359,19 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ err_printf(m, DEIER pipe %c: 0x%08x\n, pipe_name(i),
+ error-deier[i]);
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+ error-gtier[i]);
+ err_printf(m, DE_MISC_IER: 0x%08x\n, error-de_misc_ier);
+ } else {
+ err_printf(m, IER: 0x%08x\n, error-ier);
+ }
if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1093,6 +1104,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i;
/* General organization
* 1. Registers specific to a single generation
@@ -1104,7 +1116,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1138,9 +1150,18 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev)) {
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ if (intel_display_power_enabled(dev_priv,
+ POWER_DOMAIN_PIPE(i)))
+ error-deier[i] =
+ I915_READ(GEN8_DE_PIPE_IER(i));
+ for (i = 0; i 4; i++)
+ error-gtier[i] = I915_READ(GEN8_GT_IER(i));
+ error-de_misc_ier = I915_READ(GEN8_DE_MISC_IER);
+ } else if (HAS_PCH_SPLIT(dev)) {
error-ier = I915_READ(DEIER);
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
} else if (IS_GEN2(dev)) {
error-ier = I915_READ16(IER);
} else {
--
1.9.1
Re: [Intel-gfx] [PATCH 00/43] Execlists v5
On Fri, 1 Aug 2014 17:09:50 +0100 Damien Lespiau damien.lesp...@intel.com wrote: On Thu, Jul 24, 2014 at 05:04:08PM +0100, Thomas Daniel wrote: All patches can have my r-b tag but patches 12, 34, 37, 39 which have minor comments (in terms of code changes) to address. I did look more at the low-level stuff (Vs the higher level abstractions). At this point, I believe the way forward is to merge that series to allow more people to beat on it. Step 1 is to make sure we don't regress the legacy ring buffers and now is a good time to land it as we start a new kernel cycle. Whether to enable it by default for BDW is an interesting question that may depend on the first round of QA. Yeah I think we want to enable it on BDW too after getting some testing and sanity checking. The legacy ring buffers aren't getting much testing elsewhere and I'm afraid we'll run into issues that don't exist with the execlist path if we stick with the legacy submission path (we may have already hit one in fact). -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip Stolen Memory first page.
On Thu, 31 Jul 2014 12:08:20 -0700
Rodrigo Vivi rodrigo.v...@intel.com wrote:
WA to skip the first page of stolen memory due to sporadic HW write on *CS
Idle
v2: Improve variable names and fix allocated size.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 21c025a..82035b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -289,7 +289,8 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
int i915_gem_init_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int bios_reserved = 0;
+ int start_rsvd = 0;
+ int end_rsvd = 0;
#ifdef CONFIG_INTEL_IOMMU
if (intel_iommu_gfx_mapped INTEL_INFO(dev)-gen 8) {
@@ -308,15 +309,19 @@ int i915_gem_init_stolen(struct drm_device *dev)
DRM_DEBUG_KMS(found %zd bytes of stolen memory at %08lx\n,
dev_priv-gtt.stolen_size, dev_priv-mm.stolen_base);
+ /* WaSkipStolenMemoryFirstPage */
+ if (INTEL_INFO(dev)-gen = 8)
+ start_rsvd = 4096;
+
if (IS_VALLEYVIEW(dev))
- bios_reserved = 1024*1024; /* top 1M on VLV/BYT */
+ end_rsvd = 1024*1024; /* top 1M on VLV/BYT */
- if (WARN_ON(bios_reserved dev_priv-gtt.stolen_size))
+ if (WARN_ON((start_rsvd + end_rsvd) dev_priv-gtt.stolen_size))
return 0;
/* Basic memrange allocator for stolen space */
- drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_size -
- bios_reserved);
+ drm_mm_init(dev_priv-mm.stolen, start_rsvd,
+ dev_priv-gtt.stolen_size - start_rsvd - end_rsvd);
return 0;
}
Beyond the fastboot stuff Ville has already mentioned, the early
allocation of the existing fb from stolen will prevent us from
clobbering the currently displayed buffer with the contents of the
ringbuffers and whatever else we allocate out of stolen at early boot.
We might be able to avoid that by doing stolen allocations top down, or
by reserving the displayed fb even if we can't allocate an obj for it,
only freeing it after our first mode set.
Can you file a bug or JIRA for that to make sure we don't lose track of
the fastboot boot corruption issues after this fix lands?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGT 1/2] intel_bios_reader: Add support to dump MIPI Configuration Block #52
Hi,
I've pushed these two patches to i-g-t, they definitely are an
improvement and look good to me.
Thanks!
--
Damien
On Wed, Jul 16, 2014 at 07:39:32PM +0530, Gaurav K Singh wrote:
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
---
tools/intel_bios.h| 132
+
tools/intel_bios_reader.c | 94
2 files changed, 226 insertions(+)
diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index 832c580..752379a 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -85,6 +85,8 @@ struct bdb_header {
#define BDB_LVDS_LFP_DATA 42
#define BDB_LVDS_BACKLIGHT43
#define BDB_LVDS_POWER44
+#define BDB_MIPI_CONFIG 52
+#define BDB_MIPI_SEQUENCE 53
#define BDB_SKIP 254 /* VBIOS private block, ignore */
struct bdb_general_features {
@@ -597,6 +599,136 @@ struct bdb_edp {
uint16_t edp_t3_optimization;
} __attribute__ ((packed));
+
+/* Block 52 contains MiPi Panel info
+ * 6 such enteries will there. Index into correct
+ * entery is based on the panel_index in #40 LFP
+ */
+#define MAX_MIPI_CONFIGURATIONS6
+struct mipi_config {
+ uint16_t panel_id;
+
+ /* General Params */
+ uint32_t dithering:1;
+ uint32_t rsvd1:1;
+ uint32_t panel_type:1;
+ uint32_t panel_arch_type:2;
+ uint32_t cmd_mode:1;
+ uint32_t vtm:2;
+ uint32_t cabc:1;
+ uint32_t pwm_blc:1;
+
+ /* Bit 13:10
+ * 000 - Reserved, 001 - RGB565, 002 - RGB666,
+ * 011 - RGB666Loosely packed, 100 - RGB888,
+ * others - rsvd
+ */
+ uint32_t videomode_color_format:4;
+
+ /* Bit 15:14
+ * 0 - No rotation, 1 - 90 degree
+ * 2 - 180 degree, 3 - 270 degree
+ */
+ uint32_t rotation:2;
+ uint32_t bta:1;
+ uint32_t rsvd2:15;
+
+ /* 2 byte Port Description */
+ uint16_t dual_link:2;
+ uint16_t lane_cnt:2;
+ uint16_t rsvd3:12;
+
+ /* 2 byte DSI COntroller params */
+ /* 0 - Using DSI PHY, 1 - TE usage */
+ uint16_t dsi_usage:1;
+ uint16_t rsvd4:15;
+
+ uint8_t rsvd5[5];
+ uint32_t dsi_ddr_clk;
+ uint32_t bridge_ref_clk;
+
+ uint8_t byte_clk_sel:2;
+ uint8_t rsvd6:6;
+
+ /* DPHY Flags */
+ uint16_t dphy_param_valid:1;
+ uint16_t eot_disabled:1;
+ uint16_t clk_stop:1;
+ uint16_t rsvd7:13;
+
+ uint32_t hs_tx_timeout;
+ uint32_t lp_rx_timeout;
+ uint32_t turn_around_timeout;
+ uint32_t device_reset_timer;
+ uint32_t master_init_timer;
+ uint32_t dbi_bw_timer;
+ uint32_t lp_byte_clk_val;
+
+ /* 4 byte Dphy Params */
+ uint32_t prepare_cnt:6;
+ uint32_t rsvd8:2;
+ uint32_t clk_zero_cnt:8;
+ uint32_t trail_cnt:5;
+ uint32_t rsvd9:3;
+ uint32_t exit_zero_cnt:6;
+ uint32_t rsvd10:2;
+
+ uint32_t clk_lane_switch_cnt;
+ uint32_t hl_switch_cnt;
+
+ uint32_t rsvd11[6];
+
+ /* timings based on dphy spec */
+ uint8_t tclk_miss;
+ uint8_t tclk_post;
+ uint8_t rsvd12;
+ uint8_t tclk_pre;
+ uint8_t tclk_prepare;
+ uint8_t tclk_settle;
+ uint8_t tclk_term_enable;
+ uint8_t tclk_trail;
+ uint16_t tclk_prepare_clkzero;
+ uint8_t rsvd13;
+ uint8_t td_term_enable;
+ uint8_t teot;
+ uint8_t ths_exit;
+ uint8_t ths_prepare;
+ uint16_t ths_prepare_hszero;
+ uint8_t rsvd14;
+ uint8_t ths_settle;
+ uint8_t ths_skip;
+ uint8_t ths_trail;
+ uint8_t tinit;
+ uint8_t tlpx;
+ uint8_t rsvd15[3];
+
+ /* GPIOs */
+ uint8_t panel_enable;
+ uint8_t bl_enable;
+ uint8_t pwm_enable;
+ uint8_t reset_r_n;
+ uint8_t pwr_down_r;
+ uint8_t stdby_r_n;
+
+} __attribute__ ((packed));
+
+/* Block 52 contains MiPi configuration block
+ * 6 * bdb_mipi_config, followed by 6 pps data
+ * block below
+ */
+struct mipi_pps_data {
+ uint16_t panel_on_delay;
+ uint16_t bl_enable_delay;
+ uint16_t bl_disable_delay;
+ uint16_t panel_off_delay;
+ uint16_t panel_power_cycle_delay;
+} __attribute__ ((packed));
+
+struct bdb_mipi_config {
+ struct mipi_config config[MAX_MIPI_CONFIGURATIONS];
+ struct mipi_pps_data pps[MAX_MIPI_CONFIGURATIONS];
+} __attribute__ ((packed));
+
/*
* Driver-VBIOS interaction occurs through scratch bits in
* GR18 SWF*.
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 173772b..9f82481 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -696,6 +696,94 @@ static void dump_sdvo_lvds_options(const struct
bdb_block *block)
printf(\tmisc[3]: %x\n, options-panel_misc_bits_4);
}
+static void dump_mipi_config(const struct bdb_block *block)
+{
+ struct bdb_mipi_config *start = block-data;
+ struct mipi_config *config;
+
[Intel-gfx] [PATCH] tests: Add drv_workarounds
To check that static workarounds are set and stay after init,
hang and suspend/restore. Checks are currently provided for ivb
and bdw only.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
lib/intel_chipset.h |4 +
lib/intel_workaround.h | 142 +++
tests/Makefile.sources |1 +
tests/drv_workarounds.c | 244 +++
4 files changed, 391 insertions(+)
create mode 100644 lib/intel_workaround.h
create mode 100644 tests/drv_workarounds.c
diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 404c632..5a03f2b 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -263,6 +263,10 @@ void intel_check_pch(void);
(devid) == PCI_CHIP_IVYBRIDGE_S || \
(devid) == PCI_CHIP_IVYBRIDGE_S_GT2)
+#define IS_IVB_GT1(devid) ((devid) == PCI_CHIP_IVYBRIDGE_GT1 || \
+(devid) == PCI_CHIP_IVYBRIDGE_M_GT1 || \
+(devid) == PCI_CHIP_IVYBRIDGE_S)
+
#define IS_VALLEYVIEW(devid) ((devid) == PCI_CHIP_VALLEYVIEW_PO || \
(devid) == PCI_CHIP_VALLEYVIEW_1 || \
(devid) == PCI_CHIP_VALLEYVIEW_2 || \
diff --git a/lib/intel_workaround.h b/lib/intel_workaround.h
new file mode 100644
index 000..87e3a44
--- /dev/null
+++ b/lib/intel_workaround.h
@@ -0,0 +1,142 @@
+/*
+ * Copyright © 2013,2014 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:
+ *Mika Kuoppala mika.kuopp...@intel.com
+ *
+ */
+
+#ifndef INTEL_WORKAROUNDS
+#define INTEL_WORKAROUNDS
+
+#include intel_chipset.h
+#include intel_io.h
+#include igt_core.h
+
+static int __wa_devid = 0;
+
+struct wa {
+ const char * const name;
+ int (*f)(const int devid);
+};
+
+static void wa_init(const int devid)
+{
+ __wa_devid = devid;
+ intel_register_access_init(intel_get_pci_device(), 0);
+}
+
+static void wa_fini(void)
+{
+ __wa_devid = 0;
+ intel_register_access_fini();
+}
+
+static int wa_check(const struct wa *wa)
+{
+ igt_assert(__wa_devid);
+ igt_assert(wa-name);
+ igt_assert(wa-f);
+ return wa-f(__wa_devid);
+}
+
+#define WA(_name) /* _name */ static int _name##_fun(const int devid); \
+ static const struct wa _name = \
+ { #_name, _name##_fun };\
+ static int _name##_fun(const int devid)
+
+#define wa_assert_m(reg, val, mask) { \
+ unsigned int x; \
+ igt_assert(mask); \
+ x = intel_register_read(reg); \
+ if (((x) (mask)) != (val)) { \
+ igt_warn(a:0x%08x r:0x%08x m:0%08x v:0%08x\n, reg, x,
mask, val); \
+ return 1; \
+ } \
+ }
+
+#define wa_assert(reg, val) wa_assert_m(reg, val, 0x)
+#define wa_assert_bit_set(reg, bit) wa_assert_m(reg, (1 bit), (1 bit))
+#define wa_assert_bit_clr(reg, bit) wa_assert_m(reg, 0, (1 bit))
+
+#define WA_MASK(_name, reg, val, mask) \
+ WA(_name) { \
+ wa_assert_m(reg, val, mask);\
+ return 0; \
+ }
+
+#define WA_BIT_SET(_name, reg, bit) WA_MASK(_name, reg, (1 bit), (1 bit))
+#define WA_BIT_CLR(_name, reg, bit) WA_MASK(_name, reg, 0, (1 bit))
+
+
+/* *** ivb workarounds ***/
+WA(WaDisablePSDDualDispatchEnable) {
+ if (IS_IVB_GT1(devid))
+
[Intel-gfx] [PATCH] igt: Add drv_workarounds
Hi, With ivb we currently drop 5 out of 11 static workarounds due to hang/reset recovery. With bdw we see that some workarounds wont stick even after init, due to rc6 entry dropping some regs that are not part of power context? Mika Kuoppala (1): tests: Add drv_workarounds lib/intel_chipset.h |4 + lib/intel_workaround.h | 142 +++ tests/Makefile.sources |1 + tests/drv_workarounds.c | 244 +++ 4 files changed, 391 insertions(+) create mode 100644 lib/intel_workaround.h create mode 100644 tests/drv_workarounds.c -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Collect gtier properly on HSW.
2014-08-01 6:13 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
GTIER and DEIER doesn't have same interface on HSW so this or operation
makes the information provided useless.
v2: since we have gtier variable already let's split for everybody
and avoid the strange | op.
Also avoid overriding the value that was set for vlv. In this case I
believe that we should reorganize the whole function, but I'll respect
the comment that ask to not touch the order and let this organization
work to be done later.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 24 ++--
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..60227b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,6 +317,7 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 gtier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..76c67dd 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,6 +359,8 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
+ err_printf(m, GTIER: 0x%08x\n, error-gtier);
Optional bikeshed: you could just check for Gen = 5 here.
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1102,7 +1104,8 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-ier = I915_READ(GTIER) | I915_READ(VLV_IER);
+ error-gtier = I915_READ(GTIER);
+ error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1135,17 +1138,18 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
- error-ier = I915_READ(DEIER) | I915_READ(GTIER);
- else {
- if (IS_GEN2(dev))
- error-ier = I915_READ16(IER);
- else
- error-ier = I915_READ(IER);
+ if (HAS_PCH_SPLIT(dev)) {
+ error-ier = I915_READ(DEIER);
+ error-gtier = I915_READ(GTIER);
+ } else if (IS_GEN2(dev)) {
+ error-ier = I915_READ16(IER);
+ } else {
+ error-ier = I915_READ(IER);
We're still overwriting VLV's IER here.
}
- /* 4: Everything else */
- error-eir = I915_READ(EIR);
+ /* do not override what was set above for VLV */
+ if (!IS_VALLEYVIEW(dev))
+ error-eir = I915_READ(EIR);
I don't see EIR being set above on VLV. It was IER, not EIR.
error-pgtbl_er = I915_READ(PGTBL_ER);
i915_get_extra_instdone(dev, error-extra_instdone);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
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: Fix DEIER and GTIER collecting for BDW.
2014-08-01 6:14 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also listing
old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
v2: Fix small issues of first version and don't read DEIER regs when pipe's
power well is disabled
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 29 +
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..b3493d3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -703,6 +703,10 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
}
for_each_pipe(pipe) {
+ if (!intel_display_power_enabled(dev_priv,
+
POWER_DOMAIN_PIPE(pipe)))
+ continue;
Bikeshed: print something here (e.g., Pipe %c: power disabled\n).
+
seq_printf(m, Pipe %c IMR:\t%08x\n,
pipe_name(pipe),
I915_READ(GEN8_DE_PIPE_IMR(pipe)));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60227b2..d1ae952 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,7 +317,9 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
+ u32 deier[3];
+ u32 de_misc_ier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 76c67dd..088b535 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,8 +359,19 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ err_printf(m, DEIER pipe %c: 0x%08x\n, pipe_name(i),
+ error-deier[i]);
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+ error-gtier[i]);
+ err_printf(m, DE_MISC_IER: 0x%08x\n, error-de_misc_ier);
+ } else {
+ err_printf(m, IER: 0x%08x\n, error-ier);
+ }
if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1093,6 +1104,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i;
Bikeshed: also add enum pipe pipe and use it for the pipe iteration.
With or without these changes: Reviewed-by: Paulo Zanoni
paulo.r.zan...@intel.com
/* General organization
* 1. Registers specific to a single generation
@@ -1104,7 +1116,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1138,9 +1150,18 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev)) {
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(i)
+ if (intel_display_power_enabled(dev_priv,
+ POWER_DOMAIN_PIPE(i)))
+ error-deier[i] =
+ I915_READ(GEN8_DE_PIPE_IER(i));
+ for (i = 0; i 4; i++)
+ error-gtier[i] =
[Intel-gfx] [PATCH 3/5] lib/gen6_render: fix GEN6_3DSTATE_VF_STATISTICS define
We dont use this pre CTG and we will need it for gen8 golden state. Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com --- lib/gen6_render.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gen6_render.h b/lib/gen6_render.h index dfee6e7..c3e85eb 100644 --- a/lib/gen6_render.h +++ b/lib/gen6_render.h @@ -24,7 +24,7 @@ #define GEN6_3DSTATE_VERTEX_BUFFERSGEN6_3D(3, 0, 8) #define GEN6_3DSTATE_VERTEX_ELEMENTS GEN6_3D(3, 0, 9) #define GEN6_3DSTATE_INDEX_BUFFER GEN6_3D(3, 0, 0xa) -#define GEN6_3DSTATE_VF_STATISTICS GEN6_3D(3, 0, 0xb) +#define GEN6_3DSTATE_VF_STATISTICS GEN6_3D(1, 0, 0xb) #define GEN6_3DSTATE_DRAWING_RECTANGLE GEN6_3D(3, 1, 0) #define GEN6_3DSTATE_CONSTANT_COLORGEN6_3D(3, 1, 1) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] tools/null_state_gen: build cmd and state space separately
Instead of building batch directly to memory, build into cmd and
state arrays. This representation allows us more flexibility in batch
state expression and batch generation/relocation.
As a bonus, we can also attach the line information that produced the
batch data to help debugging.
There is no change in the output states produced. This can be considered
as a preparatory patch to help introduce gen8 golden state.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tools/null_state_gen/intel_batchbuffer.c | 251 +
tools/null_state_gen/intel_batchbuffer.h | 86 +
tools/null_state_gen/intel_null_state_gen.c | 100 +++---
tools/null_state_gen/intel_renderstate_gen6.c | 136 ++
tools/null_state_gen/intel_renderstate_gen7.c | 126 -
tools/null_state_gen/intel_renderstate_gen8.c | 167 ++--
6 files changed, 404 insertions(+), 462 deletions(-)
diff --git a/tools/null_state_gen/intel_batchbuffer.c
b/tools/null_state_gen/intel_batchbuffer.c
index 62e052a..2a0b340 100644
--- a/tools/null_state_gen/intel_batchbuffer.c
+++ b/tools/null_state_gen/intel_batchbuffer.c
@@ -29,145 +29,248 @@
**/
#include stdio.h
+#include stdlib.h
#include string.h
#include errno.h
+#include assert.h
#include intel_batchbuffer.h
-int intel_batch_reset(struct intel_batchbuffer *batch,
- void *p,
- uint32_t size,
- uint32_t off)
+void bb_area_emit(struct bb_area *a, uint32_t dword, item_type type, const
char *str)
{
- batch-err = -EINVAL;
- batch-base = batch-base_ptr = p;
- batch-state_base = batch-state_ptr = p;
+ struct bb_item *item;
+ assert(a != NULL);
+ assert(a-num_items MAX_ITEMS);
+ item = a-item[a-num_items];
- if (off = size || ALIGN(off, 4) != off)
- return -EINVAL;
+ item-data = dword;
+ item-type = type;
+ strncpy(item-str, str, MAX_STRLEN);
+ item-str[MAX_STRLEN - 1] = 0;
- batch-size = size;
+ a-num_items++;
+}
- batch-state_base = batch-state_ptr = batch-base[off];
+void bb_area_emit_offset(struct bb_area *a, unsigned offset, uint32_t dword,
item_type type, const char *str)
+{
+ const unsigned i = offset / 4;
+ struct bb_item *item;
+ assert(a != NULL);
+ assert(a-num_items MAX_ITEMS);
+ assert(i a-num_items);
+ item = a-item[i];
+
+ item-data = dword;
+ item-type = type;
+ strncpy(item-str, str, MAX_STRLEN);
+ item-str[MAX_STRLEN - 1] = 0;
+}
- batch-num_relocs = 0;
- batch-err = 0;
+static struct bb_item *bb_area_get(struct bb_area *a, unsigned i)
+{
+ assert (i a-num_items);
+ return a-item[i];
+}
- return batch-err;
+static unsigned bb_area_items(struct bb_area *a)
+{
+ return a-num_items;
}
-uint32_t intel_batch_state_used(struct intel_batchbuffer *batch)
+static unsigned long bb_area_used(struct bb_area *a)
{
- return batch-state_ptr - batch-state_base;
+ assert(a != NULL);
+ assert(a-num_items = MAX_ITEMS);
+
+ return a-num_items * 4;
}
-uint32_t intel_batch_state_offset(struct intel_batchbuffer *batch)
+static unsigned long bb_area_room(struct bb_area *a)
{
- return batch-state_ptr - batch-base;
+ assert (a != NULL);
+ assert (a-num_items = MAX_ITEMS);
+
+ return (MAX_ITEMS - a-num_items) * 4;
}
-void *intel_batch_state_alloc(struct intel_batchbuffer *batch,
- uint32_t size,
- uint32_t align)
+struct intel_batchbuffer *intel_batchbuffer_create(void)
{
- uint32_t cur;
- uint32_t offset;
+ struct intel_batchbuffer *batch;
- if (batch-err)
+ batch = calloc(1, sizeof(*batch));
+ if (batch == NULL)
return NULL;
- cur = intel_batch_state_offset(batch);
- offset = ALIGN(cur, align);
+ batch-cmds = calloc(1, sizeof(struct bb_area));
+ if (batch-cmds == NULL) {
+ free(batch);
+ return NULL;
+ }
- if (offset + size batch-size) {
- batch-err = -ENOSPC;
+ batch-state = calloc(1, sizeof(struct bb_area));
+ if (batch-state == NULL) {
+ free(batch-cmds);
+ free(batch);
return NULL;
}
- batch-state_ptr = batch-base + offset + size;
+ batch-state_start_offset = -1;
+ batch-cmds_end_offset = -1;
- memset(batch-base + cur, 0, size);
+ return batch;
+}
- return batch-base + offset;
+static void bb_area_align(struct bb_area *a, unsigned align)
+{
+ if (align == 0)
+ return;
+
+ assert((align % 4) == 0);
+
+ while ((a-num_items * 4) % align != 0)
+ bb_area_emit(a, 0, PAD, align pad);
[Intel-gfx] [PATCH 1/5] tools/null_state_gen: terminate relocs with -1
as this was already changed in kernel.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tools/null_state_gen/intel_null_state_gen.c |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/null_state_gen/intel_null_state_gen.c
b/tools/null_state_gen/intel_null_state_gen.c
index 14f45d3..945926f 100644
--- a/tools/null_state_gen/intel_null_state_gen.c
+++ b/tools/null_state_gen/intel_null_state_gen.c
@@ -39,6 +39,7 @@ static int print_state(int gen, struct intel_batchbuffer
*batch)
for (i = 0; i batch-num_relocs; i++) {
printf(\t0x%08x,\n, batch-relocs[i]);
}
+ printf(\t%d,\n, -1);
printf(};\n\n);
printf(static const u32 gen%d_null_state_batch[] = {\n, gen);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] lib: Add MI_LOAD_REGISTER_IMM
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
lib/intel_reg.h |1 +
tests/gem_exec_parse.c |1 -
tests/gem_non_secure_batch.c |4 +---
tests/gen7_forcewake_mt.c|5 ++---
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 56459ea..f0fc5fd 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2545,6 +2545,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define MI_WAIT_FOR_PIPEA_SCAN_LINE_WINDOW (11)
#define MI_LOAD_SCAN_LINES_INCL(0x1223)
+#define MI_LOAD_REGISTER_IMM ((0x22 23) | 1)
/* Flush */
#define MI_FLUSH (0x0423)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 5bab4db..05f271c 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -187,7 +187,6 @@ int fd;
#define MI_ARB_ON_OFF (0x8 23)
#define MI_DISPLAY_FLIP ((0x14 23) | 1)
-#define MI_LOAD_REGISTER_IMM ((0x22 23) | 1)
#define GFX_OP_PIPE_CONTROL((0x329)|(0x327)|(0x224)|2)
#define PIPE_CONTROL_QW_WRITE(114)
diff --git a/tests/gem_non_secure_batch.c b/tests/gem_non_secure_batch.c
index 01101e9..fa59392 100644
--- a/tests/gem_non_secure_batch.c
+++ b/tests/gem_non_secure_batch.c
@@ -52,8 +52,6 @@ struct intel_batchbuffer *batch;
* should fail if the non-secure handling works correctly.
*/
-#define MI_LOAD_REGISTER_IMM (0x2223)
-
static int num_rings = 1;
static void
@@ -67,7 +65,7 @@ mi_lri_loop(void)
int ring = random() % num_rings + 1;
BEGIN_BATCH(4);
- OUT_BATCH(MI_LOAD_REGISTER_IMM | 1);
+ OUT_BATCH(MI_LOAD_REGISTER_IMM);
OUT_BATCH(0x203c); /* RENDER RING CTL */
OUT_BATCH(0); /* try to stop the ring */
OUT_BATCH(MI_NOOP);
diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 0ea7d09..e974807 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -120,7 +120,6 @@ static void *thread(void *arg)
return NULL;
}
-#define MI_LOAD_REGISTER_IMM(0x2223)
#define MI_STORE_REGISTER_MEM (0x2423)
igt_simple_main
@@ -145,13 +144,13 @@ igt_simple_main
struct drm_i915_gem_exec_object2 exec[2];
struct drm_i915_gem_relocation_entry reloc[2];
uint32_t b[] = {
- MI_LOAD_REGISTER_IMM | 1,
+ MI_LOAD_REGISTER_IMM,
FORCEWAKE_MT,
2 16 | 2,
MI_STORE_REGISTER_MEM | 1,
FORCEWAKE_MT,
0, // to be patched
- MI_LOAD_REGISTER_IMM | 1,
+ MI_LOAD_REGISTER_IMM,
FORCEWAKE_MT,
2 16,
MI_STORE_REGISTER_MEM | 1,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] lib/rendercopy: fix a typo in define
No functional changes
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
lib/gen6_render.h |2 +-
lib/rendercopy_gen8.c |2 +-
tools/null_state_gen/intel_renderstate_gen8.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/gen6_render.h b/lib/gen6_render.h
index 58d511f..dfee6e7 100644
--- a/lib/gen6_render.h
+++ b/lib/gen6_render.h
@@ -360,7 +360,7 @@
#define GEN6_3DSTATE_WMGEN6_3D(3, 0, 0x14)
/* DW2 */
-# define GEN6_3DSTATE_WM_SAMPLER_COUNT_SHITF 27
+# define GEN6_3DSTATE_WM_SAMPLER_COUNT_SHIFT 27
# define GEN6_3DSTATE_WM_BINDING_TABLE_ENTRY_COUNT_SHIFT 18
/* DW4 */
# define GEN6_3DSTATE_WM_DISPATCH_START_GRF_0_SHIFT16
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index ff0b0c8..ca6276b 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -794,7 +794,7 @@ gen8_emit_ps(struct intel_batchbuffer *batch, uint32_t
kernel) {
OUT_BATCH(GEN7_3DSTATE_PS | (12-2));
OUT_BATCH(kernel);
OUT_BATCH(0); /* kernel hi */
- OUT_BATCH(1 GEN6_3DSTATE_WM_SAMPLER_COUNT_SHITF |
+ OUT_BATCH(1 GEN6_3DSTATE_WM_SAMPLER_COUNT_SHIFT |
2 GEN6_3DSTATE_WM_BINDING_TABLE_ENTRY_COUNT_SHIFT);
OUT_BATCH(0); /* scratch space stuff */
OUT_BATCH(0); /* scratch hi */
diff --git a/tools/null_state_gen/intel_renderstate_gen8.c
b/tools/null_state_gen/intel_renderstate_gen8.c
index 437454e..807c2c8 100644
--- a/tools/null_state_gen/intel_renderstate_gen8.c
+++ b/tools/null_state_gen/intel_renderstate_gen8.c
@@ -598,7 +598,7 @@ gen8_emit_ps(struct intel_batchbuffer *batch, uint32_t
kernel) {
OUT_BATCH(GEN7_3DSTATE_PS | (12-2));
OUT_BATCH(kernel);
OUT_BATCH(0); /* kernel hi */
- OUT_BATCH(1 GEN6_3DSTATE_WM_SAMPLER_COUNT_SHITF |
+ OUT_BATCH(1 GEN6_3DSTATE_WM_SAMPLER_COUNT_SHIFT |
2 GEN6_3DSTATE_WM_BINDING_TABLE_ENTRY_COUNT_SHIFT);
OUT_BATCH(0); /* scratch space stuff */
OUT_BATCH(0); /* scratch hi */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: grab struct_mutex at intel_edp_psr_enable()
From: Paulo Zanoni paulo.r.zan...@intel.com
Otherwise we will hit lockdep_assert_held(dev-struct_mutex)
from intel_edp_psr_match_conditions(). This happens all the time on my
BDW machine: just boot it and you'll get it.
In this patch I just grab struct_mutex in the deepest possible place
(around psr.lock, otherwise lockdep complains).
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 87d0489..a91142c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1876,11 +1876,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
return;
}
+ mutex_lock(dev-struct_mutex);
mutex_lock(dev_priv-psr.lock);
if (dev_priv-psr.enabled) {
DRM_DEBUG_KMS(PSR already in use\n);
- mutex_unlock(dev_priv-psr.lock);
- return;
+ goto out;
}
dev_priv-psr.busy_frontbuffer_bits = 0;
@@ -1890,7 +1890,10 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
if (intel_edp_psr_match_conditions(intel_dp))
dev_priv-psr.enabled = intel_dp;
+
+out:
mutex_unlock(dev_priv-psr.lock);
+ mutex_unlock(dev-struct_mutex);
}
void intel_edp_psr_disable(struct intel_dp *intel_dp)
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix error state collecting
Fix signal_offset when recording semaphore state on BDW. Reviewed-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 0b3f694..0ea6a6b 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -784,7 +784,8 @@ static void gen8_record_semaphore_state(struct drm_i915_private *dev_priv, if (ring == to) continue; - signal_offset = (GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4; + signal_offset = (GEN8_SIGNAL_OFFSET(ring, i) (PAGE_SIZE - 1)) + / 4; tmp = error-semaphore_obj-pages[0]; idx = intel_ring_sync_index(ring, to); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove duplicate register defines
From: Paulo Zanoni paulo.r.zan...@intel.com
cat i915_reg.h | sort | uniq -d | grep define
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 28e21ed..c45b679 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3755,7 +3755,6 @@ enum punit_power_well {
#define PIPE_VSYNC_INTERRUPT_STATUS (1UL9)
#define PIPE_DISPLAY_LINE_COMPARE_STATUS (1UL8)
#define PIPE_DPST_EVENT_STATUS (1UL7)
-#define PIPE_LEGACY_BLC_EVENT_STATUS (1UL6)
#define PIPE_A_PSR_STATUS_VLV(1UL6)
#define PIPE_LEGACY_BLC_EVENT_STATUS (1UL6)
#define PIPE_ODD_FIELD_INTERRUPT_STATUS (1UL5)
@@ -5430,7 +5429,6 @@ enum punit_power_well {
#define VLV_GTLC_ALLOWWAKEERR(1 1)
#define VLV_GTLC_PW_MEDIA_STATUS_MASK(1 5)
#define VLV_GTLC_PW_RENDER_STATUS_MASK (1 7)
-#define VLV_GTLC_SURVIVABILITY_REG 0x130098
#define FORCEWAKE_MT 0xa188 /* multi-threaded */
#define FORCEWAKE_KERNEL 0x1
#define FORCEWAKE_USER 0x2
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: only hook up hpd pulse for DP setups.
From: Dave Airlie airl...@redhat.com
On HSW/BDW the VBT can tell us if we need to have DP support for a port,
if we don't have DP this caused an oops in the hpd handling.
Don't hook up the DP hpd handling if we don't have a DP port.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856
Reported-by: Intel QA Team.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_ddi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9b1542f..42d4dce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1557,11 +1557,13 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
intel_encoder-cloneable = 0;
intel_encoder-hot_plug = intel_ddi_hot_plug;
- intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
- dev_priv-hpd_irq_port[port] = intel_dig_port;
+ if (init_dp) {
+ /* only hook up hpd processing for DP */
+ intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
+ dev_priv-hpd_irq_port[port] = intel_dig_port;
- if (init_dp)
dp_connector = intel_ddi_init_dp_connector(intel_dig_port);
+ }
/* In theory we don't need the encoder-type check, but leave it just in
* case we have some really bad VBTs... */
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix i915_frequency_info on BDW
From: Paulo Zanoni paulo.r.zan...@intel.com
The GEN6_PM* registers don't exist on BDW anymore, so when we read
this file we trigger unclaimed register errors. The equivalent BDW
register for PMs is GEN8_GT_I*R(2), so use it.
Testcase: igt/pm_rpm/debugfs-read
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..17bd20ff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1024,6 +1024,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
u32 rpstat, cagf, reqf;
u32 rpupei, rpcurup, rpprevup;
u32 rpdownei, rpcurdown, rpprevdown;
+ u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
int max_freq;
/* RPSTAT1 is in the GT power well */
@@ -1061,12 +1062,21 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(dev-struct_mutex);
+ if (IS_GEN6(dev) || IS_GEN7(dev)) {
+ pm_ier = I915_READ(GEN6_PMIER);
+ pm_imr = I915_READ(GEN6_PMIMR);
+ pm_isr = I915_READ(GEN6_PMISR);
+ pm_iir = I915_READ(GEN6_PMIIR);
+ pm_mask = I915_READ(GEN6_PMINTRMSK);
+ } else {
+ pm_ier = I915_READ(GEN8_GT_IER(2));
+ pm_imr = I915_READ(GEN8_GT_IMR(2));
+ pm_isr = I915_READ(GEN8_GT_ISR(2));
+ pm_iir = I915_READ(GEN8_GT_IIR(2));
+ pm_mask = I915_READ(GEN6_PMINTRMSK);
+ }
seq_printf(m, PM IER=0x%08x IMR=0x%08x ISR=0x%08x IIR=0x%08x,
MASK=0x%08x\n,
- I915_READ(GEN6_PMIER),
- I915_READ(GEN6_PMIMR),
- I915_READ(GEN6_PMISR),
- I915_READ(GEN6_PMIIR),
- I915_READ(GEN6_PMINTRMSK));
+ pm_ier, pm_imr, pm_isr, pm_iir, pm_mask);
seq_printf(m, GT_PERF_STATUS: 0x%08x\n, gt_perf_status);
seq_printf(m, Render p-state ratio: %d\n,
(gt_perf_status 0xff00) 8);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: only hook up hpd pulse for DP setups.
2014-08-01 17:47 GMT-03:00 Dave Airlie airl...@gmail.com:
From: Dave Airlie airl...@redhat.com
On HSW/BDW the VBT can tell us if we need to have DP support for a port,
if we don't have DP this caused an oops in the hpd handling.
Don't hook up the DP hpd handling if we don't have a DP port.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856
Reported-by: Intel QA Team.
Signed-off-by: Dave Airlie airl...@redhat.com
The patch looks correct, but AFAIK we didn't need it in the past, so I
am curious about why is it needed now. What changed that caused the
need for it?
---
drivers/gpu/drm/i915/intel_ddi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 9b1542f..42d4dce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1557,11 +1557,13 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
intel_encoder-cloneable = 0;
intel_encoder-hot_plug = intel_ddi_hot_plug;
- intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
- dev_priv-hpd_irq_port[port] = intel_dig_port;
+ if (init_dp) {
+ /* only hook up hpd processing for DP */
+ intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
+ dev_priv-hpd_irq_port[port] = intel_dig_port;
- if (init_dp)
dp_connector = intel_ddi_init_dp_connector(intel_dig_port);
+ }
/* In theory we don't need the encoder-type check, but leave it just
in
* case we have some really bad VBTs... */
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: only hook up hpd pulse for DP setups.
On 2 August 2014 07:38, Paulo Zanoni przan...@gmail.com wrote: 2014-08-01 17:47 GMT-03:00 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com On HSW/BDW the VBT can tell us if we need to have DP support for a port, if we don't have DP this caused an oops in the hpd handling. Don't hook up the DP hpd handling if we don't have a DP port. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856 Reported-by: Intel QA Team. Signed-off-by: Dave Airlie airl...@redhat.com The patch looks correct, but AFAIK we didn't need it in the past, so I am curious about why is it needed now. What changed that caused the need for it? Well the pulse handling is only new and I think we should have hit this prior to MST, since hpd_pulse called intel_dp_check_link_status. Prior to the pulse irq, intel_ddi check if the port was eDP or DP before proceeding. Dave ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On 08/01/14 05:58, Laurent Pinchart wrote: Hi Randy, On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote: On 05/12/14 11:04, Randy Dunlap wrote: On 05/12/2014 08:54 AM, Daniel Vetter wrote: On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: On 05/12/2014 01:58 AM, Daniel Vetter wrote: On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: If we decide to go for property documentation inside the source code then I believe we'll have to create our own format, as creating a properties table from kerneldoc information extracted from comments is probably not possible. Can comeone pick up the ball here and figure out what needs to be done? The reason why I want a central place for the documentation is to force people to collaborate outside their own sandbox when adding properties. Whether that's docbook or some text file I don't care so much at this point. The fact that it's a central place should mandate that the patches changing it will go through dri-devel and so everyone should se them, and when adding new properties it would make the patch author more likely to look around a bit before adding another slighty incompatible version of the same property. If someone has a better suggestion how to encforce this I'm all ears. Of course this idea can still fail if our esteemed maintainer merges stuff without checking for violations of this policy. Dave, any thoughts on the subject? Yeah I'm happy to block merging stuff, if we can spot new properties when stuff is posted on dri-devel, so much the better, most drivers still send everything via dri-devel anyways, its only really Intel I have to worry about so far, I'll enforce that all prop stuff gets cc: dri-devel and that it has updates for the prop docs. But we should definitely add it to the new driver review checklist as well. I'm also on the side of this patch is ugly and makes my eyes burn, please please get a plan to use something else ASAP, I'm willing to merge this but I'm tempted to give it a lifetime of a kernel or two before I burn it. Ok, I'll try to move make kerneldoc suck less up the task list and maybe find someone to do it for me internally ;-) I certainly have no objections to making kerneldoc suck less. There was already an attempt to use asciidoc (like git uses) for kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that effort. Hm, do you have pointers to those? My google-fu seems lacking ... I googled for /kernel doc asciidoc ravnborg/ and found several hits for them. Ok, let's move this to the top and start discussions. The past few months I've written piles of kerneldoc comments for the DRM DocBook (all pulled in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: sections are really useful to pull all the actual documentation out of the docbook xml into kerneldoc. But I've also done piles of docs for intel-gpu-tools, which is using gtkdoc. And there are some clear deficiencies: - No markdown for inline coments. Lack of lists and tables is hurting especially badly. If we add this (and I don't care one iota whether it's Yes, I've tried to add lists to kernel-doc notation but have failed so far. markdown or asciidoc or something else as long as it's readable plain text in comments) we should be able to move all the existing docbook xml paragraphs/lists/tables into kerneldoc comments. - Automatic cross-referencing of functions. If you place e.g. function() or #struct anywhere in a documentation comment gtk-doc automatically inserts a hyperlink to the relevant documentation page across the entire project. Really powerful and makes overview sections much more useful entry points for beginners since they can easily jump backforth betweeen the high-level overview and low-level per-function documentation. That's a nice-to-have IMO, but a really nice one. - In a really perfect world it would help if kerneldoc could collect structure member kerneldoc from per-member comments. Especially for large structures with lots of comments this would bring the kerneldoc and struct member much closer together. So that's my wishlist. OTOH, I would only want to add another way to do kernel-doc if it can be a full replacement for all of our docbook usage, i.e., it should provide a way that we can eliminate docbook and stop using it completely. Hm, I don't mind docbook at all, as long as all the real content is embedded into source files as kerneldoc and the docbook template just pulls in all the right bits and pieces. Even gtkdoc allos you to do that and pull in the different libararies (== header files with declarations for C) in the order you want. So imo the docbook toolchain is good enough for my needs. Or what do you mean by getting rid of all docbook usage? I meant no docbook style sheets, no 'xmlto', the whole ball of wax. But primarily I don't want to see drivers/video/ using
[Intel-gfx] [PATCH 1/2] drm/i915: Collect gtier properly on HSW.
GTIER and DEIER doesn't have same interface on HSW so this or operation
makes the information provided useless.
v2: since we have gtier variable already let's split for everybody
and avoid the strange | op.
Also avoid overriding the value that was set for vlv. In this case I
believe that we should reorganize the whole function, but I'll respect
the comment that ask to not touch the order and let this organization
work to be done later.
v3: moving VLV check to the right place.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 21 +++--
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d604f4f..60227b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,6 +317,7 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 gtier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..c8f901f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -359,6 +359,8 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
+ err_printf(m, GTIER: 0x%08x\n, error-gtier);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1102,7 +1104,8 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-ier = I915_READ(GTIER) | I915_READ(VLV_IER);
+ error-gtier = I915_READ(GTIER);
+ error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1135,16 +1138,14 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
- error-ier = I915_READ(DEIER) | I915_READ(GTIER);
- else {
- if (IS_GEN2(dev))
- error-ier = I915_READ16(IER);
- else
- error-ier = I915_READ(IER);
+ if (HAS_PCH_SPLIT(dev)) {
+ error-ier = I915_READ(DEIER);
+ error-gtier = I915_READ(GTIER);
+ } else if (IS_GEN2(dev)) {
+ error-ier = I915_READ16(IER);
+ } else if (!IS_VALLEYVIEW(dev)) {
+ error-ier = I915_READ(IER);
}
-
- /* 4: Everything else */
error-eir = I915_READ(EIR);
error-pgtbl_er = I915_READ(PGTBL_ER);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Fix DEIER and GTIER collecting for BDW.
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
v2: Fix small issues of first version and don't read DEIER regs when pipe's
power well is disabled
v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe interection
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 32
3 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..b3493d3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -703,6 +703,10 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
}
for_each_pipe(pipe) {
+ if (!intel_display_power_enabled(dev_priv,
+
POWER_DOMAIN_PIPE(pipe)))
+ continue;
+
seq_printf(m, Pipe %c IMR:\t%08x\n,
pipe_name(pipe),
I915_READ(GEN8_DE_PIPE_IMR(pipe)));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60227b2..d1ae952 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -317,7 +317,9 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
+ u32 deier[3];
+ u32 de_misc_ier;
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index c8f901f..402b621 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -328,6 +328,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_error_state *error = error_priv-error;
struct drm_i915_error_object *obj;
+ enum pipe pipe;
int i, j, offset, elt;
int max_hangcheck_score;
@@ -359,8 +360,20 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(pipe)
+ err_printf(m, DEIER pipe %c: 0x%08x\n,
+ pipe_name(pipe),
+ error-deier[pipe]);
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+ error-gtier[i]);
+ err_printf(m, DE_MISC_IER: 0x%08x\n, error-de_misc_ier);
+ } else {
+ err_printf(m, IER: 0x%08x\n, error-ier);
+ }
if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1093,6 +1106,8 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ enum pipe pipe;
+ int i;
/* General organization
* 1. Registers specific to a single generation
@@ -1104,7 +1119,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1138,9 +1153,18 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev)) {
+ if (IS_BROADWELL(dev)) {
+ for_each_pipe(pipe)
+ if (intel_display_power_enabled(dev_priv,
+
POWER_DOMAIN_PIPE(pipe)))
+ error-deier[pipe] =
+
