Re: [Intel-gfx] [PATCH] drm/i915: Ironlake GPU with VT-d fix

On Thu, 22 Sep 2011 22:09:39 -0700, Ben Widawsky wrote: > On Thu, 22 Sep 2011 21:50:49 -0700 > Keith Packard wrote: > > > On Thu, 22 Sep 2011 17:11:52 -0700, Ben Widawsky > > wrote: > > > > > It requires an additional IOMMU patch. > > > > Can we collect those two patches into one sequence? >

[Intel-gfx] The latest status of Drm and display testing & gem_stress tesing

All, This week, we have finished a new round of DRM and display testing. A new bug is filed: 41140 [SNB] "[drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH "so long as plug in vga monitor And the following bugs are the old

Re: [Intel-gfx] [PATCH] drm/i915: IOCTL to query the cache level of a BO.

On Thu, Sep 22, 2011 at 04:27:10PM -0700, Ben Widawsky wrote: > Querying a BO's cache level can help clients wishing to map the buffer. > For example, an Ironlake machine could query the buffer to determine it > should use GTT mappings, while a Sandybridge machine running the same > code would pref

Re: [Intel-gfx] [PATCH] intel: non-blocking mmaps on the cheap

On Thu, Sep 22, 2011 at 04:35:20PM -0700, Ben Widawsky wrote: > From: Daniel Vetter > > This adds a new mode to map gem objects in a non-blocking way. > > The new kernel interface required to get the caching level/coherency > is not yet wired up. All the code to transparently choose between gtt

Re: [Intel-gfx] [PATCH] drm/i915: IOCTL to query the cache level of a BO.

On Thu, 22 Sep 2011 16:27:10 -0700, Ben Widawsky wrote: > Querying a BO's cache level can help clients wishing to map the buffer. > For example, an Ironlake machine could query the buffer to determine it > should use GTT mappings, while a Sandybridge machine running the same > code would prefer to

[Intel-gfx] [PATCH] [RFC] drm/i915: Unmask all render responses for SNB

On SandyBridge in order to receive an event on the RENDER ring, you first must unmask the corresponding bit in the DERRMR (Display Engine Render Response Mask Register). This register is not accessible from a non-secure MI_LOAD_REGISTER_IMM so resort to unmasking all events upon initialisation. Pre

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Unmask all render responses for SNB

On Fri, 23 Sep 2011 11:21:29 +0100, Chris Wilson wrote: > On SandyBridge in order to receive an event on the RENDER ring, you > first must unmask the corresponding bit in the DERRMR (Display Engine > Render Response Mask Register). This register is not accessible from a > non-secure MI_LOAD_REGIS

Re: [Intel-gfx] [PATCH] drm/i915: add missing "break"

Hi 2011/9/23 Keith Packard : > On Fri, 23 Sep 2011 08:13:15 +0530, Jesse Barnes > wrote: >> What I don't understand about the refclk code is that we should be able >> to leave everything enabled and just select the right clock source in >> the DPLL_SEL bits.  But that doesn't seem to help the wa

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Unmask all render responses for SNB

On Fri, 23 Sep 2011 11:21:29 +0100 Chris Wilson wrote: > On SandyBridge in order to receive an event on the RENDER ring, you > first must unmask the corresponding bit in the DERRMR (Display Engine > Render Response Mask Register). This register is not accessible from a > non-secure MI_LOAD_REGIST

Re: [Intel-gfx] [PATCH] drm/i915: Ironlake GPU with VT-d fix

On Fri, 23 Sep 2011 08:37:10 +0100 Chris Wilson wrote: > On Thu, 22 Sep 2011 22:09:39 -0700, Ben Widawsky > wrote: > > On Thu, 22 Sep 2011 21:50:49 -0700 > > Keith Packard wrote: > > > > > On Thu, 22 Sep 2011 17:11:52 -0700, Ben Widawsky > > > wrote: > > > > > > > It requires an additional I

Re: [Intel-gfx] [PATCH 1/3] drm/i915: close PM interrupt masking races in the irq handler

Hi Keith, I think these 3 patches (note that 2/3 has a resend) are ready for -next. I don't think we need this for -fixes or Cc:stable, imo worst case we miss a PM interrupt and hit the WARN. Afaik only Jesse reported seeing that on his ivybrdige machine. 3/3 fixes an unload problem that might le

Re: [Intel-gfx] [PATCH] drm/i915: simplify swapin/out swizzle checking a bit

Hi Keith Small code-cleanup noticed while reviewing functions in that area. Please merge for -next. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists

Re: [Intel-gfx] [PATCH] drm/i915: Defend against userspace creating a gem object with size==0

Hi Keith, This fixes a potential user-triggerable oops (when submitting an execbuf with a zero-length object on a kernel with dmar support). Please merge for -fixes, Cc: stable. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _

Re: [Intel-gfx] [PATCH] drm/i915: add missing "break"

On Fri, 23 Sep 2011 09:06:31 -0300, Paulo Zanoni wrote: > If you look at the patch posted on comment #20 of bug #38750 [0], > you'll see that it checks on the video bios for a field called > "display_clock_mode" and then uses this field in the following code: > + if (dev_priv->display

Re: [Intel-gfx] [PATCH] drm/i915: fix swizzling on gen6+

Hi Keith, This one fixes a testcase from intel-gpu-tools. No actual userspace depends upon it, afaics. The other option is to stop supporting this on gen6+ and return SWIZZLE_UNKOWN. I don't mind either way, I just don't like broken interfaces ;-) Yours, Daniel -- Daniel Vetter Mail: dan...@ffwl

Re: [Intel-gfx] [PATCH 2/5] drm/i915: drop KM_USER0 argument to k(un)map_atomic

Hi Keith, This patch adapts a few leftover callers to the new kmap_atomic api. Found while working in this area. Please merge for -next. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-

Re: [Intel-gfx] [PATCH] drm/i915: add missing "break"

2011/9/23 Keith Packard : > > Can you explain what you tested? Sure. It's an Ironlake laptop so I tested its LVDS, and I also plugged/unplugged the VGA output a few times, checked the value of the DREF_CONTROL register, tried to replace the SOURCE_ENABLE for CK505_ENABLE (to stop the wavy external

Re: [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky wrote: > This makes the code a lot cleaner, and theoretically faster (not many > real world tests use this GL extension). > > Cc: Eric Anholt > Cc: Daniel Vetter > Cc: Mesa Devs > Signed-off-by: Ben Widawsky > --- > src/mesa/drivers/dri/intel/

[Intel-gfx] [PATCH] drm/i915: use DDC_ADDR instead of hard-coding it

Signed-off-by: Matt Turner --- drivers/gpu/drm/i915/intel_modes.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_modes.c b/drivers/gpu/drm/i915/intel_modes.c index 3b26a3b..ab534be 100644 --- a/drivers/gpu/drm/i915/intel_modes.c +++ b/driv

Re: [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Fri, 23 Sep 2011 10:15:02 -0700 Eric Anholt wrote: > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > wrote: > > This makes the code a lot cleaner, and theoretically faster (not > > many real world tests use this GL extension). > > > > Cc: Eric Anholt > > Cc: Daniel Vetter > > Cc: Mesa D

Re: [Intel-gfx] [PATCH] drm/i915: use DDC_ADDR instead of hard-coding it

On Fri, 23 Sep 2011 13:18:40 -0400, Matt Turner wrote: > Signed-off-by: Matt Turner We should just make intel_ddc_probe() a wrapper around drm_probe_ddc(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-g

Re: [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Fri, 23 Sep 2011 11:46:41 -0700 Ben Widawsky wrote: > On Fri, 23 Sep 2011 10:15:02 -0700 > Eric Anholt wrote: > > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > > wrote: > > > This makes the code a lot cleaner, and theoretically faster (not > > > many real world tests use this GL exte

Re: [Intel-gfx] [PATCH] drm/i915: Ironlake GPU with VT-d fix

On Fri, 23 Sep 2011 08:38:49 -0700, Ben Widawsky wrote: > On Fri, 23 Sep 2011 08:37:10 +0100 > Chris Wilson wrote: > > > On Thu, 22 Sep 2011 22:09:39 -0700, Ben Widawsky > > wrote: > > > On Thu, 22 Sep 2011 21:50:49 -0700 > > > Keith Packard wrote: > > > > > > > On Thu, 22 Sep 2011 17:11:52 -

Re: [Intel-gfx] CRT not detected via hotplug on resume

Am Donnerstag 22 September 2011, 16:33:46 schrieb Keith Packard: > On Thu, 22 Sep 2011 10:36:12 +0200, Rainer Dorsch wrote: > > This kind of output I do not see in the syslog anymore during regular > > > operation now (is that the 10-second polling?): > Yes. So, the patch is definitely included.

Re: [Intel-gfx] [PATCH] drm/i915: add missing "break"

On Fri, 23 Sep 2011 09:15:05 -0700, Keith Packard wrote: > What I didn't find there was any mention of the display_clock_mode > field; perhaps jbarnes has newer VBIOS sources or actual BDB > documentation. iirc display_clock_mode was found in the Capella VBIOS assembly, so indeed comparatively an

Re: [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Fri, 23 Sep 2011 11:56:59 -0700 Ben Widawsky wrote: > On Fri, 23 Sep 2011 11:46:41 -0700 > Ben Widawsky wrote: > > > On Fri, 23 Sep 2011 10:15:02 -0700 > > Eric Anholt wrote: > > > > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > > > wrote: > > > > This makes the code a lot cleaner,

Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Unmask all render responses for SNB

On Fri, 23 Sep 2011 08:23:14 -0700, Ben Widawsky wrote: > On Fri, 23 Sep 2011 11:21:29 +0100 > Chris Wilson wrote: > > > On SandyBridge in order to receive an event on the RENDER ring, you > > first must unmask the corresponding bit in the DERRMR (Display Engine > > Render Response Mask Register

[Intel-gfx] [PATCH 0/4 v2] Nonblocking maps

After going back and forth many times, I think Daniel and I have agreed on the solution for non-blocking maps. This new interface adds a new call to map buffers non-blocking if possible. In actuality it may block, but it will track if the buffer needs flushing or not and does the right thing for t

[Intel-gfx] [PATCH v2] drm/i915: IOCTL to query the cache level of a BO.

Querying a BO's cache level can help clients wishing to map the buffer. For example, an Ironlake machine could query the buffer to determine it should use GTT mappings, while a Sandybridge machine running the same code would prefer to use regular CPU mapped buffers since the cache is coherent. Cc:

[Intel-gfx] [PATCH v2] intel: non-blocking mmaps on the cheap

From: Daniel Vetter This adds a new mode to map gem objects in a non-blocking way. The new kernel interface required to get the caching level/coherency is not yet wired up. All the code to transparently choose between gtt mappings or (if coherent) cpu mappings is already in place, though. To ma

[Intel-gfx] [PATCH v2 1/2] i965: Cleanup MapRangeBuffer

Clean the code up, and always use a BO when creating a new buffer. I've not seen any regressions but haven't yet tried this on < Gen6. Cc: Chad Versace Cc: Eric Anholt Cc: Mesa Devs Signed-off-by: Ben Widawsky --- src/mesa/drivers/dri/intel/intel_buffer_objects.c | 86 +

[Intel-gfx] [PATCH v2 2/2] i965: Add calls to nonblocking maps

When mapping a range of a buffer that has the UNSYNCHRONIZED_BIT, and is only writable, we can take some shortcuts and let people shoot their feet. Cc: Eric Anholt Cc: Mesa Devs Signed-off-by: Ben Widawsky --- src/mesa/drivers/dri/intel/intel_buffer_objects.c | 35 ++-- src/m

Re: [Intel-gfx] CRT not detected via hotplug on resume

On Fri, 23 Sep 2011 21:05:37 +0200, Rainer Dorsch wrote: > Are there any other data I could gather to figure out what is going > wrong? Oh, have we gotten register dumps from a working vs non-working resume? git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools Let's hope there's