On Tue, Oct 15, 2013 at 01:42:53PM -0700, Jesse Barnes wrote:
On Tue, 15 Oct 2013 17:09:19 -0300
Paulo Zanoni przan...@gmail.com wrote:
2013/10/14 Jesse Barnes jbar...@virtuousgeek.org:
If we disable the power well at runtime, we need to save enough display
state so we can restore it
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c |
On Tue, Oct 15, 2013 at 10:02:57AM -0700, Ben Widawsky wrote:
From: Ben Widawsky b...@bwidawsk.net
I've sent this patch several times for various reasons. It essentially
cleans up a lot of code where we need to do something per ring, and want
to query whether or not the ring exists on that
On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
If Userspace isn't using MI_PREDICATE all slices must be enabled for
backward compatibility.
If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will
force
all slices on.
v2: fix the inverted logic for
The HDMI audio expects HDMI pixel clock to be set in the audio
configuration. We've currently just set 0, using 25.2 / 1.001 kHz
frequency, which fails with some modes.
v2: Now with a commit message.
Reference:
Mengdong, I meant to CC you on these two patches. Please have a look.
I also screwed up in-reply-to, was meant to be
http://mid.gmane.org/cover.1381765995.git.jani.nik...@intel.com
BR,
Jani.
On Wed, 16 Oct 2013, Jani Nikula jani.nik...@intel.com wrote:
This will be needed for setting the
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee
Also use #ifdef to keep consistent with all other such cases.
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
We not only want const strings, but a const array of them. Reported by
checkpatch.pl
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, Oct 15, 2013 at 06:55:26PM +0100, Damien Lespiau wrote:
This series exposes the pipe CRCs on ivybridge through debugfs. It's based on
the initial work from Shuang He, with some improvements to have a nice user
space API.
There are several points in the display pipeline where CRCs can
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee
On Tue, Oct 15, 2013 at 06:55:27PM +0100, Damien Lespiau wrote:
From: Shuang He shuang...@intel.com
There are several points in the display pipeline where CRCs can be
computed on the bits flowing there. For instance, it's usually possible
to compute the CRCs of the primary plane, the sprite
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the latter is the high level interface to
flush the GEM bookkeeping in addition to flushing the GPU. As such
i915_gem_idle() also clears
On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
On Tue, 15 Oct 2013 16:54:00 -0300
Paulo Zanoni przan...@gmail.com wrote:
[...]
No that's taken into account here. In __intel_set_mode we take a
private ref on the appropriate power well so that we'll preserve state
until we do the
Yet other direct usages of the pipe number instead of pipe_name().
We've been tracking them lately but managed to miss these last ones.
v2: Catch them all! (Ville)
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com (v1)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the latter is the high level interface to
flush the GEM bookkeeping in
Hi Chris,
Thank you very much for all suggestions. Will do the changes. But for
that question below I don't have the clear answer:
On Wed, Oct 16, 2013 at 6:15 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
If Userspace isn't
On Wed, Oct 16, 2013 at 09:12:46AM -0300, Rodrigo Vivi wrote:
+ dev_priv-gt_slices.forcing_full = true;
+ i915_gt_full_immediate(dev, ring);
What happens when this fails? If it only partially emits the commands,
etc.
This is a very good question. If it fails,
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
This is useful with the follow-up patch that frobs
dev_priv-vbt.edp_bpp, and the value no longer comes directly from VBT.
---
drivers/gpu/drm/i915/intel_dp.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.
There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus
This is a prepration for adding support for multiple power-wells needed
by future HW platforms. I pushed the rest of the enabling patches to [1].
I'd like to post the generic parts of those once we agreed how to do the
power-well abstraction.
Except a spinlock-mutex change these patches shouldn't
Upcoming patches will add tracking for a set of power domains via a
bitmask; to make things simple there remove the current gap in the
enum values.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP
It is just cleaner this way and makes it easier to add support for
other HW generations with always-on power wells powering a different
set of domains.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/intel_pm.c | 84
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by
On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
This does indeed stop the server from crashing, but actually makes the
problem worse: it used to play video for a few minutes and then crash
when trying. With my patch it would play video for a few minutes and
then present
On Wed, 2013-10-16 at 00:09 +0200, Daniel Vetter wrote:
On Tue, Oct 15, 2013 at 8:15 PM, Imre Deak imre.d...@intel.com wrote:
Related to this: I made intel_encoder_get_hw_state() only check if the
power well is on and return false if it's not to indicate that the
encoder is off. I also
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville
On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present
On Wed, 16 Oct 2013 14:10:13 +0300
Imre Deak imre.d...@intel.com wrote:
On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
On Tue, 15 Oct 2013 16:54:00 -0300
Paulo Zanoni przan...@gmail.com wrote:
[...]
No that's taken into account here. In __intel_set_mode we take a
private ref
On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote:
On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
This does indeed stop the server from crashing, but actually makes the
problem worse: it used to play video for a few minutes and then crash
when trying. With my
On Tue, Oct 15, 2013 at 07:44:27PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/Makefile.am | 2 ++
lib/igt_debugfs.c | 75
+++
lib/igt_debugfs.h | 36 ++
3 files
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.
In the technical
On Wed, 2013-10-16 at 13:19 -0300, Paulo Zanoni wrote:
2013/10/16 Imre Deak imre.d...@intel.com:
There is no hard need for this to be a spin lock, as we don't take these
locks in irq context from anywhere. An upcoming patch will add calls to
punit read/write functions from within regions
On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the
On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot
On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early
On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
So clearing the valid bit should result in the GPU reporting errors for
delayed accesses, but none were reported?
So I can't actually reproduce the problem for some
On Wed, Oct 16, 2013 at 05:47:26PM +0100, Chris Wilson wrote:
On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as
On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
This patch changes HDMI port registration order for the BayTrail platform.
The story is that in kernel version 3.11 i915 supported only one HDMI port -
the HDMIB port.
On Wed, Oct 16, 2013 at 06:07:30PM +0300, Ville Syrjälä wrote:
On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 0) for consistency. (Ville Syrjälä)
On Wed, Oct 16, 2013 at 08:39:24PM +0300, Imre Deak wrote:
Since
commit 912d812e84cea8689a2bf3dd13b11dfe191f0f1e
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Oct 11 20:08:23 2012 +0200
drm/i915/crt: don't set HOTPLUG bits on !PCH
on VLV we don't detect any VGA unplug
On Thu, Oct 10, 2013 at 02:42:40PM +0300, Ville Syrjälä wrote:
On Wed, Oct 09, 2013 at 09:23:50PM +0200, Daniel Vetter wrote:
Hi all,
That little patch turned into a bit more, and on top of it there's now also
a
new testcase in igt: kms_addfb. It checks for most of the evil stuff you
BugLink: http://bugs.launchpad.net/bugs/1195483
This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Paulo Zanoni przan...@gmail.com
Cc: David Airlie airl...@linux.ie
Cc:
Hi Daniel,
A bug was opened against the Ubuntu kernel[0]. It was found that reverting the
following commit resolved this bug:
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sat May 4 10:09:18 2013 +0200
Revert drm/i915: revert eDP bpp
On Wed, Oct 16, 2013 at 07:46:27PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
Well, certainly this is user-space problem which was exposed with Jesse's
patch. However, there is a reason why we have to do this assumption - we use
touchscreen
The ringbuffer update logic should always be the same, but different
platforms have different amounts of CRC registers. Hence extract it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 30 +++---
1 file changed, 23 insertions(+),
Hi all,
I've stitched together basic CRC support for non-ivb platforms. Still need to do
a bit more testing on this, but ignoring bugs this should be it. We also need to
pimp the igt testcase a bit so that it falls back to the new PIPE source if the
PLANE1 source isn't available.
Review and
We enable the interrupt unconditionally and only control it
through the enable bit in the CRC control register.
v2: Extract per-platform helpers to compute the register values.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 74
Also add a new _PIPE_INC macro which takes an base plus increment.
Much less likely to botch the job by missing an s/A/B/ somewhere.
v2: They've moved the bitfield. Argh!
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 46
This avoids a spurious spurious interrupt warning.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 323f58e..349f149
Suggested by Ville.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
We've set up all files, but removed only those for which we have a
pipe. Which leaves the one for pipe C on machines with less than 2
pipes, breaking module reload.
v2: We can't get at the drm device this early (wtf), so just register
all the files and also remove them all again.
Signed-off-by:
Should work down to gen2. The #defines for the interrupt sources are
already there in PIPESTAT and are the same on all gmch platforms for
gen2 up to vlv.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 28 +++-
A bit a mess, since with DP/TV outputs we can't use the pipe CRC.
Also, no plane CRCs, so we need to update the basic testcases.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git
And throw in a tiny for_each_pipe refactoring for gen2.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
The PIPE_B #define was missing the display mmio offset. Use the
_PIPE_INC macro instead, it's simpler.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
On pre-gen5 and vlv we can't use the pipe source when TV-out or a DP
port is connected to the pipe. Hence we need to expose new CRC
sources.
Also simplify the existing pipe source platform code a bit by
rejecting all unhandled sources by default.
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 44 +++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c504c27..6de9e7e
With PLANE1 and PIPE CRC sources the test will work on all currently
shipping (and planed fwiw) platforms.
Also add all the other new sources for non-ivb/hsw chips.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_debugfs.c| 12 +++-
lib/igt_debugfs.h| 7
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff6970b..5841b6f 100644
---
Really simple, and we don't even have working frame numbers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote:
BugLink: http://bugs.launchpad.net/bugs/1195483
This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Paulo
On Tuesday, October 08, 2013 10:56:11 AM Daniel Vetter wrote:
The drm/i915 driver wants to adjust it's own power policies using the
cpu policies as a guideline (we can implicitly boost the cpus through
the gpus on some platforms). To avoid a dreaded select (since a
depends will leave users
On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote:
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
README | 12
1 file changed, 12 insertions(+)
diff --git a/README b/README
index 653bfcd..a04c987 100644
--- a/README
+++ b/README
@@ -96,3 +96,15 @@
70 matches
Mail list logo
