On Tue, Jul 03, 2012 at 09:03:16PM -0300, Eugeni Dodonov wrote:
> On 07/03/12 17:24, Daniel Vetter wrote:
> > On Mon, Jul 02, 2012 at 11:51:09AM -0300, Eugeni Dodonov wrote:
> >> This is based on Ivy Bridge clock gating for now, but is subject to
> >> changes in the future.
> >>
> >> Signed-off-by:
On Mon, Jul 02, 2012 at 11:41:43AM -0700, Ben Widawsky wrote:
> On Mon, 2 Jul 2012 11:51:11 -0300
> Eugeni Dodonov wrote:
>
> > This commit moves force wake support routines into intel_pm modules, and
> > exports the gen6_gt_check_fifodbg routine (used in I915_READ).
> >
> > Signed-off-by: Euge
On Sat, Jun 30, 2012 at 08:04:44PM -0700, Ben Widawsky wrote:
> On Fri, 29 Jun 2012 23:32:16 +0200
> Daniel Vetter wrote:
>
> > While creating the new enable/disable_gt_powersave functions in
> >
> > commit 8090c6b9daa04dda649ac0a2209601042abfb0a4
> > Author: Daniel Vetter
> > Date: Sun Jun 2
On Fri, Jun 22, 2012 at 06:53:01PM +0100, Chris Wilson wrote:
> On Fri, 22 Jun 2012 10:40:22 -0700, Keith Packard wrote:
> > Chris Wilson writes:
> >
> > > On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard
> > > wrote:
> >
> > > It was structured to minimise lane count because certain chipset
On Tue, Jul 03, 2012 at 06:48:16PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> And rely on the fact that it's 0 to assume that machines without a PCH
> will have PCH_NONE as dev_priv->pch_type.
>
> Just today I finally realized that HAS_PCH_IBX is true for machines
> without a PCH. IMHO
On Tue, Jul 03, 2012 at 02:16:42PM -0700, Stéphane Marchesin wrote:
> The up and down thresholds are very asymetric, so it is possible
> to have a case where a spike of rendering increases the GPU clock to
> the max (because the up threshold is low) and then a simple blinking
> cursor is enough to
The intention is to help select which engine to use for copies with
interoperating clients - such as a GL client making a request to the X
server to perform a SwapBuffers, which may require copying from the
active GL back buffer to the X front buffer.
Signed-off-by: Chris Wilson
---
drivers/gpu/
On Wed, 4 Jul 2012 12:25:08 +0100, Chris Wilson
wrote:
> The intention is to help select which engine to use for copies with
> interoperating clients - such as a GL client making a request to the X
> server to perform a SwapBuffers, which may require copying from the
> active GL back buffer to t
2012/6/28 Eugeni Dodonov :
> This pollutes dmesg output even if we do not have FBC for the device, so
> move the DRM_DEBUG_KMS statement lower.
>
> v2: just kill the message as suggested by Daniel.
>
> Signed-off-by: Eugeni Dodonov
The message first says we "move the statement lower", but then la
Hi
I certainly like this function split. Reviews inline:
2012/6/28 Eugeni Dodonov :
> CPT/PPT and LPT have different functionality. So we introduce specific
> functions to handle each of them instead of using multiple if..
> statements.
>
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/
2012/6/28 Eugeni Dodonov :
> This is necessary for the modesetting to work correctly after a
> suspend-resume cycle. Without this, the pipes and clocks got the correct
> configuration, but the underlying DDI buffers configuration was lost.
>
> Signed-off-by: Eugeni Dodonov
I couldn't make suspend
Hi all,
I took me a while to see the real issues Chris has been complaining about, but I
think the reworked patches take them all into account now. The big change is
that the wedged check at the beginning of intel_ring_begin stays, but gets
improved by properly deciding betweein -EIO and -EAGAIN.
Simply failing to reset the gpu because someone else might still hold
the mutex isn't a great idea - I see reliable silent reset failures.
And gpu reset simply needs to be reliable and Just Work.
"But ... the deadlocks!"
We already kick all processes waiting for the gpu before launching the
reset
So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
-EIO instead. Note that this isn't really an issue with
interruptability, but more that we have quite a few codepaths (mostly
around kms stuff) that simply can't handle any errors and hence not
even -EGAIN. Instead of adding prope
With the gpu reset no longer using a trylock we've increased the
chances of userspace getting stuck quite a bit. To make that
(hopefully) rare case more paletable time out when waiting for the gpu
reset code to complete and signal this little issue to the caller by
returning -EIO.
This should help
... instead of looping endless with no hope of ever serving that
page-fault. We only need to break out of this loop when the gpu died,
to run the reset work (and hopefully resurrect it).
This seems to have been lost in:
commit d9bc7e9f32716901c617e1f0fb6ce0f74f172686
Author: Chris Wilson
Date:
The issue with this check is that it results in userspace receiving an
-EIO while the gpu reset hasn't completed, resulting in fallback to sw
rendering or worse.
Now there's also a stern comment in intel_ring_wait_seqno saying that
intel_ring_begin should not return -EAGAIN, ever, because some cal
On Wed, Jul 04, 2012 at 05:07:39PM -0300, Paulo Zanoni wrote:
> 2012/6/28 Eugeni Dodonov :
> > This is necessary for the modesetting to work correctly after a
> > suspend-resume cycle. Without this, the pipes and clocks got the correct
> > configuration, but the underlying DDI buffers configuration
On Wed, Jul 04, 2012 at 10:18:42PM +0200, Daniel Vetter wrote:
> ... instead of looping endless with no hope of ever serving that
> page-fault. We only need to break out of this loop when the gpu died,
> to run the reset work (and hopefully resurrect it).
To clarify questions Chris raised on irc:
The issue with this check is that it results in userspace receiving an
-EIO while the gpu reset hasn't completed, resulting in fallback to sw
rendering or worse.
Now there's also a stern comment in intel_ring_wait_seqno saying that
intel_ring_begin should not return -EAGAIN, ever, because some cal
So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
-EIO instead. Note that this isn't really an issue with
interruptability, but more that we have quite a few codepaths (mostly
around kms stuff) that simply can't handle any errors and hence not
even -EAGAIN. Instead of adding prop
On Wed, 4 Jul 2012 22:18:38 +0200, Daniel Vetter
wrote:
> Hi all,
>
> I took me a while to see the real issues Chris has been complaining about,
> but I
> think the reworked patches take them all into account now. The big change is
> that the wedged check at the beginning of intel_ring_begin s
Hi
2012/6/28 Eugeni Dodonov :
> This is required for a stable FDI connection.
>
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_ddi.c | 10 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_re
2012/7/3 Daniel Vetter :
> We already have this pattern at quite a few places, and moving part of
> the modeset helper stuff into the driver will add more.
>
> v2: Don't clobber the crtc struct name with the macro parameter ...
>
> Signed-Off-by: Daniel Vetter
Looks like you're missing some place
On Mon, 2 Jul 2012 11:51:05 -0300, Eugeni Dodonov
wrote:
> I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
> I915_WRITE(GEN6_RP_CONTROL,
> GEN6_RP_MEDIA_TURBO |
> @@ -2444,7 +2457,7 @@ static void gen6_enable_rps(struct drm_device *dev)
> GEN6_RP_MEDIA_IS_GF
Noticed by Chris Wilson, this got through in the last iteration of the rps
for Haswell patch.
CC: Chris Wilson
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/
On 07/04/2012 05:35 PM, Daniel Vetter wrote:
> On Wed, Jul 04, 2012 at 05:07:39PM -0300, Paulo Zanoni wrote:
>> 2012/6/28 Eugeni Dodonov :
>>> This is necessary for the modesetting to work correctly after a
>>> suspend-resume cycle. Without this, the pipes and clocks got the correct
>>> configurati
This is required for a stable FDI connection.
v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.
CC: Paulo Zanoni
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ddi.c | 9 +
2 files changed, 12 insertions(+)
di
On 07/04/2012 02:41 PM, Paulo Zanoni wrote:
> 2012/6/28 Eugeni Dodonov :
>> This pollutes dmesg output even if we do not have FBC for the device, so
>> move the DRM_DEBUG_KMS statement lower.
>>
>> v2: just kill the message as suggested by Daniel.
>>
>> Signed-off-by: Eugeni Dodonov
>
> The messa
On Wed, 4 Jul 2012 20:07:02 -0300, Eugeni Dodonov
wrote:
> Noticed by Chris Wilson, this got through in the last iteration of the rps
> for Haswell patch.
That's the fix. Hopefully there is enough time for Daniel to rewrite
history and spare our blushes.
-Chris
--
Chris Wilson, Intel Open Sou
30 matches
Mail list logo
