From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH] drm/i915: Fix pte updates in ggtt clear range
Date: Tue, 27 Nov 2012 08:22:01 +0000 [thread overview]
Message-ID: <b94cdc$7heeq5@fmsmga001.fm.intel.com> (raw)
In-Reply-To: <1353995574-1021-1-git-send-email-ben@bwidawsk.net>
On Mon, 26 Nov 2012 21:52:54 -0800, Ben Widawsky <ben@bwidawsk.net> wrote:
> This bug was introduced by me:
> commit e76e9aebcdbfebae8f4cd147e3c0f800d36e97f3
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date: Sun Nov 4 09:21:27 2012 -0800
>
> drm/i915: Stop using AGP layer for GEN6+
>
> The existing code uses memset_io which follows memset semantics in only
> guaranteeing a write of individual bytes. Since a PTE entry is 4 bytes,
> this can only be correct if the scratch page address is 0.
Gah. Wasn't there an iowrite32_rep?
> This caused unsightly errors when we clear the range at load time,
> though I'm not really sure what the heck is referencing that memory
> anyway. I caught this is because I believe we have some other bug where
> the display is doing reads of memory we feel should be cleared (or we
> are relying on scratch pages to be a specific value).
That's just because we are no longer disabling outputs before updating
the GTT and hence continue to scanout from the BIOS fb during module
load. It's a regression that we'll be able to finally fix properly with
fastboot - though that will not be without its downsides either.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-11-27 8:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 5:52 [PATCH] drm/i915: Fix pte updates in ggtt clear range Ben Widawsky
2012-11-27 8:22 ` Chris Wilson [this message]
2012-11-27 16:32 ` Ben Widawsky
2012-11-27 16:42 ` Chris Wilson
2012-11-28 19:12 ` Ben Widawsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='b94cdc$7heeq5@fmsmga001.fm.intel.com' \
--to=chris@chris-wilson.co.uk \
--cc=ben@bwidawsk.net \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox