On Thu, 14 Apr 2011 10:03:38 +0100, Chris Wilson
wrote:
> + obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
> + obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
I'll bet you want to modify the read_domain as well.
--
keith.pack...@intel.com
pgp2NzoJuMYNT.pgp
Description: PGP signatur
On Thu, 14 Apr 2011 10:03:41 +0100, Chris Wilson
wrote:
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5360,7 +5360,7 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
> goto fail_locked;
> }
>
> -
On Thu, 14 Apr 2011 10:03:45 +0100, Chris Wilson
wrote:
> The docs have a dire warning not to attempt to access snooped (the old
> style of cache sharing on pre-SandyBridge chipsets) pages through the GTT.
> Prevent userspace from doing so by sending them a SIGBUS if they try.
There is not plan
On Thu, 14 Apr 2011 10:03:46 +0100, Chris Wilson
wrote:
> Older chipsets do not support snooping (i.e. cache sharing between the
> CPU and GPU) on tiled surfaces. So prevent userspace from being silly
> should we one day expose the ability to change cache levels from
> userspace.
We will not ne
On Wed, 04 May 2011 10:09:53 -0700, Keith Packard wrote:
> On Thu, 14 Apr 2011 10:03:41 +0100, Chris Wilson
> wrote:
>
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5360,7 +5360,7 @@ static int intel_crtc_cursor_set(struct drm_crtc
> > *c
On Wed, 04 May 2011 19:28:35 +0100, Chris Wilson
wrote:
> to simply mark the device as uninterruptible for the duration.
>
> The code now does the latter.
I'm good with that plan during modesetting, the question is whether the
new users of this function should allow for interrupts.
--
keith.
On Thu, 21 Apr 2011 22:18:23 +0100, Chris Wilson
wrote:
> As we failed to update the dpms_mode after modeset, where it is presumed
> to have been changed to DRM_MODE_DPMS_ON by the upper layers the dpms state
> on the crtc became inconsistent with its actual active state. This
> notably confused
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson
wrote:
> Something to think about...
Missing SoB here...
--
keith.pack...@intel.com
pgpnCoAAssejC.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lis
On Wed, 04 May 2011 12:21:27 -0700, Keith Packard wrote:
> On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson
> wrote:
>
> > Something to think about...
>
> Missing SoB here...
Indeed, I'm still thinking about this one. I don't think it's ready yet.
-Chris
--
Chris Wilson, Intel Open Source T
On Wed, 04 May 2011 12:10:06 -0700, Keith Packard wrote:
> On Thu, 21 Apr 2011 22:18:23 +0100, Chris Wilson
> wrote:
>
> > As we failed to update the dpms_mode after modeset, where it is presumed
> > to have been changed to DRM_MODE_DPMS_ON by the upper layers the dpms state
> > on the crtc bec
On Wed, 04 May 2011 11:46:42 -0700, Keith Packard wrote:
> On Wed, 04 May 2011 19:28:35 +0100, Chris Wilson
> wrote:
>
> > to simply mark the device as uninterruptible for the duration.
> >
> > The code now does the latter.
>
> I'm good with that plan during modesetting, the question is wheth
I've add a few modesetting patches to drm-intel-fixes that I'm
hoping we can get merged for 2.6.39. Please test these soon so that I
can get a pull request sent in this week.
The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e:
Linux 2.6.39-rc6 (2011-05-03 19:59:13 -070
On Wed, 04 May 2011 20:40:37 +0100, Chris Wilson
wrote:
> We can remove dpms_mode in favour of solely using active.
That sounds like a good plan.
And what about the intel_dp->dpms_mode value? Should it be switched to a
simple 'active' boolean as well? Or is the existing crtc->active value
suff
On Wed, 04 May 2011 14:20:27 -0700, Keith Packard wrote:
> On Wed, 04 May 2011 20:40:37 +0100, Chris Wilson
> wrote:
>
> > We can remove dpms_mode in favour of solely using active.
>
> That sounds like a good plan.
>
> And what about the intel_dp->dpms_mode value? Should it be switched to a
>
On Thu, 21 Apr 2011, Mike Isely wrote:
> On Thu, 21 Apr 2011, Chris Wilson wrote:
>
> > On Thu, 21 Apr 2011 17:30:21 -0500 (CDT), Mike Isely
> > wrote:
> > > It looks like the driver did notice the specified mode and used it -
> > > because the display's refresh rate did get adjusted and the
The drm function which parses a mode into a standard mode line is
computing the "margins" flag but then failing to copy that parameter
into the parsed structure output. This seems to leave the field in a
random state, which unfortunately influences the results when the
parsed results are then sub
>
> The drm function which parses a mode into a standard mode line is
> computing the "margins" flag but then failing to copy that parameter
> into the parsed structure output. This seems to leave the field in a
> random state, which unfortunately influences the results when the
> parsed results a
17 matches
Mail list logo
