The idea of printing objects used by each process is to judge how each
process is using them. This means that we need to evaluate whether the
object is bound for that particular process, rather than just whether it
is bound into the global GTT.
Signed-off-by: Chris Wilson
Cc: Ben Widawsky
---
d
On Mon, Jan 20, 2014 at 9:55 PM, Jesse Barnes wrote:
> Can be expanded up on to include all sorts of things (HDMI infoframe
> data, more DP status, etc). Should be useful for bug reports to get a
> baseline on the display config and info.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/
On Thu, Jan 30, 2014 at 2:20 PM, Josh Boyer wrote:
> On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo wrote:
>> On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
>>> Hi All,
>>>
>>> I'm seeing the oops below on my MacBookPro 10,2 machine using i915
>>> graphics. It's after the DRM merge for
Re-adding intel-gfx, this seems generally useful.
On Thu, Jan 30, 2014 at 6:22 PM, Volkin, Bradley D
wrote:
> Ok. There's still a couple ways I could see doing it.
> - one big patch with all the new #defines, up front
> - split the #defines from their current patches, all up front
> - split the #
On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo wrote:
> On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
>> Hi All,
>>
>> I'm seeing the oops below on my MacBookPro 10,2 machine using i915
>> graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
>> but we seem to have one r
On Thu, Jan 30, 2014 at 11:00:35AM -0800, Ben Widawsky wrote:
> RC6 works a lot like HW contexts in that when the GPU enters RC6 it
> saves away the state to a context, and loads it upon wake.
>
> It's to be somewhat expected that BIOS will not set up valid GPU state.
> As a result, if loading bad
Hi All,
I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
but we seem to have one report[1] of this happening well before that,
in v3.13-3260-g03d11a0 as well. Does anyone have a clue what is going
on here?
h
RC6 works a lot like HW contexts in that when the GPU enters RC6 it
saves away the state to a context, and loads it upon wake.
It's to be somewhat expected that BIOS will not set up valid GPU state.
As a result, if loading bad state can cause the GPU to get angry, it
would make sense then that we
On Thu, Jan 30, 2014 at 03:07:15AM -0800, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 10:12:06AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
> > > > On Wed, Jan 29, 2014 at 10:
On Thu, Jan 30, 2014 at 01:12:06AM -0800, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
> > > > On Wed, Jan 29, 2014 at 01:5
From: Deepak S
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2: remove vlv_update_rps
On Thu, Jan 30, 2014 at 01:20:57AM -0800, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 02:26:12PM -0800, Volkin, Bradley D wrote:
> > On Wed, Jan 29, 2014 at 02:13:21PM -0800, Chris Wilson wrote:
> > > On Wed, Jan 29, 2014 at 01:57:28PM -0800, bradley.d.vol...@intel.com
> > > wrote:
> > > > From
On Thu, Jan 30, 2014 at 01:19:15AM -0800, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 01:55:13PM -0800, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > So userspace can query the kernel for command parser support.
> >
> > OTC-Tracker: AXIA-4631
> > Change-Id: I58af650db9f6753c
On Thu, Jan 30, 2014 at 05:58:38PM +0100, Daniel Vetter wrote:
> This regression has been introduced in
>
> commit b3f2333de8e81b089262b26d52272911523e605f
> Author: Daniel Vetter
> Date: Wed Dec 11 11:34:31 2013 +0100
>
> drm: restrict the device list for shadow attached drivers
>
Hi
On Thu, Jan 30, 2014 at 5:58 PM, Daniel Vetter wrote:
> This regression has been introduced in
>
> commit b3f2333de8e81b089262b26d52272911523e605f
> Author: Daniel Vetter
> Date: Wed Dec 11 11:34:31 2013 +0100
>
> drm: restrict the device list for shadow attached drivers
>
> Reported-by
As we seek the guilty batch using request and hangcheck
score, this code is not needed anymore.
v2: Rebase. Passing dev_priv instead of getting it from last_ring
Signed-off-by: Mika Kuoppala
Reviewed-by: Ben Widawsky (v1)
---
drivers/gpu/drm/i915/i915_gem.c | 97 +++--
With full ppgtt using acthd is not enough to find guilty
batch buffer. We get multiple false positives as acthd is
per vm.
Instead of scanning which vm was running on a ring,
to find corressponding context, use a different, simpler,
strategy of finding batches that caused gpu hang:
If hangcheck h
On Thu, Jan 30, 2014 at 09:54:41PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When we enter RC6 and GFX Clocks are off, the voltage remains higher
> than Vmin. When we try to set the freq to RPn, it might fail since the
> Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX c
On Thu, Jan 30, 2014 at 11:02 AM, Chris Wilson wrote:
> On Wed, Jan 29, 2014 at 01:50:06PM -0200, Rodrigo Vivi wrote:
>> @@ -7501,6 +7501,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
>> *crtc,
>> u32 base = 0, pos = 0;
>> bool visible;
>>
>> + if (IS_VALLEYVIEW(dev))
This regression has been introduced in
commit b3f2333de8e81b089262b26d52272911523e605f
Author: Daniel Vetter
Date: Wed Dec 11 11:34:31 2013 +0100
drm: restrict the device list for shadow attached drivers
Reported-by: Dave Jones
Cc: Dave Jones
Cc: Dave Airlie
Cc: David Herrmann
Signed-
On Thu, 2014-01-30 at 18:22 +0200, Jani Nikula wrote:
> On Thu, 30 Jan 2014, Daniel Vetter wrote:
> > On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
> >> Atm we setup the HW panel power sequencer logic both for eDP and DP
> >> ports. On eDP we then go on and start the power on sequence
On Thu, 30 Jan 2014, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
>> Atm we setup the HW panel power sequencer logic both for eDP and DP
>> ports. On eDP we then go on and start the power on sequence and commence
>> with link training when it's ready. On DP we
From: Deepak S
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPn, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPn then move GFx down.
v2: remove vlv_update_rps
On Thu, Jan 30, 2014 at 05:32:10PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 30, 2014 at 03:11:08PM +, Chris Wilson wrote:
> > On Thu, Jan 30, 2014 at 05:08:09PM +0200, Ville Syrjälä wrote:
> > > On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
> > > > We want to use the GTT for re
On Thu, 2014-01-30 at 16:52 +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
> > Atm we setup the HW panel power sequencer logic both for eDP and DP
> > ports. On eDP we then go on and start the power on sequence and commence
> > with link training when it's
On Thu, Jan 30, 2014 at 04:52:24PM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
> > Atm we setup the HW panel power sequencer logic both for eDP and DP
> > ports. On eDP we then go on and start the power on sequence and commence
> > with link training whe
On Thu, Jan 30, 2014 at 04:50:42PM +0200, Imre Deak wrote:
> Atm we setup the HW panel power sequencer logic both for eDP and DP
> ports. On eDP we then go on and start the power on sequence and commence
> with link training when it's ready. On DP we don't do the power on
> sequencing but do the li
On Thu, 30 Jan 2014, Daniel Vetter wrote:
> Ok, I seem to have been truly blind all the time. This seems to have been
> fallout from
>
> commit b6c5164d7bf624f3e1b750787ddb983150c5117c
> Author: Daniel Vetter
> Date: Fri Apr 12 18:48:43 2013 +0200
>
> drm/i915: Fixup Oops in the pipe conf
On Thu, Jan 30, 2014 at 04:01:15PM +0200, Mika Kuoppala wrote:
> With full ppgtt support drm_i915_file_private gained knowledge
> about the default context. Also reset stats are now inside
> i915_hw_context so we can use proper abstraction.
>
> v2: Move BUG_ON and WARN_ON to more proper locations
On Thu, Jan 30, 2014 at 03:11:08PM +, Chris Wilson wrote:
> On Thu, Jan 30, 2014 at 05:08:09PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
> > > We want to use the GTT for reading back objects upon an error so that we
> > > have exactly the info
On Thu, Jan 30, 2014 at 09:53:54AM -0500, Alan Stern wrote:
> On Tue, 28 Jan 2014, Daniel Vetter wrote:
>
> > I think I need a bit more debug output first. Can you please apply the
> > below patch to drm-intel-nightly and then grab a drm.debug=0xe dmesg from
> > boot?
>
> The dmesg output is belo
On Thu, Jan 30, 2014 at 05:08:09PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
> > We want to use the GTT for reading back objects upon an error so that we
> > have exactly the information that the GPU saw. However, it is verboten
> > to access snoopa
On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
> We want to use the GTT for reading back objects upon an error so that we
> have exactly the information that the GPU saw. However, it is verboten
> to access snoopable pages through the GTT and causes my PineView GPU to
> throw a page
On Thu, Jan 30, 2014 at 4:05 PM, Jani Nikula wrote:
> On Thu, 30 Jan 2014, Daniel Vetter wrote:
>> On Thu, Jan 30, 2014 at 11:37:00AM +0200, Jani Nikula wrote:
>>> Fix and cleanup the rather confused native aux read return values and
>>> return value checks. Maybe we'll get them right from now on
On Thu, 30 Jan 2014, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 11:37:00AM +0200, Jani Nikula wrote:
>> Fix and cleanup the rather confused native aux read return values and
>> return value checks. Maybe we'll get them right from now on. Just maybe.
>>
>> Did not have a chance to test this, I
On Thu, Jan 30, 2014 at 04:53:32PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 29, 2014 at 11:55:31AM -0800, Ben Widawsky wrote:
> > + obj = error->semaphore_obj;
> > + if (obj) {
>
> Chris will come along and change this to
>
> if ((obj = error->semaphore_obj))
I was merely keeping in style w
On Wed, Jan 29, 2014 at 11:55:31AM -0800, Ben Widawsky wrote:
> Since the semaphore information is in an object, just dump it, and let
> the user parse it later.
>
> NOTE: The page being used for the semaphores are incoherent with the
> CPU. No matter what I do, I cannot figure out a way to read a
Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready. On DP we don't do the power on
sequencing but do the link training immediately. At this point the DP
PHY block gets stuck,
On Thu, Jan 30, 2014 at 02:38:16PM +, Chris Wilson wrote:
> We want to use the GTT for reading back objects upon an error so that we
> have exactly the information that the GPU saw. However, it is verboten
> to access snoopable pages through the GTT and causes my PineView GPU to
> throw a page
Repeating the same information multiple times is just annoying.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
in
We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page fault instead.
This has not been a problem in the past as we only dum
If we have stopped rings then we know that test is running
so no need for spam. In addition, only spam when default
context gets banned.
v2: - make sure default context ban gets shown (Chris)
- use helper for checking for default context, everywhere (Chris)
v3: - dont be quiet when debug is s
If we have stopped rings then we know that test is running
so no need for spam. In addition, only spam when default
context gets banned.
v2: - make sure default context ban gets shown (Chris)
- use helper for checking for default context, everywhere (Chris)
v3: - dont be quiet when debug is s
With full ppgtt support drm_i915_file_private gained knowledge
about the default context. Also reset stats are now inside
i915_hw_context so we can use proper abstraction.
v2: Move BUG_ON and WARN_ON to more proper locations (Ben)
Suggested-by: Ben Widawsky
Signed-off-by: Mika Kuoppala
Reviewed
On Thu, 30 Jan 2014, Daniel Vetter wrote:
> How does this fit in with Thierry's dp aux helper improvements? I prefer
> if we start to converge on that sooner than later ...
Patch 1/4 actually fixes a potential bug in intel_dp_sink_crc(), which
now detects failure only if the read returns 0, but p
On Thu, Jan 30, 2014 at 02:18:32PM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson
> wrote:
> > Oh. So they changed how post-sync writes operated - this should be a
> > separate fix for stable I believe (so that batches are not run before we
> > have finished invalidat
On Thu, Jan 30, 2014 at 02:18:32PM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson
> wrote:
> > Oh. So they changed how post-sync writes operated - this should be a
> > separate fix for stable I believe (so that batches are not run before we
> > have finished invalidat
On Wed, Jan 29, 2014 at 11:55:29AM -0800, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 3cfcc7
On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson wrote:
> Oh. So they changed how post-sync writes operated - this should be a
> separate fix for stable I believe (so that batches are not run before we
> have finished invalidating the TLBs required).
We have an igt to exercise tlb invalidation stuff
On Wed, Jan 29, 2014 at 01:50:06PM -0200, Rodrigo Vivi wrote:
> @@ -7501,6 +7501,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
> *crtc,
> u32 base = 0, pos = 0;
> bool visible;
>
> + if (IS_VALLEYVIEW(dev))
> + intel_edp_psr_inactivate(dev);
> +
Inactivat
On Wed, Jan 29, 2014 at 01:44:34PM -0800, Ben Widawsky wrote:
> Last word: As I've discussed with Chris too, I am overall a bit wary of
> removing any use upon hardware for doing a lot of these error triage,
> detection and collection functions. I really like that no matter how
> bonghits our drive
On Wed, Jan 29, 2014 at 11:55:27AM -0800, Ben Widawsky wrote:
> Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
> wait on is all well defined by the table in the previous patch. There is
> nothing else different from previous GEN's semaphore synchronization
> code.
>
> v2: U
On Thu, Jan 30, 2014 at 02:38:17PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 29, 2014 at 11:55:26AM -0800, Ben Widawsky wrote:
> > Semaphore signalling works similarly to previous GENs with the exception
> > that the per ring mailboxes no longer exist. Instead you must define
> > your own space, so
On Thu, Jan 30, 2014 at 01:10:07PM +0100, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 06:23:40PM -0800, Matt Turner wrote:
> > On Wed, Jan 29, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > On Tue, Jan 28, 2014 at 6:29 AM, Chia-I Wu wrote:
> > >> From: Chia-I Wu
> > >>
> > >> The optimization is
On Wed, Jan 29, 2014 at 11:55:26AM -0800, Ben Widawsky wrote:
> Semaphore signalling works similarly to previous GENs with the exception
> that the per ring mailboxes no longer exist. Instead you must define
> your own space, somewhere in the GTT.
>
> The comments in the code define the layout I'v
On Wed, Jan 29, 2014 at 06:23:40PM -0800, Matt Turner wrote:
> On Wed, Jan 29, 2014 at 9:56 AM, Daniel Vetter wrote:
> > On Tue, Jan 28, 2014 at 6:29 AM, Chia-I Wu wrote:
> >> From: Chia-I Wu
> >>
> >> The optimization is available on Ivy Bridge and later, and is disabled by
> >> default. Enabl
Just code shuffling to have intel_dp_aux_native_read_retry() next to its
sibling intel_dp_aux_native_read(). No functional changes.
v2: rebase.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 48 +++
1 file changed, 24 insertions(+), 24 del
In most cases we only care about success or fail, so make the function
easier to use, and consistent with intel_dp_aux_native_read_retry().
This fixes the intel_dp_aux_native_read() usage in intel_dp_sink_crc()
which has already assumed bool, and would only have caught very specific
failure modes.
On Wed, Jan 29, 2014 at 10:10:47PM +, Chris Wilson wrote:
> On Wed, Jan 29, 2014 at 01:58:29PM -0800, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > Signed-off-by: Brad Volkin
> > ---
> > tests/gem_exec_parse.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > dif
On Thu, Jan 30, 2014 at 12:26:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 12:19:40AM -0800, Ben Widawsky wrote:
> > v2: Rebased upon cleaned up error state
> > v3: Make sure hangcheck info remains last (Chris)
> >
> > Cc: Chris Wilson
> > Signed-off-by: Ben Widawsky
>
> Pulled in
On Thu, Jan 30, 2014 at 12:19:40AM -0800, Ben Widawsky wrote:
> v2: Rebased upon cleaned up error state
> v3: Make sure hangcheck info remains last (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Ben Widawsky
Pulled in entire series with Chris' irc ack on the remaining two patches.
Note that ther
On Wed, Jan 29, 2014 at 11:55:24AM -0800, Ben Widawsky wrote:
> With the ring mask we now have an easy way to know the number of rings
> in the system, and therefore can accurately predict the number of dwords
> to emit for semaphore signalling. This was not possible (easily)
> previously.
>
> The
On Thu, Jan 30, 2014 at 10:12:06AM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
> > > > On Wed, Jan 29, 2014 at 01:5
On Wed, Jan 29, 2014 at 10:58:48PM +0100, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 10:53 PM, Chris Wilson
> wrote:
> > On Wed, Jan 29, 2014 at 09:25:51PM +0100, Daniel Vetter wrote:
> >> So originally I've thought we need this due to the massive overhead of the
> >> mmu notifier. But now wi
On Thu, Jan 30, 2014 at 10:07:42AM +0100, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > The command parser scans batch buffers submitted via execbuffer ioctls
> > before
> > the driver submits them to hardware. At
On Thu, Jan 30, 2014 at 11:37:01AM +0200, Jani Nikula wrote:
> +static inline bool
> +intel_dp_aux_native_read(struct intel_dp *intel_dp,
> + uint16_t address, uint8_t *recv, int recv_bytes)
> +{
> + return _intel_dp_aux_native_read(intel_dp, address,
> +
On Thu, Jan 30, 2014 at 11:37:00AM +0200, Jani Nikula wrote:
> Fix and cleanup the rather confused native aux read return values and
> return value checks. Maybe we'll get them right from now on. Just maybe.
>
> Did not have a chance to test this, I'm afraid, but it's pretty
> straightforward.
Ho
intel_dp_aux_native_read_retry() is only needed when the sink might be
asleep. Use the regular read without retries otherwise.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/d
intel_dp_aux_native_read_retry() returns a bool, so check for a bool for
consistency. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm
In most cases we only care about success or fail, so make the function
easier to use, and consistent with intel_dp_aux_native_read_retry().
This fixes the intel_dp_aux_native_read() usage in intel_dp_sink_crc()
which has already assumed bool, and would only have caught very specific
failure modes.
Just code shuffling to have intel_dp_aux_native_read_retry() next to its
sibling intel_dp_aux_native_read(). No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 50 +++
1 file changed, 25 insertions(+), 25 deletions(-)
di
Fix and cleanup the rather confused native aux read return values and
return value checks. Maybe we'll get them right from now on. Just maybe.
Did not have a chance to test this, I'm afraid, but it's pretty
straightforward.
BR,
Jani.
Jani Nikula (4):
drm/i915/dp: make intel_dp_aux_native_rea
On Thu, Jan 30, 2014 at 10:20 AM, Tvrtko Ursulin
wrote:
> On 01/29/2014 08:11 PM, Daniel Vetter wrote:
>>
>> On Wed, Jan 29, 2014 at 01:30:54PM +, Tvrtko Ursulin wrote:
>>>
>>> From: Tvrtko Ursulin
>>>
>>> A set of userptr test cases to support the new feature.
>
>
> [snip]
>
>
>> Minor thing
Hi,
On 01/29/2014 08:11 PM, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 01:30:54PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A set of userptr test cases to support the new feature.
[snip]
Minor thing on patch style: I'd split this up into 3 parts:
- Extraction of the helpers - al
On Wed, Jan 29, 2014 at 02:26:12PM -0800, Volkin, Bradley D wrote:
> On Wed, Jan 29, 2014 at 02:13:21PM -0800, Chris Wilson wrote:
> > On Wed, Jan 29, 2014 at 01:57:28PM -0800, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > >
> > > Signed-off-by: Brad Volkin
> > > ---
> > > inclu
On Wed, Jan 29, 2014 at 01:55:13PM -0800, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> So userspace can query the kernel for command parser support.
>
> OTC-Tracker: AXIA-4631
> Change-Id: I58af650db9f6753c2dcac9c54ab432fd31db302f
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/d
On Thu, Jan 30, 2014 at 10:05:28AM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
> > > On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com
> > > wrote:
> > > > +/*
> >
On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The command parser scans batch buffers submitted via execbuffer ioctls before
> the driver submits them to hardware. At a high level, it looks for several
> things:
>
> 1) Commands which are expli
On Thu, Jan 30, 2014 at 09:53:28AM +0100, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
> > On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
> > > +/*
> > > + * Returns a pointer to a descriptor for the command specified by
> > > cm
On Wed, Jan 29, 2014 at 03:18:21PM -0800, Volkin, Bradley D wrote:
> On Wed, Jan 29, 2014 at 02:37:25PM -0800, Chris Wilson wrote:
> > On Wed, Jan 29, 2014 at 01:55:08PM -0800, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > >
> > > These are used to implement scanline waits in the
On Wed, Jan 29, 2014 at 10:28:36PM +, Chris Wilson wrote:
> On Wed, Jan 29, 2014 at 01:55:03PM -0800, bradley.d.vol...@intel.com wrote:
> > +/*
> > + * Returns a pointer to a descriptor for the command specified by
> > cmd_header.
> > + *
> > + * The caller must supply space for a default desc
On Wed, Jan 29, 2014 at 01:55:02PM -0800, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The command parser is going to need the same synchronization and
> setup logic, so factor it out for reuse.
>
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> dri
Chris:
Do we also want to capture?
GAC_ECO_BITS /* gen6,7 */
GAM_ECOCHK /* gen6,7 */
GAB_CTL /* gen6 */
GFX_MODE /* gen6 */
Requested-by: Chris Wilson
Signed-off-by: Ben Widawsky
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gp
v2: Moved num_requests up (Chris)
Rebased on new hws page capture which required a rename since it made
two members named, 'hws' in the per ring error state. (Ben)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 65
drivers/gpu/drm/i915/i915_gpu_error.c
This helps make an upcoming patch a bit more reviewable
Signed-off-by: Ben Widawsky
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 43 -
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/dri
v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
drivers/gpu/drm/i915/i915_gpu_error.c | 37 +++
2 files changed, 46 in
The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.
A subsequent patch will clean this function up.
Signed-off-by: Ben Widawsky
Revi
Create logical sections in an attempt to clean up, and continue to keep
future additions clean.
v2: Reworded the comments. Added section headers (Chris)
Signed-off-by: Ben Widawsky
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 59 +--
1 f
88 matches
Mail list logo
