Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On Fri, 27 Feb 2015, Todd Previte tprev...@gmail.com wrote:
Hi Mika,
On 2/26/2015 2:26 AM, Mika Kahola wrote:
In a case when DP link has been once trained we can reuse
the existing link training parameters i.e. voltage swing
and pre-emphasis levels from cache when there is a need to
restart link training. In a case of eDP we initially try
to train the link by using the parameter set that we can find
from VBT. The fallback on both cases is to reset the link
training parameters and restart.
I think you have a good idea here for the eDP case. But the way it's
coded, there appear to be cases where the code will try to reuse the
same training settings for regular DP as well. That will likely have
some unfortunate results, as there's no guarantee for a normal external
Displayport connection that training settings which worked once will
work the next time. This would be of particular concern when
disconnecting and reconnecting Displayport sink devices, as it appears
as though it would try to retrain the newly connected device using the
previously valid settings for the old device.
Hmm, I thought it would be all right on external DP also if we ensure we
reset the train set when the sink may have changed, i.e. at suspend and
hotplug.
BR,
Jani.
IMHO, this really needs to be written as eDP only and such that it can
never occur on an external Displayport device. Otherwise, it seems like
there's a good chance of ending up with a black screen when you plug in
a Displayport monitor.
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 93
+++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 84 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index d1141d3..8482f58 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3288,8 +3288,39 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp, uint32_t *DP,
uint8_t dp_train_pat)
{
-memset(intel_dp-train_set, 0, sizeof(intel_dp-train_set));
+struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+struct drm_device *dev = intel_dig_port-base.base.dev;
+struct drm_i915_private *dev_priv = dev-dev_private;
+int i;
+
+/* in case of eDP, get link training parameters from VBT */
+if (is_edp(intel_dp)) {
+for (i=0; iintel_dp-lane_count; i++)
+intel_dp-train_set[i] = dev_priv-vbt.edp_vswing |
dev_priv-vbt.edp_preemphasis;
+}
+else
+memset(intel_dp-train_set, 0, sizeof(intel_dp-train_set));
+
+intel_dp_set_signal_levels(intel_dp, DP);
+return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
+}
+
+static bool
+intel_dp_reuse_link_train(struct intel_dp *intel_dp, uint32_t *DP,
+ uint8_t dp_train_pat)
+{
+struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+struct drm_device *dev = intel_dig_port-base.base.dev;
+struct drm_i915_private *dev_priv = dev-dev_private;
+
intel_dp_set_signal_levels(intel_dp, DP);
+
+I915_WRITE(intel_dp-output_reg, *DP);
+POSTING_READ(intel_dp-output_reg);
+
+drm_dp_dpcd_write(intel_dp-aux, DP_TRAINING_LANE0_SET,
+ intel_dp-train_set, intel_dp-lane_count);
+
return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
}
I'm not sure you want to be updating the sink device at this point. This
should be checked against the spec to be sure it's not out of sequence.
@@ -3356,6 +3387,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int voltage_tries, loop_tries;
uint32_t DP = intel_dp-DP;
uint8_t link_config[2];
+uint8_t link_status[DP_LINK_STATUS_SIZE];
+bool reuse_train_set = false;
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
@@ -3373,20 +3406,44 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP |= DP_PORT_EN;
-/* clock recovery */
-if (!intel_dp_reset_link_train(intel_dp, DP,
- DP_TRAINING_PATTERN_1 |
- DP_LINK_SCRAMBLING_DISABLE)) {
-DRM_ERROR(failed to enable link training\n);
-return;
+/*
+ * check if DP has already trained. Reset voltage swing and
+ * pre-emphasis levels if that's not the case.
+ */
+if (intel_dp-link_trained) {
+if (!intel_dp_reuse_link_train(intel_dp, DP,
+ DP_TRAINING_PATTERN_1 |
+ DP_LINK_SCRAMBLING_DISABLE)) {
+DRM_DEBUG_KMS(unable to set known link training
values\n);
+return;
+}
+DRM_DEBUG_KMS(reuse current link train set\n);
+
Re: [Intel-gfx] [PATCH 0/4] drm/i915/skl: Support for edp1.4 intermediate frequencies
Hi, Did anybody get a chance to look into these patches? The first patch in the series is merged in -nightly Thanks, Sonika -Original Message- From: Jindal, Sonika Sent: Saturday, February 21, 2015 11:12 AM To: intel-gfx@lists.freedesktop.org Cc: ville.syrj...@linux.intel.com; Jindal, Sonika Subject: [PATCH 0/4] drm/i915/skl: Support for edp1.4 intermediate frequencies This series adds support for edp1.4 intermediate frequencies supported by Skylake This addresses review comments by Ville and some reformatting. Sonika Jindal (4): drm: Adding edp1.4 specific dpcd macros drm/i915/skl: Read sink supported rates from edp panel drm/i915/skl: Add support for edp 1.4 intermediate frequencies drm/i915/skl: Program PLL for edp1.4 intermediate frequencies drivers/gpu/drm/i915/intel_ddi.c |9 ++ drivers/gpu/drm/i915/intel_dp.c | 179 +++--- drivers/gpu/drm/i915/intel_drv.h |2 + include/drm/drm_dp_helper.h |8 ++ 4 files changed, 184 insertions(+), 14 deletions(-) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix a use after free, and unbalanced refcounting
On Tue, 24 Feb 2015, Jani Nikula jani.nik...@linux.intel.com wrote:
On Mon, 23 Feb 2015, Daniel, Thomas thomas.dan...@intel.com wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of
Nick Hoath
Sent: Thursday, February 19, 2015 4:31 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: Fix a use after free, and unbalanced
refcounting
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
When converting from implicitly tracked execlist queue items to ref counted
requests, not all frees of requests were replaced with unrefs, and
extraneous
refs/unrefs of contexts were added.
Correct the unbalanced refcount replace the frees.
Remove a noisy warning when hitting the request creation path.
drm_i915_gem_request and intel_context are both kref reference counted
structures. Upon allocation, drm_i915_gem_request's ref count should be
bumped using kref_init. When a context is assigned to the request,
the context's reference count should be bumped using
i915_gem_context_reference.
i915_gem_request_reference will reduce the context reference count when
the request is freed.
Problem introduced in
commit 6d3d8274bc45de4babb62d64562d92af984dd238
Author: Nick Hoath nicholas.ho...@intel.com
AuthorDate: Thu Jan 15 13:10:39 2015 +
drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request
v2: Added comments explaining how the ctx pointer and the request object
should
be ref-counted. Removed noisy warning.
v3: Cleaned up the language used in the commit the header
description (Thanks David Gordon)
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/i915_gem.c | 3 +--
drivers/gpu/drm/i915/intel_lrc.c | 8
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2dedd43..956fe26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2121,6 +2121,9 @@ void i915_gem_track_fb(struct drm_i915_gem_object
*old,
* number comparisons on buffer last_read|write_seqno. It also allows an
* emission time to be associated with the request for tracking how far
ahead
* of the GPU the submission is.
+ *
+ * The requests are reference counted, so upon creation they should have an
+ * initial reference taken using kref_init
*/
struct drm_i915_gem_request {
struct kref ref;
@@ -2144,7 +2147,16 @@ struct drm_i915_gem_request {
/** Position in the ringbuffer of the end of the whole request */
u32 tail;
- /** Context related to this request */
+ /**
+* Context related to this request
+* Contexts are refcounted, so when this request is associated with a
+* context, we must increment the context's refcount, to guarantee that
+* it persists while any request is linked to it. Requests themselves
+* are also refcounted, so the request will only be freed when the last
+* reference to it is dismissed, and the code in
+* i915_gem_request_free() will then decrement the refcount on the
+* context.
+*/
struct intel_context *ctx;
/** Batch buffer related to this request if any */
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 61134ab..996f60f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2664,8 +2664,7 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
if (submit_req-ctx != ring-default_context)
intel_lr_context_unpin(ring, submit_req-ctx);
- i915_gem_context_unreference(submit_req-ctx);
- kfree(submit_req);
+ i915_gem_request_unreference(submit_req);
}
/*
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index aafcef3..62a2b2a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -512,18 +512,19 @@ static int execlists_context_queue(struct
intel_engine_cs *ring,
* If there isn't a request associated with this submission,
* create one as a temporary holder.
*/
- WARN(1, execlist context submission without request);
request = kzalloc(sizeof(*request), GFP_KERNEL);
if (request == NULL)
return -ENOMEM;
request-ring = ring;
request-ctx = to;
+ kref_init(request-ref);
+ request-uniq = dev_priv-request_uniq++;
+ i915_gem_context_reference(request-ctx);
} else {
+ i915_gem_request_reference(request);
WARN_ON(to != request-ctx);
}
request-tail = tail;
- i915_gem_request_reference(request);
- i915_gem_context_reference(request-ctx);
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On Thu, Feb 26, 2015 at 06:29:45PM -0700, Todd Previte wrote: Hi Mika, On 2/26/2015 2:26 AM, Mika Kahola wrote: In a case when DP link has been once trained we can reuse the existing link training parameters i.e. voltage swing and pre-emphasis levels from cache when there is a need to restart link training. In a case of eDP we initially try to train the link by using the parameter set that we can find from VBT. The fallback on both cases is to reset the link training parameters and restart. I think you have a good idea here for the eDP case. But the way it's coded, there appear to be cases where the code will try to reuse the same training settings for regular DP as well. That will likely have some unfortunate results, as there's no guarantee for a normal external Displayport connection that training settings which worked once will work the next time. This would be of particular concern when disconnecting and reconnecting Displayport sink devices, as it appears as though it would try to retrain the newly connected device using the previously valid settings for the old device. IMHO, this really needs to be written as eDP only and such that it can never occur on an external Displayport device. Otherwise, it seems like there's a good chance of ending up with a black screen when you plug in a Displayport monitor. I've thought we should retrain with the same parameters we used the last time iff the link was succesully trained using those parameters in the past and the sink hasn't been disconnected in the meantime. We'd do this in the hopes of speeding up subsequent link trainings. So resetting the saved parameters on link training failure and long HPD should be good enough here, I think. And this way the VBT thing could just be a special case where we just sort of pretend that we succesfully trained the link using those parameters in the past. Oh and we could also read out the state from the hardware during init, and assuming the link was up and stable at the time we could populate the previous good values from whatever the BIOS actually programmed into the hardware. Anyway, that's just how I've imagined we should implement this kind of stuff. -- 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] drm/i915: Check for driver readyness before handling an underrun interrupt
On Thu, 26 Feb 2015, Chris Wilson ch...@chris-wilson.co.uk wrote:
When we takeover from the BIOS and install our interrupt handler, the
BIOS may have left us a few surprises in the form of spontaneous
interrupts. (This is especially likely on hardware like 965gm where
display fifo underruns are continuous and the GMCH cannot filter that
interrupt souce.) As we enable our IRQ early so that we can use it
during hardware probing, our interrupt handler must be prepared to
handle a few sources prior to being fully configured. As such, we need
to add a simple is-ready check prior to dereferencing our KMS state for
reporting underruns.
Reported-by: Rob Clark rcl...@redhat.com
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972
You are not authorized to access bug #1193972. To see this bug, you
must first log in to an account with the appropriate permissions.
Meh.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_fifo_underrun.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index 04e248dd2259..f2fd992e3cd8 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -282,16 +282,6 @@ bool intel_set_cpu_fifo_underrun_reporting(struct
drm_i915_private *dev_priv,
return ret;
}
-static bool
-__cpu_fifo_underrun_reporting_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe)
-{
- struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
- return !intel_crtc-cpu_fifo_underrun_disabled;
-}
-
/**
* intel_set_pch_fifo_underrun_reporting - set PCH fifo underrun reporting
state
* @dev_priv: i915 device instance
@@ -352,9 +342,15 @@ bool intel_set_pch_fifo_underrun_reporting(struct
drm_i915_private *dev_priv,
void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
+ struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
+
+ /* We may be called too early in init, thanks BIOS! */
+ if (crtc == NULL)
+ return;
+
/* GMCH can't disable fifo underruns, filter them. */
if (HAS_GMCH_DISPLAY(dev_priv-dev)
- !__cpu_fifo_underrun_reporting_enabled(dev_priv, pipe))
+ !to_intel_crtc(crtc)-cpu_fifo_underrun_disabled)
return;
if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false))
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915/chv: Set min freq to efficient frequency on chv
On Thu, Feb 26, 2015 at 08:46:56PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com After feedback from the hardware team, now we set the GPU min freq to RPe. If we drop the freq to RPn, we found that the punit was not setting the voltage to Vnn, So recommendation is to set min freq to RPe. And does it change the voltage at all? Is there really any advantage to the extra code on idle? Does efficient_freq really consume less power than min_freq when active (assuming a min_freq/efficient_freq busy workload i.e. does a workload that would be 100% busy at min_freq consume less power when run at efficient_freq)? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Modifying RC6 Promotion timer for Media workloads.
On Thu, Feb 26, 2015 at 08:46:57PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com In normal cases, RC6 promotion timer is 1700us/500us. This will result in more time spent in C1 state. For more residency in C6 in case of media workloads, this is changed to 250us. Not doing this for 3D workloads as too many C6-C0 transition delays can result in performance impact I would prefer it if you extended intel_mark_busy() to note the source of work, and so extended the busy/idle tracking per-ring with the appropriate hooks for vlv to modify RPS, like how we already do for the general gen6_rps_busy and gen6_rps_idle. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Framebuffers need not be limited to 256MB on gen8+.
On Thu, Feb 26, 2015 at 04:01:32PM +, Chris Wilson wrote: On Thu, Feb 26, 2015 at 09:01:52PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com The restriction of pinningFramebuffer to first 256MB is removed from gen8+. Removing the restriction so that FB can be pinned in any space within GTT/PPGTT. Also, for gen8+ no need to use pin_mappable for Framebuffer also we do not take fence as Framebuffer compression is not enabled. Not quite, the reason why we restrict the framebuffer to mappable was that certain display servers depend upon being able to GTT mmap the framebuffer for direct access. Thus they would crash if we found that the framebuffer was already pinned in an unreachable location. That legacy code is currently still able to run on gen8+ and so you need to have userspace request an ABI break... Also, if we do that, we need to make sure we can't bind the buffer at the top of GGTT as we need to be able to prefetch 128 PTEs past the fb? (on SKL 136, The end of the surface cannot be within 136 PTEs of the end of the graphics memory). -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check DVO reads for errors
Not all of the DVO functions were checking the return value from their
i2c routines when reading registers. This could lead to us feeding
garbage values back into the hardware, possible causing further
failures. In some cases the uninitialised stack values were being
written into the kernel log.
Quentin Casasnovas suggested the simple solution of just initialising
the output parameter to zero in all cases, but we may as well spend the
extra few moments to fix it correctly.
Reported-by: Quentin Casasnovas quentin.casasno...@oracle.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Quentin Casasnovas quentin.casasno...@oracle.com
---
drivers/gpu/drm/i915/dvo_ch7017.c | 23 -
drivers/gpu/drm/i915/dvo_ch7xxx.c | 36 ++--
drivers/gpu/drm/i915/dvo_ivch.c | 64 +++-
drivers/gpu/drm/i915/dvo_sil164.c | 49 +--
drivers/gpu/drm/i915/dvo_tfp410.c | 69 ++-
5 files changed, 120 insertions(+), 121 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c
b/drivers/gpu/drm/i915/dvo_ch7017.c
index 86b27d1d90c2..452f0144e6a2 100644
--- a/drivers/gpu/drm/i915/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/dvo_ch7017.c
@@ -335,7 +335,8 @@ static void ch7017_dpms(struct intel_dvo_device *dvo, bool
enable)
{
uint8_t val;
- ch7017_read(dvo, CH7017_LVDS_POWER_DOWN, val);
+ if (!ch7017_read(dvo, CH7017_LVDS_POWER_DOWN, val))
+ return;
/* Turn off TV/VGA, and never turn it on since we don't support it. */
ch7017_write(dvo, CH7017_POWER_MANAGEMENT,
@@ -363,7 +364,8 @@ static bool ch7017_get_hw_state(struct intel_dvo_device
*dvo)
{
uint8_t val;
- ch7017_read(dvo, CH7017_LVDS_POWER_DOWN, val);
+ if (!ch7017_read(dvo, CH7017_LVDS_POWER_DOWN, val))
+ return false;
if (val CH7017_LVDS_POWER_DOWN_EN)
return false;
@@ -371,16 +373,20 @@ static bool ch7017_get_hw_state(struct intel_dvo_device
*dvo)
return true;
}
-static void ch7017_dump_regs(struct intel_dvo_device *dvo)
+static void ch7017_dump_reg(struct intel_dvo_device *dvo,
+ int reg, const char *name)
{
uint8_t val;
-#define DUMP(reg) \
-do { \
- ch7017_read(dvo, reg, val);\
- DRM_DEBUG_KMS(#reg : %02x\n, val);\
-} while (0)
+ if (ch7017_read(dvo, reg, val))
+ DRM_DEBUG_KMS(%s: %02x\n, name, val);
+ else
+ DRM_DEBUG_KMS(%s: failed\n, name);
+}
+static void ch7017_dump_regs(struct intel_dvo_device *dvo)
+{
+#define DUMP(reg) ch7017_dump_reg(dvo, reg, #reg)
DUMP(CH7017_HORIZONTAL_ACTIVE_PIXEL_INPUT);
DUMP(CH7017_HORIZONTAL_ACTIVE_PIXEL_OUTPUT);
DUMP(CH7017_VERTICAL_ACTIVE_LINE_OUTPUT);
@@ -390,6 +396,7 @@ do {
\
DUMP(CH7017_LVDS_CONTROL_2);
DUMP(CH7017_OUTPUTS_ENABLE);
DUMP(CH7017_LVDS_POWER_DOWN);
+#undef DUMP
}
static void ch7017_destroy(struct intel_dvo_device *dvo)
diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c
b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index 80449f475960..fb23b16eaf07 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -248,20 +248,20 @@ static enum drm_connector_status ch7xxx_detect(struct
intel_dvo_device *dvo)
{
uint8_t cdet, orig_pm, pm;
- ch7xxx_readb(dvo, CH7xxx_PM, orig_pm);
+ if (!ch7xxx_readb(dvo, CH7xxx_PM, orig_pm))
+ return connector_status_disconnected;
pm = orig_pm;
pm = ~CH7xxx_PM_FPD;
pm |= CH7xxx_PM_DVIL | CH7xxx_PM_DVIP;
+ cdet = 0;
ch7xxx_writeb(dvo, CH7xxx_PM, pm);
-
ch7xxx_readb(dvo, CH7xxx_CONNECTION_DETECT, cdet);
-
ch7xxx_writeb(dvo, CH7xxx_PM, orig_pm);
-
if (cdet CH7xxx_CDET_DVI)
return connector_status_connected;
+
return connector_status_disconnected;
}
@@ -300,16 +300,16 @@ static void ch7xxx_mode_set(struct intel_dvo_device *dvo,
ch7xxx_writeb(dvo, CH7xxx_TLPF, tlpf);
ch7xxx_writeb(dvo, CH7xxx_TCT, 0x00);
- ch7xxx_readb(dvo, CH7xxx_IDF, idf);
+ if (ch7xxx_readb(dvo, CH7xxx_IDF, idf)) {
+ idf = ~(CH7xxx_IDF_HSP | CH7xxx_IDF_VSP);
+ if (mode-flags DRM_MODE_FLAG_PHSYNC)
+ idf |= CH7xxx_IDF_HSP;
- idf = ~(CH7xxx_IDF_HSP | CH7xxx_IDF_VSP);
- if (mode-flags DRM_MODE_FLAG_PHSYNC)
- idf |= CH7xxx_IDF_HSP;
+ if (mode-flags DRM_MODE_FLAG_PVSYNC)
+ idf |= CH7xxx_IDF_VSP;
- if (mode-flags DRM_MODE_FLAG_PVSYNC)
- idf |= CH7xxx_IDF_VSP;
-
- ch7xxx_writeb(dvo, CH7xxx_IDF, idf);
+ ch7xxx_writeb(dvo, CH7xxx_IDF, idf);
+
Re: [Intel-gfx] [PATCH 1/2] drm: Complete moving rotation property to core
On Thu, Feb 26, 2015 at 07:24:24AM -0800, Matt Roper wrote:
For both patches:
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Both merged to drm-misc, thanks.
-Daniel
On Thu, Feb 26, 2015 at 01:49:17PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Commit 1da30627fc511a57c9bd23a02c97f0576379f761 drm: Add rotation value to
plane state moved the rotation property to DRM core but only did the set
property part. This does the get property part as well.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 321e098..7ca54cb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -450,6 +450,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state-src_w;
} else if (property == config-prop_src_h) {
*val = state-src_h;
+ } else if (property == config-rotation_property) {
+ *val = state-rotation;
} else if (plane-funcs-atomic_get_property) {
return plane-funcs-atomic_get_property(plane, state,
property, val);
} else {
--
2.3.0
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915/skl: Updated watermark programming
On Wed, Feb 25, 2015 at 04:47:22PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Recent BSpect updates have changed the watermark calculation to avoid
display flickering in some cases.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
There are really several changes in this patch, it would have been
easier for the review to split them (and that's usually how we are
supposed to split patches).
- Convert the inner computations to number of blocks
- W/A to increase the nb of blocks for level 1-7 by 1
- Move max block test to = instead of
Anyway, which the couple of comments below addressd (of which only the
'=' is a real problem), this is:
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
drivers/gpu/drm/i915/intel_pm.c | 52
+
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f7c9938..626c3c2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2595,7 +2595,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
if (latency == 0)
return UINT_MAX;
- wm_intermediate_val = latency * pixel_rate * bytes_per_pixel;
+ wm_intermediate_val = latency * pixel_rate * bytes_per_pixel / 512;
ret = DIV_ROUND_UP(wm_intermediate_val, 1000);
return ret;
@@ -2605,15 +2605,18 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
uint32_t latency)
{
- uint32_t ret, plane_bytes_per_line, wm_intermediate_val;
+ uint32_t ret;
+ uint32_t plane_bytes_per_line, plane_blocks_per_line;
+ uint32_t wm_intermediate_val;
if (latency == 0)
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
- plane_bytes_per_line;
+ plane_blocks_per_line;
return ret;
}
@@ -2693,39 +2696,47 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
}
}
-static bool skl_compute_plane_wm(struct skl_pipe_wm_parameters *p,
+static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
+ struct skl_pipe_wm_parameters *p,
struct intel_plane_wm_parameters *p_params,
uint16_t ddb_allocation,
- uint32_t mem_value,
+ int level,
uint16_t *out_blocks, /* out */
uint8_t *out_lines /* out */)
{
- uint32_t method1, method2, plane_bytes_per_line, res_blocks, res_lines;
- uint32_t result_bytes;
+ uint32_t latency = dev_priv-wm.skl_latency[level];
+ uint32_t method1, method2;
+ uint32_t plane_bytes_per_line, plane_blocks_per_line;
+ uint32_t res_blocks, res_lines;
+ uint32_t result_blocks;
we now have res_blocks and result_blocks, a bit confusing. Maybe rename
result_blocks to selected_result (which happens to be in blocks)
- if (mem_value == 0 || !p-active || !p_params-enabled)
+ if (latency == 0 || !p-active || !p_params-enabled)
return false;
method1 = skl_wm_method1(p-pixel_rate,
p_params-bytes_per_pixel,
- mem_value);
+ latency);
method2 = skl_wm_method2(p-pixel_rate,
p-pipe_htotal,
p_params-horiz_pixels,
p_params-bytes_per_pixel,
- mem_value);
+ latency);
plane_bytes_per_line = p_params-horiz_pixels *
p_params-bytes_per_pixel;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
/* For now xtile and linear */
- if (((ddb_allocation * 512) / plane_bytes_per_line) = 1)
- result_bytes = min(method1, method2);
+ if ((ddb_allocation / plane_blocks_per_line) = 1)
+ result_blocks = min(method1, method2);
else
- result_bytes = method1;
+ result_blocks = method1;
+
+ res_blocks = result_blocks + 1;
+ res_lines = DIV_ROUND_UP(result_blocks, plane_blocks_per_line);
- res_blocks = DIV_ROUND_UP(result_bytes, 512) + 1;
- res_lines = DIV_ROUND_UP(result_bytes, plane_bytes_per_line);
+ if (level =1 level = 7)
a space is missing before the 1 :)
+
Re: [Intel-gfx] [PATCH] drm/i915: Add media rc6 residency file to sysfs
On Thu, Feb 26, 2015 at 09:10:27PM +0530, deepa...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com On VLV/CHV the media well rc6 residency gets reported separately from the render well, so add another file to sysfs so that we can report the residency to the user. Testcase: igt/pm_rc6_residency --run-subtest media-rc6-accuracy Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Deepak S deepa...@linux.intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch -next] drm/i915: fix a printk format
This printk leads to the following Smatch warning: drivers/gpu/drm/i915/i915_gem_gtt.c:336 alloc_pt_range() error: '%pa' expects argument of type 'phys_addr_t*', argument 5 has type 'struct i915_page_table_entry*' It looks like a simple typo to me where %p was intended instead of %pa. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index e05488e..48eff65 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -334,7 +334,7 @@ static int alloc_pt_range(struct i915_page_directory_entry *pd, uint16_t pde, si goto err_out; } WARN(pd-page_table[i], -Leaking page directory entry %d (%pa)\n, +Leaking page directory entry %d (%p)\n, i, pd-page_table[i]); pd-page_table[i] = pt; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915/skl: Update watermarks for Y tiling
On Wed, Feb 25, 2015 at 04:47:23PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates as well.
v3: Rebased for plane handling changes.
v4: Handle fb == NULL when plane is disabled.
v5: Refactored for addfb2 interface.
v6: Refactored for fb modifier changes.
v7: Updated for atomic commit by only updating watermarks when tiling changes.
v8: BSpec watermark calculation updates.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Acked-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Acked-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 6
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 56
++--
drivers/gpu/drm/i915/intel_sprite.c | 6
4 files changed, 60 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 626e6538..1d50934 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11994,6 +11994,12 @@ intel_check_primary_plane(struct drm_plane *plane,
INTEL_FRONTBUFFER_PRIMARY(intel_crtc-pipe);
intel_crtc-atomic.update_fbc = true;
+
+ /* Update watermarks on tiling changes. */
+ if (!plane-state-fb || !state-base.fb ||
+ plane-state-fb-modifier[0] !=
+ state-base.fb-modifier[0])
+ intel_crtc-atomic.update_wm = true;
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 399d2b2..b124548 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -501,6 +501,7 @@ struct intel_plane_wm_parameters {
uint8_t bytes_per_pixel;
bool enabled;
bool scaled;
+ u64 tiling;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 626c3c2..e0d6ebc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2603,7 +2603,7 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t bytes_per_pixel,
static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t bytes_per_pixel,
-uint32_t latency)
+uint64_t tiling, uint32_t latency)
{
Hum, does this compile? I'm seeing an extra argument to skl_wm_method2()
but no update at the calling site?
uint32_t ret;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -2613,7 +2613,16 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
return UINT_MAX;
plane_bytes_per_line = horiz_pixels * bytes_per_pixel;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+
+ if (tiling == I915_FORMAT_MOD_Y_TILED ||
+ tiling == I915_FORMAT_MOD_Yf_TILED) {
+ plane_bytes_per_line *= 4;
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ plane_blocks_per_line /= 4;
+ } else {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ }
+
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
plane_blocks_per_line;
@@ -2665,6 +2674,7 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc-pipe;
struct drm_plane *plane;
+ struct drm_framebuffer *fb;
int i = 1; /* Index for sprite planes start */
p-active = intel_crtc_active(crtc);
@@ -2680,6 +2690,14 @@ static void skl_compute_wm_pipe_parameters(struct
drm_crtc *crtc,
crtc-primary-fb-bits_per_pixel / 8;
p-plane[0].horiz_pixels = intel_crtc-config-pipe_src_w;
p-plane[0].vert_pixels = intel_crtc-config-pipe_src_h;
+ p-plane[0].tiling = DRM_FORMAT_MOD_NONE;
+ fb = crtc-primary-fb;
+ /*
+ * Framebuffer can be NULL on plane disable, but it does not
+ * matter for watermarks if we assume no tiling in that case.
+ */
+ if (fb)
+ p-plane[0].tiling = fb-modifier[0];
p-cursor.enabled = true;
p-cursor.bytes_per_pixel = 4;
@@ -2709,6 +2727,7 @@ static bool skl_compute_plane_wm(const struct
Re: [Intel-gfx] [PATCH 8/8] drm/i915/skl: Allow Y (and Yf) frame buffer creation
On Wed, Feb 25, 2015 at 04:47:24PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
By this patch all underlying bits have been implemented and this
patch actually enables the feature.
v2: Validate passed in fb modifiers to reject garbage. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com (v1)
---
drivers/gpu/drm/i915/intel_display.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1d50934..3232ddd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12783,6 +12783,19 @@ static int intel_framebuffer_init(struct drm_device
*dev,
WARN_ON(!mutex_is_locked(dev-struct_mutex));
if (mode_cmd-flags DRM_MODE_FB_MODIFIERS) {
+ /* Passed in modifier sanity checking. */
+ switch (mode_cmd-modifier[0]) {
+ case DRM_FORMAT_MOD_NONE:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_Yf_TILED:
+ break;
+ default:
+ DRM_ERROR(Unsupported fb modifier 0x%llx!\n,
+ mode_cmd-modifier[0]);
+ return -EINVAL;
+ }
+
/* Enforce that fb modifier and tiling mode match, but only for
* X-tiled. This is needed for FBC. */
if (!!(obj-tiling_mode == I915_TILING_X) !=
@@ -12790,6 +12803,14 @@ static int intel_framebuffer_init(struct drm_device
*dev,
DRM_DEBUG(tiling_mode doesn't match fb modifier\n);
return -EINVAL;
}
+
+ if (INTEL_INFO(dev)-gen 9
+ (mode_cmd-modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ mode_cmd-modifier[0] == I915_FORMAT_MOD_Yf_TILED)) {
+ DRM_DEBUG(Unsupported tiling 0x%llx!\n,
+ mode_cmd-modifier[0]);
+ return -EINVAL;
+ }
} else {
if (obj-tiling_mode == I915_TILING_X)
mode_cmd-modifier[0] = I915_FORMAT_MOD_X_TILED;
@@ -12799,11 +12820,6 @@ static int intel_framebuffer_init(struct drm_device
*dev,
}
}
- if (mode_cmd-modifier[0] == I915_FORMAT_MOD_Y_TILED) {
- DRM_DEBUG(hardware does not support tiling Y\n);
- return -EINVAL;
- }
My idea was actually to put the switch here (reduces one indent level) and
put the per-gen stuff into the switch statement too. I.e.
/* Passed in modifier sanity checking. */
switch (mode_cmd-modifier[0]) {
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
if (INTEL_INFO(dev)-gen 9) {
DRM_DEBUG(Unsupported tiling 0x%llx!\n,
mode_cmd-modifier[0]);
return -EINVAL;
}
case DRM_FORMAT_MOD_NONE:
case I915_FORMAT_MOD_X_TILED:
break;
default:
DRM_ERROR(Unsupported fb modifier 0x%llx!\n,
mode_cmd-modifier[0]);
return -EINVAL;
}
That gives us a natural place for extensions later on if we need to add
more special cases.
-Daniel
-
stride_alignment = intel_fb_stride_alignment(dev, mode_cmd-modifier[0],
mode_cmd-pixel_format);
if (mode_cmd-pitches[0] (stride_alignment - 1)) {
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] eDP display control registers in Linux kernel
Note to anyone else who might try this (I sent someone this way from IRC
who was also wondering the same thing about the XPS 13), these patches
don't apply to 4.0-rc1 since they're missing DP_EDP_DPCD_REV (and maybe
some other things, haven't dug in thoroughly yet). Also that patch doesn't
quite apply on top - just the line number is off, though.
Going to try on drm-intel-nightly 2015y-02m-25d-15h-57m-20s
(04996479ce17b980351d69de817e4432134121cd).
- Michael
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 81d40a3..0af59d0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4673,6 +4673,9 @@ static const struct dpcd_block i915_dpcd_debug[] = {
{ .offset = DP_SINK_COUNT, .end = DP_ADJUST_REQUEST_LANE2_3 },
{ .offset = DP_SET_POWER },
{ .offset = DP_EDP_DPCD_REV },
+{ .offset = 0x701, .end = 0x704 },
+{ .offset = 0x720, .end = 0x72f },
+{ .offset = 0x732, .end = 0x733 },
};
static int i915_dpcd_show(struct seq_file *m, void *data)
___
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: Use the CRC gpio_chip for panel enable/disable
On Wed, Feb 18, 2015 at 9:18 PM, Shobhit Kumar shobhit.ku...@intel.com wrote:
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 35 +--
drivers/gpu/drm/i915/intel_dsi.h | 11 +++
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index c8c8b24..6b56ca0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -31,6 +31,7 @@
#include drm/drm_panel.h
#include drm/drm_mipi_dsi.h
#include linux/slab.h
+#include linux/gpio.h
#include i915_drv.h
#include intel_drv.h
#include intel_dsi.h
@@ -415,6 +416,13 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ /* Panel Enable over CRC PMIC if needed */
+ if (dev_priv-vbt.dsi.config-pwm_blc == PPS_BLC_PMIC)
+ gpio_set_value_cansleep(
+ intel_dsi-crc_base + GPIO_PANEL_EN, 1);
+
+ msleep(intel_dsi-panel_on_delay);
+
/* Disable DPOunit clock gating, can stall pipe
* and we need DPLL REFA always enabled */
tmp = I915_READ(DPLL(pipe));
@@ -432,8 +440,6 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
/* put device in ready state */
intel_dsi_device_ready(encoder);
- msleep(intel_dsi-panel_on_delay);
-
drm_panel_prepare(intel_dsi-panel);
for_each_dsi_port(port, intel_dsi-ports)
@@ -576,6 +582,11 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder)
msleep(intel_dsi-panel_off_delay);
msleep(intel_dsi-panel_pwr_cycle_delay);
+
+ /* Panel Disable over CRC PMIC if needed */
+ if (dev_priv-vbt.dsi.config-pwm_blc == PPS_BLC_PMIC)
+ gpio_set_value_cansleep(
+ intel_dsi-crc_base + GPIO_PANEL_EN, 0);
}
static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
@@ -977,6 +988,12 @@ static const struct drm_connector_funcs
intel_dsi_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
+static int match_gpio_chip_by_label(struct gpio_chip *chip,
+ void *data)
+{
+ return !strcmp(chip-label, data);
+}
+
void intel_dsi_init(struct drm_device *dev)
{
struct intel_dsi *intel_dsi;
@@ -1070,6 +1087,20 @@ void intel_dsi_init(struct drm_device *dev)
goto err;
}
+ /*
+* In case of BYT with CRC PMIC, we need to use GPIO for
+* Panel control. Store the GPIO base
+*/
+ if (dev_priv-vbt.dsi.config-pwm_blc == PPS_BLC_PMIC) {
+ struct gpio_chip *gpio;
+ gpio = gpiochip_find(GPIO_CHIP_NAME,
match_gpio_chip_by_label);
+ if (!gpio) {
+ printk(Failed to find crc gpio chip\n);
+ intel_dsi-crc_base = 0;
+ } else
+ intel_dsi-crc_base = gpio-base;
+ }
This looks terribly wrong - you lookup a particular GPIO chip by name,
use a forged GPIO number without even requesting it, and are using
deprecated functions.
Please use the GPIO descriptor interface when adding new GPIO code,
see Documentation/gpio/consumer.h. The integer-based GPIO interface is
considered deprecated and should not be used for new code.
Using gpiod_* functions will prevent you from doing the other mistakes
I mentioned, since it forces you to request your GPIO properly and
will not allow you to forge a descriptor.
See also Documentation/gpio/board.txt for how you can associate GPIOs
to your device's functions depending on which firmware your platform
is using.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] eDP display control registers in Linux kernel
Okay, here's the results: : 12 0a 02 41 00 00 00 00 00 00 00 00 00 0b 00 0070: 01 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100: 0a 02 00 09 09 00 00 00 01 00 00 0200: 01 00 77 00 01 01 55 00 0600: 01 0700: 02 0701: 88 40 00 00 0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0732: 00 00 If I read that right, it looks like it is dynamic backlight capable - 0x702 | (1 6). Let me know if you need anything else, like if you have control code to test. I don't have much time to work on it myself at the moment but am happy to test kernels. -- Michael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Complete moving rotation property to core
For both patches:
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
On Thu, Feb 26, 2015 at 01:49:17PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Commit 1da30627fc511a57c9bd23a02c97f0576379f761 drm: Add rotation value to
plane state moved the rotation property to DRM core but only did the set
property part. This does the get property part as well.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 321e098..7ca54cb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -450,6 +450,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state-src_w;
} else if (property == config-prop_src_h) {
*val = state-src_h;
+ } else if (property == config-rotation_property) {
+ *val = state-rotation;
} else if (plane-funcs-atomic_get_property) {
return plane-funcs-atomic_get_property(plane, state,
property, val);
} else {
--
2.3.0
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Modifying RC6 Promotion timer for Media workloads.
From: Deepak S deepa...@linux.intel.com
In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in C6
in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0 transition
delays can result in performance impact
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 15 +
drivers/gpu/drm/i915/intel_pm.c| 35 ++
5 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1dd8bc..e33bf0d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1160,6 +1160,9 @@ struct intel_gen6_power_mgmt {
* Must be taken after struct_mutex if nested.
*/
struct mutex hw_lock;
+
+ /* Delayed work to adjust RC6 promotion timer */
+ struct delayed_work vlv_media_timeout_work;
};
/* defined intel_pm.c */
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 85a6ada..81f4066 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1272,6 +1272,21 @@ i915_gem_ringbuffer_submission(struct drm_device *dev,
struct drm_file *file,
i915_gem_execbuffer_move_to_active(vmas, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
+ /* For vlv/chv, modify RC6 promotion timer upon hitting Media workload
only
+* This will help in better power savings with media scenarios.
+*/
+ if (((args-flags I915_EXEC_RING_MASK) == I915_EXEC_BSD)
+ IS_VALLEYVIEW(dev) dev_priv-rps.enabled) {
+
+ vlv_modify_rc6_promotion_timer(dev_priv, true);
+
+ /* Start a timer for 1 sec to reset this value to original */
+ mod_delayed_work(dev_priv-wq,
+ dev_priv-rps.vlv_media_timeout_work,
+ msecs_to_jiffies(1000));
+
+ }
+
error:
kfree(cliprects);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1fb1529..000f2a6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1234,6 +1234,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */);
+void vlv_modify_rc6_promotion_timer(struct drm_i915_private *dev_priv,
+ bool media_active);
/* intel_sdvo.c */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fcb074b..5f495e73 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -716,6 +716,21 @@ int intel_execlists_submission(struct drm_device *dev,
struct drm_file *file,
i915_gem_execbuffer_move_to_active(vmas, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
+ /*
+* CHV: Extend RC6 promotion timer upon hitting Media workload to help
+* increase power savings with media scenarios.
+*/
+ if (((args-flags I915_EXEC_RING_MASK) == I915_EXEC_BSD)
+ IS_CHERRYVIEW(dev_priv-dev) dev_priv-rps.enabled) {
+
+ vlv_modify_rc6_promotion_timer(dev_priv, true);
+
+ /* Start a timer for 1 sec to reset this value to original */
+ mod_delayed_work(dev_priv-wq,
+ dev_priv-rps.vlv_media_timeout_work,
+ msecs_to_jiffies(1000));
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e8bd9b9..7716be9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3941,6 +3941,9 @@ static void cherryview_disable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ /* Cancel any pending work-item */
+ cancel_delayed_work_sync(dev_priv-rps.vlv_media_timeout_work);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
}
@@ -3952,6 +3955,9 @@ static void valleyview_disable_rps(struct drm_device *dev)
* This what the BIOS expects when going into suspend */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ /* Cancel any pending work-item */
+ cancel_delayed_work_sync(dev_priv-rps.vlv_media_timeout_work);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
@@ -4857,6 +4863,32 @@ static void cherryview_enable_rps(struct drm_device *dev)
[Intel-gfx] [PATCH 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4badb23..b88b7b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1193,11 +1193,13 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool force_on)
int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
- WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
- if (force_on) {
+ if (force_on !IS_CHERRYVIEW(dev_priv-dev)) {
+ /* WARN_ON only for the Valleyview */
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/chv: Set min freq to efficient frequency on chv
From: Deepak S deepa...@linux.intel.com After feedback from the hardware team, now we set the GPU min freq to RPe. If we drop the freq to RPn, we found that the punit was not setting the voltage to Vnn, So recommendation is to set min freq to RPe. Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 90cb6c9..e8bd9b9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4755,7 +4755,7 @@ static void cherryview_init_gt_powersave(struct drm_device *dev) dev_priv-rps.max_freq_softlimit = dev_priv-rps.max_freq; if (dev_priv-rps.min_freq_softlimit == 0) - dev_priv-rps.min_freq_softlimit = dev_priv-rps.min_freq; + dev_priv-rps.min_freq_softlimit = dev_priv-rps.efficient_freq; mutex_unlock(dev_priv-rps.hw_lock); } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Re-adjusting rc6 promotional timer for chv
From: Deepak S deepa...@linux.intel.com After feedback from the hardware team we are changing the RC6 promotional timer to increase the power saving without changing performance. Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 7dcb5b6..90cb6c9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4799,8 +4799,8 @@ static void cherryview_enable_rps(struct drm_device *dev) I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10); I915_WRITE(GEN6_RC_SLEEP, 0); - /* TO threshold set to 1750 us ( 0x557 * 1.28 us) */ - I915_WRITE(GEN6_RC6_THRESHOLD, 0x557); + /* TO threshold set to 500 us ( 0x186 * 1.28 us) */ + I915_WRITE(GEN6_RC6_THRESHOLD, 0x186); /* allows RC6 residency counter to work */ I915_WRITE(VLV_COUNTER_CONTROL, -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Setup static bias for GPU
From: Deepak S deepa...@linux.intel.com
Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55143cb..dd776df 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -662,6 +662,11 @@ enum skl_disp_power_wells {
#define FB_FMAX_VMIN_FREQ_LO_SHIFT 27
#define FB_FMAX_VMIN_FREQ_LO_MASK0xf800
+#define VLV_IOSFB_RPS_OVERRIDE 0x04
+#define VLV_OVERRIDE_RPS_MASK 1
+#define VLV_ENABLE_BIAS_SHARE (1 1)
+#define VLV_BIAS_VAL (6 2)
+
#define VLV_CZ_CLOCK_TO_MILLI_SEC 10
#define VLV_RP_UP_EI_THRESHOLD 90
#define VLV_RP_DOWN_EI_THRESHOLD 70
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7716be9..5bbb047 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4841,6 +4841,12 @@ static void cherryview_enable_rps(struct drm_device *dev)
GEN6_RP_UP_BUSY_AVG |
GEN6_RP_DOWN_IDLE_AVG);
+ /* Setting Fixed Bias */
+ val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+ vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
/* RPS code assumes GPLL is used */
@@ -4951,6 +4957,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
+ /* Setting Fixed Bias */
+ val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+ vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
/* RPS code assumes GPLL is used */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 05/32] drm/i915: Track GEN6 page table usage
Michel Thierry michel.thie...@intel.com writes:
From: Ben Widawsky benjamin.widaw...@intel.com
Instead of implementing the full tracking + dynamic allocation, this
patch does a bit less than half of the work, by tracking and warning on
unexpected conditions. The tracking itself follows which PTEs within a
page table are currently being used for objects. The next patch will
modify this to actually allocate the page tables only when necessary.
With the current patch there isn't much in the way of making a gen
agnostic range allocation function. However, in the next patch we'll add
more specificity which makes having separate functions a bit easier to
manage.
One important change introduced here is that DMA mappings are
created/destroyed at the same page directories/tables are
allocated/deallocated.
Notice that aliasing PPGTT is not managed here. The patch which actually
begins dynamic allocation/teardown explains the reasoning for this.
v2: s/pdp.page_directory/pdp.page_directorys
Make a scratch page allocation helper
v3: Rebase and expand commit message.
v4: Allocate required pagetables only when it is needed, _bind_to_vm
instead of bind_vma (Daniel).
v5: Rebased to remove the unnecessary noise in the diff, also:
- PDE mask is GEN agnostic, renamed GEN6_PDE_MASK to I915_PDE_MASK.
- Removed unnecessary checks in gen6_alloc_va_range.
- Changed map/unmap_px_single macros to use dma functions directly and
be part of a static inline function instead.
- Moved drm_device plumbing through page tables operation to its own
patch.
- Moved allocate/teardown_va_range calls until they are fully
implemented (in subsequent patch).
- Merged pt and scratch_pt unmap_and_free path.
- Moved scratch page allocator helper to the patch that will use it.
v6: Reduce complexity by not tearing down pagetables dynamically, the
same can be achieved while freeing empty vms. (Daniel)
v7: s/i915_dma_map_px_single/i915_dma_map_single
s/gen6_write_pdes/gen6_write_pde
Prevent a NULL case when only GGTT is available. (Mika)
v8: Rebased after s/page_tables/page_table/.
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Mika Kuoppala mika.kuopp...@linux.intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v3+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 198
+---
drivers/gpu/drm/i915/i915_gem_gtt.h | 75 ++
2 files changed, 211 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e05488e..f9354c7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -278,29 +278,88 @@ static gen6_gtt_pte_t iris_pte_encode(dma_addr_t addr,
return pte;
}
-static void unmap_and_free_pt(struct i915_page_table_entry *pt, struct
drm_device *dev)
+#define i915_dma_unmap_single(px, dev) \
+ __i915_dma_unmap_single((px)-daddr, dev)
+
+static inline void __i915_dma_unmap_single(dma_addr_t daddr,
+ struct drm_device *dev)
+{
+ struct device *device = dev-pdev-dev;
+
+ dma_unmap_page(device, daddr, 4096, PCI_DMA_BIDIRECTIONAL);
+}
+
+/**
+ * i915_dma_map_single() - Create a dma mapping for a page table/dir/etc.
+ * @px: Page table/dir/etc to get a DMA map for
+ * @dev: drm device
+ *
+ * Page table allocations are unified across all gens. They always require a
+ * single 4k allocation, as well as a DMA mapping. If we keep the structs
+ * symmetric here, the simple macro covers us for every page table type.
+ *
+ * Return: 0 if success.
+ */
+#define i915_dma_map_single(px, dev) \
+ i915_dma_map_page_single((px)-page, (dev), (px)-daddr)
+
+static inline int i915_dma_map_page_single(struct page *page,
+struct drm_device *dev,
+dma_addr_t *daddr)
+{
+ struct device *device = dev-pdev-dev;
+
+ *daddr = dma_map_page(device, page, 0, 4096, PCI_DMA_BIDIRECTIONAL);
+ return dma_mapping_error(device, *daddr);
+}
+
+static void unmap_and_free_pt(struct i915_page_table_entry *pt,
+struct drm_device *dev)
{
if (WARN_ON(!pt-page))
return;
+
+ i915_dma_unmap_single(pt, dev);
__free_page(pt-page);
+ kfree(pt-used_ptes);
kfree(pt);
}
static struct i915_page_table_entry *alloc_pt_single(struct drm_device *dev)
{
struct i915_page_table_entry *pt;
+ const size_t count = INTEL_INFO(dev)-gen = 8 ?
+ GEN8_PTES_PER_PAGE : I915_PPGTT_PT_ENTRIES;
+ int ret = -ENOMEM;
pt = kzalloc(sizeof(*pt), GFP_KERNEL);
if (!pt)
return ERR_PTR(-ENOMEM);
+ pt-used_ptes = kcalloc(BITS_TO_LONGS(count), sizeof(*pt-used_ptes),
+ GFP_KERNEL);
+
+ if
[Intel-gfx] [PATCH i-g-t] tests/drv_suspend: Unrename tests
Renaming tests massively confuses QA's test result tracking and blacklisting. So except when really good reasons are around we shouldn't do it. Here I think just adding the -hibernat suffix and leaving test names unchanged is enough. Cc: David Weinehall david.weineh...@intel.com Cc: Imre Deak imre.d...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- tests/drv_suspend.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/drv_suspend.c b/tests/drv_suspend.c index e61a72341c11..955c294cc00a 100644 --- a/tests/drv_suspend.c +++ b/tests/drv_suspend.c @@ -184,19 +184,19 @@ igt_main igt_fixture fd = drm_open_any(); - igt_subtest(fence-restore-tiled2untiled-suspend) + igt_subtest(fence-restore-tiled2untiled) test_fence_restore(fd, true, false); - igt_subtest(fence-restore-untiled-suspend) + igt_subtest(fence-restore-untiled) test_fence_restore(fd, false, false); - igt_subtest(debugfs-reader-suspend) + igt_subtest(debugfs-reader) test_debugfs_reader(false); - igt_subtest(sysfs-reader-suspend) + igt_subtest(sysfs-reader) test_sysfs_reader(false); - igt_subtest(forcewake-suspend) + igt_subtest(forcewake) test_forcewake(false); igt_subtest(fence-restore-tiled2untiled-hibernate) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off
On Thu, Feb 26, 2015 at 08:46:54PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Do we need the force clock at all since we don't do any gunit register
save/restore? I tried to peddle a patch to remove it totally in this bug
report, but never got any decent answer back:
https://bugs.freedesktop.org/show_bug.cgi?id=87086
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4badb23..b88b7b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1193,11 +1193,13 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool force_on)
int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
- WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
- if (force_on) {
+ if (force_on !IS_CHERRYVIEW(dev_priv-dev)) {
+ /* WARN_ON only for the Valleyview */
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
--
1.9.1
--
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: Add media rc6 residency file to sysfs
From: Ville Syrjälä ville.syrj...@linux.intel.com
On VLV/CHV the media well rc6 residency gets reported separately
from the render well, so add another file to sysfs so that we can
report the residency to the user.
Testcase: igt/pm_rc6_residency --run-subtest media-rc6-accuracy
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_sysfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index cdc9da0..1f269e0 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -127,10 +127,19 @@ show_rc6pp_ms(struct device *kdev, struct
device_attribute *attr, char *buf)
return snprintf(buf, PAGE_SIZE, %u\n, rc6pp_residency);
}
+static ssize_t
+show_media_rc6_ms(struct device *kdev, struct device_attribute *attr, char
*buf)
+{
+ struct drm_minor *dminor = dev_get_drvdata(kdev);
+ u32 rc6_residency = calc_residency(dminor-dev, VLV_GT_MEDIA_RC6);
+ return snprintf(buf, PAGE_SIZE, %u\n, rc6_residency);
+}
+
static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
static DEVICE_ATTR(rc6_residency_ms, S_IRUGO, show_rc6_ms, NULL);
static DEVICE_ATTR(rc6p_residency_ms, S_IRUGO, show_rc6p_ms, NULL);
static DEVICE_ATTR(rc6pp_residency_ms, S_IRUGO, show_rc6pp_ms, NULL);
+static DEVICE_ATTR(media_rc6_residency_ms, S_IRUGO, show_media_rc6_ms, NULL);
static struct attribute *rc6_attrs[] = {
dev_attr_rc6_enable.attr,
@@ -153,6 +162,16 @@ static struct attribute_group rc6p_attr_group = {
.name = power_group_name,
.attrs = rc6p_attrs
};
+
+static struct attribute *media_rc6_attrs[] = {
+ dev_attr_media_rc6_residency_ms.attr,
+ NULL
+};
+
+static struct attribute_group media_rc6_attr_group = {
+ .name = power_group_name,
+ .attrs = media_rc6_attrs
+};
#endif
static int l3_access_valid(struct drm_device *dev, loff_t offset)
@@ -627,6 +646,12 @@ void i915_setup_sysfs(struct drm_device *dev)
if (ret)
DRM_ERROR(RC6p residency sysfs setup failed\n);
}
+ if (IS_VALLEYVIEW(dev)) {
+ ret = sysfs_merge_group(dev-primary-kdev-kobj,
+ media_rc6_attr_group);
+ if (ret)
+ DRM_ERROR(Media RC6 residency sysfs setup failed\n);
+ }
#endif
if (HAS_L3_DPF(dev)) {
ret = device_create_bin_file(dev-primary-kdev, dpf_attrs);
--
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] tests/pm_rc6_residency: Add media_rc6_residency_counter subtest
From: Deepak S deepa...@linux.intel.com
Added new media_rc6_residency_subtest for chv vlv.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
tests/pm_rc6_residency.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index 1600ac3..f6152da 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -135,7 +135,7 @@ igt_main
{
int fd;
int devid = 0;
- int rc6[2], rc6p[2], rc6pp[2];
+ int rc6[2], rc6p[2], rc6pp[2], media[2];
igt_skip_on_simulation();
@@ -146,6 +146,9 @@ igt_main
close(fd);
read_rc6_residency(rc6, rc6);
+ if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid))
+ read_rc6_residency(media, media_rc6);
+
if (IS_GEN6(devid) || IS_IVYBRIDGE(devid)) {
read_rc6_residency(rc6p, rc6p);
read_rc6_residency(rc6pp, rc6pp);
@@ -154,6 +157,9 @@ igt_main
igt_subtest(rc6-accuracy)
residency_accuracy(rc6, rc6);
+ igt_subtest(media-rc6-accuracy)
+ if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid))
+ residency_accuracy(media, media_rc6);
igt_subtest(rc6p-accuracy) {
if (!IS_GEN6(devid) !IS_IVYBRIDGE(devid))
igt_skip(This platform doesn't support RC6p\n);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] tests/pm_rc6_residency: Fix proper residency calculation
From: Deepak S deepa...@linux.intel.com
With current code we are not considering the RC6 residency during sysfs
read. This is causing test to fail due to incorrect residency_accuracy check
This patch consider code time spent for accuracy check
Signed-off-by: Deepak S deepa...@linux.intel.com
---
tests/pm_rc6_residency.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index 2658a89..1600ac3 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -37,6 +37,7 @@
#define SLEEP_DURATION 3000 // in milliseconds
#define RC6_FUDGE 900 // in milliseconds
+#define CODE_TIME 50 // in microseconfs
static unsigned int readit(const char *path)
{
@@ -102,7 +103,7 @@ static void residency_accuracy(int value[],const char
*name_of_rc6_residency)
the GPU is as idle as
possible(ie. no X,
running and running no
other tests)\n);
- counter = ((double)value[1] - (double)value[0]) /(double)
SLEEP_DURATION;
+ counter = ((double)value[1] - (double)value[0]) /(double)
(SLEEP_DURATION + CODE_TIME);
if( counter 0.9 ){
counter_result = counter;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off
On Thursday 26 February 2015 09:13 PM, Ville Syrjälä wrote:
On Thu, Feb 26, 2015 at 08:46:54PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Do we need the force clock at all since we don't do any gunit register
save/restore? I tried to peddle a patch to remove it totally in this bug
report, but never got any decent answer back:
https://bugs.freedesktop.org/show_bug.cgi?id=87086
hmm. your right we might not need. Let me confirm
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4badb23..b88b7b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1193,11 +1193,13 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool force_on)
int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
- WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
- if (force_on) {
+ if (force_on !IS_CHERRYVIEW(dev_priv-dev)) {
+ /* WARN_ON only for the Valleyview */
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Framebuffers need not be limited to 256MB on gen8+.
On Thu, Feb 26, 2015 at 09:01:52PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com The restriction of pinningFramebuffer to first 256MB is removed from gen8+. Removing the restriction so that FB can be pinned in any space within GTT/PPGTT. Also, for gen8+ no need to use pin_mappable for Framebuffer also we do not take fence as Framebuffer compression is not enabled. Not quite, the reason why we restrict the framebuffer to mappable was that certain display servers depend upon being able to GTT mmap the framebuffer for direct access. Thus they would crash if we found that the framebuffer was already pinned in an unreachable location. That legacy code is currently still able to run on gen8+ and so you need to have userspace request an ABI break... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915/skl: Allow Y (and Yf) frame buffer creation
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5826 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -2 281/281 279/281 ILK 308/308 308/308 SNB -1 326/326 325/326 IVB 380/380 380/380 BYT 294/294 294/294 HSW 387/421 387/421 BDW -1 316/316 315/316 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt_gem_userptr_blits_minor-normal-sync DMESG_WARN(3)PASS(1) DMESG_WARN(1)PASS(1) *PNV igt_gen3_render_tiledx_blits NO_RESULT(1)PASS(5) CRASH(1)PASS(1) SNB igt_kms_rotation_crc_primary-rotation DMESG_WARN(12)PASS(3) DMESG_WARN(1)PASS(1) *BDW igt_gem_gtt_hog PASS(12) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] CHV PM fix Improvements
From: Deepak S deepa...@linux.intel.com Adding few of PM fixes and Improvements for CHV/VLV. Deepak S (5): drm/i915/chv: Remove Wait for a previous gfx force-off drm/i915: Re-adjusting rc6 promotional timer for chv drm/i915/chv: Set min freq to efficient frequency on chv drm/i915: Modifying RC6 Promotion timer for Media workloads. drm/i915: Setup static bias for GPU drivers/gpu/drm/i915/i915_drv.c| 6 ++-- drivers/gpu/drm/i915/i915_drv.h| 3 ++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 + drivers/gpu/drm/i915/i915_reg.h| 5 +++ drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_lrc.c | 15 + drivers/gpu/drm/i915/intel_pm.c| 53 -- 7 files changed, 94 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: Framebuffers need not be limited to 256MB on gen8+.
From: Deepak S deepa...@linux.intel.com
The restriction of pinningFramebuffer to first 256MB is removed from gen8+.
Removing the restriction so that FB can be pinned in any space within
GTT/PPGTT. Also, for gen8+ no need to use pin_mappable for Framebuffer
also we do not take fence as Framebuffer compression is not enabled.
Signed-off-by: Satyanantha, Rama Gopal M rama.gopal.m.satyanan...@intel.com
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 9 +++--
drivers/gpu/drm/i915/intel_display.c | 11 +++
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 77a7315..c9f5b06 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3941,6 +3941,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
struct intel_engine_cs *pipelined)
{
u32 old_read_domains, old_write_domain;
+ struct drm_device *dev = obj-base.dev;
bool was_pin_display;
int ret;
@@ -3972,9 +3973,13 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
/* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
-* always use map_and_fenceable for all scanout buffers.
+* always use map_and_fenceable for all scanout buffers. No need
+* of map_fenceable for = gen8
*/
- ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
+ if ((INTEL_INFO(dev)-gen = 8))
+ ret = i915_gem_obj_ggtt_pin(obj, alignment, 0);
+ else
+ ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
if (ret)
goto err_unpin_display;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fad5f76..d3067be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2267,11 +2267,14 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
/* Install a fence for tiled scan-out. Pre-i965 always needs a
* fence, whereas 965+ only requires a fence if using
* framebuffer compression. For simplicity, we always install
-* a fence as the cost is not that onerous.
+* a fence as the cost is not that onerous. Fence is only required
+* for gen 7 below
*/
- ret = i915_gem_object_get_fence(obj);
- if (ret)
- goto err_unpin;
+ if ((INTEL_INFO(dev)-gen = 7)) {
+ ret = i915_gem_object_get_fence(obj);
+ if (ret)
+ goto err_unpin;
+ }
i915_gem_object_pin_fence(obj);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling
On Wed, Feb 25, 2015 at 04:47:21PM +, Tvrtko Ursulin wrote:
From: Damien Lespiau damien.lesp...@intel.com
v2: Rebased for addfb2 interface and consolidated a bit. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Use intel_fb_stride_alignment instead of open coding. (Damien Lespiau)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com (v3)
Still looks good to me:
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
drivers/gpu/drm/i915/intel_display.c | 40
+---
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f262515..626e6538 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7732,7 +7732,7 @@ skylake_get_initial_plane_config(struct intel_crtc
*crtc,
{
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 val, base, offset, stride_mult;
+ u32 val, base, offset, stride_mult, tiling;
int pipe = crtc-pipe;
int fourcc, pixel_format;
int aligned_height;
@@ -7751,11 +7751,6 @@ skylake_get_initial_plane_config(struct intel_crtc
*crtc,
if (!(val PLANE_CTL_ENABLE))
goto error;
- if (val PLANE_CTL_TILED_MASK) {
- plane_config-tiling = I915_TILING_X;
- fb-modifier[0] = I915_FORMAT_MOD_X_TILED;
- }
-
pixel_format = val PLANE_CTL_FORMAT_MASK;
fourcc = skl_format_to_fourcc(pixel_format,
val PLANE_CTL_ORDER_RGBX,
@@ -7763,6 +7758,26 @@ skylake_get_initial_plane_config(struct intel_crtc
*crtc,
fb-pixel_format = fourcc;
fb-bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
+ tiling = val PLANE_CTL_TILED_MASK;
+ switch (tiling) {
+ case PLANE_CTL_TILED_LINEAR:
+ fb-modifier[0] = DRM_FORMAT_MOD_NONE;
+ break;
+ case PLANE_CTL_TILED_X:
+ plane_config-tiling = I915_TILING_X;
+ fb-modifier[0] = I915_FORMAT_MOD_X_TILED;
+ break;
+ case PLANE_CTL_TILED_Y:
+ fb-modifier[0] = I915_FORMAT_MOD_Y_TILED;
+ break;
+ case PLANE_CTL_TILED_YF:
+ fb-modifier[0] = I915_FORMAT_MOD_Yf_TILED;
+ break;
+ default:
+ MISSING_CASE(tiling);
+ goto error;
+ }
+
base = I915_READ(PLANE_SURF(pipe, 0)) 0xf000;
plane_config-base = base;
@@ -7773,17 +7788,8 @@ skylake_get_initial_plane_config(struct intel_crtc
*crtc,
fb-width = ((val 0) 0x1fff) + 1;
val = I915_READ(PLANE_STRIDE(pipe, 0));
- switch (plane_config-tiling) {
- case I915_TILING_NONE:
- stride_mult = 64;
- break;
- case I915_TILING_X:
- stride_mult = 512;
- break;
- default:
- MISSING_CASE(plane_config-tiling);
- goto error;
- }
+ stride_mult = intel_fb_stride_alignment(dev, fb-modifier[0],
+ fb-pixel_format);
fb-pitches[0] = (val 0x3ff) * stride_mult;
aligned_height = intel_fb_align_height(dev, fb-height,
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check for driver readyness before handling an underrun interrupt
When we takeover from the BIOS and install our interrupt handler, the
BIOS may have left us a few surprises in the form of spontaneous
interrupts. (This is especially likely on hardware like 965gm where
display fifo underruns are continuous and the GMCH cannot filter that
interrupt souce.) As we enable our IRQ early so that we can use it
during hardware probing, our interrupt handler must be prepared to
handle a few sources prior to being fully configured. As such, we need
to add a simple is-ready check prior to dereferencing our KMS state for
reporting underruns.
Reported-by: Rob Clark rcl...@redhat.com
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_fifo_underrun.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index 04e248dd2259..f2fd992e3cd8 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -282,16 +282,6 @@ bool intel_set_cpu_fifo_underrun_reporting(struct
drm_i915_private *dev_priv,
return ret;
}
-static bool
-__cpu_fifo_underrun_reporting_enabled(struct drm_i915_private *dev_priv,
- enum pipe pipe)
-{
- struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
- return !intel_crtc-cpu_fifo_underrun_disabled;
-}
-
/**
* intel_set_pch_fifo_underrun_reporting - set PCH fifo underrun reporting
state
* @dev_priv: i915 device instance
@@ -352,9 +342,15 @@ bool intel_set_pch_fifo_underrun_reporting(struct
drm_i915_private *dev_priv,
void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
+ struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
+
+ /* We may be called too early in init, thanks BIOS! */
+ if (crtc == NULL)
+ return;
+
/* GMCH can't disable fifo underruns, filter them. */
if (HAS_GMCH_DISPLAY(dev_priv-dev)
- !__cpu_fifo_underrun_reporting_enabled(dev_priv, pipe))
+ !to_intel_crtc(crtc)-cpu_fifo_underrun_disabled)
return;
if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false))
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/skl: Added new macros
On Thu, Feb 26, 2015 at 06:19:37PM +0530, akash.g...@intel.com wrote: +#define GT_INTERVAL_FROM_US(us) (IS_GEN9(dev_priv-dev) ? \ + INTERVAL_1_33_US(us) : \ + INTERVAL_1_28_US(us)) Just use IS_GEN9(dev_priv) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/dp: add DPCD definitions from eDP 1.2
On Thu, Feb 26, 2015 at 03:21:13PM +0530, sonika wrote: On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: Mostly display control related DPCD addresses. Signed-off-by: Jani Nikula jani.nik...@intel.com --- include/drm/drm_dp_helper.h | 32 1 file changed, 32 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 209c5b91b0e8..cc96024e8776 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -426,6 +426,38 @@ #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ +#define DP_EDP_GENERAL_CAP_10x701 + +#define DP_EDP_BACKLIGHT_ADJUSTMENT_CAP 0x702 + +#define DP_EDP_GENERAL_CAP_20x703 + +#define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 + +#define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 + +#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 +#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723 + +#define DP_EDP_PWMGEN_BIT_COUNT 0x724 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 + +#define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 + +#define DP_EDP_BACKLIGHT_FREQ_SET 0x728 + +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_LSB 0x72c + +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MSB 0x72d +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MID 0x72e +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB 0x72f + +#define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 +#define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 + #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ Checked against edp1.3 spec. Reviewed-by: Sonika Jindal sonika.jin...@intel.com Merged this and patch 1 to drm-misc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add missing description to parameter in alloc_pt_range
On Thu, Feb 26, 2015 at 11:28:13AM +, Michel Thierry wrote: The patch drm/i915: Plumb drm_device through page tables operations added an extra parameter, but it didn't update the function description. Also remove unnecessary blank line added by the same patch. Found by kbuild test robot. Signed-off-by: Michel Thierry michel.thie...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/dp: add DPCD definitions from eDP 1.4
On Thu, 26 Feb 2015, sonika sonika.jin...@intel.com wrote: On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: Signed-off-by: Jani Nikula jani.nik...@intel.com --- include/drm/drm_dp_helper.h | 37 + 1 file changed, 37 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index cc96024e8776..07d94faa9255 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -168,10 +168,18 @@ #define DP_AUD_DEL_INS20x02d /* End of AV_SYNC_DATA_BLOCK */ +#define DP_RECEIVER_ALPM_CAP0x02e /* eDP 1.4 */ +# define DP_ALPM_CAP(1 0) Yes, it is named ALPM_CAP in spec, but to me something like DP_ALPM_SUPPORTED makes more sense to me here. I would prefer to keep the same name as in the spec. In many places in the DPCD, _CAP refers to a capability, so I don't find it confusing. + +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP 0x02f /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_CAP (1 0) Same comment as above. Likewise. :) + #define DP_GUID0x030 /* 1.2 */ #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 +# define DP_PSR2_IS_SUPPORTED 2 /* eDP 1.4 */ + #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ # define DP_PSR_NO_TRAIN_ON_EXIT1 # define DP_PSR_SETUP_TIME_330 (0 1) @@ -211,6 +219,7 @@ /* link configuration */ #defineDP_LINK_BW_SET 0x100 +# define DP_LINK_RATE_TABLE 0x00/* eDP 1.4 */ # define DP_LINK_BW_1_62 0x06 # define DP_LINK_BW_2_70x0a # define DP_LINK_BW_5_40x14/* 1.2 */ @@ -309,15 +318,30 @@ #define DP_AUDIO_DELAY20x114 #define DP_LINK_RATE_SET 0x115 /* eDP 1.4 */ +# define DP_LINK_RATE_SET_SHIFT 0 +# define DP_LINK_RATE_SET_MASK (7 0) + +#define DP_RECEIVER_ALPM_CONFIG 0x116 /* eDP 1.4 */ +# define DP_ALPM_ENABLE (1 0) +# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE (1 1) + +#define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF 0x117 /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_ENABLE (1 0) +# define DP_IRQ_HPD_ENABLE (1 1) #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118 /* 1.2 */ # define DP_PWR_NOT_NEEDED (1 0) +#define DP_AUX_FRAME_SYNC_VALUE 0x15c /* eDP 1.4 */ +# define DP_AUX_FRAME_SYNC_VALID(1 0) + #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE (1 0) # define DP_PSR_MAIN_LINK_ACTIVE (1 1) # define DP_PSR_CRC_VERIFICATION (1 2) # define DP_PSR_FRAME_CAPTURE (1 3) +# define DP_PSR_SELECTIVE_UPDATE(1 4) +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 5) #define DP_ADAPTER_CTRL0x1a0 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 0) @@ -425,6 +449,10 @@ # define DP_SET_POWER_MASK 0x3 #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ +# define DP_EDP_11 0x00 +# define DP_EDP_12 0x01 +# define DP_EDP_13 0x02 +# define DP_EDP_14 0x03 #define DP_EDP_GENERAL_CAP_1 0x701 @@ -432,6 +460,8 @@ #define DP_EDP_GENERAL_CAP_2 0x703 +#define DP_EDP_GENERAL_CAP_30x704/* eDP 1.4 */ + #define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 #define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 @@ -458,6 +488,9 @@ #define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 #define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 +#define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ +#define DP_EDP_REGIONAL_BACKLIGHT_0 0x741/* eDP 1.4 */ + #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ @@ -476,6 +509,7 @@ #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 0) # define DP_PSR_RFB_STORAGE_ERROR (1 1) +# define DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR (1 2) /* eDP 1.4 */ #define DP_PSR_ESI 0x2007 /* XXX 1.2? */ # define DP_PSR_CAPS_CHANGE (1 0) @@ -489,6 +523,9 @@ # define DP_PSR_SINK_INTERNAL_ERROR 7 # define DP_PSR_SINK_STATE_MASK 0x07 +#define DP_RECEIVER_ALPM_STATUS
[Intel-gfx] [PATCH 2/8] drm/i915/skl: Updated intel_gpu_freq() and intel_freq_opcode()
From: Akash Goel akash.g...@intel.com
On SKL, frequency is specified in units of 16.66 MHZ.
Updated the intel_gpu_freq() and intel_freq_opecode() functions
to do the conversion appropriately.
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7dcb5b6..1b36d0e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6660,7 +6660,9 @@ static int chv_freq_opcode(struct drm_i915_private
*dev_priv, int val)
int intel_gpu_freq(struct drm_i915_private *dev_priv, int val)
{
- if (IS_CHERRYVIEW(dev_priv-dev))
+ if (IS_GEN9(dev_priv-dev))
+ return (val * GT_FREQUENCY_MULTIPLIER) / GEN9_FREQ_SCALER;
+ else if (IS_CHERRYVIEW(dev_priv-dev))
return chv_gpu_freq(dev_priv, val);
else if (IS_VALLEYVIEW(dev_priv-dev))
return byt_gpu_freq(dev_priv, val);
@@ -6670,7 +6672,9 @@ int intel_gpu_freq(struct drm_i915_private *dev_priv, int
val)
int intel_freq_opcode(struct drm_i915_private *dev_priv, int val)
{
- if (IS_CHERRYVIEW(dev_priv-dev))
+ if (IS_GEN9(dev_priv-dev))
+ return (val * GEN9_FREQ_SCALER) / GT_FREQUENCY_MULTIPLIER;
+ else if (IS_CHERRYVIEW(dev_priv-dev))
return chv_freq_opcode(dev_priv, val);
else if (IS_VALLEYVIEW(dev_priv-dev))
return byt_freq_opcode(dev_priv, val);
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915/skl: Updated the i915_frequency_info debugfs function
From: Akash Goel akash.g...@intel.com
Added support for SKL in the i915_frequency_info debugfs function
v2:
- corrected the handling of reqf (Damien)
- Reorderd the platform check for cagf (Ville)
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3e1e5d3..7bd79d7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1089,7 +1089,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
seq_printf(m, Current P-state: %d\n,
(rgvstat MEMSTAT_PSTATE_MASK)
MEMSTAT_PSTATE_SHIFT);
} else if (IS_GEN6(dev) || (IS_GEN7(dev) !IS_VALLEYVIEW(dev)) ||
- IS_BROADWELL(dev)) {
+ IS_BROADWELL(dev) || IS_GEN9(dev)) {
u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
@@ -1108,11 +1108,15 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
reqf = I915_READ(GEN6_RPNSWREQ);
- reqf = ~GEN6_TURBO_DISABLE;
- if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- reqf = 24;
- else
- reqf = 25;
+ if (IS_GEN9(dev))
+ reqf = 23;
+ else {
+ reqf = ~GEN6_TURBO_DISABLE;
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ reqf = 24;
+ else
+ reqf = 25;
+ }
reqf = intel_gpu_freq(dev_priv, reqf);
rpmodectl = I915_READ(GEN6_RP_CONTROL);
@@ -1126,7 +1130,9 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
rpdownei = I915_READ(GEN6_RP_CUR_DOWN_EI);
rpcurdown = I915_READ(GEN6_RP_CUR_DOWN);
rpprevdown = I915_READ(GEN6_RP_PREV_DOWN);
- if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ if (IS_GEN9(dev))
+ cagf = (rpstat GEN9_CAGF_MASK) GEN9_CAGF_SHIFT;
+ else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
cagf = (rpstat HSW_CAGF_MASK) HSW_CAGF_SHIFT;
else
cagf = (rpstat GEN6_CAGF_MASK) GEN6_CAGF_SHIFT;
@@ -1152,7 +1158,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
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);
+ (gt_perf_status (IS_GEN9(dev) ? 0x1ff00 : 0xff00))
8);
seq_printf(m, Render p-state VID: %d\n,
gt_perf_status 0xff);
seq_printf(m, Render p-state limit: %d\n,
@@ -1177,14 +1183,17 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
GEN6_CURBSYTAVG_MASK);
max_freq = (rp_state_cap 0xff) 16;
+ max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
seq_printf(m, Lowest (RPN) frequency: %dMHz\n,
intel_gpu_freq(dev_priv, max_freq));
max_freq = (rp_state_cap 0xff00) 8;
+ max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
seq_printf(m, Nominal (RP1) frequency: %dMHz\n,
intel_gpu_freq(dev_priv, max_freq));
max_freq = rp_state_cap 0xff;
+ max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
seq_printf(m, Max non-overclocked (RP0) frequency: %dMHz\n,
intel_gpu_freq(dev_priv, max_freq));
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/skl: Restructured the gen6_set_rps_thresholds function
From: Akash Goel akash.g...@intel.com
Prior to SKL, the time period programmed in Up/Down EI Up/Down
threshold registers was in units of 1.28 micro seconds. But for
SKL, the units have changed (1.333 micro seconds).
Have generalized the implementation of gen6_set_rps_thresholds function,
by removing the hard coding done in it as per 1.28 micro seconds.
v2: Renamed the local variables removed superfluous comments (Chris)
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 68 +++--
1 file changed, 32 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 339a034..e094e5d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3677,6 +3677,8 @@ static u32 gen6_rps_limits(struct drm_i915_private
*dev_priv, u8 val)
static void gen6_set_rps_thresholds(struct drm_i915_private *dev_priv, u8 val)
{
int new_power;
+ u32 threshold_up = 0, threshold_down = 0; /* in % */
+ u32 ei_up = 0, ei_down = 0;
new_power = dev_priv-rps.power;
switch (dev_priv-rps.power) {
@@ -3709,59 +3711,53 @@ static void gen6_set_rps_thresholds(struct
drm_i915_private *dev_priv, u8 val)
switch (new_power) {
case LOW_POWER:
/* Upclock if more than 95% busy over 16ms */
- I915_WRITE(GEN6_RP_UP_EI, 12500);
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 11800);
+ ei_up = 16000;
+ threshold_up = 95;
/* Downclock if less than 85% busy over 32ms */
- I915_WRITE(GEN6_RP_DOWN_EI, 25000);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 21250);
-
- I915_WRITE(GEN6_RP_CONTROL,
- GEN6_RP_MEDIA_TURBO |
- GEN6_RP_MEDIA_HW_NORMAL_MODE |
- GEN6_RP_MEDIA_IS_GFX |
- GEN6_RP_ENABLE |
- GEN6_RP_UP_BUSY_AVG |
- GEN6_RP_DOWN_IDLE_AVG);
+ ei_down = 32000;
+ threshold_down = 85;
break;
case BETWEEN:
/* Upclock if more than 90% busy over 13ms */
- I915_WRITE(GEN6_RP_UP_EI, 10250);
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 9225);
+ ei_up = 13000;
+ threshold_up = 90;
/* Downclock if less than 75% busy over 32ms */
- I915_WRITE(GEN6_RP_DOWN_EI, 25000);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 18750);
-
- I915_WRITE(GEN6_RP_CONTROL,
- GEN6_RP_MEDIA_TURBO |
- GEN6_RP_MEDIA_HW_NORMAL_MODE |
- GEN6_RP_MEDIA_IS_GFX |
- GEN6_RP_ENABLE |
- GEN6_RP_UP_BUSY_AVG |
- GEN6_RP_DOWN_IDLE_AVG);
+ ei_down = 32000;
+ threshold_down = 75;
break;
case HIGH_POWER:
/* Upclock if more than 85% busy over 10ms */
- I915_WRITE(GEN6_RP_UP_EI, 8000);
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 6800);
+ ei_up = 1;
+ threshold_up = 85;
/* Downclock if less than 60% busy over 32ms */
- I915_WRITE(GEN6_RP_DOWN_EI, 25000);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 15000);
-
- I915_WRITE(GEN6_RP_CONTROL,
- GEN6_RP_MEDIA_TURBO |
- GEN6_RP_MEDIA_HW_NORMAL_MODE |
- GEN6_RP_MEDIA_IS_GFX |
- GEN6_RP_ENABLE |
- GEN6_RP_UP_BUSY_AVG |
- GEN6_RP_DOWN_IDLE_AVG);
+ ei_down = 32000;
+ threshold_down = 60;
break;
}
+ I915_WRITE(GEN6_RP_UP_EI,
+ GT_INTERVAL_FROM_US(ei_up));
+ I915_WRITE(GEN6_RP_UP_THRESHOLD,
+ GT_INTERVAL_FROM_US((ei_up * threshold_up / 100)));
+
+ I915_WRITE(GEN6_RP_DOWN_EI,
+ GT_INTERVAL_FROM_US(ei_down));
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD,
+ GT_INTERVAL_FROM_US((ei_down * threshold_down / 100)));
+
+I915_WRITE(GEN6_RP_CONTROL,
+ GEN6_RP_MEDIA_TURBO |
+ GEN6_RP_MEDIA_HW_NORMAL_MODE |
+ GEN6_RP_MEDIA_IS_GFX |
+ GEN6_RP_ENABLE |
+ GEN6_RP_UP_BUSY_AVG |
+ GEN6_RP_DOWN_IDLE_AVG);
+
dev_priv-rps.power = new_power;
dev_priv-rps.last_adj = 0;
}
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915/skl: Added new macros
From: Akash Goel akash.g...@intel.com
For SKL, register definition for RPNSWREQ (A008), RPSTAT1(A01C)
have changed slightly. Also on SKL, frequency is specified in
units of 16.66 MHZ, compared to 50 MHZ for most of the earlier
platforms and the time values are expressed in units of 1.33 us,
compared to 1.28 us for earlier platforms.
Added new macros for the aforementioned changes.
v2: Renamed the GT_FREQ_FROM_PERIOD macro to GT_INTERVAL_FROM_US (Damien)
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d42040f..73b49d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2523,6 +2523,7 @@ struct drm_i915_cmd_table {
#define NUM_L3_SLICES(dev) (IS_HSW_GT3(dev) ? 2 : HAS_L3_DPF(dev))
#define GT_FREQUENCY_MULTIPLIER 50
+#define GEN9_FREQ_SCALER 3
#include i915_trace.h
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55143cb..278b7be 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2427,6 +2427,12 @@ enum skl_disp_power_wells {
#define GEN6_RP_STATE_LIMITS (MCHBAR_MIRROR_BASE_SNB + 0x5994)
#define GEN6_RP_STATE_CAP (MCHBAR_MIRROR_BASE_SNB + 0x5998)
+#define INTERVAL_1_28_US(us) (((us) * 100) 7)
+#define INTERVAL_1_33_US(us) (((us) * 3)2)
+#define GT_INTERVAL_FROM_US(us) (IS_GEN9(dev_priv-dev) ? \
+ INTERVAL_1_33_US(us) : \
+ INTERVAL_1_28_US(us))
+
/*
* Logical Context regs
*/
@@ -6080,6 +6086,7 @@ enum skl_disp_power_wells {
#define GEN6_TURBO_DISABLE (131)
#define GEN6_FREQUENCY(x)((x)25)
#define HSW_FREQUENCY(x) ((x)24)
+#define GEN9_FREQUENCY(x)((x)23)
#define GEN6_OFFSET(x) ((x)19)
#define GEN6_AGGRESSIVE_TURBO(015)
#define GEN6_RC_VIDEO_FREQ 0xA00C
@@ -6098,8 +6105,10 @@ enum skl_disp_power_wells {
#define GEN6_RPSTAT1 0xA01C
#define GEN6_CAGF_SHIFT 8
#define HSW_CAGF_SHIFT 7
+#define GEN9_CAGF_SHIFT 23
#define GEN6_CAGF_MASK (0x7f GEN6_CAGF_SHIFT)
#define HSW_CAGF_MASK(0x7f HSW_CAGF_SHIFT)
+#define GEN9_CAGF_MASK (0x1ff GEN9_CAGF_SHIFT)
#define GEN6_RP_CONTROL0xA024
#define GEN6_RP_MEDIA_TURBO (111)
#define GEN6_RP_MEDIA_MODE_MASK (39)
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/skl: Updated the gen6_init_rps_frequencies function
From: Akash Goel akash.g...@intel.com
On SKL the frequency is specified in units of 16.66 MHZ, barring the
RP_STATE_CAP(0x5998) register, which still reports frequency in units
of 50 MHZ. So an extra conversion is required in gen6_init_rps_frequencies
function for SKL, to store the frequency values as per the actual hardware unit.
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1b36d0e..9dcfca6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4032,6 +4032,13 @@ static void gen6_init_rps_frequencies(struct drm_device
*dev)
dev_priv-rps.rp0_freq = (rp_state_cap 0) 0xff;
dev_priv-rps.rp1_freq = (rp_state_cap 8) 0xff;
dev_priv-rps.min_freq = (rp_state_cap 16) 0xff;
+ if (IS_SKYLAKE(dev)) {
+ /* Store the frequency values in 16.66 MHZ units, which is
+ the natural hardware unit for SKL */
+ dev_priv-rps.rp0_freq /= GEN9_FREQ_SCALER;
+ dev_priv-rps.rp1_freq /= GEN9_FREQ_SCALER;
+ dev_priv-rps.min_freq /= GEN9_FREQ_SCALER;
+ }
/* hw_max = RP0 until we check for overclocking */
dev_priv-rps.max_freq = dev_priv-rps.rp0_freq;
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 00/10] Added missing changes for Turbo feature on SKL
From: Akash Goel akash.g...@intel.com This patch series adds the missing changes, required for proper functioning of the Turbo feature on SKL. Most of the changes are mainly due to the fact that on SKL, the frequency has to be programmed in units of 16.66 MHZ and the time period value programmed in Up/Down EI threshold registers, is in units of 1.333 micro seconds. In this version, based on Ville Damien's suggestions, have reworked the patches to store the frequency values inside the dev_priv-rps in the original hardware units for SKL. This helped to avoid all the special cases during normal codepaths, limiting them to init and one debugfs function. Akash Goel (10): drm/i915/skl: Added new macros drm/i915/skl: Updated intel_gpu_freq() and intel_freq_opcode() drm/i915/skl: Updated the gen6_init_rps_frequencies function drm/i915/skl: Updated the gen6_set_rps function drm/i915/skl: Restructured the gen6_set_rps_thresholds function drm/i915/skl: Updated the gen6_rps_limits function drm/i915/skl: Updated the gen9_enable_rps function drm/i915/skl: Updated the i915_frequency_info debugfs function drm/i915/skl: Updated the act_freq_mhz_show sysfs function drm/i915/skl: Enabling processing of Turbo interrupts drivers/gpu/drm/i915/i915_debugfs.c | 25 --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 5 -- drivers/gpu/drm/i915/i915_reg.h | 9 +++ drivers/gpu/drm/i915/i915_sysfs.c | 4 +- drivers/gpu/drm/i915/intel_pm.c | 129 6 files changed, 102 insertions(+), 71 deletions(-) -- 1.9.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/skl: Updated the gen6_rps_limits function
From: Akash Goel akash.g...@intel.com
RP Interrupt Up/Down Frequency Limits register (A014) definition
has changed for SKL. Updated the gen6_rps_limits function as per that
v2: Renamed the function to intel_rps_limits (Chris)
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e094e5d..c3a8704 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3657,7 +3657,7 @@ static void ironlake_disable_drps(struct drm_device *dev)
* ourselves, instead of doing a rmw cycle (which might result in us clearing
* all limits and the gpu stuck at whatever frequency it is at atm).
*/
-static u32 gen6_rps_limits(struct drm_i915_private *dev_priv, u8 val)
+static u32 intel_rps_limits(struct drm_i915_private *dev_priv, u8 val)
{
u32 limits;
@@ -3667,9 +3667,15 @@ static u32 gen6_rps_limits(struct drm_i915_private
*dev_priv, u8 val)
* the hw runs at the minimal clock before selecting the desired
* frequency, if the down threshold expires in that window we will not
* receive a down interrupt. */
- limits = dev_priv-rps.max_freq_softlimit 24;
- if (val = dev_priv-rps.min_freq_softlimit)
- limits |= dev_priv-rps.min_freq_softlimit 16;
+ if (IS_GEN9(dev_priv-dev)) {
+ limits = (dev_priv-rps.max_freq_softlimit) 23;
+ if (val = dev_priv-rps.min_freq_softlimit)
+ limits |= (dev_priv-rps.min_freq_softlimit) 14;
+ } else {
+ limits = dev_priv-rps.max_freq_softlimit 24;
+ if (val = dev_priv-rps.min_freq_softlimit)
+ limits |= dev_priv-rps.min_freq_softlimit 16;
+ }
return limits;
}
@@ -3810,7 +3816,7 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
/* Make sure we continue to get interrupts
* until we hit the minimum or maximum frequencies.
*/
- I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, gen6_rps_limits(dev_priv, val));
+ I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, intel_rps_limits(dev_priv, val));
I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
POSTING_READ(GEN6_RPNSWREQ);
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/skl: Restructured the gen6_set_rps_thresholds function
On Thu, Feb 26, 2015 at 06:19:41PM +0530, akash.g...@intel.com wrote: From: Akash Goel akash.g...@intel.com Prior to SKL, the time period programmed in Up/Down EI Up/Down threshold registers was in units of 1.28 micro seconds. But for SKL, the units have changed (1.333 micro seconds). Have generalized the implementation of gen6_set_rps_thresholds function, by removing the hard coding done in it as per 1.28 micro seconds. v2: Renamed the local variables removed superfluous comments (Chris) Signed-off-by: Akash Goel akash.g...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/atomic-helper: Fix kerneldoc for prepare_planes
Copypaste-fail from cleanup_planes. Reported by Tvrtko. Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 28aa87510551..3ce57f46ad7f 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1096,9 +1096,9 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); */ /** - * drm_atomic_helper_prepare_planes - prepare plane resources after commit + * drm_atomic_helper_prepare_planes - prepare plane resources before commit * @dev: DRM device - * @state: atomic state object with old state structures + * @state: atomic state object with new state structures * * This function prepares plane state, specifically framebuffers, for the new * configuration. If any failure is encountered this function will call -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Rotation property is now handled in DRM core
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
So no need to have code which never gets called in the driver.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 9e6f727..976b891 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -203,16 +203,8 @@ intel_plane_atomic_get_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t *val)
{
- struct drm_mode_config *config = plane-dev-mode_config;
-
- if (property == config-rotation_property) {
- *val = state-rotation;
- } else {
- DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
- return -EINVAL;
- }
-
- return 0;
+ DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
+ return -EINVAL;
}
/**
@@ -233,14 +225,6 @@ intel_plane_atomic_set_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t val)
{
- struct drm_mode_config *config = plane-dev-mode_config;
-
- if (property == config-rotation_property) {
- state-rotation = val;
- } else {
- DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
- return -EINVAL;
- }
-
- return 0;
+ DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
+ return -EINVAL;
}
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm: Complete moving rotation property to core
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Commit 1da30627fc511a57c9bd23a02c97f0576379f761 drm: Add rotation value to
plane state moved the rotation property to DRM core but only did the set
property part. This does the get property part as well.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 321e098..7ca54cb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -450,6 +450,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state-src_w;
} else if (property == config-prop_src_h) {
*val = state-src_h;
+ } else if (property == config-rotation_property) {
+ *val = state-rotation;
} else if (plane-funcs-atomic_get_property) {
return plane-funcs-atomic_get_property(plane, state,
property, val);
} else {
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On Thu, Feb 26, 2015 at 02:19:51PM +, Kahola, Mika wrote: -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Thursday, February 26, 2015 12:51 PM To: Kahola, Mika Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization On Thu, Feb 26, 2015 at 11:26:10AM +0200, Mika Kahola wrote: In a case when DP link has been once trained we can reuse the existing link training parameters i.e. voltage swing and pre-emphasis levels from cache when there is a need to restart link training. In a case of eDP we initially try to train the link by using the parameter set that we can find from VBT. The fallback on both cases is to reset the link training parameters and restart. I don't think the fallback from bad VBT values works as on failure they just get reset. Care to enlighten me? -Chris -- Chris Wilson, Intel Open Source Technology Centre Thank you for the comment! This was my first patch to gfx development so all comments are welcomed. The idea that I had in mind was to initially start DP link training with the parameters that are stored in VBT. If we are unlucky and the link cannot be established at once by applying those initial parameters the parameters are reset to zero and link training is restarted. I do agree that the fallback in this case is unnecessary if VBT values are reset to zero in case of a failure. The VBT values themselves are not reset to zero. What I meant was the sequence for VBT recovery is: first time link training - intel_dp_reset_link_train() - use VBT values - reuse_train_set = true clock recovery !ok - reuse_train_set == true - intel_dp_reset_link_train - use VBT values again - reuse_train_set = false i.e. every time we call reset_link_train we restore the VBT values and not zero. What you want is something like a intel_dp-edp_use_vbt_train_set flag that is initially set to is_edp(intel_edp) and then cleared if clock recovery ever fails. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Look at staged config when fixing pipe_src_w for LVDS
On Thu, Feb 26, 2015 at 09:44:45AM +0200, Ander Conselvan de Oliveira wrote: The code in function intel_crtc_compute_config() that evens pipe_src_w if necessary would look at the current config instead of the staged one when deciding if there is an LVDS encoder in use. This could potentially lead to the value not being updated, if during the modeset a crtc wasn't driving an LVDS encoder. Signed-off-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Queued for -next, thanks for the patch. -Daniel --- I noticed this while looking for things that need to be changed for atomic. The patch is only compiled tested. Ander drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index fad5f76..b0f113d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5592,7 +5592,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc, * - LVDS dual channel mode * - Double wide pipe */ - if ((intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) + if ((intel_pipe_will_have_type(crtc, INTEL_OUTPUT_LVDS) intel_is_dual_link_lvds(dev)) || pipe_config-double_wide) pipe_config-pipe_src_w = ~1; -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915/skl: Updated the act_freq_mhz_show sysfs function
From: Akash Goel akash.g...@intel.com
Added support for SKL in the act_freq_mhz_show sysfs function
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 186ab95..57e1186 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -300,7 +300,9 @@ static ssize_t gt_act_freq_mhz_show(struct device *kdev,
ret = intel_gpu_freq(dev_priv, (freq 8) 0xff);
} else {
u32 rpstat = I915_READ(GEN6_RPSTAT1);
- if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+ if (IS_GEN9(dev_priv))
+ ret = (rpstat GEN9_CAGF_MASK) GEN9_CAGF_SHIFT;
+ else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
ret = (rpstat HSW_CAGF_MASK) HSW_CAGF_SHIFT;
else
ret = (rpstat GEN6_CAGF_MASK) GEN6_CAGF_SHIFT;
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915/skl: Enabling processing of Turbo interrupts
From: Akash Goel akash.g...@intel.com
Earlier Turbo interrupts were not being processed for SKL,
as something was amiss in turbo programming for SKL.
Now missing changes have been added, so enabling the Turbo
interrupt processing for SKL.
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 07e257c..73089ff 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1696,11 +1696,6 @@ static void i9xx_pipe_crc_irq_handler(struct drm_device
*dev, enum pipe pipe)
* the work queue. */
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir)
{
- /* TODO: RPS on GEN9+ is not supported yet. */
- if (WARN_ONCE(INTEL_INFO(dev_priv)-gen = 9,
- GEN9+: unexpected RPS IRQ\n))
- return;
-
if (pm_iir dev_priv-pm_rps_events) {
spin_lock(dev_priv-irq_lock);
gen6_disable_pm_irq(dev_priv, pm_iir dev_priv-pm_rps_events);
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/skl: Updated the gen9_enable_rps function
From: Akash Goel akash.g...@intel.com On SKL, GT frequency is programmed in units of 16.66 MHZ units compared to 50 MHZ for older platforms. Also the time value specified for Up/Down EI Up/Down thresholds are expressed in units of 1.33 us, compared to 1.28 us for older platforms. So updated the gen9_enable_rps function as per that. v2: Updated to use new macro GT_INTERVAL_FROM_US v3: Removed the initial setup of certain registers, from gen9_enable_rps, which gets overridden later from gen6_set_rps (Damien) Signed-off-by: Akash Goel akash.g...@intel.com --- drivers/gpu/drm/i915/intel_pm.c | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c3a8704..ce7ddbf 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4084,21 +4084,20 @@ static void gen9_enable_rps(struct drm_device *dev) gen6_init_rps_frequencies(dev); - I915_WRITE(GEN6_RPNSWREQ, 0xc80); - I915_WRITE(GEN6_RC_VIDEO_FREQ, 0xc80); - - I915_WRITE(GEN6_RP_DOWN_TIMEOUT, 0xf4240); - I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, 0x1206); - I915_WRITE(GEN6_RP_UP_THRESHOLD, 0xe808); - I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 0x3bd08); - I915_WRITE(GEN6_RP_UP_EI, 0x101d0); - I915_WRITE(GEN6_RP_DOWN_EI, 0x55730); + /* Program defaults and thresholds for RPS*/ + I915_WRITE(GEN6_RC_VIDEO_FREQ, + GEN9_FREQUENCY(dev_priv-rps.rp1_freq)); + + /* 1 second timeout*/ + I915_WRITE(GEN6_RP_DOWN_TIMEOUT, GT_INTERVAL_FROM_US(100)); + I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 0xa); - I915_WRITE(GEN6_PMINTRMSK, 0x6); - I915_WRITE(GEN6_RP_CONTROL, GEN6_RP_MEDIA_TURBO | - GEN6_RP_MEDIA_HW_MODE | GEN6_RP_MEDIA_IS_GFX | - GEN6_RP_ENABLE | GEN6_RP_UP_BUSY_AVG | - GEN6_RP_DOWN_IDLE_AVG); + + /* Leaning on the below call to gen6_set_rps to program/setup the +* Up/Down EI threshold registers, as well as the RP_CONTROL, +* RP_INTERRUPT_LIMITS RPNSWREQ registers */ + dev_priv-rps.power = HIGH_POWER; /* force a reset */ + gen6_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit); gen6_enable_rps_interrupts(dev); -- 1.9.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915/skl: Updated the gen6_set_rps function
From: Akash Goel akash.g...@intel.com
On SKL, the frequency is programmed differently in RPNSWREQ (A008)
register (from bits 23 to 31, compared to bits 24 to 31). So updated
the gen6_set_rps function, as per this change.
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9dcfca6..339a034 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3798,7 +3798,10 @@ static void gen6_set_rps(struct drm_device *dev, u8 val)
if (val != dev_priv-rps.cur_freq) {
gen6_set_rps_thresholds(dev_priv, val);
- if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ if (IS_GEN9(dev))
+ I915_WRITE(GEN6_RPNSWREQ,
+ GEN9_FREQUENCY(val));
+ else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
I915_WRITE(GEN6_RPNSWREQ,
HSW_FREQUENCY(val));
else
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/skl: Added new macros
On Thu, Feb 26, 2015 at 12:50:16PM +, Chris Wilson wrote: On Thu, Feb 26, 2015 at 06:19:37PM +0530, akash.g...@intel.com wrote: +#define GT_INTERVAL_FROM_US(us) (IS_GEN9(dev_priv-dev) ? \ + INTERVAL_1_33_US(us) : \ + INTERVAL_1_28_US(us)) Just use IS_GEN9(dev_priv) Oh, and implicit paraemters to a macro are evil. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions
On Thu, Feb 26, 2015 at 10:38:28AM +, Chris Wilson wrote: On Thu, Feb 26, 2015 at 04:09:47PM +0530, akash.g...@intel.com wrote: From: Akash Goel akash.g...@intel.com The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register are stored, initially by the Driver, inside the dev_priv-rps structure. Since these values are expected to remain same throughout, there is no real need to read this register, on dynamic basis, from certain debugfs/sysfs functions and the values can be instead retrieved from the dev_priv-rps structure when needed. For the i915_frequency_info debugfs interface, the frequency values from the RP_STATE_CAP register only should be used, to indicate the actual Hw state, since it is principally used for the debugging purpose. v2: Reverted the changes in i915_frequency_info function, to continue report back the frequency values, as per the actual Hw state (Chris) Signed-off-by: Akash Goel akash.g...@intel.com Nice improvement, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Simplify batch pool cache search
On Thu, Feb 26, 2015 at 10:05:17AM +, Chris Wilson wrote: Combining list_del() with the list_for_each() is actually safe. Sigh. It's not, the iterator disappears and so iter = iter-next is unsafe (I was just thinking that the value of iter-next is left untouched by list_del()). Time to go shopping. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
-Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Thursday, February 26, 2015 12:51 PM To: Kahola, Mika Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization On Thu, Feb 26, 2015 at 11:26:10AM +0200, Mika Kahola wrote: In a case when DP link has been once trained we can reuse the existing link training parameters i.e. voltage swing and pre-emphasis levels from cache when there is a need to restart link training. In a case of eDP we initially try to train the link by using the parameter set that we can find from VBT. The fallback on both cases is to reset the link training parameters and restart. I don't think the fallback from bad VBT values works as on failure they just get reset. Care to enlighten me? -Chris -- Chris Wilson, Intel Open Source Technology Centre Thank you for the comment! This was my first patch to gfx development so all comments are welcomed. The idea that I had in mind was to initially start DP link training with the parameters that are stored in VBT. If we are unlucky and the link cannot be established at once by applying those initial parameters the parameters are reset to zero and link training is restarted. I do agree that the fallback in this case is unnecessary if VBT values are reset to zero in case of a failure. Cheers, Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Support for higher DSI clk
For MIPI panels requiring higher DSI clk, values needs to be added
in lfsr_converts table for getting the correct values of pll ctrl
and dividor values which gets programmed in cck regs, otherwise DSI
PLL does not get locked leading to no display on the MIPI panel.
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
---
drivers/gpu/drm/i915/intel_dsi_pll.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 3622d0b..471336d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -46,8 +46,8 @@ struct dsi_mnp {
static const u32 lfsr_converts[] = {
426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
- 106, 53, 282, 397, 354, 227, 113, 56, 284, 142, /* 81 - 90 */
- 71, 35 /* 91 - 92 */
+ 106, 53, 282, 397, 454, 227, 113, 56, 284, 142, /* 81 - 90 */
+ 71, 35, 273, 136, 324, 418, 465, 488, 500, 506 /* 91 - 100 */
};
#ifdef DSI_CLK_FROM_RR
--
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] drm: Remove redundant code in the getencoder ioctl
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5827 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 281/281 280/281 ILK -2 308/308 306/308 SNB -1 326/326 325/326 IVB 380/380 380/380 BYT 294/294 294/294 HSW 387/421 387/421 BDW -1 316/316 315/316 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gen3_render_mixed_blits PASS(6) CRASH(1)PASS(1) *ILK igt_gem_fenced_exec_thrash_no-spare-fences-busy PASS(2) DMESG_WARN(1)PASS(1) *ILK igt_gem_fenced_exec_thrash_no-spare-fences-busy-interruptible PASS(2) DMESG_WARN(1)PASS(1) *SNB igt_kms_plane_plane-panning-bottom-right-pipe-B-plane-1 DMESG_WARN(12)PASS(4) TIMEOUT(1)PASS(1) *BDW igt_gem_gtt_hog PASS(12) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/skl: Fix stepping check for a couple of W/As
Both WaDisableSDEUnitClockGating and WaSetGAPSunitClckGateDisable are
needed on B0 as well.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7dcb5b6..f11e487 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -67,7 +67,7 @@ static void skl_init_clock_gating(struct drm_device *dev)
gen9_init_clock_gating(dev);
- if (INTEL_REVID(dev) == SKL_REVID_A0) {
+ if (INTEL_REVID(dev) = SKL_REVID_B0) {
/*
* WaDisableSDEUnitClockGating:skl
* WaSetGAPSunitClckGateDisable:skl
--
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/2] drm/i915/skl: Implement WaDisableVFUnitClockGating
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55143cb..6849b74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6056,6 +6056,7 @@ enum skl_disp_power_wells {
# define GEN6_CSUNIT_CLOCK_GATE_DISABLE(1 7)
#define GEN6_UCGCTL2 0x9404
+# define GEN6_VFUNIT_CLOCK_GATE_DISABLE(1 31)
# define GEN7_VDSUNIT_CLOCK_GATE_DISABLE (1 30)
# define GEN7_TDLUNIT_CLOCK_GATE_DISABLE (1 22)
# define GEN6_RCZUNIT_CLOCK_GATE_DISABLE (1 13)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f11e487..601f43c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -75,6 +75,10 @@ static void skl_init_clock_gating(struct drm_device *dev)
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
GEN8_GAPSUNIT_CLOCK_GATE_DISABLE |
GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+ /* WaDisableVFUnitClockGating:skl */
+ I915_WRITE(GEN6_UCGCTL2, I915_READ(GEN6_UCGCTL2) |
+ GEN6_VFUNIT_CLOCK_GATE_DISABLE);
}
if (INTEL_REVID(dev) = SKL_REVID_D0) {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] A couple of follow up W/A patches
While reviewing the initial 18 patches series Nick noticed one stepping check didn't look correct, so here a couple of patches to fix that. -- Damien Damien Lespiau (2): drm/i915/skl: Fix stepping check for a couple of W/As drm/i915/skl: Implement WaDisableVFUnitClockGating drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 6 +- 2 files changed, 6 insertions(+), 1 deletion(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9 V4] drm/i915: Update the EDID automated compliance test function
Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read operations
are handed off to userspace so that the userspace app can set the display
mode appropriately for the test response.
The compliance_test_active flag now appears at the end of the individual
test handling functions. This is so that the kernel-side operations can
be completed without the risk of interruption from the userspace app
that is polling on that flag.
V2:
- Addressed mailing list feedback
- Removed excess debug messages
- Removed extraneous comments
- Fixed formatting issues (line length 80)
- Updated the debug message in compute_edid_checksum to output hex values
instead of decimal
V3:
- Addressed more list feedback
- Added the test_active flag to the autotest function
- Removed test_active flag from handler
- Added failsafe check on the compliance test active flag
at the end of the test handler
- Fixed checkpatch.pl issues
V4:
- Removed the checksum computation function and its use as it has been
rendered superfluous by changes to the core DRM EDID functions
Signed-off-by: Todd Previte tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 52 +
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5d7b7f3..32f0fc5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -41,6 +41,13 @@
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
+/* Compliance test status bits */
+#define INTEL_DP_EDID_OK (00)
+#define INTEL_DP_EDID_CORRUPT (10)
+#define INTEL_DP_RESOLUTION_PREFERRED (12)
+#define INTEL_DP_RESOLUTION_STANDARD (13)
+#define INTEL_DP_RESOLUTION_FAILSAFE (14)
+
struct dp_link_dpll {
int link_bw;
struct dpll dpll;
@@ -3766,7 +3773,39 @@ static uint8_t intel_dp_autotest_video_pattern(struct
intel_dp *intel_dp)
static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
{
+ struct drm_connector *connector = intel_dp-attached_connector-base;
+ struct i2c_adapter *adapter = intel_dp-aux.ddc;
+ struct edid *edid_read = NULL;
uint8_t test_result = DP_TEST_NAK;
+ uint32_t ret = 0;
+
+ intel_dp-aux.i2c_nack_count = 0;
+ intel_dp-aux.i2c_defer_count = 0;
+
+ edid_read = drm_get_edid(connector, adapter);
+
+ if (edid_read == NULL) {
+ /* Check for NACKs/DEFERs, use failsafe if detected
+ (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */
+ if (intel_dp-aux.i2c_nack_count 0 ||
+ intel_dp-aux.i2c_defer_count 0)
+ DRM_DEBUG_KMS(EDID read had %d NACKs, %d DEFERs\n,
+ intel_dp-aux.i2c_nack_count,
+ intel_dp-aux.i2c_defer_count);
+ intel_dp-compliance_test_data = INTEL_DP_EDID_CORRUPT |
+INTEL_DP_RESOLUTION_FAILSAFE;
+ } else {
+ ret = drm_dp_dpcd_write(intel_dp-aux,
+ DP_TEST_EDID_CHECKSUM,
+ edid_read-checksum, 1);
+ test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
+ intel_dp-compliance_test_data = INTEL_DP_EDID_OK |
+INTEL_DP_RESOLUTION_PREFERRED;
+ }
+
+ /* Set test active flag here so userspace doesn't interrupt things */
+ intel_dp-compliance_testing_active = 1;
+
return test_result;
}
@@ -3781,6 +3820,7 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
uint8_t response = DP_TEST_NAK;
uint8_t rxdata = 0;
int status = 0;
+ int failsafe_counter = 0;
status = drm_dp_dpcd_read(intel_dp-aux, DP_TEST_REQUEST, rxdata, 1);
if (status = 0) {
@@ -3816,6 +3856,18 @@ update_status:
response, 1);
if (status = 0)
DRM_DEBUG_KMS(Could not write test response to sink\n);
+
+ /* Failsafe check on compliance testing flag */
+ while (intel_dp-compliance_testing_active) {
+ usleep_range(100, 150);
+ failsafe_counter++;
+ /*
+ If userspace still hasn't responded after 20 iterations,
+ chances are it's not going to, so clear the flag and move on
+ */
+ if (failsafe_counter 20)
+ intel_dp-compliance_testing_active = 0;
+ }
}
static int
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote: Imre Deak imre.d...@intel.com writes: That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? No, but it would help if you could still try the two attached patch separately, without any of the previous workarounds. Based on the result, we'll follow up with a fix that adds for your specific platform either of the attached workarounds or simply avoids putting the device into D3 (corresponding to the patch you already tried). None of those patches made any difference. The laptop still hangs at power-off. Not really surprising, is it? Previous testing shows that the hang occurs at the pci_set_power_state(drm_dev-pdev, PCI_D3hot) call in the poweroff_late hook. It is hard to see how replacing it by an attempt to set D3cold, or adding any call after this point, could possibly change anything. The system is stil hanging at the pci_set_power_state() call. Judging from the blinking LED, I assume that it's not pci_set_power_state() that hangs the machine, but the hang happens in BIOS code. The generic pci-driver code will put the i915 device into PCI_D3hot for you, won't it? Why do you need to duplicate that in the driver, *knowing* that doing so breaks (at least some) systems? Letting the pci core put the device into D3 wouldn't get rid of the problem. It's putting the device into D3 in the first place what causes it. I honestly don't think this let's try some random code is the proper way to fix this bug (or any other bug for that matter). You need to start understanding the code you write, and the first step is by actually explaining the changes you make. We have a good understanding about the issue: the BIOS on your platform does something unexpected behind the back of the driver/kernel. In that sense the patches were not random, for instance the first one is based on an existing workaround for an issue that resembles quite a lot yours, see pci_pm_poweroff_noirq(). I also believe that you completely miss the fact that this bug has survived a full release cycle before you became aware of it, and the implications this has wrt other affected systems/users. I assume you understand that my system isn't one-of-a-kind, This means that there are other affected users with identical/similar systems. Now, if none of those users reported the bug to you (we all know why: Linux kernel development is currently limited by the available testing resources, NOT by the available developer resources), then how do you know that there aren't a number of other systems affected as well? Let me answer that for you: You don't. Which is why you must explain the mechanism triggering the bug, proving that it is a chipset/system specific issue. Because that's the only way you will *know* that you have solved the problem not only for me, but for all affected users. IMHO, the only safe and sane solution at the moment is the revert patch I posted. It's a simple fix, reverting back to the *known* working state before this regression was introduced. Then you can start over from there, trying to implement this properly. The current way is the proper one that we want for the generic case. The issue on your platform is the exception, so working around that is a sensible choice. Attached is the proposed fix for this issue. --Imre From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 From: Imre Deak imre.d...@intel.com Date: Thu, 26 Feb 2015 18:38:53 +0200 Subject: [PATCH] drm/i915: gm45: work around hang during hibernation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak imre.d...@intel.com Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork bj...@mork.no Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 27 ++- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c
[Intel-gfx] [PATCH 1/2] drm/i915: Disable DDR DVFS on CHV
From: Ville Syrjälä ville.syrj...@linux.intel.com
DDR DVFS introduces massive memory latencies which can't be handled by
the PND deadline stuff. Instead the watermarks will need to be
programmed to compensate for the latency and the deadlines will need to
be programmed to tight fixed values. That means DDR DVFS can only be
enabled if the display FIFOs are large enough, and that pretty much
means we have to manually repartition them to suit the needs of the
moment.
That's a lot of change, so in the meantime let's just disable DDR DVFS
to get the display(s) to be stable.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_pm.c | 34 ++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 581813e..f67be5d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -630,6 +630,11 @@ enum skl_disp_power_wells {
#define FB_GFX_FMIN_AT_VMIN_FUSE 0x137
#define FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT 8
+#define PUNIT_REG_DDR_SETUP2 0x139
+#define FORCE_DDR_FREQ_REQ_ACK (1 8)
+#define FORCE_DDR_LOW_FREQ (1 1)
+#define FORCE_DDR_HIGH_FREQ (1 0)
+
#define PUNIT_GPU_STATUS_REG 0xdb
#define PUNIT_GPU_STATUS_MAX_FREQ_SHIFT16
#define PUNIT_GPU_STATUS_MAX_FREQ_MASK 0xff
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f603dac..f43d77c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -235,6 +235,28 @@ static const struct cxsr_latency
*intel_get_cxsr_latency(int is_desktop,
return NULL;
}
+static void chv_set_memory_dvfs(struct drm_i915_private *dev_priv, bool enable)
+{
+ u32 val;
+
+ mutex_lock(dev_priv-rps.hw_lock);
+
+ val = vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2);
+ if (enable)
+ val = ~FORCE_DDR_HIGH_FREQ;
+ else
+ val |= FORCE_DDR_HIGH_FREQ;
+ val = ~FORCE_DDR_LOW_FREQ;
+ val |= FORCE_DDR_FREQ_REQ_ACK;
+ vlv_punit_write(dev_priv, PUNIT_REG_DDR_SETUP2, val);
+
+ if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2)
+ FORCE_DDR_FREQ_REQ_ACK) == 0, 3))
+ DRM_ERROR(timed out waiting for Punit DDR DVFS request\n);
+
+ mutex_unlock(dev_priv-rps.hw_lock);
+}
+
static void chv_set_memory_pm5(struct drm_i915_private *dev_priv, bool enable)
{
u32 val;
@@ -281,6 +303,7 @@ void intel_set_memory_cxsr(struct drm_i915_private
*dev_priv, bool enable)
enable ? enabled : disabled);
}
+
/*
* Latency for FIFO fetches is dependent on several factors:
* - memory configuration (speed, channels)
@@ -1000,6 +1023,17 @@ static void valleyview_update_wm(struct drm_crtc *crtc)
wm.pipe[pipe].primary, wm.pipe[pipe].cursor,
wm.sr.plane, wm.sr.cursor);
+ /*
+* FIXME DDR DVFS introduces massive memory latencies which
+* are not known to system agent so any deadline specified
+* by the display may not be respected. To support DDR DVFS
+* the watermark code needs to be rewritten to essentially
+* bypass deadline mechanism and rely solely on the
+* watermarks. For now disable DDR DVFS.
+*/
+ if (IS_CHERRYVIEW(dev_priv))
+ chv_set_memory_dvfs(dev_priv, false);
+
if (!cxsr_enabled)
intel_set_memory_cxsr(dev_priv, false);
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote: Imre Deak imre.d...@intel.com writes: That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? No, but it would help if you could still try the two attached patch separately, without any of the previous workarounds. Based on the result, we'll follow up with a fix that adds for your specific platform either of the attached workarounds or simply avoids putting the device into D3 (corresponding to the patch you already tried). None of those patches made any difference. The laptop still hangs at power-off. Not really surprising, is it? Previous testing shows that the hang occurs at the pci_set_power_state(drm_dev-pdev, PCI_D3hot) call in the poweroff_late hook. It is hard to see how replacing it by an attempt to set D3cold, or adding any call after this point, could possibly change anything. The system is stil hanging at the pci_set_power_state() call. Judging from the blinking LED, I assume that it's not pci_set_power_state() that hangs the machine, but the hang happens in BIOS code. The generic pci-driver code will put the i915 device into PCI_D3hot for you, won't it? Why do you need to duplicate that in the driver, *knowing* that doing so breaks (at least some) systems? Letting the pci core put the device into D3 wouldn't get rid of the problem. It's putting the device into D3 in the first place what causes it. I honestly don't think this let's try some random code is the proper way to fix this bug (or any other bug for that matter). You need to start understanding the code you write, and the first step is by actually explaining the changes you make. We have a good understanding about the issue: the BIOS on your platform does something unexpected behind the back of the driver/kernel. In that sense the patches were not random, for instance the first one is based on an existing workaround for an issue that resembles quite a lot yours, see pci_pm_poweroff_noirq(). I also believe that you completely miss the fact that this bug has survived a full release cycle before you became aware of it, and the implications this has wrt other affected systems/users. I assume you understand that my system isn't one-of-a-kind, This means that there are other affected users with identical/similar systems. Now, if none of those users reported the bug to you (we all know why: Linux kernel development is currently limited by the available testing resources, NOT by the available developer resources), then how do you know that there aren't a number of other systems affected as well? Let me answer that for you: You don't. Which is why you must explain the mechanism triggering the bug, proving that it is a chipset/system specific issue. Because that's the only way you will *know* that you have solved the problem not only for me, but for all affected users. IMHO, the only safe and sane solution at the moment is the revert patch I posted. It's a simple fix, reverting back to the *known* working state before this regression was introduced. Then you can start over from there, trying to implement this properly. The current way is the proper one that we want for the generic case. The issue on your platform is the exception, so working around that is a sensible choice. Attached is the proposed fix for this issue. --Imre From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 From: Imre Deak imre.d...@intel.com Date: Thu, 26 Feb 2015 18:38:53 +0200 Subject: [PATCH] drm/i915: gm45: work around hang during hibernation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak imre.d...@intel.com Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork bj...@mork.no Signed-off-by: Imre Deak imre.d...@intel.com ---
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen8: Apply Per-context workarounds using W/A batch buffers
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5828 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 281/281 280/281 ILK 308/308 308/308 SNB 326/326 326/326 IVB 380/380 380/380 BYT 294/294 294/294 HSW 387/421 387/421 BDW -1 316/316 315/316 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gen3_render_mixed_blits PASS(7) CRASH(1)PASS(1) *BDW igt_gem_gtt_hog PASS(12) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote: On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote: Imre Deak imre.d...@intel.com writes: That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? No, but it would help if you could still try the two attached patch separately, without any of the previous workarounds. Based on the result, we'll follow up with a fix that adds for your specific platform either of the attached workarounds or simply avoids putting the device into D3 (corresponding to the patch you already tried). None of those patches made any difference. The laptop still hangs at power-off. Not really surprising, is it? Previous testing shows that the hang occurs at the pci_set_power_state(drm_dev-pdev, PCI_D3hot) call in the poweroff_late hook. It is hard to see how replacing it by an attempt to set D3cold, or adding any call after this point, could possibly change anything. The system is stil hanging at the pci_set_power_state() call. Judging from the blinking LED, I assume that it's not pci_set_power_state() that hangs the machine, but the hang happens in BIOS code. The generic pci-driver code will put the i915 device into PCI_D3hot for you, won't it? Why do you need to duplicate that in the driver, *knowing* that doing so breaks (at least some) systems? Letting the pci core put the device into D3 wouldn't get rid of the problem. It's putting the device into D3 in the first place what causes it. I honestly don't think this let's try some random code is the proper way to fix this bug (or any other bug for that matter). You need to start understanding the code you write, and the first step is by actually explaining the changes you make. We have a good understanding about the issue: the BIOS on your platform does something unexpected behind the back of the driver/kernel. In that sense the patches were not random, for instance the first one is based on an existing workaround for an issue that resembles quite a lot yours, see pci_pm_poweroff_noirq(). I also believe that you completely miss the fact that this bug has survived a full release cycle before you became aware of it, and the implications this has wrt other affected systems/users. I assume you understand that my system isn't one-of-a-kind, This means that there are other affected users with identical/similar systems. Now, if none of those users reported the bug to you (we all know why: Linux kernel development is currently limited by the available testing resources, NOT by the available developer resources), then how do you know that there aren't a number of other systems affected as well? Let me answer that for you: You don't. Which is why you must explain the mechanism triggering the bug, proving that it is a chipset/system specific issue. Because that's the only way you will *know* that you have solved the problem not only for me, but for all affected users. IMHO, the only safe and sane solution at the moment is the revert patch I posted. It's a simple fix, reverting back to the *known* working state before this regression was introduced. Then you can start over from there, trying to implement this properly. The current way is the proper one that we want for the generic case. The issue on your platform is the exception, so working around that is a sensible choice. Attached is the proposed fix for this issue. --Imre From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 From: Imre Deak imre.d...@intel.com Date: Thu, 26 Feb 2015 18:38:53 +0200 Subject: [PATCH] drm/i915: gm45: work around hang during hibernation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak imre.d...@intel.com Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork bj...@mork.no Signed-off-by: Imre Deak imre.d...@intel.com ---
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
Ville Syrjälä ville.syrj...@linux.intel.com writes:
@@ -651,7 +651,14 @@ static int i915_drm_suspend_late(struct drm_device
*drm_dev)
}
pci_disable_device(drm_dev-pdev);
-pci_set_power_state(drm_dev-pdev, PCI_D3hot);
+/*
+ * During hibernation on some GM45 platforms the BIOS may try to access
+ * the device even though it's already in D3 and hang the machine. So
+ * leave the device in D0 on those platforms and hope the BIOS will
+ * power down the device properly.
Please include the model of the known bad machine in this comment, to
help future archaeologists.
Here are some details:
bjorn@nemi:~$ grep . /sys/class/dmi/id/{bios,product}* 2/dev/null
/sys/class/dmi/id/bios_date:12/19/2011
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:6EET55WW (3.15 )
/sys/class/dmi/id/product_name:2776LEG
/sys/class/dmi/id/product_version:ThinkPad X301
Please let me know if you need some other data.
Bjørn
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
Imre Deak imre.d...@intel.com writes: Attached is the proposed fix for this issue. --Imre From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 From: Imre Deak imre.d...@intel.com Date: Thu, 26 Feb 2015 18:38:53 +0200 Subject: [PATCH] drm/i915: gm45: work around hang during hibernation I can confirm that this patch solves the problem for me. Thanks. Bjørn ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/12] drm/i915: Enable the maxfifo PM5 mode when appropriate on CHV
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV has a new knob in Punit to select between some memory power savings
modes PM2 and PM5. We can allow the deeper PM5 when maxfifo mode is
enabled, so let's do so in the hopes for moar power savings.
v2: Put the thing into a separate function to avoid churn later
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 19 ++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 145f0d4..5a20f58 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -552,6 +552,9 @@
#define DSPFREQSTAT_MASK (0x3 DSPFREQSTAT_SHIFT)
#define DSPFREQGUAR_SHIFT14
#define DSPFREQGUAR_MASK (0x3 DSPFREQGUAR_SHIFT)
+#define DSP_MAXFIFO_PM5_STATUS (1 22) /* chv */
+#define DSP_AUTO_CDCLK_GATE_DISABLE (1 7) /* chv */
+#define DSP_MAXFIFO_PM5_ENABLE (1 6) /* chv */
#define _DP_SSC(val, pipe) ((val) (2 * (pipe)))
#define DP_SSC_MASK(pipe)_DP_SSC(0x3, (pipe))
#define DP_SSC_PWR_ON(pipe) _DP_SSC(0x0, (pipe))
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e6cbc24..f603dac 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -235,13 +235,30 @@ static const struct cxsr_latency
*intel_get_cxsr_latency(int is_desktop,
return NULL;
}
+static void chv_set_memory_pm5(struct drm_i915_private *dev_priv, bool enable)
+{
+ u32 val;
+
+ mutex_lock(dev_priv-rps.hw_lock);
+
+ val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+ if (enable)
+ val |= DSP_MAXFIFO_PM5_ENABLE;
+ else
+ val = ~DSP_MAXFIFO_PM5_ENABLE;
+ vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
+
+ mutex_unlock(dev_priv-rps.hw_lock);
+}
+
void intel_set_memory_cxsr(struct drm_i915_private *dev_priv, bool enable)
{
struct drm_device *dev = dev_priv-dev;
u32 val;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_CHERRYVIEW(dev)) {
I915_WRITE(FW_BLC_SELF_VLV, enable ? FW_CSPWRDWNEN : 0);
+ chv_set_memory_pm5(dev_priv, enable);
} else if (IS_G4X(dev) || IS_CRESTLINE(dev)) {
I915_WRITE(FW_BLC_SELF, enable ? FW_BLC_SELF_EN : 0);
} else if (IS_PINEVIEW(dev)) {
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch -next] drm/i915: fix a printk format
On Thu, Feb 26, 2015 at 07:53:54PM +0300, Dan Carpenter wrote: This printk leads to the following Smatch warning: drivers/gpu/drm/i915/i915_gem_gtt.c:336 alloc_pt_range() error: '%pa' expects argument of type 'phys_addr_t*', argument 5 has type 'struct i915_page_table_entry*' It looks like a simple typo to me where %p was intended instead of %pa. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Queued for -next, thanks for the patch. -Daniel diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index e05488e..48eff65 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -334,7 +334,7 @@ static int alloc_pt_range(struct i915_page_directory_entry *pd, uint16_t pde, si goto err_out; } WARN(pd-page_table[i], - Leaking page directory entry %d (%pa)\n, + Leaking page directory entry %d (%p)\n, i, pd-page_table[i]); pd-page_table[i] = pt; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reudce CHV DPLL min vco frequency to 4.8 GHz
From: Ville Syrjälä ville.syrj...@linux.intel.com
The current minimum vco frequency leaves us with a gap in our supported
frequencies at 233-243 MHz. Your typical 2560x1440@60 display wants a
pixel clock of 241.5 MHz, which is just withing that gap. Reduce the
allowed vco min frequency to 4.8GHz to reduce the gap to 233-240 MHz,
and thus allow such displays to work.
4.8 GHz is actually the documented (at least in some docs) limit of the
PLL, and we just picked 4.86 GHz originally because that was the lowest
value produced by the PLL spreadsheet, which obviously didn't consider
2560x1440 displays.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 102b12d..d437a21 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -390,7 +390,7 @@ static const intel_limit_t intel_limits_chv = {
* them would make no difference.
*/
.dot = { .min = 25000 * 5, .max = 54 * 5},
- .vco = { .min = 486, .max = 670 },
+ .vco = { .min = 480, .max = 670 },
.n = { .min = 1, .max = 1 },
.m1 = { .min = 2, .max = 2 },
.m2 = { .min = 24 22, .max = 175 22 },
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Reduce chv drain latency even further for 4k displays
From: Ville Syrjälä ville.syrj...@linux.intel.com To get 4k resolutions to work reliably with the current watermark setup we need to further reduce the drain latency. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index f43d77c..e262455 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -877,7 +877,7 @@ static uint8_t vlv_compute_drain_latency(struct drm_crtc *crtc, struct intel_crtc *intel_crtc = to_intel_crtc(crtc); int entries, prec_mult, drain_latency, pixel_size; int clock = intel_crtc-config-base.adjusted_mode.crtc_clock; - const int high_precision = IS_CHERRYVIEW(dev) ? 16 : 64; + const int high_precision = IS_CHERRYVIEW(dev) ? 12 : 64; /* * FIXME the plane might have an fb -- 2.0.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions
On Thu, 2015-02-26 at 08:04 +, Chris Wilson wrote: On Thu, Feb 26, 2015 at 01:29:09PM +0530, akash.g...@intel.com wrote: From: Akash Goel akash.g...@intel.com The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register are stored, initially by the Driver, inside the dev_priv-rps structure. Since these values are expected to remain same throughout, there is no real need to read this register, on dynamic basis, from debugfs/sysfs functions and the values can be instead retrieved from the dev_priv-rps structure when needed. Inside debugfs, you want both as we want to compare what the hardware thinks and what we believe it should be. Everywhere else we should indeed be trusting our bookkeeping. Agree, ideally we should throw an error, if the stored values do not match the ones reported by Hw and report the values read from the registers to User. Actually currently there is a bit of discrepancy. For VLV/CHV, directly the stored values only are being returned to the User. Even for non VLV also, there is inconsistency in the way RP_STATE_CAP register is being used inside i915_max_freq_set/i915_min_freq_set pair of debugfs functions. So tried to bring uniformity by using the stored values everywhere. Best regards Akash -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave - First batch of fixes for v4.0-rc, plenty of cc: stable material. BR, Jani. The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-02-26 for you to fetch changes up to 62e537f8d568347bbe4e00d7803a838750cdc618: drm/i915: Fix frontbuffer false positve. (2015-02-25 10:08:15 +0200) Chris Wilson (1): drm/i915: Check obj-vma_list under the struct_mutex Daniel Vetter (1): drm/i915: Align initial plane backing objects correctly Imre Deak (1): drm/i915: avoid processing spurious/shared interrupts in low-power states Jani Nikula (2): drm/i915/skl: handle all pixel formats in skylake_update_primary_plane() drm/i915: Dell Chromebook 11 has PWM backlight Nick Hoath (1): drm/i915: Fix a use after free, and unbalanced refcounting Rodrigo Vivi (2): drm/i915/bdw: PCI IDs ending in 0xb are ULT. drm/i915: Fix frontbuffer false positve. drivers/gpu/drm/i915/i915_drv.h| 15 ++- drivers/gpu/drm/i915/i915_gem.c| 3 +-- drivers/gpu/drm/i915/i915_gem_stolen.c | 6 ++ drivers/gpu/drm/i915/i915_gem_tiling.c | 7 --- drivers/gpu/drm/i915/i915_irq.c| 22 ++ drivers/gpu/drm/i915/intel_display.c | 33 - drivers/gpu/drm/i915/intel_lrc.c | 8 include/drm/i915_pciids.h | 4 ++-- 8 files changed, 73 insertions(+), 25 deletions(-) -- Jani Nikula, 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] [RFC v2] drm/i915: Android native sync support
On Wed, Feb 25, 2015 at 12:46:31PM -0800, Jesse Barnes wrote: On 01/28/2015 02:07 AM, Chris Wilson wrote: On Wed, Jan 28, 2015 at 10:50:18AM +0100, Daniel Vetter wrote: On Wed, Jan 28, 2015 at 09:23:46AM +, Chris Wilson wrote: On Wed, Jan 28, 2015 at 10:22:15AM +0100, Daniel Vetter wrote: On Mon, Jan 26, 2015 at 09:08:03AM +, Chris Wilson wrote: On Mon, Jan 26, 2015 at 08:52:39AM +0100, Daniel Vetter wrote: I think the problem will be platforms that want full explicit fence (like android) but allow delayed creation of the fence fd from a gl sync object (like the android egl extension allows). I'm not sure yet how to best expose that really since just creating a fence from the implicit request attached to the batch might upset the interface purists with the mix in implicit and explicit fencing ;-) Hence why I think for now we should just do the eager fd creation at execbuf until ppl scream (well maybe not merge this patch until ppl scream ...). Everything we do is buffer centric. Even in the future with random bits of memory, we will still use buffers behind the scenes. From an interface perspective, it is clearer to me if we say give me a fence for this buffer. Exactly the same way as we say is this buffer busy or wait on this buffer. The change is that we now hand back an fd to slot into an event loop. That, to me, is a much smaller evolutionary step of the existing API, and yet more versatile than just attaching one to the execbuf. The problem is that big parts of the world do not subscribe to that buffer centric view of gfx. Imo since those parts will be the primary users of this interface we should try to fit their ideas as much as feasible. Later on (if we need it) we can add some glue to tie in the buffer-centric implicit model with the explicit model. They won't be using execbuffer either. So what's your point? Android very much will user execbuffer. And even the in-flight buffered svm stuff will keep on using execbuf (just without any relocs). So still buffer-centric and would benefit from the more general and more explict fencing rather than just execbuf. If you look at the throttling in mesa, you can already see a place that would rather create a fence on a buffer rather than its very approximate execbuf tracking. And once we indeed can make the case (plus have the hw) for direct userspace submission I think the kernel shouldn't be in the business of creating fence objects: The ring will be fully under control of userspace, and that's the only place we could insert a seqno into. So again the same trust issues. No buffers, no requests, nothing for the kernel to do. No impact on designing an API that is useful today. If Mesa really wants this, we should investigate intra-batch fences again, both with and without buffer tracking (because afaik Mesa wants bufferless SVM too). But you said you think an fd is too heavyweight even? What do you mean by that? Or were you just preferring re-use of an existing object (i.e. the buffer) that we already track pass around? Mostly it is burn from X using select() and so we see fd handling very high on the profiles when all X has to do is flip. However, we can and do have up to several thousand batches in flight, and many more pending retirement from userspace. That is a scary prospect if I wanted to replace the signalling on the buffer with individual fences, both from the scaling issue and running into resource limits (i.e. back to the reason why our bo are currently fd-less). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix frontbuffer false positve.
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5820 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 281/281 280/281 ILK 308/308 308/308 SNB -1 326/326 325/326 IVB 380/380 380/380 BYT 294/294 294/294 HSW 387/421 387/421 BDW -1 316/316 315/316 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt_gem_userptr_blits_minor-unsync-normal DMESG_WARN(2)PASS(1) DMESG_WARN(1)PASS(1) SNB igt_kms_plane_plane-position-hole-pipe-B-plane-1 DMESG_WARN(12)PASS(3) DMESG_WARN(1)PASS(1) *BDW igt_gem_gtt_hog PASS(8) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: DP link training optimization
In a case when DP link has been once trained we can reuse
the existing link training parameters i.e. voltage swing
and pre-emphasis levels from cache when there is a need to
restart link training. In a case of eDP we initially try
to train the link by using the parameter set that we can find
from VBT. The fallback on both cases is to reset the link
training parameters and restart.
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 93 +++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 84 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1141d3..8482f58 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3288,8 +3288,39 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp, uint32_t *DP,
uint8_t dp_train_pat)
{
- memset(intel_dp-train_set, 0, sizeof(intel_dp-train_set));
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int i;
+
+ /* in case of eDP, get link training parameters from VBT */
+ if (is_edp(intel_dp)) {
+ for (i=0; iintel_dp-lane_count; i++)
+ intel_dp-train_set[i] = dev_priv-vbt.edp_vswing |
dev_priv-vbt.edp_preemphasis;
+ }
+ else
+ memset(intel_dp-train_set, 0, sizeof(intel_dp-train_set));
+
+ intel_dp_set_signal_levels(intel_dp, DP);
+ return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
+}
+
+static bool
+intel_dp_reuse_link_train(struct intel_dp *intel_dp, uint32_t *DP,
+ uint8_t dp_train_pat)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
intel_dp_set_signal_levels(intel_dp, DP);
+
+ I915_WRITE(intel_dp-output_reg, *DP);
+ POSTING_READ(intel_dp-output_reg);
+
+ drm_dp_dpcd_write(intel_dp-aux, DP_TRAINING_LANE0_SET,
+ intel_dp-train_set, intel_dp-lane_count);
+
return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
}
@@ -3356,6 +3387,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int voltage_tries, loop_tries;
uint32_t DP = intel_dp-DP;
uint8_t link_config[2];
+ uint8_t link_status[DP_LINK_STATUS_SIZE];
+ bool reuse_train_set = false;
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
@@ -3373,20 +3406,44 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP |= DP_PORT_EN;
- /* clock recovery */
- if (!intel_dp_reset_link_train(intel_dp, DP,
- DP_TRAINING_PATTERN_1 |
- DP_LINK_SCRAMBLING_DISABLE)) {
- DRM_ERROR(failed to enable link training\n);
- return;
+ /*
+* check if DP has already trained. Reset voltage swing and
+* pre-emphasis levels if that's not the case.
+*/
+ if (intel_dp-link_trained) {
+ if (!intel_dp_reuse_link_train(intel_dp, DP,
+ DP_TRAINING_PATTERN_1 |
+ DP_LINK_SCRAMBLING_DISABLE)) {
+ DRM_DEBUG_KMS(unable to set known link training
values\n);
+ return;
+ }
+ DRM_DEBUG_KMS(reuse current link train set\n);
+ reuse_train_set = true;
+ }
+ else {
+ /* reset link training values */
+ if (!intel_dp_reset_link_train(intel_dp, DP,
+ DP_TRAINING_PATTERN_1 |
+ DP_LINK_SCRAMBLING_DISABLE)) {
+ DRM_ERROR(failed to enable link training\n);
+ return;
+ }
+ DRM_DEBUG_KMS(reset link train set\n);
+
+ /*
+* in case of eDP, allow fallback to reset link training set
+* if VBT parameters doesn't apply
+*/
+ if (is_edp(intel_dp))
+ reuse_train_set = true;
+ else
+ reuse_train_set = false;
}
voltage = 0xff;
voltage_tries = 0;
loop_tries = 0;
for (;;) {
- uint8_t link_status[DP_LINK_STATUS_SIZE];
-
drm_dp_link_train_clock_recovery_delay(intel_dp-dpcd);
if (!intel_dp_get_link_status(intel_dp, link_status)) {
DRM_ERROR(failed to get link status\n);
@@ -3397,6 +3454,20 @@
Re: [Intel-gfx] [PATCH 3/4] drm/dp: add DPCD definitions from eDP 1.2
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: Mostly display control related DPCD addresses. Signed-off-by: Jani Nikula jani.nik...@intel.com --- include/drm/drm_dp_helper.h | 32 1 file changed, 32 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 209c5b91b0e8..cc96024e8776 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -426,6 +426,38 @@ #define DP_EDP_DPCD_REV 0x700/* eDP 1.2 */ +#define DP_EDP_GENERAL_CAP_1 0x701 + +#define DP_EDP_BACKLIGHT_ADJUSTMENT_CAP 0x702 + +#define DP_EDP_GENERAL_CAP_2 0x703 + +#define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 + +#define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 + +#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 +#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723 + +#define DP_EDP_PWMGEN_BIT_COUNT 0x724 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 + +#define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 + +#define DP_EDP_BACKLIGHT_FREQ_SET 0x728 + +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_LSB 0x72c + +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MSB 0x72d +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MID 0x72e +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB 0x72f + +#define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 +#define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 + #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ Checked against edp1.3 spec. Reviewed-by: Sonika Jindal sonika.jin...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions
On Thu, Feb 26, 2015 at 04:09:47PM +0530, akash.g...@intel.com wrote: From: Akash Goel akash.g...@intel.com The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register are stored, initially by the Driver, inside the dev_priv-rps structure. Since these values are expected to remain same throughout, there is no real need to read this register, on dynamic basis, from certain debugfs/sysfs functions and the values can be instead retrieved from the dev_priv-rps structure when needed. For the i915_frequency_info debugfs interface, the frequency values from the RP_STATE_CAP register only should be used, to indicate the actual Hw state, since it is principally used for the debugging purpose. v2: Reverted the changes in i915_frequency_info function, to continue report back the frequency values, as per the actual Hw state (Chris) Signed-off-by: Akash Goel akash.g...@intel.com Nice improvement, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate
Imre Deak imre.d...@intel.com writes: That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? No, but it would help if you could still try the two attached patch separately, without any of the previous workarounds. Based on the result, we'll follow up with a fix that adds for your specific platform either of the attached workarounds or simply avoids putting the device into D3 (corresponding to the patch you already tried). None of those patches made any difference. The laptop still hangs at power-off. Not really surprising, is it? Previous testing shows that the hang occurs at the pci_set_power_state(drm_dev-pdev, PCI_D3hot) call in the poweroff_late hook. It is hard to see how replacing it by an attempt to set D3cold, or adding any call after this point, could possibly change anything. The system is stil hanging at the pci_set_power_state() call. The generic pci-driver code will put the i915 device into PCI_D3hot for you, won't it? Why do you need to duplicate that in the driver, *knowing* that doing so breaks (at least some) systems? I honestly don't think this let's try some random code is the proper way to fix this bug (or any other bug for that matter). You need to start understanding the code you write, and the first step is by actually explaining the changes you make. I also believe that you completely miss the fact that this bug has survived a full release cycle before you became aware of it, and the implications this has wrt other affected systems/users. I assume you understand that my system isn't one-of-a-kind, This means that there are other affected users with identical/similar systems. Now, if none of those users reported the bug to you (we all know why: Linux kernel development is currently limited by the available testing resources, NOT by the available developer resources), then how do you know that there aren't a number of other systems affected as well? Let me answer that for you: You don't. Which is why you must explain the mechanism triggering the bug, proving that it is a chipset/system specific issue. Because that's the only way you will *know* that you have solved the problem not only for me, but for all affected users. IMHO, the only safe and sane solution at the moment is the revert patch I posted. It's a simple fix, reverting back to the *known* working state before this regression was introduced. Then you can start over from there, trying to implement this properly. Thanks, Bjørn ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/dp: indentation and ordering cleanups
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: Keep the DPCD macros ordered by address, and make indentation conform to the rest of the file. commit e045d20bef41707dbba676e58624b54f9f39e172 Author: Sonika Jindal sonika.jin...@intel.com Date: Thu Feb 19 13:16:44 2015 +0530 drm: Adding edp1.4 specific dpcd macros Signed-off-by: Jani Nikula jani.nik...@intel.com --- Daniel, this might be squashed into the above commit in the drm-misc tree. --- include/drm/drm_dp_helper.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index d4803224028f..98fefe45d158 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -92,9 +92,6 @@ # define DP_MSA_TIMING_PAR_IGNORED(1 6) /* eDP */ # define DP_OUI_SUPPORT (1 7) -#define DP_SUPPORTED_LINK_RATES 0x010 /*eDP 1.4*/ -#define DP_MAX_SUPPORTED_RATES 0x8 - #define DP_I2C_SPEED_CAP 0x00c/* DPI */ # define DP_I2C_SPEED_1K 0x01 # define DP_I2C_SPEED_5K 0x02 @@ -105,8 +102,12 @@ #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 3) /* edp v1.2 or higher */ + #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ +#define DP_SUPPORTED_LINK_RATES 0x010 /* eDP 1.4 */ +# define DP_MAX_SUPPORTED_RATES 8 /* 16-bit little-endian */ + /* Multiple stream transport */ #define DP_FAUX_CAP 0x020 /* 1.2 */ # define DP_FAUX_CAP_1(1 0) @@ -225,7 +226,7 @@ # define DP_UP_REQ_EN (1 1) # define DP_UPSTREAM_IS_SRC (1 2) -#define DP_LINK_RATE_SET 0x115 +#define DP_LINK_RATE_SET 0x115 /* eDP 1.4 */ #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE(1 0) @@ -338,7 +339,7 @@ # define DP_SET_POWER_D30x2 # define DP_SET_POWER_MASK 0x3 -#define DP_EDP_DPCD_REV 0x700 +#define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE 0x1200 /* 1.2 MST */ Reviewed-by: Sonika Jindal sonika.jin...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/dp: add DPCD definitions from DP 1.2a
On Wednesday 25 February 2015 06:16 PM, Jani Nikula wrote: Signed-off-by: Jani Nikula jani.nik...@intel.com --- include/drm/drm_dp_helper.h | 95 ++--- 1 file changed, 90 insertions(+), 5 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 98fefe45d158..209c5b91b0e8 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -92,6 +92,15 @@ # define DP_MSA_TIMING_PAR_IGNORED(1 6) /* eDP */ # define DP_OUI_SUPPORT (1 7) +#define DP_RECEIVE_PORT_0_CAP_0 0x008 /* XXX 1.2? */ This is part of DPv1.1 as well, the 1.2 in comment stands for DP version? +# define DP_LOCAL_EDID_PRESENT (1 1) +# define DP_ASSOCIATED_TO_PRECEDING_PORT(1 2) + +#define DP_RECEIVE_PORT_0_BUFFER_SIZE 0x009 + +#define DP_RECEIVE_PORT_1_CAP_00x00a +#define DP_RECEIVE_PORT_1_BUFFER_SIZE 0x00b + #define DP_I2C_SPEED_CAP 0x00c/* DPI */ # define DP_I2C_SPEED_1K 0x01 # define DP_I2C_SPEED_5K 0x02 @@ -101,10 +110,16 @@ # define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 0) +# define DP_FRAMING_CHANGE_CAP (1 1) # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 3) /* edp v1.2 or higher */ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ +#define DP_ADAPTER_CAP 0x00f /* 1.2 */ +# define DP_FORCE_LOAD_SENSE_CAP (1 0) +# define DP_ALTERNATE_I2C_PATTERN_CAP (1 1) + #define DP_SUPPORTED_LINK_RATES 0x010 /* eDP 1.4 */ # define DP_MAX_SUPPORTED_RATES8 /* 16-bit little-endian */ @@ -115,6 +130,44 @@ #define DP_MSTM_CAP 0x021 /* 1.2 */ # define DP_MST_CAP (1 0) +#define DP_NUMBER_OF_AUDIO_ENDPOINTS 0x022 /* 1.2 */ + +/* AV_SYNC_DATA_BLOCK 1.2 */ +#define DP_AV_GRANULARITY 0x023 +# define DP_AG_FACTOR_MASK (0xf 0) +# define DP_AG_FACTOR_3MS (0 0) +# define DP_AG_FACTOR_2MS (1 0) +# define DP_AG_FACTOR_1MS (2 0) +# define DP_AG_FACTOR_500US(3 0) +# define DP_AG_FACTOR_200US(4 0) +# define DP_AG_FACTOR_100US(5 0) +# define DP_AG_FACTOR_10US (6 0) +# define DP_AG_FACTOR_1US (7 0) +# define DP_VG_FACTOR_MASK (0xf 4) +# define DP_VG_FACTOR_3MS (0 4) +# define DP_VG_FACTOR_2MS (1 4) +# define DP_VG_FACTOR_1MS (2 4) +# define DP_VG_FACTOR_500US(3 4) +# define DP_VG_FACTOR_200US(4 4) +# define DP_VG_FACTOR_100US(5 4) + +#define DP_AUD_DEC_LAT00x024 +#define DP_AUD_DEC_LAT10x025 + +#define DP_AUD_PP_LAT0 0x026 +#define DP_AUD_PP_LAT1 0x027 + +#define DP_VID_INTER_LAT 0x028 + +#define DP_VID_PROG_LAT0x029 + +#define DP_REP_LAT 0x02a + +#define DP_AUD_DEL_INS00x02b +#define DP_AUD_DEL_INS10x02c +#define DP_AUD_DEL_INS20x02d +/* End of AV_SYNC_DATA_BLOCK */ + #define DP_GUID 0x030 /* 1.2 */ #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ @@ -173,11 +226,12 @@ # define DP_TRAINING_PATTERN_33 /* 1.2 */ # define DP_TRAINING_PATTERN_MASK 0x3 -# define DP_LINK_QUAL_PATTERN_DISABLE (0 2) -# define DP_LINK_QUAL_PATTERN_D10_2(1 2) -# define DP_LINK_QUAL_PATTERN_ERROR_RATE(2 2) -# define DP_LINK_QUAL_PATTERN_PRBS7(3 2) -# define DP_LINK_QUAL_PATTERN_MASK (3 2) +/* DPCD 1.1 only. For DPCD = 1.2 see per-lane DP_LINK_QUAL_LANEn_SET */ +# define DP_LINK_QUAL_PATTERN_11_DISABLE(0 2) +# define DP_LINK_QUAL_PATTERN_11_D10_2 (1 2) +# define DP_LINK_QUAL_PATTERN_11_ERROR_RATE (2 2) +# define DP_LINK_QUAL_PATTERN_11_PRBS7 (3 2) +# define DP_LINK_QUAL_PATTERN_11_MASK (3 2) # define DP_RECOVERED_CLOCK_OUT_EN (1 4) # define DP_LINK_SCRAMBLING_DISABLE (1 5) @@ -220,14 +274,45 @@ /* bitmask as for DP_I2C_SPEED_CAP */ #define DP_EDP_CONFIGURATION_SET0x10a /* XXX 1.2? */ +# define DP_ALTERNATE_SCRAMBLER_RESET_ENABLE (1 0) +# define DP_FRAMING_CHANGE_ENABLE (1 1) +# define DP_PANEL_SELF_TEST_ENABLE (1 7) + +#define DP_LINK_QUAL_LANE0_SET 0x10b /* DPCD = 1.2 */ +#define DP_LINK_QUAL_LANE1_SET 0x10c +#define DP_LINK_QUAL_LANE2_SET
[Intel-gfx] [PATCH 6/6] drm/i915: Include active flag when describing objects in debugfs
Since we use obj-active as a hint in many places throughout the code, knowing its state in debugfs is extremely useful. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 40eb3ec1a4b7..14f4f5f976be 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -123,8 +123,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) struct i915_vma *vma; int pin_count = 0; - seq_printf(m, %pK: %s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s, + seq_printf(m, %pK: %s%s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s, obj-base, + obj-active ? * : , get_pin_flag(obj), get_tiling_flag(obj), get_global_flag(obj), -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Free batch pool when idle
At runtime, this helps ensure that the batch pools are kept trim and
fast. Then at suspend, this releases memory that we do not need to
restore. It also ties into the oom-notifier to ensure that we recover as
much kernel memory as possible during OOM.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 42df2d3a69be..ce927bdadeaf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2842,8 +2842,19 @@ i915_gem_idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), mm.idle_work.work);
+ struct drm_device *dev = dev_priv-dev;
+
+ intel_mark_idle(dev);
- intel_mark_idle(dev_priv-dev);
+ if (mutex_trylock(dev-struct_mutex)) {
+ struct intel_engine_cs *ring;
+ int i;
+
+ for_each_ring(ring, dev_priv, i)
+ i915_gem_batch_pool_fini(ring-batch_pool);
+
+ mutex_unlock(dev-struct_mutex);
+ }
}
/**
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Simplify batch pool cache search
Combining list_del() with the list_for_each() is actually safe.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 41 +-
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index f1db6416d859..c0ad1f6503d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -97,10 +97,9 @@ struct drm_i915_gem_object *
i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
size_t size)
{
- struct drm_i915_gem_object *obj = NULL;
- struct drm_i915_gem_object *tmp, *next;
+ struct drm_i915_gem_object *obj;
struct list_head *list;
- int n;
+ int ret, n;
WARN_ON(!mutex_is_locked(pool-dev-struct_mutex));
@@ -109,37 +108,33 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
n = ARRAY_SIZE(pool-cache_list) - 1;
list = pool-cache_list[n];
- list_for_each_entry_safe(tmp, next, list, batch_pool_link) {
- if (tmp-active)
+ list_for_each_entry(obj, list, batch_pool_link) {
+ if (obj-active)
break;
/* While we're looping, do some clean up */
- if (tmp-madv == __I915_MADV_PURGED) {
- list_del(tmp-batch_pool_link);
- drm_gem_object_unreference(tmp-base);
+ if (obj-madv == __I915_MADV_PURGED) {
+ list_del(obj-batch_pool_link);
+ drm_gem_object_unreference(obj-base);
continue;
}
- if (tmp-base.size = size) {
- obj = tmp;
- break;
- }
+ if (obj-base.size = size)
+ goto out;
}
- if (obj == NULL) {
- int ret;
-
- obj = i915_gem_alloc_object(pool-dev, size);
- if (obj == NULL)
- return ERR_PTR(-ENOMEM);
+ /* None found, allocate a fresh bo and backing storage */
+ obj = i915_gem_alloc_object(pool-dev, size);
+ if (obj == NULL)
+ return ERR_PTR(-ENOMEM);
- ret = i915_gem_object_get_pages(obj);
- if (ret)
- return ERR_PTR(ret);
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ERR_PTR(ret);
- obj-madv = I915_MADV_DONTNEED;
- }
+ obj-madv = I915_MADV_DONTNEED;
+out:
list_move_tail(obj-batch_pool_link, list);
i915_gem_object_pin_pages(obj);
return obj;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Split batch pool into size buckets
Now with the trimmed memcpy before the command parser, we try to
allocate many different sizes of batches, predominantly one or two
pages. We can therefore speed up searching for a good sized batch by
keeping the objects of buckets of roughly the same size.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c| 46 +++---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 45 +
drivers/gpu/drm/i915/i915_gem_batch_pool.h | 2 +-
5 files changed, 60 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ddb3388aca5..40eb3ec1a4b7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -378,15 +378,17 @@ static void print_batch_pool_stats(struct seq_file *m,
struct drm_i915_gem_object *obj;
struct file_stats stats;
struct intel_engine_cs *ring;
- int i;
+ int i, j;
memset(stats, 0, sizeof(stats));
for_each_ring(ring, dev_priv, i) {
- list_for_each_entry(obj,
- ring-batch_pool.cache_list,
- batch_pool_list)
- per_file_stats(0, obj, stats);
+ for (j = 0; j ARRAY_SIZE(ring-batch_pool.cache_list); j++) {
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list[j],
+ batch_pool_link)
+ per_file_stats(0, obj, stats);
+ }
}
print_file_stats(m, batch pool, stats);
@@ -618,26 +620,38 @@ static int i915_gem_batch_pool_info(struct seq_file *m,
void *data)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
struct intel_engine_cs *ring;
- int count = 0;
- int ret, i;
+ int total = 0;
+ int ret, i, j;
ret = mutex_lock_interruptible(dev-struct_mutex);
if (ret)
return ret;
for_each_ring(ring, dev_priv, i) {
- seq_printf(m, %s cache:\n, ring-name);
- list_for_each_entry(obj,
- ring-batch_pool.cache_list,
- batch_pool_list) {
- seq_puts(m,);
- describe_obj(m, obj);
- seq_putc(m, '\n');
- count++;
+ for (j = 0; j ARRAY_SIZE(ring-batch_pool.cache_list); j++) {
+ int count;
+
+ count = 0;
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list[j],
+ batch_pool_link)
+ count++;
+ seq_printf(m, %s cache[%d]: %d objects\n,
+ ring-name, j, count);
+
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list[j],
+ batch_pool_link) {
+ seq_puts(m,);
+ describe_obj(m, obj);
+ seq_putc(m, '\n');
+ }
+
+ total += count;
}
}
- seq_printf(m, total: %d\n, count);
+ seq_printf(m, total: %d\n, total);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4425f3858b76..bb969e92fd7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1999,7 +1999,7 @@ struct drm_i915_gem_object {
/** Used in execbuf to temporarily hold a ref */
struct list_head obj_exec_link;
- struct list_head batch_pool_list;
+ struct list_head batch_pool_link;
/**
* This is set if the object is on the active lists (has pending
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ce927bdadeaf..d62825814d0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4397,7 +4397,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(obj-ring_list);
INIT_LIST_HEAD(obj-obj_exec_link);
INIT_LIST_HEAD(obj-vma_list);
- INIT_LIST_HEAD(obj-batch_pool_list);
+ INIT_LIST_HEAD(obj-batch_pool_link);
obj-ops = ops;
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 40ab2207fcb9..f1db6416d859 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++
[Intel-gfx] [PATCH 1/6] drm/i915: Split i915_gem_batch_pool into its own header
In the next patch, I want to use the structure elsewhere and so require
it defined earlier. Rather than move the definition to an earlier location
where it feels very odd, place it in its own header file.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h| 13 +
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 1 +
drivers/gpu/drm/i915/i915_gem_batch_pool.h | 42 ++
3 files changed, 44 insertions(+), 12 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60a66f6cef78..6246a224f15b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,6 +37,7 @@
#include intel_bios.h
#include intel_ringbuffer.h
#include intel_lrc.h
+#include i915_gem_batch_pool.h
#include i915_gem_gtt.h
#include i915_gem_render_state.h
#include linux/io-mapping.h
@@ -1251,11 +1252,6 @@ struct intel_l3_parity {
int which_slice;
};
-struct i915_gem_batch_pool {
- struct drm_device *dev;
- struct list_head cache_list;
-};
-
struct i915_gem_mm {
/** Memory allocator for GTT stolen memory */
struct drm_mm stolen;
@@ -3145,13 +3141,6 @@ void i915_destroy_error_state(struct drm_device *dev);
void i915_get_extra_instdone(struct drm_device *dev, uint32_t *instdone);
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
-/* i915_gem_batch_pool.c */
-void i915_gem_batch_pool_init(struct drm_device *dev,
- struct i915_gem_batch_pool *pool);
-void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
-struct drm_i915_gem_object*
-i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
-
/* i915_cmd_parser.c */
int i915_cmd_parser_get_version(void);
int i915_cmd_parser_init_ring(struct intel_engine_cs *ring);
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index aa477ddf12f1..40ab2207fcb9 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -23,6 +23,7 @@
*/
#include i915_drv.h
+#include i915_gem_batch_pool.h
/**
* DOC: batch pool
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
new file mode 100644
index ..5ed70ef6a887
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright © 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.
+ *
+ */
+
+#ifndef I915_GEM_BATCH_POOL_H
+#define I915_GEM_BATCH_POOL_H
+
+#include i915_drv.h
+
+struct i915_gem_batch_pool {
+ struct drm_device *dev;
+ struct list_head cache_list;
+};
+
+/* i915_gem_batch_pool.c */
+void i915_gem_batch_pool_init(struct drm_device *dev,
+ struct i915_gem_batch_pool *pool);
+void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
+struct drm_i915_gem_object*
+i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
+
+#endif /* I915_GEM_BATCH_POOL_H */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Split the batch pool by engine
I woke up one morning and found 50k objects sitting in the batch pool
and every search seemed to iterate the entire list... Painting the
screen in oils would provide a more fluid display.
One issue with the current design is that we only check for retirements
on the current ring when preparing to submit a new batch. This means
that we can have thousands of active batches on another ring that we
have to walk over. The simplest way to avoid that is to split the pools
per ring and then our LRU execution ordering will also ensure that the
inactive buffers remain at the front.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c| 33 ++
drivers/gpu/drm/i915/i915_dma.c| 1 -
drivers/gpu/drm/i915/i915_drv.h| 8
drivers/gpu/drm/i915/i915_gem.c| 2 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +--
drivers/gpu/drm/i915/intel_ringbuffer.c| 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.h| 8
7 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a76b2ed3a3cd..6ddb3388aca5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -377,13 +377,17 @@ static void print_batch_pool_stats(struct seq_file *m,
{
struct drm_i915_gem_object *obj;
struct file_stats stats;
+ struct intel_engine_cs *ring;
+ int i;
memset(stats, 0, sizeof(stats));
- list_for_each_entry(obj,
- dev_priv-mm.batch_pool.cache_list,
- batch_pool_list)
- per_file_stats(0, obj, stats);
+ for_each_ring(ring, dev_priv, i) {
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list,
+ batch_pool_list)
+ per_file_stats(0, obj, stats);
+ }
print_file_stats(m, batch pool, stats);
}
@@ -613,21 +617,24 @@ static int i915_gem_batch_pool_info(struct seq_file *m,
void *data)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
+ struct intel_engine_cs *ring;
int count = 0;
- int ret;
+ int ret, i;
ret = mutex_lock_interruptible(dev-struct_mutex);
if (ret)
return ret;
- seq_puts(m, cache:\n);
- list_for_each_entry(obj,
- dev_priv-mm.batch_pool.cache_list,
- batch_pool_list) {
- seq_puts(m,);
- describe_obj(m, obj);
- seq_putc(m, '\n');
- count++;
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, %s cache:\n, ring-name);
+ list_for_each_entry(obj,
+ ring-batch_pool.cache_list,
+ batch_pool_list) {
+ seq_puts(m,);
+ describe_obj(m, obj);
+ seq_putc(m, '\n');
+ count++;
+ }
}
seq_printf(m, total: %d\n, count);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f9992ca11d10..26f854f3c47b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1050,7 +1050,6 @@ int i915_driver_unload(struct drm_device *dev)
mutex_lock(dev-struct_mutex);
i915_gem_cleanup_ringbuffer(dev);
- i915_gem_batch_pool_fini(dev_priv-mm.batch_pool);
i915_gem_context_fini(dev);
mutex_unlock(dev-struct_mutex);
i915_gem_cleanup_stolen(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6246a224f15b..4425f3858b76 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,7 +37,6 @@
#include intel_bios.h
#include intel_ringbuffer.h
#include intel_lrc.h
-#include i915_gem_batch_pool.h
#include i915_gem_gtt.h
#include i915_gem_render_state.h
#include linux/io-mapping.h
@@ -1265,13 +1264,6 @@ struct i915_gem_mm {
*/
struct list_head unbound_list;
- /*
-* A pool of objects to use as shadow copies of client batch buffers
-* when the command parser is enabled. Prevents the client from
-* modifying the batch contents after software parsing.
-*/
- struct i915_gem_batch_pool batch_pool;
-
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 51ac13811e19..42df2d3a69be 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5011,8
[Intel-gfx] [PATCH v2] drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions
From: Akash Goel akash.g...@intel.com
The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register
are stored, initially by the Driver, inside the dev_priv-rps structure.
Since these values are expected to remain same throughout, there is no real
need to read this register, on dynamic basis, from certain debugfs/sysfs
functions and the values can be instead retrieved from the dev_priv-rps
structure when needed.
For the i915_frequency_info debugfs interface, the frequency values from the
RP_STATE_CAP register only should be used, to indicate the actual Hw state,
since it is principally used for the debugging purpose.
v2: Reverted the changes in i915_frequency_info function, to continue report
back the frequency values, as per the actual Hw state (Chris)
Signed-off-by: Akash Goel akash.g...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 --
drivers/gpu/drm/i915/i915_sysfs.c | 39 +
2 files changed, 17 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 26e9c7b..3e1e5d3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4191,7 +4191,7 @@ i915_max_freq_set(void *data, u64 val)
{
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 rp_state_cap, hw_max, hw_min;
+ u32 hw_max, hw_min;
int ret;
if (INTEL_INFO(dev)-gen 6)
@@ -4208,18 +4208,10 @@ i915_max_freq_set(void *data, u64 val)
/*
* Turbo will still be enabled, but won't go above the set value.
*/
- if (IS_VALLEYVIEW(dev)) {
- val = intel_freq_opcode(dev_priv, val);
+ val = intel_freq_opcode(dev_priv, val);
- hw_max = dev_priv-rps.max_freq;
- hw_min = dev_priv-rps.min_freq;
- } else {
- val = intel_freq_opcode(dev_priv, val);
-
- rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
- hw_max = dev_priv-rps.max_freq;
- hw_min = (rp_state_cap 16) 0xff;
- }
+ hw_max = dev_priv-rps.max_freq;
+ hw_min = dev_priv-rps.min_freq;
if (val hw_min || val hw_max || val
dev_priv-rps.min_freq_softlimit) {
mutex_unlock(dev_priv-rps.hw_lock);
@@ -4266,7 +4258,7 @@ i915_min_freq_set(void *data, u64 val)
{
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 rp_state_cap, hw_max, hw_min;
+ u32 hw_max, hw_min;
int ret;
if (INTEL_INFO(dev)-gen 6)
@@ -4283,18 +4275,10 @@ i915_min_freq_set(void *data, u64 val)
/*
* Turbo will still be enabled, but won't go below the set value.
*/
- if (IS_VALLEYVIEW(dev)) {
- val = intel_freq_opcode(dev_priv, val);
+ val = intel_freq_opcode(dev_priv, val);
- hw_max = dev_priv-rps.max_freq;
- hw_min = dev_priv-rps.min_freq;
- } else {
- val = intel_freq_opcode(dev_priv, val);
-
- rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
- hw_max = dev_priv-rps.max_freq;
- hw_min = (rp_state_cap 16) 0xff;
- }
+ hw_max = dev_priv-rps.max_freq;
+ hw_min = dev_priv-rps.min_freq;
if (val hw_min || val hw_max || val
dev_priv-rps.max_freq_softlimit) {
mutex_unlock(dev_priv-rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index cdc9da0..186ab95 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -487,38 +487,17 @@ static ssize_t gt_rp_mhz_show(struct device *kdev, struct
device_attribute *attr
struct drm_minor *minor = dev_to_drm_minor(kdev);
struct drm_device *dev = minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 val, rp_state_cap;
- ssize_t ret;
-
- ret = mutex_lock_interruptible(dev-struct_mutex);
- if (ret)
- return ret;
- intel_runtime_pm_get(dev_priv);
- rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
- intel_runtime_pm_put(dev_priv);
- mutex_unlock(dev-struct_mutex);
+ u32 val;
- if (attr == dev_attr_gt_RP0_freq_mhz) {
- if (IS_VALLEYVIEW(dev))
- val = intel_gpu_freq(dev_priv, dev_priv-rps.rp0_freq);
- else
- val = intel_gpu_freq(dev_priv,
-((rp_state_cap 0xff) 0));
- } else if (attr == dev_attr_gt_RP1_freq_mhz) {
- if (IS_VALLEYVIEW(dev))
- val = intel_gpu_freq(dev_priv, dev_priv-rps.rp1_freq);
- else
- val = intel_gpu_freq(dev_priv,
-((rp_state_cap 0x00ff00) 8));
- }
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On Thu, Feb 26, 2015 at 11:26:10AM +0200, Mika Kahola wrote: In a case when DP link has been once trained we can reuse the existing link training parameters i.e. voltage swing and pre-emphasis levels from cache when there is a need to restart link training. In a case of eDP we initially try to train the link by using the parameter set that we can find from VBT. The fallback on both cases is to reset the link training parameters and restart. I don't think the fallback from bad VBT values works as on failure they just get reset. Care to enlighten me? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Rotation property is now handled in DRM core
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
So no need to have code which never gets called in the driver.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 9e6f727..976b891 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -203,16 +203,8 @@ intel_plane_atomic_get_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t *val)
{
- struct drm_mode_config *config = plane-dev-mode_config;
-
- if (property == config-rotation_property) {
- *val = state-rotation;
- } else {
- DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
- return -EINVAL;
- }
-
- return 0;
+ DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
+ return -EINVAL;
}
/**
@@ -233,14 +225,6 @@ intel_plane_atomic_set_property(struct drm_plane *plane,
struct drm_property *property,
uint64_t val)
{
- struct drm_mode_config *config = plane-dev-mode_config;
-
- if (property == config-rotation_property) {
- state-rotation = val;
- } else {
- DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
- return -EINVAL;
- }
-
- return 0;
+ DRM_DEBUG_KMS(Unknown plane property '%s'\n, property-name);
+ return -EINVAL;
}
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm: Complete moving rotation property to core
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Commit 1da30627fc511a57c9bd23a02c97f0576379f761 drm: Add rotation value to
plane state moved the rotation property to DRM core but only did the set
property part. This does the get property part as well.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/drm_atomic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 321e098..7ca54cb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -450,6 +450,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state-src_w;
} else if (property == config-prop_src_h) {
*val = state-src_h;
+ } else if (property == config-rotation_property) {
+ *val = state-rotation;
} else if (plane-funcs-atomic_get_property) {
return plane-funcs-atomic_get_property(plane, state,
property, val);
} else {
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add missing description to parameter in alloc_pt_range
The patch drm/i915: Plumb drm_device through page tables operations
added an extra parameter, but it didn't update the function description.
Also remove unnecessary blank line added by the same patch.
Found by kbuild test robot.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e05488e..5eea745 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -309,6 +309,7 @@ static struct i915_page_table_entry *alloc_pt_single(struct
drm_device *dev)
* available to point to the allocated page tables.
* @pde: First page directory entry for which we are allocating.
* @count: Number of pages to allocate.
+ * @dev: DRM device.
*
* Allocates multiple page table pages and sets the appropriate entries in the
* page table structure within the page directory. Function cleans up after
@@ -318,7 +319,6 @@ static struct i915_page_table_entry *alloc_pt_single(struct
drm_device *dev)
*/
static int alloc_pt_range(struct i915_page_directory_entry *pd, uint16_t pde,
size_t count,
struct drm_device *dev)
-
{
int i, ret;
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
