On Mon, Jul 08, 2013 at 11:08:32PM -0700, Ben Widawsky wrote:
> The GTT and PPGTT can be thought of more generally as GPU address
> spaces. Many of their actions (insert entries), state (LRU lists) and
> many of their characteristics (size), can be shared. Do that.
>
> The change itself doesn't ac
On Mon, Jul 08, 2013 at 11:08:34PM -0700, Ben Widawsky wrote:
> After we plumb our code to support multiple address spaces (VMs), there
> are a few situations where we want to be able to traverse the list of
> all address spaces in the system. Cases like eviction, or error state
> collection are ob
Probably need to squash whole thing, or just the inactive part, tbd...
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++--
drivers/gpu/drm/i915/i915_gem.c | 47 -
2 files changed, 35 insertions(+), 26 deletions(-)
diff --git
This is simply obj->active for now, but will serve a purpose when we
track activity per vma.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 18 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
formerly: "drm/i915: Create VMAs (part 4) - Error capture"
Since the active/inactive lists are per VM, we need to modify the error
capture code to be aware of this, and also extend it to capture the
buffers from all the VMs. For now all the code assumes only 1 VM, but it
will become more generic o
formerly: "drm/i915: Create VMAs (part 5) - move mm_list"
The mm_list is used for the active/inactive LRUs. Since those LRUs are
per address space, the link should be per VMx .
Because we'll only ever have 1 VMA before this point, it's not incorrect
to defer this change until this point in the pa
Formerly: "drm/i915: Create VMAs (part 1)"
In a previous patch, the notion of a VM was introduced. A VMA describes
an area of part of the VM address space. A VMA is similar to the concept
in the linux mm. However, instead of representing regular memory, a VMA
is backed by a GEM BO. There may be ma
formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable
tracking"
The map_and_fenceable tracking is per object. GTT mapping, and fences
only apply to global GTT. As such, object operations which are not
performed on the global GTT should not effect mappable or fenceable
characteristics.
Shamelessly manipulated out of Daniel :-)
"When moving the lists around explain that the active/inactive stuff is
used by eviction when we run out of address space, so needs to be
per-vma and per-address space. Bound/unbound otoh is used by the
shrinker which only cares about the amount of memory u
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists) and
many of their characteristics (size), can be shared. Do that.
The change itself doesn't actually impact most of the VMA/VM rework
coming up, it just fits in with
After we plumb our code to support multiple address spaces (VMs), there
are a few situations where we want to be able to traverse the list of
all address spaces in the system. Cases like eviction, or error state
collection are obvious example.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915
By Daniel's request, to make the PPGTT merging more manageable, here are the
patches associated with the VM/VMA infrastructure. They are not as well tested
as the previous series, although I would hope that without actually changing
address space, most of this series is just massaging code.
Even t
Every address space should support object allocation. It therefore makes
sense to have the allocator be part of the "superclass" which GGTT and
PPGTT will derive.
Since our maximum address space size is only 2GB we're not yet able to
avoid doing allocation/eviction; but we'd hope one day this beco
Hi all,
I hope I have found the right forum for asking my question -- apologies
if that's not the case. I have a Dell U2412M connected to a Dell
StudioSlim 540s, with the i915 driver on Fedora's 3.9.6 Kernel running
KDE (4.10.4). The monitor is connected via an HDMI cable, with a DVI
adapter to th
On Fri, Jul 5, 2013 at 5:32 PM, Daniel Vetter wrote:
> On Mon, Jul 01, 2013 at 05:47:39PM -0300, Rodrigo Vivi wrote:
>> Again, Thank you very much for your comments.
>>
>> Replying what I did and why I didn't here and patches coming later.
>
> Paulo asked me to drop by maintainer bikeshed on this
On Fri, Jul 5, 2013 at 6:58 PM, Paulo Zanoni wrote:
> Hi
>
> Sorry for the delay.
>
> 2013/7/1 Rodrigo Vivi :
>> On Fri, Jun 28, 2013 at 4:31 PM, Paulo Zanoni wrote:
>>> Hi
>>>
>>> 2013/6/28 Rodrigo Vivi :
Adding Enable and Disable PSR functionalities. This includes setting the
PSR conf
On Fri, Jul 5, 2013 at 7:48 PM, Paulo Zanoni wrote:
> 2013/6/28 Rodrigo Vivi :
>> Required function to disable PSR when going to console mode.
>> But also can be used whenever PSR mode entry conditions changed.
>>
>> v2: Add it before PSR Hook. Update function not really been called yet.
>> v3: Fi
On Mon, Jul 8, 2013 at 10:03 AM, Paulo Zanoni wrote:
> 2013/6/28 Rodrigo Vivi :
>> PSR tracking engine in HSW doesn't detect automagically some directly copy
>> area
>> operations through scanout so we will have to kick it manually and
>> reschedule it to come back to normal operation as soon as
I tried to enable psr using fbc calls and all I got was a frozen machine...
I prefer to stay with the way I'm sure it works
On Mon, Jul 8, 2013 at 4:46 PM, Daniel Vetter wrote:
> On Mon, Jul 08, 2013 at 10:13:30AM -0300, Paulo Zanoni wrote:
>> 2013/7/1 Rodrigo Vivi :
>> > PSR must be enabled afte
On Fri, Jul 05, 2013 at 02:42:04PM +0100, Chris Wilson wrote:
> Despite being a unified memory architecture (UMA) some bits of memory
> are more equal than others. In particular we have the thorny issue of
> stolen memory, memory stolen from the system by the BIOS and reserved
> for igfx use. Stole
Hi
Due to the current features that I'm implementing I started looking at
our interrupt code so I can reuse it. I noticed quite a few details
and potential problems, and I can write patches for them, but first I
think I should ask some questions to make sure I won't spend a big
time writing patche
On Mon, Jul 08, 2013 at 04:38:48PM +0300, Abdiel Janulgue wrote:
> Signed-off-by: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++
> include/uapi/drm/i915_drm.h|1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem
On Mon, Jul 08, 2013 at 04:47:38PM +0300, Abdiel Janulgue wrote:
> Expose defines for resource streamer controls.
> Based on the work of: Lukasz Anaczkowski
>
> Signed-off-by: Abdiel Janulgue
Note that drm header patches should be generated by running
$ make headers_install
in (patched) kern
On Sun, Jul 07, 2013 at 11:03:53AM -0700, Ben Widawsky wrote:
> This smells like a missing git add, but unregister was not handled
> properly in:
> commit c032d5491a4d8d56d8364f4919364815b55d3437
> Author: Daniel Vetter
> Date: Thu Jul 4 20:39:49 2013 +0200
>
> drm/i915: convert debugfs cre
On Mon, Jul 08, 2013 at 09:44:18PM +0200, Daniel Vetter wrote:
> On Mon, Jul 8, 2013 at 4:01 PM, Paulo Zanoni wrote:
> > 2013/7/5 Daniel Vetter :
> >> On Fri, Jul 05, 2013 at 12:29:14PM -0700, Ben Widawsky wrote:
> >>> On Thu, Jul 04, 2013 at 08:49:44PM +0200, Daniel Vetter wrote:
> >>> > At least
On Sat, Jul 06, 2013 at 11:41:07PM +0200, Jan Niggemann wrote:
> Hi list,
>
> I'm not sure, but I think the recent patch to keep i915 systems from
> locking up / slowing down in case of irq storms didn't fully help.
> I compiled 3.10, but every now and then, my system has the same
> symptoms as be
On Mon, Jul 08, 2013 at 10:13:30AM -0300, Paulo Zanoni wrote:
> 2013/7/1 Rodrigo Vivi :
> > PSR must be enabled after transcoder and port are running.
> > And it is only available for HSW.
> >
> > v2: move enable/disable to intel_ddi
> > v3: The spec suggests PSR should be disabled even before back
On Mon, Jul 8, 2013 at 4:01 PM, Paulo Zanoni wrote:
> 2013/7/5 Daniel Vetter :
>> On Fri, Jul 05, 2013 at 12:29:14PM -0700, Ben Widawsky wrote:
>>> On Thu, Jul 04, 2013 at 08:49:44PM +0200, Daniel Vetter wrote:
>>> > At least for the common cases where we only need special file
>>> > operations. T
On Saturday, July 06, 2013 10:26:28 PM Rafael J. Wysocki wrote:
> On Saturday, July 06, 2013 04:16:36 PM Daniel Vetter wrote:
> > On Sat, Jul 6, 2013 at 3:59 PM, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > I've just started to play with a new Acer Aspire S5 test box and noticed
> > > that
> >
2013/7/4 Daniel Vetter :
> Since the addition of VECS we have a slightly different enable
> sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
> will end up in hard to track down surprises.
>
> Hence unifiy things and since we have copies of this code in 3 places
> now, extract it i
2013/7/4 Daniel Vetter :
> It's racy: There's no guarantee that we won't walk this code (due to a
> pch fifo underrun interrupt) while someone is changing the pointers
> around.
>
> The only reason we do this is to use the righ crtc for the pch fifo
> underrun accounting. But we never expose this t
2013/7/4 Daniel Vetter :
> The current code won't report any fifo underruns on cpt if just one
> pipe has fifo underrun reporting disabled. We can't enable the
> interrupts, but we can still check the per-transcoder bits and so
> report the underrun delayed if:
> - We always clear the transcoder's
2013/7/4 Daniel Vetter :
> This way all changes to SDEIMR all go through the same function, with
> the exception of the (single-threaded) setup/teardown code.
>
> For paranoia again add an assert_spin_locked.
>
> v2: For even more paranoia also sprinkle a spinlock assert over
> cpt_can_enable_serr_
2013/7/5 Daniel Vetter :
> On Fri, Jul 05, 2013 at 12:29:14PM -0700, Ben Widawsky wrote:
>> On Thu, Jul 04, 2013 at 08:49:44PM +0200, Daniel Vetter wrote:
>> > At least for the common cases where we only need special file
>> > operations. The forcewake file is still rather more special.
>> >
>> > v
Expose defines for resource streamer controls.
Based on the work of: Lukasz Anaczkowski
Signed-off-by: Abdiel Janulgue
---
include/drm/i915_drm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..8ddda40 100644
--- a/include/dr
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9c50fa..3db1184 10064
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++
include/uapi/drm/i915_drm.h|1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 5aeb447..3d6d
Daniel Vetter suggested at some point we need to implement getparam ioctl
so userspace can figure out whether kernel supports RS at runtime.
For now, this will do to support the corresponding RFC mesa patches.
Based on the work of: Lukasz Anaczkowski
Abdiel Janulgue (2):
drm/i915/hsw: Exp
2013/7/1 Rodrigo Vivi :
> PSR must be enabled after transcoder and port are running.
> And it is only available for HSW.
>
> v2: move enable/disable to intel_ddi
> v3: The spec suggests PSR should be disabled even before backlight (by
> pzanoni)
> v4: also disabling and enabling whenever panel is
2013/6/28 Rodrigo Vivi :
> PSR tracking engine in HSW doesn't detect automagically some directly copy
> area
> operations through scanout so we will have to kick it manually and
> reschedule it to come back to normal operation as soon as possible.
>
> v2: Before PSR Hook. Don't force it when busy
2013/6/28 Rodrigo Vivi :
> PSR is enabled by default but can be disabled.
>
> v2: prefer seq_puts to seq_printf detected by Paulo Zanoni.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.c | 4
> drivers/gpu/drm/i915/i91
At Sun, 7 Jul 2013 19:59:33 -0400,
Wang xingchao wrote:
>
> On Sat, Jul 06, 2013 at 08:20:59AM +0200, Takashi Iwai wrote:
> > > >> >> > drm-intel-next. I'll show up in the next linux-next and I'll
> > > >> >> > forward it to
> > > >> >> > Dave for mergin into drm-next in roughly 2 weeks.
> > > >>
On 07/07/2013 09:19 PM, Rafael J. Wysocki wrote:
> OK, the patch is appended. Please have a look and tell me what you think.
>
> Thanks,
> Rafael
>
>
> ---
> From: Rafael J. Wysocki
> Subject: ACPI / video / i915: Remove ACPI backlight if firmware expects
> Windows 8
>
> According to Matthew
On Sat, Jul 06, 2013 at 08:20:59AM +0200, Takashi Iwai wrote:
> > >> >> > drm-intel-next. I'll show up in the next linux-next and I'll
> > >> >> > forward it to
> > >> >> > Dave for mergin into drm-next in roughly 2 weeks.
> > >> >>
> > >> >> So today I unblacklisted the audio modules on one of my
44 matches
Mail list logo
