Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote: On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote: I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff but I couldn't test them yet since no dp mst here and I didn't find anything that would ship faster than 1-2 weeks yet. I'll try to get some other people here to test it meanwhile too. I've tried pulling in your patches from fixes-stuff, onto Linus's tree (without Linus's fix), and the good news is that I'm no longer crashing on boot. The *bad* news is that (a) it breaks the external monitor attached to the docking station completely (this was working with Linus's patch), and (b) it's triggering a LOCKDEP failure. So even though Linus's patch wasn't supposed to work, I think I'm going to back to it Ok I updated fixes-stuff with just 2 patches which seem to be enough to fix it. Plus a patch to convert Linus' hack into something we can keep plus a drive-by WARNING fix in mst that got in the way for me. Seems to work here in getting rid of the Oops. If this tests out for you too I'll send a pull to Linus. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body
On Mon, Aug 03, 2015 at 08:37:41AM -0600, Jonathan Corbet wrote: On Mon, 3 Aug 2015 10:23:19 +0200 Daniel Vetter dan...@ffwll.ch wrote: I'm wondering if we need a kernel summit session on commenting conventions, markdown-in-kerneldoc, etc? Maybe I'll stick a proposal out there. Might be useful, but I'm not sure how many people really would actively work on improving the tooling. The only comment I've seen is to maybe use gtkdoc, but that would be a pain since it's slightly incompatible with kerneldoc. The idea was to get a sense for what sort of improvements would be useful, to begin with. But my attempt to start a discussion on the kernel summit list appears to have hit the ground pretty hard; I guess that means I have free rein :) Wrt feature wishlists the 3 things Danilo has worked on thus far (hyperlinks, markdown and inline struct member kerneldoc) are really the things I'd like to have. Of course there's room for some more prettification, but I think that would better fit as improvements to pandoc. One example is more flexible table handling with row/column spanning - currently pandoc doesn't handle that in the docbook converter. I expect I'll apply the struct-args doc patch in the fairly near future. Then we'll see if others complain when patches using it start to show up, but the feature itself shouldn't break anything. I'm *really* hoping to take a hard look at Danilo's stuff for a 4.3 merge as well. It should be possible, but there's real-world obnoxiousness that is doing its best to get in the way. Awesome. Missing 4.3 wouldn't be a big deal for i915 really since drm feature freeze should happen around -rc5 anyway, so everything new I pull in will be for 4.4 only. But getting it in early always helps, just in case there's something unexpected. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/atomic-helpers: Make encoder picking more robust
We've had a few issues with atomic where subtle bugs in the encoder
picking logic lead to accidental self-stealing of the encoder,
resulting in a NULL connector_state-crtc in update_connector_routing
and subsequent.
Linus applied some duct-tape for an mst regression in
commit 27667f4744fc5a0f3e50910e78740bac5670d18b
Author: Linus Torvalds torva...@linux-foundation.org
Date: Wed Jul 29 22:18:16 2015 -0700
i915: temporary fix for DP MST docking station NULL pointer dereference
But that was incomplete (the code will still oops when debuggin is
enabled) and mangled the state even further. So instead WARN and bail
out as the more future-proof option.
Cc: Theodore Ts'o ty...@mit.edu
Cc: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 8694ca9beee3..9dcc7280e572 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -234,13 +234,14 @@ update_connector_routing(struct drm_atomic_state *state,
int conn_idx)
}
}
+ if (WARN_ON(!connector_state-crtc))
+ return -EINVAL;
+
connector_state-best_encoder = new_encoder;
- if (connector_state-crtc) {
- idx = drm_crtc_index(connector_state-crtc);
+ idx = drm_crtc_index(connector_state-crtc);
- crtc_state = state-crtc_states[idx];
- crtc_state-mode_changed = true;
- }
+ crtc_state = state-crtc_states[idx];
+ crtc_state-mode_changed = true;
DRM_DEBUG_ATOMIC([CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
[CRTC:%d]\n,
connector-base.id,
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/dp-mst: Remove debug WARN_ON
Apparently been in there since forever and fairly easy to hit when hotplugging really fast. I can do that since my mst hub has a manual button to flick the hpd line for reprobing. The resulting WARNING spam isn't pretty. Cc: Dave Airlie airl...@gmail.com Cc: sta...@vger.kernel.org Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/drm_dp_mst_topology.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 778bbb6425b8..b0487c9f018c 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1294,7 +1294,6 @@ retry: goto retry; } DRM_DEBUG_KMS(failed to dpcd write %d %d\n, tosend, ret); - WARN(1, fail\n); return -EIO; } -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/atomic-helper: Add an atomice best_encoder callback
With legacy helpers all the routing was already set up when calling
best_encoder and so could be inspected. But with atomic it's staged,
hence we need a new atomic compliant callback for drivers which need
to inspect the requested state and can't just decided the best encoder
statically.
This is needed to fix up i915 dp mst where we need to pick the right
encoder depending upon the requested CRTC for the connector.
v2: Don't forget to amend the kerneldoc
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Theodore Ts'o ty...@mit.edu
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
include/drm/drm_crtc_helper.h | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index aac212297b49..8694ca9beee3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -196,7 +196,12 @@ update_connector_routing(struct drm_atomic_state *state,
int conn_idx)
}
funcs = connector-helper_private;
- new_encoder = funcs-best_encoder(connector);
+
+ if (funcs-atomic_best_encoder)
+ new_encoder = funcs-atomic_best_encoder(connector,
+connector_state);
+ else
+ new_encoder = funcs-best_encoder(connector);
if (!new_encoder) {
DRM_DEBUG_ATOMIC(No suitable encoder found for
[CONNECTOR:%d:%s]\n,
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index c8fc187061de..918aa68b5199 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -168,6 +168,7 @@ struct drm_encoder_helper_funcs {
* @get_modes: get mode list for this connector
* @mode_valid: is this mode valid on the given connector? (optional)
* @best_encoder: return the preferred encoder for this connector
+ * @atomic_best_encoder: atomic version of @best_encoder
*
* The helper operations are called by the mid-layer CRTC helper.
*/
@@ -176,6 +177,8 @@ struct drm_connector_helper_funcs {
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
struct drm_encoder *(*best_encoder)(struct drm_connector *connector);
+ struct drm_encoder *(*atomic_best_encoder)(struct drm_connector
*connector,
+ struct drm_connector_state
*connector_state);
};
extern void drm_helper_disable_unused_functions(struct drm_device *dev);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Fixup dp mst encoder selection
In
commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
Author: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Date: Tue Apr 21 17:13:19 2015 +0300
drm/i915: Use atomic helpers for computing changed flags
we've switched over to the atomic version to compute the
crtc-encoder-connector routing from the i915 variant. That one
relies upon the -best_encoder callback, but the i915-private version
relied upon intel_find_encoder. Which didn't matter except for dp mst,
where the encoder depends upon the selected crtc.
Fix this functional bug by implemented a correct atomic-state based
encoder selector for dp mst.
Note that we can't get rid of the legacy best_encoder callback since
the fbdev emulation uses that still. That means it's incorrect there
still, but that's been the case ever since i915 dp mst support was
merged so not a regression. Best to fix that by converting fbdev over
to atomic too.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Theodore Ts'o ty...@mit.edu
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/i915/intel_dp_mst.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 6e4cc5334f47..600afdbef8c9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -357,6 +357,16 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
+static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector
*connector,
+struct
drm_connector_state *state)
+{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_dp *intel_dp = intel_connector-mst_port;
+ struct intel_crtc *crtc = to_intel_crtc(state-crtc);
+
+ return intel_dp-mst_encoders[crtc-pipe]-base.base;
+}
+
static struct drm_encoder *intel_mst_best_encoder(struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -367,6 +377,7 @@ static struct drm_encoder *intel_mst_best_encoder(struct
drm_connector *connecto
static const struct drm_connector_helper_funcs
intel_dp_mst_connector_helper_funcs = {
.get_modes = intel_dp_mst_get_modes,
.mode_valid = intel_dp_mst_mode_valid,
+ .atomic_best_encoder = intel_mst_atomic_best_encoder,
.best_encoder = intel_mst_best_encoder,
};
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body
On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.
Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
* struct my_struct - short description
* @a: first member
* @b: second member
*
* Longer description
*/
struct my_struct {
int a;
int b;
/**
* @c: This is longer description of C
*
* You can use paragraphs to describe arguments
* using this method.
*/
int c;
};
This patch allows the use of this kind of syntax. Only one argument
per comment and user can use how many paragraphs he needs. It should
start with /**, which is already being used by kernel-doc. If those
comment doesn't follow those rules, it will be ignored.
Signed-off-by: Danilo Cesar Lemes de Paula danilo.ce...@collabora.co.uk
Cc: Randy Dunlap rdun...@infradead.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Jonathan Corbet cor...@lwn.net
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Stephan Mueller smuel...@chronox.de
Cc: Michal Marek mma...@suse.cz
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx intel-gfx@lists.freedesktop.org
Cc: dri-devel dri-de...@lists.freedesktop.org
---
scripts/kernel-doc | 80
--
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66..9bfa8b9 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -133,6 +133,30 @@ use strict;
#
# All descriptions can be multiline, except the short function description.
#
+# For really longs structs, you can also describe arguments inside the
+# body of the struct.
+# eg.
+# /**
+# * struct my_struct - short description
+# * @a: first member
+# * @b: second member
+# *
+# * Longer description
+# */
+# struct my_struct {
+# int a;
+# int b;
+# /**
+# * @c: This is longer description of C
+# *
+# * You can use paragraphs to describe arguments
+# * using this method.
+# */
+# int c;
+# };
+#
+# This should be use for arguments only.
used
What are arguments in this context? do you mean struct fields or members?
+#
# You can also add additional sections. When documenting kernel functions you
# should document the Context: of the function, e.g. whether the functions
# can be called form interrupts. Unlike other sections you can end it with an
@@ -287,9 +311,19 @@ my $lineprefix=;
# 2 - scanning field start.
# 3 - scanning prototype.
# 4 - documentation block
+# 5 - gathering documentation outside main block
my $state;
my $in_doc_sect;
+# Split Doc State
+# 0 - Invalid (Before start or after finish)
+# 1 - Is started (the /** was found inside a struct)
+# 2 - The @parameter header was found, start accepting multi paragraph text.
+# 3 - Finished (the */ was found)
+# 4 - Error - Comment without header was found. Spit a warning as it's not
+# proper kernel-doc and ignore the rest.
+my $split_doc_state;
+
#declaration types: can be
# 'function', 'struct', 'union', 'enum', 'typedef'
my $decl_type;
@@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
my $doc_content = $doc_com_body . '(.*)';
my $doc_block = $doc_com . 'DOC:\s*(.*)?';
+my $doc_split_start = '^\s*/\*\*\s*$';
+my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
+my $doc_split_end = '^\s*\*/\s*$';
my %constants;
my %parameterdescs;
@@ -2181,6 +2218,7 @@ sub reset_state {
$prototype = ;
$state = 0;
+$split_doc_state = 0;
}
sub tracepoint_munge($) {
@@ -2453,7 +2491,6 @@ sub process_file($) {
}
$section = $newsection;
} elsif (/$doc_end/) {
-
if (($contents ne ) ($contents ne \n)) {
dump_section($file, $section, xml_escape($contents));
$section = $section_default;
@@ -2494,8 +2531,47 @@ sub process_file($) {
print STDERR Warning(${file}:$.): bad line: $_;
++$warnings;
}
+ } elsif ($state == 5) { # scanning for split parameters
+
+ # First line (state 1) needs to be a @parameter
+ if ($split_doc_state == 1 /$doc_split_sect/o) {
+ $section = $1;
+ $contents = $2;
+ if ($contents ne ) {
+ while ((substr($contents, 0, 1) eq ) ||
+ substr($contents, 0, 1) eq \t) {
+ $contents = substr($contents, 1);
+ }
+ $contents .= \n;
+ }
+ $split_doc_state = 2;
Re: [Intel-gfx] [PATCH] drm/i915: Postpone plane readout until after encoder readout
Hey,
Op 31-07-15 om 15:04 schreef Patrik Jakobsson:
When reading out hw state for planes we disable inactive planes which in
turn triggers an update of the watermarks. The update depends on the
crtc_clock being set which is done when reading out encoders. Thus
postpone the plane readout until after encoder readout.
This prevents a warning in skl_compute_linetime_wm() where pixel_rate
becomes 0 when crtc_clock is 0.
Running this on skylake it looks like like it's a partial fix.
You would need to move hwmode like below too?
Also:
References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index add7f807a82d..49907f4e939a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14888,8 +14888,6 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc-base.state-mode.private_flags =
I915_MODE_FLAG_INHERITED;
}
- crtc-base.hwmode = crtc-config-base.adjusted_mode;
-
DRM_DEBUG_KMS([CRTC:%d] hw state readout: %s\n,
crtc-base.base.id,
crtc-active ? enabled : disabled);
@@ -14971,6 +14969,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
for_each_pipe(dev_priv, pipe) {
crtc = to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
+ crtc-base.hwmode = crtc-config-base.adjusted_mode;
for_each_intel_plane(crtc-base.dev, plane) {
if (crtc-pipe != plane-pipe)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body
On Mon, 3 Aug 2015 10:23:19 +0200 Daniel Vetter dan...@ffwll.ch wrote: I'm wondering if we need a kernel summit session on commenting conventions, markdown-in-kerneldoc, etc? Maybe I'll stick a proposal out there. Might be useful, but I'm not sure how many people really would actively work on improving the tooling. The only comment I've seen is to maybe use gtkdoc, but that would be a pain since it's slightly incompatible with kerneldoc. The idea was to get a sense for what sort of improvements would be useful, to begin with. But my attempt to start a discussion on the kernel summit list appears to have hit the ground pretty hard; I guess that means I have free rein :) I expect I'll apply the struct-args doc patch in the fairly near future. Then we'll see if others complain when patches using it start to show up, but the feature itself shouldn't break anything. I'm *really* hoping to take a hard look at Danilo's stuff for a 4.3 merge as well. It should be possible, but there's real-world obnoxiousness that is doing its best to get in the way. jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3] Android.mk: Disable tools that do not build for android
On 17/07/15 09:53, Morton, Derek J wrote: -Original Message- From: Morton, Derek J Sent: Friday, July 17, 2015 9:44 AM To: intel-gfx@lists.freedesktop.org Cc: Wood, Thomas; Morton, Derek J Subject: [PATCH i-g-t v3] Android.mk: Disable tools that do not build for android Disable the tools / demo code that do not currently build for android until they can be fixed. Affected tools / demos intel_display_crc intel_sprite_on v2: intel_display_crc compiled conditionally on ANDROID_HAS_CAIRO flag. v3: removed intel_reg from the skip list as Thomas has prepared a patch to fix it for Android. Signed-off-by: Derek Morton derek.j.mor...@intel.com --- Android.mk | 2 +- tools/Android.mk | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/Android.mk b/Android.mk index 1ab3e64..681d114 100644 --- a/Android.mk +++ b/Android.mk @@ -1,2 +1,2 @@ -include $(call all-named-subdir-makefiles, lib tests tools benchmarks demos) +include $(call all-named-subdir-makefiles, lib tests tools benchmarks) diff --git a/tools/Android.mk b/tools/Android.mk index 39f4512..4be0032 100644 --- a/tools/Android.mk +++ b/tools/Android.mk @@ -37,10 +37,15 @@ endef skip_tools_list := \ intel_framebuffer_dump \ +intel_reg \ That's weird, git diff HEAD^ shows this being removed but git format-patch HEAD^ has left it in. The relevant man pages say: git diff [--options] commit [--] [path...] This form is to view the changes you have in your working tree relative to the named commit. You can use HEAD to compare it with the latest commit, or a branch name to compare with the tip of a different branch. git format-patch [-k] [(-o|--output-directory) dir | --stdout] ... [common diff options] [ since | revision range ] So git format-patch HEAD^ is describing the changes between HEAD^ and HEAD i.e. 'since' == HEAD^, equivalent to revision range HEAD^..HEAD Whereas git diff HEAD^ is comparing the commit referenced by HEAD^ with the current working tree (which might differ from HEAD). They'll be different if you have uncommitted changes in your working tree! .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware
This patch contains the changes to remove the byte
swapping logic introduced with old dmc firmware.
While debugging PC10 entry issue for skylake found
with latest dmc firmware version 1.18 without byte
swapping dmc is working fine and able to enter PC10.
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_csr.c | 16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b94ada9..9d0ee58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -742,7 +742,7 @@ enum csr_state {
struct intel_csr {
const char *fw_path;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
uint32_t dmc_fw_size;
uint32_t mmio_count;
uint32_t mmioaddr[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf..ba1ae03 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -244,7 +244,7 @@ void intel_csr_load_status_set(struct drm_i915_private
*dev_priv,
void intel_csr_load_program(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- __be32 *payload = dev_priv-csr.dmc_payload;
+ u32 *payload = dev_priv-csr.dmc_payload;
uint32_t i, fw_size;
if (!IS_GEN9(dev)) {
@@ -256,7 +256,7 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv-csr.dmc_fw_size;
for (i = 0; i fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
- (u32 __force)payload[i]);
+ payload[i]);
for (i = 0; i dev_priv-csr.mmio_count; i++) {
I915_WRITE(dev_priv-csr.mmioaddr[i],
@@ -279,7 +279,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
char substepping = intel_get_substepping(dev);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
bool fw_loaded = false;
if (!fw) {
@@ -375,15 +375,7 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
}
dmc_payload = csr-dmc_payload;
- for (i = 0; i dmc_header-fw_size; i++) {
- uint32_t *tmp = (u32 *)fw-data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = cpu_to_be32(*tmp);
- }
+ memcpy(dmc_payload, fw-data[readcount], nbytes);
/* load csr program during system boot, as needed for DC states */
intel_csr_load_program(dev);
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [SKL-DMC-BUGFIX 4/5] drm/i915/skl: Block disable call for pw1 if dmc firmware is present.
Another interesting criteria to work dmc as expected is pw1 to be
enabled by driver and dmc will shut it off in its execution
sequence. If already disabled by driver dmc will get confuse and
behave differently than expected found during pc10 entry issue
for skl.
So berfore we disable power-well 1, added check if dmc firmware is
present and driver will not disable power well 1, but for any reason
if firmware is not present of failed to load we can shut off the
power well 1 which will save some power.
As skl is currently fully dependent on dmc to go in lowest possible
power state (dc6) but the same is not applicable for bxt. Display
engine can enter into dc9 without dmc, hence unblocking disable call.
v1: Initial version.
v2: Based on revire commnents from Sunil,
- condition check for pw1 is moved in skl_set_power_well.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index c660245..00cd4ff 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -636,9 +636,15 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
}
} else {
if (enable_requested) {
- I915_WRITE(HSW_PWR_WELL_DRIVER, tmp ~req_mask);
- POSTING_READ(HSW_PWR_WELL_DRIVER);
- DRM_DEBUG_KMS(Disabling %s\n, power_well-name);
+ if (IS_SKYLAKE(dev)
+ (power_well-data == SKL_DISP_PW_1)
+ (intel_csr_load_status_get(dev_priv) ==
FW_LOADED))
+ DRM_DEBUG_KMS(Not Disabling PW1, dmc will
handle\n);
+ else {
+ I915_WRITE(HSW_PWR_WELL_DRIVER, tmp
~req_mask);
+ POSTING_READ(HSW_PWR_WELL_DRIVER);
+ DRM_DEBUG_KMS(Disabling %s\n,
power_well-name);
+ }
if (GEN9_ENABLE_DC5(dev)
power_well-data == SKL_DISP_PW_2)
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [SKL-DMC-BUGFIX 0/5] SKL PC10 entry fixes.
The following patches helps to solve PC10 entry issue for SKL. Detailed description about the changes done to solve the issue is mentioned in commit message of each patch. All these patches are send earlier for review as part of Redesign of dmc firmware loading patch series. Now skl specific bug-fixes are seperated out and sending as seperate patch series to make it simple. Animesh Manna (5): drm/i915/gen9: Removed byte swapping for csr firmware drm/i915/skl: Making DC6 entry is the last call in suspend flow. drm/i915/skl: Do not disable cdclk PLL if csr firmware is present. drm/i915/skl: Block disable call for pw1 if dmc firmware is present. drm/i915/skl: Removed csr firmware load in resume path. drivers/gpu/drm/i915/i915_drv.c | 13 +- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_csr.c| 16 +++- drivers/gpu/drm/i915/intel_display.c| 11 +--- drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 45 + 6 files changed, 37 insertions(+), 52 deletions(-) -- 2.0.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [SKL-DMC-BUGFIX 5/5] drm/i915/skl: Removed csr firmware load in resume path
As csr firmware is taking care of loading the firmware,
so no need for driver to load again.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e1d0102..02019e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1066,13 +1066,10 @@ static int bxt_resume_prepare(struct drm_i915_private
*dev_priv)
static int skl_resume_prepare(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = dev_priv-dev;
-
if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
skl_disable_dc6(dev_priv);
skl_init_cdclk(dev_priv);
- intel_csr_load_program(dev);
return 0;
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [SKL-DMC-BUGFIX 3/5] drm/i915/skl: Do not disable cdclk PLL if csr firmware is present.
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properly.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-bt: Vathsala Nagaraju vathsala.nagar...@intel.com
Signed-off-by: Rajneesh Bhardwaj rajneesh.bhard...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..ef2ef4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5675,10 +5675,13 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
if (I915_READ(DBUF_CTL) DBUF_POWER_STATE)
DRM_ERROR(DBuf power disable timeout\n);
- /* disable DPLL0 */
- I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) ~LCPLL_PLL_ENABLE);
- if (wait_for(!(I915_READ(LCPLL1_CTL) LCPLL_PLL_LOCK), 1))
- DRM_ERROR(Couldn't disable DPLL0\n);
+ if (dev_priv-csr.dmc_payload) {
+ /* disable DPLL0 */
+ I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL)
+ ~LCPLL_PLL_ENABLE);
+ if (wait_for(!(I915_READ(LCPLL1_CTL) LCPLL_PLL_LOCK), 1))
+ DRM_ERROR(Couldn't disable DPLL0\n);
+ }
intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote: Ok I updated fixes-stuff with just 2 patches which seem to be enough to fix it. Plus a patch to convert Linus' hack into something we can keep plus a drive-by WARNING fix in mst that got in the way for me. Seems to work here in getting rid of the Oops. If this tests out for you too I'll send a pull to Linus. I've just tried pulling in your updated fixes-stuff, and it avoids the oops and allows external the monitor to work correctly. However, I'm still seeing a large number of drm/i915 related warning messages and other kernel kvetching. Thanks!! - Ted [4.084198] [drm] Initialized drm 1.1.0 20060810 [4.129576] [drm] Memory usable by graphics device = 2048M [4.129616] [drm] Replacing VGA console driver [4.130315] Console: switching to colour dummy device 80x25 [4.145332] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [4.145334] [drm] Driver supports precise vblank timestamp query. [4.146184] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [4.163778] usbcore: registered new interface driver btusb [4.170719] [ cut here ] [4.170749] WARNING: CPU: 0 PID: 463 at /usr/projects/linux/linux/drivers/gpu/drm/i915/intel_pm.c:2339 ilk_update_wm+0x71a/0xb27 [i915]() [4.170751] WARN_ON(!r-enable) [4.170752] Modules linked in: [4.170754] btusb btrtl btbcm btintel iwlmvm(+) bluetooth mac80211 iwlwifi snd_hda_intel i915(+) drm_kms_helper snd_hda_codec cfg80211 drm snd_hwdep lpc_ich snd_hda_core intel_gtt thinkpad_acpi tpm_tis nvram tpm intel_smartconnect uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core sch_fq_codel kvm_intel kvm ecryptfs parport_pc ppdev lp parport autofs4 btrfs xor hid_generic usbhid hid raid6_pq microcode rtsx_pci_sdmmc ehci_pci e1000e rtsx_pci ehci_hcd xhci_pci ptp mfd_core pps_core xhci_hcd [4.170805] CPU: 0 PID: 463 Comm: systemd-udevd Not tainted 4.2.0-rc5-14194-g130583b #18 [4.170807] Hardware name: LENOVO 20BECTO1WW/20BECTO1WW, BIOS GMET59WW (2.07 ) 02/12/2014 [4.170809] 0009 880403f0f4c8 8161aaee 0006 [4.170814] 880403f0f518 880403f0f508 8107e5f0 0006 [4.170818] c05ade43 8800c8b7 8800c7f16000 880405fb48b8 [4.170823] Call Trace: [4.170829] [8161aaee] dump_stack+0x4c/0x65 [4.170833] [8107e5f0] warn_slowpath_common+0xa1/0xbb [4.170856] [c05ade43] ? ilk_update_wm+0x71a/0xb27 [i915] [4.170859] [8107e650] warn_slowpath_fmt+0x46/0x48 [4.170879] [c05abb1e] ? ilk_compute_wm_maximums+0x43/0xa2 [i915] [4.170899] [c05ade43] ilk_update_wm+0x71a/0xb27 [i915] [4.170921] [c05afb2b] intel_update_watermarks+0x1e/0x20 [i915] [4.170957] [c05ff8d4] haswell_crtc_disable+0x270/0x2ae [i915] [4.170989] [c060199d] intel_crtc_control+0xa0/0xe1 [i915] [4.171020] [c0601a2b] intel_crtc_update_dpms+0x4d/0x5d [i915] [4.171052] [c0607dd9] intel_modeset_setup_hw_state+0x7b0/0xa90 [i915] [4.171081] [c05ec6de] ? hsw_write64+0xcd/0xcd [i915] [4.171113] [c060ab44] ? ilk_fbc_disable+0x29/0x69 [i915] [4.171142] [c0609512] intel_modeset_init+0x130d/0x14e3 [i915] [4.171179] [c0636962] i915_driver_load+0xf05/0x1139 [i915] [4.171183] [810ba787] ? mark_held_locks+0x56/0x6c [4.171186] [81620c06] ? _raw_spin_unlock_irqrestore+0x3f/0x4d [4.171189] [810ba90e] ? trace_hardirqs_on_caller+0x171/0x18d [4.171204] [c042cf19] drm_dev_register+0x84/0xfd [drm] [4.171215] [c042f77e] drm_get_pci_dev+0x102/0x1bc [drm] [4.171237] [c05a61e2] i915_pci_probe+0x4f/0x51 [i915] [4.171240] [81333c33] pci_device_probe+0x74/0xd6 [4.171245] [813d4b8e] ? driver_probe_device+0x387/0x387 [4.171248] [813d4966] driver_probe_device+0x15f/0x387 [4.171250] [813d4b8e] ? driver_probe_device+0x387/0x387 [4.171252] [813d4be1] __driver_attach+0x53/0x74 [4.171255] [813d2c00] bus_for_each_dev+0x6f/0x89 [4.171257] [813d4350] driver_attach+0x1e/0x20 [4.171260] [813d3f93] bus_add_driver+0x140/0x238 [4.171263] [813d5538] driver_register+0x8f/0xcc [4.171266] [81332d41] __pci_register_driver+0x5e/0x62 [4.171268] [c069c000] ? 0xc069c000 [4.171278] [c042f890] drm_pci_init+0x58/0xda [drm] [4.171281] [c069c000] ? 0xc069c000 [4.171301] [c069c0a0] i915_init+0xa0/0xa8 [i915] [4.171303] [c069c000] ? 0xc069c000 [4.171307] [810003c7] do_one_initcall+0x19a/0x1af [4.171310] [81619d1d] ?
[Intel-gfx] [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
v1: Initial version.
v2: commit message updated based on comment from Vathsala.
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
Signed-off-by: Rajneesh Bhardwaj rajneesh.bhard...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 33 -
3 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d6775a..e1d0102 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct drm_i915_private
*dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
- /*
-* This is to ensure that CSR isn't identified as loaded before
-* CSR-loading program is called during runtime-resume.
-*/
- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
-
skl_uninit_cdclk(dev_priv);
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_enable_dc6(dev_priv);
+
return 0;
}
@@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv-dev;
+ if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
+ skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..06f346f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6393b76..c660245 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct drm_i915_private
*dev_priv)
DC6 already programmed to be disabled.\n);
}
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -610,10 +610,10 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
Invalid for power well status to be enabled,
unless done by the BIOS, \
when request is to disable!\n);
- if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev))
- power_well-data == SKL_DISP_PW_2) {
+ if (power_well-data == SKL_DISP_PW_2) {
+ if (GEN9_ENABLE_DC5(dev))
+ gen9_disable_dc5(dev_priv);
if (SKL_ENABLE_DC6(dev)) {
- skl_disable_dc6(dev_priv);
/*
* DDI buffer programming unnecessary
during driver-load/resume
* as it's already done during modeset
initialization then.
@@ -621,8 +621,6 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
*/
if
(!dev_priv-power_domains.initializing)
intel_prepare_ddi(dev);
- } else {
- gen9_disable_dc5(dev_priv);
}
}
I915_WRITE(HSW_PWR_WELL_DRIVER, tmp | req_mask);
@@
Re: [Intel-gfx] [PATCH] intel: Drop aub dumping functionality
On Sat, Aug 1, 2015 at 2:06 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Jul 31, 2015 at 10:53:26AM -0700, k...@bitplanet.net wrote: From: Kristian Høgsberg Kristensen kristian.h.kristen...@intel.com We now have a separate tool for this in intel-gpu-tools and we don't need to clutter up libdrm with this feature. We leave the entry points in there to avoid breaking API/ABI. A quick mention of the replacement would be a useful pointer. To use the new aub dumping tool install intel-gpu-tools and run $ intel_aubdump --output=the.aub -- glxgears See intel_aubdump for further details. Yes, with the new tool that is more general than the aub writer here, we no longer need the clutter in libdrm. (intel_aubdump looks really nice btw, though I would like an igt trace :)) Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Thanks for taking a look. I realized I have to leave intel_aub.h in since it's an installed header and used by mesa. I added a pointer and example to the deprecation and commit messages. By igt trace, do you mean something that captures and decodes all ioctls? That sounds useful too, could be a separate mode or even separate tool. Kristian -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] scripts/kernel-doc Allow struct arguments documentation in struct body
On 08/03/2015 12:59 PM, Randy Dunlap wrote:
On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.
Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
* struct my_struct - short description
* @a: first member
* @b: second member
*
* Longer description
*/
struct my_struct {
int a;
int b;
/**
* @c: This is longer description of C
*
* You can use paragraphs to describe arguments
* using this method.
*/
int c;
};
This patch allows the use of this kind of syntax. Only one argument
per comment and user can use how many paragraphs he needs. It should
start with /**, which is already being used by kernel-doc. If those
comment doesn't follow those rules, it will be ignored.
Signed-off-by: Danilo Cesar Lemes de Paula danilo.ce...@collabora.co.uk
Cc: Randy Dunlap rdun...@infradead.org
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Jonathan Corbet cor...@lwn.net
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Stephan Mueller smuel...@chronox.de
Cc: Michal Marek mma...@suse.cz
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx intel-gfx@lists.freedesktop.org
Cc: dri-devel dri-de...@lists.freedesktop.org
---
scripts/kernel-doc | 80
--
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9922e66..9bfa8b9 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -133,6 +133,30 @@ use strict;
#
# All descriptions can be multiline, except the short function description.
#
+# For really longs structs, you can also describe arguments inside the
+# body of the struct.
+# eg.
+# /**
+# * struct my_struct - short description
+# * @a: first member
+# * @b: second member
+# *
+# * Longer description
+# */
+# struct my_struct {
+# int a;
+# int b;
+# /**
+# * @c: This is longer description of C
+# *
+# * You can use paragraphs to describe arguments
+# * using this method.
+# */
+# int c;
+# };
+#
+# This should be use for arguments only.
used
What are arguments in this context? do you mean struct fields or members?
Yes. I can change the text if you want to.
+#
# You can also add additional sections. When documenting kernel functions
you
# should document the Context: of the function, e.g. whether the functions
# can be called form interrupts. Unlike other sections you can end it with
an
@@ -287,9 +311,19 @@ my $lineprefix=;
# 2 - scanning field start.
# 3 - scanning prototype.
# 4 - documentation block
+# 5 - gathering documentation outside main block
my $state;
my $in_doc_sect;
+# Split Doc State
+# 0 - Invalid (Before start or after finish)
+# 1 - Is started (the /** was found inside a struct)
+# 2 - The @parameter header was found, start accepting multi paragraph text.
+# 3 - Finished (the */ was found)
+# 4 - Error - Comment without header was found. Spit a warning as it's not
+# proper kernel-doc and ignore the rest.
+my $split_doc_state;
+
#declaration types: can be
# 'function', 'struct', 'union', 'enum', 'typedef'
my $decl_type;
@@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
my $doc_content = $doc_com_body . '(.*)';
my $doc_block = $doc_com . 'DOC:\s*(.*)?';
+my $doc_split_start = '^\s*/\*\*\s*$';
+my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
+my $doc_split_end = '^\s*\*/\s*$';
my %constants;
my %parameterdescs;
@@ -2181,6 +2218,7 @@ sub reset_state {
$prototype = ;
$state = 0;
+$split_doc_state = 0;
}
sub tracepoint_munge($) {
@@ -2453,7 +2491,6 @@ sub process_file($) {
}
$section = $newsection;
} elsif (/$doc_end/) {
-
if (($contents ne ) ($contents ne \n)) {
dump_section($file, $section, xml_escape($contents));
$section = $section_default;
@@ -2494,8 +2531,47 @@ sub process_file($) {
print STDERR Warning(${file}:$.): bad line: $_;
++$warnings;
}
+} elsif ($state == 5) { # scanning for split parameters
+
+# First line (state 1) needs to be a @parameter
+if ($split_doc_state == 1 /$doc_split_sect/o) {
+$section = $1;
+$contents = $2;
+if ($contents ne ) {
+while ((substr($contents, 0, 1) eq ) ||
+substr($contents, 0, 1) eq \t) {
+$contents = substr($contents, 1);
+}
+
Re: [Intel-gfx] [PATCH v1 1/2] drm/i915:skl: Add WaEnableGapsTsvCreditFix
On Mon, Aug 03, 2015 at 08:24:56PM +0100, Arun Siluvery wrote:
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 77967ca..8991cd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6849,6 +6849,9 @@ enum skl_disp_power_wells {
#define GEN7_MISCCPCTL (0x9424)
#define GEN7_DOP_CLOCK_GATE_ENABLE (10)
+#define GEN8_GARBCNTL 0xB004
+#define GEN9_GAPS_TSV_CREDIT_DISABLE (17)
+
/* IVYBRIDGE DPF */
#define GEN7_L3CDERRST1 0xB008 /* L3CD Error Status 1 */
#define HSW_L3CDERRST11 0xB208 /* L3CD Error Status
register 1 slice 1 */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c23cab6..9152113 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -106,6 +106,12 @@ static void skl_init_clock_gating(struct drm_device *dev)
/* WaDisableLSQCROPERFforOCL:skl */
I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_RO_PERF_DIS);
+
+ /* WaEnableGapsTsvCreditFix:skl */
+ if (IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_C0)) {
+ I915_WRITE(GEN8_GARBCNTL, (I915_READ(GEN8_GARBCNTL) |
+GEN9_GAPS_TSV_CREDIT_DISABLE));
+ }
}
static void bxt_init_clock_gating(struct drm_device *dev)
FWIW, the docs make it sound like BIOS should be doing this. Did you verify we
actually don't have the bit set with more recent BKC?
Tested-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Ben Widawsky b...@bwidawsk.net
--
Ben Widawsky, 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] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Tuesday, August 04, 2015 12:05:14 AM Daniel Vetter wrote: On Mon, Aug 3, 2015 at 7:24 PM, Linus Torvalds torva...@linux-foundation.org wrote: However, I'm still seeing a large number of drm/i915 related warning messages and other kernel kvetching. I suspect I can live with that for now. The lockdep one looks like it's mainly an initialization issue, so you'd never get the actual deadlock in practice, but it's obviously annoying. The intel_pm.c one I'll have to defer to the i915 people for.. The lockdep splat is just acpi being inconsistent with init_mutex vs. backlight notifier_chain (which has it's own lock) calls. init_mutex is new in 4.2 and has been added in commit 87521e16a7abbf3fa337f56cb4d1e18247f15e8a Author: Hans de Goede hdego...@redhat.com Date: Tue Jun 16 16:27:48 2015 +0200 acpi-video-detect: Rewrite backlight interface selection logic Not mine ;-) But adding relevant people. Hans, can you have a look at this, please? Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915:gen9: Add disable gather at set shader w/a
On Mon, Aug 03, 2015 at 08:24:57PM +0100, Arun Siluvery wrote:
This WA is implemented in init_context as well as WA batch init.
There are also some dependent bits need to be set in other registers
for this to be complete.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_lrc.c| 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8991cd5..24b8bb9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1720,7 +1720,9 @@ enum skl_disp_power_wells {
#define MEM_DISPLAY_A_TRICKLE_FEED_DISABLE (12) /* 830/845 only */
#define MEM_DISPLAY_TRICKLE_FEED_DISABLE (12) /* 85x only */
#define FW_BLC 0x020d8
+#define GEN9_DISABLE_GATHER_AT_SET_SHADER(17)
#define FW_BLC2 0x020dc
+#define GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER (12)
Neither of these belong here. BLC is for backlight. Create a new define if we
don't have one.
#define RS_CHICKEN 0x20dc
#define FW_BLC_SELF 0x020e0 /* 915+ only */
#define FW_BLC_SELF_EN_MASK (131)
#define FW_BLC_SELF_FIFO_MASK(116) /* 945 only */
@@ -5836,6 +5838,7 @@ enum skl_disp_power_wells {
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((110) | (126))
# define GEN9_RHWO_OPTIMIZATION_DISABLE (114)
#define COMMON_SLICE_CHICKEN20x7014
+#define GEN9_DISABLE_GATHER_SET_SHADER_SLICE (112)
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE(10)
#define HIZ_CHICKEN 0x7018
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 9faad82..d3a03f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1292,6 +1292,14 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WA to reset disable gather at set shader slice bit */
+ if (IS_SKYLAKE(dev)) {
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, COMMON_SLICE_CHICKEN2);
+ wa_ctx_emit(batch, index,
+
_MASKED_BIT_DISABLE(GEN9_DISABLE_GATHER_SET_SHADER_SLICE));
+ }
+
Shouldn't this be for BXT as well? Also, why bother with the revid check below
and not here?
/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_B0)) ||
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0))) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dcd1b8f..4fc4b5e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -985,6 +985,15 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
+ /* WA to gather at set shader - skl,bxt
+ * These are dependent bits need to be set for the WA.
+ */
+ if (IS_SKYLAKE(dev) (INTEL_REVID(dev) SKL_REVID_D0) ||
+ (IS_BROXTON(dev) INTEL_REVID(dev) BXT_REVID_A0)) {
+ WA_SET_BIT_MASKED(FW_BLC, GEN9_DISABLE_GATHER_AT_SET_SHADER);
+ WA_SET_BIT_MASKED(FW_BLC2,
GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER);
+ }
+
return 0;
}
@@ -1068,6 +1077,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
HDC_FENCE_DEST_SLM_DISABLE |
HDC_BARRIER_PERFORMANCE_DISABLE);
+ /* WA to Disable gather at set shader - skl
+ * This bit needs to be reset in Per ctx WA batch and it is also
+ * dependent on other bits in different register, all of them need
+ * be set for the WA to be complete.
+ */
+ WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
GEN9_DISABLE_GATHER_SET_SHADER_SLICE);
+
return skl_tune_iz_hashing(ring);
}
I wouldn't set both 20dc, and 20d8, I am not sure what implication it has.
Instead, set or read bit 15 of 0x20e0 and then just set one. To me, it seems
like the best way to do this is to set 115 of 0x20e0, and then use bit 2 of
0x20dc for the workaround. We don't need per context controls of something we
have to disable always anyway.
--
Ben Widawsky, 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] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Mon, Aug 3, 2015 at 7:24 PM, Linus Torvalds torva...@linux-foundation.org wrote: However, I'm still seeing a large number of drm/i915 related warning messages and other kernel kvetching. I suspect I can live with that for now. The lockdep one looks like it's mainly an initialization issue, so you'd never get the actual deadlock in practice, but it's obviously annoying. The intel_pm.c one I'll have to defer to the i915 people for.. The lockdep splat is just acpi being inconsistent with init_mutex vs. backlight notifier_chain (which has it's own lock) calls. init_mutex is new in 4.2 and has been added in commit 87521e16a7abbf3fa337f56cb4d1e18247f15e8a Author: Hans de Goede hdego...@redhat.com Date: Tue Jun 16 16:27:48 2015 +0200 acpi-video-detect: Rewrite backlight interface selection logic Not mine ;-) But adding relevant people. I'll send you a pull for the mst one tomorrow and look into the watermark fail in intel_pm.c too. -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] [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware
This patch contains the changes to remove the byte swapping logic introduced
with old dmc firmware.
Which version of DMC need reversal logic? Atleast , 4,1.16,1.18 follow the
same format.
-Original Message-
From: Manna, Animesh
Sent: Monday, August 3, 2015 9:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Manna, Animesh; Vetter, Daniel; Lespiau, Damien; Deak, Imre; Kamath, Sunil;
Nagaraju, Vathsala
Subject: [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr
firmware
This patch contains the changes to remove the byte swapping logic introduced
with old dmc firmware.
While debugging PC10 entry issue for skylake found with latest dmc firmware
version 1.18 without byte swapping dmc is working fine and able to enter PC10.
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_csr.c |
16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b94ada9..9d0ee58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -742,7 +742,7 @@ enum csr_state {
struct intel_csr {
const char *fw_path;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
uint32_t dmc_fw_size;
uint32_t mmio_count;
uint32_t mmioaddr[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf..ba1ae03 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -244,7 +244,7 @@ void intel_csr_load_status_set(struct drm_i915_private
*dev_priv, void intel_csr_load_program(struct drm_device *dev) {
struct drm_i915_private *dev_priv = dev-dev_private;
- __be32 *payload = dev_priv-csr.dmc_payload;
+ u32 *payload = dev_priv-csr.dmc_payload;
uint32_t i, fw_size;
if (!IS_GEN9(dev)) {
@@ -256,7 +256,7 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv-csr.dmc_fw_size;
for (i = 0; i fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
- (u32 __force)payload[i]);
+ payload[i]);
for (i = 0; i dev_priv-csr.mmio_count; i++) {
I915_WRITE(dev_priv-csr.mmioaddr[i],
@@ -279,7 +279,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
char substepping = intel_get_substepping(dev);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
bool fw_loaded = false;
if (!fw) {
@@ -375,15 +375,7 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
}
dmc_payload = csr-dmc_payload;
- for (i = 0; i dmc_header-fw_size; i++) {
- uint32_t *tmp = (u32 *)fw-data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = cpu_to_be32(*tmp);
- }
+ memcpy(dmc_payload, fw-data[readcount], nbytes);
/* load csr program during system boot, as needed for DC states */
intel_csr_load_program(dev);
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware
On 8/4/2015 9:16 AM, Nagaraju, Vathsala wrote:
This patch contains the changes to remove the byte swapping logic introduced with
old dmc firmware.
Which version of DMC need reversal logic? Atleast , 4,1.16,1.18 follow the
same format.
Packaging of firmware binary completely changed after api version 1.0, so by
old firmware I want to mean
the initial version before dmc 1.0.
-Original Message-
From: Manna, Animesh
Sent: Monday, August 3, 2015 9:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Manna, Animesh; Vetter, Daniel; Lespiau, Damien; Deak, Imre; Kamath, Sunil;
Nagaraju, Vathsala
Subject: [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr
firmware
This patch contains the changes to remove the byte swapping logic introduced
with old dmc firmware.
While debugging PC10 entry issue for skylake found with latest dmc firmware
version 1.18 without byte swapping dmc is working fine and able to enter PC10.
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
Signed-off-by: Vathsala Nagaraju vathsala.nagar...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_csr.c |
16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b94ada9..9d0ee58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -742,7 +742,7 @@ enum csr_state {
struct intel_csr {
const char *fw_path;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
uint32_t dmc_fw_size;
uint32_t mmio_count;
uint32_t mmioaddr[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf..ba1ae03 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -244,7 +244,7 @@ void intel_csr_load_status_set(struct drm_i915_private
*dev_priv, void intel_csr_load_program(struct drm_device *dev) {
struct drm_i915_private *dev_priv = dev-dev_private;
- __be32 *payload = dev_priv-csr.dmc_payload;
+ u32 *payload = dev_priv-csr.dmc_payload;
uint32_t i, fw_size;
if (!IS_GEN9(dev)) {
@@ -256,7 +256,7 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv-csr.dmc_fw_size;
for (i = 0; i fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
- (u32 __force)payload[i]);
+ payload[i]);
for (i = 0; i dev_priv-csr.mmio_count; i++) {
I915_WRITE(dev_priv-csr.mmioaddr[i],
@@ -279,7 +279,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
char substepping = intel_get_substepping(dev);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
bool fw_loaded = false;
if (!fw) {
@@ -375,15 +375,7 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
}
dmc_payload = csr-dmc_payload;
- for (i = 0; i dmc_header-fw_size; i++) {
- uint32_t *tmp = (u32 *)fw-data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = cpu_to_be32(*tmp);
- }
+ memcpy(dmc_payload, fw-data[readcount], nbytes);
/* load csr program during system boot, as needed for DC states */
intel_csr_load_program(dev);
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/vlv: Add RPS debugfs disabling for vlv/chv
This patch exposes a new debugfs interface 'i915_rps_disable'
Following 2 values shall be echoed into this file.
'0' - RPS explicitly enabled .
'1' - RPS explicitly disabled.
This interface provides capabilty to enable/disable Turbo feature
at runtime, which is needed for its validation.
Signed-off-by: Deepak S deepa...@intel.com
Signed-off-by: Praveen Paneri praveen.pan...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 55 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..9124654 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4771,6 +4771,60 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
i915_min_freq_get, i915_min_freq_set,
%llu\n);
+static int i915_rps_disable_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!IS_VALLEYVIEW(dev))
+ return -ENODEV;
+
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+
+ *val = dev_priv-rps.rps_disable;
+
+ return 0;
+}
+
+static int i915_rps_disable_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
+
+ if (!IS_VALLEYVIEW(dev))
+ return -ENODEV;
+
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+
+ DRM_DEBUG_DRIVER(Setting RPS disable %s\n,
+val ? true : false);
+
+ ret = mutex_lock_interruptible(dev_priv-rps.hw_lock);
+ if (ret)
+ return ret;
+
+ dev_priv-rps.rps_disable = val;
+
+ if (val)
+ I915_WRITE(GEN6_RP_CONTROL, 0);
+ else
+ 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_CONT);
+
+ mutex_unlock(dev_priv-rps.hw_lock);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_rps_disable_fops,
+ i915_rps_disable_get, i915_rps_disable_set,
+ %llu\n);
+
static int
i915_cache_sharing_get(void *data, u64 *val)
{
@@ -5107,6 +5161,7 @@ static const struct i915_debugfs_files {
{i915_wedged, i915_wedged_fops},
{i915_max_freq, i915_max_freq_fops},
{i915_min_freq, i915_min_freq_fops},
+ {i915_rps_disable, i915_rps_disable_fops},
{i915_cache_sharing, i915_cache_sharing_fops},
{i915_ring_stop, i915_ring_stop_fops},
{i915_ring_missed_irq, i915_ring_missed_irq_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..e2a57f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1137,6 +1137,8 @@ struct intel_gen6_power_mgmt {
u8 up_threshold; /* Current %busy required to uplock */
u8 down_threshold; /* Current %busy required to downclock */
+ bool rps_disable;
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/19] drm/i915/gen8: Add 4 level support in insert_entries and clear_range
Reviewed the patch it looks fine.
Reviewed-by: Akash Goel akash.g...@intel.com
On 8/3/2015 2:23 PM, Michel Thierry wrote:
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was inspired by Ben's Depend exclusively on map and
unmap_vma.
v2: Rebase after s/page_tables/page_table/.
v3: Remove unnecessary pdpe loop in gen8_ppgtt_clear_range_4lvl and use
clamp_pdp in gen8_ppgtt_insert_entries (Akash).
v4: Merge gen8_ppgtt_clear_range_4lvl into gen8_ppgtt_clear_range to
maintain symmetry with gen8_ppgtt_insert_entries (Akash).
v5: Do not mix pages and bytes in insert_entries (Akash).
v6: Prevent overflow in sg_nents PAGE_SHIFT, when inserting 4GB at
once.
v7: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Use gen8_px_index functions, and remove unnecessary number of pages
parameter in insert_pte_entries.
v8: Change gen8_ppgtt_clear_pte_range to stop at PDP boundary, instead of
adding and extra clamp function; remove unnecessary pdp_start/pdp_len
variables (Akash).
v9: pages-orig_nents instead of sg_nents(pages-sgl) to get the
length (Akash).
v10: Remove pdp warning check ingen8_ppgtt_insert_pte_entries until this
commit (Akash).
Reviewed-by: Akash Goel akash.g...@intel.com (v9)
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 52 +
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 31fc672..d5ae5de 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -681,9 +681,9 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
- unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
- unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
- unsigned pte = start GEN8_PTE_SHIFT GEN8_PTE_MASK;
+ unsigned pdpe = gen8_pdpe_index(start);
+ unsigned pde = gen8_pde_index(start);
+ unsigned pte = gen8_pte_index(start);
unsigned num_entries = length PAGE_SHIFT;
unsigned last_pte, i;
@@ -722,7 +722,8 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
pte = 0;
if (++pde == I915_PDES) {
- pdpe++;
+ if (++pdpe == I915_PDPES_PER_PDP(vm-dev))
+ break;
pde = 0;
}
}
@@ -735,12 +736,21 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
-
gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm-scratch_page),
I915_CACHE_LLC, use_scratch);
- gen8_ppgtt_clear_pte_range(vm, pdp, start, length, scratch_pte);
+ if (!USES_FULL_48BIT_PPGTT(vm-dev)) {
+ gen8_ppgtt_clear_pte_range(vm, ppgtt-pdp, start, length,
+ scratch_pte);
+ } else {
+ uint64_t templ4, pml4e;
+ struct i915_page_directory_pointer *pdp;
+
+ gen8_for_each_pml4e(pdp, ppgtt-pml4, start, length, templ4,
pml4e) {
+ gen8_ppgtt_clear_pte_range(vm, pdp, start, length,
+ scratch_pte);
+ }
+ }
}
static void
@@ -753,16 +763,13 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space
*vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
- unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
- unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
- unsigned pte = start GEN8_PTE_SHIFT GEN8_PTE_MASK;
+ unsigned pdpe = gen8_pdpe_index(start);
+ unsigned pde = gen8_pde_index(start);
+ unsigned pte = gen8_pte_index(start);
pt_vaddr = NULL;
while (__sg_page_iter_next(sg_iter)) {
- if (WARN_ON(pdpe = GEN8_LEGACY_PDPES))
- break;
-
if (pt_vaddr == NULL) {
struct i915_page_directory *pd =
pdp-page_directory[pdpe];
struct i915_page_table *pt = pd-page_table[pde];
@@ -776,7 +783,8 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
kunmap_px(ppgtt, pt_vaddr);
pt_vaddr = NULL;
if
[Intel-gfx] [PATCH] drm/i915: Allow DSI dual link to be configured on any pipe
Just like single link MIPI panels, similarly for dual link panels, pipe to be
configured is based on the DVO port from VBT Block 2. In hardware,
Port A is mapped with Pipe A and Port C is mapped with Pipe B.
This issue got introduced in -
commit 7e9804fdcffc650515c60f524b8b2076ee59e710
Author: Jani Nikula jani.nik...@intel.com
Date: Fri Jan 16 14:27:23 2015 +0200
drm/i915/dsi: add drm mipi dsi host support
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 18dd7d7..8aa9c7cc 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1048,11 +1048,7 @@ void intel_dsi_init(struct drm_device *dev)
intel_connector-unregister = intel_connector_unregister;
/* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
- if (dev_priv-vbt.dsi.config-dual_link) {
- /* XXX: does dual link work on either pipe? */
- intel_encoder-crtc_mask = (1 PIPE_A);
- intel_dsi-ports = ((1 PORT_A) | (1 PORT_C));
- } else if (dev_priv-vbt.dsi.port == DVO_PORT_MIPIA) {
+ if (dev_priv-vbt.dsi.port == DVO_PORT_MIPIA) {
intel_encoder-crtc_mask = (1 PIPE_A);
intel_dsi-ports = (1 PORT_A);
} else if (dev_priv-vbt.dsi.port == DVO_PORT_MIPIC) {
@@ -1060,6 +1056,9 @@ void intel_dsi_init(struct drm_device *dev)
intel_dsi-ports = (1 PORT_C);
}
+ if (dev_priv-vbt.dsi.config-dual_link)
+ intel_dsi-ports = ((1 PORT_A) | (1 PORT_C));
+
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi-ports) {
struct intel_dsi_host *host;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Support NV12 in rotated GGTT mapping
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Just adding the rotated UV plane at the end of the rotated Y plane.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 37 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 12
3 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b4c6ed5d02dd..6495996c285e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2760,10 +2760,13 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
{
struct intel_rotation_info *rot_info = ggtt_view-rotation_info;
unsigned int size_pages = rot_info-size PAGE_SHIFT;
+ unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
unsigned long i;
dma_addr_t *page_addr_list;
struct sg_table *st;
+ unsigned int uv_start_page;
+ struct scatterlist *sg;
int ret = -ENOMEM;
/* Allocate a temporary list of source pages for random access. */
@@ -2772,12 +2775,18 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
if (!page_addr_list)
return ERR_PTR(ret);
+ /* Account for UV plane with NV12. */
+ if (rot_info-pixel_format == DRM_FORMAT_NV12)
+ size_pages_uv = rot_info-size_uv PAGE_SHIFT;
+ else
+ size_pages_uv = 0;
+
/* Allocate target SG list. */
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
goto err_st_alloc;
- ret = sg_alloc_table(st, size_pages, GFP_KERNEL);
+ ret = sg_alloc_table(st, size_pages + size_pages_uv, GFP_KERNEL);
if (ret)
goto err_sg_alloc;
@@ -2789,15 +2798,30 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
}
/* Rotate the pages. */
- rotate_pages(page_addr_list, 0,
+ sg = rotate_pages(page_addr_list, 0,
rot_info-width_pages, rot_info-height_pages,
st, NULL);
+ /* Append the UV plane if NV12. */
+ if (rot_info-pixel_format == DRM_FORMAT_NV12) {
+ uv_start_page = size_pages;
+
+ /* Check for tile-row un-alignment. */
+ if (offset_in_page(rot_info-uv_offset))
+ uv_start_page--;
+
+ rotate_pages(page_addr_list, uv_start_page,
+rot_info-width_pages_uv,
+rot_info-height_pages_uv,
+st, sg);
+ }
+
DRM_DEBUG_KMS(
- Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages).\n,
+ Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane
0)).\n,
obj-base.size, rot_info-pitch, rot_info-height,
rot_info-pixel_format, rot_info-width_pages,
- rot_info-height_pages, size_pages);
+ rot_info-height_pages, size_pages + size_pages_uv,
+ size_pages);
drm_free_large(page_addr_list);
@@ -2809,10 +2833,11 @@ err_st_alloc:
drm_free_large(page_addr_list);
DRM_DEBUG_KMS(
- Failed to create rotated mapping for object size %zu!
(%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages)\n,
+ Failed to create rotated mapping for object size %zu!
(%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane
0))\n,
obj-base.size, ret, rot_info-pitch, rot_info-height,
rot_info-pixel_format, rot_info-width_pages,
- rot_info-height_pages, size_pages);
+ rot_info-height_pages, size_pages + size_pages_uv,
+ size_pages);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index e1cfa292f9ad..3daa60332e28 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -124,10 +124,13 @@ enum i915_ggtt_view_type {
struct intel_rotation_info {
unsigned int height;
unsigned int pitch;
+ unsigned int uv_offset;
uint32_t pixel_format;
uint64_t fb_modifier;
unsigned int width_pages, height_pages;
uint64_t size;
+ unsigned int width_pages_uv, height_pages_uv;
+ uint64_t size_uv;
};
struct i915_ggtt_view {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 03e550874aec..342d96553a7b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2297,6 +2297,7 @@
[Intel-gfx] [PATCH 1/4] drm/i915: Support planar formats in tile height calculations
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This will be needed for NV12 support.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43b0f17ad1fa..03e550874aec 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2224,7 +2224,7 @@ static bool need_vtd_wa(struct drm_device *dev)
unsigned int
intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
- uint64_t fb_format_modifier)
+ uint64_t fb_format_modifier, unsigned int plane)
{
unsigned int tile_height;
uint32_t pixel_bytes;
@@ -2240,7 +2240,7 @@ intel_tile_height(struct drm_device *dev, uint32_t
pixel_format,
tile_height = 32;
break;
case I915_FORMAT_MOD_Yf_TILED:
- pixel_bytes = drm_format_plane_cpp(pixel_format, 0);
+ pixel_bytes = drm_format_plane_cpp(pixel_format, plane);
switch (pixel_bytes) {
default:
case 1:
@@ -2274,7 +2274,7 @@ intel_fb_align_height(struct drm_device *dev, unsigned
int height,
uint32_t pixel_format, uint64_t fb_format_modifier)
{
return ALIGN(height, intel_tile_height(dev, pixel_format,
- fb_format_modifier));
+ fb_format_modifier, 0));
}
static int
@@ -2300,7 +2300,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
info-fb_modifier = fb-modifier[0];
tile_height = intel_tile_height(fb-dev, fb-pixel_format,
- fb-modifier[0]);
+ fb-modifier[0], 0);
tile_pitch = PAGE_SIZE / tile_height;
info-width_pages = DIV_ROUND_UP(fb-pitches[0], tile_pitch);
info-height_pages = DIV_ROUND_UP(fb-height, tile_height);
@@ -3094,7 +3094,7 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
if (intel_rotation_90_or_270(rotation)) {
/* stride = Surface height in tiles */
tile_height = intel_tile_height(dev, fb-pixel_format,
- fb-modifier[0]);
+ fb-modifier[0], 0);
stride = DIV_ROUND_UP(fb-height, tile_height);
x_offset = stride * tile_height - y - src_h;
y_offset = x;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6bd848..429d05406a5c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1061,7 +1061,7 @@ int intel_plane_atomic_calc_changes(struct drm_crtc_state
*crtc_state,
unsigned int
intel_tile_height(struct drm_device *dev, uint32_t pixel_format,
- uint64_t fb_format_modifier);
+ uint64_t fb_format_modifier, unsigned int plane);
static inline bool
intel_rotation_90_or_270(unsigned int rotation)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 9d8af2f8a875..f0bfe1647967 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -228,7 +228,7 @@ skl_update_plane(struct drm_plane *drm_plane, struct
drm_crtc *crtc,
if (intel_rotation_90_or_270(rotation)) {
/* stride: Surface height in tiles */
tile_height = intel_tile_height(dev, fb-pixel_format,
- fb-modifier[0]);
+ fb-modifier[0], 0);
stride = DIV_ROUND_UP(fb-height, tile_height);
plane_size = (src_w 16) | src_h;
x_offset = stride * tile_height - y - (src_h + 1);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: load driver even if debugfs fails
On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote: On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote: debugfs files are not necessary for the usual operation of the driver and the device. No need to check for the return values from the debugfs file creation. Even if one debugfs file fails to create we try with the next debugfs file and ultimately return success always so that the driver continues to load. Does this even happen? I'm reluctant to merge patches without real-world justification. -Daniel cleanup will clean all the created debugfs files as the list of file that are created are maintained in minor-debugfs_list. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- A gentle ping. regards sudip ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2.1 2.7/12] drm/i915: Update atomic state when removing mst connector, v2.
Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.
With atomic the state can be made consistent all the time.
Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
---
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7747520bf9f6..dfe4407b0390 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6370,10 +6370,6 @@ static void intel_connector_check_state(struct
intel_connector *connector)
connector-base.base.id,
connector-base.name);
- /* there is no real hw state for MST connectors */
- if (connector-mst_port)
- return;
-
I915_STATE_WARN(connector-base.dpms == DRM_MODE_DPMS_OFF,
wrong connector dpms state\n);
I915_STATE_WARN(connector-base.encoder != encoder-base,
@@ -12751,13 +12747,6 @@ check_encoder_state(struct drm_device *dev)
encoder-base.crtc,
connector's crtc doesn't match encoder crtc\n);
}
- /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
- if (!enabled encoder-base.encoder_type ==
DRM_MODE_ENCODER_DPMST)
- continue;
I915_STATE_WARN(!!encoder-base.crtc != enabled,
encoder's enabled state mismatch
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 585f0a45b3f1..35f2eb59818a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -448,6 +448,49 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return connector;
}
+static void
+intel_dp_unbind_mst_connector(struct drm_device *dev,
+ struct drm_connector *connector)
+{
+ struct drm_atomic_state *state;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc = connector-state-crtc;
+ int ret;
+
+ if (!crtc)
+ return;
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return;
+
+ state-acquire_ctx = dev-mode_config.acquire_ctx;
+
+ conn_state = drm_atomic_get_connector_state(state, connector);
+ ret = PTR_ERR_OR_ZERO(conn_state);
+ if (!ret)
+ ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+
+ if (!ret)
+ ret = drm_atomic_add_affected_connectors(state, crtc);
+
+ if (!ret !drm_atomic_connectors_for_crtc(state, crtc)) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_existing_crtc_state(state, crtc);
+
+ crtc_state-active = false;
+ ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+ }
+
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret)
+ drm_atomic_state_free(state);
+
+ I915_STATE_WARN_ON(ret);
+}
+
static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector)
{
@@ -455,7 +498,7 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_device *dev = connector-dev;
/* need to nuke the connector */
drm_modeset_lock_all(dev);
- intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ intel_dp_unbind_mst_connector(dev, connector);
drm_modeset_unlock_all(dev);
intel_connector-unregister(intel_connector);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 06/19] drm/i915/gen8: Add PML4 structure
On 7/31/2015 6:35 PM, Goel, Akash wrote:
On 7/31/2015 5:42 PM, Michel Thierry wrote:
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -689,9 +689,6 @@ gen8_ppgtt_insert_pte_entries(struct
i915_address_space *vm,
pt_vaddr = NULL;
for_each_sg_page(pages-sgl, sg_iter, pages-nents, 0) {
-if (WARN_ON(pdpe = GEN8_LEGACY_PDPES))
-break;
-
Apologize for this eleventh hour comment.
Would this change be better off in the later patch Add 4 level support
in insert_entries and clear_range.
Makes sense.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/9] drm/i915: Convert requests to use struct fence
On 07/28/2015 11:10 AM, John Harrison wrote:
[snip]
static inline void
@@ -2267,7 +2284,7 @@ i915_gem_request_unreference__unlocked(struct
drm_i915_gem_request *req)
return;
dev = req-ring-dev;
-if (kref_put_mutex(req-ref, i915_gem_request_free,
dev-struct_mutex))
+if (kref_put_mutex(req-fence.refcount, fence_release,
dev-struct_mutex))
mutex_unlock(dev-struct_mutex);
Would it be nicer to add fence_put_mutex(struct fence *, struct mutex
*) for this? It would avoid the layering violation of requests peeking
into fence implementation details.
Maarten pointed out that adding 'fence_put_mutex()' is breaking the
fence ABI itself. It requires users of any random fence to know and
worry about what mutex objects that fence's internal implementation
might require.
I don't see what it has to do with the ABI? I dislike both approaches
actually and don't like the question of what is the lesser evil. :)
This is a bit more hacky from our point of view but it is only a
temporary measure until the mutex lock is not required for
dereferencing. At that point all the nasty stuff disappears completely.
Yes saw that in later patches. No worries then, just a consequence of
going patch by patch.
+
if (req-file_priv)
i915_gem_request_remove_from_client(req);
@@ -2637,6 +2639,47 @@ void i915_gem_request_free(struct kref *req_ref)
kmem_cache_free(req-i915-requests, req);
}
+static const char *i915_gem_request_get_driver_name(struct fence
*req_fence)
+{
+return i915_request;
+}
I think this becomes kind of ABI once added so we need to make sure
the best name is chosen to start with. I couldn't immediately figure
out why not just i915?
The thought was that we might start using fences for other purposes at
some point in the future. At which point it is helpful to differentiate
them. If nothing else, a previous iteration of the native sync
implementation was using different fence objects due to worries about
allowing user land to get its grubby mitts on important driver internal
structures.
I don't follow on the connection between these names and the last
concern? If I did, would it explain why driver name i915 and
differentiation by timeline names would be problematic? Looks much
cleaner to me.
+
+static const char *i915_gem_request_get_timeline_name(struct fence
*req_fence)
+{
+struct drm_i915_gem_request *req = container_of(req_fence,
+ typeof(*req), fence);
+return req-ring-name;
+}
+
+static bool i915_gem_request_enable_signaling(struct fence *req_fence)
+{
+/* Interrupt driven fences are not implemented yet.*/
+WARN(true, This should not be called!);
+return true;
I suppose WARN is not really needed in the interim patch. Would return
false work?
The point is to keep the driver 'safe' if that patch is viewed as stand
alone. I.e., if the interrupt follow up does not get merged immediately
after (or not at all) then this prevents people accidentally trying to
use an unsupported interface without first implementing it.
I assumed true means signaling enabled successfully but false
actually means fence already passed so you are right. I blame the
un-intuitive API. :)
+fence_base = fence_context_alloc(I915_NUM_RINGS);
+
/* Now it is safe to go back round and do everything else: */
for_each_ring(ring, dev_priv, i) {
struct drm_i915_gem_request *req;
WARN_ON(!ring-default_context);
+ring-fence_context = fence_base + i;
Could you store fence_base in dev_priv and then ring-init_hw could
set up the fence_context on its own?
Probably. It seemed to make more sense to me to keep the fence
allocation all in one place rather than splitting it in half and
distributing it. It gets removed again with the per context per ring
timelines anyway.
Yes saw that later, never mind then.
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/9] drm/i915: Convert requests to use struct fence
On 07/28/2015 11:18 AM, John Harrison wrote:
On 22/07/2015 15:45, Tvrtko Ursulin wrote:
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
There is a construct in the linux kernel called 'struct fence' that
is intended
to keep track of work that is executed on hardware. I.e. it solves
the basic
problem that the drivers 'struct drm_i915_gem_request' is trying to
address. The
request structure does quite a lot more than simply track the
execution progress
so is very definitely still required. However, the basic completion
status side
could be updated to use the ready made fence implementation and gain
all the
advantages that provides.
This patch makes the first step of integrating a struct fence into
the request.
It replaces the explicit reference count with that of the fence. It also
replaces the 'is completed' test with the fence's equivalent.
Currently, that
simply chains on to the original request implementation. A future
patch will
improve this.
For: VIZ-5190
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 45 +
drivers/gpu/drm/i915/i915_gem.c | 58
++---
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++
5 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index cf6761c..79d346c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include linux/intel-iommu.h
#include linux/kref.h
#include linux/pm_qos.h
+#include linux/fence.h
/* General customization:
*/
@@ -2150,7 +2151,17 @@ void i915_gem_track_fb(struct
drm_i915_gem_object *old,
* initial reference taken using kref_init
*/
struct drm_i915_gem_request {
-struct kref ref;
+/**
+ * Underlying object for implementing the signal/wait stuff.
+ * NB: Never call fence_later() or return this fence object to user
+ * land! Due to lazy allocation, scheduler re-ordering,
pre-emption,
+ * etc., there is no guarantee at all about the validity or
+ * sequentiality of the fence's seqno! It is also unsafe to let
+ * anything outside of the i915 driver get hold of the fence object
+ * as the clean up when decrementing the reference count requires
+ * holding the driver mutex lock.
+ */
+struct fence fence;
/** On Which ring this request was generated */
struct drm_i915_private *i915;
@@ -2227,7 +2238,13 @@ int i915_gem_request_alloc(struct
intel_engine_cs *ring,
struct intel_context *ctx,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
-void i915_gem_request_free(struct kref *req_ref);
+
+static inline bool i915_gem_request_completed(struct
drm_i915_gem_request *req,
+ bool lazy_coherency)
+{
+return fence_is_signaled(req-fence);
+}
+
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file);
@@ -2247,7 +2264,7 @@ static inline struct drm_i915_gem_request *
i915_gem_request_reference(struct drm_i915_gem_request *req)
{
if (req)
-kref_get(req-ref);
+fence_get(req-fence);
return req;
}
@@ -2255,7 +2272,7 @@ static inline void
i915_gem_request_unreference(struct drm_i915_gem_request *req)
{
WARN_ON(!mutex_is_locked(req-ring-dev-struct_mutex));
-kref_put(req-ref, i915_gem_request_free);
+fence_put(req-fence);
}
static inline void
@@ -2267,7 +2284,7 @@ i915_gem_request_unreference__unlocked(struct
drm_i915_gem_request *req)
return;
dev = req-ring-dev;
-if (kref_put_mutex(req-ref, i915_gem_request_free,
dev-struct_mutex))
+if (kref_put_mutex(req-fence.refcount, fence_release,
dev-struct_mutex))
mutex_unlock(dev-struct_mutex);
}
@@ -2284,12 +2301,6 @@ static inline void
i915_gem_request_assign(struct drm_i915_gem_request **pdst,
}
/*
- * XXX: i915_gem_request_completed should be here but currently
needs the
- * definition of i915_seqno_passed() which is below. It will be
moved in
- * a later patch when the call to i915_seqno_passed() is obsoleted...
- */
-
-/*
* A command that requires special handling by the command parser.
*/
struct drm_i915_cmd_descriptor {
@@ -2851,18 +2862,6 @@ i915_seqno_passed(uint32_t seq1, uint32_t seq2)
return (int32_t)(seq1 - seq2) = 0;
}
-static inline bool i915_gem_request_completed(struct
drm_i915_gem_request *req,
- bool lazy_coherency)
-{
-u32 seqno;
-
-BUG_ON(req == NULL);
-
-seqno = req-ring-get_seqno(req-ring, lazy_coherency);
-
-return i915_seqno_passed(seqno, req-seqno);
-}
-
int __must_check i915_gem_get_seqno(struct drm_device
Re: [Intel-gfx] [PATCH v2] drm/i915: load driver even if debugfs fails
On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote: debugfs files are not necessary for the usual operation of the driver and the device. No need to check for the return values from the debugfs file creation. Even if one debugfs file fails to create we try with the next debugfs file and ultimately return success always so that the driver continues to load. cleanup will clean all the created debugfs files as the list of file that are created are maintained in minor-debugfs_list. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- A gentle ping. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/8] NV12 90/270 rotated GGTT mapping
From: Tvrtko Ursulin tvrtko.ursu...@intel.com Still the first attempt at rotated GGTT mapping for the NV12 format. Just rebased on latest -nighlty this time. Sending out for Chandra to try the full rotated NV12 patches with the latest NV12 workarounds. Only smoke tested with normal (not NV12) kms_rotation_crc. Tvrtko Ursulin (4): drm/i915: Support planar formats in tile height calculations drm/i915: Support appending to the rotated pages mapping drm/i915: Support NV12 in rotated GGTT mapping drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset drivers/gpu/drm/i915/i915_gem_gtt.c | 58 drivers/gpu/drm/i915/i915_gem_gtt.h | 4 +++ drivers/gpu/drm/i915/intel_display.c | 48 ++--- drivers/gpu/drm/i915/intel_drv.h | 6 ++-- drivers/gpu/drm/i915/intel_sprite.c | 4 +-- 5 files changed, 93 insertions(+), 27 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
v2: Rebase.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
5 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6495996c285e..0bae7128845a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2810,6 +2810,8 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
if (offset_in_page(rot_info-uv_offset))
uv_start_page--;
+ rot_info-uv_start_page = uv_start_page;
+
rotate_pages(page_addr_list, uv_start_page,
rot_info-width_pages_uv,
rot_info-height_pages_uv,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 3daa60332e28..516a72b9b1fd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -131,6 +131,7 @@ struct intel_rotation_info {
uint64_t size;
unsigned int width_pages_uv, height_pages_uv;
uint64_t size_uv;
+ unsigned int uv_start_page;
};
struct i915_ggtt_view {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 342d96553a7b..83dadb4796a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2914,14 +2914,29 @@ u32 intel_fb_stride_alignment(struct drm_device *dev,
uint64_t fb_modifier,
}
unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+unsigned int plane)
{
const struct i915_ggtt_view *view = i915_ggtt_view_normal;
+ struct i915_vma *vma;
+ unsigned char *offset;
if (intel_rotation_90_or_270(intel_plane-base.state-rotation))
view = i915_ggtt_view_rotated;
- return i915_gem_obj_ggtt_offset_view(obj, view);
+ vma = i915_gem_obj_to_ggtt_view(obj, view);
+ if (WARN(!vma, ggtt vma for display object not found! (view=%u)\n,
+ view-type))
+ return -1;
+
+ offset = (unsigned char *)vma-node.start;
+
+ if (plane == 1) {
+ offset += vma-ggtt_view.rotation_info.uv_start_page *
+ PAGE_SIZE;
+ }
+
+ return (unsigned long)offset;
}
static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
@@ -3079,7 +3094,7 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
obj = intel_fb_obj(fb);
stride_div = intel_fb_stride_alignment(dev, fb-modifier[0],
fb-pixel_format);
- surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj);
+ surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj, 0);
/*
* FIXME: intel_plane_state-src, dst aren't set when transitional
@@ -11520,8 +11535,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup_pending;
- work-gtt_offset = intel_plane_obj_offset(to_intel_plane(primary), obj)
- + intel_crtc-dspaddr_offset;
+ work-gtt_offset = intel_plane_obj_offset(to_intel_plane(primary),
+ obj, 0);
+ work-gtt_offset += intel_crtc-dspaddr_offset;
if (mmio_flip) {
ret = intel_queue_mmio_flip(dev, crtc, fb, obj, ring,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 429d05406a5c..6b89840c9c9c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1142,7 +1142,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state
*crtc_state);
int skl_max_scale(struct intel_crtc *crtc, struct intel_crtc_state
*crtc_state);
unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
-struct drm_i915_gem_object *obj);
+struct drm_i915_gem_object *obj,
+unsigned int plane);
+
u32 skl_plane_ctl_format(uint32_t pixel_format);
u32 skl_plane_ctl_tiling(uint64_t fb_modifier);
u32 skl_plane_ctl_rotation(unsigned int rotation);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f0bfe1647967..c13c5296e1de 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -223,7 +223,7 @@ skl_update_plane(struct drm_plane
[Intel-gfx] [PATCH 2/4] drm/i915: Support appending to the rotated pages mapping
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
By providing a start offset into the source array of pages, and returning the
end position in the scatter-gather table, we will be able to append the UV
plane to the rotated mapping in later patches.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 96054a560f4f..b4c6ed5d02dd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2722,15 +2722,18 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
}
-static void
-rotate_pages(dma_addr_t *in, unsigned int width, unsigned int height,
-struct sg_table *st)
+static struct scatterlist *
+rotate_pages(dma_addr_t *in, unsigned int offset,
+unsigned int width, unsigned int height,
+struct sg_table *st, struct scatterlist *sg)
{
unsigned int column, row;
unsigned int src_idx;
- struct scatterlist *sg = st-sgl;
- st-nents = 0;
+ if (!sg) {
+ st-nents = 0;
+ sg = st-sgl;
+ }
for (column = 0; column width; column++) {
src_idx = width * (height - 1) + column;
@@ -2741,12 +2744,14 @@ rotate_pages(dma_addr_t *in, unsigned int width,
unsigned int height,
* The only thing we need are DMA addresses.
*/
sg_set_page(sg, NULL, PAGE_SIZE, 0);
- sg_dma_address(sg) = in[src_idx];
+ sg_dma_address(sg) = in[offset + src_idx];
sg_dma_len(sg) = PAGE_SIZE;
sg = sg_next(sg);
src_idx -= width;
}
}
+
+ return sg;
}
static struct sg_table *
@@ -2784,9 +2789,9 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
}
/* Rotate the pages. */
- rotate_pages(page_addr_list,
+ rotate_pages(page_addr_list, 0,
rot_info-width_pages, rot_info-height_pages,
-st);
+st, NULL);
DRM_DEBUG_KMS(
Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages).\n,
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/9] drm/i915: Interrupt driven fences
On 07/27/2015 03:00 PM, Daniel Vetter wrote: On Mon, Jul 27, 2015 at 02:20:43PM +0100, Tvrtko Ursulin wrote: On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote: From: John Harrison john.c.harri...@intel.com The intended usage model for struct fence is that the signalled status should be set on demand rather than polled. That is, there should not be a need for a 'signaled' function to be called everytime the status is queried. Instead, 'something' should be done to enable a signal callback from the hardware which will update the state directly. In the case of requests, this is the seqno update interrupt. The idea is that this callback will only be enabled on demand when something actually tries to wait on the fence. This change removes the polling test and replaces it with the callback scheme. Each fence is added to a 'please poke me' list at the start of i915_add_request(). The interrupt handler then scans through the 'poke me' list when a new seqno pops out and signals any matching fence/request. The fence is then removed from the list so the entire request stack does not need to be scanned every time. Note that the fence is added to the list before the commands to generate the seqno interrupt are added to the ring. Thus the sequence is guaranteed to be race free if the interrupt is already enabled. Note that the interrupt is only enabled on demand (i.e. when __wait_request() is called). Thus there is still a potential race when enabling the interrupt as the request may already have completed. However, this is simply solved by calling the interrupt processing code immediately after enabling the interrupt and thereby checking for already completed requests. Lastly, the ring clean up code has the possibility to cancel outstanding requests (e.g. because TDR has reset the ring). These requests will never get signalled and so must be removed from the signal list manually. This is done by setting a 'cancelled' flag and then calling the regular notify/retire code path rather than attempting to duplicate the list manipulatation and clean up code in multiple places. This also avoid any race condition where the cancellation request might occur after/during the completion interrupt actually arriving. v2: Updated to take advantage of the request unreference no longer requiring the mutex lock. For: VIZ-5190 Signed-off-by: John Harrison john.c.harri...@intel.com --- [snip] @@ -1382,6 +1387,10 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) list_del_init(request-list); i915_gem_request_remove_from_client(request); + /* In case the request is still in the signal pending list */ + if (!list_empty(request-signal_list)) + request-cancelled = true; + Another thing I did not see implemented is the sync_fence error state. This is more about the Android part, but related to this canceled flag so I am commenting here. I thought when TDR kicks in and we set request-cancelled to true, there should be a code path which somehow makes sync_fence-status negative. As it is, because fence_signal will not be called on canceled, I thought waiters will wait until timeout, rather than being woken up and return error status. For this to work you would somehow need to make sync_fence-status go negative. With normal fence completion it goes from 1 - 0, via the completion callback. I did not immediately see how to make it go negative using the existing API. I think back when we did struct fence we decided that we won't care yet about forwarding error state since doing that across drivers if you have a chain of fences looked complicated. And no one had any clear idea about what kind of semantics we really want. If we want this we'd need to add it, but probably better to do that as a follow-up (usual caveat about open-source userspace and demonstration vehicles apply and all that). Hm, I am not sure but it feels to me not having an error state is a problem. Without it userspace can just keep waiting and waiting upon a fence even though the driver has discarded that workload and never plans to resubmit it. Am I missing something? Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/19] 48-bit PPGTT
On 7/29/2015 5:23 PM, Michel Thierry wrote: Michel Thierry (19): drm/i915: Remove unnecessary gen8_clamp_pd drm/i915/gen8: Make pdp allocation more dynamic drm/i915/gen8: Abstract PDP usage drm/i915/gen8: Generalize PTE writing for GEN8 PPGTT drm/i915/gen8: Add dynamic page trace events drm/i915/gen8: Add PML4 structure drm/i915/gen8: implement alloc/free for 4lvl drm/i915/gen8: Add 4 level switching infrastructure and lrc support drm/i915/gen8: Pass sg_iter through pte inserts drm/i915/gen8: Add 4 level support in insert_entries and clear_range drm/i915/gen8: Initialize PDPs and PML4 drm/i915: Expand error state's address width to 64b drm/i915/gen8: Add ppgtt info and debug_dump drm/i915: object size needs to be u64 drm/i915: batch_obj vm offset must be u64 drm/i915/userptr: Kill user_size limit check drm/i915: Wa32bitGeneralStateOffset Wa32bitInstructionBaseOffset drm/i915/gen8: Flip the 48b switch drm/i915: Save some page table setup on repeated binds drivers/gpu/drm/i915/i915_debugfs.c| 18 +- drivers/gpu/drm/i915/i915_drv.h| 11 +- drivers/gpu/drm/i915/i915_gem.c| 30 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 + drivers/gpu/drm/i915/i915_gem_gtt.c| 665 - drivers/gpu/drm/i915/i915_gem_gtt.h| 64 ++- drivers/gpu/drm/i915/i915_gem_userptr.c| 4 - drivers/gpu/drm/i915/i915_gpu_error.c | 24 +- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_reg.h| 1 + drivers/gpu/drm/i915/i915_trace.h | 32 +- drivers/gpu/drm/i915/intel_lrc.c | 60 ++- include/uapi/drm/i915_drm.h| 3 +- 13 files changed, 747 insertions(+), 180 deletions(-) -- 2.4.5 Hi Daniel, Finally all the patches have Akash's r-b. Since there were still some small changes by him and Chris, I addressed them individually (instead of resending the whole series one more time). Below are the msg-id of the last versions of each of them, in case there are some doubts about which patches to merge. Note, the last patch (drm/i915: Save some page table setup on repeated binds) is an optimization Akash recommended. That's why he didn't review it. Do you have someone in mind to check it? Or should I ask around for volunteers? Thanks, -Michel [01/19] drm/i915: Remove unnecessary gen8_clamp_pd 1438187043-34267-2-git-send-email-michel.thie...@intel.com [02/19] drm/i915/gen8: Make pdp allocation more dynamic 1438187043-34267-3-git-send-email-michel.thie...@intel.com [03/19] drm/i915/gen8: Abstract PDP usage 1438250523-22533-1-git-send-email-michel.thie...@intel.com [04/19] drm/i915/gen8: Generalize PTE writing for GEN8 PPGTT 1438250569-22618-1-git-send-email-michel.thie...@intel.com [05/19] drm/i915/gen8: Add dynamic page trace events 1438187043-34267-6-git-send-email-michel.thie...@intel.com [06/19] drm/i915/gen8: Add PML4 structure 1438591921-3087-1-git-send-email-michel.thie...@intel.com [07/19] drm/i915/gen8: implement alloc/free for 4lvl 1438250729-22955-1-git-send-email-michel.thie...@intel.com [08/19] drm/i915/gen8: Add 4 level switching infrastructure and lrc support 1438250783-23118-1-git-send-email-michel.thie...@intel.com [09/19] drm/i915/gen8: Pass sg_iter through pte inserts 1438591967-3249-1-git-send-email-michel.thie...@intel.com [10/19] drm/i915/gen8: Add 4 level support in insert_entries and clear_range 1438592007-3354-1-git-send-email-michel.thie...@intel.com [11/19] drm/i915/gen8: Initialize PDPs and PML4 1438187043-34267-12-git-send-email-michel.thie...@intel.com [12/19] drm/i915: Expand error state's address width to 64b 1438187043-34267-13-git-send-email-michel.thie...@intel.com [13/19] drm/i915/gen8: Add ppgtt info and debug_dump 1438187043-34267-14-git-send-email-michel.thie...@intel.com [14/19] drm/i915: object size needs to be u64 1438187043-34267-15-git-send-email-michel.thie...@intel.com [15/19] drm/i915: batch_obj vm offset must be u64 1438187043-34267-16-git-send-email-michel.thie...@intel.com [16/19] drm/i915/userptr: Kill user_size limit check 1438187043-34267-17-git-send-email-michel.thie...@intel.com [17/19] drm/i915: Wa32bitGeneralStateOffset Wa32bitInstructionBaseOffset 1438187043-34267-18-git-send-email-michel.thie...@intel.com [18/19] drm/i915/gen8: Flip the 48b switch 1438346110-18985-1-git-send-email-michel.thie...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 06/19] drm/i915/gen8: Add PML4 structure
Reviewed the patch it looks fine.
Reviewed-by: Akash Goel akash.g...@intel.com
On 8/3/2015 2:22 PM, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
v5: Postpone 48-bit code in sanitize_enable_ppgtt (Akash).
v6: Keep _insert_pte_entries changes outside this patch (Akash).
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 27 +--
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
3 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..4729eaf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2498,7 +2498,8 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 6)
#define HAS_LOGICAL_RING_CONTEXTS(dev)(INTEL_INFO(dev)-gen = 8)
#define USES_PPGTT(dev) (i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt = 2)
+#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
#define HAS_OVERLAY(dev) (INTEL_INFO(dev)-has_overlay)
#define OVERLAY_NEEDS_PHYSICAL(dev)
(INTEL_INFO(dev)-overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f71746..e099c18 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1105,14 +1105,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
ppgtt-base.start = 0;
- ppgtt-base.total = 1ULL 32;
- if (IS_ENABLED(CONFIG_X86_32))
- /* While we have a proliferation of size_t variables
-* we cannot represent the full ppgtt size on 32bit,
-* so limit it to the same size as the GGTT (currently
-* 2GiB).
-*/
- ppgtt-base.total = to_i915(ppgtt-base.dev)-gtt.base.total;
ppgtt-base.cleanup = gen8_ppgtt_cleanup;
ppgtt-base.allocate_va_range = gen8_alloc_va_range;
ppgtt-base.insert_entries = gen8_ppgtt_insert_entries;
@@ -1122,10 +1114,25 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-switch_mm = gen8_mm_switch;
- ret = __pdp_init(false, ppgtt-pdp);
+ if (!USES_FULL_48BIT_PPGTT(ppgtt-base.dev)) {
+ ret = __pdp_init(false, ppgtt-pdp);
- if (ret)
+ if (ret)
+ goto free_scratch;
+
+ ppgtt-base.total = 1ULL 32;
+ if (IS_ENABLED(CONFIG_X86_32))
+ /* While we have a proliferation of size_t variables
+* we cannot represent the full ppgtt size on 32bit,
+* so limit it to the same size as the GGTT (currently
+* 2GiB).
+*/
+ ppgtt-base.total =
to_i915(ppgtt-base.dev)-gtt.base.total;
+ } else {
+ ppgtt-base.total = 1ULL 48;
+ ret = -EPERM; /* Not yet implemented */
goto free_scratch;
+ }
return 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 87e389c..04bc66f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -88,9 +88,17 @@ typedef uint64_t gen8_pde_t;
* PDPE | PDE | PTE | offset
* The difference as compared to normal x86 3 level page table is the PDPEs
are
* programmed via register.
+ *
+ * GEN8 48b legacy style address is defined as a 4 level page table:
+ * 47:39 | 38:30 | 29:21 | 20:12 | 11:0
+ * PML4E | PDPE | PDE | PTE | offset
*/
+#define GEN8_PML4ES_PER_PML4 512
+#define GEN8_PML4E_SHIFT 39
#define GEN8_PDPE_SHIFT 30
-#define GEN8_PDPE_MASK 0x3
+/* NB: GEN8_PDPE_MASK is untrue for 32b platforms, but it has no impact on 32b
page
+ * tables */
+#define GEN8_PDPE_MASK 0x1ff
#define GEN8_PDE_SHIFT21
#define GEN8_PDE_MASK 0x1ff
#define GEN8_PTE_SHIFT12
@@ -98,8 +106,8 @@ typedef uint64_t gen8_pde_t;
#define GEN8_LEGACY_PDPES 4
#define GEN8_PTES I915_PTES(sizeof(gen8_pte_t))
-/* FIXME: Next patch will use dev */
-#define I915_PDPES_PER_PDP(dev)GEN8_LEGACY_PDPES
[Intel-gfx] [PATCH] libdrm: Add framebuffer modifiers uapi
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Sync up with new kernel features as per commits:
e3eb3250d84ef97b766312345774367b6a310db8
93b81f5102a7cd270a305c2741b17c8d44bb0629
b5ff6e1637b683d5996ae11ac29afe406c0bee90
8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e
570655b09b065d2fff1b8ab9bdb8308f4c5a05a3
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: dri-de...@lists.freedesktop.org
Cc: Rob Clark robdcl...@gmail.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
include/drm/drm.h| 1 +
include/drm/drm_fourcc.h | 93
include/drm/drm_mode.h | 11 +-
3 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 167b7b81b0d0..a950b580cd11 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -816,6 +816,7 @@ struct drm_event_vblank {
#define DRM_CAP_PRIME 0x5
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
+#define DRM_CAP_ADDFB2_MODIFIERS 0x10
#define DRM_PRIME_CAP_IMPORT 0x1
#define DRM_PRIME_CAP_EXPORT 0x2
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 85facb0a17cf..63a80ca5ba39 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -127,4 +127,97 @@
#define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
non-subsampled Cb (1) and Cr (2) planes */
#define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
non-subsampled Cr (1) and Cb (2) planes */
+
+/*
+ * Format Modifiers:
+ *
+ * Format modifiers describe, typically, a re-ordering or modification
+ * of the data in a plane of an FB. This can be used to express tiled/
+ * swizzled formats, or compression, or a combination of the two.
+ *
+ * The upper 8 bits of the format modifier are a vendor-id as assigned
+ * below. The lower 56 bits are assigned as vendor sees fit.
+ */
+
+/* Vendor Ids: */
+#define DRM_FORMAT_MOD_NONE 0
+#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
+#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
+#define DRM_FORMAT_MOD_VENDOR_NV 0x03
+#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
+#define DRM_FORMAT_MOD_VENDOR_QCOM0x05
+/* add more to the end as needed */
+
+#define fourcc_mod_code(vendor, val) \
+ u64)DRM_FORMAT_MOD_VENDOR_## vendor) 56) | (val
0x00ffULL))
+
+/*
+ * Format Modifier tokens:
+ *
+ * When adding a new token please document the layout with a code comment,
+ * similar to the fourcc codes above. drm_fourcc.h is considered the
+ * authoritative source for all of these.
+ */
+
+/* Intel framebuffer modifiers */
+
+/*
+ * Intel X-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out row-major, with
+ * a platform-dependent stride. On top of that the memory can apply
+ * platform-depending swizzling of some higher address bits into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_X_TILEDfourcc_mod_code(INTEL, 1)
+
+/*
+ * Intel Y-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
+ * chunks column-major, with a platform-dependent height. On top of that the
+ * memory can apply platform-depending swizzling of some higher address bits
+ * into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_Y_TILEDfourcc_mod_code(INTEL, 2)
+
+/*
+ * Intel Yf-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles in row-major layout.
+ * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
+ * are arranged in four groups (two wide, two high) with column-major layout.
+ * Each group therefore consits out of four 256 byte units, which are also laid
+ * out as 2x2 column-major.
+ * 256 byte units are made out of four 64 byte blocks of pixels, producing
+ * either a square block or a 2:1 unit.
+ * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the
width
+ * in pixel depends on the pixel depth.
+ */
+#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+
+/*
+ * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
+ *
+ * Macroblocks are laid in a Z-shape, and each pixel data is following the
+ * standard NV12 style.
+ * As for NV12, an image is the result of two frame buffers: one for Y,
+ * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
+ * Alignment requirements are (for each buffer):
+ * - multiple of 128 pixels for the width
+ * - multiple of 32
Re: [Intel-gfx] 4.0.8-4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black
On 08/02/2015 09:43 AM, Pavel Machek wrote: On Wed 2015-07-29 15:54:00, Toralf Förster wrote: Undocking helps, and then I can dock again. This happens at a hardened 64 bit Gentoo with i915, but I think, it is not hardened related, or ? Any chance to bisect it? Aren't there are already pending patches in Gregs stable queue ? If now I'll see. A quick look at the latest 4.1.3+hardened just shows that the power button at the docking station does not produce an ACPI event. And I do get this : Aug 3 11:40:18 t44 kernel: [ cut here ] Aug 3 11:40:18 t44 kernel: WARNING: CPU: 0 PID: 1233 at drivers/gpu/drm/i915/intel_display.c:1332 assert_plane.constprop.89+0x89/0xb0 [i915]() Aug 3 11:40:18 t44 kernel: plane A assertion failure (expected on, current off) Aug 3 11:40:18 t44 kernel: Modules linked in: nf_conntrack_ipv6 nf_defrag_ipv6 ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit ipt_REJECT nf_reject_ipv4 xt_recent xt_tcpudp xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables nfsd auth_rpcgss oid_registry lockd grace ctr ccm sunrpc af_packet bridge stp llc tun rc_dib0700_rc5 dib7000p dvb_usb_dib0700 dib3000mc dvb_usb dvb_core dib0070 dib7000m dibx000_common dib0090 rc_core hid_generic hid_cherry usbhid hid arc4 snd_hda_codec_generic rtsx_pci_sdmmc mmc_core evdev x86_pkg_temp_thermal coretemp kvm_intel kvm iwlmvm aesni_intel aes_x86_64 glue_helper lrw mac80211 gf128mul ablk_helper cryptd iwlwifi psmouse atkbd pcspkr cfg80211 Aug 3 11:40:18 t44 kernel: rtsx_pci thermal wmi i915 fbcon bitblit cfbfillrect softcursor cfbimgblt thinkpad_acpi i2c_algo_bit font battery cfbcopyarea nvram rfkill ac tpm_tis drm_kms_helper tpm ehci_pci xhci_pci drm xhci_hcd snd_hda_intel snd_hda_controller snd_hda_codec ehci_hcd video snd_pcm intel_gtt i2c_i801 snd_timer agpgart usbcore snd_hda_core e1000e fb processor lpc_ich thermal_sys fbdev i2c_core mfd_core usb_common snd hwmon button soundcore [last unloaded: microcode] Aug 3 11:40:18 t44 kernel: CPU: 0 PID: 1233 Comm: X Tainted: GW 4.1.3-hardened-r2 #2 Aug 3 11:40:18 t44 kernel: Hardware name: LENOVO 20AQCTO1WW/20AQCTO1WW, BIOS GJET83WW (2.33 ) 03/09/2015 Aug 3 11:40:18 t44 kernel: 810e3006 c0402598 c90002173558 Aug 3 11:40:18 t44 kernel: 815b2fe6 2424 c900021735a8 c90002173598 Aug 3 11:40:18 t44 kernel: 8105e10a 4111 c0402598 0534 Aug 3 11:40:18 t44 kernel: Call Trace: Aug 3 11:40:18 t44 kernel: [810e3006] ? print_modules+0x76/0xe0 Aug 3 11:40:18 t44 kernel: [c0402598] ? i915_ioctls+0x8018/0x1c6e8 [i915] Aug 3 11:40:18 t44 kernel: [815b2fe6] dump_stack+0x45/0x5d Aug 3 11:40:18 t44 kernel: [8105e10a] warn_slowpath_common+0x8a/0xd0 Aug 3 11:40:18 t44 kernel: [c0402598] ? i915_ioctls+0x8018/0x1c6e8 [i915] Aug 3 11:40:18 t44 kernel: [c04041d8] ? i915_ioctls+0x9c58/0x1c6e8 [i915] Aug 3 11:40:18 t44 kernel: [8105e1aa] warn_slowpath_fmt+0x5a/0x70 Aug 3 11:40:18 t44 kernel: [c04041d8] ? i915_ioctls+0x9c58/0x1c6e8 [i915] Aug 3 11:40:18 t44 kernel: [c040f395] ? i915_ioctls+0x14e15/0x1c6e8 [i915] Aug 3 11:40:18 t44 kernel: [c040f398] ? i915_ioctls+0x14e18/0x1c6e8 [i915] Aug 3 11:40:18 t44 kernel: [c0396889] assert_plane.constprop.89+0x89/0xb0 [i915] Aug 3 11:40:18 t44 kernel: [c039f746] hsw_disable_ips+0x56/0x1d0 [i915] Aug 3 11:40:18 t44 kernel: [c039fbc5] intel_crtc_disable_planes+0x45/0x190 [i915] Aug 3 11:40:18 t44 kernel: [c03a0b9f] haswell_crtc_disable+0x5f/0x440 [i915] Aug 3 11:40:18 t44 kernel: [c03a1cf1] __intel_set_mode+0xbb1/0xcd0 [i915] Aug 3 11:40:18 t44 kernel: [c02c1b7e] ? drm_atomic_get_crtc_state+0x1e/0xe0 [drm] Aug 3 11:40:18 t44 kernel: [c03a975e] intel_crtc_set_config+0xade/0x10c0 [i915] Aug 3 11:40:18 t44 kernel: [c02c1b2f] ? drm_atomic_state_free+0x2f/0x60 [drm] Aug 3 11:40:18 t44 kernel: [c01b7dcd] ? drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] Aug 3 11:40:18 t44 kernel: [c02b0b32] drm_mode_set_config_internal+0x82/0x130 [drm] Aug 3 11:40:18 t44 kernel: [c01ba120] restore_fbdev_mode+0xd0/0x100 [drm_kms_helper] Aug 3 11:40:18 t44 kernel: [c01bc319] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x70 [drm_kms_helper] Aug 3 11:40:18 t44 kernel: [c01bc387] drm_fb_helper_set_par+0x27/0x60 [drm_kms_helper] Aug 3 11:40:18 t44 kernel: [c03b903e] intel_fbdev_set_par+0x1e/0x70 [i915] Aug 3 11:40:18 t44 kernel: [c01f0b03] fb_set_var+0x283/0x4e0 [fb] Aug 3 11:40:18 t44 kernel: [81367374] ? __list_add+0x24/0x50 Aug 3 11:40:18 t44 kernel: [810934f2] ?
Re: [Intel-gfx] [PATCH] drm/i915: Postpone plane readout until after encoder readout
Op 31-07-15 om 15:04 schreef Patrik Jakobsson: When reading out hw state for planes we disable inactive planes which in turn triggers an update of the watermarks. The update depends on the crtc_clock being set which is done when reading out encoders. Thus postpone the plane readout until after encoder readout. This prevents a warning in skl_compute_linetime_wm() where pixel_rate becomes 0 when crtc_clock is 0. The plane loop doesn't have to be nested. But that's just a minor nitpick, feel free to ignore.. Reviewed-By: Maarten Lankhorst maarten.lankho...@linux.intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 10/19] drm/i915/gen8: Add 4 level support in insert_entries and clear_range
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was inspired by Ben's Depend exclusively on map and
unmap_vma.
v2: Rebase after s/page_tables/page_table/.
v3: Remove unnecessary pdpe loop in gen8_ppgtt_clear_range_4lvl and use
clamp_pdp in gen8_ppgtt_insert_entries (Akash).
v4: Merge gen8_ppgtt_clear_range_4lvl into gen8_ppgtt_clear_range to
maintain symmetry with gen8_ppgtt_insert_entries (Akash).
v5: Do not mix pages and bytes in insert_entries (Akash).
v6: Prevent overflow in sg_nents PAGE_SHIFT, when inserting 4GB at
once.
v7: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Use gen8_px_index functions, and remove unnecessary number of pages
parameter in insert_pte_entries.
v8: Change gen8_ppgtt_clear_pte_range to stop at PDP boundary, instead of
adding and extra clamp function; remove unnecessary pdp_start/pdp_len
variables (Akash).
v9: pages-orig_nents instead of sg_nents(pages-sgl) to get the
length (Akash).
v10: Remove pdp warning check ingen8_ppgtt_insert_pte_entries until this
commit (Akash).
Reviewed-by: Akash Goel akash.g...@intel.com (v9)
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 52 +
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 31fc672..d5ae5de 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -681,9 +681,9 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
- unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
- unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
- unsigned pte = start GEN8_PTE_SHIFT GEN8_PTE_MASK;
+ unsigned pdpe = gen8_pdpe_index(start);
+ unsigned pde = gen8_pde_index(start);
+ unsigned pte = gen8_pte_index(start);
unsigned num_entries = length PAGE_SHIFT;
unsigned last_pte, i;
@@ -722,7 +722,8 @@ static void gen8_ppgtt_clear_pte_range(struct
i915_address_space *vm,
pte = 0;
if (++pde == I915_PDES) {
- pdpe++;
+ if (++pdpe == I915_PDPES_PER_PDP(vm-dev))
+ break;
pde = 0;
}
}
@@ -735,12 +736,21 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
-
gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm-scratch_page),
I915_CACHE_LLC, use_scratch);
- gen8_ppgtt_clear_pte_range(vm, pdp, start, length, scratch_pte);
+ if (!USES_FULL_48BIT_PPGTT(vm-dev)) {
+ gen8_ppgtt_clear_pte_range(vm, ppgtt-pdp, start, length,
+ scratch_pte);
+ } else {
+ uint64_t templ4, pml4e;
+ struct i915_page_directory_pointer *pdp;
+
+ gen8_for_each_pml4e(pdp, ppgtt-pml4, start, length, templ4,
pml4e) {
+ gen8_ppgtt_clear_pte_range(vm, pdp, start, length,
+ scratch_pte);
+ }
+ }
}
static void
@@ -753,16 +763,13 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space
*vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
- unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
- unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
- unsigned pte = start GEN8_PTE_SHIFT GEN8_PTE_MASK;
+ unsigned pdpe = gen8_pdpe_index(start);
+ unsigned pde = gen8_pde_index(start);
+ unsigned pte = gen8_pte_index(start);
pt_vaddr = NULL;
while (__sg_page_iter_next(sg_iter)) {
- if (WARN_ON(pdpe = GEN8_LEGACY_PDPES))
- break;
-
if (pt_vaddr == NULL) {
struct i915_page_directory *pd =
pdp-page_directory[pdpe];
struct i915_page_table *pt = pd-page_table[pde];
@@ -776,7 +783,8 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
kunmap_px(ppgtt, pt_vaddr);
pt_vaddr = NULL;
if (++pde == I915_PDES) {
- pdpe++;
+ if (++pdpe ==
[Intel-gfx] [PATCH v9 09/19] drm/i915/gen8: Pass sg_iter through pte inserts
As a step towards implementing 4 levels, while not discarding the
existing pte insert functions, we need to pass the sg_iter through.
The current function understands to the page directory granularity.
An object's pages may span the page directory, and so using the iter
directly as we write the PTEs allows the iterator to stay coherent
through a VMA insert operation spanning multiple page table levels.
v2: Rebase after s/page_tables/page_table/.
v3: Rebase after Mika's ppgtt cleanup / scratch merge patch series;
updated commit message (s/map/insert).
v4: Rebase.
Reviewed-by: Akash Goel akash.g...@intel.com (v3)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ea35935..31fc672 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -746,7 +746,7 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
static void
gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp,
- struct sg_table *pages,
+ struct sg_page_iter *sg_iter,
uint64_t start,
enum i915_cache_level cache_level)
{
@@ -756,11 +756,10 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space
*vm,
unsigned pdpe = start GEN8_PDPE_SHIFT GEN8_PDPE_MASK;
unsigned pde = start GEN8_PDE_SHIFT GEN8_PDE_MASK;
unsigned pte = start GEN8_PTE_SHIFT GEN8_PTE_MASK;
- struct sg_page_iter sg_iter;
pt_vaddr = NULL;
- for_each_sg_page(pages-sgl, sg_iter, pages-nents, 0) {
+ while (__sg_page_iter_next(sg_iter)) {
if (WARN_ON(pdpe = GEN8_LEGACY_PDPES))
break;
@@ -771,7 +770,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
}
pt_vaddr[pte] =
- gen8_pte_encode(sg_page_iter_dma_address(sg_iter),
+ gen8_pte_encode(sg_page_iter_dma_address(sg_iter),
cache_level, true);
if (++pte == GEN8_PTES) {
kunmap_px(ppgtt, pt_vaddr);
@@ -797,8 +796,10 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
struct i915_page_directory_pointer *pdp = ppgtt-pdp; /* FIXME: 48b */
+ struct sg_page_iter sg_iter;
- gen8_ppgtt_insert_pte_entries(vm, pdp, pages, start, cache_level);
+ __sg_page_iter_start(sg_iter, pages-sgl, sg_nents(pages-sgl), 0);
+ gen8_ppgtt_insert_pte_entries(vm, pdp, sg_iter, start, cache_level);
}
static void gen8_free_page_tables(struct drm_device *dev,
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body
On Sat, Aug 01, 2015 at 01:22:10PM +0200, Jonathan Corbet wrote: On Fri, 31 Jul 2015 18:06:45 -0300 Danilo Cesar Lemes de Paula danilo.ce...@collabora.co.uk wrote: Describing arguments at top of a struct definition works fine for small/medium size structs, but it definitely doesn't work well for struct with a huge list of elements. Keeping the arguments list inside the struct body makes it easier to maintain the documentation. Interesting approach. I think it could make sense, but I fear pushback from a subset of maintainers refusing to accept this mode. I wonder what it would take to get a consensus on allowing these in-struct comments? At least in drm we have a lot of such comments (as non-kerneldoc) right above struct members to explain some details. Common examples are: - locks, with a description of what they protect and maybe also how they nest. - vfunc ops structs, with a per-function description of what each hook does. - tricky stuff which can't be described in one sentence only. So it's not just huge structs by number of members, but huge by number of comment lines. Trying to stuff that all into the top kerneldoc comment means that it's much harder to jump to the right comment, and it's also easier to ignore the comments (since it e.g. won't show up in the diff context). The current approach at least in drm is to duplicate comments and that just results in inconsistency. I'm wondering if we need a kernel summit session on commenting conventions, markdown-in-kerneldoc, etc? Maybe I'll stick a proposal out there. Might be useful, but I'm not sure how many people really would actively work on improving the tooling. The only comment I've seen is to maybe use gtkdoc, but that would be a pain since it's slightly incompatible with kerneldoc. And it's the improved tooling I really need for my long-term plan to get solid docs for drm drm/i915. Next step is to start building a proper doc writer team to make all the bits we already have into a consistent hole (and nag developers to fill in the areas still undocumented). For that I've already pulled Danilo's patches into the drm-intel integration tree and I plan to use them for any further drm kerneldoc I write since we really need them. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 06/19] drm/i915/gen8: Add PML4 structure
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
v5: Postpone 48-bit code in sanitize_enable_ppgtt (Akash).
v6: Keep _insert_pte_entries changes outside this patch (Akash).
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 27 +--
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
3 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..4729eaf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2498,7 +2498,8 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 6)
#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 8)
#define USES_PPGTT(dev)(i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt = 2)
+#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
#define HAS_OVERLAY(dev) (INTEL_INFO(dev)-has_overlay)
#define OVERLAY_NEEDS_PHYSICAL(dev)
(INTEL_INFO(dev)-overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f71746..e099c18 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1105,14 +1105,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
ppgtt-base.start = 0;
- ppgtt-base.total = 1ULL 32;
- if (IS_ENABLED(CONFIG_X86_32))
- /* While we have a proliferation of size_t variables
-* we cannot represent the full ppgtt size on 32bit,
-* so limit it to the same size as the GGTT (currently
-* 2GiB).
-*/
- ppgtt-base.total = to_i915(ppgtt-base.dev)-gtt.base.total;
ppgtt-base.cleanup = gen8_ppgtt_cleanup;
ppgtt-base.allocate_va_range = gen8_alloc_va_range;
ppgtt-base.insert_entries = gen8_ppgtt_insert_entries;
@@ -1122,10 +1114,25 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-switch_mm = gen8_mm_switch;
- ret = __pdp_init(false, ppgtt-pdp);
+ if (!USES_FULL_48BIT_PPGTT(ppgtt-base.dev)) {
+ ret = __pdp_init(false, ppgtt-pdp);
- if (ret)
+ if (ret)
+ goto free_scratch;
+
+ ppgtt-base.total = 1ULL 32;
+ if (IS_ENABLED(CONFIG_X86_32))
+ /* While we have a proliferation of size_t variables
+* we cannot represent the full ppgtt size on 32bit,
+* so limit it to the same size as the GGTT (currently
+* 2GiB).
+*/
+ ppgtt-base.total =
to_i915(ppgtt-base.dev)-gtt.base.total;
+ } else {
+ ppgtt-base.total = 1ULL 48;
+ ret = -EPERM; /* Not yet implemented */
goto free_scratch;
+ }
return 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 87e389c..04bc66f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -88,9 +88,17 @@ typedef uint64_t gen8_pde_t;
* PDPE | PDE | PTE | offset
* The difference as compared to normal x86 3 level page table is the PDPEs are
* programmed via register.
+ *
+ * GEN8 48b legacy style address is defined as a 4 level page table:
+ * 47:39 | 38:30 | 29:21 | 20:12 | 11:0
+ * PML4E | PDPE | PDE | PTE | offset
*/
+#define GEN8_PML4ES_PER_PML4 512
+#define GEN8_PML4E_SHIFT 39
#define GEN8_PDPE_SHIFT30
-#define GEN8_PDPE_MASK 0x3
+/* NB: GEN8_PDPE_MASK is untrue for 32b platforms, but it has no impact on 32b
page
+ * tables */
+#define GEN8_PDPE_MASK 0x1ff
#define GEN8_PDE_SHIFT 21
#define GEN8_PDE_MASK 0x1ff
#define GEN8_PTE_SHIFT 12
@@ -98,8 +106,8 @@ typedef uint64_t gen8_pde_t;
#define GEN8_LEGACY_PDPES 4
#define GEN8_PTES I915_PTES(sizeof(gen8_pte_t))
-/* FIXME: Next patch will use dev */
-#define I915_PDPES_PER_PDP(dev)GEN8_LEGACY_PDPES
+#define I915_PDPES_PER_PDP(dev) (USES_FULL_48BIT_PPGTT(dev) ?\
+GEN8_PML4ES_PER_PML4 : GEN8_LEGACY_PDPES)
#define
Re: [Intel-gfx] drivers/gpu/drm/i915/intel_display.c:9717 intel_check_page_flip+0xb3/0xd2()
Could someone give me a clue if the issues I'm seeing are more likely to be solved with a newer kernel or a newer userland driver (xserver-xorg-video-intel) ? Thanks, Marc On Sat, Jul 18, 2015 at 01:35:53PM -0700, Marc MERLIN wrote: On Wed, Jul 15, 2015 at 04:13:23PM +, Marc MERLIN wrote: kernel: 3.19.8 xserver-xorg-video-intel 2:2.99.917-1 on debian X.Org X Server 1.17.1 [254670.214607] pool[30720]: segfault at 20 ip 7f0e68d3f534 sp 7f0dd57f9500 error 4 in libgio-2.0.so.0.4200.1[7f0e68cfa000+171000] [254670.781126] [ cut here ] [254670.781140] WARNING: CPU: 0 PID: 29514 at drivers/gpu/drm/i915/intel_display.c:9717 intel_check_page_flip+0xb3/0xd2() [254670.781143] Kicking stuck page flip: queued at 6027120, now 6027126 [254670.781144] Modules linked in: btusb uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev xhci_pci iwlmvm mac80211 iwlwifi cfg80211 ctr ccm rndis_host cdc_ether usbnet e1000e nls_utf8 nls_cp437 vfat fat ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_log_ipv4 nf_log_common xt_LOG iptable_mangle ip6table_filter ip6_tables ebtable_nat ebtables rfcomm bnep pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_addrtype xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat nf_conntrack bridge stp llc autofs4 binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ecryptfs configs ppdev parport_pc lp parport input_polldev loop firewire_sbp2 firewire_core crc_itu_t bluetooth media joydev arc4 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller intel_rapl snd_hda_codec iosf_mbi snd_hwdep snd_pcm_oss x 86_pkg_temp_thermal intel_powerclamp snd_mixer_oss snd_pcm coretemp rtsx_pci_ms kvm_intel kvm snd_seq_midi iTCO_wdt crct10dif_pclmul snd_seq_midi_event memstick iTCO_vendor_support rtsx_pci_sdmmc crc32_pclmul snd_rawmidi ghash_clmulni_intel thinkpad_acpi xhci_hcd snd_seq nvram i2c_i801 snd_seq_device psmouse snd_timer rtsx_pci rfkill usbcore lpc_ich microcode snd sg serio_raw shpchp soundcore usb_common tpm_tis pcspkr tpm battery ac ie31200_edac edac_core intel_smartconnect wmi evdev processor sata_sil24 r8169 mii fuse fan raid456 multipath mmc_block mmc_core dm_crypt dm_mod async_raid6_recov async_pq async_xor async_memcpy async_tx blowfish_x86_64 blowfish_common ecb xts crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ptp ablk_helper cryptd pps_core thermal [last unloaded: btusb] [254670.781278] CPU: 0 PID: 29514 Comm: kworker/u16:1 Tainted: GW OE 3.19.8-amd64-i915-volpreempt-s20150421rc3 #1 I'm also seeing this (which looks related): [502148.620412] WARNING: CPU: 6 PID: 30706 at drivers/gpu/drm/i915/intel_display.c:3630 intel_crtc_wait_for_pending_flips+0x12a/0x1ad() [502148.620413] Removing stuck page flip [502148.620413] Modules linked in: iwlmvm mac80211 iwlwifi cfg80211 e1000e btusb uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev xhci_pci ctr ccm rndis_host cdc_ether usbnet nls_utf8 nls_cp437 vfat fat ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_log_ipv4 nf_log_common xt_LOG iptable_mangle ip6table_filter ip6_tables ebtable_nat ebtables rfcomm bnep pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_addrtype xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat nf_conntrack bridge stp llc autofs4 binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ecryptfs configs ppdev parport_pc lp parport input_polldev loop firewire_sbp2 firewire_core crc_itu_t bluetooth media joydev arc4 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller intel_rapl snd_hda_codec iosf_mbi snd_hwdep snd_pcm_oss x86_pkg_temp_thermal intel_powerclamp snd_mixer_oss snd_pcm coretemp rtsx_pci_ms kvm_intel kvm snd_seq_midi iTCO_wdt crct10dif_pclmul snd_seq_midi_event memstick iTCO_vendor_support rtsx_pci_sdmmc crc32_pclmul snd_rawmidi ghash_clmulni_intel thinkpad_acpi xhci_hcd snd_seq nvram i2c_i801 snd_seq_device psmouse snd_timer rtsx_pci rfkill usbcore lpc_ich microcode snd sg serio_raw shpchp soundcore usb_common tpm_tis pcspkr tpm battery ac ie31200_edac edac_core intel_smartconnect wmi evdev processor sata_sil24 r8169 mii fuse fan raid456 multipath mmc_block mmc_core dm_crypt dm_mod async_raid6_recov async_pq async_xor async_memcpy async_tx blowfish_x86_64 blowfish_common ecb xts crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ptp ablk_helper cryptd pps_core thermal [last unloaded: cfg80211] [502148.620465] CPU: 6 PID: 30706 Comm: Xorg Tainted: GW OE 3.19.8-amd64-i915-volpreempt-s20150421rc3
Re: [Intel-gfx] 4.0.8-4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black
On 08/03/2015 11:53 AM, Toralf Förster wrote: A quick look at the latest 4.1.3+hardened just shows that the power button at the docking station does not produce an ACPI event. This is fixed between 4.1.3 and 4.1.4 - would be helpful to know the commit id for the following bisecting of the blackmonitor issue (still an issue in 4.1.4 and 4.2-rc5) -- Toralf, pgp key: 872AE508 0076E94E ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 2/2] drm/i915:gen9: Add disable gather at set shader w/a
This WA is implemented in init_context as well as WA batch init.
There are also some dependent bits need to be set in other registers
for this to be complete.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_lrc.c| 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8991cd5..24b8bb9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1720,7 +1720,9 @@ enum skl_disp_power_wells {
#define MEM_DISPLAY_A_TRICKLE_FEED_DISABLE (12) /* 830/845 only */
#define MEM_DISPLAY_TRICKLE_FEED_DISABLE (12) /* 85x only */
#define FW_BLC 0x020d8
+#define GEN9_DISABLE_GATHER_AT_SET_SHADER(17)
#define FW_BLC20x020dc
+#define GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER (12)
#define FW_BLC_SELF0x020e0 /* 915+ only */
#define FW_BLC_SELF_EN_MASK (131)
#define FW_BLC_SELF_FIFO_MASK(116) /* 945 only */
@@ -5836,6 +5838,7 @@ enum skl_disp_power_wells {
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((110) | (126))
# define GEN9_RHWO_OPTIMIZATION_DISABLE(114)
#define COMMON_SLICE_CHICKEN2 0x7014
+#define GEN9_DISABLE_GATHER_SET_SHADER_SLICE (112)
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (10)
#define HIZ_CHICKEN0x7018
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9faad82..d3a03f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1292,6 +1292,14 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WA to reset disable gather at set shader slice bit */
+ if (IS_SKYLAKE(dev)) {
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, COMMON_SLICE_CHICKEN2);
+ wa_ctx_emit(batch, index,
+
_MASKED_BIT_DISABLE(GEN9_DISABLE_GATHER_SET_SHADER_SLICE));
+ }
+
/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_B0)) ||
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0))) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dcd1b8f..4fc4b5e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -985,6 +985,15 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
+ /* WA to gather at set shader - skl,bxt
+* These are dependent bits need to be set for the WA.
+*/
+ if (IS_SKYLAKE(dev) (INTEL_REVID(dev) SKL_REVID_D0) ||
+ (IS_BROXTON(dev) INTEL_REVID(dev) BXT_REVID_A0)) {
+ WA_SET_BIT_MASKED(FW_BLC, GEN9_DISABLE_GATHER_AT_SET_SHADER);
+ WA_SET_BIT_MASKED(FW_BLC2,
GEN9_RS_CHICKEN_DISABLE_GATHER_AT_SHADER);
+ }
+
return 0;
}
@@ -1068,6 +1077,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
HDC_FENCE_DEST_SLM_DISABLE |
HDC_BARRIER_PERFORMANCE_DISABLE);
+ /* WA to Disable gather at set shader - skl
+* This bit needs to be reset in Per ctx WA batch and it is also
+* dependent on other bits in different register, all of them need
+* be set for the WA to be complete.
+*/
+ WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
GEN9_DISABLE_GATHER_SET_SHADER_SLICE);
+
return skl_tune_iz_hashing(ring);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 1/2] drm/i915:skl: Add WaEnableGapsTsvCreditFix
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 77967ca..8991cd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6849,6 +6849,9 @@ enum skl_disp_power_wells {
#define GEN7_MISCCPCTL (0x9424)
#define GEN7_DOP_CLOCK_GATE_ENABLE (10)
+#define GEN8_GARBCNTL 0xB004
+#define GEN9_GAPS_TSV_CREDIT_DISABLE (17)
+
/* IVYBRIDGE DPF */
#define GEN7_L3CDERRST10xB008 /* L3CD Error Status 1 */
#define HSW_L3CDERRST110xB208 /* L3CD Error Status
register 1 slice 1 */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c23cab6..9152113 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -106,6 +106,12 @@ static void skl_init_clock_gating(struct drm_device *dev)
/* WaDisableLSQCROPERFforOCL:skl */
I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) |
GEN8_LQSC_RO_PERF_DIS);
+
+ /* WaEnableGapsTsvCreditFix:skl */
+ if (IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_C0)) {
+ I915_WRITE(GEN8_GARBCNTL, (I915_READ(GEN8_GARBCNTL) |
+ GEN9_GAPS_TSV_CREDIT_DISABLE));
+ }
}
static void bxt_init_clock_gating(struct drm_device *dev)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 0/2] Add SKL Workarounds
The following WA are helping in resolving GPU hang observed with gem_ringfill and fbo-depth-array tests. Arun Siluvery (2): drm/i915:skl: Add WaEnableGapsTsvCreditFix drm/i915:gen9: Add disable gather at set shader w/a drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_lrc.c| 8 drivers/gpu/drm/i915/intel_pm.c | 6 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 16 4 files changed, 36 insertions(+) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [SKL-DMC-BUGFIX 0/5] SKL PC10 entry fixes.
Em Seg, 2015-08-03 às 21:55 +0530, Animesh Manna escreveu: The following patches helps to solve PC10 entry issue for SKL. Detailed description about the changes done to solve the issue is mentioned in commit message of each patch. All these patches are send earlier for review as part of Redesign of dmc firmware loading patch series. Now skl specific bug-fixes are seperated out and sending as seperate patch series to make it simple. Hello I find interesting that even with this series, igt/pm_rpm/rte fails. We don't seem to be doing runtime PM, yet we allow PC10 somehow. Maybe it would be nice to have some kind of documentation explaining what's different on SKL and how things are supposed to work. Also, since this feature is not relying on runtime PM, it would be really nice to elaborate some IGT tests for it. You could even try to automate PC10 entry checks by reading the appropriate MSR regsiters - just like we do with PC8 on HSW. Thanks, Paulo Animesh Manna (5): drm/i915/gen9: Removed byte swapping for csr firmware drm/i915/skl: Making DC6 entry is the last call in suspend flow. drm/i915/skl: Do not disable cdclk PLL if csr firmware is present. drm/i915/skl: Block disable call for pw1 if dmc firmware is present. drm/i915/skl: Removed csr firmware load in resume path. drivers/gpu/drm/i915/i915_drv.c | 13 +- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_csr.c| 16 +++- drivers/gpu/drm/i915/intel_display.c| 11 +--- drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 45 +-- -- 6 files changed, 37 insertions(+), 52 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Mon, Aug 03, 2015 at 10:24:53AM -0700, Linus Torvalds wrote: On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o ty...@mit.edu wrote: I've just tried pulling in your updated fixes-stuff, and it avoids the oops and allows external the monitor to work correctly. Good. Have either of you tested the suspend/resume behavior? Is that fixed too? No, I haven't had a chance to test the suspend/resume behavior, because that requires suspending at work, going home, and connecting to a dock which has a different monitor attached to it, and resuming (or vice versa of suspending at home and then resuming at work). So it's a bit trickier for me to test. It's also not a regression, and the workaround of rebooting is annoying, but I've lived with it for several releases now, but I'll try the two patches/changes that folks had suggested hopefully later this week. - Ted ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o ty...@mit.edu wrote: I've just tried pulling in your updated fixes-stuff, and it avoids the oops and allows external the monitor to work correctly. Good. Have either of you tested the suspend/resume behavior? Is that fixed too? However, I'm still seeing a large number of drm/i915 related warning messages and other kernel kvetching. I suspect I can live with that for now. The lockdep one looks like it's mainly an initialization issue, so you'd never get the actual deadlock in practice, but it's obviously annoying. The intel_pm.c one I'll have to defer to the i915 people for.. I'll be travelling much of this week (flying to Finland tomorrow, back on Sunday - yay, 30h in airplanes for three days on the ground, but it's my dad's bday), and my internet will be sporadic. But I'll have a laptop and be able to pull stuff every once in a while. It would be good to have this one resolved, and I just need to worry about the remaining VM problem.. Linus [4.170749] WARNING: CPU: 0 PID: 463 at drivers/gpu/drm/i915/intel_pm.c:2339 ilk_update_wm+0x71a/0xb27 [i915]() [4.170751] WARN_ON(!r-enable) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset
On Mon, Aug 03, 2015 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
v2: Rebase.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
5 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6495996c285e..0bae7128845a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2810,6 +2810,8 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
if (offset_in_page(rot_info-uv_offset))
uv_start_page--;
+ rot_info-uv_start_page = uv_start_page;
+
rotate_pages(page_addr_list, uv_start_page,
rot_info-width_pages_uv,
rot_info-height_pages_uv,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 3daa60332e28..516a72b9b1fd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -131,6 +131,7 @@ struct intel_rotation_info {
uint64_t size;
unsigned int width_pages_uv, height_pages_uv;
uint64_t size_uv;
+ unsigned int uv_start_page;
};
struct i915_ggtt_view {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 342d96553a7b..83dadb4796a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2914,14 +2914,29 @@ u32 intel_fb_stride_alignment(struct drm_device *dev,
uint64_t fb_modifier,
}
unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
- struct drm_i915_gem_object *obj)
+ struct drm_i915_gem_object *obj,
+ unsigned int plane)
All callers pass in .plane=0; how is this supposed to work?
-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: load driver even if debugfs fails
On Mon, Aug 03, 2015 at 12:54:33PM +0200, Daniel Vetter wrote: On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote: On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote: debugfs files are not necessary for the usual operation of the driver and the device. No need to check for the return values from the debugfs file creation. Even if one debugfs file fails to create we try with the next debugfs file and ultimately return success always so that the driver continues to load. Does this even happen? realistically - I don't think it can happen. Even if it happens then there will be more serious problem like memory crunch or filesystem problem and in those cases there is no point in continuing to load the driver. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enable querying offset of UV plane with intel_plane_obj_offset
On 08/03/2015 12:56 PM, Chris Wilson wrote:
On Mon, Aug 03, 2015 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
v2: Rebase.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
5 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6495996c285e..0bae7128845a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2810,6 +2810,8 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
if (offset_in_page(rot_info-uv_offset))
uv_start_page--;
+ rot_info-uv_start_page = uv_start_page;
+
rotate_pages(page_addr_list, uv_start_page,
rot_info-width_pages_uv,
rot_info-height_pages_uv,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 3daa60332e28..516a72b9b1fd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -131,6 +131,7 @@ struct intel_rotation_info {
uint64_t size;
unsigned int width_pages_uv, height_pages_uv;
uint64_t size_uv;
+ unsigned int uv_start_page;
};
struct i915_ggtt_view {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 342d96553a7b..83dadb4796a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2914,14 +2914,29 @@ u32 intel_fb_stride_alignment(struct drm_device *dev,
uint64_t fb_modifier,
}
unsigned long intel_plane_obj_offset(struct intel_plane *intel_plane,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+unsigned int plane)
All callers pass in .plane=0; how is this supposed to work?
I forgot to include a critical piece of information in the cover letter
this time - this series only deals with GGTT mapping part of the story,
while Chandra has many more patches on top which implement the actual
rotated NV12 scanout.
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: disable_shared_pll doesn't work on pre-gen5
Looks like commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst maarten.lankho...@linux.intel.com Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. introduced the unconditional calling of disable_shared_dpll, but didn't fix up pre-gen5 to avoid the BUG_ON at the top of the function. So change the BUG_ON into a gen check (alternately we could move the BUG_ON until later, since we shouldn't have a pll struct here either, but this seems clearer to read). This fixes a crash on load on my x200s platform. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 43b0f17..b5e79b3 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1936,7 +1936,9 @@ static void intel_disable_shared_dpll(struct intel_crtc *crtc) struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc); /* PCH only available on ILK+ */ - BUG_ON(INTEL_INFO(dev)-gen 5); + if (INTEL_INFO(dev)-gen 5) + return; + if (pll == NULL) return; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
