On Wed, 11 Sep 2013 22:54:54 +0100
Chris Wilson wrote:
> On Wed, Sep 11, 2013 at 01:43:20PM -0700, Jesse Barnes wrote:
> > Unsupported; we just do RC6.
>
> Same for Haswell, right?
Dunno... didn't check. Paulo?
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, Sep 11, 2013 at 11:45:19AM +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, Aaron Lu wrote:
> > It is possible the i915 driver decides not to register a backlight
> > interface for the graphics card for some reason(memory allocation failed
> > or it knows the native control does not work o
On Wed, Sep 11, 2013 at 11:25:50PM +0100, Chris Wilson wrote:
> On Wed, Sep 11, 2013 at 02:57:53PM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > As we plumb the code with more VM information, it has become more
> > obvious that the easiest way to deal with bind and unbind is to simply
On Wed, Sep 11, 2013 at 02:57:50PM -0700, Ben Widawsky wrote:
> When reserving objects during execbuf, it is possible to come across an
> object which will not fit given the current fragmentation of the address
> space. We do not have any defragment in drm_mm, so the strategy is to
> instead evict
On Wed, Sep 11, 2013 at 02:57:54PM -0700, Ben Widawsky wrote:
> @@ -464,11 +465,12 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> struct intel_ring_buffer *ring,
> bool *need_reloc)
> {
> - struct drm_i915_private *dev_pri
From: Ben Widawsky
As we plumb the code with more VM information, it has become more
obvious that the easiest way to deal with bind and unbind is to simply
put the function pointers in the vm, and let those choose the correct
way to handle the page table updates. This change allows many places in
lifted from Daniel:
pread/pwrite isn't about the object's domain at all, but purely about
synchronizing for outstanding rendering. Replacing the call to
set_to_gtt_domain with a wait_rendering would imo improve code
readability. Furthermore we could pimp pread to only block for
outstanding writes a
From: Ben Widawsky
Even though we track object activity and not VMA, because we have the
active_list be based on the VM, it makes the most sense to use VMAs in
the APIs.
NOTE: Daniel intends to eventually rip out active/inactive LRUs, but for
now, leave them be.
v2: Remove leftover hunk from th
Tracing vm eviction is really the event we care about. For the cases we
evict everything, we still will get the trace.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/i915_trace.h | 15 +++
2 files changed, 17 insertions(+)
dif
As we'll see in the next patch, being able to evict for just 1 VM is
handy.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_evict.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu
When reserving objects during execbuf, it is possible to come across an
object which will not fit given the current fragmentation of the address
space. We do not have any defragment in drm_mm, so the strategy is to
instead evict everything, and reallocate objects.
With the upcoming addition of mul
On Wed, Sep 11, 2013 at 01:43:20PM -0700, Jesse Barnes wrote:
> Unsupported; we just do RC6.
Same for Haswell, right?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.fr
On 11 September 2013 21:47, Chris Wilson wrote:
> Thanks for the patch, pushed. If you do catch me on irc, I will happily
> take build fixes and other trivial patches in any form you can supply
> them. :)
I'll endeavour to get the next patch to you via avian carriers. :)
Cheers,
Ross
___
On Wed, Sep 11, 2013 at 02:57:53PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> As we plumb the code with more VM information, it has become more
> obvious that the easiest way to deal with bind and unbind is to simply
> put the function pointers in the vm, and let those choose the correct
On Wed, Sep 11, 2013 at 02:57:52PM -0700, Ben Widawsky wrote:
> if (from != NULL) {
> - struct drm_i915_private *dev_priv =
> from->obj->base.dev->dev_private;
> - struct i915_address_space *ggtt = &dev_priv->gtt.base;
> + struct drm_i915_private *dev_priv
From: Ben Widawsky
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Upd
On Wed, Sep 11, 2013 at 02:57:51PM -0700, Ben Widawsky wrote:
> Tracing vm eviction is really the event we care about. For the cases we
> evict everything, we still will get the trace.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
> drivers/gpu/drm/i915/i
From: Ben Widawsky
With bind/unbind function pointers in place, we no longer need
insert_entries. We could, and want, to remove clear_range, however it's
not totally easy at this point. Since it's used in a couple of place
still that don't only deal in objects: setup, ppgtt init, and restore
gtt
Unsupported; we just do RC6.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_sysfs.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index c8c4112..a813905 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+
On Wed, Sep 11, 2013 at 06:02:48PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We currently use the recommended values from BSpec, but the VBT
> specifies the correct value to use for the hardware we have, so use
> it. We also fall back to the recommended value in case we can't find
> the
On Wed, Sep 11, 2013 at 06:02:51PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> There's no reason to init a DP connector if the encoder just supports
> HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
> AUX transactions to detect if there's something there. Same goes
On Wed, Sep 11, 2013 at 06:02:50PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our code makes a lot of assumptions regarding what each DDI port
> actually supports, and the VBT should tell us what is really happening
> in the hardware. So parse the information provided by the VBT and
> ch
From: Paulo Zanoni
Our code makes a lot of assumptions regarding what each DDI port
actually supports, and the VBT should tell us what is really happening
in the hardware. So parse the information provided by the VBT and
check if any of our assumptions is wrong.
Our driver also has a history of
On Wed, Sep 11, 2013 at 06:02:49PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our code currently assumes that port X will use the DP AUX channel X
> and the DDC pin X. The VBT should tell us how things are mapped, so
> add some WARNs in case we discover our assumptions are wrong (or in
>
Thanks for the patch, pushed. If you do catch me on irc, I will happily
take build fixes and other trivial patches in any form you can supply
them. :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists
From: Paulo Zanoni
We currently use the recommended values from BSpec, but the VBT
specifies the correct value to use for the hardware we have, so use
it. We also fall back to the recommended value in case we can't find
the VBT.
In addition, this code also provides some infrastructure to parse m
From: Paulo Zanoni
Our code currently assumes that port X will use the DP AUX channel X
and the DDC pin X. The VBT should tell us how things are mapped, so
add some WARNs in case we discover our assumptions are wrong (or in
case the VBT is just wrong, which is also perfectly possible).
Why would
From: Paulo Zanoni
We currently treat the child_device_config as a simple struct, but
this is not correct: new BDB versions change the meaning of some
offsets, so the struct needs to be adjusted for each version.
Since there are too many changes (today we're in version 170!), making
a big versio
From: Paulo Zanoni
There's no reason to init a DP connector if the encoder just supports
HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
AUX transactions to detect if there's something there. Same goes for a
DP connector that doesn't support HDMI, but I'm not sure these
act
2013/9/3 Rodrigo Vivi :
> On Wed, Aug 28, 2013 at 12:39 PM, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> We currently use the recommended values from BSpec, but the VBT
>> specifies the correct value to use for the hardware we have, so use
>> it. We also fall back to the recommended value in c
Signed-off-by: Ross Burton
---
test/Makefile.am | 10 ++
1 file changed, 10 insertions(+)
diff --git a/test/Makefile.am b/test/Makefile.am
index 893fa7d..26d724a 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -16,9 +16,14 @@ stress_TESTS = \
render-copyarea-size \
2013/9/6 Daniel Vetter :
> On Thu, Sep 05, 2013 at 08:40:52PM +0300, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> When transitioning away from vgacon the system tries to save the
>> current contents of the VGA memory, so that it can be cleanly handed
>> off to fbcon (or whatev
From: Paulo Zanoni
In some Haswell machines we're seeing a full system hang while calling
haswell_crtc_enable. Ville bisected the problem to the following
commit:
commit 90a8864320b2a9f91e5b5d561924a4bb70b90dcc
Author: Paulo Zanoni
Date: Fri May 3 17:23:45 2013 -0300
drm/i9
On Wed, Sep 11, 2013 at 08:44:21PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 11, 2013 at 10:07:39AM -0700, Ben Widawsky wrote:
> > On Wed, Sep 11, 2013 at 02:45:28PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 10, 2013 at 07:36:45PM -0300, Rodrigo Vivi wrote:
> > > > From: Ben Widawsky
> > > >
On Wed, Sep 11, 2013 at 10:07:39AM -0700, Ben Widawsky wrote:
> On Wed, Sep 11, 2013 at 02:45:28PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 10, 2013 at 07:36:45PM -0300, Rodrigo Vivi wrote:
> > > From: Ben Widawsky
> > >
> > > The buf pointer used during l3_write is just char *, therefore it d
On Wed, Sep 11, 2013 at 02:45:28PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 10, 2013 at 07:36:45PM -0300, Rodrigo Vivi wrote:
> > From: Ben Widawsky
> >
> > The buf pointer used during l3_write is just char *, therefore it does
> > not require the silly /4.
> >
> > Signed-off-by: Ben Widawsky
On 11 September 2013 07:50, Mika Kuoppala wrote:
> Paul Berry writes:
>
> > On 10 September 2013 06:16, Mika Kuoppala >wrote:
> >
> >> Current policy is to ban context if it manages to hang
> >> gpu in a certain time windows. Paul Berry asked if more
> >> strict policy could be available for use
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf even
Paul Berry writes:
> On 10 September 2013 06:16, Mika Kuoppala
> wrote:
>
>> Current policy is to ban context if it manages to hang
>> gpu in a certain time windows. Paul Berry asked if more
>> strict policy could be available for use cases where
>> the application doesn't know if the rendering
On Tue, Sep 10, 2013 at 07:36:45PM -0300, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> The buf pointer used during l3_write is just char *, therefore it does
> not require the silly /4.
>
> Signed-off-by: Ben Widawsky
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 4
On Wed, Sep 11, 2013 at 09:58:50AM +0200, Daniel Vetter wrote:
> Yet another regression due to
>
> commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64
> Author: Daniel Vetter
> Date: Sun Jul 21 21:37:09 2013 +0200
>
> drm/i915: clean up crtc timings computation
>
> I'm starting to wonder whet
On Wed, 2013-09-11 at 13:29 +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, Matthew Garrett wrote:
> > On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
> >
> >> Before plunging forward, have you observed any difference between the
> >> boot modes? We have reports [1] that the backlight behav
On Wed, 11 Sep 2013, Matthew Garrett wrote:
> On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
>
>> Before plunging forward, have you observed any difference between the
>> boot modes? We have reports [1] that the backlight behaviour is
>> different with UEFI vs. UEFI+CSM or legacy boot. So I
On mer., 2013-09-11 at 08:45 +, Matthew Garrett wrote:
> On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
>
> > Before plunging forward, have you observed any difference between the
> > boot modes? We have reports [1] that the backlight behaviour is
> > different with UEFI vs. UEFI+CSM or
On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
> Before plunging forward, have you observed any difference between the
> boot modes? We have reports [1] that the backlight behaviour is
> different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the
> acpi_gbl_osi_data >= ACPI_OSI
On Wed, 11 Sep 2013, Aaron Lu wrote:
> It is possible the i915 driver decides not to register a backlight
> interface for the graphics card for some reason(memory allocation failed
> or it knows the native control does not work on this card or whatever),
> so I would prefer let i915 tell ACPI vide
On Wed, 11 Sep 2013, Rodrigo Vivi wrote:
> From: Kamal Mostafa
>
> Boot params quirks_set and quirks_mask allow the user to enable or
> inhibit any dmi-matched quirks, overriding the dmi match table. Examples:
>
> i915.quirks_set=0x2 - enables QUIRK_LVDS_SSC_DISABLE
> i915.quirks_set=0x8
Yet another regression due to
commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64
Author: Daniel Vetter
Date: Sun Jul 21 21:37:09 2013 +0200
drm/i915: clean up crtc timings computation
I'm starting to wonder whether this was worth it ...
v2: Actually make it compile.
Cc: Jesse Barnes
Cc: V
We've failed to properly clear out the flags when converting a dtd to
a drm mode. For more paranoia just memset the entire structure (and
drop the now redundant clears).
Also since
commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64
Author: Daniel Vetter
Date: Sun Jul 21 21:37:09 2013 +0200
d
Jani Nikula writes:
> On Tue, 10 Sep 2013, Mika Kuoppala wrote:
>> If branch device advertise dummy enough sink, bail out early
>> trusting to sink count instead of falling back to ddc probe
>> which is deemed to fail.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=60263
>> Signe
50 matches
Mail list logo
