Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
put the proper "NULL" values in for the mbox info.
v2: v1 had a stale
This patch series implements hardware semaphores to be on par with support of
other platforms. The biggest change in the series is the removal of the
mailboxes we previously had. To replace this, there is a 4k BO allocated for
the semaphore communication. This could have also been done in the HWSP.
On Fri, Dec 13, 2013 at 08:15:55PM -0800, Ben Widawsky wrote:
> Gen8 will do things a bit differently. As such split out the semaphore
> member initialization, and use proper NOPfor gen8, since the old commands
> don't work.
This is the wrong commit message for this patch. The original commit
only
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 0152073..f6d1e79 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/
A few command were out of numerical order and had different spacing. Put
them back in numerical order, with proper spacing.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 52 -
1 file changed, 26 insertions(+), 26 deletions(-)
diff --gi
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've opted for, which should
be fairly future proof. Ie. I tried to define
Gen8 will do things a bit differently. As such split out the semaphore
member initialization, and use proper NOPfor gen8, since the old commands
don't work.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 134 ++--
1 file changed, 92 insertio
Simple debugfs file to display the current state of semaphores. This is
useful if you want to see the state without hanging the GPU.
NOTE: This patch is optional to the series.
NOTE2: Like the GPU error state collection, the reads are currently
incoherent.
Signed-off-by: Ben Widawsky
---
drive
Everything should be lined up now to make gen8 semaphores work like they
did on previous generations, so just do it.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i91
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.
There should be no functional impact, simply fewer instructions emitted.
Whi
This abstraction again is in preparation for gen8. Gen8 will bring new
semantics for doing this operation.
While here, make the writes of MI_NOOPs explicit for non-existent rings.
This should have been implicit before.
NOTE: This is going to be removed in a few patches.
Signed-off-by: Ben Widaws
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 anything but
0s. Note that the semaphore waits are indeed working.
Signe
Implement the note indicated in the bspec.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index e08acab..a14a3b3 100644
--- a/d
Add_request has always contained both the semaphore mailbox updates as
well as the breadcrumb writes. Since the semaphore signal is the one
which actually knows about the number of dwords it needs to emit to the
ring, we move the ring_begin to that function. This allows us to remove
the hideously s
This macro, unlike for_each_ring, will iterate all rings supported by
the platform. It is distinct from for_each_ring in that it can be used
before rings are initialized (and after they are destroyed).
NOTE: I've written this macro a few times in a few different places. The
name differed this time
Having the ring id all set up will allow us to use some macro shortcuts
during ringbuffer init. Admittedly it leaves the code a bit confusing,
having the initialization of the id member in a separate place - but I
think the savings is worth it.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i91
This will be helpful in abstracting some of the code in preparation for
gen8 semaphores.
Cc: Mika Kuoppala
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 10 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 84 ++
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a577640..ebdc8a7 100644
--- a/drivers/gp
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.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 3
Aside from the fact that it leaves confusing dumps on error capture, it
is entirely unnecessary, and potentially harmful in cases like BDW,
where the instruction has changed.
In reality (seemingly), this will have no behavioral impact.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_
On Fri, 13 Dec 2013 21:47:45 +0100
Daniel Vetter wrote:
> On Fri, Dec 13, 2013 at 8:09 PM, Jesse Barnes
> wrote:
> > On Thu, 12 Dec 2013 23:54:37 +0100
> > Daniel Vetter wrote:
> >
> >> > @@ -258,8 +357,102 @@ static void intel_fbdev_destroy(struct drm_device
> >> > *dev,
> >> >
> >> > dr
On Fri, Dec 13, 2013 at 8:26 PM, Jesse Barnes wrote:
> Obviously still need a lot of work (and I didn't quite get the patch
> split correctly, I meant commit the first bits earlier).
>
> I think the approach may be sound though, and is actually not too hard
> to get right with all the cross checki
On Fri, Dec 13, 2013 at 8:09 PM, Jesse Barnes wrote:
> On Thu, 12 Dec 2013 23:54:37 +0100
> Daniel Vetter wrote:
>
>> > @@ -258,8 +357,102 @@ static void intel_fbdev_destroy(struct drm_device
>> > *dev,
>> >
>> > drm_fb_helper_fini(&ifbdev->helper);
>> >
>> > - drm_framebuffer_unregister_p
On Fri, Dec 13, 2013 at 08:48:24PM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Also, skip the compilation of pm_lpsp in Android (uses Cairo)
>
> Signed-off-by: Oscar Mateo
Oops, we seem to be pretty bad at breaking the Android build :(
Applied, thanks for the patch.
-Daniel
--
On Fri, Dec 13, 2013 at 05:46:38PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> In the current code, at haswell_modeset_global_resources, first we
> decide if we want to enable/disable the power well, then we decide if
> we want to enable/disable PC8. On the case where we're enabling PC8
>
On 12/12/2013 03:28 PM, Ben Widawsky wrote:
> WaVSRefCountFullforceMissDisable and
> WaDSRefCountFullforceMissDisable
>
> VS is a carry-over from HSW, and DS is likely not used by anyone yet.
You're correct that no one uses DS; we don't support GL 4.0's
tessellation shaders yet.
I was about to c
From: Oscar Mateo
Also, skip the compilation of pm_lpsp in Android (uses Cairo)
Signed-off-by: Oscar Mateo
---
tests/Android.mk | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/tests/Android.mk b/tests/Android.mk
index c96f30a..c65f94c
From: Paulo Zanoni
In the current code, at haswell_modeset_global_resources, first we
decide if we want to enable/disable the power well, then we decide if
we want to enable/disable PC8. On the case where we're enabling PC8
this works fine, but on the case where we disable PC8 due to a non-eDP
mo
The intent is to get back to userspace as quickly as possible so it can
start doing drawing or whatever. It should also allow our
suspend/resume/init time to improve a lot.
---
drivers/gpu/drm/i915/i915_irq.c | 10 +-
drivers/gpu/drm/i915/intel_display.c | 27
Obviously still need a lot of work (and I didn't quite get the patch
split correctly, I meant commit the first bits earlier).
I think the approach may be sound though, and is actually not too hard
to get right with all the cross checking we have in place. Things to
fix:
- modeset cross check -
This allows us to hide queuing of enable/disable later.
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_display.c | 83 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
4 files changed, 71 i
On Thu, 12 Dec 2013 23:54:37 +0100
Daniel Vetter wrote:
> > @@ -258,8 +357,102 @@ static void intel_fbdev_destroy(struct drm_device
> > *dev,
> >
> > drm_fb_helper_fini(&ifbdev->helper);
> >
> > - drm_framebuffer_unregister_private(&ifbdev->ifb.base);
> > - intel_framebuffer_fini(&if
\o/
Reviewed-by: Rodrigo Vivi
On Fri, Dec 13, 2013 at 3:22 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now that all the infrastructure is in place and all the tests from
> pm_pc8 pass, we can finally enable the feature.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_dr
When I saw this I was afraid this force could break userspace somehow,
but Paulo explained me the release with pagefault mechanism. Thanks Paulo.
Reviewed-by: Rodrigo Vivi
On Fri, Dec 13, 2013 at 3:22 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So we'll get a fault when someone tries to a
On Fri, Dec 13, 2013 at 07:03:11PM +0100, Daniel Vetter wrote:
> On Fri, Dec 13, 2013 at 05:51:25PM +, Damien Lespiau wrote:
> > - *.log/*.trs are generated by make check
> > - TAGS are generated by make tags
> > - build-aux, config.h.in~ by autoconf
> > - *.sw? are temporary files create by vi
libdrm has a way to unit-test the CS decoder: test_decode can decode a raw
batch and compare it to a reference output.
However, one still needs to genarate the raw, binary, batches to feed to
test_decode. This couple of patches do exactly that.
--
Damien
These batches can be used to test the CS parser in libdrm. Let's start
by generating a MI_FLUSH_DW command that flushes a DWord (as opposed to
a QWord).
Signed-off-by: Damien Lespiau
---
tests/.gitignore | 1 +
tests/Makefile.sources| 1 +
tests/generate_test_batches.c |
Signed-off-by: Damien Lespiau
---
tests/generate_test_batches.c | 20
1 file changed, 20 insertions(+)
diff --git a/tests/generate_test_batches.c b/tests/generate_test_batches.c
index 997ce37..41f883d 100644
--- a/tests/generate_test_batches.c
+++ b/tests/generate_test_batch
Reviewed-by: Rodrigo Vivi
On Fri, Dec 13, 2013 at 3:22 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The hangcheck function requires the hardware to be working, and if
> we're suspending we're going to put the HW in D3 state.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i91
On Fri, Dec 13, 2013 at 05:51:26PM +, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> intel/test_decode.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/intel/test_decode.c b/intel/test_decode.c
> index 0fcdf3b..b710f34 100644
> --- a/intel/test_decode.c
> +++ b/intel
On Fri, Dec 13, 2013 at 05:51:25PM +, Damien Lespiau wrote:
> - *.log/*.trs are generated by make check
> - TAGS are generated by make tags
> - build-aux, config.h.in~ by autoconf
> - *.sw? are temporary files create by vim
> - name_from_fd wasn't ignored yet for some reason
>
> Signed-off-by:
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 0fcdf3b..b710f34 100644
--- a/intel/test_decode.c
+++ b/intel/test_decode.c
@@ -146,6 +146,7 @@ infer_devid(const char *batch_filename)
- *.log/*.trs are generated by make check
- TAGS are generated by make tags
- build-aux, config.h.in~ by autoconf
- *.sw? are temporary files create by vim
- name_from_fd wasn't ignored yet for some reason
Signed-off-by: Damien Lespiau
---
.gitignore | 8 +++-
1 file changed, 7 insertions(+)
On Fri, Dec 13, 2013 at 03:37:07PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/12/13 Dave Jones :
> > I left this on overnight, and this morning this was in the log.
> >
> > Dave
> >
> > WARNING: CPU: 1 PID: 131 at drivers/gpu/drm/i915/intel_display.c:6309
> > hsw_enable_pc8_work+0x6a9/0x6d0
Hi
2013/12/13 Dave Jones :
> I left this on overnight, and this morning this was in the log.
>
> Dave
>
> WARNING: CPU: 1 PID: 131 at drivers/gpu/drm/i915/intel_display.c:6309
> hsw_enable_pc8_work+0x6a9/0x6d0()
> Power well on
> Modules linked in: tun hidp bnep rfcomm can_raw can_bcm cai
From: Paulo Zanoni
Now that all the infrastructure is in place and all the tests from
pm_pc8 pass, we can finally enable the feature.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dr
From: Paulo Zanoni
So we'll get a fault when someone tries to access the mmap, then we'll
wake up from D3.
v2: - Rebase
v3: - Use gtt active/inactive
Testcase: igt/pm_pc8/gem-mmap-gtt
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 1
From: Paulo Zanoni
The hangcheck function requires the hardware to be working, and if
we're suspending we're going to put the HW in D3 state.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/dr
Hi all,
New -testing cycle with cool stuff:
- fbc1 improvements from Ville (pre-gm45).
- vlv forcewake improvements from Deepak S.
- Some corner-cases fixes from Mika for the context hang stat code.
- pc8 improvements and prep work for runtime D3 from Paulo, almost ready for
primetime.
- gen2 dp
On Fri, Dec 13, 2013 at 11:09:58AM +, Damien Lespiau wrote:
> On Thu, Dec 12, 2013 at 03:28:04PM -0800, Ben Widawsky wrote:
> > WaVSRefCountFullforceMissDisable and
> > WaDSRefCountFullforceMissDisable
> >
> > VS is a carry-over from HSW, and DS is likely not used by anyone yet.
> >
> > Cc: K
On Fri, Dec 13, 2013 at 04:24:37PM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> With Full PPGTT, each new fd creates a new context and thus a new
> PPGTT, so we have to reduce the number of simultaneous fds or face
> OOM problems. For every new PPGTT, its PDEs are stored in the GGT
From: Oscar Mateo
With Full PPGTT, each new fd creates a new context and thus a new
PPGTT, so we have to reduce the number of simultaneous fds or face
OOM problems. For every new PPGTT, its PDEs are stored in the GGTT
which imposes a limit of 1024 new contexts. We want to leave at
least 1/4 of th
I left this on overnight, and this morning this was in the log.
Dave
WARNING: CPU: 1 PID: 131 at drivers/gpu/drm/i915/intel_display.c:6309
hsw_enable_pc8_work+0x6a9/0x6d0()
Power well on
Modules linked in: tun hidp bnep rfcomm can_raw can_bcm caif_socket caif phonet
af_rxrpc bluetooth c
From: Ville Syrjälä
Not all registers need forcewake even if they're not shadowed.
Add the missing check to gen8_writeX() to avoid needless forcewake
usage when writing eg. display registers.
v2: Use straight up <0x4 check instead of NEEDS_FORCE_WAKE()
Reviewed-by: Ben Widawsky
Signed-off-
On Thu, Dec 12, 2013 at 03:28:04PM -0800, Ben Widawsky wrote:
> WaVSRefCountFullforceMissDisable and
> WaDSRefCountFullforceMissDisable
>
> VS is a carry-over from HSW, and DS is likely not used by anyone yet.
>
> Cc: Kenneth Graunke
> Signed-off-by: Ben Widawsky
Reviewed-by: Damien Lespiau
On Thu, Dec 12, 2013 at 05:26:03PM -0800, Ben Widawsky wrote:
> I stumbled on to some unimplemented errata. To be honest, I am not
> really sure of the impact, just that the docs say to do.
>
> No w/a name for this one.
WaForceEnableNonCoherent looks like a good candidate.
> v2: v1 was a stale t
Damien Lespiau writes:
> v3, following up a couple of review comments from Ville:
> http://lists.freedesktop.org/archives/intel-gfx/2013-December/037313.html
>
> Changes:
> - Always use INTEL_INFO() after initialization to access dev_priv->info
> (well, except in the reg macros, where it'
On Thu, Dec 12, 2013 at 01:08:16PM -0800, Jesse Barnes wrote:
> On Thu, 17 Oct 2013 22:53:19 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Add trace points for observing the atomic pipe update mechanism.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers
On Thu, Dec 12, 2013 at 09:58:25PM +0100, Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 9:56 PM, Jesse Barnes
> wrote:
> > On Thu, 17 Oct 2013 22:53:13 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> >> From: Ville Syrjälä
> >>
> >> When color keying is used, the primary may not be invisib
59 matches
Mail list logo
