Re: [Intel-gfx] [PATCH] drm/i915: Do not invalidate obj-pages under mempressure

2015-02-20 Thread Sean V Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/11/2015 05:02 AM, Daniel Vetter wrote:
 On Wed, Feb 11, 2015 at 1:55 AM, Sean V Kelley sea...@posteo.de
 wrote:
 No corruption seen.  I will add reloc domains to my growing audit
 list.
 
 One more for the libva audit list:
 
 If you do any ioctl directly, please make sure that you clear the 
 ioctl structure with memset(arg, 0, sizeof(arg)); or similar. 
 Otherwise when we extended them in upstream (which we're just
 doing, the kernel 0-fills the new fields automatically) it'll break
 because after a recompile there's now garbage in the new fields.
 
 I just spent a while fixing up libdrm ;-) -Daniel
 

Cleaned up the hybrid driver.  Found numerous instances of the
wrong reloc domain assignments, e.g., write_domain of 0. I've since
verified it was the root cause of the run 2 run issue. Also cleaned up
ioctl and structure clearing.

Thanks,

Sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU57L/AAoJEGScDsMo8QYOFsIQANHSmmYUG5JSqsmewCDO1zHk
dh2h56x5oCIooJ2mOh9lcWTRpVbE4uv6HOt6WfThb4dP11Yg5LlOZA1uR65iniIy
9gi2vUotuajm9cOdXKVXCbQBuymR0rKJuRb74e73jk/u5QpOv/zNtThXOG7FfUVu
p1DpoVuh8iLGexwAd+6UrCOze5hWfCuh+9t9jTZ8Yr0pgSiRsGClX1mW8vUD4+99
7h5VGonr3tKYqHNZBtneaTcmRkVBtuZ/RBGr5FOnzP1VKIXidgt2t4ID33nZmjsx
rJjzQfh408qniBr9L7zIIDUZMiiAucIRm1+4eQ1b+yA9pYkXQfrs/lA9dH80IjAw
iWFS+IX7xUCpKZzLB38+dIV/Nsn0nxoF5N1ptz4RMKoeXJVWsRS72jgCjlrE5w4R
dnyodU7nlmdcNoeGcDEhcN5Jek7OPYoJLgaC100wu6yDZKJ/2CXJ6XwyORWQ7GU1
UWyqOuam84DJqiwzwkLl6Q9Ur7oC8S8jUIFLqRk/1PZOesu90/yNoJUByLQMMZbl
WzUMGdV4D18+uTHhmWGPruCYHLMgRXKVlT/diKH1q5aBOvtP4xeANn+0GSw+E3OZ
TN1TGDW/q8U0uN1CDk5hTIDgiJX0Eo9an0CsJ2yZL3K+J56+e6QUY6EPrU/ctqp0
QbT5eI44/dZX2Xmf/kc7
=24vy
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not invalidate obj-pages under mempressure

2015-02-10 Thread Sean V Kelley 


On 02/09/2015 08:46 AM, Chris Wilson wrote:
 On Sun, Feb 08, 2015 at 03:27:13PM -0800, Sean V Kelley wrote:


 On 01/16/2015 08:05 PM, Daniel Vetter wrote:
 On Thu, Jan 15, 2015 at 08:44:00PM +, Chris Wilson wrote:
 On Thu, Jan 15, 2015 at 08:36:15PM +0100, Daniel Vetter wrote:
 On Wed, Jan 14, 2015 at 9:34 PM, Chris Wilson
 ch...@chris-wilson.co.uk wrote:
 This (partially) reverts

 commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd Author: Chris
 Wilson ch...@chris-wilson.co.uk Date:   Tue Mar 25 13:23:06
 2014 +

 drm/i915: Invalidate our pages under memory pressure

 Shouldn't we also revert the hunk in i915_gem_free_objects?
 Without the truncate vs. invalidate disdinction it seems to
 have lost it's reason for existence ...

 No, setting MADV_DONTNEED has other nice properties during
 put_pages() - I think it is useful in its own right, for example
 that is where my page stealing code goes...

 Well right now I can't make sense of this bit any more (tbh I
 didn't with the other code either, but overlooked that while
 reviewing). When it's just there for future work but atm dead code
 I prefer for it to get removed. -Daniel


 So can we also revert the hunk in i915_gem_free_objects?  I would like
 to get this patch merged, it looks like that is the primary concern.
 
 A problem I have is that the test written to hit the exact condition
 considered in the changelog does not ellict the bug. 
 
 Can you test whether
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 39e032615b31..6269204ba16f 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -1030,6 +1030,7 @@ i915_gem_execbuffer_move_to_active(struct list_head 
 *vmas,
 /* update for the implicit flush after a batch */
 obj-base.write_domain = ~I915_GEM_GPU_DOMAINS;
 }
 +   obj-dirty = 1;
 if (entry-flags  EXEC_OBJECT_NEEDS_FENCE) {
 i915_gem_request_assign(obj-last_fenced_req, req);
 if (entry-flags  __EXEC_OBJECT_HAS_FENCE) {
 
 makes the bug go away. If so, I think the bug is in the caller not
 setting reloc domains correctly.

I think you may be right.  This implies a caller issue, because
essentially you are forcing a write back here as if it were in the
write domain.

No corruption seen.  I will add reloc domains to my growing audit list.

via

drm-intel-nightly: 2014y-12m-08d-22h-24m-34s UTC integration manifest


diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0c25f62..4cb2755 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -970,6 +970,8 @@ i915_gem_execbuffer_move_to_active(struct list_head
*vmas,
/* update for the implicit flush after a batch */
obj-base.write_domain = ~I915_GEM_GPU_DOMAINS;
}
+
+   obj-dirty = 1;
if (entry-flags  EXEC_OBJECT_NEEDS_FENCE) {
i915_gem_request_assign(obj-last_fenced_req, req);
if (entry-flags  __EXEC_OBJECT_HAS_FENCE) {


Sean


 -Chris
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not invalidate obj-pages under mempressure

2015-02-09 Thread Sean V Kelley 


On 02/09/2015 08:46 AM, Chris Wilson wrote:
 On Sun, Feb 08, 2015 at 03:27:13PM -0800, Sean V Kelley wrote:
 
 
 On 01/16/2015 08:05 PM, Daniel Vetter wrote:
 On Thu, Jan 15, 2015 at 08:44:00PM +, Chris Wilson wrote:
 On Thu, Jan 15, 2015 at 08:36:15PM +0100, Daniel Vetter
 wrote:
 On Wed, Jan 14, 2015 at 9:34 PM, Chris Wilson 
 ch...@chris-wilson.co.uk wrote:
 This (partially) reverts
 
 commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd Author:
 Chris Wilson ch...@chris-wilson.co.uk Date:   Tue Mar
 25 13:23:06 2014 +
 
 drm/i915: Invalidate our pages under memory pressure
 
 Shouldn't we also revert the hunk in
 i915_gem_free_objects? Without the truncate vs. invalidate
 disdinction it seems to have lost it's reason for existence
 ...
 
 No, setting MADV_DONTNEED has other nice properties during 
 put_pages() - I think it is useful in its own right, for
 example that is where my page stealing code goes...
 
 Well right now I can't make sense of this bit any more (tbh I 
 didn't with the other code either, but overlooked that while 
 reviewing). When it's just there for future work but atm dead
 code I prefer for it to get removed. -Daniel
 
 
 So can we also revert the hunk in i915_gem_free_objects?  I would
 like to get this patch merged, it looks like that is the primary
 concern.
 
 A problem I have is that the test written to hit the exact
 condition considered in the changelog does not ellict the bug.
 
 Can you test whether
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index
 39e032615b31..6269204ba16f 100644 ---
 a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1030,6 +1030,7 @@
 i915_gem_execbuffer_move_to_active(struct list_head *vmas, /*
 update for the implicit flush after a batch */ 
 obj-base.write_domain = ~I915_GEM_GPU_DOMAINS; } +
 obj-dirty = 1; if (entry-flags  EXEC_OBJECT_NEEDS_FENCE) { 
 i915_gem_request_assign(obj-last_fenced_req, req); if
 (entry-flags  __EXEC_OBJECT_HAS_FENCE) {
 
 makes the bug go away. If so, I think the bug is in the caller not 
 setting reloc domains correctly. -Chris

Sure,  I will take a look.

Thanks,

Sean

 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not invalidate obj-pages under mempressure

2015-02-08 Thread Sean V Kelley 


On 01/16/2015 08:05 PM, Daniel Vetter wrote:
 On Thu, Jan 15, 2015 at 08:44:00PM +, Chris Wilson wrote:
 On Thu, Jan 15, 2015 at 08:36:15PM +0100, Daniel Vetter wrote:
 On Wed, Jan 14, 2015 at 9:34 PM, Chris Wilson
 ch...@chris-wilson.co.uk wrote:
 This (partially) reverts
 
 commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd Author: Chris
 Wilson ch...@chris-wilson.co.uk Date:   Tue Mar 25 13:23:06
 2014 +
 
 drm/i915: Invalidate our pages under memory pressure
 
 Shouldn't we also revert the hunk in i915_gem_free_objects?
 Without the truncate vs. invalidate disdinction it seems to
 have lost it's reason for existence ...
 
 No, setting MADV_DONTNEED has other nice properties during
 put_pages() - I think it is useful in its own right, for example
 that is where my page stealing code goes...
 
 Well right now I can't make sense of this bit any more (tbh I
 didn't with the other code either, but overlooked that while
 reviewing). When it's just there for future work but atm dead code
 I prefer for it to get removed. -Daniel


So can we also revert the hunk in i915_gem_free_objects?  I would like
to get this patch merged, it looks like that is the primary concern.

Thanks,

Sean

 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do not invalidate obj-pages under mempressure

2015-01-14 Thread Sean V Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 01/14/2015 04:55 PM, Daniel Vetter wrote:
 On Wed, Jan 14, 2015 at 08:34:31PM +, Chris Wilson wrote:
 This (partially) reverts
 
 commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd Author: Chris
 Wilson ch...@chris-wilson.co.uk Date:   Tue Mar 25 13:23:06
 2014 +
 
 drm/i915: Invalidate our pages under memory pressure
 
 It appears given the right workload, that pages which are swapped
 out more than once are incorrectly invalidated and discarded. I
 had presumed that the swapin would mark the pages dirty again and
 so preserve them against the next cycle of invalidation - that
 appears to be false, and leads to memory corruption (even leak of
 stale pages to userspace).
 
 Reported-by: Sean V Kelley sean.v.kel...@intel.com 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Sean V
 Kelley sean.v.kel...@intel.com Cc: sta...@vger.kernel.org
 
 Hm, scary. Do we have a testcase for this (might need a
 correctness version for some of the swap thrashing tests maybe). 
 -Daniel

I can put together a test case we use with a media runtime workload
for an EU that we could add to igt.  Also this appears to be something
that has been also encountered on BDW during an Android kernel team
port that from what I can tell was patched locally (internally) and
not shared upstream.  I stumbled upon it only after getting Chris'
help with this patch.

Sean


 
 --- drivers/gpu/drm/i915/i915_gem.c | 23 ++- 
 1 file changed, 2 insertions(+), 21 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c
 b/drivers/gpu/drm/i915/i915_gem.c index
 4d453490596e..b06f051a73de 100644 ---
 a/drivers/gpu/drm/i915/i915_gem.c +++
 b/drivers/gpu/drm/i915/i915_gem.c @@ -1947,26 +1947,6 @@
 i915_gem_object_truncate(struct drm_i915_gem_object *obj) 
 obj-madv = __I915_MADV_PURGED; }
 
 -/* Try to discard unwanted pages */ -static void 
 -i915_gem_object_invalidate(struct drm_i915_gem_object *obj) -{ -
 struct address_space *mapping; - - switch (obj-madv) { - case
 I915_MADV_DONTNEED: - i915_gem_object_truncate(obj); - case
 __I915_MADV_PURGED: - return; - } - - if (obj-base.filp ==
 NULL) - return; - - mapping =
 file_inode(obj-base.filp)-i_mapping, -
 invalidate_mapping_pages(mapping, 0, (loff_t)-1); -} - static
 void i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
 *obj) { @@ -2029,7 +2009,8 @@ i915_gem_object_put_pages(struct
 drm_i915_gem_object *obj) ops-put_pages(obj); obj-pages =
 NULL;
 
 - i915_gem_object_invalidate(obj); + if
 (i915_gem_object_is_purgeable(obj)) +
 i915_gem_object_truncate(obj);
 
 return 0; } -- 2.1.4
 
 ___ Intel-gfx mailing
 list Intel-gfx@lists.freedesktop.org 
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUtxW9AAoJEGScDsMo8QYOlZkP/3IbGTlfw4aj37nlClMA+JpO
qHDbYi9evALt7NkiE5UcVz+LJwPZ/FLZR+Q8w5m/4NqPDVbGCDFDEovoJx/MKWgA
u6MuUrkuFC5KjGFiYZFuP/+EsXKMblNKRv4xWeWoPWgwlvd9ZYw1rSNVPLqkgIPu
RtvSJAsKdehvbl7Y4VyKDjKn9gUp58qKE9P/setx3u1vc/xbufKRACkdp9QLDzBm
s0HjmgIkXRQr1n7L4tUmZiYB9igZnapjxzyX2FazTQhHQFthUMu7pVJaP6MYLuSJ
Dr9CidL/DC4r4sciaOUhLlA5rD0PJ5AMrS9ZN6wf50gN1JWYYIgdl51TLkqFMjou
EpTv442qzjO+Mi5mY8YMheruDV/voGU7mc/11i3Ng9kSBdkv7kfVhcnSLsJsGCxw
4mI3fHOdSySIG+ZgM5Fw7XmFpXypbcqTZ99qbQkMoyQoXtbn96s1wCWp4j3qHHQ1
hQN6lgU3eb35gafmJ18qtEYouUahtRtB1SHOppGiLMuEaFcqr4hvFoq7fDl7VtQa
RqnoOyDcwUEht7btPLaRcnyd7kUl0fTcwmTbeFLo5hrOuv5Ke08ms9aMfAvk+cR7
mYO9OzxkvUJAgjPn9yCLR70fuDVGQa3rbM31LY6QBEGxfvjG2qPe2eFw5XdBkgTV
iCREv8mvFVotVg0vFAJB
=RERA
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Disable hpd for disabled eDP ports

2015-01-12 Thread Sean V Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 01/09/2015 04:21 AM, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 My BSW has a nasty problem where it generates tons of spurious hpd
 interrupts when the eDP display is disabled. The best solution
 seems to be to disable hpd for eDP ports when the port is disabled
 since we don't care about long hpds anyway and short hpds are only
 relevant while the link is up and running.
 

How did these spurious interrupts affect your system?  Did you see
this on both B and C Stepping?

Sean



 This series tries to implement that, and I've included a few
 random fixes/refactorings to the hpd code as well.
 
 Ville Syrjälä (7): drm/i915: Make hpd arrays big enough to avoid
 out of bounds access drm/i915: Remove I915_HAS_HOTPLUG() check from
 i915_hpd_irq_setup() drm/i915: Don't register HDMI connectors for
 eDP ports on VLV/CHV drm/i915: Don't pretend SDVO hotplug works on
 915 drm/i915: Set intel_connector-polled to DRM_CONNECTOR_POLL_HPD
 when appropriate drm/i915: Unify hpd setup between init and hpd
 storm handling drm/i915: Disable HPD for disabled eDP ports
 
 drivers/gpu/drm/i915/i915_irq.c  | 172
 --- 
 drivers/gpu/drm/i915/intel_crt.c |   4 +- 
 drivers/gpu/drm/i915/intel_display.c |   6 +- 
 drivers/gpu/drm/i915/intel_dp.c  |  18  
 drivers/gpu/drm/i915/intel_dp_mst.c  |   2 + 
 drivers/gpu/drm/i915/intel_drv.h |   3 + 
 drivers/gpu/drm/i915/intel_hdmi.c|   2 + 
 drivers/gpu/drm/i915/intel_sdvo.c|   4 + 8 files changed, 136
 insertions(+), 75 deletions(-)
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUtGrNAAoJEGScDsMo8QYOmWsQAMORWtlFc8743+LrJ6y6+rX0
+uF3u/v6F+nQr7ijDqMAGuLfCHc04MFJl+uFzCI4p6/DoGTtL9s98EjLlLq/epGI
GuRimDfAx/VsYz18JIByXTbslduoXjq5Cf2C+6atN+AJ3zFEx+j9CRuDcniFVioJ
wufpSdp+p3ruLSSIj/s2IiaiveKUZ2mROxIoiJsfBeS0vvbNCVh87JlQQCJ21xlZ
L6kGGQq7n7lTa6uIxUo9JoU00yRvB3WsPxlSI8K8aDiYIiYxG+ovchUNCj7s0+IE
ePBdYPaZpA4i6/i8HPqXlPveAq8Y4rA2TX6dICd5SRok8PAz7lVVKoMSwS59BMX7
rq9dSFTPkgbU5iwATcmIqQ1plvFAwDpixJ/xpQWjAwm+JF85mW/1GEoPfpImERAY
3CQvi8fkmdVhkcwOQ0SXRMzkIzVjROVkG5PABwgDw4LSFzdP84x07RHCH6omSRIa
NH8fO3cLYWGRmgc1UtP5rW5gBx6J/c+AMtjz74ePoaQOv7H6WaNWEnRnebyXqFo5
RT3Gk0QLS79FFBApZKm2XsWa7Qj6XTKDKPShQME/5kUF5a6yl/arkYyfRVmiNcPg
LWWjS6zUAXm0NjwB24pMuAtugIAGp8D13bWxFQ2501cwDxXHNUK7i9ppdl08A2A7
agVTLHHrEhf8LxXS9AWv
=1UId
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH v4 3/4] ipvr: user mode helper for ipvr drm driver

2015-01-07 Thread Sean V Kelley 
From: Yao Cheng yao.ch...@intel.com

add usermode helper for the ipvr kernel driver.
test_ioctl: test kernel driver by directly ioctl

v2:
take Emil's comments
- correctly align ipvr_drm.h

v3:
take Daniel Vetter and Daniel Stone's comments, and implement PRIME
- correctly align ipvr_drm.h
- use __u32 family in ipvr_drm.h
- rip out explicit fence from libdrm_ipvr
- implemented PRIME support
- add relocation fixup implementation

v4
bug fixing and add stress test tool
- rename ipvr/test_ioctl.c to ipvr/test_ipvr.c
- implement parallel ioctl stress test in test_ipvr.c
- implement parallel libdrm stress test in test_ipvr.c
- update ipvr_drm.h to keep consistent with kernel change
- remove unused buffer_ofs/alloc_size/ext_handle from struct 
drm_ipvr_bo
- remove unused arguments for some public functions
- fix a few foolish copy-paste bugs
- fix 32bit compiling issue

Signed-off-by: Yao Cheng yao.ch...@intel.com
Signed-off-by: Sean V Kelley sea...@posteo.de
---
 Makefile.am|6 +-
 Makefile.sources   |1 +
 configure.ac   |   26 +-
 include/drm/ipvr_drm.h |  259 +++
 ipvr/Makefile.am   |   57 +++
 ipvr/Makefile.sources  |5 +
 ipvr/ipvr_bufmgr.h |  132 ++
 ipvr/ipvr_bufmgr_gem.c | 1188 
 ipvr/libdrm_ipvr.pc.in |   11 +
 ipvr/test_ipvr.c   |  919 +
 10 files changed, 2602 insertions(+), 2 deletions(-)
 create mode 100644 include/drm/ipvr_drm.h
 create mode 100644 ipvr/Makefile.am
 create mode 100644 ipvr/Makefile.sources
 create mode 100644 ipvr/ipvr_bufmgr.h
 create mode 100644 ipvr/ipvr_bufmgr_gem.c
 create mode 100644 ipvr/libdrm_ipvr.pc.in
 create mode 100644 ipvr/test_ipvr.c

diff --git a/Makefile.am b/Makefile.am
index 3cb516c..035d937 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -33,6 +33,10 @@ if HAVE_INTEL
 INTEL_SUBDIR = intel
 endif
 
+if HAVE_IPVR
+IPVR_SUBDIR = ipvr
+endif
+
 if HAVE_NOUVEAU
 NOUVEAU_SUBDIR = nouveau
 endif
@@ -57,7 +61,7 @@ if HAVE_TEGRA
 TEGRA_SUBDIR = tegra
 endif
 
-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) 
$(TEGRA_SUBDIR) tests man
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) 
$(TEGRA_SUBDIR) tests man
 
 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/Makefile.sources b/Makefile.sources
index 566f7b5..819a0cb 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \
include/drm/drm_mode.h \
include/drm/drm_sarea.h \
include/drm/i915_drm.h \
+   include/drm/ipvr_drm.h \
include/drm/mach64_drm.h \
include/drm/mga_drm.h \
include/drm/nouveau_drm.h \
diff --git a/configure.ac b/configure.ac
index c88a1c5..9fea4db 100644
--- a/configure.ac
+++ b/configure.ac
@@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel,
  [Enable support for intel's KMS API (default: auto)]),
  [INTEL=$enableval], [INTEL=auto])
 
+AC_ARG_ENABLE(ipvr,
+ AS_HELP_STRING([--disable-ipvr],
+ [Enable support for valeyview's IPVR hardware decode (default: 
auto)]),
+ [IPVR=$enableval], [IPVR=auto])
+
 AC_ARG_ENABLE(radeon,
  AS_HELP_STRING([--disable-radeon],
  [Enable support for radeon's KMS API (default: auto)]),
@@ -209,7 +214,7 @@ if test x$drm_cv_atomic_primitives = xlibatomic-ops; 
then
AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have libatomic-ops-dev 
installed])
 fi
 
-if test x$INTEL != xno -o x$RADEON != xno -o x$NOUVEAU != xno; then
+if test x$INTEL != xno -o x$IPVR != xno -o x$RADEON != xno -o 
x$NOUVEAU != xno; then
if test x$drm_cv_atomic_primitives = xnone; then
if test x$INTEL != xauto; then
if test x$INTEL != xno; then
@@ -219,6 +224,14 @@ if test x$INTEL != xno -o x$RADEON != xno -o 
x$NOUVEAU != xno; then
AC_MSG_WARN([Disabling libdrm_intel. It depends on 
atomic operations, which were not found for your compiler/cpu. Try compiling 
with -march=native, or install the libatomics-op-dev package.])
INTEL=no
fi
+   if test x$IPVR != xauto; then
+   if test x$IPVR != xno; then
+   AC_MSG_ERROR([libdrm_ipvr depends upon atomic 
operations, which were not found for your compiler/cpu. Try compiling with 
-march=native, or install the libatomics-op-dev package, or, failing both of 
those, disable support for IPVR by passing --disable-ipvr to ./configure])
+   fi
+   else
+   AC_MSG_WARN([Disabling libdrm_ipvr. It depends on 
atomic operations

[Intel-gfx] [RFC PATCH v4 4/4] tests/drv_module_reload: add ipvr support

2015-01-07 Thread Sean V Kelley 
From: Yao Cheng yao.ch...@intel.com

on vlv, if ipvr is installed, it need be manually unloaded before
i915, otherwise user might run into use-after-free issue.

v2:
added this patch per Daniel's comment

v3:
no change

Signed-off-by: Yao Cheng yao.ch...@intel.com
Signed-off-by: Sean V Kelley sea...@posteo.de
---
 tests/drv_module_reload | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/drv_module_reload b/tests/drv_module_reload
index 5cbff89..82c67bd 100755
--- a/tests/drv_module_reload
+++ b/tests/drv_module_reload
@@ -24,6 +24,14 @@ rmmod snd_hda_intel  /dev/null
 
 #ignore errors in ips - gen5 only
 rmmod intel_ips  /dev/null
+
+# vlv only for now:
+# due to platform device model limitation, need unload ipvr manually
+if lsmod | grep ipvr  /dev/null ; then
+   echo Need manually unload ipvr.ko.
+   rmmod ipvr
+fi
+
 rmmod i915
 #ignore errors in intel-gtt, often built-in
 rmmod intel-gtt  /dev/null
@@ -31,6 +39,11 @@ rmmod intel-gtt  /dev/null
 rmmod drm_kms_helper  /dev/null
 rmmod drm  /dev/null
 
+if lsmod | grep ipvr  /dev/null ; then
+   echo WARNING: ipvr.ko still loaded!
+   exit 1
+fi
+
 if lsmod | grep i915  /dev/null ; then
echo WARNING: i915.ko still loaded!
exit 1
@@ -41,6 +54,9 @@ fi
 modprobe i915
 echo 1  /sys/class/vtconsole/vtcon1/bind
 
+# for vlv, load VED driver
+modprobe ipvr
+
 modprobe snd_hda_intel
 
 # try to run something
-- 
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH V4 1/4] drm/i915: add i915_ved.c to setup bridge for VED

2015-01-07 Thread Sean V Kelley 
From: Yao Cheng yao.ch...@intel.com

Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver (a standalone drm driver) probes the VED device and
creates a new dri card on install.
Currently only supports VED on valleyview.
Kerneldoc is updated for i915_ved.c.

v2:
take Daniel  Jani's comments
- extract change to new file i915_ved.c
- add kerneldoc
- change 'ipvr-ved' to 'ipvr-vlv-ved' for extensibility
- unregister platdev before irq_free_desc
- add WARN_ON(!intel_irqs_enabled) in irq init code
- remove unnecessary trace point
- remove unnecessary BUG_ON

v3:
take Ville's comments and VED PRIME support
- add HAS_VED() check
- add ved struct to make code neat
- no need to check platform in vlv_irq_handler
- i915_reg.h update
- no need to kmalloc for small amount of resource
- remove unnecessary REG resource
- follow vlv_display_irqs_install() to implement VED mask/unmask
- workaround nommu_map_sg issue by set dma_mask to support VED PRIME.

v4:
take Bob's comments
- add more detail on the use-after-free issue description
- mask VED irq before removing the child device

Signed-off-by: Yao Cheng yao.ch...@intel.com
Signed-off-by: Sean V Kelley sea...@posteo.de
---
 Documentation/DocBook/drm.tmpl  |   5 +
 drivers/gpu/drm/i915/Makefile   |   3 +
 drivers/gpu/drm/i915/i915_dma.c |  11 ++
 drivers/gpu/drm/i915/i915_drv.h |  12 ++
 drivers/gpu/drm/i915/i915_irq.c |   2 +
 drivers/gpu/drm/i915/i915_reg.h |   4 +
 drivers/gpu/drm/i915/i915_ved.c | 270 
 7 files changed, 307 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_ved.c

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 56e2a9b..9db989c 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3867,6 +3867,11 @@ int num_ioctls;/synopsis
 !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
 !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
   /sect2
+  sect2
+titleVED video core integration/title
+!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
+!Idrivers/gpu/drm/i915/i915_ved.c
+  /sect2
 /sect1
 sect1
   titleDisplay Hardware Handling/title
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e4083e4..7d0bbfa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -84,6 +84,9 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_dma.o \
  i915_ums.o
 
+# VED for VLV
+i915-y += i915_ved.o
+
 obj-$(CONFIG_DRM_I915)  += i915.o
 
 CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 887d88f..cd96618 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -828,6 +828,13 @@ int i915_driver_load(struct drm_device *dev, unsigned long 
flags)
if (IS_GEN5(dev))
intel_gpu_ips_init(dev_priv);
 
+   if (HAS_VED(dev)) {
+   ret = vlv_setup_ved(dev);
+   if (ret  0) {
+   DRM_ERROR(failed to setup VED bridge: %d\n, ret);
+   }
+   }
+
intel_runtime_pm_enable(dev_priv);
 
return 0;
@@ -870,6 +877,10 @@ int i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
 
+   if (HAS_VED(dev)) {
+   vlv_teardown_ved(dev);
+   }
+
ret = i915_gem_suspend(dev);
if (ret) {
DRM_ERROR(failed to idle hardware: %d\n, ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 502a01b..aa39d47 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1773,6 +1773,12 @@ struct drm_i915_private {
 
uint32_t bios_vgacntr;
 
+   /* necessary resource sharing with ved driver. */
+   struct {
+   struct platform_device *platdev;
+   int irq;
+   } ved;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct {
int (*do_execbuf)(struct drm_device *dev, struct drm_file *file,
@@ -2305,6 +2311,7 @@ struct drm_i915_cmd_table {
 IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
 #define HAS_RC6(dev)   (INTEL_INFO(dev)-gen = 6)
 #define HAS_RC6p(dev)  (INTEL_INFO(dev)-gen == 6 || IS_IVYBRIDGE(dev))
+#define HAS_VED(dev)   (INTEL_INFO(dev)-is_valleyview  IS_GEN7(dev))
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
@@ -2894,6 +2901,11 @@ void

[Intel-gfx] [RFC PATCH v4 0/4] drm driver for VED in Intel GPU

2015-01-07 Thread Sean V Kelley 

drm/ipvr is a new GEM driver for VED (PowerVR's VPU integrated in Intel GPU),
which extends video capability.
A new Kconfig added for building ipvr driver:

  CONFIG_DRM_IPVR: Build option for ipvr module

The driver name ipvr means the PowerVR's core wrapped by Intel. The
PowerVR VPUs are also integrated by non-i915 platforms such as GMA500, so we
keep ipvr driver and i915 driver separated and independent to each other. To
achieve this we do the minimum change in i915: i915_ved.c added for setting
up the bridge between VED and i915, kerneldoc also updated.

User mode drm helper libdrm_ipvr.so and simple ioctl/execute test is
included.

one test script drv_module_reload in i-g-t also updated to support ipvr
loading and unloading. Due to restriction in Linux platform device model, we
have to manually unload ipvr before unloading i915.

Yao Cheng (4):
[1/4] drm/i915: add i915_ved.c to setup bridge for VED
[2/4] drm/ipvr: drm driver for VED
[3/4] libdrm/ipvr: user mode helper for ipvr drm driver
[4/4] i-g-t: tests/drv_module_reload: add ipvr support

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392

2014-10-16 Thread Sean V Kelley 
On Thu, Oct 16, 2014 at 7:36 AM, Cheng, Yao yao.ch...@intel.com wrote:
 Hi Daniel, this patch
 [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver
 adds the ipvr part into libdrm.
 Do you mean this patch is missing?

The umd (ipvr_vaapi_driver) is needed to fully exercise the APIs
exposed.  That code is in flight and I'll work with you to get it into
the repos.

Sean


 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
 Vetter
 Sent: Thursday, October 16, 2014 7:46 PM
 To: Cheng, Yao
 Cc: intel-gfx@lists.freedesktop.org; Jiang, Fei; dri-
 de...@lists.freedesktop.org; Vetter, Daniel
 Subject: Re: [Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392

 On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
  drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates VP8
 video decoding.
  The driver name ipvr means the PowerVR's IP wrapped by Intel. In the
 future, ipvr may support other platforms such as Merrifield.
  Code is placed at drivers/gpu/drm/ipvr and the following two new Kconfig
 are added:
CONFIG_DRM_IPVR: Build option for ipvr module
CONFIG_DRM_IPVR_EC: Experimental feature of error concealment
 
  User mode drm helper libdrm_ipvr.so and simple test are also included.

 git repos/patches for the userspace side seems to be missing.
 -Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Sean V. Kelley sean.v.kel...@intel.com
Open Source Technology Center / SSG
Intel Corp.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392

2014-10-14 Thread Sean V Kelley 
On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
thierry.red...@gmail.com wrote:
 On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
 drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates VP8 
 video decoding.
 The driver name ipvr means the PowerVR's IP wrapped by Intel. In the 
 future, ipvr may support other platforms such as Merrifield.
 Code is placed at drivers/gpu/drm/ipvr and the following two new Kconfig are 
 added:
   CONFIG_DRM_IPVR: Build option for ipvr module
   CONFIG_DRM_IPVR_EC: Experimental feature of error concealment

 User mode drm helper libdrm_ipvr.so and simple test are also included.

 Yao Cheng (3):
  [1/3] drm/i915: add vxd392 bridge in i915 on baytrail
  [2/3] drm/ipvr: ipvr drm driver for vxd392

 If this is Intel-specific, why doesn't it live under the i915 driver?

It is an entirely unrelated HW IP block, VXD392.  Nothing to do with
GEN aside from DRM based.

Sean


 Thierry

 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx




-- 
Sean V. Kelley sean.v.kel...@intel.com
Open Source Technology Center / SSG
Intel Corp.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915: Regression: +4W in idle power use on Macbook Pro 15 (late 2013)

2014-08-28 Thread Sean V Kelley 
On Mon, Aug 25, 2014 at 3:22 AM, Jani Nikula jani.nik...@intel.com wrote:


 [just moving from lkml to intel-gfx for a better fitting audience]

 On Mon, 25 Aug 2014, Jani Nikula jani.nik...@intel.com wrote:
  On Fri, 22 Aug 2014, Eric Rannaud eric.rann...@gmail.com wrote:
  Hi,
 
  Between 3.15.4 and 3.15.8, there was an increase in idle power
 consumption on
  Apple Macbook Pro 15 (late 2013) on a freshly booted system (no wifi
 driver
  loaded; brightness set to 4/100; X running; no desktop environment,
 except
  Awesome), from 6.5W to about 10.5W, as reported by powertop.
 
  In the stable tree, it bisects to:
  commit f4db98240ac2c6d9d2118c6f82d483ff5293f1ed
  Author: Chris Wilson ch...@chris-wilson.co.uk
  Date:   Fri Jun 6 10:37:11 2014 +0100
 
  drm/i915: Disable FBC by default also on Haswell and later
 
  commit 0368920e51ae0cded0eb518c340a4dd17764d461 upstream.
 
  It causes black screen on bootup and is approximately 100x
  slower than
  running with FBC disabled, so the GPU runs at a high
  frequency for much
  longer - completely contrary to the power saving claims.
  It also still
  has mutex deadlocks in multi-head scenarios, which can lead
 to a
  system/X lockup. These bugs were known before FBC was
  enabled by default
  on Haswell and still have not been fixed.
 
  The issue is still present in Linus' tree (v3.17-rc1-22-g480cadc2b7e0).
 
  With a 75Wh battery, that's a significant loss in battery life in
 normal use.
 
  I'll be happy to help test any potential fix.
 
  The earlier regression trumps, and in this case it was enabling FBC by
  default on Haswell. Sorry.
 
  You can enable FBC with i915.enable_fbc=1 module parameter, but all bets
  are off. See the commit message you quoted above. I don't recommend.
 



For what it's worth, I have a Mid-2014, Macbook Pro Retina (13inch
display), running Archlinux with 3.16.

Definitely, enable_fbc is a win for me and I do manually enable it.  But I
am still seeing what I believe to be
a regression overall of about +4W even with fbc enabled.  Still digging for
clues.

Sean





-- 
Sean V. Kelley sean.v.kel...@intel.com
Open Source Technology Center / SSG
Intel Corp.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 i-g-t] intel-gpu-tools: add igt_core init func calls to some tests

2014-08-05 Thread Sean V Kelley 
From: Tim Gore tim.g...@intel.com

igt-core.h/c provides some macros and initialisation
functions to support the tests but some of the single
tests do not use these. Modifying these tests to use
the igt_simple_main macro and igt_simple_init function
is the first step towards a consistent command line
across all tests.

Signed-off-by: Tim Gore tim.g...@intel.com
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 tests/gem_bad_address.c  | 4 +---
 tests/gem_bad_batch.c| 4 +---
 tests/gem_bad_blit.c | 4 +---
 tests/gem_hang.c | 2 ++
 tests/gem_non_secure_batch.c | 4 +---
 tests/gem_stress.c   | 2 ++
 6 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/tests/gem_bad_address.c b/tests/gem_bad_address.c
index f8fda90..e7a9587 100644
--- a/tests/gem_bad_address.c
+++ b/tests/gem_bad_address.c
@@ -60,7 +60,7 @@ bad_store(void)
intel_batchbuffer_flush(batch);
 }
 
-int main(int argc, char **argv)
+igt_simple_main
 {
int fd;
 
@@ -76,6 +76,4 @@ int main(int argc, char **argv)
drm_intel_bufmgr_destroy(bufmgr);
 
close(fd);
-
-   return 0;
 }
diff --git a/tests/gem_bad_batch.c b/tests/gem_bad_batch.c
index 33b3241..7f92a93 100644
--- a/tests/gem_bad_batch.c
+++ b/tests/gem_bad_batch.c
@@ -56,7 +56,7 @@ bad_batch(void)
intel_batchbuffer_flush(batch);
 }
 
-int main(int argc, char **argv)
+igt_simple_main
 {
int fd;
 
@@ -72,6 +72,4 @@ int main(int argc, char **argv)
drm_intel_bufmgr_destroy(bufmgr);
 
close(fd);
-
-   return 0;
 }
diff --git a/tests/gem_bad_blit.c b/tests/gem_bad_blit.c
index 9c03117..71a9f78 100644
--- a/tests/gem_bad_blit.c
+++ b/tests/gem_bad_blit.c
@@ -95,7 +95,7 @@ bad_blit(drm_intel_bo *src_bo, uint32_t devid)
intel_batchbuffer_flush(batch);
 }
 
-int main(int argc, char **argv)
+igt_simple_main
 {
drm_intel_bo *src;
int fd;
@@ -114,6 +114,4 @@ int main(int argc, char **argv)
drm_intel_bufmgr_destroy(bufmgr);
 
close(fd);
-
-   return 0;
 }
diff --git a/tests/gem_hang.c b/tests/gem_hang.c
index 8ebf606..6248244 100644
--- a/tests/gem_hang.c
+++ b/tests/gem_hang.c
@@ -72,6 +72,8 @@ int main(int argc, char **argv)
 {
int fd;
 
+   igt_simple_init();
+
igt_assert_f(argc == 2,
 usage: %s disabled pipe number\n,
 argv[0]);
diff --git a/tests/gem_non_secure_batch.c b/tests/gem_non_secure_batch.c
index 9acfda4..01101e9 100644
--- a/tests/gem_non_secure_batch.c
+++ b/tests/gem_non_secure_batch.c
@@ -77,7 +77,7 @@ mi_lri_loop(void)
}
 }
 
-int main(int argc, char **argv)
+igt_simple_main
 {
int fd;
int devid;
@@ -108,6 +108,4 @@ int main(int argc, char **argv)
drm_intel_bufmgr_destroy(bufmgr);
 
close(fd);
-
-   return 0;
 }
diff --git a/tests/gem_stress.c b/tests/gem_stress.c
index d46c643..2ccb6fc 100644
--- a/tests/gem_stress.c
+++ b/tests/gem_stress.c
@@ -865,6 +865,8 @@ int main(int argc, char **argv)
int i, j;
unsigned *current_permutation, *tmp_permutation;
 
+   igt_simple_init();
+
drm_fd = drm_open_any();
devid = intel_get_drm_devid(drm_fd);
 
-- 
2.0.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 i-g-t] lib/chv: CHV media pipeline command sequence

2014-08-05 Thread Sean V Kelley 
Enable gem_media_fill test for CHV platform.  In addition to differences in
media IP blocks from Broadwell, the command sequence also differs for
programming the media pipeline, e.g., should not send a MEDIA_STATE_FLUSH
right before the MI_BATCH_BUFFER_END of batch buffers using MEDIA_OBJECT.
Uses explicit IS_BROADWELL / IS_CHERRYVIEW to distinguish in gen8 media
fill handling.

Signed-off-by: Sean V Kelley sean.v.kel...@intel.com
---
 lib/Makefile.sources|   1 +
 lib/intel_batchbuffer.c |   4 +-
 lib/media_fill.h|   7 +
 lib/media_fill_gen8lp.c | 370 
 4 files changed, 381 insertions(+), 1 deletion(-)
 create mode 100644 lib/media_fill_gen8lp.c

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index aa9a130..242d2e0 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -25,6 +25,7 @@ libintel_tools_la_SOURCES =   \
media_fill.h\
media_fill_gen7.c   \
media_fill_gen8.c   \
+   media_fill_gen8lp.c \
gen7_media.h\
gen8_media.h\
rendercopy_i915.c   \
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index e868922..2c253d5 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -460,10 +460,12 @@ igt_media_fillfunc_t igt_get_media_fillfunc(int devid)
 {
igt_media_fillfunc_t fill = NULL;
 
-   if (IS_GEN8(devid))
+   if (IS_BROADWELL(devid))
fill = gen8_media_fillfunc;
else if (IS_GEN7(devid))
fill = gen7_media_fillfunc;
+   else if (IS_CHERRYVIEW(devid))
+   fill = gen8lp_media_fillfunc;
 
return fill;
 }
diff --git a/lib/media_fill.h b/lib/media_fill.h
index d417c75..ca35aeb 100644
--- a/lib/media_fill.h
+++ b/lib/media_fill.h
@@ -18,4 +18,11 @@ gen7_media_fillfunc(struct intel_batchbuffer *batch,
 unsigned width, unsigned height,
 uint8_t color);
 
+void
+gen8lp_media_fillfunc(struct intel_batchbuffer *batch,
+   struct igt_buf *dst,
+   unsigned x, unsigned y,
+   unsigned width, unsigned height,
+   uint8_t color);
+
 #endif /* RENDE_MEDIA_FILL_H */
diff --git a/lib/media_fill_gen8lp.c b/lib/media_fill_gen8lp.c
new file mode 100644
index 000..74dc573
--- /dev/null
+++ b/lib/media_fill_gen8lp.c
@@ -0,0 +1,370 @@
+#include intel_bufmgr.h
+#include i915_drm.h
+
+#include media_fill.h
+#include gen8_media.h
+#include intel_reg.h
+#include drmtest.h
+
+#include assert.h
+
+
+static const uint32_t media_kernel[][4] = {
+   { 0x0041, 0x20202288, 0x0020, 0x },
+   { 0x0061, 0x20800208, 0x008d, 0x },
+   { 0x0021, 0x20800208, 0x00450040, 0x },
+   { 0x0001, 0x20880608, 0x, 0x000f000f },
+   { 0x0081, 0x20a00208, 0x0020, 0x },
+   { 0x0081, 0x20e00208, 0x0020, 0x },
+   { 0x0081, 0x21200208, 0x0020, 0x },
+   { 0x0081, 0x21600208, 0x0020, 0x },
+   { 0x0c800031, 0x24000a40, 0x0e80, 0x120a8000 },
+   { 0x0061, 0x2e000208, 0x008d, 0x },
+   { 0x07800031, 0x2a40, 0x0e000e00, 0x8210 },
+};
+
+static uint32_t
+batch_used(struct intel_batchbuffer *batch)
+{
+   return batch-ptr - batch-buffer;
+}
+
+static uint32_t
+batch_align(struct intel_batchbuffer *batch, uint32_t align)
+{
+   uint32_t offset = batch_used(batch);
+   offset = ALIGN(offset, align);
+   batch-ptr = batch-buffer + offset;
+   return offset;
+}
+
+static void *
+batch_alloc(struct intel_batchbuffer *batch, uint32_t size, uint32_t align)
+{
+   uint32_t offset = batch_align(batch, align);
+   batch-ptr += size;
+   return memset(batch-buffer + offset, 0, size);
+}
+
+static uint32_t
+batch_offset(struct intel_batchbuffer *batch, void *ptr)
+{
+   return (uint8_t *)ptr - batch-buffer;
+}
+
+static uint32_t
+batch_copy(struct intel_batchbuffer *batch, const void *ptr, uint32_t size, 
uint32_t align)
+{
+   return batch_offset(batch, memcpy(batch_alloc(batch, size, align), ptr, 
size));
+}
+
+static void
+gen8_render_flush(struct intel_batchbuffer *batch, uint32_t batch_end)
+{
+   int ret;
+
+   ret = drm_intel_bo_subdata(batch-bo, 0, 4096, batch-buffer);
+   if (ret == 0)
+   ret = drm_intel_bo_mrb_exec(batch-bo, batch_end,
+   NULL, 0, 0, 0);
+   assert(ret == 0);
+}
+
+static uint32_t
+gen8_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
+   uint8_t color)
+{
+   uint8_t *curbe_buffer;
+   uint32_t offset;
+
+   curbe_buffer = batch_alloc(batch, sizeof(uint32_t) * 8, 64);
+   offset = batch_offset(batch, curbe_buffer);
+   *curbe_buffer = color;
+
+   return offset;
+}
+
+static uint32_t
+gen8_fill_surface_state(struct intel_batchbuffer *batch

Re: [Intel-gfx] [PATCH v2 i-g-t] intel-gpu-tools: add igt_core init func calls to some tests

2014-08-05 Thread Sean V Kelley 
Ignore PBKAC.

On Tue, Aug 5, 2014 at 1:51 PM, Sean V Kelley sean.v.kel...@intel.com wrote:
 From: Tim Gore tim.g...@intel.com

 igt-core.h/c provides some macros and initialisation
 functions to support the tests but some of the single
 tests do not use these. Modifying these tests to use
 the igt_simple_main macro and igt_simple_init function
 is the first step towards a consistent command line
 across all tests.

 Signed-off-by: Tim Gore tim.g...@intel.com
 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  tests/gem_bad_address.c  | 4 +---
  tests/gem_bad_batch.c| 4 +---
  tests/gem_bad_blit.c | 4 +---
  tests/gem_hang.c | 2 ++
  tests/gem_non_secure_batch.c | 4 +---
  tests/gem_stress.c   | 2 ++
  6 files changed, 8 insertions(+), 12 deletions(-)

 diff --git a/tests/gem_bad_address.c b/tests/gem_bad_address.c
 index f8fda90..e7a9587 100644
 --- a/tests/gem_bad_address.c
 +++ b/tests/gem_bad_address.c
 @@ -60,7 +60,7 @@ bad_store(void)
 intel_batchbuffer_flush(batch);
  }

 -int main(int argc, char **argv)
 +igt_simple_main
  {
 int fd;

 @@ -76,6 +76,4 @@ int main(int argc, char **argv)
 drm_intel_bufmgr_destroy(bufmgr);

 close(fd);
 -
 -   return 0;
  }
 diff --git a/tests/gem_bad_batch.c b/tests/gem_bad_batch.c
 index 33b3241..7f92a93 100644
 --- a/tests/gem_bad_batch.c
 +++ b/tests/gem_bad_batch.c
 @@ -56,7 +56,7 @@ bad_batch(void)
 intel_batchbuffer_flush(batch);
  }

 -int main(int argc, char **argv)
 +igt_simple_main
  {
 int fd;

 @@ -72,6 +72,4 @@ int main(int argc, char **argv)
 drm_intel_bufmgr_destroy(bufmgr);

 close(fd);
 -
 -   return 0;
  }
 diff --git a/tests/gem_bad_blit.c b/tests/gem_bad_blit.c
 index 9c03117..71a9f78 100644
 --- a/tests/gem_bad_blit.c
 +++ b/tests/gem_bad_blit.c
 @@ -95,7 +95,7 @@ bad_blit(drm_intel_bo *src_bo, uint32_t devid)
 intel_batchbuffer_flush(batch);
  }

 -int main(int argc, char **argv)
 +igt_simple_main
  {
 drm_intel_bo *src;
 int fd;
 @@ -114,6 +114,4 @@ int main(int argc, char **argv)
 drm_intel_bufmgr_destroy(bufmgr);

 close(fd);
 -
 -   return 0;
  }
 diff --git a/tests/gem_hang.c b/tests/gem_hang.c
 index 8ebf606..6248244 100644
 --- a/tests/gem_hang.c
 +++ b/tests/gem_hang.c
 @@ -72,6 +72,8 @@ int main(int argc, char **argv)
  {
 int fd;

 +   igt_simple_init();
 +
 igt_assert_f(argc == 2,
  usage: %s disabled pipe number\n,
  argv[0]);
 diff --git a/tests/gem_non_secure_batch.c b/tests/gem_non_secure_batch.c
 index 9acfda4..01101e9 100644
 --- a/tests/gem_non_secure_batch.c
 +++ b/tests/gem_non_secure_batch.c
 @@ -77,7 +77,7 @@ mi_lri_loop(void)
 }
  }

 -int main(int argc, char **argv)
 +igt_simple_main
  {
 int fd;
 int devid;
 @@ -108,6 +108,4 @@ int main(int argc, char **argv)
 drm_intel_bufmgr_destroy(bufmgr);

 close(fd);
 -
 -   return 0;
  }
 diff --git a/tests/gem_stress.c b/tests/gem_stress.c
 index d46c643..2ccb6fc 100644
 --- a/tests/gem_stress.c
 +++ b/tests/gem_stress.c
 @@ -865,6 +865,8 @@ int main(int argc, char **argv)
 int i, j;
 unsigned *current_permutation, *tmp_permutation;

 +   igt_simple_init();
 +
 drm_fd = drm_open_any();
 devid = intel_get_drm_devid(drm_fd);

 --
 2.0.1




-- 
Sean V. Kelley sean.v.kel...@intel.com
Open Source Technology Center / SSG
Intel Corp.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix vxd392 memory corruption on VLV and 4GB

2014-03-08 Thread Sean V Kelley 
On Saturday 08 Mar 2014 at 09:25:54 (+), Chris Wilson writes :
 On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
  On VLV systems addressing 4GB of memory or greater, memory corruption was 
  seen
  when initializing and attempting to render VP8 hardware decode surfaces 
  using
  the VXD392 HW IP block.
  
  The VXD MMU has a limitation to addressing only 32bits.  On 64bit kernel and
  user space builds this can cause problems for use of that IP block.
  
  When 2G memory is inserted, fw buffer pfn was at 0x5f62b, which is below 
  4GB.
  While for 4GB of memory the fw buffer pfn was 0x162ea9 with a physical 
  address
  at 0x162ea9000, above 4GB.
  
  So although the memory is 4GB in the test hardware (Bayleybay CRB), a large
  physical region (for example 3G-4G) can be occupied by onboard system
  resources.
  
  Enabling ZONE_DMA32 and setting the correct mask DMA for this device
  resolves the issue kernel side.
 
 That's a shame. I guess this is restricted to a subset of byt?

It should affect all baytrail systems. To my knowledge there are no subsets 
that have it fused off.

  
  Cc: Jesse Barnes jbar...@virtuousgeek.org
  Cc: Alan Cox a...@linux.intel.com
  Cc: Fei Jiang fei.ji...@intel.com
  Signed-off-by: Sean V Kelley sean.v.kel...@intel.com
  ---
   drivers/gpu/drm/i915/i915_dma.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_dma.c 
  b/drivers/gpu/drm/i915/i915_dma.c
  index e4d2b9f..b8c6efc 100644
  --- a/drivers/gpu/drm/i915/i915_dma.c
  +++ b/drivers/gpu/drm/i915/i915_dma.c
  @@ -1636,7 +1636,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
  long flags)
   * behaviour if any general state is accessed within a page above 4GB,
   * which also needs to be handled carefully.
 
 Also add a sentence here giving a quick explanation as to why we need to
 quirk IS_VLV as well.

Thanks for the feedback also going through Daniel's.

Sean

 
   */
  -   if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
  +   if (IS_BROADWATER(dev) || IS_CRESTLINE(dev) || IS_VALLEYVIEW(dev))
  dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(32));
   
  aperture_size = dev_priv-gtt.mappable_end;
 
 -- 
 Chris Wilson, Intel Open Source Technology Centre


pgpyfNDDzTyYy.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix vxd392 memory corruption on VLV and 4GB

2014-03-08 Thread Sean V Kelley 
On Saturday 08 Mar 2014 at 11:07:50 (+0100), Daniel Vetter writes :
 On Sat, Mar 08, 2014 at 09:25:54AM +, Chris Wilson wrote:
  On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
   On VLV systems addressing 4GB of memory or greater, memory corruption was 
   seen
   when initializing and attempting to render VP8 hardware decode surfaces 
   using
   the VXD392 HW IP block.
   
   The VXD MMU has a limitation to addressing only 32bits.  On 64bit kernel 
   and
   user space builds this can cause problems for use of that IP block.
   
   When 2G memory is inserted, fw buffer pfn was at 0x5f62b, which is below 
   4GB.
   While for 4GB of memory the fw buffer pfn was 0x162ea9 with a physical 
   address
   at 0x162ea9000, above 4GB.
   
   So although the memory is 4GB in the test hardware (Bayleybay CRB), a 
   large
   physical region (for example 3G-4G) can be occupied by onboard system
   resources.
   
   Enabling ZONE_DMA32 and setting the correct mask DMA for this device
   resolves the issue kernel side.
  
  That's a shame. I guess this is restricted to a subset of byt?
   
   Cc: Jesse Barnes jbar...@virtuousgeek.org
   Cc: Alan Cox a...@linux.intel.com
   Cc: Fei Jiang fei.ji...@intel.com
   Signed-off-by: Sean V Kelley sean.v.kel...@intel.com
   ---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
   
   diff --git a/drivers/gpu/drm/i915/i915_dma.c 
   b/drivers/gpu/drm/i915/i915_dma.c
   index e4d2b9f..b8c6efc 100644
   --- a/drivers/gpu/drm/i915/i915_dma.c
   +++ b/drivers/gpu/drm/i915/i915_dma.c
   @@ -1636,7 +1636,7 @@ int i915_driver_load(struct drm_device *dev, 
   unsigned long flags)
  * behaviour if any general state is accessed within a page above 4GB,
  * which also needs to be handled carefully.
  
  Also add a sentence here giving a quick explanation as to why we need to
  quirk IS_VLV as well.
  
  */
   - if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
   + if (IS_BROADWATER(dev) || IS_CRESTLINE(dev) || IS_VALLEYVIEW(dev))
 dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(32));
 
 Nack because:
 - the vxd392 isn't merged upstream

Sure, I just wanted to get some feedback.  Yeah, in it's current state my
driver port will not be acceptable upstream until I cleanup the  deprecated API 
from
the driver, remove my wrappers/hooks from the i915, and make similar API 
changes to the user
mode driver.  That is a work-in-progress for me now.

 - we can allocate shared buffers from vxd392 and have the restriction just
   there
 - for shared buffers allocated in i915 imo the right approach is to move
   offending pages around when vxd392 attaches - i.e. we need to check the
   attached device's dma masks and if there's something offending, migrate
   the buffer with a differen shmem allocation mask. Iirc Alan Cox had
   patches to do just that (but for swapoff, still the same idea though).

Will keep that in mind.  I have been getting some feedback from Alan too.

Thanks,

Sean

 
 Cheers, Daniel

 aperture_size = dev_priv-gtt.mappable_end;
  
  -- 
  Chris Wilson, Intel Open Source Technology Centre
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 -- 
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch


pgpMnrIwxCtHg.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx