Re: Mesa >= 23.3.x and python 2.6 ...

On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch wrote: > I noticed that with version 23.3.x Mesa no longer can be built with python > 2.6. It still worked with Mesa 23.2.1. For anyone who got this far and was completely incredulous... this (and the subject) is typo'd -- the problem is about

Re: [PATCH v10 00/15] dma-fence: Deadline awareness

upport igt-tests, and compositors which delay decisions about which > client buffer to display), and a sw_sync ioctl to read back the > deadline. IGT tests utilizing these can be found at: I read through the series and didn't spot anything. Have a rather weak Reviewed-by: Matt Turner Thanks!

Re: [PATCH v9 15/15] drm/i915: Add deadline based boost support

On Fri, Mar 3, 2023 at 10:08 AM Tvrtko Ursulin wrote: > > > On 03/03/2023 14:48, Rob Clark wrote: > > On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin > > wrote: > >> > >> > >> On 03/03/2023 03:21, Rodrigo Vivi wrote: > >>> On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote: > From: Rob

Re: gitlab.fd.o financial situation and impact on services

On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone wrote: > > Hi Matt, > > On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote: > > We're paying 75K USD for the bandwidth to transfer data from the > > GitLab cloud instance. i.e., for viewing the https site, for > &

Re: gitlab.fd.o financial situation and impact on services

On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter wrote: > > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially

Re: [Mesa-dev] XDC 2017 feedback

On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark wrote: > If you had known of the khr dates, and brought it up in Feb (or really > somewhat earlier, given that XDC is roughly same time each year +/- > few weeks), that *might* have been early enough to move things. That's unfair.

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 21 March 2017 at 18:06, Matt Turner <matts...@gmail.com> wrote: >> (1) Non-recursive automake is necessary for parallel build performance > Fully agree > >> (2) Non-

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 21 March 2017 at 15:57, Matt Turner <matts...@gmail.com> wrote: >> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 10:10 PM, Jonathan Gray <j...@jsg.id.au> wrote: > On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote: >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >> > Seems like we ended up all

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 10:00 PM, Jonathan Gray <j...@jsg.id.au> wrote: > On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote: >> >> >> On 21/03/17 06:39, Emil Velikov wrote: >> > On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wro

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote: >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> Seems like we

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov wrote: > Seems like we ended up all over the place, so let me try afresh. > > Above all: > - Saying "I don't care" about your users is arrogant - let us _not_ > do that, please ? Let's be honest, the OpenBSD is subjecting

[ANNOUNCE] libdrm 2.4.72

runtime complaints on platform devices Junwei Zhang (1): amdgpu: add the function to get the marketing name (v4) Matt Turner (4): intel: Add uthash.h to Makefile.sources. amdgpu: Add amdgpu_asic_id.h to Makefile.sources. freedreno: Add fd_ringbuffer_flush2 to symbol check

[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry wrote: > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c > b/src/mesa/drivers/dri/i965/intel_batchbuffer.c > index 54081a1..ca90784 100644 > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c > +++

[PATCH libdrm] configure: Add flag to disable valgrind support.

On Mon, Jun 22, 2015 at 10:07 AM, Emil Velikov wrote: > On 22 June 2015 at 16:56, Matt Turner wrote: >> --- >> configure.ac | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/configure.ac b/configure.ac >> index 78a001

[PATCH libdrm] configure: Add flag to disable valgrind support.

--- configure.ac | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 78a0010..dd6c0ab 100644 --- a/configure.ac +++ b/configure.ac @@ -403,7 +403,15 @@ else fi AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test

[PATCH] Add DRM_CAS for mips32

On Thu, May 14, 2015 at 5:12 AM, Aleksey Kuleshov wrote: > Signed-off-by: Aleksey Kuleshov > --- At least a few years ago, DRM_CAS was only used by DRI1 which is pretty dead at this point. Has something changed? What problem are you trying to solve?

[PATCH 2/4] drm/cache: Try to be smarter about clflushing on x86

On Sat, Dec 13, 2014 at 7:08 PM, Ben Widawsky wrote: > Any GEM driver which has very large objects and a slow CPU is subject to very > long waits simply for clflushing incoherent objects. Generally, each > individual > object is not a problem, but if you have very large objects, or very many >

[Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails

problem in the referenced bug report. > > Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681 > Signed-off-by: Keith Packard > --- Seems like a good plan. Reviewed-by: Matt Turner Should we add a Cc: for the stable branch?

[PATCH] glx/dri3: Use four buffers until X driver supports async flips

Cc'ing people who might be able to review.

looking for i915 direct programming sample application

On Sat, Jun 7, 2014 at 3:45 PM, G?bor Bereczki wrote: > did some more research. Is the following correct? > -OpenCL is not yet supported for Intel GPU on Linux The Beignet project [1] supports OpenCL IvyBridge (and Haswell, I think). I believe your time would be much better spent contributing

[PATCH 02/33] drm/vmwgfx: Update the svga3d register header file for new device version

On Thu, Jan 16, 2014 at 12:38 PM, Thomas Hellstrom wrote: > Reivewed-by: Zack Rusin Typo.

[Mesa-dev] rules for merging patches to libdrm

On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie wrote: > Since we seemed to have some confusion over this I'll state it clearly here. > > You should not merge kernel interface and ioctls to libdrm until they > have appeared in a git commit upstream with a stable id, this > generally means drm-next,

[PATCH] Fix build of swrast only without libdrm

On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin wrote: > > Signed-off-by: Daniel Martin > --- > There's a small logic error preventing mesa to be build with swrast only > and not having libdrm. > > configure.ac |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git

Re: [PATCH] Fix build of swrast only without libdrm

On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin consume.no...@gmail.com wrote: Signed-off-by: Daniel Martin consume.no...@gmail.com --- There's a small logic error preventing mesa to be build with swrast only and not having libdrm. configure.ac |2 +- 1 files changed, 1 insertions(+),

clang: warning: argument unused during compilation: '-fno-builtin-memcmp'

On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek wrote: > Hi, > > I am playing with llvm/clang v3.2 and mesa. > > It's annoying to see these hundreds of warnings... > > clang: warning: argument unused during compilation: '-fno-builtin-memcmp' > > NOTE: '-fno-builtin-memcmp' is a gcc-specific

Re: clang: warning: argument unused during compilation: '-fno-builtin-memcmp'

On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek sedat.di...@gmail.com wrote: Hi, I am playing with llvm/clang v3.2 and mesa. It's annoying to see these hundreds of warnings... clang: warning: argument unused during compilation: '-fno-builtin-memcmp' NOTE: '-fno-builtin-memcmp' is a

[PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen wrote: > Signed-off-by: Huacai Chen > Signed-off-by: Hongliang Tao > Signed-off-by: Hua Yan > Cc: dri-devel at lists.freedesktop.org > --- > include/drm/drm_sarea.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git

Re: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen chenhua...@gmail.com wrote: Signed-off-by: Huacai Chen che...@lemote.com Signed-off-by: Hongliang Tao ta...@lemote.com Signed-off-by: Hua Yan y...@lemote.com Cc: dri-devel@lists.freedesktop.org --- include/drm/drm_sarea.h |2 ++ 1 files

[PATCH] mgag200: initial g200se driver

> @@ -0,0 +1,1494 @@ > +/* > + * Copyright 2000,2001 Sven Luther. Here... > + * Copyright 2010 Matt Turner. > + * Copyright 2011 Red Hat > + * > + * This file is subject to the terms and conditions of the GNU General > + * Public License version 2. See the file COPYING in the main > +

Re: [PATCH] mgag200: initial g200se driver

@@ +/* + * Copyright 2000,2001 Sven Luther. Here... + * Copyright 2010 Matt Turner. + * Copyright 2011 Red Hat m...@redhat.com + * + * This file is subject to the terms and conditions of the GNU General + * Public License version 2. See the file COPYING in the main + * directory of this archive

[PATCH] Only build test programs with make check

On Sat, Mar 17, 2012 at 2:35 PM, Jakob Bornecrantz wrote: > With my limited knowledge of automake I'm going to have > to NACK this patch. Most of these programs are used during > driver bring up to test things out, often we also modify > them a bit to suit our need. > > If this patch doesn't make

[PATCH] Only build test programs with make check

Signed-off-by: Matt Turner --- tests/kmstest/Makefile.am |2 +- tests/modeprint/Makefile.am |2 +- tests/modetest/Makefile.am |2 +- tests/radeon/Makefile.am|2 +- tests/vbltest/Makefile.am |2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/tests

[PATCH] Only build test programs with make check

Signed-off-by: Matt Turner matts...@gmail.com --- tests/kmstest/Makefile.am |2 +- tests/modeprint/Makefile.am |2 +- tests/modetest/Makefile.am |2 +- tests/radeon/Makefile.am|2 +- tests/vbltest/Makefile.am |2 +- 5 files changed, 5 insertions(+), 5 deletions

Re: [PATCH] Only build test programs with make check

On Sat, Mar 17, 2012 at 2:35 PM, Jakob Bornecrantz ja...@vmware.com wrote: With my limited knowledge of automake I'm going to have to NACK this patch. Most of these programs are used during driver bring up to test things out, often we also modify them a bit to suit our need. If this patch

[PATCH libdrm] Don't require pciaccess if Intel is disabled

Signed-off-by: Matt Turner --- configure.ac | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 97bbcb7..71a596c 100644 --- a/configure.ac +++ b/configure.ac @@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs

[PATCH libdrm] Don't require pciaccess if Intel is disabled

Signed-off-by: Matt Turner matts...@gmail.com --- configure.ac | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 97bbcb7..71a596c 100644 --- a/configure.ac +++ b/configure.ac @@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS

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

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

[PATCH] drm/radeon: use DDC_ADDR instead of hard-coding it

Signed-off-by: Matt Turner --- drivers/gpu/drm/radeon/radeon_i2c.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c b/drivers/gpu/drm/radeon/radeon_i2c.c index 6c111c1..37a6d38 100644 --- a/drivers/gpu/drm/radeon/radeon_i2c.c +++ b

[PATCH] drm: remove unneeded redefinition of DDC_ADDR

It's already defined in drm_edid.h. Signed-off-by: Matt Turner --- drivers/gpu/drm/drm_edid.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7425e5c..9fa8316 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b

[PATCH] drm: remove unneeded redefinition of DDC_ADDR

It's already defined in drm_edid.h. Signed-off-by: Matt Turner matts...@gmail.com --- drivers/gpu/drm/drm_edid.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7425e5c..9fa8316 100644 --- a/drivers/gpu/drm

[PATCH] drm/radeon: use DDC_ADDR instead of hard-coding it

Signed-off-by: Matt Turner matts...@gmail.com --- drivers/gpu/drm/radeon/radeon_i2c.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c b/drivers/gpu/drm/radeon/radeon_i2c.c index 6c111c1..37a6d38 100644 --- a/drivers/gpu/drm/radeon

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

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

Re: [PATCH] modeprint.c: use PRIu64 for printing uint64_t

On Thu, Mar 3, 2011 at 9:04 PM, Matt Turner matts...@gmail.com wrote: Signed-off-by: Matt Turner matts...@gmail.com ---  tests/modeprint/modeprint.c |    7 ---  1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c index

[PATCH 4/6] drm/radeon: Add a rmb() in IH processing

On Wed, Jul 13, 2011 at 6:28 AM, Benjamin Herrenschmidt wrote: > We should have a read memory barrier between reading the WPTR from > memory and reading ring entries based on that value (ie, we need to > ensure both loads are done in order by the CPU). > > It could be argued that the MMIO reads

[PATCH 0/3] alpha, drm: Update Alpha DRM support

> ?drivers/gpu/drm/mga/mga_drv.h ? ? ? | ? 19 --- > ?drivers/gpu/drm/radeon/radeon_ttm.c | ? 23 +++ > ?4 files changed, 24 insertions(+), 23 deletions(-) Patches 1 and 3 are Tested-by: Matt Turner They also fix Bugzilla: https://bugs.freedesktop.org/sh

Re: [PATCH 0/3] alpha, drm: Update Alpha DRM support

---  drivers/gpu/drm/radeon/radeon_ttm.c |   23 +++  4 files changed, 24 insertions(+), 23 deletions(-) Patches 1 and 3 are Tested-by: Matt Turner matts...@gmail.com They also fix Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=23227 In that report

BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

On Wed, May 25, 2011 at 8:12 PM, Thierry Vignaud wrote: > On 25 May 2011 17:43, Alex Deucher wrote: >>> Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes >>> immediately upon start. >> >> Any reason you are not using kms? > > Any reason you are not respecting the

Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

On Wed, May 25, 2011 at 8:12 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 25 May 2011 17:43, Alex Deucher alexdeuc...@gmail.com wrote: Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes immediately upon start. Any reason you are not using kms? Any reason

[PATCH] drm: Add a driver for kvm emulated Cirrus

icated in at least Nouveau, glint, and now cirrusfb. I guess we should fix that at some point. The only other nit-pick I've got is that I named variables gfb and gfbdev because I'm uncreative with variable names and because glint started with a 'g'. Not important though. Thanks, I'll have to give it a try. Please have a Reviewed-by: Matt Turner Matt

Re: [PATCH] drm: Add a driver for kvm emulated Cirrus

we should fix that at some point. The only other nit-pick I've got is that I named variables gfb and gfbdev because I'm uncreative with variable names and because glint started with a 'g'. Not important though. Thanks, I'll have to give it a try. Please have a Reviewed-by: Matt Turner matts

Future desktop on dumb frame buffers?

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox wrote: >> ? 1) inertia: fbdev has been around a lot longer, and provides most of >> ? what embedded devices need anyway >> ? 2) feature set: why bother doing a full KMS driver if you're not >> ? going to use any of the additional features it would provide

Re: Future desktop on dumb frame buffers?

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:   1) inertia: fbdev has been around a lot longer, and provides most of   what embedded devices need anyway   2) feature set: why bother doing a full KMS driver if you're not   going to use any of the additional features

[PATCH] don't try to build modetest without libkms

Signed-off-by: Matt Turner --- tests/Makefile.am |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index ebf4853..01ca8b4 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -16,9 +16,6 @@ if HAVE_LIBKMS SUBDIRS

[PATCH] modeprint.c: use PRIu64 for printing uint64_t

Signed-off-by: Matt Turner --- tests/modeprint/modeprint.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c index 09b8df0..545ff40 100644 --- a/tests/modeprint/modeprint.c +++ b/tests/modeprint/modeprint.c

[PATCH] modeprint.c: use PRIu64 for printing uint64_t

Signed-off-by: Matt Turner matts...@gmail.com --- tests/modeprint/modeprint.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c index 09b8df0..545ff40 100644 --- a/tests/modeprint/modeprint.c +++ b/tests

[PATCH] don't try to build modetest without libkms

Signed-off-by: Matt Turner matts...@gmail.com --- tests/Makefile.am |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index ebf4853..01ca8b4 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -16,9 +16,6 @@ if HAVE_LIBKMS

[Bug 29842] Radeon runs very hot

On Fri, Feb 25, 2011 at 5:11 PM, Phillip Susi wrote: > So I have been looking over the source code in drivers/gpu/drm/radeon. > I see various functions to start/stop/resume/initialize "mc" and "cp". > I assume those stand for microcode and control program? ?What exactly is > the difference?

Re: [Bug 29842] Radeon runs very hot

On Fri, Feb 25, 2011 at 5:11 PM, Phillip Susi ps...@cfl.rr.com wrote: So I have been looking over the source code in drivers/gpu/drm/radeon. I see various functions to start/stop/resume/initialize mc and cp. I assume those stand for microcode and control program?  What exactly is the

[PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher wrote: > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: >> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: >>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: >>> > Just two quick notes. I'll try to do a full review this weekend. >>> >

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls awa...@md.metrocast.net wrote: On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil hansv...@cisco.com wrote: Just two quick

[PATCH 2/2] amd-k7-agp: remove non-x86 code

amd-k7-agp can't be built on Alpha anymore, so remove now unnecessary code. Signed-off-by: Matt Turner --- drivers/char/agp/amd-k7-agp.c | 19 --- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c

[PATCH 1/2] Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen"

on Nautilus. So there's no point in allowing this driver to be configured on Alpha. Signed-off-by: Matt Turner --- drivers/char/agp/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig index fcd867d..d8b1b57 100644

[PATCH 2/2] amd-k7-agp: remove non-x86 code

amd-k7-agp can't be built on Alpha anymore, so remove now unnecessary code. Signed-off-by: Matt Turner matts...@gmail.com --- drivers/char/agp/amd-k7-agp.c | 19 --- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp

[PATCH 1/2] Revert agp: AMD AGP is used on UP1100 UP1500 alpha boxen

on Nautilus. So there's no point in allowing this driver to be configured on Alpha. Signed-off-by: Matt Turner matts...@gmail.com --- drivers/char/agp/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig index fcd867d

intelfb refuses to load

On Sat, Dec 11, 2010 at 10:13 PM, Pavel Machek wrote: You want CONFIG_DRM_I915 and not CONFIG_FB_INTEL. The old framebuffer driver should not be used in conjunction with xf86-video-intel. Matt

Re: intelfb refuses to load

On Sat, Dec 11, 2010 at 10:13 PM, Pavel Machek pa...@ucw.cz wrote: You want CONFIG_DRM_I915 and not CONFIG_FB_INTEL. The old framebuffer driver should not be used in conjunction with xf86-video-intel. Matt ___ dri-devel mailing list

@tungstengraphics.com email addresses all over bugzilla

We should update everyone's email addresses, now that tungstengraphics.com is owned by squatters. Who let that happen, by the way? :\ Matt

@tungstengraphics.com email addresses all over bugzilla

We should update everyone's email addresses, now that tungstengraphics.com is owned by squatters. Who let that happen, by the way? :\ Matt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

3Dfx KMS board needed

On Wed, Nov 10, 2010 at 7:45 PM, James Simmons wrote: > Looking to work on the 3Dfx KMS driver I discovered that it is very > difficult to find a motherboard that supports AGP of 3.3V. So I discovered > that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP > Card which also is

Re: 3Dfx KMS board needed

On Wed, Nov 10, 2010 at 7:45 PM, James Simmons jsimm...@infradead.org wrote: Looking to work on the 3Dfx KMS driver I discovered that it is very difficult to find a motherboard that supports AGP of 3.3V. So I discovered that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP

[PATCH 1/4] drivers/gpu/drm/vmwgfx: Fix k.alloc switched arguments

it(struct vmw_private *dev_priv) > ? ? ? ? ? ? ? ?return -ENOSYS; > ? ? ? ?} > > - ? ? ? overlay = kmalloc(GFP_KERNEL, sizeof(*overlay)); > + ? ? ? overlay = kmalloc(sizeof(*overlay), GFP_KERNEL); > ? ? ? ?if (!overlay) > ? ? ? ? ? ? ? ?return -ENOMEM; > > -- > 1.7.3.1.g432b3.dirty Oh! That's a bad one. Reviewed-by: Matt Turner

Re: [PATCH 1/4] drivers/gpu/drm/vmwgfx: Fix k.alloc switched arguments

= kmalloc(GFP_KERNEL, sizeof(*overlay)); +       overlay = kmalloc(sizeof(*overlay), GFP_KERNEL);        if (!overlay)                return -ENOMEM; -- 1.7.3.1.g432b3.dirty Oh! That's a bad one. Reviewed-by: Matt Turner matts...@gmail.com ___ dri-devel

[RFC libdrm] Use __sync_val_compare_and_swap to implement DRM_CAS

Can we use gcc's __sync_val_compare_and_swap to implement DRM_CAS? (If so, do we actually need the __sync_val version, or can we use __sync_bool?) I just threw the patch together in two minutes, so I've got no idea if it's right, just looking for feedback. The purpose of this is to remove a lot

[RFC libdrm] Use __sync_val_compare_and_swap to implement DRM_CAS

Can we use gcc's __sync_val_compare_and_swap to implement DRM_CAS? (If so, do we actually need the __sync_val version, or can we use __sync_bool?) I just threw the patch together in two minutes, so I've got no idea if it's right, just looking for feedback. The purpose of this is to remove a lot

[PATCH] drm/radeon/kms: fix bad cast/shift in evergreen.c

t; 28; > + ? ? ? ? ? ? ? efuse_box_bit_127_124 = (u8)((efuse_straps_3 & 0xF000) >> > 28); > > ? ? ? ? ? ? ? ?switch(efuse_box_bit_127_124) { > ? ? ? ? ? ? ? ?case 0x0: > -- > 1.7.1.1 Reviewed-by: Matt Turner

GSoC: modprobe glint - monitor loses signal

I'll preface this response by saying that the driver is working now, in very large part due to help I've received from Adam Jackson, Dave Airlie, Alex Deucher, and Jerome Glisse. On Thu, Aug 5, 2010 at 5:47 PM, Adam Jackson wrote: > On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote: &g

GSoC: modprobe glint - monitor loses signal

Hi, I've hit a snag and I'm not really sure how to debug it. Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in virtually identical ways. I'm trying to do the same, but I think some of what I'm passing in from drm_display_mode is

Re: GSoC: modprobe glint - monitor loses signal

I'll preface this response by saying that the driver is working now, in very large part due to help I've received from Adam Jackson, Dave Airlie, Alex Deucher, and Jerome Glisse. On Thu, Aug 5, 2010 at 5:47 PM, Adam Jackson a...@redhat.com wrote: On Thu, 2010-08-05 at 12:16 -0400, Matt Turner

[PATCH 1/4] drm: Remove drm_resource wrappers

620,15 +621,16 @@ int savage_driver_firstopen(struct drm_device *dev) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev_priv->mtrr[0].size, DRM_MTRR_WC); > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ? ? ?DRM_ERROR("strange pci_resource_len %08llx\n", > - ? ? ? ? ? ? ? ? ? ? ? ? ?

Re: Problems with alpha/pci + radeon/ttm

On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: On Thu, 24 Jun 2010 10:53:52 -0400 Matt Turner matts...@gmail.com wrote: Seems that the IOMMU can't find 128 pages. It's likely due to: - out of the IOMMU space (possibly someone doesn't free the IOMMU

Problems with alpha/pci + radeon/ttm

On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori wrote: > On Thu, 24 Jun 2010 10:53:52 -0400 > Matt Turner wrote: > >> > Seems that the IOMMU can't find 128 pages. It's likely due to: >> > >> > - out of the IOMMU space (possibly someon

Problems with alpha/pci + radeon/ttm

On Thu, Jun 24, 2010 at 5:51 AM, Michael Cree wrote: > On 22/06/10 20:32, Dave Airlie wrote: >> >> On Tue, Jun 22, 2010 at 3:59 PM, FUJITA Tomonori >> ?wrote: >>> >>> On Mon, 21 Jun 2010 17:19:43 -0400 >>> Matt Turner ?wrote: >>> >>

Problems with alpha/pci + radeon/ttm

On Tue, Jun 22, 2010 at 1:59 AM, FUJITA Tomonori wrote: > On Mon, 21 Jun 2010 17:19:43 -0400 > Matt Turner wrote: > >> Michael Cree and I have been debugging FDO bug 26403 [1]. I tried >> booting with `radeon.test=1` and found this, which I think is related: >>

Re: Problems with alpha/pci + radeon/ttm

On Tue, Jun 22, 2010 at 1:59 AM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: On Mon, 21 Jun 2010 17:19:43 -0400 Matt Turner matts...@gmail.com wrote: Michael Cree and I have been debugging FDO bug 26403 [1]. I tried booting with `radeon.test=1` and found this, which I think

Re: Problems with alpha/pci + radeon/ttm

On Thu, Jun 24, 2010 at 5:51 AM, Michael Cree mc...@orcon.net.nz wrote: On 22/06/10 20:32, Dave Airlie wrote: On Tue, Jun 22, 2010 at 3:59 PM, FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp  wrote: On Mon, 21 Jun 2010 17:19:43 -0400 Matt Turnermatts...@gmail.com  wrote: Michael Cree and I

Problems with alpha/pci + radeon/ttm

* failed to bind 128 pages at 0x0FF02000 Is this the cause of the bug we're seeing in the report [1]? Anyone know what's going wrong here? Thanks! Matt Turner [1] https://bugs.freedesktop.org/show_bug.cgi?id=26403 ___ dri-devel mailing list dri-devel

Problems with alpha/pci + radeon/ttm

Michael Cree and I have been debugging FDO bug 26403 [1]. I tried booting with `radeon.test=1` and found this, which I think is related: > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x202000 > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x302000 [snip] > [drm] Tested

[PATCH] DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300)

On Thu, Jun 17, 2010 at 7:02 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a regression from 2.6.34 related to the recent radeon power > management changes, caused by attempting to cancel a delayed work > item that's never been scheduled. ?However, the code as is has some >

[PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

On Wed, Jun 2, 2010 at 3:16 PM, Alex Deucher wrote: > On Wed, Jun 2, 2010 at 2:32 PM, Matt Turner wrote: >> On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher >> wrote: >>> Fixes: >>> https://bugs.freedesktop.org/show_bug.cgi?id=28327 >>> >>> Signed

[PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher wrote: > Fixes: > https://bugs.freedesktop.org/show_bug.cgi?id=28327 > > Signed-off-by: Alex Deucher > --- > ?drivers/gpu/drm/radeon/r600_cs.c | ? 43 ++--- > ?1 files changed, 16 insertions(+), 27 deletions(-) > > diff

Re: [PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher alexdeuc...@gmail.com wrote: Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28327 Signed-off-by: Alex Deucher alexdeuc...@gmail.com ---  drivers/gpu/drm/radeon/r600_cs.c |   43 ++---  1 files changed, 16

Re: [PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

On Wed, Jun 2, 2010 at 3:16 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jun 2, 2010 at 2:32 PM, Matt Turner matts...@gmail.com wrote: On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher alexdeuc...@gmail.com wrote: Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28327 Signed-off

[PATCH 1/3] r600: add span support for 2D tiling

On Thu, May 27, 2010 at 7:52 PM, Alan Cox wrote: >> Look up tables have some hidden penalties but I think it might be a >> win. Looks like we may have to benchmark the solutions against one >> another to really know which is best in real life. > > For x86 and ppc the single assembler instruction

[PATCH 1/4] drm: Remove drm_resource wrappers

Seems like a good simplification. Reviewed-by: Matt Turner

[PATCH 1/3] r600: add span support for 2D tiling

> +static inline GLint r600_log2(GLint n) > +{ > + ? ? ? GLint log2 = 0; > + > + ? ? ? while (n >>= 1) > + ? ? ? ? ? ? ? ++log2; > + ? ? ? return log2; > +} Does mesa not provide something like this? Matt

[PATCH 2/20] drivers/gpu/drm: Use kzalloc

; ? ? ? ? ? ? ? ?return -ENOMEM; > > - ? ? ? memset(dev_priv, 0, sizeof(drm_savage_private_t)); > ? ? ? ?dev->dev_private = (void *)dev_priv; > > ? ? ? ?dev_priv->chipset = (enum savage_family)chipset; > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Reviewed-by: Matt Turner

Re: [PATCH 2/20] drivers/gpu/drm: Use kzalloc

));        dev-dev_private = (void *)dev_priv;        dev_priv-chipset = (enum savage_family)chipset; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel Reviewed-by: Matt Turner matts

Re: [PATCH] drm/radeon: Fix sparc regression in r300_scratch()

); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel Should help Alpha as well. Acked-by: Matt Turner matts...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org

[PATCH] agp: use scratch page on memory remove and at GATT creation V4

On Thu, Apr 22, 2010 at 6:30 AM, Jerome Glisse wrote: > On Thu, Apr 22, 2010 at 11:27:11AM +0200, Daniel Vetter wrote: >> On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote: >> > Convert most AGP chipset to use scratch page as default entries. >> > This help avoiding GPU querying 0

  1   2   >