Re: [PATCH 2/5] drm: Make the HPD status updates debug logs more readable
On Wed, 08 May 2013, Ville Syrjälä wrote:
> On Wed, May 08, 2013 at 05:03:31PM +0100, Damien Lespiau wrote:
>> +static const char *connector_status_str(enum drm_connector_status status)
>> +{
>> +switch (status) {
>> +case connector_status_connected:
>> +return "connected";
>> +case connector_status_disconnected:
>> +return "disconnected";
>> +default:
>> +return "unknown";
>> +}
>> +}
>
> drm_get_connector_status_name()
...and export it and use in intel_hpd_irq_event() in i915/i915_irq.c too
please.
Jani.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #17 from Thilo Cestonaro --- Hey ho, I updated to ubuntu raring latest again and the bug is still bugging me ;). Please let me know if I can provide more info so the bug can be fixed. Greetings Thilo -- 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
[PATCH] radeon: add RADEON_SURF_FMASK flag which disables 2D->1D tiling transition
I will release a new version of libdrm after this is committed.
---
radeon/radeon_surface.c |9 ++---
radeon/radeon_surface.h |1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 288b5e2..56012da 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -158,7 +158,8 @@ static void surf_minify(struct radeon_surface *surf,
surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
-if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
+if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
+!(surf->flags & RADEON_SURF_FMASK)) {
if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
surflevel->mode = RADEON_SURF_MODE_1D;
return;
@@ -564,7 +565,8 @@ static void eg_surf_minify(struct radeon_surface *surf,
surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
-if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
+if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
+!(surf->flags & RADEON_SURF_FMASK)) {
if (surflevel->nblk_x < mtilew || surflevel->nblk_y < mtileh) {
surflevel->mode = RADEON_SURF_MODE_1D;
return;
@@ -1458,7 +1460,8 @@ static void si_surf_minify_2d(struct radeon_surface *surf,
surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) /
surf->blk_d;
}
-if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
+if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
+!(surf->flags & RADEON_SURF_FMASK)) {
if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
surflevel->mode = RADEON_SURF_MODE_1D;
return;
diff --git a/radeon/radeon_surface.h b/radeon/radeon_surface.h
index 2babfd7..bbed56f 100644
--- a/radeon/radeon_surface.h
+++ b/radeon/radeon_surface.h
@@ -56,6 +56,7 @@
#define RADEON_SURF_SBUFFER (1 << 18)
#define RADEON_SURF_HAS_SBUFFER_MIPTREE (1 << 19)
#define RADEON_SURF_HAS_TILE_MODE_INDEX (1 << 20)
+#define RADEON_SURF_FMASK (1 << 21)
#define RADEON_SURF_GET(v, field) (((v) >> RADEON_SURF_ ## field ## _SHIFT)
& RADEON_SURF_ ## field ## _MASK)
#define RADEON_SURF_SET(v, field) (((v) & RADEON_SURF_ ## field ## _MASK) <<
RADEON_SURF_ ## field ## _SHIFT)
--
1.7.10.4
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #15 from Tom Stellard --- (In reply to comment #8) > (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. > I'm not sure that benchmark mode works for bfgminer. Can you try without --benchmark -- 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 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 Luke-Jr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Luke-Jr 2013-05-09 23:16:03 --- Well, like I said... this works fine with fglrx, so I'd guess the VBIOS is the only issue. Seems qemu is mixing up the VBIOS for the two video cards (emulated Cirrus + passthrough Radeon) - the first 64K of the virtualized Radeon's rom is that of the Cirrus, but the 2nd 64K is correct. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #7 from Alex Deucher 2013-05-09 23:06:32 --- That's not something I'd like to support in the driver. If you can't get the vbios, you probably have bigger problems. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 11/12] drm: DRM should depend on HAS_DMA
If NO_DMA=y: drivers/built-in.o: In function `__drm_pci_free': drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `drm_pci_alloc': drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `drm_gem_unmap_dma_buf': drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `drm_gem_map_dma_buf': drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg' Signed-off-by: Geert Uytterhoeven Cc: David Airlie Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b16c50e..38f1228 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -6,7 +6,7 @@ # menuconfig DRM tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA select HDMI select I2C select I2C_ALGOBIT -- 1.7.0.4
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #6 from Luke-Jr 2013-05-09 22:52:11 --- For the workaround, I meant the driver ignoring the vbios ROM, and instead loading it from a firmware file. ;) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 64376] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugs.freedesktop.org/show_bug.cgi?id=64376 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Alex Deucher --- Duplicate of: https://bugzilla.kernel.org/show_bug.cgi?id=57831 Not really a driver bug. You need to configure KVM to pass the proper pci rom to the VM. -- 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/20130509/d5d36893/attachment.html>
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #5 from Alex Deucher 2013-05-09 22:32:47 --- You should be able to pass the existing pci rom resource through to the VM, but I'm not really a KVM expert. Just about every graphics driver is going to need the vbios image so there is presumably a way. Might want to ask on the KVM mailing lists. These links may be useful: http://www.linux-kvm.org/page/VGA_device_assignment http://thread.gmane.org/gmane.comp.emulators.kvm.devel/71981 This isn't really a driver bug. I think this bug can be closed. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #4 from Luke-Jr 2013-05-09 22:19:33 --- Confirmed both the fglrx and radeon systems are getting the Cirrus (emulated) VGA ROM instead of the Radeon ROM. Is there a way I can override/provide the Radeon ROM to the driver as a workaround? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #14 from Aaron Watry --- > @Aaron, could you use pyrit or any other OpenCL tools with yours HD6850 > without lockup? I get the same error from pyrit (cpyrit-opencl) as you do: > awatry@veer:~/src/opencl_applications/cpyrit-opencl-0.4.0$ pyrit benchmark > Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com > This code is distributed under the GNU General Public License v3+ > > Calibrating... LLVM ERROR: Not supported instr: Reg:1046> > I'm not sure right now what instruction is causing that error. I do get lockups when I run: bfgminer -v1 --benchmark Kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2013-05-03-raring/ Mesa: git master as of yesterday LLVM: git master as of a70d02ff284, with a few additional patches on top drm: git master 040f6b015ef7d9c A simpler test case might be the piglit min() builtin CL test. Does that test lock up for you as well? You might have to run it a few times. -- 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 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #3 from Alex Deucher 2013-05-09 21:01:41 --- No both drivers need the vbios image. The closed driver either gets the vbios via some alternative means or it has some sort of fallback image if it can't find the actual vbios image. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #2 from Luke-Jr 2013-05-09 20:47:30 --- I guess I assumed that the hardware end should be working fine since fglrx works. Is needing the PCI ROM something unique to the free drivers? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC/PATCH v2 0/8] Clean up write-combining MTRR addition
On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
> 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 comment is wrong, as i said we need MTRR on PAT system for VRAM.
Cheers,
Jerome
> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
> otherwise. (Other architectures, if any, with a similar mechanism could
> implement them.)
>
> 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/.
>
> Changes from v1:
> - Helpers renamed
> - Lots of bugs fixed
>
> The series is also at:
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup/rfc_v2
>
> Andy Lutomirski (8):
> Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
> drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Remove
> drm_mtrr_{add,del}
> drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
> drm,agpgart: Use pgprot_writecombine for AGP maps and make the MTRR
> optional
> i915: Use arch_phys_wc_{add,del}
> radeon: Switch to arch_phys_wc_add and add a missing ..._del
> uvesafb: Clean up MTRR code
> drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
>
> Documentation/fb/uvesafb.txt | 16 +++-
> arch/x86/include/asm/io.h | 7
> arch/x86/include/asm/mtrr.h| 5 ++-
> arch/x86/kernel/cpu/mtrr/main.c| 48 +++
> drivers/char/agp/frontend.c| 8 ++--
> drivers/gpu/drm/ast/ast_ttm.c | 13 ++-
> drivers/gpu/drm/cirrus/cirrus_ttm.c| 15 ++--
> drivers/gpu/drm/drm_bufs.c | 17 +
> drivers/gpu/drm/drm_pci.c | 8 ++--
> drivers/gpu/drm/drm_stub.c | 10 +
> drivers/gpu/drm/drm_vm.c | 22 +--
> drivers/gpu/drm/i915/i915_dma.c| 44 +++--
> 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| 43 -
> 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 | 34 +
> include/drm/drm_os_linux.h | 16
> include/linux/io.h | 25
> include/video/uvesafb.h| 1 +
> 23 files changed, 181 insertions(+), 268 deletions(-)
>
> --
> 1.8.1.4
>
[PATCH v2 2/4] drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
The original line, WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into MGA1064_PIX_CLK_CTL. Change the line to write properly into MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use the same pattern (but work correctly), so this patch updates them all to use this new (slightly more efficient) write pattern. The WREG_DAC macro was causing the DAC_INDEX register to be set to the same value twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX is already at the value we want. Signed-off-by: Christopher Harvey Acked-by: Julia Lemire Tested-by: Julia Lemire Acked-by: Mathieu Larouche --- drivers/gpu/drm/mgag200/mgag200_mode.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c index 2d9333d..6f3b9db 100644 --- a/drivers/gpu/drm/mgag200/mgag200_mode.c +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c @@ -189,12 +189,12 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_REMHEADCTL_CLKDIS; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* select PLL Set C */ tmp = RREG8(MGAREG_MEM_MISC_READ); @@ -204,7 +204,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN | 0x80; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -212,7 +212,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_VREF_CTL); tmp = RREG8(DAC_DATA); tmp &= ~0x04; - WREG_DAC(MGA1064_VREF_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(50); @@ -236,13 +236,13 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_REMHEADCTL_CLKSL_MSK; tmp |= MGA1064_REMHEADCTL_CLKSL_PLL; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* reset dotclock rate bit */ WREG8(MGAREG_SEQ_INDEX, 1); @@ -253,7 +253,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); vcount = RREG8(MGAREG_VCOUNT); @@ -318,7 +318,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); tmp = RREG8(MGAREG_MEM_MISC_READ); tmp |= 0x3 << 2; @@ -326,12 +326,12 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_PLL_STAT); tmp = RREG8(DAC_DATA); - WREG_DAC(MGA1064_PIX_PLL_STAT, tmp & ~0x40); + WREG8(DAC_DATA, tmp & ~0x40); WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG_DAC(MGA1064_EV_PIX_PLLC_M, m); WREG_DAC(MGA1064_EV_PIX_PLLC_N, n); @@ -342,7 +342,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -350,11 +350,11 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(
[PATCH v2 1/4] drm/mgag200: Don't change unrelated registers during modeset
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
Tested-by: Julia Lemire
Acked-by: Julia Lemire
Acked-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index f988965..2d9333d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -829,11 +829,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
for (i = 0; i < sizeof(dacvalue); i++) {
- if ((i <= 0x03) ||
- (i == 0x07) ||
- (i == 0x0b) ||
- (i == 0x0f) ||
- ((i >= 0x13) && (i <= 0x17)) ||
+ if ((i <= 0x17) ||
(i == 0x1b) ||
(i == 0x1c) ||
((i >= 0x1f) && (i <= 0x29)) ||
--
1.8.1.5
[PATCH] radeon: add RADEON_SURF_FMASK flag which disables 2D->1D tiling transition
On Thu, May 9, 2013 at 5:30 PM, Marek Ol??k wrote:
> I will release a new version of libdrm after this is committed.
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c |9 ++---
> radeon/radeon_surface.h |1 +
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 288b5e2..56012da 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -158,7 +158,8 @@ static void surf_minify(struct radeon_surface *surf,
> surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
> surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
> surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
> -if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
> +if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
> +!(surf->flags & RADEON_SURF_FMASK)) {
> if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
> surflevel->mode = RADEON_SURF_MODE_1D;
> return;
> @@ -564,7 +565,8 @@ static void eg_surf_minify(struct radeon_surface *surf,
> surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
> surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
> surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
> -if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
> +if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
> +!(surf->flags & RADEON_SURF_FMASK)) {
> if (surflevel->nblk_x < mtilew || surflevel->nblk_y < mtileh) {
> surflevel->mode = RADEON_SURF_MODE_1D;
> return;
> @@ -1458,7 +1460,8 @@ static void si_surf_minify_2d(struct radeon_surface
> *surf,
> surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) /
> surf->blk_d;
> }
>
> -if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
> +if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
> +!(surf->flags & RADEON_SURF_FMASK)) {
> if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
> surflevel->mode = RADEON_SURF_MODE_1D;
> return;
> diff --git a/radeon/radeon_surface.h b/radeon/radeon_surface.h
> index 2babfd7..bbed56f 100644
> --- a/radeon/radeon_surface.h
> +++ b/radeon/radeon_surface.h
> @@ -56,6 +56,7 @@
> #define RADEON_SURF_SBUFFER (1 << 18)
> #define RADEON_SURF_HAS_SBUFFER_MIPTREE (1 << 19)
> #define RADEON_SURF_HAS_TILE_MODE_INDEX (1 << 20)
> +#define RADEON_SURF_FMASK (1 << 21)
>
> #define RADEON_SURF_GET(v, field) (((v) >> RADEON_SURF_ ## field ##
> _SHIFT) & RADEON_SURF_ ## field ## _MASK)
> #define RADEON_SURF_SET(v, field) (((v) & RADEON_SURF_ ## field ## _MASK)
> << RADEON_SURF_ ## field ## _SHIFT)
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC/PATCH v2 0/8] Clean up write-combining MTRR addition
On Thu, May 9, 2013 at 4:44 PM, Jerome Glisse wrote: > On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski > wrote: >> 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 comment is wrong, as i said we need MTRR on PAT system for VRAM. I didn't follow it last time. - If userspace is setting an MTRR directly, then it will work exactly as before -- this patch has no effect on the userspace MTRR APIs. - If userspace uses the drm map interface with DRM_FRAME_BUFFER or DRM_WRITE_COMBINING, there won't be an MTRR but the range will still be WC. - If userspace uses GEM or TTM, then everything should still use WC (TTM has explicit handling for this, which I presume is correct, and i915, the major GEM user, already doesn't set an MTRR). - If userspace does not map the range, then either the kernel driver is buggy or it doesn't matter because there's no map. Is there a case I've missed? --Andy
nouveau GF108 kernel crash in optimus mode when enabling external display output
Hello, ping also here.. any other information needed about this nouveau kernel crash? Thanks, -- Pasi On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi K?rkk?inen wrote: > Hello, > > Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS: > > $ lspci | grep VGA > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor > Graphics Controller (rev 09) > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS > 5400M] (rev a1) > > $ uname -a > Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 > UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > > I boot up the system with only laptop internal LVDS active on intel gpu, and > when in X session, > I enable the second display on nouveau gpu connected to the dock DP2/DVI > connector. > At this point the kernel crashes immediately. > > Screenshots of the kernel crash/stacktrace here: > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg > > hand-written bits from the kernel crash: > > Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO > 2349H2G/2349H2G > RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 > [nouveau] > RSP: 0018:8803298357c8 EFLAGS: 00010206 > .. > Process Xorg (pid: 1208,..) > .. > Call Trace: > .. nouveau_vm_map_sg+0xc2/0x130 [nouveau] > .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau] > .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau] > .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau] > .. nouveau_bo_move+0xa5/0x400 [nouveau] > .. ttm_bo_handle_move_mem+0x245/0x610 [ttm] > > More info from the screenshots above.. > > > dmesg drm bits before the crash: > > [0.137586] vgaarb: device added: > PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none > [0.137590] vgaarb: device added: > PCI::01:00.0,decodes=io+mem,owns=none,locks=none > [0.137591] vgaarb: loaded > [0.137591] vgaarb: bridge control possible :01:00.0 > [0.137592] vgaarb: no bridge control possible :00:02.0 > [0.529802] fb0: VESA VGA frame buffer device > [0.877212] ata1.00: supports DRM functions and may not be fully accessible > [0.878010] ata1.00: supports DRM functions and may not be fully accessible > [1.969486] [drm] Initialized drm 1.1.0 20060810 > [1.990584] VGA switcheroo: detected Optimus DSM method > \_SB_.PCI0.PEG_.VID_ handle > [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007) > [1.990874] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0c1780a1 > [1.990877] nouveau [ DEVICE][:01:00.0] Chipset: GF108 (NVC1) > [1.990878] nouveau [ DEVICE][:01:00.0] Family : NVC0 > [1.992485] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > [2.002182] nouveau [ VBIOS][:01:00.0] ... signature not found > [2.002184] nouveau [ VBIOS][:01:00.0] checking PROM for image... > [2.002243] nouveau [ VBIOS][:01:00.0] ... signature not found > [2.002245] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > [2.189928] nouveau [ VBIOS][:01:00.0] ... appears to be valid > [2.189935] nouveau [ VBIOS][:01:00.0] using image from ACPI > [2.190143] nouveau [ VBIOS][:01:00.0] BIT signature found > [2.190149] nouveau [ VBIOS][:01:00.0] version 70.08.b7.02.02 > [2.190467] nouveau [ DEVINIT][:01:00.0] adaptor not initialised > [2.190470] nouveau [ VBIOS][:01:00.0] running init tables > [2.278184] nouveau [ PFB][:01:00.0] RAM type: DDR3 > [2.278189] nouveau [ PFB][:01:00.0] RAM size: 512 MiB > [2.278192] nouveau [ PFB][:01:00.0]ZCOMP: 0 tags > [2.311802] nouveau [ DRM] VRAM: 512 MiB > [2.311805] nouveau [ DRM] GART: 512 MiB > [2.311810] nouveau [ DRM] BIT BIOS found > [2.311814] nouveau [ DRM] Bios version 70.08.b7.02 > [2.311831] nouveau [ DRM] TMDS table version 2.0 > [2.311832] nouveau [ DRM] DCB version 4.0 > [2.311833] nouveau [ DRM] DCB outp 00: 01800323 00010034 > [2.311834] nouveau [ DRM] DCB outp 01: 02811300 > [2.311835] nouveau [ DRM] DCB outp 02: 028223a6 0f220010 > [2.311836] nouveau [ DRM] DCB outp 03: 02822362 00020010 > [2.311837] nouveau [ DRM] DCB outp 04: 048333b6 0f220010 > [2.311838] nouveau [ DRM] DCB outp 05: 04833372 00020010 > [2.311839] nouveau [ DRM] DCB outp 06: 088443c6 0f220010 > [2.311840] nouveau [ DRM] DCB outp 07: 08844382 00020010 > [2.311841] nouveau [ DRM] DCB conn 00: 0040 > [2.311842] nouveau [ DRM] DCB conn 01: 0100 > [2.311843] nouveau [ DRM] DCB conn 02: 00110246 > [2.311844] nouveau [ DRM] DCB conn 03: 00220346 > [2.311845] nouveau [ DRM] DCB conn 04: 01400446 > [2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [
nouveau GF108 kernel errors and graphics corruption when enabling another output
Hello, Any comments? Should I provide more logs, or try something I didn't try yet? Thanks, -- Pasi On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi K?rkk?inen wrote: > Hello, > > Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled > in BIOS, > and only the Nvidia discreet GPU is enabled: > > $ lspci | grep VGA > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS > 5400M] (rev a1) > > > I boot up the laptop with only using the laptop internal LVDS panel, and when > in X session, > I connect DVI cable to the docking station. xrandr now correctly shows DP2 as > connected, > and when I enable the DVI display, I get these nouveau errors in the kernel > dmesg: > > [ 103.196252] nouveau [ PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040 > [ 103.196257] nouveau [ PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040 > [ 103.353160] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.353163] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.353923] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.353925] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.354257] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.354259] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.354703] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.354705] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.404091] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.404094] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.418076] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.418078] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.418567] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.418569] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.418788] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.418789] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.419164] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.419166] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.419473] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.419474] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.420080] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.420082] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.420367] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.420369] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.423674] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.423676] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.471348] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.471351] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.487327] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.487330] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.487675] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.487677] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.488222] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.488224] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.488834] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.488836] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.490843] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.490845] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > > > Should I file a freedesktop bug about this? > > DVI monitor output actually gets enabled, and I can see the desktop there, > but both the LVDS display and the DVI display are all messed up. > > For example moving a window around leaves traces of other window contents, > and the background image gets replaced with all kinds of corrupted patterns, > so graphics looks quite weird and corrupted on both displays. > > Switching back to only using the internal LVDS (disabling DVI/DP2 output) > fixes the graphics corruptions. > > > $ uname -a > Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 > UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > > > $ dmesg|grep -i nouveau > > [1.935779] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing > generic driver > [1.93
[PATCH 2/4] drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
The original line, WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into MGA1064_PIX_CLK_CTL. Change the line to write properly into MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use the same pattern (but work correctly), so this patch updates them all to use this new (slightly more efficient) write pattern. The WREG_DAC macro was causing the DAC_INDEX register to be set to the same value twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX is already at the value we want. Signed-off-by: Christopher Harvey --- drivers/gpu/drm/mgag200/mgag200_mode.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c index 2d9333d..6f3b9db 100644 --- a/drivers/gpu/drm/mgag200/mgag200_mode.c +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c @@ -189,12 +189,12 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_REMHEADCTL_CLKDIS; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* select PLL Set C */ tmp = RREG8(MGAREG_MEM_MISC_READ); @@ -204,7 +204,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN | 0x80; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -212,7 +212,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_VREF_CTL); tmp = RREG8(DAC_DATA); tmp &= ~0x04; - WREG_DAC(MGA1064_VREF_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(50); @@ -236,13 +236,13 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_REMHEADCTL_CLKSL_MSK; tmp |= MGA1064_REMHEADCTL_CLKSL_PLL; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* reset dotclock rate bit */ WREG8(MGAREG_SEQ_INDEX, 1); @@ -253,7 +253,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); vcount = RREG8(MGAREG_VCOUNT); @@ -318,7 +318,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); tmp = RREG8(MGAREG_MEM_MISC_READ); tmp |= 0x3 << 2; @@ -326,12 +326,12 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_PLL_STAT); tmp = RREG8(DAC_DATA); - WREG_DAC(MGA1064_PIX_PLL_STAT, tmp & ~0x40); + WREG8(DAC_DATA, tmp & ~0x40); WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG_DAC(MGA1064_EV_PIX_PLLC_M, m); WREG_DAC(MGA1064_EV_PIX_PLLC_N, n); @@ -342,7 +342,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -350,11 +350,11 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_PIX_PLL_STAT); tmp
[PATCH 1/4] drm/mgag200: Don't change unrelated registers during modeset
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index f988965..2d9333d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -829,11 +829,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
for (i = 0; i < sizeof(dacvalue); i++) {
- if ((i <= 0x03) ||
- (i == 0x07) ||
- (i == 0x0b) ||
- (i == 0x0f) ||
- ((i >= 0x13) && (i <= 0x17)) ||
+ if ((i <= 0x17) ||
(i == 0x1b) ||
(i == 0x1c) ||
((i >= 0x1f) && (i <= 0x29)) ||
--
1.8.1.5
[Bug 63236] kwin crashes when some desktop effects are used
https://bugs.freedesktop.org/show_bug.cgi?id=63236 Eugene changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eugene --- Not sure about LLVM, but it works fine after system upgrade: KDE Version 4.10.3 client glx vendor string: Mesa Project and SGI client glx version string: 1.4 OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 256 bits) OpenGL version string: 2.1 Mesa 9.1.2 OpenGL shading language version string: 1.20 -- 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/20130509/24a38ee8/attachment.html>
[Bug 57921] NULL pointer dereference in radeon_bo_create
https://bugzilla.kernel.org/show_bug.cgi?id=57921 --- Comment #1 from Luke-Jr 2013-05-10 00:40:46 --- Created an attachment (id=101051) --> (https://bugzilla.kernel.org/attachment.cgi?id=101051) kernel patch by workaround VBIOS issue -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57921] New: NULL pointer dereference in radeon_bo_create
https://bugzilla.kernel.org/show_bug.cgi?id=57921 Summary: NULL pointer dereference in radeon_bo_create Product: Drivers Version: 2.5 Kernel Version: 3.9.0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: luke-jr+linuxb...@utopios.org CC: alexdeuc...@gmail.com Regression: No Created an attachment (id=101041) --> (https://bugzilla.kernel.org/attachment.cgi?id=101041) Full dmesg This might be invalid, as I'm a kernel newbie trying to workaround a host issue with my hacky patch, but it *seems* to be unrelated to that issue. Any pointers would be welcome. [ 133.921546] BUG: unable to handle kernel NULL pointer dereference at 0020 [ 133.922104] IP: [] drm_pcie_get_speed_cap_mask+0x24/0xc0 [drm] [ 133.922104] *pde = [ 133.922104] Oops: [#1] PREEMPT SMP [ 133.922104] Modules linked in: radeon(+) ipv6 hwmon drm_kms_helper ttm drm evdev 8250 serial_core sr_mod i2c_piix4 button i2c_algo_bit cdrom psmouse [last unloaded: radeon] [ 133.922104] Pid: 4983, comm: modprobe Not tainted 3.9.0-gentoo #5 Bochs Bochs [ 133.922104] EIP: 0060:[] EFLAGS: 00010286 CPU: 0 [ 133.922104] EIP is at drm_pcie_get_speed_cap_mask+0x24/0xc0 [drm] [ 133.922104] EAX: f6a96000 EBX: f4073c30 ECX: EDX: f4073c30 [ 133.922104] ESI: EDI: f6b5b070 EBP: f4073c24 ESP: f4073c00 [ 133.922104] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 133.922104] CR0: 8005003b CR2: 0020 CR3: 361d8000 CR4: 06d0 [ 133.922104] DR0: DR1: DR2: DR3: [ 133.922104] DR6: 0ff0 DR7: 0400 [ 133.922104] Process modprobe (pid: 4983, ti=f4072000 task=f6b325d0 task.ti=f4072000) [ 133.922104] Stack: [ 133.922104] f4073c4c f8828415 0001 f63ca614 0001 f41e [ 133.922104] f4073c3c f886e79d 1000 f41e f41e f4073c80 [ 133.922104] f886e8c0 f6b5b070 f4073c68 f8829403 0001 0004 [ 133.922104] Call Trace: [ 133.922104] [] ? radeon_bo_create+0x145/0x180 [radeon] [ 133.922104] [] evergreen_pcie_gen2_enable+0x8d/0x1a0 [radeon] [ 133.922104] [] evergreen_startup+0x10/0x1970 [radeon] [ 133.922104] [] ? radeon_gart_table_vram_alloc+0x53/0x60 [radeon] [ 133.922104] [] ? r600_pcie_gart_init+0x59/0x60 [radeon] [ 133.922104] [] evergreen_init+0x17c/0x290 [radeon] [ 133.922104] [] radeon_device_init+0x559/0x610 [radeon] [ 133.922104] [] ? cail_mc_write+0x20/0x20 [radeon] [ 133.922104] [] radeon_driver_load_kms+0x78/0x120 [radeon] [ 133.922104] [] drm_get_pci_dev+0x12b/0x240 [drm] [ 133.922104] [] radeon_pci_probe+0x81/0xa0 [radeon] [ 133.922104] [] pci_device_probe+0x7b/0xc0 [ 133.922104] [] driver_probe_device+0x5c/0x1e0 [ 133.922104] [] ? pci_match_device+0xaa/0xc0 [ 133.922104] [] __driver_attach+0x89/0x90 [ 133.922104] [] ? driver_probe_device+0x1e0/0x1e0 [ 133.922104] [] bus_for_each_dev+0x42/0x70 [ 133.922104] [] driver_attach+0x1c/0x30 [ 133.922104] [] ? driver_probe_device+0x1e0/0x1e0 [ 133.922104] [] bus_add_driver+0xcc/0x220 [ 133.922104] [] ? pci_dev_put+0x20/0x20 [ 133.922104] [] driver_register+0x65/0x130 [ 133.922104] [] __pci_register_driver+0x2e/0x40 [ 133.922104] [] drm_pci_init+0xf5/0x100 [drm] [ 133.922104] [] radeon_init+0x52/0x6f [radeon] [ 133.922104] [] do_one_initcall+0x2f/0x170 [ 133.922104] [] ? __vunmap+0x6e/0xd0 [ 133.922104] [] ? 0xf88b9fff [ 133.922104] [] load_module+0x1ad4/0x2050 [ 133.922104] [] ? vmap_page_range_noflush+0x103/0x190 [ 133.922104] [] ? _copy_from_user+0x30/0x50 [ 133.922104] [] sys_init_module+0x7a/0xa0 [ 133.922104] [] syscall_call+0x7/0xb [ 133.922104] Code: 90 90 90 90 90 90 90 55 89 e5 83 ec 24 89 5d f8 89 d3 89 75 fc c7 02 00 00 00 00 8b 80 f0 01 00 00 85 c0 74 10 8b 40 08 8b 70 1c <0f> b7 46 20 66 3d 66 11 75 0f b8 ea ff ff ff 8b 5d f8 8b 75 fc [ 133.922104] EIP: [] drm_pcie_get_speed_cap_mask+0x24/0xc0 [drm] SS:ESP 0068:f4073c00 [ 133.922104] CR2: 0020 [ 133.977137] ---[ end trace 71ff26e878f5734b ]--- -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC/PATCH v2 0/8] Clean up write-combining MTRR addition
On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
> 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 comment is wrong, as i said we need MTRR on PAT system for VRAM.
Cheers,
Jerome
> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
> otherwise. (Other architectures, if any, with a similar mechanism could
> implement them.)
>
> 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/.
>
> Changes from v1:
> - Helpers renamed
> - Lots of bugs fixed
>
> The series is also at:
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup/rfc_v2
>
> Andy Lutomirski (8):
> Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
> drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Remove
> drm_mtrr_{add,del}
> drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
> drm,agpgart: Use pgprot_writecombine for AGP maps and make the MTRR
> optional
> i915: Use arch_phys_wc_{add,del}
> radeon: Switch to arch_phys_wc_add and add a missing ..._del
> uvesafb: Clean up MTRR code
> drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
>
> Documentation/fb/uvesafb.txt | 16 +++-
> arch/x86/include/asm/io.h | 7
> arch/x86/include/asm/mtrr.h| 5 ++-
> arch/x86/kernel/cpu/mtrr/main.c| 48 +++
> drivers/char/agp/frontend.c| 8 ++--
> drivers/gpu/drm/ast/ast_ttm.c | 13 ++-
> drivers/gpu/drm/cirrus/cirrus_ttm.c| 15 ++--
> drivers/gpu/drm/drm_bufs.c | 17 +
> drivers/gpu/drm/drm_pci.c | 8 ++--
> drivers/gpu/drm/drm_stub.c | 10 +
> drivers/gpu/drm/drm_vm.c | 22 +--
> drivers/gpu/drm/i915/i915_dma.c| 44 +++--
> 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| 43 -
> 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 | 34 +
> include/drm/drm_os_linux.h | 16
> include/linux/io.h | 25
> include/video/uvesafb.h| 1 +
> 23 files changed, 181 insertions(+), 268 deletions(-)
>
> --
> 1.8.1.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Introduce a new helper framework for buffer synchronization
cess the shared buffer will be blocked until a owner signals the shared buffer. fence_helper_signal() - this function signals a shared buffer. This means that the shared buffer access by a caller has been completed so other threads can access the shared buffer. at this moment, if there are blocked threads, they are waked up and then they commit their fences to the same shared buffer: they was blocked at fence_helper_commit_reserve() so are waked up at there. And tutorial. when setting up dma relevant registers struct fence_helper *fh; fh = fence_helper_init(NULL, NULL); fence_helper_init_reserve(fh, dmabuf, WRITE or READ or DMA); just before dma start fence_helper_commit_reserve(fh); after the completion of dma operation fence_helper_signal(fh); User interfaces. DMA_BUF_GET_FENCE - this ioctl command performs the above 1-3 steps of interfaces. a fence helper object is created by fence_helper_init() and a pointer of the fence helper object is passed to user. DMA_BUF_PUT_FENCE - this ioctl command performs the above 4 step of interfaces. the pointer made of step 1 is passed into kernel through this ioctl command. And tutorial for user process. just before cpu access struct dma_buf_fence *df; df->type = DMA_BUF_ACCESS_READ or DMA_BUF_ACCESS_WRITE; ioctl(fd, DMA_BUF_GET_FENCE, &df); after memset or memcpy ioctl(fd, DMA_BUF_PUT_FENCE, &df); Resource management. Basically, a fence helper object is created and released internally; created at fence_helper_init() and released at fence_helper_signal(). And also this can be done case by case like below, - If there was any thread blocked, its own resource is released at fence_helper_commit_reserve() after the thread was waked up. - If a blocked thread was timed out without fence_helper_singal() call; anyone hasn't signaled a shared buffer, its own resource is released at fence_helper_commit_reserve(). - if a shared buffer access by a thread was completed without blocked, its own resource is released at fence_helper_signal(). References. [1] http://lists.freedesktop.org/archives/dri-devel/2013-January/033436.html [2] http://lists.freedesktop.org/archives/dri-devel/2013-January/033434.html Thanks, Inki Dae -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130509/c2d57955/attachment.html>
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 Luke-Jr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Luke-Jr 2013-05-09 23:16:03 --- Well, like I said... this works fine with fglrx, so I'd guess the VBIOS is the only issue. Seems qemu is mixing up the VBIOS for the two video cards (emulated Cirrus + passthrough Radeon) - the first 64K of the virtualized Radeon's rom is that of the Cirrus, but the 2nd 64K is correct. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: add RADEON_SURF_FMASK flag which disables 2D->1D tiling transition
On Thu, May 9, 2013 at 5:30 PM, Marek Olšák wrote:
> I will release a new version of libdrm after this is committed.
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c |9 ++---
> radeon/radeon_surface.h |1 +
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 288b5e2..56012da 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -158,7 +158,8 @@ static void surf_minify(struct radeon_surface *surf,
> surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
> surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
> surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
> -if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
> +if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
> +!(surf->flags & RADEON_SURF_FMASK)) {
> if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
> surflevel->mode = RADEON_SURF_MODE_1D;
> return;
> @@ -564,7 +565,8 @@ static void eg_surf_minify(struct radeon_surface *surf,
> surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
> surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
> surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
> -if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
> +if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
> +!(surf->flags & RADEON_SURF_FMASK)) {
> if (surflevel->nblk_x < mtilew || surflevel->nblk_y < mtileh) {
> surflevel->mode = RADEON_SURF_MODE_1D;
> return;
> @@ -1458,7 +1460,8 @@ static void si_surf_minify_2d(struct radeon_surface
> *surf,
> surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) /
> surf->blk_d;
> }
>
> -if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
> +if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
> +!(surf->flags & RADEON_SURF_FMASK)) {
> if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
> surflevel->mode = RADEON_SURF_MODE_1D;
> return;
> diff --git a/radeon/radeon_surface.h b/radeon/radeon_surface.h
> index 2babfd7..bbed56f 100644
> --- a/radeon/radeon_surface.h
> +++ b/radeon/radeon_surface.h
> @@ -56,6 +56,7 @@
> #define RADEON_SURF_SBUFFER (1 << 18)
> #define RADEON_SURF_HAS_SBUFFER_MIPTREE (1 << 19)
> #define RADEON_SURF_HAS_TILE_MODE_INDEX (1 << 20)
> +#define RADEON_SURF_FMASK (1 << 21)
>
> #define RADEON_SURF_GET(v, field) (((v) >> RADEON_SURF_ ## field ##
> _SHIFT) & RADEON_SURF_ ## field ## _MASK)
> #define RADEON_SURF_SET(v, field) (((v) & RADEON_SURF_ ## field ## _MASK)
> << RADEON_SURF_ ## field ## _SHIFT)
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #7 from Alex Deucher 2013-05-09 23:06:32 --- That's not something I'd like to support in the driver. If you can't get the vbios, you probably have bigger problems. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #6 from Luke-Jr 2013-05-09 22:52:11 --- For the workaround, I meant the driver ignoring the vbios ROM, and instead loading it from a firmware file. ;) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64376] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugs.freedesktop.org/show_bug.cgi?id=64376 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Alex Deucher --- Duplicate of: https://bugzilla.kernel.org/show_bug.cgi?id=57831 Not really a driver bug. You need to configure KVM to pass the proper pci rom to the VM. -- 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
[RFC/PATCH v2 8/8] drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
There are no users left in drivers/gpu.
Signed-off-by: Andy Lutomirski
---
This is new in v2. The code I'm deleting is kind of gross.
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3e6cfa0..7a9fef5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -55,16 +55,13 @@
#include
#include
#include
+#include
#include
#if defined(__alpha__) || defined(__powerpc__)
#include/* For pte_wrprotect */
#endif
-#include
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
#include
#include
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 3933691..35c7c2b 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -65,22 +65,6 @@ struct no_agp_kern {
#define DRM_AGP_KERNstruct no_agp_kern
#endif
-#if !(__OS_HAS_MTRR)
-static __inline__ int mtrr_add(unsigned long base, unsigned long size,
- unsigned int type, char increment)
-{
- return -ENODEV;
-}
-
-static __inline__ int mtrr_del(int reg, unsigned long base, unsigned long size)
-{
- return -ENODEV;
-}
-
-#define MTRR_TYPE_WRCOMB 1
-
-#endif
-
/** Other copying of data to kernel space */
#define DRM_COPY_FROM_USER(arg1, arg2, arg3) \
copy_from_user(arg1, arg2, arg3)
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC/PATCH v2 7/8] 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
---
Documentation/fb/uvesafb.txt | 16 --
drivers/video/uvesafb.c | 70 +++-
include/video/uvesafb.h | 1 +
3 files changed, 23 insertions(+), 64 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..8701f96 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -24,9 +24,6 @@
#ifdef CONFIG_X86
#include
#endif
-#ifdef CONFIG_MTRR
-#include
-#endif
#include "edid.h"
static struct cb_id uvesafb_cn_id = {
@@ -1540,67 +1537,30 @@ 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 = arch_phys_wc_add(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_base = ioremap(info->fix.smem_start, info->fix.smem_len);
-#endif /* CONFIG_X86 */
+ info->screen_base = ioremap_wc(info->fix.smem_start,
info->fix.smem_len);
}
static ssize_t
[RFC/PATCH v2 6/8] radeon: Switch to arch_phys_wc_add and add a missing ..._del
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..15cd34b 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 = arch_phys_wc_add(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);
+ arch_phys_wc_del(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 0/4] mgag200 fixes
Christopher Harvey writes: > The Following should be CC'd to stable: > * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register > * drm/mgag200: Fix framebuffer base address programming > > The others are bug fixes, but aren't critical. I'm sitting on some > hardware cursor code that depends on all of these patches before it > can go in. I'm aiming for 3.11 for the hardware cursor support. > > thanks, > Christopher Harvey (4): > drm/mgag200: Don't change unrelated registers during modeset > drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register > drm/mgag200: Convert counter delays to jiffies > drm/mgag200: Fix framebuffer base address programming > > drivers/gpu/drm/mgag200/mgag200_mode.c | 90 > -- > 1 file changed, 52 insertions(+), 38 deletions(-) please ignore this, version 2 has been posted. -C
[RFC/PATCH v2 5/8] i915: Use arch_phys_wc_{add,del}
i915 open-coded logic that was essentially equivalent to the new API.
Signed-off-by: Andy Lutomirski
---
Changes from v1: More cleanup
drivers/gpu/drm/i915/i915_dma.c | 44 ++---
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4fa6beb..cfdfb45 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#define LP_RING(d) (&((struct drm_i915_private *)(d))->ring[RCS])
@@ -1393,29 +1392,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 +1528,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 = arch_phys_wc_add(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 +1632,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;
- }
+ arch_phys_wc_del(dev_priv->mm.gtt_mtrr);
+ dev_priv->mm.gtt_mtrr = 0;
io_mapping_free(dev_priv->gtt.mappable);
out_rmmap:
pci_iounmap(dev->pdev, dev_priv->regs);
@@ -1697,12 +1669,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;
- }
+ arch_phys_wc_del(dev_priv->mm.gtt_mtrr);
+ dev_priv->mm.gtt_mtrr = 0;
acpi_video_unregister();
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC/PATCH v2 4/8] drm, agpgart: Use pgprot_writecombine for AGP maps and make the MTRR optional
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior just requests WC explicitly for all AGP maps.
If there is any code out there that expects cacheable access to the
AGP aperture (because the drm driver doesn't request an MTRR or
because it's using /dev/agpgart directly), then it will now end up
with a UC or WC mapping, depending on the architecture and PAT
availability. But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Signed-off-by: Andy Lutomirski
---
It's conceivable that libpciaccess could have issues with this due to
memtype conflicts, but I think this is unlikely (as long as a WC
mapping gets there first, I think the conflict resolution rules will
all work out). In any case, everything that maps the AGP aperture
ought to be using /dev/agpgart or the DRM API, in which case
everything should be okay.
I don't have anything with an AGP slot to test AFAIK.
drivers/char/agp/frontend.c | 8 +---
drivers/gpu/drm/drm_pci.c | 8
drivers/gpu/drm/drm_stub.c | 10 ++
drivers/gpu/drm/drm_vm.c| 11 ---
4 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c
index 2e04433..1b19239 100644
--- a/drivers/char/agp/frontend.c
+++ b/drivers/char/agp/frontend.c
@@ -603,7 +603,8 @@ static int agp_mmap(struct file *file, struct
vm_area_struct *vma)
vma->vm_ops = kerninfo.vm_ops;
} else if (io_remap_pfn_range(vma, vma->vm_start,
(kerninfo.aper_base + offset) >> PAGE_SHIFT,
- size, vma->vm_page_prot)) {
+ size,
+ pgprot_writecombine(vma->vm_page_prot))) {
goto out_again;
}
mutex_unlock(&(agp_fe.agp_mutex));
@@ -618,8 +619,9 @@ static int agp_mmap(struct file *file, struct
vm_area_struct *vma)
if (kerninfo.vm_ops) {
vma->vm_ops = kerninfo.vm_ops;
} else if (io_remap_pfn_range(vma, vma->vm_start,
- kerninfo.aper_base >> PAGE_SHIFT,
- size, vma->vm_page_prot)) {
+ kerninfo.aper_base >> PAGE_SHIFT,
+ size,
+ pgprot_writecombine(vma->vm_page_prot))) {
goto out_again;
}
mutex_unlock(&(agp_fe.agp_mutex));
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..d0f6699 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 = arch_phys_wc_add(
+ 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..9e2acdf 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)
+ arch_phys_wc_del(dev->agp->agp_mtrr);
if (dev->driver->unload)
dev->driver->unload(dev);
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 163f436..b1e4ec8 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -49,13 +49,10 @@ static pgprot_t drm_io_prot(struct drm_local_map *map,
pgprot_t tmp = vm_get_page_prot(vma->vm_flags);
#if defined(__i386__) || defined(__x86_64__
[RFC/PATCH v2 3/8] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine.
The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.
The DRM_AGP case is unchanged for now.
Signed-off-by: Andy Lutomirski
---
Unlike v1, this should work well even for drivers that call
drmAddMap from userspace. I didn't understand how the flags were
supposed to work last time around.
drivers/gpu/drm/drm_bufs.c | 17 +
drivers/gpu/drm/drm_vm.c | 23 +++
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 0128147..0190fce 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -210,12 +210,16 @@ 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 =
+ arch_phys_wc_add(map->offset,
map->size);
}
}
if (map->type == _DRM_REGISTERS) {
- map->handle = ioremap(map->offset, map->size);
+ if (map->flags & _DRM_WRITE_COMBINING)
+ map->handle = ioremap_wc(map->offset,
+map->size);
+ else
+ map->handle = ioremap(map->offset, map->size);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -451,11 +455,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))
+ arch_phys_wc_del(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..163f436 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -43,14 +43,18 @@
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->type != _DRM_AGP) {
+ if (map->type == _DRM_FRAME_BUFFER ||
+ map->flags & _DRM_WRITE_COMBINING)
+ tmp = pgprot_writecombine(tmp);
+ else
+ tmp = pgprot_noncached(tmp);
}
#elif defined(__powerpc__)
pgprot_val(tmp) |= _PAGE_NO_CACHE;
@@ -250,13 +254,8 @@ static void drm_vm_shm_close(struct vm_area_struct *vma)
switch (map->type) {
case _DRM_REGISTERS:
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))
+ arch_phys_wc_del(map->mtrr);
iounmap(map->handle);
break;
case _DRM_SHM:
@@ -617,7 +616,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 |= V
[RFC/PATCH v2 2/8] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Remove drm_mtrr_{add, del}
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/ast/ast_ttm.c | 13 +++
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 | 43 ---
drivers/gpu/drm/savage/savage_drv.h | 5 +---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10
include/drm/drmP.h| 29 ---
8 files changed, 35 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 3602731..c4574fd 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -271,26 +271,19 @@ 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 = arch_phys_wc_add(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;
- }
+ arch_phys_wc_del(ast->fb_mtrr);
}
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..09f06d3 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 = arch_phys_wc_add(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;
- }
+ arch_phys_wc_del(cirrus->fb_mtrr);
+ cirrus->fb_mtrr = 0;
}
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..5c6f3c8 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 = arch_phys_wc_add(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;
- }
+ arch_phys_wc_del(mdev->fb_mtrr);
+ mdev->fb_mtrr = 0;
}
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..63fa6a5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -377,9 +377,8 @@ nouveau_ttm_init(struct nouveau_drm *drm)
return ret;
[RFC/PATCH v2 1/8] Add arch_phys_wc_{add, del} to manipulate WC MTRRs if needed
Several drivers currently use mtrr_add through various #ifdef guards
and/or drm wrappers. The vast majority of them want to add WC MTRRs
on x86 systems and don't actually need the MTRR if PAT (i.e.
ioremap_wc, etc) are working.
arch_phys_wc_add and arch_phys_wc_del are new functions, available
on all architectures and configurations, that add WC MTRRs on x86 if
needed (and handle errors) and do nothing at all otherwise. They're
also easier to use than mtrr_add and mtrr_del, so the call sites can
be simplified.
As an added benefit, this will avoid wasting MTRRs and possibly
warning pointlessly on PAT-supporting systems.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/io.h | 7 ++
arch/x86/include/asm/mtrr.h | 5 -
arch/x86/kernel/cpu/mtrr/main.c | 48 +
include/linux/io.h | 25 +
4 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d8e8eef..34f69cb 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -345,4 +345,11 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec
*vec1,
#define IO_SPACE_LIMIT 0x
+#ifdef CONFIG_MTRR
+extern int __must_check arch_phys_wc_add(unsigned long base,
+unsigned long size);
+extern void arch_phys_wc_del(int handle);
+#define arch_phys_wc_add arch_phys_wc_add
+#endif
+
#endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index e235582..10d0fba 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -26,7 +26,10 @@
#include
-/* The following functions are for use by other drivers */
+/*
+ * The following functions are for use by other drivers that cannot use
+ * arch_phys_wc_add and arch_phys_wc_del.
+ */
# ifdef CONFIG_MTRR
extern u8 mtrr_type_lookup(u64 addr, u64 end);
extern void mtrr_save_fixed_ranges(void *);
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 726bf96..23bd49a 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,53 @@ int mtrr_del(int reg, unsigned long base, unsigned long
size)
}
EXPORT_SYMBOL(mtrr_del);
+/**
+ * arch_phys_wc_add - 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 arch_phys_wc_add(unsigned long base, unsigned long size)
+{
+ int ret;
+
+ if (pat_enabled)
+ return 0; /* Success! (We don't need to do anything.) */
+
+ ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true);
+ if (ret < 0) {
+ pr_warn("Failed to add WC MTRR for [%p-%p]; performance may
suffer.",
+ (void *)base, (void *)(base + size - 1));
+ return ret;
+ }
+ return ret + 1000;
+}
+EXPORT_SYMBOL(arch_phys_wc_add);
+
+/*
+ * arch_phys_wc_del - undoes arch_phys_wc_add
+ * @handle: Return value from arch_phys_wc_add
+ *
+ * This cleans up after mtrr_add_wc_if_needed.
+ *
+ * The API guarantees that mtrr_del_wc_if_needed(error code) and
+ * mtrr_del_wc_if_needed(0) do nothing.
+ */
+extern void arch_phys_wc_del(int handle)
+{
+ if (handle >= 1) {
+ WARN_ON(handle < 1000);
+ mtrr_del(handle - 1000, 0, 0);
+ }
+}
+EXPORT_SYMBOL(arch_phys_wc_del);
+
/*
* HACK ALERT!
* These should be called implicitly, but we can't yet until all the initcall
diff --git a/include/linux/io.h b/include/linux/io.h
index 069e407..f4f42fa 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -76,4 +76,29 @@ void devm_ioremap_release(struct device *dev, void *res);
#define arch_has_dev_port() (1)
#endif
+/*
+ * Some systems (x86 without PAT) have a somewhat reliable way to mark a
+ * physical address range such that uncached mappings will actually
+ * end up write-combining. This facility should be used in conjunction
+ * with pgprot_writecombine, ioremap-wc, or set_memory_wc, since it has
+ * no effect if the per-page mechanisms are functional.
+ * (On x86 without PAT, these functions manipulate MTRRs.)
+ *
+ * arch_phys_del_wc(0) or arch_phys_del_wc(any error code) is guaranteed
+ * to have no effect.
+ */
+#ifndef arch_phys_wc_add
+static inline int __must_check arch_phys_wc_add(unsigned long base,
+ unsigned long size)
+{
+ return 0; /* It worked (i.e. did nothing). */
+}
+
+static inline void arch_phys_wc_del(int hand
[RFC/PATCH v2 0/8] 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 arch_phys_wc_{add,del} that, on PAT-less
x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
otherwise. (Other architectures, if any, with a similar mechanism could
implement them.)
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/.
Changes from v1:
- Helpers renamed
- Lots of bugs fixed
The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup/rfc_v2
Andy Lutomirski (8):
Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Remove
drm_mtrr_{add,del}
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
drm,agpgart: Use pgprot_writecombine for AGP maps and make the MTRR
optional
i915: Use arch_phys_wc_{add,del}
radeon: Switch to arch_phys_wc_add and add a missing ..._del
uvesafb: Clean up MTRR code
drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
Documentation/fb/uvesafb.txt | 16 +++-
arch/x86/include/asm/io.h | 7
arch/x86/include/asm/mtrr.h| 5 ++-
arch/x86/kernel/cpu/mtrr/main.c| 48 +++
drivers/char/agp/frontend.c| 8 ++--
drivers/gpu/drm/ast/ast_ttm.c | 13 ++-
drivers/gpu/drm/cirrus/cirrus_ttm.c| 15 ++--
drivers/gpu/drm/drm_bufs.c | 17 +
drivers/gpu/drm/drm_pci.c | 8 ++--
drivers/gpu/drm/drm_stub.c | 10 +
drivers/gpu/drm/drm_vm.c | 22 +--
drivers/gpu/drm/i915/i915_dma.c| 44 +++--
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| 43 -
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 | 34 +
include/drm/drm_os_linux.h | 16
include/linux/io.h | 25
include/video/uvesafb.h| 1 +
23 files changed, 181 insertions(+), 268 deletions(-)
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] *** SUBJECT HERE ***
I forgot to include some acked and tested-by lines in v1 of this series. No code changes in v2. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to jiffies drm/mgag200: Fix framebuffer base address programming drivers/gpu/drm/mgag200/mgag200_mode.c | 90 -- 1 file changed, 52 insertions(+), 38 deletions(-) -- 1.8.1.5
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #5 from Alex Deucher 2013-05-09 22:32:47 --- You should be able to pass the existing pci rom resource through to the VM, but I'm not really a KVM expert. Just about every graphics driver is going to need the vbios image so there is presumably a way. Might want to ask on the KVM mailing lists. These links may be useful: http://www.linux-kvm.org/page/VGA_device_assignment http://thread.gmane.org/gmane.comp.emulators.kvm.devel/71981 This isn't really a driver bug. I think this bug can be closed. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #4 from Luke-Jr 2013-05-09 22:19:33 --- Confirmed both the fglrx and radeon systems are getting the Cirrus (emulated) VGA ROM instead of the Radeon ROM. Is there a way I can override/provide the Radeon ROM to the driver as a workaround? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ 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 #9 from Dave Witbrodt ---
Noting Benjamin's experience with EFI in comment 8, I took a look at my 3
machines on which I am trying the UVD support. I have a laptop, a desktop, and
another (inexpensive) desktop which I use as a file server.
Desktop: JUNIPER, no EFI support (several years old)
CONFIG_EXTRA_FIRMWARE="radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin
radeon/JUNIPER_rlc.bin radeon/CYPRESS_uvd.bin ..."
Boot results:
[0.816646] [drm] UVD initialized successfully.
Laptop: SUMO, no EFI support (not old, but not new enough for EFI)
CONFIG_EXTRA_FIRMWARE="radeon/SUMO_rlc.bin radeon/SUMO_me.bin
radeon/SUMO_pfp.bin radeon/SUMO_uvd.bin ..."
Boot results:
[1.650383] [drm] UVD initialized successfully.
"fileserver": SUMO2, EFI support (newest motherboard of the 3)
CONFIG_EXTRA_FIRMWARE="radeon/SUMO_rlc.bin radeon/SUMO2_me.bin
radeon/SUMO2_pfp.bin radeon/SUMO_uvd.bin"
Boot results:
[ 11.575783] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).
See comment 6 above.
This looks like further evidence of EFI involvement with the problem. I cannot
see any BIOS settings that would allow me to alter EFI support on my
"fileserver" motherboard. The only option I could find had to do with PCI ROM
support ("legacy" vs "EFI"), but this had defaulted to "legacy" when I
installed the motherboard and I never touched it.
--
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/20130509/19e08833/attachment.html>
[PATCH] radeon: add RADEON_SURF_FMASK flag which disables 2D->1D tiling transition
I will release a new version of libdrm after this is committed.
---
radeon/radeon_surface.c |9 ++---
radeon/radeon_surface.h |1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 288b5e2..56012da 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -158,7 +158,8 @@ static void surf_minify(struct radeon_surface *surf,
surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
-if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
+if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
+!(surf->flags & RADEON_SURF_FMASK)) {
if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
surflevel->mode = RADEON_SURF_MODE_1D;
return;
@@ -564,7 +565,8 @@ static void eg_surf_minify(struct radeon_surface *surf,
surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) / surf->blk_w;
surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) / surf->blk_h;
surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) / surf->blk_d;
-if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
+if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
+!(surf->flags & RADEON_SURF_FMASK)) {
if (surflevel->nblk_x < mtilew || surflevel->nblk_y < mtileh) {
surflevel->mode = RADEON_SURF_MODE_1D;
return;
@@ -1458,7 +1460,8 @@ static void si_surf_minify_2d(struct radeon_surface *surf,
surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) /
surf->blk_d;
}
-if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D) {
+if (surf->nsamples == 1 && surflevel->mode == RADEON_SURF_MODE_2D &&
+!(surf->flags & RADEON_SURF_FMASK)) {
if (surflevel->nblk_x < xalign || surflevel->nblk_y < yalign) {
surflevel->mode = RADEON_SURF_MODE_1D;
return;
diff --git a/radeon/radeon_surface.h b/radeon/radeon_surface.h
index 2babfd7..bbed56f 100644
--- a/radeon/radeon_surface.h
+++ b/radeon/radeon_surface.h
@@ -56,6 +56,7 @@
#define RADEON_SURF_SBUFFER (1 << 18)
#define RADEON_SURF_HAS_SBUFFER_MIPTREE (1 << 19)
#define RADEON_SURF_HAS_TILE_MODE_INDEX (1 << 20)
+#define RADEON_SURF_FMASK (1 << 21)
#define RADEON_SURF_GET(v, field) (((v) >> RADEON_SURF_ ## field ## _SHIFT)
& RADEON_SURF_ ## field ## _MASK)
#define RADEON_SURF_SET(v, field) (((v) & RADEON_SURF_ ## field ## _MASK) <<
RADEON_SURF_ ## field ## _SHIFT)
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm: Use names of ioctls in debug traces
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
[drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]
into:
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_THROTTLE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_CREATE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_TILING
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, IOCTL_MODE_ADDFB
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_MMAP_GTT
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]
v2: drm_ioctls is now a constant (Ville Syrj?l?)
Signed-off-by: Chris Cummins
---
drivers/gpu/drm/drm_drv.c | 20 +---
include/drm/drmP.h| 3 ++-
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 0ba4dcb..dfa228b 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,7 +57,7 @@ static int drm_version(struct drm_device *dev, void *data,
struct drm_file *file_priv);
#define DRM_IOCTL_DEF(ioctl, _func, _flags) \
- [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags,
.cmd_drv = 0}
+ [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags,
.cmd_drv = 0, .name = #ioctl}
/** Ioctl table */
static const struct drm_ioctl_desc drm_ioctls[] = {
@@ -375,7 +375,7 @@ long drm_ioctl(struct file *filp,
{
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev;
- const struct drm_ioctl_desc *ioctl;
+ const struct drm_ioctl_desc *ioctl = NULL;
drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
int retcode = -EINVAL;
@@ -392,11 +392,6 @@ long drm_ioctl(struct file *filp,
atomic_inc(&dev->counts[_DRM_STAT_IOCTLS]);
++file_priv->ioctl_count;
- DRM_DEBUG("pid=%d, cmd=0x%02x, nr=0x%02x, dev 0x%lx, auth=%d\n",
- task_pid_nr(current), cmd, nr,
- (long)old_encode_dev(file_priv->minor->device),
- file_priv->authenticated);
-
if ((nr >= DRM_CORE_IOCTL_COUNT) &&
((nr < DRM_COMMAND_BASE) || (nr >= DRM_COMMAND_END)))
goto err_i1;
@@ -416,6 +411,11 @@ long drm_ioctl(struct file *filp,
} else
goto err_i1;
+ DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
+ task_pid_nr(current),
+ (long)old_encode_dev(file_priv->minor->device),
+ file_priv->authenticated, ioctl->name);
+
/* Do not trust userspace, use our own definition */
func = ioctl->func;
/* is there a local override? */
@@ -470,6 +470,12 @@ long drm_ioctl(struct file *filp,
}
err_i1:
+ if (!ioctl)
+ DRM_DEBUG("invalid iotcl: pid=%d, dev=0x%lx, auth=%d,
cmd=0x%02x, nr=0x%02x\n",
+ task_pid_nr(current),
+ (long)old_encode_dev(file_priv->minor->device),
+ file_priv->authenticated, cmd, nr);
+
if (kdata != stack_kdata)
kfree(kdata);
atomic_dec(&dev->ioctl_count);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..379787c 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -316,6 +316,7 @@ struct drm_ioctl_desc {
int flags;
drm_ioctl_t *func;
unsigned int cmd_drv;
+ const char *name;
};
/**
@@ -324,7 +325,7 @@ struct drm_ioctl_desc {
*/
#define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)\
- [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
.flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl}
+ [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
.flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl, .name = #ioctl}
struct drm_magic_entry {
struct list_head head;
--
1.8.1.4
[PATCH 11/12] drm: DRM should depend on HAS_DMA
If NO_DMA=y: drivers/built-in.o: In function `__drm_pci_free': drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `drm_pci_alloc': drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `drm_gem_unmap_dma_buf': drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `drm_gem_map_dma_buf': drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg' Signed-off-by: Geert Uytterhoeven Cc: David Airlie Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b16c50e..38f1228 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -6,7 +6,7 @@ # menuconfig DRM tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA select HDMI select I2C select I2C_ALGOBIT -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #3 from Alex Deucher 2013-05-09 21:01:41 --- No both drivers need the vbios image. The closed driver either gets the vbios via some alternative means or it has some sort of fallback image if it can't find the actual vbios image. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] mgag200 fixes
The Following should be CC'd to stable: * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register * drm/mgag200: Fix framebuffer base address programming The others are bug fixes, but aren't critical. I'm sitting on some hardware cursor code that depends on all of these patches before it can go in. I'm aiming for 3.11 for the hardware cursor support. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to jiffies drm/mgag200: Fix framebuffer base address programming drivers/gpu/drm/mgag200/mgag200_mode.c | 90 -- 1 file changed, 52 insertions(+), 38 deletions(-) -- 1.8.1.5
[PATCH] qxl: fix bug with object eviction and update area
From: Dave Airlie
if the surface is evicted, this validation will happen
to the wrong place, I noticed this with other work I was
doing, haven't seen it go wrong in practice.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 04b64f9..6db7370 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -294,6 +294,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev,
void *data,
goto out;
if (!qobj->pin_count) {
+ qxl_ttm_placement_from_domain(qobj, qobj->type);
ret = ttm_bo_validate(&qobj->tbo, &qobj->placement,
true, false);
if (unlikely(ret))
--
1.8.2.1
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 --- Comment #2 from Luke-Jr 2013-05-09 20:47:30 --- I guess I assumed that the hardware end should be working fine since fglrx works. Is needing the PCI ROM something unique to the free drivers? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64376] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugs.freedesktop.org/show_bug.cgi?id=64376 --- Comment #1 from Alex Deucher --- You need to make sure the VM has access to the PCI rom. -- 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/20130509/bd98261e/attachment.html>
[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2013-05-09 13:17:59 --- You need to make sure the VM has access to the PCI rom. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC/PATCH v2 8/8] drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
There are no users left in drivers/gpu.
Signed-off-by: Andy Lutomirski
---
This is new in v2. The code I'm deleting is kind of gross.
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3e6cfa0..7a9fef5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -55,16 +55,13 @@
#include
#include
#include
+#include
#include
#if defined(__alpha__) || defined(__powerpc__)
#include/* For pte_wrprotect */
#endif
-#include
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
#include
#include
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 3933691..35c7c2b 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -65,22 +65,6 @@ struct no_agp_kern {
#define DRM_AGP_KERNstruct no_agp_kern
#endif
-#if !(__OS_HAS_MTRR)
-static __inline__ int mtrr_add(unsigned long base, unsigned long size,
- unsigned int type, char increment)
-{
- return -ENODEV;
-}
-
-static __inline__ int mtrr_del(int reg, unsigned long base, unsigned long size)
-{
- return -ENODEV;
-}
-
-#define MTRR_TYPE_WRCOMB 1
-
-#endif
-
/** Other copying of data to kernel space */
#define DRM_COPY_FROM_USER(arg1, arg2, arg3) \
copy_from_user(arg1, arg2, arg3)
--
1.8.1.4
[RFC/PATCH v2 7/8] 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
---
Documentation/fb/uvesafb.txt | 16 --
drivers/video/uvesafb.c | 70 +++-
include/video/uvesafb.h | 1 +
3 files changed, 23 insertions(+), 64 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..8701f96 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -24,9 +24,6 @@
#ifdef CONFIG_X86
#include
#endif
-#ifdef CONFIG_MTRR
-#include
-#endif
#include "edid.h"
static struct cb_id uvesafb_cn_id = {
@@ -1540,67 +1537,30 @@ 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 = arch_phys_wc_add(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_base = ioremap(info->fix.smem_start, info->fix.smem_len);
-#endif /* CONFIG_X86 */
+ info->screen_base = ioremap_wc(info->fix.smem_start,
info->fix.smem_len);
}
static ssize_t uvesafb_sho
[RFC/PATCH v2 6/8] radeon: Switch to arch_phys_wc_add and add a missing ..._del
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..15cd34b 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 = arch_phys_wc_add(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);
+ arch_phys_wc_del(rdev->mc.vram_mtrr);
}
void radeon_bo_list_add_object(struct radeon_bo_list *lobj,
--
1.8.1.4
[RFC/PATCH v2 5/8] i915: Use arch_phys_wc_{add,del}
i915 open-coded logic that was essentially equivalent to the new API.
Signed-off-by: Andy Lutomirski
---
Changes from v1: More cleanup
drivers/gpu/drm/i915/i915_dma.c | 44 ++---
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4fa6beb..cfdfb45 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#define LP_RING(d) (&((struct drm_i915_private *)(d))->ring[RCS])
@@ -1393,29 +1392,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 +1528,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 = arch_phys_wc_add(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 +1632,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;
- }
+ arch_phys_wc_del(dev_priv->mm.gtt_mtrr);
+ dev_priv->mm.gtt_mtrr = 0;
io_mapping_free(dev_priv->gtt.mappable);
out_rmmap:
pci_iounmap(dev->pdev, dev_priv->regs);
@@ -1697,12 +1669,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;
- }
+ arch_phys_wc_del(dev_priv->mm.gtt_mtrr);
+ dev_priv->mm.gtt_mtrr = 0;
acpi_video_unregister();
--
1.8.1.4
[RFC/PATCH v2 4/8] drm, agpgart: Use pgprot_writecombine for AGP maps and make the MTRR optional
I'm not sure I understand the intent of the previous behavior. mmap
on /dev/agpgart and DRM_AGP maps had no cache flags set, so they
would be fully cacheable. But the DRM code (most of the time) would
add a write-combining MTRR that would change the effective memory
type to WC.
The new behavior just requests WC explicitly for all AGP maps.
If there is any code out there that expects cacheable access to the
AGP aperture (because the drm driver doesn't request an MTRR or
because it's using /dev/agpgart directly), then it will now end up
with a UC or WC mapping, depending on the architecture and PAT
availability. But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Signed-off-by: Andy Lutomirski
---
It's conceivable that libpciaccess could have issues with this due to
memtype conflicts, but I think this is unlikely (as long as a WC
mapping gets there first, I think the conflict resolution rules will
all work out). In any case, everything that maps the AGP aperture
ought to be using /dev/agpgart or the DRM API, in which case
everything should be okay.
I don't have anything with an AGP slot to test AFAIK.
drivers/char/agp/frontend.c | 8 +---
drivers/gpu/drm/drm_pci.c | 8
drivers/gpu/drm/drm_stub.c | 10 ++
drivers/gpu/drm/drm_vm.c| 11 ---
4 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c
index 2e04433..1b19239 100644
--- a/drivers/char/agp/frontend.c
+++ b/drivers/char/agp/frontend.c
@@ -603,7 +603,8 @@ static int agp_mmap(struct file *file, struct
vm_area_struct *vma)
vma->vm_ops = kerninfo.vm_ops;
} else if (io_remap_pfn_range(vma, vma->vm_start,
(kerninfo.aper_base + offset) >> PAGE_SHIFT,
- size, vma->vm_page_prot)) {
+ size,
+ pgprot_writecombine(vma->vm_page_prot))) {
goto out_again;
}
mutex_unlock(&(agp_fe.agp_mutex));
@@ -618,8 +619,9 @@ static int agp_mmap(struct file *file, struct
vm_area_struct *vma)
if (kerninfo.vm_ops) {
vma->vm_ops = kerninfo.vm_ops;
} else if (io_remap_pfn_range(vma, vma->vm_start,
- kerninfo.aper_base >> PAGE_SHIFT,
- size, vma->vm_page_prot)) {
+ kerninfo.aper_base >> PAGE_SHIFT,
+ size,
+ pgprot_writecombine(vma->vm_page_prot))) {
goto out_again;
}
mutex_unlock(&(agp_fe.agp_mutex));
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..d0f6699 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 = arch_phys_wc_add(
+ 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..9e2acdf 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)
+ arch_phys_wc_del(dev->agp->agp_mtrr);
if (dev->driver->unload)
dev->driver->unload(dev);
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 163f436..b1e4ec8 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -49,13 +49,10 @@ static pgprot_t drm_io_prot(struct drm_local_map *map,
pgprot_t tmp = vm_get_page_prot(vma->vm_flags);
#if defined(__i386__) || defined(__x86_64__)
-
[RFC/PATCH v2 3/8] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
MTRR being added but the actual mappings being created as UC-.
Now these mappings have the MTRR added only if needed, but they will
be mapped with pgprot_writecombine.
The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.
The DRM_AGP case is unchanged for now.
Signed-off-by: Andy Lutomirski
---
Unlike v1, this should work well even for drivers that call
drmAddMap from userspace. I didn't understand how the flags were
supposed to work last time around.
drivers/gpu/drm/drm_bufs.c | 17 +
drivers/gpu/drm/drm_vm.c | 23 +++
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 0128147..0190fce 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -210,12 +210,16 @@ 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 =
+ arch_phys_wc_add(map->offset,
map->size);
}
}
if (map->type == _DRM_REGISTERS) {
- map->handle = ioremap(map->offset, map->size);
+ if (map->flags & _DRM_WRITE_COMBINING)
+ map->handle = ioremap_wc(map->offset,
+map->size);
+ else
+ map->handle = ioremap(map->offset, map->size);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -451,11 +455,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))
+ arch_phys_wc_del(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..163f436 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -43,14 +43,18 @@
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->type != _DRM_AGP) {
+ if (map->type == _DRM_FRAME_BUFFER ||
+ map->flags & _DRM_WRITE_COMBINING)
+ tmp = pgprot_writecombine(tmp);
+ else
+ tmp = pgprot_noncached(tmp);
}
#elif defined(__powerpc__)
pgprot_val(tmp) |= _PAGE_NO_CACHE;
@@ -250,13 +254,8 @@ static void drm_vm_shm_close(struct vm_area_struct *vma)
switch (map->type) {
case _DRM_REGISTERS:
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))
+ arch_phys_wc_del(map->mtrr);
iounmap(map->handle);
break;
case _DRM_SHM:
@@ -617,7 +616,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_
[RFC/PATCH v2 2/8] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Remove drm_mtrr_{add, del}
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/ast/ast_ttm.c | 13 +++
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 | 43 ---
drivers/gpu/drm/savage/savage_drv.h | 5 +---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10
include/drm/drmP.h| 29 ---
8 files changed, 35 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 3602731..c4574fd 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -271,26 +271,19 @@ 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 = arch_phys_wc_add(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;
- }
+ arch_phys_wc_del(ast->fb_mtrr);
}
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..09f06d3 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 = arch_phys_wc_add(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;
- }
+ arch_phys_wc_del(cirrus->fb_mtrr);
+ cirrus->fb_mtrr = 0;
}
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..5c6f3c8 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 = arch_phys_wc_add(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;
- }
+ arch_phys_wc_del(mdev->fb_mtrr);
+ mdev->fb_mtrr = 0;
}
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..63fa6a5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -377,9 +377,8 @@ nouveau_ttm_init(struct nouveau_drm *drm)
return ret;
}
-
[RFC/PATCH v2 1/8] Add arch_phys_wc_{add, del} to manipulate WC MTRRs if needed
Several drivers currently use mtrr_add through various #ifdef guards
and/or drm wrappers. The vast majority of them want to add WC MTRRs
on x86 systems and don't actually need the MTRR if PAT (i.e.
ioremap_wc, etc) are working.
arch_phys_wc_add and arch_phys_wc_del are new functions, available
on all architectures and configurations, that add WC MTRRs on x86 if
needed (and handle errors) and do nothing at all otherwise. They're
also easier to use than mtrr_add and mtrr_del, so the call sites can
be simplified.
As an added benefit, this will avoid wasting MTRRs and possibly
warning pointlessly on PAT-supporting systems.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/io.h | 7 ++
arch/x86/include/asm/mtrr.h | 5 -
arch/x86/kernel/cpu/mtrr/main.c | 48 +
include/linux/io.h | 25 +
4 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d8e8eef..34f69cb 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -345,4 +345,11 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec
*vec1,
#define IO_SPACE_LIMIT 0x
+#ifdef CONFIG_MTRR
+extern int __must_check arch_phys_wc_add(unsigned long base,
+unsigned long size);
+extern void arch_phys_wc_del(int handle);
+#define arch_phys_wc_add arch_phys_wc_add
+#endif
+
#endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index e235582..10d0fba 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -26,7 +26,10 @@
#include
-/* The following functions are for use by other drivers */
+/*
+ * The following functions are for use by other drivers that cannot use
+ * arch_phys_wc_add and arch_phys_wc_del.
+ */
# ifdef CONFIG_MTRR
extern u8 mtrr_type_lookup(u64 addr, u64 end);
extern void mtrr_save_fixed_ranges(void *);
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 726bf96..23bd49a 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,53 @@ int mtrr_del(int reg, unsigned long base, unsigned long
size)
}
EXPORT_SYMBOL(mtrr_del);
+/**
+ * arch_phys_wc_add - 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 arch_phys_wc_add(unsigned long base, unsigned long size)
+{
+ int ret;
+
+ if (pat_enabled)
+ return 0; /* Success! (We don't need to do anything.) */
+
+ ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true);
+ if (ret < 0) {
+ pr_warn("Failed to add WC MTRR for [%p-%p]; performance may
suffer.",
+ (void *)base, (void *)(base + size - 1));
+ return ret;
+ }
+ return ret + 1000;
+}
+EXPORT_SYMBOL(arch_phys_wc_add);
+
+/*
+ * arch_phys_wc_del - undoes arch_phys_wc_add
+ * @handle: Return value from arch_phys_wc_add
+ *
+ * This cleans up after mtrr_add_wc_if_needed.
+ *
+ * The API guarantees that mtrr_del_wc_if_needed(error code) and
+ * mtrr_del_wc_if_needed(0) do nothing.
+ */
+extern void arch_phys_wc_del(int handle)
+{
+ if (handle >= 1) {
+ WARN_ON(handle < 1000);
+ mtrr_del(handle - 1000, 0, 0);
+ }
+}
+EXPORT_SYMBOL(arch_phys_wc_del);
+
/*
* HACK ALERT!
* These should be called implicitly, but we can't yet until all the initcall
diff --git a/include/linux/io.h b/include/linux/io.h
index 069e407..f4f42fa 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -76,4 +76,29 @@ void devm_ioremap_release(struct device *dev, void *res);
#define arch_has_dev_port() (1)
#endif
+/*
+ * Some systems (x86 without PAT) have a somewhat reliable way to mark a
+ * physical address range such that uncached mappings will actually
+ * end up write-combining. This facility should be used in conjunction
+ * with pgprot_writecombine, ioremap-wc, or set_memory_wc, since it has
+ * no effect if the per-page mechanisms are functional.
+ * (On x86 without PAT, these functions manipulate MTRRs.)
+ *
+ * arch_phys_del_wc(0) or arch_phys_del_wc(any error code) is guaranteed
+ * to have no effect.
+ */
+#ifndef arch_phys_wc_add
+static inline int __must_check arch_phys_wc_add(unsigned long base,
+ unsigned long size)
+{
+ return 0; /* It worked (i.e. did nothing). */
+}
+
+static inline void arch_phys_wc_del(int handle)
+{
+
[RFC/PATCH v2 0/8] 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 arch_phys_wc_{add,del} that, on PAT-less
x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
otherwise. (Other architectures, if any, with a similar mechanism could
implement them.)
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/.
Changes from v1:
- Helpers renamed
- Lots of bugs fixed
The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup/rfc_v2
Andy Lutomirski (8):
Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Remove
drm_mtrr_{add,del}
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
drm,agpgart: Use pgprot_writecombine for AGP maps and make the MTRR
optional
i915: Use arch_phys_wc_{add,del}
radeon: Switch to arch_phys_wc_add and add a missing ..._del
uvesafb: Clean up MTRR code
drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
Documentation/fb/uvesafb.txt | 16 +++-
arch/x86/include/asm/io.h | 7
arch/x86/include/asm/mtrr.h| 5 ++-
arch/x86/kernel/cpu/mtrr/main.c| 48 +++
drivers/char/agp/frontend.c| 8 ++--
drivers/gpu/drm/ast/ast_ttm.c | 13 ++-
drivers/gpu/drm/cirrus/cirrus_ttm.c| 15 ++--
drivers/gpu/drm/drm_bufs.c | 17 +
drivers/gpu/drm/drm_pci.c | 8 ++--
drivers/gpu/drm/drm_stub.c | 10 +
drivers/gpu/drm/drm_vm.c | 22 +--
drivers/gpu/drm/i915/i915_dma.c| 44 +++--
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| 43 -
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 | 34 +
include/drm/drm_os_linux.h | 16
include/linux/io.h | 25
include/video/uvesafb.h| 1 +
23 files changed, 181 insertions(+), 268 deletions(-)
--
1.8.1.4
Re: [PATCH 0/4] mgag200 fixes
Christopher Harvey writes: > The Following should be CC'd to stable: > * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register > * drm/mgag200: Fix framebuffer base address programming > > The others are bug fixes, but aren't critical. I'm sitting on some > hardware cursor code that depends on all of these patches before it > can go in. I'm aiming for 3.11 for the hardware cursor support. > > thanks, > Christopher Harvey (4): > drm/mgag200: Don't change unrelated registers during modeset > drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register > drm/mgag200: Convert counter delays to jiffies > drm/mgag200: Fix framebuffer base address programming > > drivers/gpu/drm/mgag200/mgag200_mode.c | 90 > -- > 1 file changed, 52 insertions(+), 38 deletions(-) please ignore this, version 2 has been posted. -C ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/mgag200: Fix framebuffer base address programming
Higher bits of the base address of framebuffers weren't being
programmed properly. This caused framebuffers that didn't happen to be
allocated at a low enough address to not be displayed properly.
Signed-off-by: Christopher Harvey
Signed-off-by: Mathieu Larouche
Acked-by: Julia Lemire
Tested-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6dbf6de..77b8a45 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -654,12 +654,26 @@ static void mga_g200wb_commit(struct drm_crtc *crtc)
WREG_DAC(MGA1064_GEN_IO_DATA, tmp);
}
-
+/*
+ This is how the framebuffer base address is stored in g200 cards:
+ * Assume @offset is the gpu_addr variable of the framebuffer object
+ * Then addr is the number of _pixels_ (not bytes) from the start of
+ VRAM to the first pixel we want to display. (divided by 2 for 32bit
+ framebuffers)
+ * addr is stored in the CRTCEXT0, CRTCC and CRTCD registers
+ addr<20> -> CRTCEXT0<6>
+ addr<19-16> -> CRTCEXT0<3-0>
+ addr<15-8> -> CRTCC<7-0>
+ addr<7-0> -> CRTCD<7-0>
+ CRTCEXT0 has to be programmed last to trigger an update and make the
+ new addr variable take effect.
+ */
void mga_set_start_address(struct drm_crtc *crtc, unsigned offset)
{
struct mga_device *mdev = crtc->dev->dev_private;
u32 addr;
int count;
+ u8 crtcext0;
while (RREG8(0x1fda) & 0x08);
while (!(RREG8(0x1fda) & 0x08));
@@ -667,10 +681,17 @@ void mga_set_start_address(struct drm_crtc *crtc,
unsigned offset)
count = RREG8(MGAREG_VCOUNT) + 2;
while (RREG8(MGAREG_VCOUNT) < count);
- addr = offset >> 2;
+ WREG8(MGAREG_CRTCEXT_INDEX, 0);
+ crtcext0 = RREG8(MGAREG_CRTCEXT_DATA);
+ crtcext0 &= 0xB0;
+ addr = offset / 8;
+ /* Can't store addresses any higher than that...
+ but we also don't have more than 16MB of memory, so it should be
fine. */
+ WARN_ON(addr > 0x1f);
+ crtcext0 |= (!!(addr & (1<<20)))<<6;
WREG_CRT(0x0d, (u8)(addr & 0xff));
WREG_CRT(0x0c, (u8)(addr >> 8) & 0xff);
- WREG_CRT(0xaf, (u8)(addr >> 16) & 0xf);
+ WREG_ECRT(0x0, ((u8)(addr >> 16) & 0xf) | crtcext0);
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/mgag200: Convert counter delays to jiffies
Signed-off-by: Christopher Harvey
Acked-by: Julia Lemire
Tested-by: Julia Lemire
Acked-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -46,29 +46,26 @@ static void mga_crtc_load_lut(struct drm_crtc *crtc)
static inline void mga_wait_vsync(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ/10;
unsigned int status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while ((status & 0x08) && (count < 25));
- count = 0;
+ } while ((status & 0x08) && time_before(jiffies, timeout));
+ timeout = jiffies + HZ/10;
status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while (!(status & 0x08) && (count < 25));
+ } while (!(status & 0x08) && time_before(jiffies, timeout));
}
static inline void mga_wait_busy(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
status = RREG8(MGAREG_Status + 2);
- count++;
- } while ((status & 0x01) && (count < 50));
+ } while ((status & 0x01) && time_before(jiffies, timeout));
}
/*
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
The original line, WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into MGA1064_PIX_CLK_CTL. Change the line to write properly into MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use the same pattern (but work correctly), so this patch updates them all to use this new (slightly more efficient) write pattern. The WREG_DAC macro was causing the DAC_INDEX register to be set to the same value twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX is already at the value we want. Signed-off-by: Christopher Harvey Acked-by: Julia Lemire Tested-by: Julia Lemire Acked-by: Mathieu Larouche --- drivers/gpu/drm/mgag200/mgag200_mode.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c index 2d9333d..6f3b9db 100644 --- a/drivers/gpu/drm/mgag200/mgag200_mode.c +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c @@ -189,12 +189,12 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_REMHEADCTL_CLKDIS; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* select PLL Set C */ tmp = RREG8(MGAREG_MEM_MISC_READ); @@ -204,7 +204,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN | 0x80; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -212,7 +212,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_VREF_CTL); tmp = RREG8(DAC_DATA); tmp &= ~0x04; - WREG_DAC(MGA1064_VREF_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(50); @@ -236,13 +236,13 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_REMHEADCTL_CLKSL_MSK; tmp |= MGA1064_REMHEADCTL_CLKSL_PLL; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* reset dotclock rate bit */ WREG8(MGAREG_SEQ_INDEX, 1); @@ -253,7 +253,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); vcount = RREG8(MGAREG_VCOUNT); @@ -318,7 +318,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); tmp = RREG8(MGAREG_MEM_MISC_READ); tmp |= 0x3 << 2; @@ -326,12 +326,12 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_PLL_STAT); tmp = RREG8(DAC_DATA); - WREG_DAC(MGA1064_PIX_PLL_STAT, tmp & ~0x40); + WREG8(DAC_DATA, tmp & ~0x40); WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG_DAC(MGA1064_EV_PIX_PLLC_M, m); WREG_DAC(MGA1064_EV_PIX_PLLC_N, n); @@ -342,7 +342,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -350,11 +350,11 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp)
[PATCH v2 1/4] drm/mgag200: Don't change unrelated registers during modeset
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
Tested-by: Julia Lemire
Acked-by: Julia Lemire
Acked-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index f988965..2d9333d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -829,11 +829,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
for (i = 0; i < sizeof(dacvalue); i++) {
- if ((i <= 0x03) ||
- (i == 0x07) ||
- (i == 0x0b) ||
- (i == 0x0f) ||
- ((i >= 0x13) && (i <= 0x17)) ||
+ if ((i <= 0x17) ||
(i == 0x1b) ||
(i == 0x1c) ||
((i >= 0x1f) && (i <= 0x29)) ||
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] *** SUBJECT HERE ***
I forgot to include some acked and tested-by lines in v1 of this series. No code changes in v2. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to jiffies drm/mgag200: Fix framebuffer base address programming drivers/gpu/drm/mgag200/mgag200_mode.c | 90 -- 1 file changed, 52 insertions(+), 38 deletions(-) -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/mgag200: Fix framebuffer base address programming
Higher bits of the base address of framebuffers weren't being
programmed properly. This caused framebuffers that didn't happen to be
allocated at a low enough address to not be displayed properly.
Signed-off-by: Christopher Harvey
Signed-off-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6dbf6de..77b8a45 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -654,12 +654,26 @@ static void mga_g200wb_commit(struct drm_crtc *crtc)
WREG_DAC(MGA1064_GEN_IO_DATA, tmp);
}
-
+/*
+ This is how the framebuffer base address is stored in g200 cards:
+ * Assume @offset is the gpu_addr variable of the framebuffer object
+ * Then addr is the number of _pixels_ (not bytes) from the start of
+ VRAM to the first pixel we want to display. (divided by 2 for 32bit
+ framebuffers)
+ * addr is stored in the CRTCEXT0, CRTCC and CRTCD registers
+ addr<20> -> CRTCEXT0<6>
+ addr<19-16> -> CRTCEXT0<3-0>
+ addr<15-8> -> CRTCC<7-0>
+ addr<7-0> -> CRTCD<7-0>
+ CRTCEXT0 has to be programmed last to trigger an update and make the
+ new addr variable take effect.
+ */
void mga_set_start_address(struct drm_crtc *crtc, unsigned offset)
{
struct mga_device *mdev = crtc->dev->dev_private;
u32 addr;
int count;
+ u8 crtcext0;
while (RREG8(0x1fda) & 0x08);
while (!(RREG8(0x1fda) & 0x08));
@@ -667,10 +681,17 @@ void mga_set_start_address(struct drm_crtc *crtc,
unsigned offset)
count = RREG8(MGAREG_VCOUNT) + 2;
while (RREG8(MGAREG_VCOUNT) < count);
- addr = offset >> 2;
+ WREG8(MGAREG_CRTCEXT_INDEX, 0);
+ crtcext0 = RREG8(MGAREG_CRTCEXT_DATA);
+ crtcext0 &= 0xB0;
+ addr = offset / 8;
+ /* Can't store addresses any higher than that...
+ but we also don't have more than 16MB of memory, so it should be
fine. */
+ WARN_ON(addr > 0x1f);
+ crtcext0 |= (!!(addr & (1<<20)))<<6;
WREG_CRT(0x0d, (u8)(addr & 0xff));
WREG_CRT(0x0c, (u8)(addr >> 8) & 0xff);
- WREG_CRT(0xaf, (u8)(addr >> 16) & 0xf);
+ WREG_ECRT(0x0, ((u8)(addr >> 16) & 0xf) | crtcext0);
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/mgag200: Convert counter delays to jiffies
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -46,29 +46,26 @@ static void mga_crtc_load_lut(struct drm_crtc *crtc)
static inline void mga_wait_vsync(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ/10;
unsigned int status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while ((status & 0x08) && (count < 25));
- count = 0;
+ } while ((status & 0x08) && time_before(jiffies, timeout));
+ timeout = jiffies + HZ/10;
status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while (!(status & 0x08) && (count < 25));
+ } while (!(status & 0x08) && time_before(jiffies, timeout));
}
static inline void mga_wait_busy(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
status = RREG8(MGAREG_Status + 2);
- count++;
- } while ((status & 0x01) && (count < 50));
+ } while ((status & 0x01) && time_before(jiffies, timeout));
}
/*
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register
The original line, WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into MGA1064_PIX_CLK_CTL. Change the line to write properly into MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use the same pattern (but work correctly), so this patch updates them all to use this new (slightly more efficient) write pattern. The WREG_DAC macro was causing the DAC_INDEX register to be set to the same value twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX is already at the value we want. Signed-off-by: Christopher Harvey --- drivers/gpu/drm/mgag200/mgag200_mode.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c index 2d9333d..6f3b9db 100644 --- a/drivers/gpu/drm/mgag200/mgag200_mode.c +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c @@ -189,12 +189,12 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_REMHEADCTL_CLKDIS; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* select PLL Set C */ tmp = RREG8(MGAREG_MEM_MISC_READ); @@ -204,7 +204,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN | 0x80; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -212,7 +212,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_VREF_CTL); tmp = RREG8(DAC_DATA); tmp &= ~0x04; - WREG_DAC(MGA1064_VREF_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(50); @@ -236,13 +236,13 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_REMHEADCTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_REMHEADCTL_CLKSL_MSK; tmp |= MGA1064_REMHEADCTL_CLKSL_PLL; - WREG_DAC(MGA1064_REMHEADCTL, tmp); + WREG8(DAC_DATA, tmp); /* reset dotclock rate bit */ WREG8(MGAREG_SEQ_INDEX, 1); @@ -253,7 +253,7 @@ static int mga_g200wb_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); vcount = RREG8(MGAREG_VCOUNT); @@ -318,7 +318,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_DIS; - WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); + WREG8(DAC_DATA, tmp); tmp = RREG8(MGAREG_MEM_MISC_READ); tmp |= 0x3 << 2; @@ -326,12 +326,12 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_PLL_STAT); tmp = RREG8(DAC_DATA); - WREG_DAC(MGA1064_PIX_PLL_STAT, tmp & ~0x40); + WREG8(DAC_DATA, tmp & ~0x40); WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp |= MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG_DAC(MGA1064_EV_PIX_PLLC_M, m); WREG_DAC(MGA1064_EV_PIX_PLLC_N, n); @@ -342,7 +342,7 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) WREG8(DAC_INDEX, MGA1064_PIX_CLK_CTL); tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_CLK_POW_DOWN; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); udelay(500); @@ -350,11 +350,11 @@ static int mga_g200ev_set_plls(struct mga_device *mdev, long clock) tmp = RREG8(DAC_DATA); tmp &= ~MGA1064_PIX_CLK_CTL_SEL_MSK; tmp |= MGA1064_PIX_CLK_CTL_SEL_PLL; - WREG_DAC(MGA1064_PIX_CLK_CTL, tmp); + WREG8(DAC_DATA, tmp); WREG8(DAC_INDEX, MGA1064_PIX_PLL_ST
[PATCH 1/4] drm/mgag200: Don't change unrelated registers during modeset
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index f988965..2d9333d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -829,11 +829,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
for (i = 0; i < sizeof(dacvalue); i++) {
- if ((i <= 0x03) ||
- (i == 0x07) ||
- (i == 0x0b) ||
- (i == 0x0f) ||
- ((i >= 0x13) && (i <= 0x17)) ||
+ if ((i <= 0x17) ||
(i == 0x1b) ||
(i == 0x1c) ||
((i >= 0x1f) && (i <= 0x29)) ||
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] mgag200 fixes
The Following should be CC'd to stable: * drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register * drm/mgag200: Fix framebuffer base address programming The others are bug fixes, but aren't critical. I'm sitting on some hardware cursor code that depends on all of these patches before it can go in. I'm aiming for 3.11 for the hardware cursor support. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to jiffies drm/mgag200: Fix framebuffer base address programming drivers/gpu/drm/mgag200/mgag200_mode.c | 90 -- 1 file changed, 52 insertions(+), 38 deletions(-) -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63236] kwin crashes when some desktop effects are used
https://bugs.freedesktop.org/show_bug.cgi?id=63236 Eugene changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eugene --- Not sure about LLVM, but it works fine after system upgrade: KDE Version 4.10.3 client glx vendor string: Mesa Project and SGI client glx version string: 1.4 OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 256 bits) OpenGL version string: 2.1 Mesa 9.1.2 OpenGL shading language version string: 1.20 -- 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
[PATCH v2 5/5] drm: Use names of ioctls in debug traces
On Thu, May 9, 2013 at 9:20 AM, Chris Cummins
wrote:
> The intention here is to make the output of dmesg with full verbosity a
> bit easier for a human to parse. This commit transforms:
>
> [drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1
> [drm:drm_mode_addfb], [FB:32]
> [drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1
> [drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
> [drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1
> [drm:intel_crtc_set_config], [CRTC:3] [NOFB]
>
> into:
>
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_THROTTLE
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_CREATE
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_TILING
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, IOCTL_MODE_ADDFB
> [drm:drm_mode_addfb], [FB:32]
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_MMAP_GTT
> [drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
> [drm:intel_crtc_set_config], [CRTC:3] [NOFB]
>
> v2: drm_ioctls is now a constant (Ville Syrj?l?)
>
> Signed-off-by: Chris Cummins
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_drv.c | 20 +---
> include/drm/drmP.h| 3 ++-
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 0ba4dcb..dfa228b 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -57,7 +57,7 @@ static int drm_version(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
>
> #define DRM_IOCTL_DEF(ioctl, _func, _flags) \
> - [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags =
> _flags, .cmd_drv = 0}
> + [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags =
> _flags, .cmd_drv = 0, .name = #ioctl}
>
> /** Ioctl table */
> static const struct drm_ioctl_desc drm_ioctls[] = {
> @@ -375,7 +375,7 @@ long drm_ioctl(struct file *filp,
> {
> struct drm_file *file_priv = filp->private_data;
> struct drm_device *dev;
> - const struct drm_ioctl_desc *ioctl;
> + const struct drm_ioctl_desc *ioctl = NULL;
> drm_ioctl_t *func;
> unsigned int nr = DRM_IOCTL_NR(cmd);
> int retcode = -EINVAL;
> @@ -392,11 +392,6 @@ long drm_ioctl(struct file *filp,
> atomic_inc(&dev->counts[_DRM_STAT_IOCTLS]);
> ++file_priv->ioctl_count;
>
> - DRM_DEBUG("pid=%d, cmd=0x%02x, nr=0x%02x, dev 0x%lx, auth=%d\n",
> - task_pid_nr(current), cmd, nr,
> - (long)old_encode_dev(file_priv->minor->device),
> - file_priv->authenticated);
> -
> if ((nr >= DRM_CORE_IOCTL_COUNT) &&
> ((nr < DRM_COMMAND_BASE) || (nr >= DRM_COMMAND_END)))
> goto err_i1;
> @@ -416,6 +411,11 @@ long drm_ioctl(struct file *filp,
> } else
> goto err_i1;
>
> + DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
> + task_pid_nr(current),
> + (long)old_encode_dev(file_priv->minor->device),
> + file_priv->authenticated, ioctl->name);
> +
> /* Do not trust userspace, use our own definition */
> func = ioctl->func;
> /* is there a local override? */
> @@ -470,6 +470,12 @@ long drm_ioctl(struct file *filp,
> }
>
>err_i1:
> + if (!ioctl)
> + DRM_DEBUG("invalid iotcl: pid=%d, dev=0x%lx, auth=%d,
> cmd=0x%02x, nr=0x%02x\n",
> + task_pid_nr(current),
> + (long)old_encode_dev(file_priv->minor->device),
> + file_priv->authenticated, cmd, nr);
> +
> if (kdata != stack_kdata)
> kfree(kdata);
> atomic_dec(&dev->ioctl_count);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 2d94d74..379787c 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -316,6 +316,7 @@ struct drm_ioctl_desc {
> int flags;
> drm_ioctl_t *func;
> unsigned int cmd_drv;
> + const char *name;
> };
>
> /**
> @@ -324,7 +325,7 @@ struct drm_ioctl_desc {
> */
>
> #define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)\
> - [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
> .flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl}
> + [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
> .flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl, .name = #ioctl}
>
> struct drm_magic_entry {
> struct list_he
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #64 from udo --- Weird thing is that with 3.8.10 the box has been stable for a few days without weird radeon-related errors. Currently trying 3.9.1. Git mesa, llvm, libclc, xf-video-ati etc -- 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/20130509/7d88c138/attachment.html>
Re: nouveau GF108 kernel crash in optimus mode when enabling external display output
Hello, ping also here.. any other information needed about this nouveau kernel crash? Thanks, -- Pasi On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi Kärkkäinen wrote: > Hello, > > Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS: > > $ lspci | grep VGA > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor > Graphics Controller (rev 09) > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS > 5400M] (rev a1) > > $ uname -a > Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 > UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > > I boot up the system with only laptop internal LVDS active on intel gpu, and > when in X session, > I enable the second display on nouveau gpu connected to the dock DP2/DVI > connector. > At this point the kernel crashes immediately. > > Screenshots of the kernel crash/stacktrace here: > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg > > hand-written bits from the kernel crash: > > Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO > 2349H2G/2349H2G > RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 > [nouveau] > RSP: 0018:8803298357c8 EFLAGS: 00010206 > .. > Process Xorg (pid: 1208,..) > .. > Call Trace: > .. nouveau_vm_map_sg+0xc2/0x130 [nouveau] > .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau] > .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau] > .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau] > .. nouveau_bo_move+0xa5/0x400 [nouveau] > .. ttm_bo_handle_move_mem+0x245/0x610 [ttm] > > More info from the screenshots above.. > > > dmesg drm bits before the crash: > > [0.137586] vgaarb: device added: > PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none > [0.137590] vgaarb: device added: > PCI::01:00.0,decodes=io+mem,owns=none,locks=none > [0.137591] vgaarb: loaded > [0.137591] vgaarb: bridge control possible :01:00.0 > [0.137592] vgaarb: no bridge control possible :00:02.0 > [0.529802] fb0: VESA VGA frame buffer device > [0.877212] ata1.00: supports DRM functions and may not be fully accessible > [0.878010] ata1.00: supports DRM functions and may not be fully accessible > [1.969486] [drm] Initialized drm 1.1.0 20060810 > [1.990584] VGA switcheroo: detected Optimus DSM method > \_SB_.PCI0.PEG_.VID_ handle > [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007) > [1.990874] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0c1780a1 > [1.990877] nouveau [ DEVICE][:01:00.0] Chipset: GF108 (NVC1) > [1.990878] nouveau [ DEVICE][:01:00.0] Family : NVC0 > [1.992485] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > [2.002182] nouveau [ VBIOS][:01:00.0] ... signature not found > [2.002184] nouveau [ VBIOS][:01:00.0] checking PROM for image... > [2.002243] nouveau [ VBIOS][:01:00.0] ... signature not found > [2.002245] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > [2.189928] nouveau [ VBIOS][:01:00.0] ... appears to be valid > [2.189935] nouveau [ VBIOS][:01:00.0] using image from ACPI > [2.190143] nouveau [ VBIOS][:01:00.0] BIT signature found > [2.190149] nouveau [ VBIOS][:01:00.0] version 70.08.b7.02.02 > [2.190467] nouveau [ DEVINIT][:01:00.0] adaptor not initialised > [2.190470] nouveau [ VBIOS][:01:00.0] running init tables > [2.278184] nouveau [ PFB][:01:00.0] RAM type: DDR3 > [2.278189] nouveau [ PFB][:01:00.0] RAM size: 512 MiB > [2.278192] nouveau [ PFB][:01:00.0]ZCOMP: 0 tags > [2.311802] nouveau [ DRM] VRAM: 512 MiB > [2.311805] nouveau [ DRM] GART: 512 MiB > [2.311810] nouveau [ DRM] BIT BIOS found > [2.311814] nouveau [ DRM] Bios version 70.08.b7.02 > [2.311831] nouveau [ DRM] TMDS table version 2.0 > [2.311832] nouveau [ DRM] DCB version 4.0 > [2.311833] nouveau [ DRM] DCB outp 00: 01800323 00010034 > [2.311834] nouveau [ DRM] DCB outp 01: 02811300 > [2.311835] nouveau [ DRM] DCB outp 02: 028223a6 0f220010 > [2.311836] nouveau [ DRM] DCB outp 03: 02822362 00020010 > [2.311837] nouveau [ DRM] DCB outp 04: 048333b6 0f220010 > [2.311838] nouveau [ DRM] DCB outp 05: 04833372 00020010 > [2.311839] nouveau [ DRM] DCB outp 06: 088443c6 0f220010 > [2.311840] nouveau [ DRM] DCB outp 07: 08844382 00020010 > [2.311841] nouveau [ DRM] DCB conn 00: 0040 > [2.311842] nouveau [ DRM] DCB conn 01: 0100 > [2.311843] nouveau [ DRM] DCB conn 02: 00110246 > [2.311844] nouveau [ DRM] DCB conn 03: 00220346 > [2.311845] nouveau [ DRM] DCB conn 04: 01400446 > [2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [
Re: nouveau GF108 kernel errors and graphics corruption when enabling another output
Hello, Any comments? Should I provide more logs, or try something I didn't try yet? Thanks, -- Pasi On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi Kärkkäinen wrote: > Hello, > > Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled > in BIOS, > and only the Nvidia discreet GPU is enabled: > > $ lspci | grep VGA > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS > 5400M] (rev a1) > > > I boot up the laptop with only using the laptop internal LVDS panel, and when > in X session, > I connect DVI cable to the docking station. xrandr now correctly shows DP2 as > connected, > and when I enable the DVI display, I get these nouveau errors in the kernel > dmesg: > > [ 103.196252] nouveau [ PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040 > [ 103.196257] nouveau [ PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040 > [ 103.353160] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.353163] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.353923] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.353925] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.354257] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.354259] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.354703] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.354705] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.404091] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.404094] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.418076] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.418078] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.418567] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.418569] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.418788] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.418789] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.419164] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.419166] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.419473] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.419474] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.420080] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.420082] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.420367] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.420369] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.423674] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.423676] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.471348] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.471351] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.487327] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.487330] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.487675] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.487677] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.488222] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.488224] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.488834] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.488836] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > [ 103.490843] nouveau E[ VM][:01:00.0] failed to create 0x0400, > -28 > [ 103.490845] nouveau E[ VM][:01:00.0] failed to create 0x0200, > -28 > > > Should I file a freedesktop bug about this? > > DVI monitor output actually gets enabled, and I can see the desktop there, > but both the LVDS display and the DVI display are all messed up. > > For example moving a window around leaves traces of other window contents, > and the background image gets replaced with all kinds of corrupted patterns, > so graphics looks quite weird and corrupted on both displays. > > Switching back to only using the internal LVDS (disabling DVI/DP2 output) > fixes the graphics corruptions. > > > $ uname -a > Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 > UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > > > $ dmesg|grep -i nouveau > > [1.935779] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing > generic driver > [1.93
[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 #9 from Dave Witbrodt ---
Noting Benjamin's experience with EFI in comment 8, I took a look at my 3
machines on which I am trying the UVD support. I have a laptop, a desktop, and
another (inexpensive) desktop which I use as a file server.
Desktop: JUNIPER, no EFI support (several years old)
CONFIG_EXTRA_FIRMWARE="radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin
radeon/JUNIPER_rlc.bin radeon/CYPRESS_uvd.bin ..."
Boot results:
[0.816646] [drm] UVD initialized successfully.
Laptop: SUMO, no EFI support (not old, but not new enough for EFI)
CONFIG_EXTRA_FIRMWARE="radeon/SUMO_rlc.bin radeon/SUMO_me.bin
radeon/SUMO_pfp.bin radeon/SUMO_uvd.bin ..."
Boot results:
[1.650383] [drm] UVD initialized successfully.
"fileserver": SUMO2, EFI support (newest motherboard of the 3)
CONFIG_EXTRA_FIRMWARE="radeon/SUMO_rlc.bin radeon/SUMO2_me.bin
radeon/SUMO2_pfp.bin radeon/SUMO_uvd.bin"
Boot results:
[ 11.575783] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).
See comment 6 above.
This looks like further evidence of EFI involvement with the problem. I cannot
see any BIOS settings that would allow me to alter EFI support on my
"fileserver" motherboard. The only option I could find had to do with PCI ROM
support ("legacy" vs "EFI"), but this had defaulted to "legacy" when I
installed the motherboard and I never touched it.
--
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: [PATCH v2 5/5] drm: Use names of ioctls in debug traces
On Thu, May 9, 2013 at 9:20 AM, Chris Cummins
wrote:
> The intention here is to make the output of dmesg with full verbosity a
> bit easier for a human to parse. This commit transforms:
>
> [drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1
> [drm:drm_mode_addfb], [FB:32]
> [drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1
> [drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
> [drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1
> [drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1
> [drm:intel_crtc_set_config], [CRTC:3] [NOFB]
>
> into:
>
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_THROTTLE
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_CREATE
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_TILING
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, IOCTL_MODE_ADDFB
> [drm:drm_mode_addfb], [FB:32]
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_MMAP_GTT
> [drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
> [drm:drm_ioctl], pid=699, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
> [drm:intel_crtc_set_config], [CRTC:3] [NOFB]
>
> v2: drm_ioctls is now a constant (Ville Syrjälä)
>
> Signed-off-by: Chris Cummins
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_drv.c | 20 +---
> include/drm/drmP.h| 3 ++-
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 0ba4dcb..dfa228b 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -57,7 +57,7 @@ static int drm_version(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
>
> #define DRM_IOCTL_DEF(ioctl, _func, _flags) \
> - [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags =
> _flags, .cmd_drv = 0}
> + [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags =
> _flags, .cmd_drv = 0, .name = #ioctl}
>
> /** Ioctl table */
> static const struct drm_ioctl_desc drm_ioctls[] = {
> @@ -375,7 +375,7 @@ long drm_ioctl(struct file *filp,
> {
> struct drm_file *file_priv = filp->private_data;
> struct drm_device *dev;
> - const struct drm_ioctl_desc *ioctl;
> + const struct drm_ioctl_desc *ioctl = NULL;
> drm_ioctl_t *func;
> unsigned int nr = DRM_IOCTL_NR(cmd);
> int retcode = -EINVAL;
> @@ -392,11 +392,6 @@ long drm_ioctl(struct file *filp,
> atomic_inc(&dev->counts[_DRM_STAT_IOCTLS]);
> ++file_priv->ioctl_count;
>
> - DRM_DEBUG("pid=%d, cmd=0x%02x, nr=0x%02x, dev 0x%lx, auth=%d\n",
> - task_pid_nr(current), cmd, nr,
> - (long)old_encode_dev(file_priv->minor->device),
> - file_priv->authenticated);
> -
> if ((nr >= DRM_CORE_IOCTL_COUNT) &&
> ((nr < DRM_COMMAND_BASE) || (nr >= DRM_COMMAND_END)))
> goto err_i1;
> @@ -416,6 +411,11 @@ long drm_ioctl(struct file *filp,
> } else
> goto err_i1;
>
> + DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
> + task_pid_nr(current),
> + (long)old_encode_dev(file_priv->minor->device),
> + file_priv->authenticated, ioctl->name);
> +
> /* Do not trust userspace, use our own definition */
> func = ioctl->func;
> /* is there a local override? */
> @@ -470,6 +470,12 @@ long drm_ioctl(struct file *filp,
> }
>
>err_i1:
> + if (!ioctl)
> + DRM_DEBUG("invalid iotcl: pid=%d, dev=0x%lx, auth=%d,
> cmd=0x%02x, nr=0x%02x\n",
> + task_pid_nr(current),
> + (long)old_encode_dev(file_priv->minor->device),
> + file_priv->authenticated, cmd, nr);
> +
> if (kdata != stack_kdata)
> kfree(kdata);
> atomic_dec(&dev->ioctl_count);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 2d94d74..379787c 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -316,6 +316,7 @@ struct drm_ioctl_desc {
> int flags;
> drm_ioctl_t *func;
> unsigned int cmd_drv;
> + const char *name;
> };
>
> /**
> @@ -324,7 +325,7 @@ struct drm_ioctl_desc {
> */
>
> #define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)\
> - [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
> .flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl}
> + [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
> .flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl, .name = #ioctl}
>
> struct drm_magic_entry {
> struct list_he
[PATCH v2 5/5] drm: Use names of ioctls in debug traces
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
[drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]
into:
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_THROTTLE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_CREATE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_TILING
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, IOCTL_MODE_ADDFB
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_MMAP_GTT
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]
v2: drm_ioctls is now a constant (Ville Syrjälä)
Signed-off-by: Chris Cummins
---
drivers/gpu/drm/drm_drv.c | 20 +---
include/drm/drmP.h| 3 ++-
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 0ba4dcb..dfa228b 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,7 +57,7 @@ static int drm_version(struct drm_device *dev, void *data,
struct drm_file *file_priv);
#define DRM_IOCTL_DEF(ioctl, _func, _flags) \
- [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags,
.cmd_drv = 0}
+ [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags,
.cmd_drv = 0, .name = #ioctl}
/** Ioctl table */
static const struct drm_ioctl_desc drm_ioctls[] = {
@@ -375,7 +375,7 @@ long drm_ioctl(struct file *filp,
{
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev;
- const struct drm_ioctl_desc *ioctl;
+ const struct drm_ioctl_desc *ioctl = NULL;
drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
int retcode = -EINVAL;
@@ -392,11 +392,6 @@ long drm_ioctl(struct file *filp,
atomic_inc(&dev->counts[_DRM_STAT_IOCTLS]);
++file_priv->ioctl_count;
- DRM_DEBUG("pid=%d, cmd=0x%02x, nr=0x%02x, dev 0x%lx, auth=%d\n",
- task_pid_nr(current), cmd, nr,
- (long)old_encode_dev(file_priv->minor->device),
- file_priv->authenticated);
-
if ((nr >= DRM_CORE_IOCTL_COUNT) &&
((nr < DRM_COMMAND_BASE) || (nr >= DRM_COMMAND_END)))
goto err_i1;
@@ -416,6 +411,11 @@ long drm_ioctl(struct file *filp,
} else
goto err_i1;
+ DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
+ task_pid_nr(current),
+ (long)old_encode_dev(file_priv->minor->device),
+ file_priv->authenticated, ioctl->name);
+
/* Do not trust userspace, use our own definition */
func = ioctl->func;
/* is there a local override? */
@@ -470,6 +470,12 @@ long drm_ioctl(struct file *filp,
}
err_i1:
+ if (!ioctl)
+ DRM_DEBUG("invalid iotcl: pid=%d, dev=0x%lx, auth=%d,
cmd=0x%02x, nr=0x%02x\n",
+ task_pid_nr(current),
+ (long)old_encode_dev(file_priv->minor->device),
+ file_priv->authenticated, cmd, nr);
+
if (kdata != stack_kdata)
kfree(kdata);
atomic_dec(&dev->ioctl_count);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..379787c 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -316,6 +316,7 @@ struct drm_ioctl_desc {
int flags;
drm_ioctl_t *func;
unsigned int cmd_drv;
+ const char *name;
};
/**
@@ -324,7 +325,7 @@ struct drm_ioctl_desc {
*/
#define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)\
- [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
.flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl}
+ [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
.flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl, .name = #ioctl}
struct drm_magic_entry {
struct list_head head;
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64376] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugs.freedesktop.org/show_bug.cgi?id=64376 --- Comment #1 from Alex Deucher --- You need to make sure the VM has access to the PCI rom. -- 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 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2013-05-09 13:17:59 --- You need to make sure the VM has access to the PCI rom. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64376] New: radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugs.freedesktop.org/show_bug.cgi?id=64376 Priority: medium Bug ID: 64376 Assignee: dri-devel at lists.freedesktop.org Summary: radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: luke-jr+freedesktopbugs at utopios.org Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Booting on a KVM instance tested to work fine with fglrx: [3.771157] [drm] Initialized drm 1.1.0 20060810 [4.006077] [drm] radeon kernel modesetting enabled. [4.006350] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [4.006714] [drm] initializing kernel modesetting (CYPRESS 0x1002:0x6899 0x1458:0x21E4). [4.006723] [drm] register mmio base: 0xFEB8 [4.006724] [drm] register mmio size: 131072 [4.006785] radeon :00:05.0: Expecting atombios for evergreen GPU [4.006786] radeon :00:05.0: Fatal error during GPU init [4.006789] [drm] radeon: finishing device. [4.006792] [TTM] Memory type 2 has not been initialized [4.008077] radeon: probe of :00:05.0 failed with error -22 -- 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/20130509/53f21447/attachment-0001.html>
[Bug 57831] New: radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)
https://bugzilla.kernel.org/show_bug.cgi?id=57831 Summary: radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough) Product: Drivers Version: 2.5 Kernel Version: 3.9.0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: luke-jr+linuxbugs at utopios.org Regression: No Booting on a KVM instance tested to work fine with fglrx: [3.771157] [drm] Initialized drm 1.1.0 20060810 [4.006077] [drm] radeon kernel modesetting enabled. [4.006350] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [4.006714] [drm] initializing kernel modesetting (CYPRESS 0x1002:0x6899 0x1458:0x21E4). [4.006723] [drm] register mmio base: 0xFEB8 [4.006724] [drm] register mmio size: 131072 [4.006785] radeon :00:05.0: Expecting atombios for evergreen GPU [4.006786] radeon :00:05.0: Fatal error during GPU init [4.006789] [drm] radeon: finishing device. [4.006792] [TTM] Memory type 2 has not been initialized [4.008077] radeon: probe of :00:05.0 failed with error -22 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #64 from udo --- Weird thing is that with 3.8.10 the box has been stable for a few days without weird radeon-related errors. Currently trying 3.9.1. Git mesa, llvm, libclc, xf-video-ati etc -- 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
Introduce a new helper framework for buffer synchronization
Hi all, This post introduces a new helper framework based on dma fence. And the purpose of this post is to collect other opinions and advices before RFC posting. First of all, this helper framework, called fence helper, is in progress yet so might not have enough comments in codes and also might need to be more cleaned up. Moreover, we might be missing some parts of the dma fence. However, I'd like to say that all things mentioned below has been tested with Linux platform and worked well. The below link is fence helper codes, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=dma-fence-work&id=59096850b48ba0c5cd944dfc1dc4c2b8a92c12f5 And fence helper is based on the below patches, http://lists.freedesktop.org/archives/dri-devel/2013-January/033430.html Fence helper includes easy-to-use user and kernel interfaces for applying a buffer synchronization mechanism into device driver and user space. And the below link is example codes for device drivers, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=dma-fence-work&id=750a6bee163882e9f0cda48ce21eca7d18614e1c And also the below link is user interface relevant codes for user process, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=dma-fence-work&id=d2e30e8d8564b42c838108c86dae23138ddae7be The dma fence framework[1] had already been posted by Maarten and Rob. And the dma fence is used with reservation framework. Simple mechanism of the dma fence is as the followings, 1. one dmabuf has one reservation object when one buffer is exported into a dmabuf. 2. a thread creates its own fence object and sets the fence object to a reservation object of a dmabuf: a dmabuf is a buffer a thread wants accessing. 3. dma fence provides fence_default_wait() to block a thread and fence_signal() to wake up a thread: a thread is blocked once trying to access a shared buffer if another fence object had already been set to a reservation object of a shared buffer. And then a blocked thread is waked up by a owner when the owner- the owner is a thread accessing the shared buffer - signals the shared buffer. PS. Know that all buffers to be shared should be exported into dmabuf fd. However, dma fence just provides basic interfaces for buffer synchronization between DMA and DMA. Therefore developers should consider how interfaces of the dma fence should be called and also the resources of the dma fence should be managed. Thus, it might not be easy to apply the dma fence framework into their device drivers. Moreover, we need user interfaces for buffer synchronization between CPU and DMA. For example, we cannot aware of when and how CPU tries to access a shared buffer. So user applications need to notify the fact to dma fence framework so that the dma fence framework can synchronize the shared buffer between CPU and DMA. Fence helper includes the following features and interfaces. Features. 1. provide optimized buffer synchronization method - we need to check if a thread tried to access buffer with READ or WRITE, and if a thread tries to access same buffer with READ or WRITE. The reason is that we can avoid unnecessary read-lock by buffer synchronization and perform proper cache operation. 2. provide buffer synchronization to READ, WRITE and DMA access - Fence helper has three access types: READ, WRITE, and DMA. And these types can be compounded like below, READ, WRITE, READ | DMA or WRITE | DMA. 3. provide user interfaces for buffer synchronization between CPU and DMA - Fence helper provides user interfaces and the user interfaces has been implemented in dma-buf framework. User application can call these interfaces before and after cpu access. 4. provide cache control method - Fence helper performs proper cache operation looking before and after of CPU and DMA access. Actual cache operation is done just before committing a fence after memory access by CPU or DMA was completed. For cache operation, dma-buf interfaces, dma_buf_begin_cpu_access() and dma_buf_end_cpu_access(), are used. 5. provide easy-to-use user and kernel interfaces - Fence helper has four exported interfaces: these can be called by device driver and user application like below, Interfaces. fence_helper_init() - this function creates a new fence helper object internally and returns the fence helper object. fence_helper_init_reserve() - this function sets up a shard buffer into the fence helper object. And mutiple shared buffers can be set to there. fence_helper_commit_reserve() - this function synchronizes a shared buffer checking fence helper objects already committeds and commits a fence helper object to a shared buffer. The checking means that a caller waits for all threads, which committed their fence helper objects, signal the shared buffer. And the commit means that the caller is using a shared buffer so the shared buffer access by another thread isn't permitted: any thread trying to access the shared buffer
