date:20130509

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)

2013-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

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)

2013-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

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 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)

2013-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

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)

2013-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

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

2013-05-09 Thread Jerome Glisse

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);
+

[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
> [

[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>

Introduce a new helper framework for buffer synchronization

2013-05-09 Thread Inki Dae

 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, );

after memset or memcpy
ioctl(fd, DMA_BUF_PUT_FENCE, );

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>

[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

[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 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 v2 5/5] drm: Use names of ioctls in debug traces

2013-05-09 Thread Chris Cummins

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(>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(>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 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

2013-05-09 Thread Dave Airlie

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(>tbo, >placement,
  true, false);
if (unlikely(ret))
-- 
1.8.2.1

[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)

2013-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

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

[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(_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 |=

[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(>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(>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

[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(>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(>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;

[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>

[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)

2013-05-09 Thread bugzilla-dae...@bugzilla.kernel.org

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 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 #8 from Benjamin Lee  ---
I booted in Apple's BIOS emulation mode and found that UVD initializes
successfully, so the problem is limited to EFI booting (like the former video
BIOS issue).

Is there any debugging output I can provide that would help identify what is
different when EFI booting?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

Re: [PATCH] radeon: Allow disabling UVD

2013-05-09 Thread Parag Warudkar



On Wed, 8 May 2013, Christian König wrote:

 Am 07.05.2013 23:13, schrieb Parag Warudkar:
  On Tue, May 7, 2013 at 4:44 AM, Christian König deathsim...@vodafone.de
  wrote:
  Without SUMO_uvd.bin - suspends fine and only wakes up when I want it to.
 
 Hui? Wait a second, the firmware doesn't work but still causes an instant
 resume on suspend? Very strange.

Yes, I tested this multiple times - if firmware loads and the init bails 
out, machine resume instantly, like this -

[ 3631.441257] PM: Entering mem sleep
[ 3631.441274] Suspending console(s) (use no_console_suspend to debug)
[ 3631.441825] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 3631.442003] sd 0:0:0:0: [sda] Stopping disk
[ 3631.755076] PM: suspend of devices complete after 313.257 msecs
[ 3631.755219] PM: late suspend of devices complete after 0.134 msecs
[ 3631.795185] PM: noirq suspend of devices complete after 39.904 msecs
[ 3631.821922] pcieport :00:1c.1: power state changed by ACPI to D0
[ 3631.915378] PM: noirq resume of devices complete after 119.999 msecs
[ 3631.915459] PM: early resume of devices complete after 0.062 msecs
[ 3631.915525] ahci :00:1f.2: setting latency timer to 64
[ 3631.915609] ehci-pci :00:1a.7: setting latency timer to 64
[ 3631.915654] uhci_hcd :00:1a.0: setting latency timer to 64
[ 3631.915690] usb usb1: root hub lost power or was reset
[ 3631.915709] snd_hda_intel :00:1b.0: irq 46 for MSI/MSI-X
[ 3631.915770] uhci_hcd :00:1d.0: setting latency timer to 64
[ 3631.915792] usb usb2: root hub lost power or was reset
[ 3631.915804] ehci-pci :00:1d.7: setting latency timer to 64
[ 3631.915821] snd_hda_intel :01:00.1: irq 48 for MSI/MSI-X
[ 3631.918662] [drm] probing gen 2 caps for device 8086:101 = 2212d02/0
[ 3631.918665] [drm] PCIE gen 2 link speeds already enabled
[ 3631.921479] [drm] PCIE GART of 512M enabled (table at 
0x0004).
[ 3631.921584] radeon :01:00.0: WB enabled

Right now, I have removed SUMO_uvd.bin and suspend resume is working 
without fail. Strange indeed, and I only noticed it when the machine did 
not instant resume when running with the UVD disable patch and no_uvd=1 
which skips uvd init just like firmware lodaing failure does I suppose.

 
 My best guess is that it has something todo with a different clock routing on
 Macs, but without access to the hardware (or precise documentation from Apple
 what the heck they did different) I don't really see a chance to solve that
 problem.

Hopefully it is not that hard and we'll find a way! I will experiment the 
clocks and see how that goes.

 If you want to hack a bit on it you could try commenting out the calls to
 radeon_set_uvd_clocks in radeon_uvd.c. That should give you the default
 clocks of 100Mhz, not enough for usable decoding, but on SUMO based UVD blocks
 a very failsafe default.
 
 Whatever it is, please send me an output of lspci, so I can blacklist the
 offending chip.
 
Here is the lspci -nn output :

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee 
ATI Whistler [Radeon HD 6600M/6700M/7600M Series] [1002:6741]

Parag___
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

2013-05-09 Thread Inki Dae

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-workid=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-workid=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-workid=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

[Bug 57831] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)

https://bugzilla.kernel.org/show_bug.cgi?id=57831


Alex Deucher alexdeuc...@gmail.com changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #1 from Alex Deucher alexdeuc...@gmail.com  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] 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 ag...@yahoo.com ---
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

[PATCH v2 5/5] drm: Use names of ioctls in debug traces

2013-05-09 Thread Chris Cummins

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 christopher.e.cumm...@intel.com
---
 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

Re: [PATCH v2 5/5] drm: Use names of ioctls in debug traces

On Thu, May 9, 2013 at 9:20 AM, Chris Cummins
christopher.e.cumm...@intel.com 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 christopher.e.cumm...@intel.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  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

[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 dawit...@sbcglobal.net ---
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: 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.936042] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
 [1.936044] nouveau  [  DEVICE][:01:00.0] Chipset:

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:[a01abb7e] [a01abb7e] 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).
 [2.312503] [drm] No driver support for vblank timestamp query.
 [

[Bug 63236] kwin crashes when some desktop effects are used

https://bugs.freedesktop.org/show_bug.cgi?id=63236

Eugene omegat...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Eugene omegat...@gmail.com ---
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 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

[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 char...@matrox.com
---
 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 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 char...@matrox.com
---
 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,

[PATCH 3/4] drm/mgag200: Convert counter delays to jiffies

Signed-off-by: Christopher Harvey char...@matrox.com
---
 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 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 char...@matrox.com
Signed-off-by: Mathieu Larouche mathieu.larou...@matrox.com
---
 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
+   addr20 - CRTCEXT06
+   addr19-16 - CRTCEXT03-0
+   addr15-8 - CRTCC7-0
+   addr7-0 - CRTCD7-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  (120)))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 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 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 char...@matrox.com
Tested-by: Julia Lemire jlem...@matrox.com
Acked-by: Julia Lemire jlem...@matrox.com
Acked-by: Mathieu Larouche mathieu.larou...@matrox.com
---
 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 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 char...@matrox.com
Acked-by: Julia Lemire jlem...@matrox.com
Tested-by: Julia Lemire jlem...@matrox.com
Acked-by: Mathieu Larouche mathieu.larou...@matrox.com
---
 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 |=

[PATCH v2 3/4] drm/mgag200: Convert counter delays to jiffies

Signed-off-by: Christopher Harvey char...@matrox.com
Acked-by: Julia Lemire jlem...@matrox.com
Tested-by: Julia Lemire jlem...@matrox.com
Acked-by: Mathieu Larouche mathieu.larou...@matrox.com
---
 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 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 char...@matrox.com
Signed-off-by: Mathieu Larouche mathieu.larou...@matrox.com
Acked-by: Julia Lemire jlem...@matrox.com
Tested-by: Julia Lemire jlem...@matrox.com
---
 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
+   addr20 - CRTCEXT06
+   addr19-16 - CRTCEXT03-0
+   addr15-8 - CRTCC7-0
+   addr7-0 - CRTCD7-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  (120)))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

Re: [PATCH 0/4] mgag200 fixes


Christopher Harvey char...@matrox.com 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

[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 luke-jr+linuxb...@utopios.org  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 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 alexdeuc...@gmail.com  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 11/12] drm: DRM should depend on HAS_DMA

2013-05-09 Thread Geert Uytterhoeven

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 ge...@linux-m68k.org
Cc: David Airlie airl...@linux.ie
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

[PATCH] radeon: add RADEON_SURF_FMASK flag which disables 2D-1D tiling transition

2013-05-09 Thread Marek Olšák

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

[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 luke-jr+linuxb...@utopios.org  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 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 alexdeuc...@gmail.com  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

[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

[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 l...@amacapital.net
---
 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 uapi/asm/mtrr.h
 
 
-/*  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 asm/e820.h
 #include asm/mtrr.h
 #include asm/msr.h
+#include asm/pat.h
 
 #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.

[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 l...@amacapital.net
---
 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 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 l...@amacapital.net
---

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_IO; /* not in core dump */
-

[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 l...@amacapital.net
---

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__)
-   if (map-type != _DRM_AGP) {
-

[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 l...@amacapital.net
---

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 linux/vga_switcheroo.h
 #include linux/slab.h
 #include acpi/video.h
-#include asm/pat.h
 
 #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 6/8] radeon: Switch to arch_phys_wc_add and add a missing ..._del

Signed-off-by: Andy Lutomirski l...@amacapital.net
---
 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

[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 l...@amacapital.net
---
 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 video/vga.h
 #endif
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#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 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 l...@amacapital.net
---

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 linux/mm.h
 #include linux/cdev.h
 #include linux/mutex.h
+#include linux/io.h
 #include linux/slab.h
 #if defined(__alpha__) || defined(__powerpc__)
 #include asm/pgtable.h   /* For pte_wrprotect */
 #endif
-#include asm/io.h
 #include asm/mman.h
 #include asm/uaccess.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
 #if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
 #include linux/types.h
 #include linux/agp_backend.h
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

[Bug 64376] radeon fatal error during GPU init (Radeon 5850, KVM GPU passthrough)

https://bugs.freedesktop.org/show_bug.cgi?id=64376

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
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

[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 luke-jr+linuxb...@utopios.org  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 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 alexdeuc...@gmail.com  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

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 mar...@gmail.com wrote:
 I will release a new version of libdrm after this is committed.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  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


Luke-Jr luke-jr+linuxb...@utopios.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #8 from Luke-Jr luke-jr+linuxb...@utopios.org  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: [RFC/PATCH v2 0/8] Clean up write-combining MTRR addition

2013-05-09 Thread Jerome Glisse

On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski l...@amacapital.net 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

[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: [f80efb94] 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:[f80efb94] 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]  [f8828415] ? radeon_bo_create+0x145/0x180 [radeon]
[  133.922104]  [f886e79d] evergreen_pcie_gen2_enable+0x8d/0x1a0 [radeon]
[  133.922104]  [f886e8c0] evergreen_startup+0x10/0x1970 [radeon]
[  133.922104]  [f8829403] ? radeon_gart_table_vram_alloc+0x53/0x60 [radeon]
[  133.922104]  [f8853eb9] ? r600_pcie_gart_init+0x59/0x60 [radeon]
[  133.922104]  [f887039c] evergreen_init+0x17c/0x290 [radeon]
[  133.922104]  [f8813559] radeon_device_init+0x559/0x610 [radeon]
[  133.922104]  [f8812180] ? cail_mc_write+0x20/0x20 [radeon]
[  133.922104]  [f8814dd8] radeon_driver_load_kms+0x78/0x120 [radeon]
[  133.922104]  [f80efd5b] drm_get_pci_dev+0x12b/0x240 [drm]
[  133.922104]  [f88120e1] radeon_pci_probe+0x81/0xa0 [radeon]
[  133.922104]  [c120efdb] pci_device_probe+0x7b/0xc0
[  133.922104]  [c129207c] driver_probe_device+0x5c/0x1e0
[  133.922104]  [c120e6da] ? pci_match_device+0xaa/0xc0
[  133.922104]  [c1292289] __driver_attach+0x89/0x90
[  133.922104]  [c1292200] ? driver_probe_device+0x1e0/0x1e0
[  133.922104]  [c1290a82] bus_for_each_dev+0x42/0x70
[  133.922104]  [c1291c7c] driver_attach+0x1c/0x30
[  133.922104]  [c1292200] ? driver_probe_device+0x1e0/0x1e0
[  133.922104]  [c129186c] bus_add_driver+0xcc/0x220
[  133.922104]  [c120ee90] ? pci_dev_put+0x20/0x20
[  133.922104]  [c1292715] driver_register+0x65/0x130
[  133.922104]  [c120f0be] __pci_register_driver+0x2e/0x40
[  133.922104]  [f80eff65] drm_pci_init+0xf5/0x100 [drm]
[  133.922104]  [f88ba052] radeon_init+0x52/0x6f [radeon]
[  133.922104]  [c100113f] do_one_initcall+0x2f/0x170
[  133.922104]  [c10d765e] ? __vunmap+0x6e/0xd0
[  133.922104]  [f88ba000] ? 0xf88b9fff
[  133.922104]  [c1081ce4] load_module+0x1ad4/0x2050
[  133.922104]  [c10d5a93] ? vmap_page_range_noflush+0x103/0x190
[  133.922104]  [c11f83a0] ? _copy_from_user+0x30/0x50
[  133.922104]  [c10822da] sys_init_module+0x7a/0xa0
[  133.922104]  [c1397c60] 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: [f80efb94] 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

[Bug 57921] NULL pointer dereference in radeon_bo_create

https://bugzilla.kernel.org/show_bug.cgi?id=57921





--- Comment #1 from Luke-Jr luke-jr+linuxb...@utopios.org  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 64201] OpenCL usage result segmentation fault on r600g with HD6850.