On Sat, Apr 05, 2014 at 11:52:38AM -0700, Jesse Barnes wrote:
On Sat, 5 Apr 2014 17:22:40 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Apr 05, 2014 at 07:29:22AM +0100, Chris Wilson wrote:
On Fri, Apr 04, 2014 at 04:12:09PM -0700, Jesse Barnes wrote:
This always indicates a bug
On Sat, Apr 05, 2014 at 02:55:53PM -0700, Ben Widawsky wrote:
As we've learned over time, the HW context is just a series of GPU
commands that we're able to decode without intel_error_decode. Since
Correct to ... without any changes in intel_error_decode. ... since I
presumed that's what you
Apparently it doesn't work. X-tiled self-refresh works flawlessly
otoh. It's unclear whether this just borked wm setup from our side or
a hw restriction, but just disabling gets things going.
Note that this regression was only brought to light with
commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581
On Sat, 05 Apr 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
This only applies to external sinks.
[citation needed]
eDP 1.3 has SET_POWER_CAPABLE (bit 7) in in DPCD
EDP_GENERAL_CAPABILITY_REGISTER_1 (register 0x702) which indicates
whether panel power state can be controlled through
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Hi Alex, similar to Thierry's patch for i915.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
On Sun, Apr 06, 2014 at 11:35:03AM -0700, Ben Widawsky wrote:
On Sat, Apr 05, 2014 at 07:45:28PM -0700, Ben Widawsky wrote:
The issue I was seeing appeared to seeing from sigkill. In such a case,
the process may want to die before the context/work/address space is
freeable. For example:
On Apr-07-2014 3:33 PM, Kannan, Vandana wrote:
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: dri-de...@lists.freedesktop.org
---
This
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31
Create and attach the drm property to set aspect ratio. If there is no user
specified value, then PAR_NONE/Automatic option is set by default. User can
select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would
come into effect with a mode set.
Signed-off-by: Vandana Kannan
On Thu, 2014-04-03 at 14:11 +0530, sourab gupta wrote:
On Wed, 2014-03-26 at 13:20 +0530, sourab gupta wrote:
Hi Ville/Damien,
Can you please review the below patch(v3) for mmio flips.
Thanks,
Sourab
On Sun, 2014-03-23 at 09:01 +, Gupta, Sourab wrote:
From: Sourab Gupta
This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.
The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780 and
these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.
The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780 and
these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
On Mon, Apr 07, 2014 at 10:42:56AM +0100, Chris Wilson wrote:
On Sun, Apr 06, 2014 at 11:35:03AM -0700, Ben Widawsky wrote:
On Sat, Apr 05, 2014 at 07:45:28PM -0700, Ben Widawsky wrote:
The issue I was seeing appeared to seeing from sigkill. In such a case,
the process may want to die
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3316ec190d9c..1fefba56e073 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based on earlier patches
On 27/03/2014 22:23, Chris Wilson wrote:
On Thu, Mar 27, 2014 at 03:28:26PM +, arun.siluv...@linux.intel.com wrote:
From: Siluvery, Arun arun.siluv...@intel.com
This patch series adds a new ioctl to resize a gem object.
I'm tired, but off the top of my head, I think you can do away with
I feel like it'd be wise, when we merge execlists support, to provide a way to
disable them, just in case.
Actually, it may be even wiser, would we want to merge them early, to merge
execlists disabled by default.
--
Damien
Damien Lespiau (2):
drm/i915: Factor out a enable_execlists()
Execlist are relatively new, and so it'd be wise to be able to merge
that support disabled by default while still allowing a module parameter
to enable that feature.
Even if we end up enabling execlists by default, it'll be handy to be
able to switch back to ring submission to debug subtle
So it's clear what the condition is. We'll add a bit more code shortly.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_pipe_wm will be used to track the state in different stages
of the watermark update process. For that we need to keep a bit
more state in intel_pipe_wm.
We also need to
On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula jani.nik...@intel.com wrote:
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Hi Alex, similar to Thierry's patch for i915.
Looks good to me.
Reviewed-by: Alex Deucher
On 04/07/2014 02:18 PM, Siluvery, Arun wrote:
On 27/03/2014 22:23, Chris Wilson wrote:
On Thu, Mar 27, 2014 at 03:28:26PM +,
arun.siluv...@linux.intel.com wrote:
From: Siluvery, Arun arun.siluv...@intel.com
This patch series adds a new ioctl to resize a gem object.
I'm tired, but off
On Mon, 07 Apr 2014 11:36:46 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Sat, 05 Apr 2014, Jesse Barnes jbar...@virtuousgeek.org wrote:
This only applies to external sinks.
[citation needed]
eDP 1.3 has SET_POWER_CAPABLE (bit 7) in in DPCD
EDP_GENERAL_CAPABILITY_REGISTER_1
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Even though the inactive pipes should have their watermarks set to all 0
with enable=true, we can possibly shave off a few cycles by completely
skipping the merge procedure for
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We will have another use for the maximum watermark values that the
registers can hold. Pull those out into separate functions.
Signed-off-by: Ville Syrjälä
On Mon, Apr 07, 2014 at 03:05:39PM +0100, Damien Lespiau wrote:
Execlist are relatively new, and so it'd be wise to be able to merge
that support disabled by default while still allowing a module parameter
to enable that feature.
Even if we end up enabling execlists by default, it'll be
On Mon, Apr 07, 2014 at 01:30:04PM +0100, Chris Wilson wrote:
On Mon, Apr 07, 2014 at 02:15:00PM +0200, Daniel Vetter wrote:
On Mon, Apr 07, 2014 at 10:42:56AM +0100, Chris Wilson wrote:
On Sun, Apr 06, 2014 at 11:35:03AM -0700, Ben Widawsky wrote:
On Sat, Apr 05, 2014 at 07:45:28PM
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We already do this for HSW, but doing it makes sense for everything else
as well. Extend it for ILK/SNB/IVB since that's where the new watermark
code is used.
Signed-off-by: Ville
I wrote:
I noticed that VGA output (external display) cannot be turned on.
Following the advice in another thread on intel-gfx I have created bug report
https://bugs.freedesktop.org/show_bug.cgi?id=77137
No need to reply to my mail anymore
Thanks,
Uwe Geuder
Nomovok Ltd.
Tampere, Finland
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Bring UP Power Wells before disabling RC6. - Reviewer:
Patch drm/i915:
On Mon, Apr 7, 2014 at 4:35 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula jani.nik...@intel.com wrote:
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Hi Alex, similar to Thierry's
From: Chris Wilson ch...@chris-wilson.co.uk
Across a device reset, we try to restore and user forcewake reference
counts. This is complicated by our deferred forcewake put adding an
extra reference, that may or may not be flushed when we call
del_timer_sync. So we have to take that pending
From: Chris Wilson ch...@chris-wilson.co.uk
Since dma_buf_vunmap() procedes blithely on ignorant of whether the
driver failed to actually unmap the backing storage for the dma-buf, we
need to make a best-effort to do so. This involves not allowing
ourselves to be susceptible to signals causing us
From: Mika Kuoppala mika.kuopp...@linux.intel.com
Piglit runner and QA are both looking at the dmesg for
DRM_ERRORs with test cases.
Add flag to stop_rings debugfs interface to prevent DRM_ERROR
output when default context banning is being tested.
References:
From: Deepak S deepa...@intel.com
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit message. (Daniel)
Signed-off-by: Deepak S deepa...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Bring UP Power Wells before disabling RC6. - Reviewer:
Patch drm/i915:
From: Chris Wilson ch...@chris-wilson.co.uk
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous
From: Ben Widawsky benjamin.widaw...@intel.com
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
2014-03-10 8:57 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Mon, Mar 10, 2014 at 12:20 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Mar 07, 2014 at 10:29:26PM +0100, Daniel Vetter wrote:
On Fri, Mar 07, 2014 at 06:32:14PM +0200, ville.syrj...@linux.intel.com
wrote:
From:
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Rather than have a wait_for_vblank() in the primary plane enable/disable
funcs, move the wait_for_vblank() to happen after enabling/disabling all
planes.
Why exactly? What is
On Thu, Mar 27, 2014 at 05:59:29PM +, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
Hi all,
This patch series implement execlists for GEN8+. Before continuing, it
is important to mention that I might have taken upon myself to
assemble the series and rewrite it
In gen8, 32b PPGTT has always had one pdp (it doesn't actually have
one, but it resembles having one). The #define was confusing as is, and
using PDPE is a much better description.
sed -i 's/GEN8_LEGACY_PDPS/GEN8_LEGACY_PDPES/' drivers/gpu/drm/i915/*.[ch]
Signed-off-by: Ben Widawsky
Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC
return value to detect overlapping framebuffers (which the bios uses
always when lighting up more than one screen). All this fanciness
happens in intel_alloc_plane_obj in intel_display.c.
Since no one else uses this we can savely
On Mon, Apr 07, 2014 at 11:58:28AM -0700, Ben Widawsky wrote:
On Mon, Apr 07, 2014 at 01:30:04PM +0100, Chris Wilson wrote:
On Mon, Apr 07, 2014 at 02:15:00PM +0200, Daniel Vetter wrote:
On Mon, Apr 07, 2014 at 10:42:56AM +0100, Chris Wilson wrote:
On Sun, Apr 06, 2014 at 11:35:03AM
On Mon, Apr 07, 2014 at 11:50:06PM +0200, Daniel Vetter wrote:
On Mon, Apr 07, 2014 at 11:58:28AM -0700, Ben Widawsky wrote:
On Mon, Apr 07, 2014 at 01:30:04PM +0100, Chris Wilson wrote:
On Mon, Apr 07, 2014 at 02:15:00PM +0200, Daniel Vetter wrote:
On Mon, Apr 07, 2014 at 10:42:56AM
It seems like it wouldn't be too unlikely to be wanting to use a an
expression in the macro argument and things could go very wrong.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3697433..a646ed4 100644
GEN8 now has a qword to code for 48bit addresses.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 22d8b14..bc5ec33 100644
---
STORE_REGISTER_MEM has now one extra dword on gen8. This series is not exactly
well tested.
--
Damien
Damien Lespiau (3):
drm/i915: Protect the argument expansion in LRI and SRM macros
drm/i915/bdw: Provide a gen8 version of SRM
drm/i915/bdw: Use the GEN8 SRM when qeueing a flip
On Mon, Apr 07, 2014 at 01:59:17PM -0700, Ben Widawsky wrote:
Cool. This explains the bad DERRMR values I was seeing in in error
states. I'm honestly didn't check if we actually need an SRM for BDW
still, but I'll assume you did check.
Just checked, the LRI command still mentions that we need
On Mon, Apr 07, 2014 at 08:24:32PM +0100, Damien Lespiau wrote:
It seems like it wouldn't be too unlikely to be wanting to use a an
expression in the macro argument and things could go very wrong.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |
On Mon, Apr 07, 2014 at 08:24:34PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Our current code cannot handle a failure to evict well. You'll get at
the very least the following splat, but usually a lot worse fallout after:
[ 134.819441] [ cut here ]
[ 134.819467] WARNING: CPU: 3 PID: 442 at
drivers/gpu/drm/i915/i915_gem_evict.c:230
On Sun, Apr 06, 2014 at 12:58:56PM -0700, Ben Widawsky wrote:
Screwed up the CC... my bad. Basically, I started doing my own state
setup thing, and thought Mika could benefit. In the end my thing didn't
solve the problem I was trying to solve.
Okay, I botched the patch too. See below, if you
It is now clear that this interrupt is for the primary plane and not
something global to the pipe. It also matches what the spec calls it.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed,
On Mon, 2014-04-07 at 20:01 +, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle
On Mon, 2014-03-24 at 17:30 +, Gupta, Sourab wrote:
From: Akash Goel akash.g...@intel.com
This workaround is needed on VLV for the HW context feature.
It is used after adding the mi_set_context command in ring buffer
for Hw context switch. As per the spec
The software must send a
On Mon, 7 Apr 2014 23:25:20 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC
return value to detect overlapping framebuffers (which the bios uses
always when lighting up more than one screen). All this fanciness
happens in
Ville et al,
It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
another commit in 3.13.7) broke modes which require DVI-D dual-link,
eg 2560x1440 with my panel.
I don't see these modelines in 3.13.7 or later (eg 3.14):
[ 5.582] (II) intel(0): Modeline 2560x1440x60.0 312.25
60 matches
Mail list logo
