On Tuesday 06 May 2014 03:20 AM, Daisy Sun wrote:
RP frequency request is affected by 2 modules: normal turbo
algorithm and RPS boost algorithm. By adding RPS boost algorithm
to the mix, the final frequency becomes relatively unpredictable.
Add a switch to enable/disable RPS boost functionality.
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index fec8114..a4ea50a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/
From: Chris Wilson
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This ha
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 33f9abd..15ede8e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/
This HACK allows users to reuse the userptr ioctl in order to
pre-reserve the VMA at a specific location. The vma will follow all the
same paths as other userptr objects - only the drm_mm node is actually
allocated.
Again, this patch is a big HACK to get some other people currently using
userptr e
This is needed for the proof of concept work that will allow mirrored
GPU addressing via the existing userptr interface. Part of the hack
involves passing the context ID to the ioctl in order to get a VM.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 120 +
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b3b52cf..0848638 100644
--- a/drivers/gpu/
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop use ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top l
After this change, the old GGTT keeps its insert_entries/clear_range
functions as we don't expect those to ever change in terms of page table
levels. The address space now gets map_vma/unmap VMA. It better reflects
the operations we actually want to support for a VMA.
I was too lazy, but the GGTT
Map is easy, it's the same register as the PDP descriptor 0, but it only
has one entry. Also, the mapping code is now trivial thanks to all of
the prep patches.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 53 +
drivers/gpu/drm/i915/i9
There is no need to preallocate the aliasing PPGTT. The code is properly
plubmed now to treat this address space like any other.
v2: Updated for CHV. Note CHV doesn't support 64b address space.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 281 ---
v2: 0 pad the new 8B fields or else intel_error_decode has a hard time.
Note, regardless we need an igt update.
v3: Make reloc_offset 64b also.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 18 ++
2 files
Don't do them if they're not necessary, which they're not, for the RCS,
in certain conditions.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 20
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/dr
The code for 4lvl works just as one would expect, and nicely it is able
to call into the existing 3lvl page table code to handle all of the
lower levels.
PML4 has no special attributes.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 170 ---
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier to swallow. The patch also introduces the PML4, ie. the new top
level structure of the page tables.
Signed-off-by: Ben Widawsky
---
drivers/gpu/d
I was getting unexplainable hangs with the last patch, even though I
think it should be correct. As the subject says, should this ever get
merged, it needs to be coordinated with the patch this reverts.
Revert "drm/i915/bdw: Optimize PDP loads"
This reverts commit 64053129b5cbd3a5f87dab27d026c17e
This works the same as GEN6.
I was disappointed that I need to pass vm around now, but it's not so
much uglier than the drm_device, and having the vm in trace events is
hugely important.
v2: Consolidate pagetable/pagedirectory events
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_ge
Similar to the patch a few back in the series, we can always map and
unmap page directories when we do their allocation and teardown. Page
directory pages only exist on gen8+, so this should only effect behavior
on those platforms.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gt
With a little bit of macro magic, and the fact that every page
table/dir/etc. we wish to map will have a page, and daddr member, we can
greatly simplify and reduce code.
The patch introduces an i915_dma_map/unmap which has the same semantics
as pci_map_page, but is 1 line, and doesn't require newl
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 54 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 10 +++
2 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_g
The docs say you cannot change the PDEs of a currently running context. If you
are changing the PDEs of the currently running context then. We never
map new PDEs of a running context, and expect them to be present - so I
think this is okay. (We can unmap, but this should also be okay since we
only
This finishes off the dynamic page tables allocations, in the legacy 3
level style that already exists. Most everything has already been setup
to this point, the patch finishes off the enabling by setting the
appropriate function pointers.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i91
Instead of implementing the full tracking + dynamic allocation, this
patch does a bit less than half of the work, by tracking and warning on
unexpected conditions. The tracking itself follows which PTEs within a
page table are currently being used for objects. The next patch will
modify this to act
This is probably not required since BDW is hopefully a bit more robust
that previous generations. Realize also that scratch will not exist for
every entry within the page table structure. Doing this would waste
an extraordinary amount of space when we move to 4 level page tables.
Therefore, the scr
This patch continues on the idea from the previous patch. From here on,
in the steady state, PDEs are all pointing to the scratch page table (as
recommended in the spec). When an object is allocated in the VA range,
the code will determine if we need to allocate a page for the page
table. Similarly
One important part of this patch is we now write a scratch page
directory into any unused PDP descriptors. This matters for 2 reasons,
first, it's not clear we're allowed to just use 0, or an invalid
pointer, and second, we must wipe out any previous contents from the last
context.
The latter poin
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 59 +++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 32
drivers/gpu/drm/i915/i915_gem_gtt.h | 9 ++
3 files changed, 85 insertions(+), 15 deletions(-)
diff --git a/drivers/
There is never a case where we don't want to do it. Since we've broken
up the allocations into nice clean helper functions, it's both easy and
obvious to do the dma mapping at the same time.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 78
These values are never quite useful for dynamic allocations of the page
tables. Getting rid of them will help prevent later confusion.
TODO: this probably needs to be earlier in the series
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 -
drivers/gpu/drm/i915/i
The page directory freer is left here for now as it's still useful given
that GEN8 still preallocates. Once the allocation functions are broken
up into more discrete chunks, we'll follow suit and destroy this
leftover piece.
comments
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem
Map and unmap are common operations across all generations for
pagetables. With a simple helper, we can get a nice net code reduction
as well as simplified complexity.
There is some room for optimization here, for instance with the multiple
page mapping, that can be done in one pci_map operation.
Like with gen6/7, we can enable bitmap tracking with all the
preallocations to make sure things actually don't blow up.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 101 +++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 12 +
2 files changed
Now that we don't need to trace num_pd_pages, we may as well kill all
need for the PPGTT structure in the alloc_pagedirs. This is very useful
for when we move to 48b addressing, and the PDP isn't the root of the
page table structure.
The param is replaced with drm_device, which is an unavoidable w
Having a more general way of doing mappings will allow the ability to
easy map and unmap a specific page table. Specifically in this case, we
pass down the page directory + entry, and the page table to map. This
works similarly to the x86 code.
The same work will need to happen for GEN8. At that p
When we do dynamic page table allocations for gen8, we'll need to have
more control over how and when we map page tables, similar to gen6.
This patch adds the functionality and calls it at init, which should
have no functional change.
The PDPEs are still a special case for now. We'll need a funct
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 43 ++---
1 file changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 14aae05..10cfad8 100644
--- a/drivers/gp
We have some fanciness coming up. This patch just breaks out the logic.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_ge
Therefore we can do it from our general init function. Eventually, I
hope to have a lot more commonality like this. It won't arrive yet, but
this was a nice easy one.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
di
These page table helpers make the code much cleaner. There is some
room to use the arch/x86 header files. The reason I've opted not to is
in several cases, the definitions are dictated by the CONFIG_ options
which do not always indicate the restrictions in the GPU. While here,
clean up the defines
It's useful to have it not as a macro for some upcoming work. Generally
since we try to avoid macros anyway, I think it doesn't hurt to put this
as its own patch.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 9 +++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 --
2 file
Thus far we've opted to make complex code requiring difficult review. In
the future, the code is only going to become more complex, and as such
we'll take the hit now and start to encapsulate things.
To help transition the code nicely there is some wasted space in gen6/7.
This will be ameliorated
The actual correct way to think about this with the new style of page
table data structures is as the actual entry that is being indexed into
the array. "pd", and "pt" aren't representative of what the operation is
doing.
The clarity here will improve the readability of future patches.
Signed-off
Upcoming patches will use the terms map and unmap in references to the
page table entries. Having this distinction will really help with code
clarity at that point.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions
Split out single mappings which will help with upcoming work. Also while
here, rename the function because it is a better description - but this
function is going away soon.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 ++---
1 file cha
There often is not enough memory to dump the full contents of the PPGTT.
As a temporary bandage, to continue getting valuable basic PPGTT info,
wrap the dangerous, memory hungry part inside of a new verbose version
of the debugfs file.
Also while here we can split out the PPGTT print function so i
As we move toward dynamic page table allocation, it becomes much easier
to manage our data structures if break do things less coarsely by
breaking up all of our actions into individual tasks. This makes the
code easier to write, read, and verify.
Aside from the dissection of the allocation functi
Move the remaining members over to the new page table structures.
This can be squashed with the previous commit if desire. The reasoning
is the same as that patch. I simply felt it is easier to review if split.
Signed-off-by: Ben Widawsky
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
trivial.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 7c06c43..2002393 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++
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
This will be useful for some upcoming patches which do more platform
specific work. Having it in one central place just makes things a bit
cleaner and easier.
NOTE: I didn't actually end up using this patch for the intended
purpose, but I thought it was a nice patch to keep around.
v2: s/i915_gem
The current code will both potentially print a WARN, and setup part of
the PPGTT structure. Neither of these harm the current code, it is
simply for clarity, and to perhaps prevent later bugs, or weird
debug messages.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 -
The old code (I'm having trouble finding the commit) had a reason for
doing things when there was an error, and would continue on, thus the
!ret. For the newer code however, this looks completely silly.
Follow the normal idiom of if (ret) return ret.
Also, put the pde wiring in the gen specific i
This patch finishes off actually separating the aliasing and global
finds. Prior to this, all global binds would be aliased. Now if aliasing
binds are required, they must be explicitly asked for. So far, we have
no users of this outside of execbuf - but Mika has already submitted a
patch requiring
The driver currently lets callers pin global, and then tries to do
things correctly inside the function. Doing so has two downsides:
1. It's not possible to exclusively pin to a global, or an aliasing
address space.
2. It's difficult to read, and understand.
The eventual goal when realized should
From: Chris Wilson
We neither report any unfinished operations during releasing GEM objects
associated with the file, and even if we did, it is bad form to report
-EINTR from a close().
The root cause of the bug that first showed itself during close is that
we do not do proper live tracking of v
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6e2145b..29dd825 100644
--- a/drivers/gpu/drm/i915/i915_gem_conte
This reverts commit 7d9c477966e739a52d4c9655149958a2671ef376.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
include/uapi/drm/i915_drm.h
---
drivers/gpu/drm/i915/i915_dma.c | 5 -
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/
Just as before, these patches are living based off of my Broadwell
branch, here:
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=gpu_mirror
This is the follow-on patches for [1]
This patch series brings 3 things:
1. Dynamic page table allocation for gen6-8
2. 64b (48b canonical) graphics v
On 2014-05-09 16:25 (GMT-0400) Brandon composed:
I have an old laptop with on board 82845G/GL[Brookdale-G]/GE Chipset Integrated
Graphics Device (rev 03) which only has 640x480 available using the
xf86-video-intel v2.99.911 driver with xorg-server 1.15.1. Â Additionally, I
cannot use an exter
On Mon, Apr 28, 2014 at 08:01:29AM -0700, arun.siluv...@linux.intel.com wrote:
> From: "Siluvery, Arun"
>
> This patch adds support to have gem objects of variable size.
> The size of the gem object obj->size is always constant and this fact
> is tightly coupled in the driver; this implementation
On 10 May 2014 03:03, Ville Syrjälä wrote:
> On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote:
>> On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote:
>> > > Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
>> > > then attach the complete dmesg? Please make
I have an old laptop with on board 82845G/GL[Brookdale-G]/GE Chipset Integrated
Graphics Device (rev 03) which only has 640x480 available using the
xf86-video-intel v2.99.911 driver with xorg-server 1.15.1. Additionally, I
cannot use an external monitor attached to the onboard VGA out which I k
Commit 81b5c7bc found that the current VGA arbiter support in i915
only works for ancient GMCH-based IGD devices and attempted to update
support for newer HD devices. Unfortunately newer devices cannot
completely opt-out of VGA arbitration like the old devices could.
The VGA I/O space cannot be di
I have a very old laptop with
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, 09 May 2014, Darren Hart wrote:
> On 5/9/14, 5:41, "Jani Nikula" wrote:
>
>>Media force wake get hangs the machine when the system is booted without
>>displays attached. The assumption is that (at least some versions of)
>>the firmware has skipped some initialization in that case.
>>
>>Em
On 5/9/14, 5:41, "Jani Nikula" wrote:
>Media force wake get hangs the machine when the system is booted without
>displays attached. The assumption is that (at least some versions of)
>the firmware has skipped some initialization in that case.
>
>Empirical evidence suggests we need to reset the me
On Fri, May 09, 2014 at 05:46:43PM +, Robert Navarro wrote:
> Ville Syrjälä linux.intel.com> writes:
>
> > I think it should apply to 3.13+. If not directly then with a bit of
> > manual frobbery. Which reminds me that we should perhaps slap a cc
> > stable on it to get it included in 3.13+.
Ville Syrjälä linux.intel.com> writes:
> I think it should apply to 3.13+. If not directly then with a bit of
> manual frobbery. Which reminds me that we should perhaps slap a cc
> stable on it to get it included in 3.13+. For older kernels the patch
> would have to look totally different, so I'm
On Fri, May 09, 2014 at 02:59:42PM +0300, Ville Syrjälä wrote:
> On Sun, Mar 23, 2014 at 02:31:05PM +0530, sourab.gu...@intel.com wrote:
> > + intel_do_mmio_flip(dev, crtc);
> > + mmio_flip_data->seqno = 0;
> > + ring->irq_put(ring);
> > +
On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote:
> On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote:
> > > Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
> > > then attach the complete dmesg? Please make sure that the dmesg
> > > contains the boot-up s
On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote:
> > Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
> > then attach the complete dmesg? Please make sure that the dmesg
> > contains the boot-up stuff too.
> >
> > Thanks, Daniel
> Here it is. I should mention it only
On Fri, May 09, 2014 at 03:23:41PM +, Robert Navarro wrote:
> Thanks for this Ville.
>
> Should this apply to 3.14 and 3.15?
>
> I'll try it on 3.15 first and report back.
I think it should apply to 3.13+. If not directly then with a bit of
manual frobbery. Which reminds me that we should pe
Thanks for this Ville.
Should this apply to 3.14 and 3.15?
I'll try it on 3.15 first and report back.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, May 06, 2014 at 02:47:40PM +0100, Chris Wilson wrote:
> Why does this work? It is neither the most minimal batch, nor the
> maximal. Which state is truly required? It looks like cargo-culted
> Chinese.
I'll have to echo this. It's really not obvious why this is needed.
If you look at the r
On Tue, May 06, 2014 at 04:39:01PM +0300, Mika Kuoppala wrote:
> diff --git a/tools/null_state_gen/intel_renderstate_gen8.c
> b/tools/null_state_gen/intel_renderstate_gen8.c
> new file mode 100644
> index 000..7e22b24
> --- /dev/null
> +++ b/tools/null_state_gen/intel_renderstate_gen8.c
[...]
On Fri, May 09, 2014 at 01:08:54PM +0100, oscar.ma...@intel.com wrote:
> + if (ring->id == RCS) {
> + reg_state[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
> + reg_state[CTX_LRI_HEADER_2] |= MI_LRI_FORCE_POSTED;
This header doesn't have bit 12 set in BSpec.
> +
Jani Nikula writes:
> Media force wake get hangs the machine when the system is booted without
> displays attached. The assumption is that (at least some versions of)
> the firmware has skipped some initialization in that case.
>
> Empirical evidence suggests we need to reset the media force wake
On Fri, May 09, 2014 at 02:59:42PM +0300, Ville Syrjälä wrote:
> On Sun, Mar 23, 2014 at 02:31:05PM +0530, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > Using MMIO based flips on VLV for Media power well residency optimization.
> > The blitter ring is currently being used just for
Hi Deepak,
deepa...@linux.intel.com writes:
> From: Deepak S
>
> v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
>
> v3: Fix PCBR condition check during CHV RC6 Enable flag set
>
> v4: Fixup PCBR comment msg. (Chris)
> Rebase against latest code (Deak)
> Fixup Spurious hunk (Ben
From: Oscar Mateo
This is missing in:
commit 78325f2d270897c9ee0887125b7abb963eb8efea
Author: Ben Widawsky
Date: Tue Apr 29 14:52:29 2014 -0700
drm/i915: Virtualize the ringbuffer signal func
Looks to me like a rebase side-effect...
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915
Media force wake get hangs the machine when the system is booted without
displays attached. The assumption is that (at least some versions of)
the firmware has skipped some initialization in that case.
Empirical evidence suggests we need to reset the media force wake
request register in addition t
Adding mailing lists.
Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
then attach the complete dmesg? Please make sure that the dmesg
contains the boot-up stuff too.
Thanks, Daniel
On Mon, May 5, 2014 at 9:51 AM, Jörg Otte wrote:
> I still have FIFO underruns in drm:
> [dr
From: Oscar Mateo
If we receive a storm of requests for the same context (see gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue function. At most, the
From: Oscar Mateo
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c797e63..9699
From: Oscar Mateo
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful (e.g. dump the
context
From: Oscar Mateo
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests and that we re-program the ring for
execution. Also, reset the hangcheck counters.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem.c | 13 +
From: Oscar Mateo
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context currently in
execution).
But we have identified an scenario in which a full preemption occurs:
1)
From: Ben Widawsky
This has turned out to be really handy in debug so far.
Update:
Since writing this patch, I've gotten similar code upstream for error
state. I've used it quite a bit in debugfs however, and I'd like to keep
it here at least until preemption is working.
Signed-off-by: Ben Wida
From: Oscar Mateo
Explain intel_lrc.c with some execlists notes
Signed-off-by: Thomas Daniel
v2: Add notes on logical ring context creation.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 67
1 file changed, 67 insertions(+)
diff
From: Oscar Mateo
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc212df..c99a872 100644
--- a/dri
From: Oscar Mateo
The write tail function is a very special place for execlists: since
all access to the ring is mediated through requests (thanks to
Chris Wilson's "Write RING_TAIL once per-request" for that) and all
requests end up with a write tail, this is the place we are going to
use to sub
From: Thomas Daniel
BSPEC says: SW must set Force Wakeup bit to prevent GT from
entering C6 while ELSP writes are in progress.
Signed-off-by: Thomas Daniel
Acked-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 15 +++
2 files changed
From: Oscar Mateo
v2: Warn and return if LRCs are not enabled.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 74 +
drivers/gpu/drm/i915/i915_reg.h | 7
drivers/gpu/drm/i915/intel_lrc.c| 6 ---
3 files changed, 81 inserti
From: Michel Thierry
Context switch (and execlist submission) should happen only when
other contexts are not active, otherwise pre-emption occurs.
To assure this, we place context switch requests in a queue and those
request are later consumed when the right context switch interrupt is
received.
From: Ben Widawsky
A context switch occurs by submitting a context descriptor to the
ExecList Submission Port. Given that we can now initialize a context,
it's possible to begin implementing the context switch by creating the
descriptor and submitting it to ELSP (actually two, since the ELSP
has
From: Thomas Daniel
We need to attend context switch interrupts from all rings. Also, fixed writing
IMR/IER and added HWSTAM at ring init time.
Notice that, if added to irq_enable_mask, the context switch interrupts would
be incorrectly masked out when the user interrupts are due to no users wai
From: Oscar Mateo
Finally, start queueing request on ring->submit. Also, remove
remaining legacy context switches.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem.c| 9 ++---
drivers/gpu/drm/i915/i915_gem_context.c| 10 ++
drivers/gpu/drm/i915/i915_gem
From: Thomas Daniel
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to schedule new contexts on interrupt when a previously
From: Oscar Mateo
This is mostly for correctness so that we know we are running the LR
context correctly (this is, the PDPs are contained inside the context
object).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drive
From: Oscar Mateo
Each logical ring context has the tail pointer in the context object,
so update it before submission.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/dr
1 - 100 of 138 matches
Mail list logo
