Wait request is poorly named IMO. After working with these functions for
some time, I feel it's much clearer to name the functions more
appropriately.
Of course we must update the callers to use the new name as well.
This leaves room within our namespace for a *real* wait request function
at some
Move the final interesting chunk from i915_wait_seqno into a timed
variant. The timed variant can take a NULL or 0 timeout argument to
preserve the old behavior, and this allowing the old (still useful
function) to call directly into the timed variant.
This code does not require struct_mutex, ther
Finally we can use the new timed seqno waiting function to allow
userspace to wait on a request with a timeout. This implements that
interface.
The new ioctl is very straight forward, there is a flags field which I
envision may be useful for various flush permutations of the command.
Signed-off-b
Insert a wait parameter in the code so we can possibly timeout on a
seqno wait if need be. The code should be functionally the same as
before because all the callers will continue to retry if an arbitrary
timeout elapses.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 41 +++
It turns out throttle had an almost identical bit of code to do the
wait. Now we can call the new helper directly. This is just a bonus,
and not needed for the overall series.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c |9 ++---
1 file changed, 2 insertions(+), 7 d
The only time irq_get should fail is during unload or suspend. Both of
these points should try to quiesce the GPU before disabling interrupts
and so the atomic polling should never occur.
This was recommended by Chris Wilson as a way of reducing added
complexity to the polled wait which I introduc
i915_wait_request is actually a fairly large function encapsulating
quite a few different operations. Because being able to wait on seqnos
in various conditions is useful, extracting that bit of code to a helper
function seems useful
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.
It's not terribly useful and it ruins our ability to do waits atomically.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c |2 --
drivers/gpu/drm/i915/i915_gem.c |2 --
drivers/gpu/drm/i915/i915_irq.c |8 +++-
drivers/gpu/drm/i915/intel_ring
This extra bit of interrupt enabling code doesn't belong in the wait
seqno function. If anything we should pull it out to a helper so the
throttle code can also use it. The history is a bit vague, but I am
going to attempt to just dump it, unless someone can argue otherwise.
Removing this allows f
This originates from a hack by me to quickly fix a bug in an earlier
patch where we needed control over whether or not waiting on a seqno
actually did any retire list processing. Since the two operations aren't
clearly related, we should pull the parameter out of the wait function,
and make the cal
patches 1-6 are various fixes and cleanups in our existing wait_request
handling code. The purpose here is to consolidate as much code as
possible into core waiting functions, and to prepare those core
functions for atomic access.
patches 7-8 are the patches we actually care about - timeout parame
On Fri, 20 Apr 2012 21:03:36 +0200, Daniel Vetter
wrote:
> Somehow we have a fast-path that tries to avoid going through
> the load-detect code when the encode already has a crtc associated.
> But this fails horribly when the crtc is off. The load detect pipe
> itself manages this case well (and
On Fri, 20 Apr 2012 21:03:35 +0200, Daniel Vetter
wrote:
> If we try to do that and the scanlines just wouldn't advance, we
> busy-hang the machine holding the modeset mutex. Not great for
> debugging.
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=43020
> Signed-off-by: Daniel Vett
On Fri, Apr 20, 2012 at 08:24:04PM +0100, Chris Wilson wrote:
> On Fri, 20 Apr 2012 11:50:01 -0700, Ben Widawsky wrote:
> > Chris' fix for my 32b breakage was incorrect. do_div returns a
> > remainder. Go back to a divide macro which is more 32b friendly.
> >
> > Tested on x86-64.
> >
> > This h
On Fri, 20 Apr 2012 11:50:01 -0700, Ben Widawsky wrote:
> Chris' fix for my 32b breakage was incorrect. do_div returns a
> remainder. Go back to a divide macro which is more 32b friendly.
>
> Tested on x86-64.
>
> This has only been compile tested on 32b systems.
>
> Bugzilla: https://bugs.free
When fixing up the crt load detect code I've failed to notice the same
problem in the tv load detect code. Again, unconditionally use the
load detect pipe infrastructure, it gets things right.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c |4 +---
1 file changed, 1 inserti
Somehow we have a fast-path that tries to avoid going through
the load-detect code when the encode already has a crtc associated.
But this fails horribly when the crtc is off. The load detect pipe
itself manages this case well (and also does not forget to restore the
dpms state), so just rip out th
If we try to do that and the scanlines just wouldn't advance, we
busy-hang the machine holding the modeset mutex. Not great for
debugging.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43020
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 21 -
Chris' fix for my 32b breakage was incorrect. do_div returns a
remainder. Go back to a divide macro which is more 32b friendly.
Tested on x86-64.
This has only been compile tested on 32b systems.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48756
Cc: Chris Wilson
Signed-off-by: Ben Wi
Pretty useful to debug our DP bandwidth woes.
v2: Also print out the required and available link bandwidth,
suggested by Chris Wilson.
v3: Also print out the input parameters so that diagnosing failures to
find a valid dp link configuration is possible.
v4: s/Display port/DP/ to shorten the outp
Pretty useful to debug our DP bandwidth woes.
v2: Also print out the required and available link bandwidth,
suggested by Chris Wilson.
v3: Also print out the input parameters so that diagnosing failures to
find a valid dp link configuration is possible.
v4: s/Display port/DP/ to shorten the outp
From: Jesse Barnes
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
v2: add num_pch_pll fiel
From: Jesse Barnes
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
v2: add num_pch_pll fiel
On Fri, Apr 20, 2012 at 05:59, Chris Wilson wrote:
> From: Jesse Barnes
>
> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> treat them as part of the pipe.
>
> So split the code out and manage PCH PLLs separately, allocating them
> when needed or trying to re-use existing
On Fri, 20 Apr 2012 16:25:58 +0200, Daniel Vetter
wrote:
> Pretty useful to debug our DP bandwidth woes.
>
> v2: Also print out the required and available link bandwidth,
> suggested by Chris Wilson.
>
> v3: Also print out the input parameters so that diagnosing failures to
> find a valid dp li
Pretty useful to debug our DP bandwidth woes.
v2: Also print out the required and available link bandwidth,
suggested by Chris Wilson.
v3: Also print out the input parameters so that diagnosing failures to
find a valid dp link configuration is possible.
Signed-Off-by: Daniel Vetter
---
drivers
At Fri, 20 Apr 2012 13:05:48 +0100,
Dave Airlie wrote:
>
> On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai wrote:
> > At Thu, 19 Apr 2012 14:03:58 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Tue, 17 Apr 2012 17:26:26 +0200,
> >> Takashi Iwai wrote:
> >> >
> >> > At Fri, 13 Apr 2012 16:56:26 -0400,
At Fri, 20 Apr 2012 13:04:42 +0100,
Dave Airlie wrote:
>
> On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai wrote:
> > At Tue, 17 Apr 2012 17:26:26 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Fri, 13 Apr 2012 16:56:26 -0400,
> >> Adam Jackson wrote:
> >> >
> >> > On 4/13/12 4:33 PM, Adam Jackson wro
On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai wrote:
> At Thu, 19 Apr 2012 14:03:58 +0200,
> Takashi Iwai wrote:
>>
>> At Tue, 17 Apr 2012 17:26:26 +0200,
>> Takashi Iwai wrote:
>> >
>> > At Fri, 13 Apr 2012 16:56:26 -0400,
>> > Adam Jackson wrote:
>> > >
>> > > On 4/13/12 4:33 PM, Adam Jackson wr
On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai wrote:
> At Tue, 17 Apr 2012 17:26:26 +0200,
> Takashi Iwai wrote:
>>
>> At Fri, 13 Apr 2012 16:56:26 -0400,
>> Adam Jackson wrote:
>> >
>> > On 4/13/12 4:33 PM, Adam Jackson wrote:
>> > > Incorporates some feedback from Rodrigo and Takashi. Major the
We seem to trigger an occasional error when the GPU tries to dereference
a PTE for an overlay plane prior to us populating the offsets in the
overlay registers. This is despite the Overlay Command being set to off.
Close this window delaying the switch on until after those registers are
initialised
On Fri, 20 Apr 2012 11:29:48 +0200, Daniel Vetter
wrote:
> Pretty useful to debug our DP bandwidth woes.
>
> v2: Also print out the required and available link bandwidth,
> suggested by Chris Wilson.
And possibly even more important in the failure path! ;-)
-Chris
--
Chris Wilson, Intel Open
Pretty useful to debug our DP bandwidth woes.
v2: Also print out the required and available link bandwidth,
suggested by Chris Wilson.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/
On Fri, 20 Apr 2012 11:08:45 +0200, Daniel Vetter
wrote:
> Pretty useful to debug our DP bandwidth woes.
I'd like to see the computed values as well, i..e the link_required and
max_data_rate.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
Pretty useful to debug our DP bandwidth woes.
Signed-Off-by: Daniel Vetter
---
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/i915/intel_dp.c
index 44cf32c..4640790 100644
--- a/drivers/
From: Jesse Barnes
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
v2: add num_pch_pll fiel
On Fri, Apr 20, 2012 at 08:48:40AM +0100, Chris Wilson wrote:
> On Fri, 20 Apr 2012 09:30:58 +0200, Daniel Vetter wrote:
> > QA reported that this blows up:
> >
> > https://bugs.freedesktop.org/process_bug.cgi
>
> Which bug?
Duuh.
https://bugs.freedesktop.org/show_bug.cgi?id=48950
/me grabs a
On Fri, 20 Apr 2012 09:30:58 +0200, Daniel Vetter wrote:
> QA reported that this blows up:
>
> https://bugs.freedesktop.org/process_bug.cgi
Which bug?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@li
On Wed, Apr 18, 2012 at 11:36:08PM +0200, Daniel Vetter wrote:
> On Fri, Apr 13, 2012 at 06:24:38PM +0100, Chris Wilson wrote:
> > From: Jesse Barnes
> >
> > PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> > treat them as part of the pipe.
> >
> > So split the code out an
39 matches
Mail list logo
