[Bug 64225] New: bfgminer --scyte generates Segmentation Fault on Northern Island
https://bugs.freedesktop.org/show_bug.cgi?id=64225 Priority: medium Bug ID: 64225 Assignee: dri-devel at lists.freedesktop.org Summary: bfgminer --scyte generates Segmentation Fault on Northern Island Severity: normal Classification: Unclassified OS: Linux (All) Reporter: spamjunkeater at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 78869 --> https://bugs.freedesktop.org/attachment.cgi?id=78869&action=edit ./bfgminer -v1 --benchmark --scrypt &> OpenSUSE LLVM-trunk (patched version using: https://bugs.freedesktop.org/attachment.cgi?id=78831) with Mesa trunk 3.9 kernel x86_64 "./bfgminer -v1 --benchmark --scrypt" Generated segmentation fault. Log attached. Thanks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/96ee8246/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #9 from Erdem U. Altinyurt --- Created attachment 78868 --> https://bugs.freedesktop.org/attachment.cgi?id=78868&action=edit GPU Lockup with bfgminer -v1 --benchmark kernel messages -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/f218a4ef/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #8 from Erdem U. Altinyurt --- (In reply to comment #7) > I would recommend using bfgminer for bitcoin mining. It auto-detects the > mesa platform, and disabled unsupported features. All you need to do to get > it to work is pass the -v1 flag. I just want try openCL programs. Not intended to waste energy with those yet, until I produce my energy by solar panels... With "bfgminer -v1 --benchmark", I think it start working first. But hey! I got GPU lockups which is serious bug I think! :-/ I attached the kernel messages. Anyway I got 1.6M hash/s. Also "bfgminer -v1 --benchmark --scrypt" gives segmentation fault. Attaching the debug output with R600_cs=DEBUG. > > And python-opencl package from suse repo that give pipe_r600.so fault. > Can you open a separate bug for this or any other programs you've tried. ACK -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/39dfd79f/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 runetmember at gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from runetmember at gmail.com --- Thanks! That workaround help prevent GPU lockups. *** This bug has been marked as a duplicate of bug 60969 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/d4da7abe/attachment.html>
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 runetmember at gmail.com changed: What|Removed |Added CC||runetmember at gmail.com --- Comment #9 from runetmember at gmail.com --- *** Bug 64220 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/115fba4c/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 Andreas Boll changed: What|Removed |Added Version|7.10|9.1 Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #4 from Andreas Boll --- Does setting the env var R600_HYPERZ=0 help? If yes, an upgrade to mesa 9.1.2, where hyperz is disabled by default, should fix your issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/38f55d6c/attachment-0001.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #7 from Tom Stellard --- (In reply to comment #4) > Hi friends, > > @Vincent, I will add output as an attachment. > > @Tom Stellard > > For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/ > pyrit-read-only > > I don't patched it. Will report with your patch asap. > > Other programs are cgminer : https://github.com/ckolivas/cgminer > I would recommend using bfgminer for bitcoin mining. It auto-detects the mesa platform, and disabled unsupported features. All you need to do to get it to work is pass the -v1 flag. > And python-opencl package from suse repo that give pipe_r600.so fault. > Can you open a separate bug for this or any other programs you've tried. > Any other program that I trued doesn't work on my card, yet. > > Thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/91002b11/attachment.html>
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 --- Comment #8 from letharion at gmail.com --- Created attachment 78862 --> https://bugs.freedesktop.org/attachment.cgi?id=78862&action=edit Trine 2 windowed. Proper rendering. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/956aa27f/attachment.html>
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 letharion at gmail.com changed: What|Removed |Added Attachment #78860|0 |1 is obsolete|| --- Comment #7 from letharion at gmail.com --- Created attachment 78861 --> https://bugs.freedesktop.org/attachment.cgi?id=78861&action=edit Trine 2 in fullscreen, heavy miss rendering. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/11d15d6f/attachment.html>
DMA mapping API abuse in exynos-drm
Hi, Recently I've been working a bit on a DRM driver for the GPU of Samsung S3C6410 SoCs, which required me to familiarize a bit with exynos-drm, as it already contains a KMS driver which is compatible with the SoC I'm working with, making it a good place to put my driver in. Reading through exynos_drm_buf.c I stumbled across following (a bit long) piece of code: dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->dma_attrs); nr_pages = buf->size >> PAGE_SHIFT; if (!is_drm_iommu_supported(dev)) { dma_addr_t start_addr; unsigned int i = 0; buf->pages = kzalloc(sizeof(struct page) * nr_pages, GFP_KERNEL); if (!buf->pages) { DRM_ERROR("failed to allocate pages.\n"); return -ENOMEM; } buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size, &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs); if (!buf->kvaddr) { DRM_ERROR("failed to allocate buffer.\n"); kfree(buf->pages); return -ENOMEM; } start_addr = buf->dma_addr; while (i < nr_pages) { buf->pages[i] = phys_to_page(start_addr); start_addr += PAGE_SIZE; i++; } } else { buf->pages = dma_alloc_attrs(dev->dev, buf->size, &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs); if (!buf->pages) { DRM_ERROR("failed to allocate buffer.\n"); return -ENOMEM; } } buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages); if (!buf->sgt) { DRM_ERROR("failed to get sg table.\n"); ret = -ENOMEM; goto err_free_attrs; } Notice that the value returned by dma_alloc_attrs() is assumed by this code to be either a kernel virtual address (in !is_drm_iommu_supported() case) or struct pages ** (in is_drm_iommu_supported() case), which seemed a bit worrying to me, making me do a more in depth research on how dma_alloc_attrs works. This, in turn, led me to following excerpt of Documentation/DMA- attributes.txt : DMA_ATTR_NO_KERNEL_MAPPING -- DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel virtual mapping for the allocated buffer. On some architectures creating such mapping is non-trivial task and consumes very limited resources (like kernel virtual address space or dma consistent address space). Buffers allocated with this attribute can be only passed to user space by calling dma_mmap_attrs(). By using this API, you are guaranteeing that you won't dereference the pointer returned by dma_alloc_attr(). You can threat it as a cookie that must be passed to dma_mmap_attrs() and dma_free_attrs(). Make sure that both of these also get this attribute set on each call. of which the following sentence is the most relevant: By using this API, you are guaranteeing that you won't dereference the pointer returned by dma_alloc_attr(). This statement is obviously ignored by buffer allocation code of exynos- drm. A simple git blame revealed that this brokenness has been introduced by commit: 4744ad2 drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute and later fixed a bit by following depending patches (because the original patch apparently broke any allocations without IOMMU): c704f1b drm/exynos: consider no iommu support to console framebuffer 694be45 drm/exynos: consider buffer allocation without iommu Now, the real question is whether my reasoning is incorrect (sorry for the noise then) or this is really a bug which needs to be fixed? Best regards, Tomasz
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 --- Comment #6 from letharion at gmail.com --- Created attachment 78860 --> https://bugs.freedesktop.org/attachment.cgi?id=78860&action=edit Trine 2 in fullscreen, heavy miss rendering. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/edea8e5c/attachment.html>
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 letharion at gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from letharion at gmail.com --- Running with mesa as of c4150123aa9c2a71a62fed800d7c4424e9b948f2 I do not see this fixed. The problems in the main menu, as shows in the screenshots already attached, remain. I'll attach images of gameplay as well, as the effect is shown more clearly there. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/c8a340d3/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 --- Comment #3 from runetmember at gmail.com --- This GPU lockup is also reproducible on Radeon HD 6650M. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/766c5efb/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 runetmember at gmail.com changed: What|Removed |Added Summary|GPU lockup in L4D2 on SUMO |GPU lockup in L4D2 on SUMO ||and TURKS -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/ece96419/attachment-0001.html>
[PULL] drm-intel-fixes
Hi Dave, A few intel fixes for smaller issues and one revert for an sdv hack which we've wanted to kill anyway. Plus two drm patches included for your convenience, both regression fixers for mine own screw-ups. Cheers, Daniel The following changes since commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff: drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 14:07:16 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9: drm/i915: hsw: fix link training for eDP on port-A (2013-05-04 10:24:56 +0200) Chris Wilson (1): drm/i915: Always normalize return timeout for wait_timeout_ioctl Daniel Vetter (3): drm/mm: fix dump table BUG drm: don't check modeset locks in panic handler Revert "drm/i915: revert eDP bpp clamping code changes" Imre Deak (1): drm/i915: hsw: fix link training for eDP on port-A Ville Syrj?l? (1): drm/i915: Fix pipe enabled mask for pipe C in WM calculations drivers/gpu/drm/drm_crtc.c |4 ++ drivers/gpu/drm/drm_mm.c | 34 + drivers/gpu/drm/i915/i915_gem.c |8 ++-- drivers/gpu/drm/i915/intel_ddi.c |5 +++ drivers/gpu/drm/i915/intel_dp.c | 77 -- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_pm.c | 44 +++--- 7 files changed, 101 insertions(+), 72 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #4 from runetmember at gmail.com --- Still reproducible with radeon 7.1.0. Tested on native Left 4 Dead 2. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/384746a8/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO
https://bugs.freedesktop.org/show_bug.cgi?id=64220 --- Comment #2 from runetmember at gmail.com --- Created attachment 78858 --> https://bugs.freedesktop.org/attachment.cgi?id=78858&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/de165c8a/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO
https://bugs.freedesktop.org/show_bug.cgi?id=64220 --- Comment #1 from runetmember at gmail.com --- Created attachment 78857 --> https://bugs.freedesktop.org/attachment.cgi?id=78857&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/98647fc1/attachment.html>
[Bug 64220] New: GPU lockup in L4D2 on SUMO
https://bugs.freedesktop.org/show_bug.cgi?id=64220 Priority: medium Bug ID: 64220 Assignee: dri-devel at lists.freedesktop.org Summary: GPU lockup in L4D2 on SUMO Severity: normal Classification: Unclassified OS: All Reporter: runetmember at gmail.com Hardware: Other Status: NEW Version: 7.10 Component: Drivers/DRI/R600 Product: Mesa To reproduce this issue start L4D2, load any campaign, kill few zombies. It'll take less than a minute to GPU hang happen. Logs attached. Software: Linux 3.8.0-19 libdrm 2.4.43 Mesa 9.1.1 xserver-xorg-video-radeon 7.1.0 Xserver 1.13.3 Kubuntu 13.04 x86_64 Hardware: A8-3500M with Radeon HD 6620G. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/212c38d4/attachment.html>
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #13 from Chris Rankin --- This version of Mesa is a lot more promising! OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAICOS OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-8c347d4) OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) No lock-ups so far! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/f51a1398/attachment.html>
[PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}
On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote: > This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The > interface is simplified (because the base and size parameters to > drm_mtrr_del never did anything) and it uses > mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems > that don't need them. > > Signed-off-by: Andy Lutomirski > --- [snip] > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > index 2d94d74..2a3e1fd 100644 > --- a/include/drm/drmP.h > +++ b/include/drm/drmP.h > @@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device > *dev) > return drm_core_check_feature(dev, DRIVER_USE_MTRR); > } > > -#define DRM_MTRR_WC MTRR_TYPE_WRCOMB > - > -static inline int drm_mtrr_add(unsigned long offset, unsigned long size, > -unsigned int flags) > +static inline int __must_check drm_mtrr_add_wc(unsigned long offset, > +unsigned long size) > { > - return mtrr_add(offset, size, flags, 1); > + return mtrr_add_wc_if_needed(offset, size); > } > > -static inline int drm_mtrr_del(int handle, unsigned long offset, > -unsigned long size, unsigned int flags) > +static inline void drm_mtrr_del_wc(int handle) > { > - return mtrr_del(handle, offset, size); > + mtrr_del_wc_if_needed(handle); > } > > #else > @@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned > long offset, > > #define DRM_MTRR_WC 0 > > -static inline int drm_mtrr_add(unsigned long offset, unsigned long size, > -unsigned int flags) > +static inline int __must_check drm_mtrr_add_wc(unsigned long offset, > +unsigned long size) > { > - return 0; > + return -1; > } > > -static inline int drm_mtrr_del(int handle, unsigned long offset, > -unsigned long size, unsigned int flags) > +static inline void drm_mtrr_del_wc(int handle) > { > - return 0; > } Tbh I'm not a big fan of the drm_ indirection. Historically that was useful as an OS abstraction layer so that the same drivers could be used unchanged on Linux and the *BSD. But those days are long gone and drm drivers are now proper Linux drivers, and generally OS HALs seem to be frowned upon. Is there another reason than just being consistent with the historic stuff here? If we need dummy functions for !CONFIG_MTRR I think those should simply be in the core. And if the inconsistency bugs you I'd volunteer myself to ditch the old drm_ mtrr helpers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #7 from Andy Furniss --- Created attachment 78855 --> https://bugs.freedesktop.org/attachment.cgi?id=78855&action=edit R600_DEBUG=vs,ps,fs glxgears rendering dark on heads -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/e1122375/attachment.html>
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #6 from Andy Furniss --- Created attachment 78854 --> https://bugs.freedesktop.org/attachment.cgi?id=78854&action=edit R600_DEBUG=vs,ps,fs glxgears rendering OK on packetize with patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/ac1635dd/attachment.html>
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #5 from Andy Furniss --- (In reply to comment #4) > Can you cherry pick this patch : > https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on > top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of > R600_DEBUG=vs,ps,fs again please ? glxgears looks normal with the patch, though it doesn't fix other demos/games eg. nexuiz just hung and gloss renders almost OK but the sides are matt with no reflection. I'll attach the debug as requested and one from heads I did this morning as well where it is rendering dark. FWIW when llvm is on packetize mesa doesn't build on head so for these it's been (random choice) set on e2b985dc0f93a195d984aa7c88669ab67160c6c4 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/fb349cc9/attachment.html>
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #7 from Parag --- I am getting the same error on HD6750M - I verified the kernel (Linus git from today) I am running has the raise clocks patch. I've also replaced everything in /lib/firmware/radeon from http://people.freedesktop.org/~agd5f/radeon_ucode/. lspci | grep -i radeon -- 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler [Radeon HD 6600M/6700M/7600M Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI Audio [Radeon HD 6000 Series] dmesg - dmesg |grep -i uvd [ 17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/e6aa9d56/attachment.html>
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 Parag changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Parag --- Ugh, wrong status and wrong bug looks like. I will leave this closed and comment on 63935 which seems more appropriate. Sorry about the noise. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/6d436c9f/attachment.html>
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 Parag changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #18 from Parag --- I am getting the same error on HD6750M - I verified the kernel (Linus git from today) I am running has the raise clocks patch. I've also replaced everything in /lib/firmware/radeon from http://people.freedesktop.org/~agd5f/radeon_ucode/. lspci | grep -i radeon -- 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler [Radeon HD 6600M/6700M/7600M Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI Audio [Radeon HD 6000 Series] dmesg - dmesg |grep -i uvd [ 17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/dcbb6f60/attachment-0001.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #10 from Erdem U. Altinyurt --- Also faced same lockups at GIMP OpenCL, otherwise it looks start working, sloly. :) If bfgminer fix doesn't fix GIMP also, I will open bug report for it also. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64225] bfgminer --scyte generates Segmentation Fault on Northern Island
https://bugs.freedesktop.org/show_bug.cgi?id=64225 Erdem U. Altinyurt changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64226] New: python-opencl package generate segmentation fault at pipe_r600.so
https://bugs.freedesktop.org/show_bug.cgi?id=64226 Priority: medium Bug ID: 64226 Assignee: dri-devel@lists.freedesktop.org Summary: python-opencl package generate segmentation fault at pipe_r600.so Severity: normal Classification: Unclassified OS: Linux (All) Reporter: spamjunkea...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Using OpenSUSE llvm-trunk & Mesa-trunk 3.9 Kernel x86_64 Using OpenSuSE repo package: https://build.opensuse.org/package/show?project=home%3A-miska-&package=python-opencl Source included also, packed version of : https://github.com/srossross/oclpb death@triQuad:/home/compile/svn/cgminer> python Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import opencl >>> opencl.test() [] test_broadcast_0D (test.test_memobj.TestBuffer) ... ok test_broadcast_2D (test.test_memobj.TestBuffer) ... ok test_copy_1D (test.test_memobj.TestBuffer) ... FAIL test_copy_2D (test.test_memobj.TestBuffer) ... FAIL test_copy_2D_negative_stride (test.test_memobj.TestBuffer) ... expected failure test_copy_contig (test.test_memobj.TestBuffer) ... Segmentation fault death@triQuad:/home/compile/svn/cgminer> -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64225] New: bfgminer --scyte generates Segmentation Fault on Northern Island
https://bugs.freedesktop.org/show_bug.cgi?id=64225 Priority: medium Bug ID: 64225 Assignee: dri-devel@lists.freedesktop.org Summary: bfgminer --scyte generates Segmentation Fault on Northern Island Severity: normal Classification: Unclassified OS: Linux (All) Reporter: spamjunkea...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 78869 --> https://bugs.freedesktop.org/attachment.cgi?id=78869&action=edit ./bfgminer -v1 --benchmark --scrypt &> OpenSUSE LLVM-trunk (patched version using: https://bugs.freedesktop.org/attachment.cgi?id=78831) with Mesa trunk 3.9 kernel x86_64 "./bfgminer -v1 --benchmark --scrypt" Generated segmentation fault. Log attached. Thanks -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #9 from Erdem U. Altinyurt --- Created attachment 78868 --> https://bugs.freedesktop.org/attachment.cgi?id=78868&action=edit GPU Lockup with bfgminer -v1 --benchmark kernel messages -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #8 from Erdem U. Altinyurt --- (In reply to comment #7) > I would recommend using bfgminer for bitcoin mining. It auto-detects the > mesa platform, and disabled unsupported features. All you need to do to get > it to work is pass the -v1 flag. I just want try openCL programs. Not intended to waste energy with those yet, until I produce my energy by solar panels... With "bfgminer -v1 --benchmark", I think it start working first. But hey! I got GPU lockups which is serious bug I think! :-/ I attached the kernel messages. Anyway I got 1.6M hash/s. Also "bfgminer -v1 --benchmark --scrypt" gives segmentation fault. Attaching the debug output with R600_cs=DEBUG. > > And python-opencl package from suse repo that give pipe_r600.so fault. > Can you open a separate bug for this or any other programs you've tried. ACK -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 runetmem...@gmail.com changed: What|Removed |Added CC||runetmem...@gmail.com --- Comment #9 from runetmem...@gmail.com --- *** Bug 64220 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 runetmem...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from runetmem...@gmail.com --- Thanks! That workaround help prevent GPU lockups. *** This bug has been marked as a duplicate of bug 60969 *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #4 from vincent --- Can you cherry pick this patch : https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of R600_DEBUG=vs,ps,fs again please ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/fc0a916d/attachment.html>
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 Andreas Boll changed: What|Removed |Added Version|7.10|9.1 Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #4 from Andreas Boll --- Does setting the env var R600_HYPERZ=0 help? If yes, an upgrade to mesa 9.1.2, where hyperz is disabled by default, should fix your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #7 from Tom Stellard --- (In reply to comment #4) > Hi friends, > > @Vincent, I will add output as an attachment. > > @Tom Stellard > > For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/ > pyrit-read-only > > I don't patched it. Will report with your patch asap. > > Other programs are cgminer : https://github.com/ckolivas/cgminer > I would recommend using bfgminer for bitcoin mining. It auto-detects the mesa platform, and disabled unsupported features. All you need to do to get it to work is pass the -v1 flag. > And python-opencl package from suse repo that give pipe_r600.so fault. > Can you open a separate bug for this or any other programs you've tried. > Any other program that I trued doesn't work on my card, yet. > > Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 --- Comment #8 from lethar...@gmail.com --- Created attachment 78862 --> https://bugs.freedesktop.org/attachment.cgi?id=78862&action=edit Trine 2 windowed. Proper rendering. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 lethar...@gmail.com changed: What|Removed |Added Attachment #78860|0 |1 is obsolete|| --- Comment #7 from lethar...@gmail.com --- Created attachment 78861 --> https://bugs.freedesktop.org/attachment.cgi?id=78861&action=edit Trine 2 in fullscreen, heavy miss rendering. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 --- Comment #6 from lethar...@gmail.com --- Created attachment 78860 --> https://bugs.freedesktop.org/attachment.cgi?id=78860&action=edit Trine 2 in fullscreen, heavy miss rendering. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 lethar...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from lethar...@gmail.com --- Running with mesa as of c4150123aa9c2a71a62fed800d7c4424e9b948f2 I do not see this fixed. The problems in the main menu, as shows in the screenshots already attached, remain. I'll attach images of gameplay as well, as the effect is shown more clearly there. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 --- Comment #3 from runetmem...@gmail.com --- This GPU lockup is also reproducible on Radeon HD 6650M. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS
https://bugs.freedesktop.org/show_bug.cgi?id=64220 runetmem...@gmail.com changed: What|Removed |Added Summary|GPU lockup in L4D2 on SUMO |GPU lockup in L4D2 on SUMO ||and TURKS -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #4 from runetmem...@gmail.com --- Still reproducible with radeon 7.1.0. Tested on native Left 4 Dead 2. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64220] GPU lockup in L4D2 on SUMO
https://bugs.freedesktop.org/show_bug.cgi?id=64220 --- Comment #2 from runetmem...@gmail.com --- Created attachment 78858 --> https://bugs.freedesktop.org/attachment.cgi?id=78858&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64220] GPU lockup in L4D2 on SUMO
https://bugs.freedesktop.org/show_bug.cgi?id=64220 --- Comment #1 from runetmem...@gmail.com --- Created attachment 78857 --> https://bugs.freedesktop.org/attachment.cgi?id=78857&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64220] New: GPU lockup in L4D2 on SUMO
https://bugs.freedesktop.org/show_bug.cgi?id=64220 Priority: medium Bug ID: 64220 Assignee: dri-devel@lists.freedesktop.org Summary: GPU lockup in L4D2 on SUMO Severity: normal Classification: Unclassified OS: All Reporter: runetmem...@gmail.com Hardware: Other Status: NEW Version: 7.10 Component: Drivers/DRI/R600 Product: Mesa To reproduce this issue start L4D2, load any campaign, kill few zombies. It'll take less than a minute to GPU hang happen. Logs attached. Software: Linux 3.8.0-19 libdrm 2.4.43 Mesa 9.1.1 xserver-xorg-video-radeon 7.1.0 Xserver 1.13.3 Kubuntu 13.04 x86_64 Hardware: A8-3500M with Radeon HD 6620G. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #13 from Chris Rankin --- This version of Mesa is a lot more promising! OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAICOS OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-8c347d4) OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) No lock-ups so far! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #6 from Erdem U. Altinyurt --- Created attachment 78839 --> https://bugs.freedesktop.org/attachment.cgi?id=78839&action=edit Pyrit Debug log with Patched LLVM-trunk Hi again, I attached debug log with patch for examination. Regards, Erdem -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/bd40685c/attachment.html>
DMA mapping API abuse in exynos-drm
Hi, Recently I've been working a bit on a DRM driver for the GPU of Samsung S3C6410 SoCs, which required me to familiarize a bit with exynos-drm, as it already contains a KMS driver which is compatible with the SoC I'm working with, making it a good place to put my driver in. Reading through exynos_drm_buf.c I stumbled across following (a bit long) piece of code: dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->dma_attrs); nr_pages = buf->size >> PAGE_SHIFT; if (!is_drm_iommu_supported(dev)) { dma_addr_t start_addr; unsigned int i = 0; buf->pages = kzalloc(sizeof(struct page) * nr_pages, GFP_KERNEL); if (!buf->pages) { DRM_ERROR("failed to allocate pages.\n"); return -ENOMEM; } buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size, &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs); if (!buf->kvaddr) { DRM_ERROR("failed to allocate buffer.\n"); kfree(buf->pages); return -ENOMEM; } start_addr = buf->dma_addr; while (i < nr_pages) { buf->pages[i] = phys_to_page(start_addr); start_addr += PAGE_SIZE; i++; } } else { buf->pages = dma_alloc_attrs(dev->dev, buf->size, &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs); if (!buf->pages) { DRM_ERROR("failed to allocate buffer.\n"); return -ENOMEM; } } buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages); if (!buf->sgt) { DRM_ERROR("failed to get sg table.\n"); ret = -ENOMEM; goto err_free_attrs; } Notice that the value returned by dma_alloc_attrs() is assumed by this code to be either a kernel virtual address (in !is_drm_iommu_supported() case) or struct pages ** (in is_drm_iommu_supported() case), which seemed a bit worrying to me, making me do a more in depth research on how dma_alloc_attrs works. This, in turn, led me to following excerpt of Documentation/DMA- attributes.txt : DMA_ATTR_NO_KERNEL_MAPPING -- DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel virtual mapping for the allocated buffer. On some architectures creating such mapping is non-trivial task and consumes very limited resources (like kernel virtual address space or dma consistent address space). Buffers allocated with this attribute can be only passed to user space by calling dma_mmap_attrs(). By using this API, you are guaranteeing that you won't dereference the pointer returned by dma_alloc_attr(). You can threat it as a cookie that must be passed to dma_mmap_attrs() and dma_free_attrs(). Make sure that both of these also get this attribute set on each call. of which the following sentence is the most relevant: By using this API, you are guaranteeing that you won't dereference the pointer returned by dma_alloc_attr(). This statement is obviously ignored by buffer allocation code of exynos- drm. A simple git blame revealed that this brokenness has been introduced by commit: 4744ad2 drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute and later fixed a bit by following depending patches (because the original patch apparently broke any allocations without IOMMU): c704f1b drm/exynos: consider no iommu support to console framebuffer 694be45 drm/exynos: consider buffer allocation without iommu Now, the real question is whether my reasoning is incorrect (sorry for the noise then) or this is really a bug which needs to be fixed? Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #5 from Erdem U. Altinyurt --- Created attachment 78838 --> https://bugs.freedesktop.org/attachment.cgi?id=78838&action=edit Pyrit Error log with Debug -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/8c645914/attachment-0001.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #4 from Erdem U. Altinyurt --- Hi friends, @Vincent, I will add output as an attachment. @Tom Stellard For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/ pyrit-read-only I don't patched it. Will report with your patch asap. Other programs are cgminer : https://github.com/ckolivas/cgminer And python-opencl package from suse repo that give pipe_r600.so fault. Any other program that I trued doesn't work on my card, yet. Thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/8c571afe/attachment.html>
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #7 from Andy Furniss --- Created attachment 78855 --> https://bugs.freedesktop.org/attachment.cgi?id=78855&action=edit R600_DEBUG=vs,ps,fs glxgears rendering dark on heads -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #6 from Andy Furniss --- Created attachment 78854 --> https://bugs.freedesktop.org/attachment.cgi?id=78854&action=edit R600_DEBUG=vs,ps,fs glxgears rendering OK on packetize with patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #5 from Andy Furniss --- (In reply to comment #4) > Can you cherry pick this patch : > https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on > top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of > R600_DEBUG=vs,ps,fs again please ? glxgears looks normal with the patch, though it doesn't fix other demos/games eg. nexuiz just hung and gloss renders almost OK but the sides are matt with no reflection. I'll attach the debug as requested and one from heads I did this morning as well where it is rendering dark. FWIW when llvm is on packetize mesa doesn't build on head so for these it's been (random choice) set on e2b985dc0f93a195d984aa7c88669ab67160c6c4 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, A few intel fixes for smaller issues and one revert for an sdv hack which we've wanted to kill anyway. Plus two drm patches included for your convenience, both regression fixers for mine own screw-ups. Cheers, Daniel The following changes since commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff: drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 14:07:16 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9: drm/i915: hsw: fix link training for eDP on port-A (2013-05-04 10:24:56 +0200) Chris Wilson (1): drm/i915: Always normalize return timeout for wait_timeout_ioctl Daniel Vetter (3): drm/mm: fix dump table BUG drm: don't check modeset locks in panic handler Revert "drm/i915: revert eDP bpp clamping code changes" Imre Deak (1): drm/i915: hsw: fix link training for eDP on port-A Ville Syrjälä (1): drm/i915: Fix pipe enabled mask for pipe C in WM calculations drivers/gpu/drm/drm_crtc.c |4 ++ drivers/gpu/drm/drm_mm.c | 34 + drivers/gpu/drm/i915/i915_gem.c |8 ++-- drivers/gpu/drm/i915/intel_ddi.c |5 +++ drivers/gpu/drm/i915/intel_dp.c | 77 -- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_pm.c | 44 +++--- 7 files changed, 101 insertions(+), 72 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #7 from Parag --- I am getting the same error on HD6750M - I verified the kernel (Linus git from today) I am running has the raise clocks patch. I've also replaced everything in /lib/firmware/radeon from http://people.freedesktop.org/~agd5f/radeon_ucode/. lspci | grep -i radeon -- 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler [Radeon HD 6600M/6700M/7600M Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI Audio [Radeon HD 6000 Series] dmesg - dmesg |grep -i uvd [ 17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 Parag changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Parag --- Ugh, wrong status and wrong bug looks like. I will leave this closed and comment on 63935 which seems more appropriate. Sorry about the noise. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 Parag changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #18 from Parag --- I am getting the same error on HD6750M - I verified the kernel (Linus git from today) I am running has the raise clocks patch. I've also replaced everything in /lib/firmware/radeon from http://people.freedesktop.org/~agd5f/radeon_ucode/. lspci | grep -i radeon -- 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler [Radeon HD 6600M/6700M/7600M Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI Audio [Radeon HD 6000 Series] dmesg - dmesg |grep -i uvd [ 17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
On 3 May 2013 at 15:03, Jani Nikula wrote: > >> This fixes a compilation issue with clang. An initial version of this patch > >> was developed by PaX Team . > >> This is respin of this patch. > >> > >> Signed-off-by: Jan-Simon M?ller > >> CC: pageexec at freemail.hu > >> CC: daniel.vetter at ffwll.ch > >> CC: airlied at linux.ie > >> CC: intel-gfx at lists.freedesktop.org > >> CC: dri-devel at lists.freedesktop.org > >> CC: linux-kernel at vger.kernel.org > > Picked up for -fixes, thanks for the patch. > > Please drop it. > > The patch removes the inline keyword, creating dozens of copies of the > functions, and consequently loads of warnings: in my original patch they were both static inline, not sure where the inline got lost...
[PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}
On Sat, May 4, 2013 at 10:45 AM, Daniel Vetter wrote: > On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote: >> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The >> interface is simplified (because the base and size parameters to >> drm_mtrr_del never did anything) and it uses >> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems >> that don't need them. >> >> Signed-off-by: Andy Lutomirski >> --- > > > Tbh I'm not a big fan of the drm_ indirection. Historically that was > useful as an OS abstraction layer so that the same drivers could be used > unchanged on Linux and the *BSD. But those days are long gone and drm > drivers are now proper Linux drivers, and generally OS HALs seem to be > frowned upon. > > Is there another reason than just being consistent with the historic stuff > here? If we need dummy functions for !CONFIG_MTRR I think those should > simply be in the core. I admit to a bit of cargo-culting. There was a layer of indirection, so I kept it. I'll just call mtrr_add/del_wc_if_needed directly in v2 (I added those functions in patch 1 of this series). I'd assume you're okay with skipping mtrr addition if PAT is available since i915 already does it :) (Although the current logic is buggy -- cpu_has_pat is the wrong flag to check -- I think pat_enabled is better.) Note to self: I should remove #include in i915_dma.c in v2. --Andy
Re: [PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}
On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote: > This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The > interface is simplified (because the base and size parameters to > drm_mtrr_del never did anything) and it uses > mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems > that don't need them. > > Signed-off-by: Andy Lutomirski > --- [snip] > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > index 2d94d74..2a3e1fd 100644 > --- a/include/drm/drmP.h > +++ b/include/drm/drmP.h > @@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device > *dev) > return drm_core_check_feature(dev, DRIVER_USE_MTRR); > } > > -#define DRM_MTRR_WC MTRR_TYPE_WRCOMB > - > -static inline int drm_mtrr_add(unsigned long offset, unsigned long size, > -unsigned int flags) > +static inline int __must_check drm_mtrr_add_wc(unsigned long offset, > +unsigned long size) > { > - return mtrr_add(offset, size, flags, 1); > + return mtrr_add_wc_if_needed(offset, size); > } > > -static inline int drm_mtrr_del(int handle, unsigned long offset, > -unsigned long size, unsigned int flags) > +static inline void drm_mtrr_del_wc(int handle) > { > - return mtrr_del(handle, offset, size); > + mtrr_del_wc_if_needed(handle); > } > > #else > @@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned > long offset, > > #define DRM_MTRR_WC 0 > > -static inline int drm_mtrr_add(unsigned long offset, unsigned long size, > -unsigned int flags) > +static inline int __must_check drm_mtrr_add_wc(unsigned long offset, > +unsigned long size) > { > - return 0; > + return -1; > } > > -static inline int drm_mtrr_del(int handle, unsigned long offset, > -unsigned long size, unsigned int flags) > +static inline void drm_mtrr_del_wc(int handle) > { > - return 0; > } Tbh I'm not a big fan of the drm_ indirection. Historically that was useful as an OS abstraction layer so that the same drivers could be used unchanged on Linux and the *BSD. But those days are long gone and drm drivers are now proper Linux drivers, and generally OS HALs seem to be frowned upon. Is there another reason than just being consistent with the historic stuff here? If we need dummy functions for !CONFIG_MTRR I think those should simply be in the core. And if the inconsistency bugs you I'd volunteer myself to ditch the old drm_ mtrr helpers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for 3.10-rc1
On Sat, May 4, 2013 at 3:18 AM, Josh Boyer wrote: > On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: >>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote: >>> OK. Git bisect tells me this: >>> >>> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit >>> commit 57c219633275c7e7413f8bc7be250dc092887458 >>> Author: Daniel Vetter >>> Date: Thu Apr 4 17:19:37 2013 +0200 >>> >>> drm/i915: revert eDP bpp clamping code changes >> >>Yeah, that commit is a bit dubios and for 3.11 we've already planned >>to kick it out. It tries to work around an issue on a funky >>pre-release hw. Does reverting this commit fix your issue? > > Yes, seems so. I reverted it on top of Linus tree as of commit > ce857229e0c3adc2 and things boot normally on the machine after that. Thanks for confirming, I've reverted the patch and will foward my current drm-intel-fixes tree soon to Dave. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCHv5 0/2] Speed Cap fixes for ppc64
On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: > This patch series does: > 1. max_bus_speed is used to set the device to gen2 speeds > 2. on power there's no longer a conflict between the pseries call and other > architectures, because the overwrite is done via a ppc_md hook > 3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask > for gen2 capability detection > > The first patch consists of some architecture changes, such as adding a hook > on > powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a > function, while all other architectures get a NULL pointer. So that whenever > pci_create_root_bus is called, we'll get max_bus_speed properly setup from > OpenFirmware. > > The second patch consists of simple radeon changes not to call > drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, > the max_bus_speed property will be properly set already. So I'm ok with the approach now and I might even put the powerpc patch in for 3.10 since arguably we are fixing a nasty bug (uninitialized max_bus_speed). David, what's your feeling about the radeon change ? It would be nice if that could go in soon for various distro targets :-) On the other hand I'm not going to be pushy if you are not comfortable with it. Cheers, Ben.
[Bug 64193] LLVM RV670 regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64193 --- Comment #4 from vincent --- Can you cherry pick this patch : https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of R600_DEBUG=vs,ps,fs again please ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
On 3 May 2013 at 15:03, Jani Nikula wrote: > >> This fixes a compilation issue with clang. An initial version of this patch > >> was developed by PaX Team . > >> This is respin of this patch. > >> > >> Signed-off-by: Jan-Simon Möller > >> CC: pagee...@freemail.hu > >> CC: daniel.vet...@ffwll.ch > >> CC: airl...@linux.ie > >> CC: intel-...@lists.freedesktop.org > >> CC: dri-devel@lists.freedesktop.org > >> CC: linux-ker...@vger.kernel.org > > Picked up for -fixes, thanks for the patch. > > Please drop it. > > The patch removes the inline keyword, creating dozens of copies of the > functions, and consequently loads of warnings: in my original patch they were both static inline, not sure where the inline got lost... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 3.10-rc1
On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: >On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote: >> OK. Git bisect tells me this: >> >> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit >> commit 57c219633275c7e7413f8bc7be250dc092887458 >> Author: Daniel Vetter >> Date: Thu Apr 4 17:19:37 2013 +0200 >> >> drm/i915: revert eDP bpp clamping code changes > >Yeah, that commit is a bit dubios and for 3.11 we've already planned >to kick it out. It tries to work around an issue on a funky >pre-release hw. Does reverting this commit fix your issue? Yes, seems so. I reverted it on top of Linus tree as of commit ce857229e0c3adc2 and things boot normally on the machine after that. josh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] uvesafb: Clean up MTRR code
The old code allowed very strange memory types. Now it works like all the other video drivers: ioremap_wc is used unconditionally, and MTRRs are set if PAT is unavailable (unless MTRR is disabled by a module parameter). UC, WB, and WT support is gone. If there are MTRR conflicts that prevent addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's better to just turn off MTRR support entirely. As an added bonus, any MTRR added is freed on unload. Signed-off-by: Andy Lutomirski --- I can't test this -- the link to v86d in Documentation/fb/uvesafb.txt seems to be broken, and Fedora doesn't seem to package it. Documentation/fb/uvesafb.txt | 16 -- drivers/video/uvesafb.c | 70 include/video/uvesafb.h | 1 + 3 files changed, 24 insertions(+), 63 deletions(-) diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt index eefdd91..f6362d8 100644 --- a/Documentation/fb/uvesafb.txt +++ b/Documentation/fb/uvesafb.txt @@ -81,17 +81,11 @@ pmipal Use the protected mode interface for palette changes. mtrr:n Setup memory type range registers for the framebuffer where n: - 0 - disabled (equivalent to nomtrr) (default) - 1 - uncachable - 2 - write-back - 3 - write-combining - 4 - write-through - -If you see the following in dmesg, choose the type that matches -the old one. In this example, use "mtrr:2". -... -mtrr: type mismatch for e000,800 old: write-back new: write-combining -... + 0 - disabled (equivalent to nomtrr) + 3 - write-combining (default) + + Values other than 0 and 3 will result in a warning and will be + treated just like 3. nomtrr Do not use memory type range registers. diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c index d428445..4f447ad 100644 --- a/drivers/video/uvesafb.c +++ b/drivers/video/uvesafb.c @@ -24,9 +24,7 @@ #ifdef CONFIG_X86 #include #endif -#ifdef CONFIG_MTRR #include -#endif #include "edid.h" static struct cb_id uvesafb_cn_id = { @@ -1540,67 +1538,31 @@ static void uvesafb_init_info(struct fb_info *info, struct vbe_mode_ib *mode) static void uvesafb_init_mtrr(struct fb_info *info) { -#ifdef CONFIG_MTRR + struct uvesafb_par *par = info->par; + if (mtrr && !(info->fix.smem_start & (PAGE_SIZE - 1))) { int temp_size = info->fix.smem_len; - unsigned int type = 0; - switch (mtrr) { - case 1: - type = MTRR_TYPE_UNCACHABLE; - break; - case 2: - type = MTRR_TYPE_WRBACK; - break; - case 3: - type = MTRR_TYPE_WRCOMB; - break; - case 4: - type = MTRR_TYPE_WRTHROUGH; - break; - default: - type = 0; - break; - } + int rc; - if (type) { - int rc; + /* Find the largest power-of-two */ + temp_size = roundup_pow_of_two(temp_size); - /* Find the largest power-of-two */ - temp_size = roundup_pow_of_two(temp_size); + /* Try and find a power of two to add */ + do { + rc = mtrr_add_wc_if_needed(info->fix.smem_start, + temp_size); + temp_size >>= 1; + } while (temp_size >= PAGE_SIZE && rc == -EINVAL); - /* Try and find a power of two to add */ - do { - rc = mtrr_add(info->fix.smem_start, - temp_size, type, 1); - temp_size >>= 1; - } while (temp_size >= PAGE_SIZE && rc == -EINVAL); - } + if (rc >= 0) + par->mtrr_handle = rc; } -#endif /* CONFIG_MTRR */ } static void uvesafb_ioremap(struct fb_info *info) { -#ifdef CONFIG_X86 - switch (mtrr) { - case 1: /* uncachable */ - info->screen_base = ioremap_nocache(info->fix.smem_start, info->fix.smem_len); - break; - case 2: /* write-back */ - info->screen_base = ioremap_cache(info->fix.smem_start, info->fix.smem_len); - break; - case 3: /* write-combining */ - info->screen_base = ioremap_wc(info->fix.smem_start, info->fix.smem_len); - break; - case 4: /* write-through */ - default: - info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len); - break; - } -#else - info->screen_
[PATCH 6/7] radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc
Signed-off-by: Andy Lutomirski --- drivers/gpu/drm/radeon/radeon_object.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index d3aface..01d4906 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -321,8 +321,8 @@ void radeon_bo_force_delete(struct radeon_device *rdev) int radeon_bo_init(struct radeon_device *rdev) { /* Add an MTRR for the VRAM */ - rdev->mc.vram_mtrr = mtrr_add(rdev->mc.aper_base, rdev->mc.aper_size, - MTRR_TYPE_WRCOMB, 1); + rdev->mc.vram_mtrr = drm_mtrr_add_wc(rdev->mc.aper_base, +rdev->mc.aper_size); DRM_INFO("Detected VRAM RAM=%lluM, BAR=%lluM\n", rdev->mc.mc_vram_size >> 20, (unsigned long long)rdev->mc.aper_size >> 20); @@ -334,6 +334,7 @@ int radeon_bo_init(struct radeon_device *rdev) void radeon_bo_fini(struct radeon_device *rdev) { radeon_ttm_fini(rdev); + drm_mtrr_del_wc(rdev->mc.vram_mtrr); } void radeon_bo_list_add_object(struct radeon_bo_list *lobj, -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] i915: Use drm_mtrr_{add,del}_wc
i915 open-coded logic that was essentially equivalent to the new drm_mtrr_{add,del}_wc. Signed-off-by: Andy Lutomirski --- drivers/gpu/drm/i915/i915_dma.c | 43 ++--- 1 file changed, 6 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 4fa6beb..0fc95ba 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1393,29 +1393,6 @@ void i915_master_destroy(struct drm_device *dev, struct drm_master *master) master->driver_priv = NULL; } -static void -i915_mtrr_setup(struct drm_i915_private *dev_priv, unsigned long base, - unsigned long size) -{ - dev_priv->mm.gtt_mtrr = -1; - -#if defined(CONFIG_X86_PAT) - if (cpu_has_pat) - return; -#endif - - /* Set up a WC MTRR for non-PAT systems. This is more common than -* one would think, because the kernel disables PAT on first -* generation Core chips because WC PAT gets overridden by a UC -* MTRR if present. Even if a UC MTRR isn't present. -*/ - dev_priv->mm.gtt_mtrr = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1); - if (dev_priv->mm.gtt_mtrr < 0) { - DRM_INFO("MTRR allocation failed. Graphics " -"performance may suffer.\n"); - } -} - static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv) { struct apertures_struct *ap; @@ -1552,8 +1529,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) goto out_rmmap; } - i915_mtrr_setup(dev_priv, dev_priv->gtt.mappable_base, - aperture_size); + dev_priv->mm.gtt_mtrr = drm_mtrr_add_wc(dev_priv->gtt.mappable_base, + aperture_size); /* The i915 workqueue is primarily used for batched retirement of * requests (and thus managing bo) once the task has been completed @@ -1656,12 +1633,8 @@ out_gem_unload: intel_teardown_mchbar(dev); destroy_workqueue(dev_priv->wq); out_mtrrfree: - if (dev_priv->mm.gtt_mtrr >= 0) { - mtrr_del(dev_priv->mm.gtt_mtrr, -dev_priv->gtt.mappable_base, -aperture_size); - dev_priv->mm.gtt_mtrr = -1; - } + drm_mtrr_del_wc(dev_priv->mm.gtt_mtrr); + dev_priv->mm.gtt_mtrr = -1; io_mapping_free(dev_priv->gtt.mappable); out_rmmap: pci_iounmap(dev->pdev, dev_priv->regs); @@ -1697,12 +1670,8 @@ int i915_driver_unload(struct drm_device *dev) cancel_delayed_work_sync(&dev_priv->mm.retire_work); io_mapping_free(dev_priv->gtt.mappable); - if (dev_priv->mm.gtt_mtrr >= 0) { - mtrr_del(dev_priv->mm.gtt_mtrr, -dev_priv->gtt.mappable_base, -dev_priv->gtt.mappable_end); - dev_priv->mm.gtt_mtrr = -1; - } + drm_mtrr_del_wc(dev_priv->mm.gtt_mtrr); + dev_priv->mm.gtt_mtrr = -1; acpi_video_unregister(); -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm: Use drm_mtrr_add_wc for the AGP aperture
Signed-off-by: Andy Lutomirski --- drivers/gpu/drm/drm_pci.c | 8 drivers/gpu/drm/drm_stub.c | 10 ++ 2 files changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c index bd719e9..3628683 100644 --- a/drivers/gpu/drm/drm_pci.c +++ b/drivers/gpu/drm/drm_pci.c @@ -278,10 +278,10 @@ int drm_pci_agp_init(struct drm_device *dev) } if (drm_core_has_MTRR(dev)) { if (dev->agp) - dev->agp->agp_mtrr = - mtrr_add(dev->agp->agp_info.aper_base, -dev->agp->agp_info.aper_size * -1024 * 1024, MTRR_TYPE_WRCOMB, 1); + dev->agp->agp_mtrr = drm_mtrr_add_wc( + dev->agp->agp_info.aper_base, + dev->agp->agp_info.aper_size * + 1024 * 1024); } } return 0; diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index 7d30802..96e21bd 100644 --- a/drivers/gpu/drm/drm_stub.c +++ b/drivers/gpu/drm/drm_stub.c @@ -451,14 +451,8 @@ void drm_put_dev(struct drm_device *dev) drm_lastclose(dev); - if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) && - dev->agp && dev->agp->agp_mtrr >= 0) { - int retval; - retval = mtrr_del(dev->agp->agp_mtrr, - dev->agp->agp_info.aper_base, - dev->agp->agp_info.aper_size * 1024 * 1024); - DRM_DEBUG("mtrr_del=%d\n", retval); - } + if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) && dev->agp) + drm_mtrr_del_wc(dev->agp->agp_mtrr); if (dev->driver->unload) dev->driver->unload(dev); -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
Signed-off-by: Andy Lutomirski --- This needs careful review. I don't really know what this code does, nor do I have the hardware. (I don't understand AGP and the associated caching implications.) drivers/gpu/drm/drm_bufs.c | 11 --- drivers/gpu/drm/drm_vm.c | 13 +++-- 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index 0128147..0ae9cbb 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -210,8 +210,8 @@ static int drm_addmap_core(struct drm_device * dev, resource_size_t offset, if (drm_core_has_MTRR(dev)) { if (map->type == _DRM_FRAME_BUFFER || (map->flags & _DRM_WRITE_COMBINING)) { - map->mtrr = mtrr_add(map->offset, map->size, -MTRR_TYPE_WRCOMB, 1); + map->mtrr = + drm_mtrr_add_wc(map->offset, map->size); } } if (map->type == _DRM_REGISTERS) { @@ -451,11 +451,8 @@ int drm_rmmap_locked(struct drm_device *dev, struct drm_local_map *map) iounmap(map->handle); /* FALLTHROUGH */ case _DRM_FRAME_BUFFER: - if (drm_core_has_MTRR(dev) && map->mtrr >= 0) { - int retcode; - retcode = mtrr_del(map->mtrr, map->offset, map->size); - DRM_DEBUG("mtrr_del=%d\n", retcode); - } + if (drm_core_has_MTRR(dev)) + drm_mtrr_del_wc(map->mtrr); break; case _DRM_SHM: vfree(map->handle); diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index db7bd29..b255fd7 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -43,15 +43,16 @@ static void drm_vm_open(struct vm_area_struct *vma); static void drm_vm_close(struct vm_area_struct *vma); -static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) +static pgprot_t drm_io_prot(struct drm_local_map *map, + struct vm_area_struct *vma) { pgprot_t tmp = vm_get_page_prot(vma->vm_flags); #if defined(__i386__) || defined(__x86_64__) - if (boot_cpu_data.x86 > 3 && map_type != _DRM_AGP) { - pgprot_val(tmp) |= _PAGE_PCD; - pgprot_val(tmp) &= ~_PAGE_PWT; - } + if (map->flags & _DRM_WRITE_COMBINING) + tmp = pgprot_writecombine(tmp); + else if (map->type != _DRM_AGP) + tmp = pgprot_noncached(tmp); #elif defined(__powerpc__) pgprot_val(tmp) |= _PAGE_NO_CACHE; if (map_type == _DRM_REGISTERS) @@ -617,7 +618,7 @@ int drm_mmap_locked(struct file *filp, struct vm_area_struct *vma) case _DRM_REGISTERS: offset = drm_core_get_reg_ofs(dev); vma->vm_flags |= VM_IO; /* not in core dump */ - vma->vm_page_prot = drm_io_prot(map->type, vma); + vma->vm_page_prot = drm_io_prot(map, vma); if (io_remap_pfn_range(vma, vma->vm_start, (map->offset + offset) >> PAGE_SHIFT, vma->vm_end - vma->vm_start, -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}
This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The interface is simplified (because the base and size parameters to drm_mtrr_del never did anything) and it uses mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems that don't need them. Signed-off-by: Andy Lutomirski --- drivers/gpu/drm/ast/ast_ttm.c | 14 drivers/gpu/drm/cirrus/cirrus_ttm.c | 15 - drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 --- drivers/gpu/drm/savage/savage_bci.c | 42 +-- drivers/gpu/drm/savage/savage_drv.h | 5 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 - include/drm/drmP.h| 23 --- 8 files changed, 45 insertions(+), 91 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c index 3602731..5286c96 100644 --- a/drivers/gpu/drm/ast/ast_ttm.c +++ b/drivers/gpu/drm/ast/ast_ttm.c @@ -271,26 +271,20 @@ int ast_mm_init(struct ast_private *ast) return ret; } - ast->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0), - pci_resource_len(dev->pdev, 0), - DRM_MTRR_WC); + ast->fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 0), + pci_resource_len(dev->pdev, 0)); return 0; } void ast_mm_fini(struct ast_private *ast) { - struct drm_device *dev = ast->dev; ttm_bo_device_release(&ast->ttm.bdev); ast_ttm_global_release(ast); - if (ast->fb_mtrr >= 0) { - drm_mtrr_del(ast->fb_mtrr, -pci_resource_start(dev->pdev, 0), -pci_resource_len(dev->pdev, 0), DRM_MTRR_WC); - ast->fb_mtrr = -1; - } + drm_mtrr_del_wc(ast->fb_mtrr); + ast->fb_mtrr = -1; } void ast_ttm_placement(struct ast_bo *bo, int domain) diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c b/drivers/gpu/drm/cirrus/cirrus_ttm.c index 1413a26..95e87ee 100644 --- a/drivers/gpu/drm/cirrus/cirrus_ttm.c +++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c @@ -271,9 +271,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus) return ret; } - cirrus->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0), - pci_resource_len(dev->pdev, 0), - DRM_MTRR_WC); + cirrus->fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 0), + pci_resource_len(dev->pdev, 0)); cirrus->mm_inited = true; return 0; @@ -281,8 +280,6 @@ int cirrus_mm_init(struct cirrus_device *cirrus) void cirrus_mm_fini(struct cirrus_device *cirrus) { - struct drm_device *dev = cirrus->dev; - if (!cirrus->mm_inited) return; @@ -290,12 +287,8 @@ void cirrus_mm_fini(struct cirrus_device *cirrus) cirrus_ttm_global_release(cirrus); - if (cirrus->fb_mtrr >= 0) { - drm_mtrr_del(cirrus->fb_mtrr, -pci_resource_start(dev->pdev, 0), -pci_resource_len(dev->pdev, 0), DRM_MTRR_WC); - cirrus->fb_mtrr = -1; - } + drm_mtrr_del_wc(cirrus->fb_mtrr); + cirrus->fb_mtrr = -1; } void cirrus_ttm_placement(struct cirrus_bo *bo, int domain) diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c b/drivers/gpu/drm/mgag200/mgag200_ttm.c index 8fc9d92..62245b4 100644 --- a/drivers/gpu/drm/mgag200/mgag200_ttm.c +++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c @@ -270,26 +270,20 @@ int mgag200_mm_init(struct mga_device *mdev) return ret; } - mdev->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0), - pci_resource_len(dev->pdev, 0), - DRM_MTRR_WC); + mdev->fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 0), + pci_resource_len(dev->pdev, 0)); return 0; } void mgag200_mm_fini(struct mga_device *mdev) { - struct drm_device *dev = mdev->dev; ttm_bo_device_release(&mdev->ttm.bdev); mgag200_ttm_global_release(mdev); - if (mdev->fb_mtrr >= 0) { - drm_mtrr_del(mdev->fb_mtrr, -pci_resource_start(dev->pdev, 0), -pci_resource_len(dev->pdev, 0), DRM_MTRR_WC); - mdev->fb_mtrr = -1; - } + drm_mtrr_del_wc(mdev->fb_mtrr); + mdev->fb_mtrr = -1; } void mgag200_ttm_placement(struct mgag200_bo *bo, int domain) diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 9be9cb5..1506d78 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -377,9 +377,8 @@ nouveau_ttm_in
Re: [git pull] drm for 3.10-rc1
On Fri, May 03, 2013 at 12:57:20PM -0400, Josh Boyer wrote: >On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote: >>On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote: >>> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote: The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c: mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-next for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59: qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000) >>> >>> So something in this batch of commits breaks a Macbook Pro Retina I have >>> sitting here. If I boot a Fedora kernel based on Linux >>> v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and >>> are generally working fine. If I boot with a kernel based on Linux >>> v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get >>> nothing but static on the screen (like 1950s TV static). >>> >>> This machine is using i915 graphics, so I booted with nomodeset and did >>> the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it >>> repeated the failure with that. I've gathered a bunch of data like >>> dmesg, an intel_reg_snapshot, etc. It's all attached below. >>> >>> I'll start bisecting to see if I can narrow down the commit that broke >>> things, but I thought I would give a heads up now in case anyone has any >>> ideas. >> >>Looked through the log files and didn't see a clue. And usually DP >>tends to fail pretty noisily. So I think the bisect result would be >>interestin. Meanwhile: > >Yeah, working on that. OK. Git bisect tells me this: 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit commit 57c219633275c7e7413f8bc7be250dc092887458 Author: Daniel Vetter Date: Thu Apr 4 17:19:37 2013 +0200 drm/i915: revert eDP bpp clamping code changes The behaviour around handling the eDP bpp value from vbt has been slightly changed in commit 3600836585e3fdef0a1410d63fe5ce4015007aac Author: Daniel Vetter Date: Wed Mar 27 00:44:59 2013 +0100 drm/i915: convert DP autodither code to new infrastructure The old behaviour was that we used the plane's bpp (usually 24bpp) for computing the dp link bw, but set up the pipe with the bpp value from vbt if available. This takes the vbt bpp override into account even for the dp link bw configuration. On Paulo's hsw machine this resulted in a slower link clock and a black screen - but the mode actually /should/ fit even with the lower clock. Until we've cleared up simply stay bug-for-bug compatible with the old code. While at it, also restore a debug message lost in: commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw Cc: Paulo Zanoni Reviewed-by: Paulo Zanoni Tested-by: Paulo Zanoni Signed-off-by: Daniel Vetter :04 04 a7529c568073885302e5ca03cce5bd224e244b57 d5d860a0d4b04ad98d77abb1df774c1448bd1697 M drivers The bisect log is below. I can try to revert it directly on top of Linus' latest tree later. >>- do you have drm.debug=0xe dmesg for a working kernel, too? > >No, but I can try and get one. I haven't gotten to this quite yet. I'll try to get to it over the weekend. josh [jwboyer@obiwan linux]$ git bisect log git bisect start # good: [5a148af66932c31814e263366094b5812210b501] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc git bisect good 5a148af66932c31814e263366094b5812210b501 # bad: [ce857229e0c3adc211944a13a5579ef84fd7b4af] ipc: fix GETALL/IPC_RM race for sysv semaphores git bisect bad ce857229e0c3adc211944a13a5579ef84fd7b4af # bad: [4ed108352d9b60a723a5071ed05e722826c2b72f] drm/radeon: put UVD PLLs in bypass mode git bisect bad 4ed108352d9b60a723a5071ed05e722826c2b72f # bad: [dc652f90e088798bfa31f496ba994ddadd5d5680] drm/i915: ensure single initialization and cleanup of backlight device git bisect bad dc652f90e088798bfa31f496ba994ddadd5d5680 # good: [bb60b9695ced58768ba05b2d88fb4ee815df18f4] drm/i915: emit a hotplug event on resume git bisect good bb60b9695ced58768ba05b2d88fb4ee815df18f4 # good: [8b47047bd103c9fdb50440790a2ef17fa69a35c4] drm/i915: rip out superflous is_dp&is_cpu_edp tracking git bisect good 8b47047bd103c9fdb50440790a2ef17fa69a35c4 # bad: [4615d4c9e27eda42c3e965f208a4b4065841498c] drm/i915: Use MLC (l3$) for context objects git bisect bad 4615d4c9e27eda42c3e965f208a4b4065841498c # bad: [40c7ead980945ac96eadbd6d99b050458d797e2b] drm/i915: PCH_NOP git bisect bad 40c7ead980945ac96eadbd6d99b050458d797e2b # good: [9c8e09b7a551fc81842a2
Re: [git pull] drm for 3.10-rc1
On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote: >On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote: >> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote: >>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c: >>> >>> mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700) >>> >>>are available in the git repository at: >>> >>> git://people.freedesktop.org/~airlied/linux.git drm-next >>> >>>for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59: >>> >>> qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000) >>> >>> >> >> So something in this batch of commits breaks a Macbook Pro Retina I have >> sitting here. If I boot a Fedora kernel based on Linux >> v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and >> are generally working fine. If I boot with a kernel based on Linux >> v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get >> nothing but static on the screen (like 1950s TV static). >> >> This machine is using i915 graphics, so I booted with nomodeset and did >> the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it >> repeated the failure with that. I've gathered a bunch of data like >> dmesg, an intel_reg_snapshot, etc. It's all attached below. >> >> I'll start bisecting to see if I can narrow down the commit that broke >> things, but I thought I would give a heads up now in case anyone has any >> ideas. > >Looked through the log files and didn't see a clue. And usually DP >tends to fail pretty noisily. So I think the bisect result would be >interestin. Meanwhile: Yeah, working on that. >- do you have drm.debug=0xe dmesg for a working kernel, too? No, but I can try and get one. >- is the panel completely dead or is just the backlight on (or panel >on but backlight off)? Backlight is on. Literally static flickering on the screen. Occasionally it will flicker from static to black back and forth. But the backlight is clearly on and what is trying to render (the GDM screen normally) is just coming up as static. josh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] x86: Add mtrr_{add,del}_wc_if_needed
These MTRR helpers add a WC MTRR if PAT is disabled. Modern drivers should be using ioremap_wc, etc. to get WC memory; the MTRR is just a fallback if the system doesn't have PAT. So, rather than allocating an unnecessary MTRR even on PAT systems and having error handling spread out and handled differently by different drivers, consolidate it all and don't waste the MTRR on PAT-supporting systems. (Follow-up changes will update drivers.) This should be a simple change, a bit of a clean-up, and it will flush out any drivers that actually depend on the MTRR for write combining. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/mtrr.h | 21 arch/x86/kernel/cpu/mtrr/main.c | 53 + 2 files changed, 74 insertions(+) diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h index e235582..cc96c72 100644 --- a/arch/x86/include/asm/mtrr.h +++ b/arch/x86/include/asm/mtrr.h @@ -45,6 +45,18 @@ extern void mtrr_aps_init(void); extern void mtrr_bp_restore(void); extern int mtrr_trim_uncached_memory(unsigned long end_pfn); extern int amd_special_default_mtrr(void); + +/* + * These are for drivers (mostly video) that want to add WC MTRRs as a + * fallback if PAT is unavailable. There is no need to check for errors. + * + * The handles used by the _if_needed functions are *not* MTRR indices. + * mtrr_del_wc_if_needed(0) and mtrr_del_wc_if_needed(-1) are + * guaranteed to have no effect. + */ +extern int __must_check mtrr_add_wc_if_needed(unsigned long base, + unsigned long size); +extern void mtrr_del_wc_if_needed(int handle); # else static inline u8 mtrr_type_lookup(u64 addr, u64 end) { @@ -86,6 +98,15 @@ static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) #define set_mtrr_aps_delayed_init() do {} while (0) #define mtrr_aps_init() do {} while (0) #define mtrr_bp_restore() do {} while (0) + +static inline int __must_check mtrr_add_wc_if_needed(unsigned long base, +unsigned long size) +{ + return -ENODEV; +} +static inline void mtrr_del_wc_if_needed(int handle) +{ +} # endif #ifdef CONFIG_COMPAT diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index 726bf96..6370238 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -51,6 +51,7 @@ #include #include #include +#include #include "mtrr.h" @@ -524,6 +525,58 @@ int mtrr_del(int reg, unsigned long base, unsigned long size) } EXPORT_SYMBOL(mtrr_del); +/** + * mtrr_add_wc_if_needed - add a WC MTRR and handle errors if PAT is unavailable + * @base: Physical base address + * @size: Size of region + * + * If PAT is available, this does nothing. If PAT is unavailable, it + * attempts to add a WC MTRR covering size bytes starting at base and + * logs an error if this fails. + * + * Drivers must store the return value to pass to mtrr_del_wc_if_needed, + * but drivers should not try to interpret that return value. + */ +int mtrr_add_wc_if_needed(unsigned long base, unsigned long size) +{ + int ret; + + if (pat_enabled) { + /* +* Don't bother -- we don't need the MTRR. Return an error +* so that no one gets confused. +*/ + return -EBUSY; /* The error doesn't matter. */ + } + + ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true); + if (ret < 0) { + pr_warn("Failed to add WC MTRR for [%p-%p]; performance will suffer.", + (void *)base, (void *)(base + size - 1)); + return ret; + } + return ret + 1000; +} +EXPORT_SYMBOL(mtrr_add_wc_if_needed); + +/* + * mtrr_del_wc_if_needed - undoes mtrr_add_wc_if_needed + * @handle: Return value from mtrr_add_wc_if_needed + * + * This cleans up after mtrr_add_wc_if_needed. + * + * The API guarantees that mtrr_del_wc_if_needed(-1) and + * mtrr_del_wc_if_needed(0) do nothing. + */ +extern void mtrr_del_wc_if_needed(int handle) +{ + if (handle >= 1) { + WARN_ON(handle < 1000); + mtrr_del(handle - 1000, 0, 0); + } +} +EXPORT_SYMBOL(mtrr_del_wc_if_needed); + /* * HACK ALERT! * These should be called implicitly, but we can't yet until all the initcall -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] Clean up write-combining MTRR addition
A fair number of drivers (mostly graphics) add write-combining MTRRs. Most ignore errors and most add the MTRR even on PAT systems which don't need to use MTRRs. This series adds new functions mtrr_{add,del}_wc_if_needed and drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is enabled. I've only tested the radeon driver, since I don't have test hardware easily available for the other drivers. Benefits include: - Simpler code - No more complaints about MTRR conflict warnings on PAT systems - Eventual unexporting of the MTRR API? This series eliminates about half of the mtrr_add calls in drivers/. The series is also at: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup Andy Lutomirski (7): x86: Add mtrr_{add,del}_wc_if_needed drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework drm_mtrr_{add,del} drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs drm: Use drm_mtrr_add_wc for the AGP aperture i915: Use drm_mtrr_{add,del}_wc radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc uvesafb: Clean up MTRR code Documentation/fb/uvesafb.txt | 16 +++- arch/x86/include/asm/mtrr.h| 21 ++ arch/x86/kernel/cpu/mtrr/main.c| 53 + drivers/gpu/drm/ast/ast_ttm.c | 14 ++- drivers/gpu/drm/cirrus/cirrus_ttm.c| 15 ++-- drivers/gpu/drm/drm_bufs.c | 11 ++ drivers/gpu/drm/drm_pci.c | 8 ++-- drivers/gpu/drm/drm_stub.c | 10 + drivers/gpu/drm/drm_vm.c | 13 --- drivers/gpu/drm/i915/i915_dma.c| 43 +++-- drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 ++- drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ++- drivers/gpu/drm/radeon/radeon_object.c | 5 ++- drivers/gpu/drm/savage/savage_bci.c| 42 drivers/gpu/drm/savage/savage_drv.h| 5 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 10 ++--- drivers/video/uvesafb.c| 70 +- include/drm/drmP.h | 23 +-- include/video/uvesafb.h| 1 + 19 files changed, 169 insertions(+), 218 deletions(-) -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi
On Fri, May 3, 2013 at 2:04 AM, Rahul Sharma wrote: > On Mon, Apr 29, 2013 at 10:06 PM, Sean Paul wrote: >> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma >> wrote: >>> Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc >>> components. Currently, drivers for these components are getting registered >>> in exynos_drm_drv.c, which is meant for registration of drm sub-drivers. >>> >>> In this patch, registration of drm hdmi sub-driver and device, drivers for >>> hdmi sub-system components are moved to exynos_drm_hdmi.c. This ensures >>> limited & relevant exposure of hdmi-sub-system components to >>> exynos_drm_drv.c. >>> It will also help in handling the hdmi-sub-system diversities within the >>> exynos-common-hdmi. >>> >>> Signed-off-by: Rahul Sharma >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 ++-- >>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 14 - >>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 46 >>> -- >>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |3 ++ >>> 4 files changed, 49 insertions(+), 39 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> index ba6d995..4eabb6e 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> @@ -331,19 +331,9 @@ static int __init exynos_drm_init(void) >>> #endif >>> >>> #ifdef CONFIG_DRM_EXYNOS_HDMI >>> - ret = platform_driver_register(&hdmi_driver); >>> + ret = exynos_common_hdmi_register(); >>> if (ret < 0) >>> goto out_hdmi; >>> - ret = platform_driver_register(&mixer_driver); >>> - if (ret < 0) >>> - goto out_mixer; >>> - ret = platform_driver_register(&exynos_drm_common_hdmi_driver); >>> - if (ret < 0) >>> - goto out_common_hdmi; >>> - >>> - ret = exynos_platform_device_hdmi_register(); >>> - if (ret < 0) >>> - goto out_common_hdmi_dev; >>> #endif >>> >>> #ifdef CONFIG_DRM_EXYNOS_VIDI >>> @@ -436,13 +426,7 @@ out_vidi: >>> #endif >>> >>> #ifdef CONFIG_DRM_EXYNOS_HDMI >>> - exynos_platform_device_hdmi_unregister(); >>> -out_common_hdmi_dev: >>> - platform_driver_unregister(&exynos_drm_common_hdmi_driver); >>> -out_common_hdmi: >>> - platform_driver_unregister(&mixer_driver); >>> -out_mixer: >>> - platform_driver_unregister(&hdmi_driver); >>> + exynos_common_hdmi_unregister(); >>> out_hdmi: >>> #endif >>> >>> @@ -483,10 +467,7 @@ static void __exit exynos_drm_exit(void) >>> #endif >>> >>> #ifdef CONFIG_DRM_EXYNOS_HDMI >>> - exynos_platform_device_hdmi_unregister(); >>> - platform_driver_unregister(&exynos_drm_common_hdmi_driver); >>> - platform_driver_unregister(&mixer_driver); >>> - platform_driver_unregister(&hdmi_driver); >>> + exynos_common_hdmi_unregister(); >>> #endif >>> >>> #ifdef CONFIG_DRM_EXYNOS_VIDI >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h >>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h >>> index eaa1966..34aa36d 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h >>> @@ -319,15 +319,16 @@ int exynos_drm_subdrv_open(struct drm_device *dev, >>> struct drm_file *file); >>> void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file >>> *file); >>> >>> /* >>> - * this function registers exynos drm hdmi platform device. It ensures >>> only one >>> - * instance of the device is created. >>> + * this function registers exynos drm hdmi platform driver and singleton >>> + * device. It also registers subdrivers like mixer, hdmi and hdmiphy. >>> */ >>> -int exynos_platform_device_hdmi_register(void); >>> +int exynos_common_hdmi_register(void); >>> >>> /* >>> - * this function unregisters exynos drm hdmi platform device if it exists. >>> + * this function unregisters exynos drm hdmi platform driver and device, >>> + * subdrivers for mixer, hdmi and hdmiphy. >>> */ >>> -void exynos_platform_device_hdmi_unregister(void); >>> +void exynos_common_hdmi_unregister(void); >>> >>> /* >>> * this function registers exynos drm ipp platform device. >>> @@ -340,9 +341,6 @@ int exynos_platform_device_ipp_register(void); >>> void exynos_platform_device_ipp_unregister(void); >>> >>> extern struct platform_driver fimd_driver; >>> -extern struct platform_driver hdmi_driver; >>> -extern struct platform_driver mixer_driver; >>> -extern struct platform_driver exynos_drm_common_hdmi_driver; >>> extern struct platform_driver vidi_driver; >>> extern struct platform_driver g2d_driver; >>> extern struct platform_driver fimc_driver; >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c >>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c >>> index 060fbe8..7ab5f9f 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c >>> @@ -41,6 +41,8 @
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #3 from Tom Stellard --- Created attachment 78831 --> https://bugs.freedesktop.org/attachment.cgi?id=78831&action=edit Possible fix This patch should fix the error you were seeing with pyrit. However, it's possible you will now see a different error. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/c6712c0b/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #6 from Erdem U. Altinyurt --- Created attachment 78839 --> https://bugs.freedesktop.org/attachment.cgi?id=78839&action=edit Pyrit Debug log with Patched LLVM-trunk Hi again, I attached debug log with patch for examination. Regards, Erdem -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #5 from Erdem U. Altinyurt --- Created attachment 78838 --> https://bugs.freedesktop.org/attachment.cgi?id=78838&action=edit Pyrit Error log with Debug -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #4 from Erdem U. Altinyurt --- Hi friends, @Vincent, I will add output as an attachment. @Tom Stellard For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/ pyrit-read-only I don't patched it. Will report with your patch asap. Other programs are cgminer : https://github.com/ckolivas/cgminer And python-opencl package from suse repo that give pipe_r600.so fault. Any other program that I trued doesn't work on my card, yet. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63973] Regression in WebGL gl-vertexattribpointer.html by commit 5649f886f7602
https://bugs.freedesktop.org/show_bug.cgi?id=63973 Bryan Quigley changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Bryan Quigley --- This was reverted in commit: c4bea00fb39fb1813d220b95f0bc94e6fce8c84a -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/3c9e0362/attachment.html>
Re: [git pull] drm for 3.10-rc1
On Sat, May 4, 2013 at 3:18 AM, Josh Boyer wrote: > On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: >>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote: >>> OK. Git bisect tells me this: >>> >>> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit >>> commit 57c219633275c7e7413f8bc7be250dc092887458 >>> Author: Daniel Vetter >>> Date: Thu Apr 4 17:19:37 2013 +0200 >>> >>> drm/i915: revert eDP bpp clamping code changes >> >>Yeah, that commit is a bit dubios and for 3.11 we've already planned >>to kick it out. It tries to work around an issue on a funky >>pre-release hw. Does reverting this commit fix your issue? > > Yes, seems so. I reverted it on top of Linus tree as of commit > ce857229e0c3adc2 and things boot normally on the machine after that. Thanks for confirming, I've reverted the patch and will foward my current drm-intel-fixes tree soon to Dave. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel