Hi Dave,
3 fixes plus 1 prep patch, all four cc: stable. Jani will take over from
here and the plan is that he'll do 3.14-fixes for the entire release just
to work things out a bit.
Cheers, Daniel
The following changes since commit 1d2cb9a54abc6e1d239f28f07661366d5662a94a:
drm/i915: Pair
Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enables swtiching between low and high refresh rates based on the usage
scenario. This feature is applciable for internal eDP panel. Indication that
the panel supports DRRS is given by the panel EDID,
From: Pradeep Bhat pradeep.b...@intel.com
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2
From: Pradeep Bhat pradeep.b...@intel.com
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode, based on the implementaion find_panel_downclock.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane, then high refresh rate is applied.
The feature is not used in
From: Pradeep Bhat pradeep.b...@intel.com
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M N registers and the new M/N values will be used in the next
On Thu, Feb 13, 2014 at 04:11:55PM +0200, Antti Koskipää wrote:
On 02/11/2014 05:12 PM, Imre Deak wrote:
The main point of this patchset is to fix a driver unload bug caused by
incorrect order of dp aux i2c cleanup wrt. destroying the corresponding
encoder/connector objects, see the second
On Fri, Feb 14, 2014 at 03:32:21PM +0530, Vandana Kannan wrote:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1933675..3407af6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3411,11 +3411,17 @@ void
On Wed, 2014-02-12 at 23:15 +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The cursor plane also supports 180 degree rotation. Add a new
cursor-rotation property on the crtc which controls this.
Unlike sprites, the cursor has a fixed size, so
On Fri, Feb 14, 2014 at 04:31:17PM +0530, Sagar Arun Kamble wrote:
On Wed, 2014-02-12 at 23:15 +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The cursor plane also supports 180 degree rotation. Add a new
cursor-rotation property on the crtc
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a new function intel_get_crtc_scanline() that returns the current
scanline counter for the crtc.
v2: Rebase after vblank timestamp changes.
Use intel_ prefix instead of i915_ as is more customary for
display related functions.
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
From: Ville Syrjälä ville.syrj...@linux.intel.com
In interlaced modes, the pixel counter counts all pixels,
so one field will have htotal more pixels. In order to avoid
the reported position from jumping backwards when the pixel
counter is beyond the length of the shorter field, just
clamp the
On Fri, Feb 14, 2014 at 02:18:57PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the line_time_us isn't zero in the gmch watermarks code as
that would cause a div by zero. This can be triggered by specifying
a very fast pixel clock
On Fri, Feb 14, 2014 at 12:28:29PM +, Chris Wilson wrote:
On Fri, Feb 14, 2014 at 02:18:57PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the line_time_us isn't zero in the gmch watermarks code as
that would cause a div by
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
Split out from Chris vma-bind rework.
Jani wondered why this is save, and the reason is that i915_vma_unbind
does all these checks, too. So they're redundant.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Jani Nikula jani.nik...@intel.com
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
v2: Undo the behaviour change in object_pin that Chris spotted.
v3: Split out misplaced hunk to handle set_cache_level errors,
spotted by Jani.
Only the hardware really access them, so no need to have cpu
gtt access available.
Split out from Chris vma-bind rework.
Note that this is only possible due to the split-up of the mappable
pin flag into PIN_GLOBAL and PIN_MAPPABLE.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky
We access it through the cpu window. No functional difference expected
atm since we default to a bottom-up allocation scheme. But that might
eventually change so that we prefer the unmappable range for buffers
that don't need cpu gtt access.
Split out from Chris vma-bind rework.
Note that this
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3
So I've finally gotten around to shuffle these patches a bit more and hopefully
in the process cleared up any lingering misunderstandings I've had about Chris'
originally patch.
I'll pull this in later today (presuming nothing bad shows up) and then cut a
new -testing before heading off for 2
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3
Tighter code since legacy gem has only mappable anyway.
Split out from Chris vma-bind rework.
Note that this is only possible due to the split-up of the mappable
pin flag into PIN_GLOBAL and PIN_MAPPABLE.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
This is prep work for reworking the object_pin logic. Atm
it still does a (now redundant) lookup of the vma. The next
patch will fix this.
Split out from Chris vma-bind rework.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Reviewed-by: Jani Nikula
With abitrary pin flags it makes sense to split out a please bind
this into global gtt from the please allocate in the mappable
range.
Use this unconditionally in our global gtt pin helper since this is
what its callers want. Later patches will drop PIN_MAPPABLE where it's
not strictly needed.
One side-effect of the introduction of ppgtt was that we needed to
rebind the object into the appropriate vm (and global gtt in some
peculiar cases). For simplicity this was done twice for every object on
every call to execbuffer. However, that adds a tremendous amount of CPU
overhead (rewriting
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 12
Spotted while auditing the code for fencing issues.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_overlay.c | 2 +-
2 files changed, 6 insertions(+), 6
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.
Spurred by Ville's report that something goes wrong here and
originally I've thought that this might slip through the pwrite
On Fri, Feb 14, 2014 at 02:01:10PM +0100, Daniel Vetter wrote:
So I've finally gotten around to shuffle these patches a bit more and
hopefully
in the process cleared up any lingering misunderstandings I've had about
Chris'
originally patch.
I'll pull this in later today (presuming
On Fri, Feb 14, 2014 at 01:08:05PM +, Chris Wilson wrote:
On Fri, Feb 14, 2014 at 02:01:10PM +0100, Daniel Vetter wrote:
So I've finally gotten around to shuffle these patches a bit more and
hopefully
in the process cleared up any lingering misunderstandings I've had about
Chris'
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter
Hi Dave,
First pull request for 3.15! One week later than usual since our QA was
celbrating Chines New Year ;-)
drm-intel-next-2014-02-07:
- Yet more steps towards atomic modeset from Ville.
- DP panel power sequencing improvements from Paulo.
- irq code cleanups from Ville.
- 5.4 GHz dp lane
Looks like I've missed one of the potential NULL deref bugs in Jesse's
fbdev-fb embedded struct to pointer conversions. Fix it up.
This regression has been introduced in
commit 8bcd45534ddf68ab71aeed709dacd9cf65dc0f75
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Feb 7 12:10:38 2014
On Fri, 14 Feb 2014 16:35:54 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Looks like I've missed one of the potential NULL deref bugs in Jesse's
fbdev-fb embedded struct to pointer conversions. Fix it up.
This regression has been introduced in
commit
On Fri, 14 Feb 2014 15:32:18 +0530
Vandana Kannan vandana.kan...@intel.com wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
sometime later starting with the WARN below.
Regression introduced in
commit 6a9c4b35e6696a63805b6da5e4889c6986e9ee1b
Author: Rui Guo
On Fri, Feb 14, 2014 at 02:06:06PM +0100, Daniel Vetter wrote:
Spotted while auditing the code for fencing issues.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
On Fri, Feb 14, 2014 at 07:23:32PM +0200, Imre Deak wrote:
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
sometime later starting with the WARN below.
That's a very nice find.
But you can tidy this loop up
On Fri, 2014-02-14 at 17:35 +, Chris Wilson wrote:
On Fri, Feb 14, 2014 at 07:23:32PM +0200, Imre Deak wrote:
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
sometime later starting with the WARN below.
On Fri, Feb 14, 2014 at 07:48:18PM +0200, Imre Deak wrote:
On Fri, 2014-02-14 at 17:35 +, Chris Wilson wrote:
@@ -382,18 +379,15 @@ void intel_detect_pch(struct drm_device *dev)
DRM_DEBUG_KMS(Found LynxPoint LP PCH\n);
Hi all,
New -testing cycle with cool stuff:
- Fix the execbuf rebind performance regression due to topic/ppgtt (Chris).
- Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre).
- Try to preserve the firmware modeset config on driver load. And a bit of prep
work for
On Fri, Feb 14, 2014 at 05:29:30PM +, Damien Lespiau wrote:
On Fri, Feb 14, 2014 at 02:06:06PM +0100, Daniel Vetter wrote:
Spotted while auditing the code for fencing issues.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by:
On Fri, Feb 14, 2014 at 08:23:54PM +0200, Imre Deak wrote:
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
starting with the WARN below.
Regression introduced in
commit
On Fri, Feb 14, 2014 at 09:09:52AM +0200, Jani Nikula wrote:
It seems that it will be better to track this in bugzilla rather than
the mailing lists. Please file a bug on DRM/Intel component at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI. Attach these
files.
Done. We can
On Tue, Feb 11, 2014 at 05:12:17PM +0100, Daniel Vetter wrote:
On Thu, Feb 06, 2014 at 11:42:39AM -0200, Rodrigo Vivi wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Jan 29, 2014 at 2:25 AM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
Signed-off-by: Ben Widawsky
On Fri, Feb 14, 2014 at 12:34:22PM -0800, Ben Widawsky wrote:
On Tue, Feb 11, 2014 at 05:12:17PM +0100, Daniel Vetter wrote:
- 6/9 lacks review ...
6/9 can be skipped for this series, though I think it's a reasonable
patch. Maybe Chris or Jesse has an opinion on 6/9?
Yes, programming
On certain OpenGL benchmark applications, setting this bit results in
frequent GPU hangs. On BYT-M/I, the hangs go away by not setting this
bit.
---
drivers/gpu/drm/i915/intel_pm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
In commit e4e0c058a19c41150d12ad2d3023b3cf09c5de67
Author: Eugeni Dodonov eugeni.dodo...@intel.com
Date: Wed Feb 8 12:53:50 2012 -0800
drm/i915: gen7: Implement an L3 caching workaround.
the L3 cache aging was disabled. This was part of a shotgun response
to a number of GPU hang bugs, but
I get the following splat in my tests running 3.14-rc2:
[3.955123] WARNING: CPU: 0 PID: 1 at
/work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_display.c:857
intel_wait_for_pipe_off+0x17a/0x2d0()
[3.955124] pipe_off wait timed out
[3.955127] CPU: 0 PID: 1 Comm:
Allow fd_set_cloexec / fd_set_nonblock to be used outside of intel_device.c.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/intel_device.c | 8
src/intel_driver.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/intel_device.c b/src/intel_device.c
Once the xserver stops running as root on kms capabable systems, we will need
some other way to access the backlight.
The approach taken in this patch leaves most of the heavy lifting (wrt
doing everything suid root safe) to pkexec, as is done in ie
gnome-settings-daemon, which controls the
O_NONBLOCK is a status flag not a descriptor flag, so F_GETFL / F_SETFL should
be used to modify it.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/intel_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index
On Sat, Feb 15, 2014 at 12:02:35AM +0100, Hans de Goede wrote:
O_NONBLOCK is a status flag not a descriptor flag, so F_GETFL / F_SETFL should
be used to modify it.
Signed-off-by: Hans de Goede hdego...@redhat.com
Oops, that was a silly typo that unfortunately compiled.
Thanks,
-Chris
--
On Sat, Feb 15, 2014 at 12:02:37AM +0100, Hans de Goede wrote:
Once the xserver stops running as root on kms capabable systems, we will need
some other way to access the backlight.
The approach taken in this patch leaves most of the heavy lifting (wrt
doing everything suid root safe) to
58 matches
Mail list logo
