On Mon, 07 Apr 2014, Daniel Vetter wrote:
> On Mon, Apr 7, 2014 at 4:35 PM, Alex Deucher wrote:
>> On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote:
>>> To support bare address requests used by the drm dp helpers.
>>>
>>> Signed-off-by: Jani Nikula
>>>
>>> ---
>>>
>>> Hi Alex, similar to Thier
On Mon, Apr 7, 2014 at 11:58 PM, Ben Widawsky wrote:
> Blocking important fixes for a test case is harmful to customers of our
> software. I won't argue past that. If you won't take it as is, add it to the
> JIRA task like you said. I'll carry this one around with my dynamic page table
> allocatio
On Tue, 2014-04-08 at 06:45 +, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 04:32:02AM +, Gupta, Sourab wrote:
> > Hi Rodrigo,
> > In this patch, while freeing the purgeable stolen object, the memory
> > node also has to be freed, so as to make space for new object. We need
> > to call drm
On Mon, Apr 07, 2014 at 02:58:34PM -0700, Ben Widawsky wrote:
> Blocking important fixes for a test case is harmful to customers of our
> software. I won't argue past that. If you won't take it as is, add it to the
> JIRA task like you said. I'll carry this one around with my dynamic page table
> a
On Tue, Apr 08, 2014 at 04:32:02AM +, Gupta, Sourab wrote:
> Hi Rodrigo,
> In this patch, while freeing the purgeable stolen object, the memory
> node also has to be freed, so as to make space for new object. We need
> to call drm_mm_remove_node while freeing obj.
>
> The below modification pa
On Mon, Apr 07, 2014 at 11:20:14PM +0100, Damien Lespiau wrote:
> 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
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 "2560x1440"x60.0 312.25
On Mon, 7 Apr 2014 23:25:20 +0200
Daniel Vetter 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 intel_alloc_plane_ob
On Mon, 2014-03-24 at 17:30 +, Gupta, Sourab wrote:
> From: Akash Goel
>
> 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 pipe_control with a
On Mon, 2014-04-07 at 20:01 +, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> 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 evictin
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
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed, 3 insertions(+), 3 delet
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
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 i915_gem_evict_
On Mon, Apr 07, 2014 at 08:24:34PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> 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/
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
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> 1 file ch
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 nee
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
drivers/
GEN8 now has a qword to code for 48bit addresses.
Signed-off-by: Damien Lespiau
---
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
--- a/drivers/gpu/drm/i915/i915_
Signed-off-by: Damien Lespiau
---
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
--- a/drivers/gpu/drm/i915/
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
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915
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
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:
On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote:
> From: Deepak S
>
> 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
> Signed-off-by: Rodrigo Vivi
> ---
> d
On Mon, Apr 7, 2014 at 8:12 PM, Damien Lespiau wrote:
>> 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 for upstreaming, but many people
>> have worked on this series bef
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 r
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
---
dri
2014-03-07 13:32 GMT-03:00 :
> From: Ville Syrjälä
>
> We may have use for vblank interrupts during plane enabling/disabling, so
> don't call drm_vblank_off() until planes are off, and call
> drm_vblank_on() just before we start to enable the planes.
Just like the previous patch, this one also n
On Thu, Mar 27, 2014 at 05:59:29PM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> 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 for upstreaming,
2014-03-07 13:32 GMT-03:00 :
> From: Ville Syrjälä
>
> 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 improved? Are we solving a bug? What are the
risks? What's the
2014-03-10 8:57 GMT-03:00 Daniel Vetter :
> On Mon, Mar 10, 2014 at 12:20 PM, Ville Syrjälä
> 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: Ville Syrjälä
>>> >
>>> > We w
From: Ben Widawsky
Cc: Kenneth Graunke
Signed-off-by: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_
From: Deepak S
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
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --g
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: dma_buf
From: Chris Wilson
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 space in the vma when bind
From: Mika Kuoppala
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: https://bugs.freedesktop.org/show_bug.cgi?id=75876
Signed-off-by:
From: Chris Wilson
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 to leak the storage.
Th
From: Chris Wilson
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 reference into account
when res
On Mon, Apr 7, 2014 at 4:35 PM, Alex Deucher wrote:
> On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote:
>> To support bare address requests used by the drm dp helpers.
>>
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> Hi Alex, similar to Thierry's patch for i915.
>>
>
> Looks good to me.
>
> Rev
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: dma_buf
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
uwe
2014-03-07 13:32 GMT-03:00 :
> From: Ville Syrjälä
>
> 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 Syrjälä
Reviewed-by: Paulo Zanoni
> ---
> drivers
On Thu, Mar 27, 2014 at 06:00:13PM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2347,6 +2347,7 @@ int gen8_switch_context_queue(struct intel_engine *ring,
> struct i915_hw_c
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:
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
2014-03-07 13:32 GMT-03:00 :
> From: Ville Syrjälä
>
> 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ä
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c | 66
> +
2014-03-07 13:32 GMT-03:00 :
> From: Ville Syrjälä
>
> 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 inactive pipes.
>
> Signed-off-by: Ville Syrjälä
Reviewed-b
On Mon, 07 Apr 2014 11:36:46 +0300
Jani Nikula wrote:
> On Sat, 05 Apr 2014, Jesse Barnes 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 pa
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"
This patch series adds a new ioctl to resize a gem object.
I'm tired, but off the top of my head, I t
On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula wrote:
> To support bare address requests used by the drm dp helpers.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Hi Alex, similar to Thierry's patch for i915.
>
Looks good to me.
Reviewed-by: Alex Deucher
Do you want me to add this to the patch set?
2014-03-07 13:32 GMT-03:00 :
> From: Ville Syrjälä
>
> 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 separate the multi-pipe intel_wm_config computation
> from
So it's clear what the condition is. We'll add a bit more code shortly.
Signed-off-by: Damien Lespiau
---
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 b/drivers/gpu/drm/i915/i915_gem.c
index 1a58e6e..998
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() functio
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 problem
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"
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 the
magic extension to
2014-04-05 15:51 GMT-03:00 Jesse Barnes :
> Needs to happen after clock is running or it doesn't behave correctly.
>
> v2: fix subject (Ville)
> make it clearer that this occurs in pre_enable (Paulo)
> misc bikesheds (Paulo)
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Paulo Zanoni
> --
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 -0700, Ben Widawsky wrote:
> > > > The issue I was seeing appeare
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 b
---
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
+++ b/drivers/gpu/
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
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
differ
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
differ
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: Sour
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
---
dri
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
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31 +++
include/drm/drm_crtc.
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
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9 +++--
1 file changed, 7
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
> Cc: dri-de...@lists.freedesktop.org
> ---
This patch series is being
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 exampl
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula
---
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 a/drivers/gpu/drm/i915/intel_dp.c
On Sat, 05 Apr 2014, Jesse Barnes 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 DP_SET_POWER. Even
when the pa
69 matches
Mail list logo
