On Tue, Jun 10, 2014 at 06:21:35PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, May 29, 2014 at 5:57 PM, Thomas Wood wrote:
> > Introduce generic functions to register and unregister connectors. This
> > provides a common place to add and remove associated user space
> > interfaces.
> >
> > Sign
On 6/18/2014 10:32 PM, Damien Lespiau wrote:
On Wed, Jun 18, 2014 at 02:27:26PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source w
On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
wrote:
> This commit add check for return value of init_ring_common() in the
> init_render_ring(). Now, when failure is detected the error code is
> propagated to the caller layer instead of being ignored.
>
> I believe that this fix will have a
From: Sagar Kamble
Signed-off-by: Sagar Kamble
Cc: Daniel Vetter
Cc: "Ville Syrjälä"
Cc: linux-...@vger.kernel.org (open list:DOCUMENTATION)
Cc: linux-ker...@vger.kernel.org (open list)
---
Documentation/DocBook/drm.tmpl | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
dif
On Thu, Jun 19, 2014 at 12:13 AM, Volkin, Bradley D
wrote:
>> +void intel_lr_context_free(struct intel_context *ctx)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < I915_NUM_RINGS; i++) {
>> + struct drm_i915_gem_object *ctx_obj = ctx->engine[i].obj;
>> + if (ctx_obj) {
On Thu, Jun 19, 2014 at 3:47 AM, Alex Williamson
wrote:
> Finding some more specs... the MGGC0 register (50h) seems to indicate
> the GTT stolen memory size is 2M, which sounds suspiciously like the 2M
> that the RMRR is reporting. However, from the IvyBridge MMIO, Media
> Registers & Programming
On Wed, 2014-06-18 at 15:48 -0600, Alex Williamson wrote:
> On Tue, 2014-06-17 at 15:44 +0200, Daniel Vetter wrote:
> > On Tue, Jun 17, 2014 at 07:16:22AM -0600, Alex Williamson wrote:
> > > On Tue, 2014-06-17 at 13:41 +0100, David Woodhouse wrote:
> > > > On Tue, 2014-06-17 at 06:22 -0600, Alex Wi
On Fri, Jun 13, 2014 at 08:37:37AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> I plan to reuse these for the new logical ring path.
>
> No functional changes.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 31 ++-
>
On Fri, Jun 13, 2014 at 08:37:33AM -0700, oscar.ma...@intel.com wrote:
> 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).
>
> v2: Move the check to inside the enable PPGTT
On Fri, Jun 13, 2014 at 08:37:30AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> For the most part, logical ring context objects are similar to hardware
> contexts in that the backing object is meant to be opaque. There are
> some exceptions where we need to poke certain offsets of
On Fri, Jun 13, 2014 at 08:37:29AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> As we have said a couple of times by now, logical ring contexts have
> their own ringbuffers: not only the backing pages, but the whole
> management struct.
>
> In a previous version of the series, thi
On Fri, Jun 13, 2014 at 08:37:28AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> There are a few big differences between context init and fini with the
> previous implementation of hardware contexts. One of them is
> demonstrated in this patch: we must allocate a ctx backing object
On Tue, 2014-06-17 at 15:44 +0200, Daniel Vetter wrote:
> On Tue, Jun 17, 2014 at 07:16:22AM -0600, Alex Williamson wrote:
> > On Tue, 2014-06-17 at 13:41 +0100, David Woodhouse wrote:
> > > On Tue, 2014-06-17 at 06:22 -0600, Alex Williamson wrote:
> > > > On Tue, 2014-06-17 at 08:04 +0100, David W
On Fri, Jun 13, 2014 at 08:37:22AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> We are going to start creating a lot of extra ringbuffers soon, so
> these functions are handy.
>
> No functional changes.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_ringbuffe
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj->pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects
On Fri, Jun 13, 2014 at 04:37:18PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> For a description of this patchset, please check the previous cover letters:
> [1] and [2].
>
> The main difference with v2 is in how we get to the point of context
> submission: this time
> around,
On Tue, Jun 17, 2014 at 11:35:40PM +0200, Daniel Vetter wrote:
> On Tue, Jun 17, 2014 at 10:11:45PM +0100, Chris Wilson wrote:
> > On Tue, Jun 17, 2014 at 09:03:00PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Take the minimum of the object size and the
On Fri, Jun 13, 2014 at 04:38:11PM +0100, oscar.ma...@intel.com wrote:
> From: Sourab Gupta
>
> If we want flips to work, either we create an Execlists-aware version
> of intel_gen7_queue_flip, or we don't place commands directly in the
> ringbuffer.
>
> When upstreamed, this patch should implem
On Fri, Jun 13, 2014 at 04:38:04PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> v2: Warn and return if LRCs are not enabled.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 72
> +
> drivers/gpu/drm/i915/intel_lrc
On Fri, Jun 13, 2014 at 04:38:03PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Or with a spinlock grabbed, because it might sleep, which is not
> a nice thing to do. Instead, do the runtime_pm get/put together
> with the create/destroy request, and handle the forcewake get/put
> d
On Wed, Jun 18, 2014 at 10:52:08PM +0200, Daniel Vetter wrote:
> On Fri, Jun 13, 2014 at 04:38:01PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > Since the ringbuffer does not belong per engine anymore, we have to
> > make sure that we are always recording the correct ringbuff
On Fri, Jun 13, 2014 at 04:38:01PM +0100, oscar.ma...@intel.com wrote:
> 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 worki
On Fri, Jun 13, 2014 at 04:38:00PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> If we reset a ring after a hang, we have to make sure that we clear
> out all queued Execlists requests.
>
> v2: The ring is, at this point, already being correctly re-programmed
> for Execlists, and t
On Fri, Jun 13, 2014 at 04:37:59PM +0100, oscar.ma...@intel.com wrote:
> 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
> ex
On Fri, Jun 13, 2014 at 04:37:54PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> As suggested by Daniel.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_drv.h| 26
> drivers/gpu/drm/i915/i915_gem.c| 48
> +
On Fri, Jun 13, 2014 at 04:37:37PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> I plan to reuse these for the new logical ring path.
>
> No functional changes.
>
> Signed-off-by: Oscar Mateo
I don't see the new user of this yet, but imo copy-pasting this around
wouldn't be too
On Fri, Jun 13, 2014 at 04:37:31PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> The backing objects for contexts created via open fd are actually
> empty until the user starts sending execbuffers to them. We do this
> because, at create time, we really don't know which engine is go
On Fri, Jun 13, 2014 at 04:37:27PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Early in the series we had our own gen8_gem_context_init/fini
> functions, but the truth is they now look almost the same as the
> legacy hw context init/fini functions. We can always split them
> later
On Fri, Jun 13, 2014 at 04:37:26PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
> These expanded contexts enable a number of new abilities, especially
> "Execlists".
>
> The macro is defined to off until we have
On Fri, Jun 13, 2014 at 04:37:25PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Some legacy HW context code assumptions don't make sense for this new
> submission method, so we will place this stuff in a separate file.
>
> Note for reviewers: I've carefully considered the best nam
On Fri, Jun 13, 2014 at 04:37:24PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> A context backing object only makes sense for a given engine (because
> it holds state data specific to that engine).
>
> In legacy ringbuffer sumission mode, the only MI_SET_CONTEXT we really
> perfor
On Wed, Jun 18, 2014 at 12:52 PM, Thomas Wood wrote:
> Add a file to debugfs for each connector to enable modification of the
> "force" connector attribute. This allows connectors to be enabled or
> disabled for testing and debugging purposes.
>
> v2: Add stricter value checking and clean up debug
On Wed, Jun 18, 2014 at 03:37:30PM -0400, Alex Deucher wrote:
> On Wed, Jun 18, 2014 at 12:52 PM, Thomas Wood wrote:
> > +static ssize_t edid_write(struct file *file, const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + struct seq_file *m = file->priv
On Wed, Jun 18, 2014 at 08:58:34PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Proveide a ring notify mechanism where you can ask for a callback when a
> specific seqno has been passed.
>
> Can be used for FBC and mmio flips at least.
>
> Signed-off-by: Ville Syrjälä
On Wed, Jun 18, 2014 at 08:58:33PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> This series rewrites the FBC code to actually work. It utilizes the
> hardware tracking/nuking as much as possible, eg. relying on hardware
> nuke on flip when possible.
>
> I also introduce
[snip]
On Mon, Jun 16, 2014 at 08:18:00AM -0700, Mateo Lozano, Oscar wrote:
> > > +struct intel_context *
> > > +i915_gem_context_validate(struct drm_device *dev, struct drm_file *file,
> > > + struct intel_engine_cs *ring, const u32 ctx_id) {
> > > + struct intel_context *ctx =
On Wed, Jun 18, 2014 at 07:11:46PM +0100, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 10:49:05AM -0700, Volkin, Bradley D wrote:
> > What specifically are you thinking in terms of implementing busy tracking
> > in the pool? The idea with adding the shadow object to the request was just
> > to get
On Wed, Jun 18, 2014 at 08:58:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a vblank notify mechanism where you can ask for a callback when a
> specific frame counter value has been passed.
>
> This could be used for various things like FBC, IPS, watermarks,
> an
On Wed, Jun 18, 2014 at 05:15:35PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> As a first step, split switch_mm into two different functions:
> sync_switch_mm (currently used by ppgtt_enable) and switch_mm
> (used by the outside world).
>
> Signed-off-by: Oscar Mateo
I guess th
On Wed, Jun 18, 2014 at 05:34:49PM +0100, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 05:16:03PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > The original comment that introduced it said:
> >
> > commit 0009e46cd54324c4af20b0b52b89973b1b914167
> > Author: Ben Widawsky
> >
On Wed, Jun 18, 2014 at 12:52 PM, Thomas Wood wrote:
> Add a file to debugfs for each connector to allow the EDID to be
> overridden.
>
> v2: Copy ubuf before accessing it and reject invalid length data. (David
> Herrmann)
> Ensure override_edid is reset when a new EDID value is written.
>
From: Ville Syrjälä
Add a subtest to make sure the kernel doesn't leak the vma
pin_count for the last context on reset.
Signed-off-by: Ville Syrjälä
---
tests/gem_ctx_exec.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/tests/gem_ctx_exec.c
From: Ville Syrjälä
We're forgetting to unpin the last_context from the ggtt at GPU reset
time. This leads to the vma pin_count leaking at every reset if the
last context wasn't the ring default context. Further use of the same
context will trigger the pin_count check in i915_gem_object_pin() and
On Wed, Jun 18, 2014 at 10:49:05AM -0700, Volkin, Bradley D wrote:
> On Wed, Jun 18, 2014 at 09:52:52AM -0700, Chris Wilson wrote:
> > On Wed, Jun 18, 2014 at 09:36:14AM -0700, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > >
> > > This patch sets up all of the tracking and copying
From: Ville Syrjälä
Proveide a ring notify mechanism where you can ask for a callback when a
specific seqno has been passed.
Can be used for FBC and mmio flips at least.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem.c | 10
drivers/gpu/drm/i915/i915_irq.c
From: Ville Syrjälä
The FBC RT address is saved as part of the context, so track it
the same way in the driver to skip pointless LRIs. Also try
make sure we re-emit the render/blitter tracking stuff on driver
load and gpu reset.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h
From: Ville Syrjälä
Redesign the fbc code to deal with multiple pipes better, fix the
locking problems, and in general try to utilize the hardware front
buffer tracking features to their full extent.
For each crtc we will compute a pending fbc score as (pixel_rate * cpp).
At appropriate times (a
From: Ville Syrjälä
FBC host modification tracking only works through GTT mmaps, so any
direct CPU access needs to manually nuke the compressed framebuffer
on modifications. Do the nuking from the SW_FINISH ioctl.
v2: nuke from SW_FINISH insted of DIRTYFB ioctl
v3: Call intel_fbc_nuke() only whe
From: Ville Syrjälä
The FBC RT address is stored in the context, and thus needs to be
rewritten after a context switch before any batches are run. We emit
the LRI to update the FBC RT address when we call the ring ->flush
function to invalidate the caches.
When a context switch is being performe
From: Ville Syrjälä
Add a debugfs file which shows the fbc state in all its glory.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 44 +
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/
From: Ville Syrjälä
Flush the caches when moving a scanout buffer from CPU to GTT domain.
This allows us to move a scanout buffer to CPU write domain, do some
writes, and move it back to the GTT read domain. The display will then
see the correct data. In addition we still need to do the dirtyfb
i
From: Ville Syrjälä
Things should work just fine now for FBC2 platforms. However on g4x we
don't have any code to set up the FBC watermarks so I'm hesitant to
enable it there by default. FBC1 platforms could use more testing, and
also my 855 seems to experience some GPU+system hangs occasionally
From: Ville Syrjälä
ILK should work pretty much the same as SNB, except it
doesn't have the blitter, so we only care about render tracking.
v2: Rebased against earlier changes
v3: Rebased due to fbc.obj changes
Acked-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915
From: Ville Syrjälä
The hardware state might not match the software state here, so just
call the low level fbc disable hook to disable it in case the BIOS
left it enabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_suspend.c | 5 +++--
drivers/gpu/drm/i915/intel_display.c | 3
From: Ville Syrjälä
Only print the FBC enabled debug message when FBC wasn't already
enabled. Now we call the .enable_fbc() function every time we need to
update the CPU fence during page flips, so dmesg gets considerable
amounts of pointless spam.
Also unify the format of the message across all
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need
From: Ville Syrjälä
WaFbcOnlyForNativeModeOnLFP:ctg says we need to disable fbc when panel
fitting is enabled on g4x.
On ilk we need to disable fbc if panel fitter is downscaling. Upscaling
is apparently OK.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 26 +++
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 10 +--
drivers/gpu/drm/i915/intel_display.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 130 +++
drivers/gpu/drm/i915/
From: Ville Syrjälä
We don't do double scan anyway so don't bother checking it in the fbc
code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm
From: Ville Syrjälä
WaFbcDisabledForOverlaySprite:ctg says we need to disallow fbc when
sprites are enabled.
We don't currently expose the sprites on g4x, but maybe we will later.
Add the appropriate check to fbc2_possible(). We will also need to
adjust the sprite code to turn off fbc prior to e
From: Ville Syrjälä
fbc function prototypes are spread around in to headers. Collect them to
a single place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/g
From: Ville Syrjälä
fbc is only possible with certain pixel formats. Check for those before
enabling fbc.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_p
From: Ville Syrjälä
The locking needs to be adjusted to accomodate the upcoming fbc.mutex,
so shuffle around the prep steps before actally issuing the flip.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 47 ++--
1 file changed, 24 inser
From: Ville Syrjälä
If the scanout object exceeds the size of the stolen memory, there's no
way we can ever enable fbc with it. Just say no.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/
From: Ville Syrjälä
FBC1 and FBC2 behave a bit differently when it comes to multiple pipes.
FBC1 supposedly must be disabled when multiple pipes are enabled, but FBC2
can be enabled. To make this more easier to read simply split the code
along the FBC1 vs. FBC2 lines.
On FBC2 we get to pick one
From: Ville Syrjälä
Kill the magic numbers from the IPS code and give a name to the
IPS pcode control bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/dr
From: Ville Syrjälä
Add a vblank notify mechanism where you can ask for a callback when a
specific frame counter value has been passed.
This could be used for various things like FBC, IPS, watermarks,
and updating single buffered display registers from the interrupt
handler (eg. gamma).
As gen2
From: Ville Syrjälä
Just shuffle code around, no functional change.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 62 -
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm
From: Ville Syrjälä
IPS enable must be delayed one frame after the planes have been enabled.
Currently there's a blocking vblank wait in the path. Replace that with
a vblank notify so that it can be done asynchronously. The disable path
must remain synchronous.
TODO: see if the ips state checkin
From: Ville Syrjälä
This series rewrites the FBC code to actually work. It utilizes the
hardware tracking/nuking as much as possible, eg. relying on hardware
nuke on flip when possible.
I also introduce the generic ring and vblank notifier gizmos which could
be used for various other things. I a
On Wed, Jun 18, 2014 at 09:52:52AM -0700, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 09:36:14AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > This patch sets up all of the tracking and copying necessary to
> > use batch pools with the command parser, but does not actua
On Wed, Jun 18, 2014 at 02:27:26PM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> Primary planes support 180 degree rotation. Expose the feature
> through rotation drm property.
>
> v2: Calculating linear/tiled offsets based on pipe source width and
> height. Added 180 degree ro
We don't need to uninstall the full handler, simply disabling interrupts
ought to be enough.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 5 ++---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i9
We should be taking the right power well refs these days, so this
shouldn't be necessary. It also gets in the way of re-using these
routines for S0iX states, as those need all the power saving features
enabled.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
1 file chan
Add a file to debugfs for each connector to allow the EDID to be
overridden.
v2: Copy ubuf before accessing it and reject invalid length data. (David
Herrmann)
Ensure override_edid is reset when a new EDID value is written.
(David Herrmann)
Fix the debugfs file permissions. (David
Add a file to debugfs for each connector to enable modification of the
"force" connector attribute. This allows connectors to be enabled or
disabled for testing and debugging purposes.
v2: Add stricter value checking and clean up debugfs_entry if file
creation fails in drm_debugfs_connector_ad
The following patches update the last two patches in the original series with
the suggested changes from David Herrmann.
Thomas Wood (2):
drm/debugfs: add a "force" file per connector
drm/debugfs: add an "edid_override" file per connector
drivers/gpu/drm/drm_crtc.c | 21 -
drive
On Wed, Jun 18, 2014 at 09:36:14AM -0700, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> This patch sets up all of the tracking and copying necessary to
> use batch pools with the command parser, but does not actually
> dispatch the copied (shadow) batch to the hardware yet. We still
>
From: Brad Volkin
This is useful for testing the batch pool code with aliasing PPGTT.
It doesn't work with full PPGTT though; the GPU hangs and the whole
UI is corrupted. We need fixes for the secure dispatch path to
enable this for real.
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i91
From: Brad Volkin
This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser, but does not actually
dispatch the copied (shadow) batch to the hardware yet. We still
aren't quite ready to set the secure bit during dispatch.
Note that performance takes
From: Brad Volkin
This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple, but separating
it out makes it easier to change the underlying algorithms and to
extend to future u
From: Brad Volkin
It provides some useful information about the buffers in
the per-ring command parser batch pools.
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_debugfs.c | 48 +
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915
From: Brad Volkin
This series is what I have so far on the batch copy aspect of the
command parser. The individual patches and kerneldoc have details.
It doesn't work with full ppgtt at the moment, so isn't ready for
merge. But I'd like to get feedback on the direction and particularly
whether I'
On Wed, Jun 18, 2014 at 05:16:03PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> The original comment that introduced it said:
>
> commit 0009e46cd54324c4af20b0b52b89973b1b914167
> Author: Ben Widawsky
> Date: Fri Dec 6 14:11:02 2013 -0800
>
> drm/i915: Track which ring a c
No, dear reader, you are not missing patches: this series should be 1/4, 2/4,
3/4 and 4/4, but git went rogue on me :(
I can resend the series if that helps...
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of oscar.ma...@intel.com
> S
From: Daniele Ceraolo Spurio
These tracepoints are useful for observing the creation and
destruction of Full PPGTTs.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_context.c | 5 +
drivers/gpu/drm/i915/i915_trace.h | 38 +
2 files change
From: Daniele Ceraolo Spurio
These callbacks can be assigned to specific functions inside an external
validation kernel module. This module can then extract run-time information
to make sure everything is working as expected.
Specifically, these two callbacks extract information about ifull PPGG
From: Daniele Ceraolo Spurio
The context used top execute a batchbuffer is becoming increasingly
important.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
d
From: Oscar Mateo
The original comment that introduced it said:
commit 0009e46cd54324c4af20b0b52b89973b1b914167
Author: Ben Widawsky
Date: Fri Dec 6 14:11:02 2013 -0800
drm/i915: Track which ring a context ran on
Previously we dropped the association of a context to a ring. It is
From: Oscar Mateo
PPGTT enabling is per-ring on GEN7+, so it makes sense that the enable
functions takes a ring argument. GEN6 can live with multiple calls to
the enable function.
And, more importantly, this allows us to enable the PPGTT from the ring
init code (the place where all the initializ
From: Oscar Mateo
At this point, I could simply kill the sync_switch_mm function pointer
off and just transform it into some static functions belonging to
i915_gem_gtt.c
But I have a problem with Execlists: enabling the PPGTT is still needed,
but switching to it the old way (writing to the PDP r
From: Oscar Mateo
If this comment is true for GEN6 and GEN7, I imagine it is for GEN8 as well:
If we're in reset, we can assume the GPU is sufficiently idle to
manually frob these bits. Ideally we could use the ring functions,
except our error handling makes it quite difficult (can't
From: Oscar Mateo
As a first step, split switch_mm into two different functions:
sync_switch_mm (currently used by ppgtt_enable) and switch_mm
(used by the outside world).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c |
From: Bob Beckett
Create a scratch page for the two unused PDPs and set all the PTEs
for them to point to it.
This patch addresses a page fault, and subsequent hang in pipe
control flush. In these cases, the Main Graphic Arbiter Error
register [0x40A0] showed a TLB Page Fault error, and a high m
On Wed, Jun 18, 2014 at 05:57:39PM +0200, Daniel Vetter wrote:
> On Wed, Jun 18, 2014 at 03:57:49PM +0100, Chris Wilson wrote:
> > On Wed, Jun 18, 2014 at 03:05:19PM +0200, Daniel Vetter wrote:
> > > X could end up putting the fbcon fb into other domains, e.g.
> > > for smooth take-overs. Also we w
On Wed, Jun 18, 2014 at 06:05:02PM +0200, Daniel Vetter wrote:
> On Wed, Jun 18, 2014 at 04:58:54PM +0100, Chris Wilson wrote:
> > On Wed, Jun 18, 2014 at 05:55:31PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 18, 2014 at 03:55:44PM +0100, Chris Wilson wrote:
> > > > On Wed, Jun 18, 2014 at 03:01
On Wed, Jun 18, 2014 at 04:58:54PM +0100, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 05:55:31PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 18, 2014 at 03:55:44PM +0100, Chris Wilson wrote:
> > > On Wed, Jun 18, 2014 at 03:01:25PM +0200, Daniel Vetter wrote:
> > > > +void i915_gem_update_fb_bits
Hi Ville,
thanks again for your alm_fixes5 branch. Just installed it on the old
R31 - this seems to work fine. The external monitor works
(unlike with intel_drm_nightly, which is broken), and watermarks are
also setup correctly. Booting works correctly, boot console
is setup correctly.
Suspen
On Wed, Jun 18, 2014 at 03:51:01PM +0100, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 01:59:17PM +0200, Daniel Vetter wrote:
> > Add busy_frontbuffer_bits and locking.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
> > 1 file changed, 6 inserti
On Wed, Jun 18, 2014 at 03:50:20PM +0100, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 02:46:49PM +0200, Daniel Vetter wrote:
> > Can be useful to figure out imbalances and bugs in the frontbuffer
> > tracking.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Chris Wilson
>
> I don't thi
1 - 100 of 211 matches
Mail list logo
