On Thu, Jul 04, 2013 at 12:55:51AM +0200, Daniel Vetter wrote:
> On Wed, Jul 03, 2013 at 02:45:22PM -0700, Ben Widawsky wrote:
> > Soon we want to gut a lot of our existing assumptions how many address
> > spaces an object can live in, and in doing so, embed the drm_mm_node in
> > the object (and l
On Thu, Jul 04, 2013 at 01:38:05AM +0200, Daniel Vetter wrote:
> On Thu, Jul 4, 2013 at 1:33 AM, Chris Wilson wrote:
> > On Thu, Jul 04, 2013 at 01:26:03AM +0200, Daniel Vetter wrote:
> >> On Thu, Jul 4, 2013 at 1:23 AM, Chris Wilson
> >> wrote:
> >> > So I made the mistake of missing that the d
On Thu, Jul 4, 2013 at 1:33 AM, Chris Wilson wrote:
> On Thu, Jul 04, 2013 at 01:26:03AM +0200, Daniel Vetter wrote:
>> On Thu, Jul 4, 2013 at 1:23 AM, Chris Wilson
>> wrote:
>> > So I made the mistake of missing that the desktop and mobile chipsets
>> > have different layouts in their PCI confi
On Thu, Jul 04, 2013 at 01:26:03AM +0200, Daniel Vetter wrote:
> On Thu, Jul 4, 2013 at 1:23 AM, Chris Wilson wrote:
> > So I made the mistake of missing that the desktop and mobile chipsets
> > have different layouts in their PCI configurations, and we were
> > incorrectly setting the wrong physi
On Thu, Jul 4, 2013 at 1:23 AM, Chris Wilson wrote:
> So I made the mistake of missing that the desktop and mobile chipsets
> have different layouts in their PCI configurations, and we were
> incorrectly setting the wrong physical address for stolen memory on
> mobile chipsets.
>
> Since all gen3+
So I made the mistake of missing that the desktop and mobile chipsets
have different layouts in their PCI configurations, and we were
incorrectly setting the wrong physical address for stolen memory on
mobile chipsets.
Since all gen3+ are actually consistent in the location of the GBSM
register in
On Wed, Jul 03, 2013 at 02:45:22PM -0700, Ben Widawsky wrote:
> Soon we want to gut a lot of our existing assumptions how many address
> spaces an object can live in, and in doing so, embed the drm_mm_node in
> the object (and later the VMA).
>
> It's possible in the future we'll want to add more
On Wed, Jul 03, 2013 at 11:58:31PM +0200, Daniel Vetter wrote:
> On Wed, Jul 3, 2013 at 11:44 PM, Ben Widawsky wrote:
> > Yes. It won't be a requirement for mesa to know, but since I want to
> > kill aliasing ppgtt as much as possible, I intend to update getparam to
> > both set 0 to aliasing, and
On Wed, Jul 3, 2013 at 11:44 PM, Ben Widawsky wrote:
> Yes. It won't be a requirement for mesa to know, but since I want to
> kill aliasing ppgtt as much as possible, I intend to update getparam to
> both set 0 to aliasing, and a new one for ppgtt.
We use that one essentially to decide whether th
On Wed, Jul 03, 2013 at 10:41:11PM +0100, Chris Wilson wrote:
> On Wed, Jul 03, 2013 at 02:23:23PM -0700, Ben Widawsky wrote:
> > On Wed, Jul 03, 2013 at 04:14:31PM +0100, Chris Wilson wrote:
> > > Ben, will we be informing userspace about the ABI change?
> >
> > Hmm. I'm not convinced we ever wan
Shortly we'll want to switch to an embedded drm_mm_node per object, and
therefore using pointers as we're doing is unfeasible.
I've chosen an impossible gtt start offset as the way to denote a
reservation.
CC: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h
Embedding the node in the obj is more natural in the transition to VMAs
which will also have embedded nodes. This change also helps transition
away from put_block to remove node.
Though it's quite an uncommon occurrence, it's somewhat convenient to not
fail at bind time because we cannot allocate
From: Chris Wilson
Clients like i915 needs to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation o
Soon we want to gut a lot of our existing assumptions how many address
spaces an object can live in, and in doing so, embed the drm_mm_node in
the object (and later the VMA).
It's possible in the future we'll want to add more getter/setter
methods, but for now this is enough to enable the VMAs.
v
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(),
With the getters in place from the previous patch this members serves no
purpose other than saving one spare pointer chase, which will be killed
in the next patch anyway.
Moving to VMAs, this members adds unnecessary confusion since an object
may exist at different offsets in different VMs.
Signe
On Wed, Jul 03, 2013 at 02:23:23PM -0700, Ben Widawsky wrote:
> On Wed, Jul 03, 2013 at 04:14:31PM +0100, Chris Wilson wrote:
> > Ben, will we be informing userspace about the ABI change?
>
> Hmm. I'm not convinced we ever want to reset the default context stats.
I meant: will userspace be able t
On Wed, Jul 03, 2013 at 04:14:31PM +0100, Chris Wilson wrote:
> On Wed, Jul 03, 2013 at 05:22:12PM +0300, Mika Kuoppala wrote:
> > int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 33cb973..0d4e3a8 10
From: Paulo Zanoni
Now that the audio driver is using our power well API, everything
should be working correctly, so let's give it a try.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
2013/6/6 Daniel Vetter :
> On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote:
>> Hi all,
>>
>>This is V7 and here're some changes notes:
>>change from V6-->V7:
>>- rename variable
>>- use HAS_POWER_WELL instead of IS_HASWELL
>>- put structure inside drm_i915_private
On Wed, Jul 03, 2013 at 05:22:12PM +0300, Mika Kuoppala wrote:
> int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 33cb973..0d4e3a8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i
Dear Chris Wilson,
> On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote:
> > Hi Chris,
> >
> > > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > > > Hi guys,
> > > >
> > > > I recently got the rMBP 10,1 model, it has two graphic cards:
> > > >
> > > > 00:02.0 VGA compa
Hi Chris,
> On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > Hi guys,
> >
> > I recently got the rMBP 10,1 model, it has two graphic cards:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> > processor Graphics Controller (rev 09)
> > 01:00.0 VGA compati
On 2 July 2013 12:03, Chris Wilson wrote:
> On Tue, Jul 02, 2013 at 12:00:48PM -0700, Paul Berry wrote:
> >On 28 June 2013 15:39, Chris Wilson <[1]ch...@chris-wilson.co.uk>
> wrote:
> >
> > On Fri, Jun 28, 2013 at 03:23:31PM -0700, Ben Widawsky wrote:
> > > This series originated fr
On 28 June 2013 15:39, Chris Wilson wrote:
> On Fri, Jun 28, 2013 at 03:23:31PM -0700, Ben Widawsky wrote:
> > This series originated from the request from Paul, "can you enable page
> > faults"? After some though and discussion, we came up with 3 debug
> features to
> > implement:
>
> The issue
On Wed, Jul 03, 2013 at 12:13:44PM +0100, Chris Wilson wrote:
> On Wed, Jul 03, 2013 at 12:56:54PM +0200, Daniel Vetter wrote:
> > This fixes gpu reset on my gm45 - without this patch the bsd thing is
> > forever stuck since the seqno updates never reach the status page.
> >
> > Tbh I have no idea
From: Mika Kuoppala
Upon resetting the GPU, we begin processing batches once more, so
reset the hangcheck timer.
v2: kicking inside reset instead of hangcheck_elapsed and
sane commit message by Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c |2 ++
1 file
From: Chris Wilson
The default context is always supported (as it contains the global
hangcheck stats) and the contexts for hangcheck are not limited
to any ring.
References: https://bugs.freedesktop.org/show_bug.cgi?id=65845
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/
Hi,
Assortment of hangcheck related stuff and
reset stats ioctl on top.
Ben noted that his ppgtt series provides 1/7 but
I included it here cause 7/7 depends on it.
-Mika
Chris Wilson (2):
drm/i915: Fix retrieval of hangcheck stats
drm/i915: Replace open-coding of DEFAULT_CONTEXT_ID
Mika K
This ioctl returns reset stats for specified context.
The struct returned contains context loss counters.
reset_count:all resets across all contexts
batch_active: active batches lost on resets
batch_pending: pending batches lost on resets
v2: get rid of state tracking completely and deliv
From: Mika Kuoppala
To run hangcheck in near future.
Signed-off-by: Mika Kuoppala
Reviewed-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c |6 ++
drivers/gpu/drm/i915/i915_irq.c | 21 -
3 files changed, 15 insertions
Use reset_counter to track how many actual resets
have been done. Reset in progress is enough to increment
the counter.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |9 +++--
drivers/gpu/drm/i915/i915_irq.c |2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
From: Mika Kuoppala
The timer for hangchecking can run again before the previous
reset it has triggered has been handled. This can corrupt
the hangcheck state as reset handling will access and write to
the hangcheck data. To prevent this, avoid running the hangcheck
logic while reset is in progre
From: Chris Wilson
The intent of the check is made more clear if we use the proper name for
0 here.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Reviewed-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote:
> Hi Chris,
>
> > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > > Hi guys,
> > >
> > > I recently got the rMBP 10,1 model, it has two graphic cards:
> > >
> > > 00:02.0 VGA compatible controller: Intel Corporation 3r
Hi Dave,
Pile of fixes for 3.11. A bit large in patch count, but that's simply due
to two fixes being split up into really small parts. Also I've included a
few more vlv patches than I'd have included for other platforms. But since
vlv is officially supported for the first time only in 3.11 that s
On Wed, Jul 03, 2013 at 12:56:54PM +0200, Daniel Vetter wrote:
> This fixes gpu reset on my gm45 - without this patch the bsd thing is
> forever stuck since the seqno updates never reach the status page.
>
> Tbh I have no idea how this ever worked without rewriting the hws
> registers after a gpu
This fixes gpu reset on my gm45 - without this patch the bsd thing is
forever stuck since the seqno updates never reach the status page.
Tbh I have no idea how this ever worked without rewriting the hws
registers after a gpu reset.
To satisfy my OCD also give the functions a bit more consistent n
Tbh I have no idea how this ever worked without rewriting the hws
registers after a gpu reset.
To satisfy my OCD also give the functions a bit more consistent names:
- Use status_page everywhere, also for the physical addressed one.
- Use init for the allocation part and setup for the register set
On Wed, Jul 03, 2013 at 09:43:32AM +0100, Chris Wilson wrote:
> On Wed, Jul 03, 2013 at 10:07:57AM +0200, Daniel Vetter wrote:
> > Otherwise we can't resurrect the bsd ring on gm45 completely. I've
> > discovered this trick because module reload recovered the bsd ring,
> > making it clear that it's
WARN and return or else we create an invalid stolen mm.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Jul 03, 2013 at 10:07:57AM +0200, Daniel Vetter wrote:
> Otherwise we can't resurrect the bsd ring on gm45 completely. I've
> discovered this trick because module reload recovered the bsd ring,
> making it clear that it's not an issue with the hw or our reset code.
>
> While touching the c
On Wed, Jul 03, 2013 at 10:36:21AM +0200, Daniel Vetter wrote:
> On Wed, Jul 03, 2013 at 09:22:49AM +0100, Chris Wilson wrote:
> > On Wed, Jul 03, 2013 at 10:07:56AM +0200, Daniel Vetter wrote:
> > > Originally I've thought that this fixes up the reset issues on my
> > > gm45, but that was just a r
On Wed, Jul 03, 2013 at 09:22:49AM +0100, Chris Wilson wrote:
> On Wed, Jul 03, 2013 at 10:07:56AM +0200, Daniel Vetter wrote:
> > Originally I've thought that this fixes up the reset issues on my
> > gm45, but that was just a red herring due to b0rked testing.
> >
> > Still I much prefer writing
On Wed, Jul 03, 2013 at 10:07:56AM +0200, Daniel Vetter wrote:
> Originally I've thought that this fixes up the reset issues on my
> gm45, but that was just a red herring due to b0rked testing.
>
> Still I much prefer writing the right values (all other fields are
> reserved) instead of potentiall
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 0f8cf62..51bc8bd 100644
--- a/drivers/
Originally I've thought that this fixes up the reset issues on my
gm45, but that was just a red herring due to b0rked testing.
Still I much prefer writing the right values (all other fields are
reserved) instead of potentially dragging gunk around. Hence also
clear the register to 0 after a reset.
Otherwise we can't resurrect the bsd ring on gm45 completely. I've
discovered this trick because module reload recovered the bsd ring,
making it clear that it's not an issue with the hw or our reset code.
While touching the code update the comment to be a bit clearer about
what we actually want to
On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> Hi guys,
>
> I recently got the rMBP 10,1 model, it has two graphic cards:
>
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Cor
49 matches
Mail list logo
