agp/sworks-agp.c | 18 ---
6 files changed, 73 insertions(+), 28 deletions(-)
commit 44a207fc66c13c82f627178f9f858b8f3e76028f
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Wed Feb 20 10:37:08 2008 +1000
agp: fix missing casts that produced a warning.
Signed-off
s/char/drm/via_video.c |4 +-
61 files changed, 2291 insertions(+), 770 deletions(-)
commit 3d5e2c13b13468f5eb2ac9323690af7e17f195fe
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Thu Feb 7 15:01:05 2008 +1000
drm: add initial r500 drm support
This adds CP support for the r500
ntel-agp.c| 305 +++
include/linux/agp_backend.h |1 +
include/linux/agpgart.h |1 +
11 files changed, 276 insertions(+), 71 deletions(-)
commit bc894606e8843808c232319f69c26c18f6eaa662
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Tue Feb
On Jan 10, 2008 7:55 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 07:44:03PM +1000, Dave Airlie wrote:
> > >
> > > finally managed to get the time to review your CPA patchset, and i
> > > fundamentally agree with most of the detail chan
>
> finally managed to get the time to review your CPA patchset, and i
> fundamentally agree with most of the detail changes done in it. But here
> are a few structural high-level observations:
>
> - firstly, there's no rationale given. So we'll change ioremap()/etc.
> from doing a cflush-range i
> On Wed, Jan 09, 2008 at 03:37:50AM +0000, Dave Airlie wrote:
> >
> > > The drm drivers in this patch all used drm_ioctl to perform their
> > > ioctl calls. The common function is converted to use lock_kernel()
> > > and unlock_kernel() and the drivers
>
> An alternative might be to come up with something decent and target 2.6.24.x
I don't see mmiotrace getting merged into a stable kernel... how do
however see it getting cleaned up for 2.6.25 now that people know how
fragile the kernel hooks for it are..
> We put the crappy code back in for
> The drm drivers in this patch all used drm_ioctl to perform their
> ioctl calls. The common function is converted to use lock_kernel()
> and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
>
NAK
I've started looking at this already in the drm git tree, I'm going to
prov
> On Wed, 9 Jan 2008 02:34:46 + (GMT) Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> >
> > [This an initial RFC but I'd like to have this patch in before 2.6.24 goes
> > final as it really breaks this useful feature]
> >
> > mmiotrace the MMI
[This an initial RFC but I'd like to have this patch in before 2.6.24 goes
final as it really breaks this useful feature]
mmiotrace the MMIO access tracer used to reverse engineer binary blobs
used this notifier interface and is planned on being pushed upstream.
Having users able to just use th
> Well they're all gone.. ;)
>
> There is a nopfn method which I converted in a subsequent patch I sent you.
> Maybe that's what you mean?
>
Ah thats what it was, we added a nopfn not a nopage..
Thanks,
Dave.
> Thanks,
> Nick
> >
> > Dave.
> >
> > >
> > > Anyway, please apply.
> > >
> > >
> Dave, this patch is against 2.6.24-rc6-mm1. You said git-drm had rewritten
> this area,
> but the patch didn't have any rejects and seems to run fine here (although
> I'm not
> exactly sure how to exercise drm too well).
Hi Nick,
there should be a new nopage method added though which you ne
On Jan 9, 2008 6:32 AM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 09:06:38PM +0200, Pekka Paalanen wrote:
> > - Is there anything coming to replace register_page_fault_notifier()?
>
> no.
>
> > - Has someone found another way to accomplish the same without patching
> >
> > It doesn't work really, which is mostly the problem :)
> >
> > We mostly use UC on these pages, or WB within cache coherent domains.
> > mtrrs are totally useless in this situation.
> >
>
> In what sense does it not work?
oh I was mostly joking hence the smily.. really it just means thing
run
On Dec 15, 2007 8:00 AM, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 14, 2007 at 12:28:25AM +0000, Dave Airlie wrote:
> > Yes, the main use for GPUs is to have RAM pages mapped WC, and placed into
> > a GART on the GPU side, currently for Intel IGD we ar
> Yes. It is that wonderful time of the year again.
> No, no. We are not talking about holiday season or new year here.
>
> We are talking about one another rehash of "why we do not support PAT in x86"
> question and series of patches that implement some PAT support before going
> into hibernatio
> Convert drm from nopage to fault.
> Remove redundant vma range checks.
Hi Nick,
can you rebase against the -mm tree? or are you pushing this for before
then? if so can you supply me a patch against -mm?
The drm git tree has a new VM user for the memory manager..
Dave.
>
> Signed-off-by: N
> >
> > I also have a few AGP changes I need to line up to support the chipset
> > flushing work I've done to support TTM properly..
> >
>
> Did anything happen with that null-pointer deref I was hitting?
>
I've rebased the patches in my tree along with a chunk I missed which
should make your patc
> What are the prospects of the DRM TTM changes making it into 2.6.24? I
> noticed that Andrew has them [1] in his mm tree... any chance of that
> getting pushed into Linus' tree for 2.6.24?
>
No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm
for the 2.6.23 cycle as we
|2 --
drivers/char/drm/drm_ioctl.c|2 +-
drivers/char/drm/drm_os_linux.h |8
drivers/char/drm/savage_bci.c |3 ---
4 files changed, 1 insertions(+), 14 deletions(-)
Dave Airlie (2):
drm: remove second forward decleration of drm device struct.
drm: remove r
>
> I think its about time we merged this code, it is in an area of the
> kernel wholly self-contained and mostly maintained by me, and adds a
> feature that allows userspace graphics to leverage features of graphics
> cards that only the binary vendors have done up until now.
And I mean to -
Hi all,
These patches are the first set of patches containing the core components
of the DRI memory manger from Tungsten Graphics.
At least one patch is too big for the list, and I spent a lot of time
getting the separation even to this level...
the patches are here:
http://people.freedesktop.
vers/char/drm/drmP.h |2 --
drivers/char/drm/drm_os_linux.h |8
drivers/char/drm/radeon_cp.c|5 +++--
drivers/char/drm/radeon_drv.h |1 +
drivers/char/drm/savage_bci.c |3 ---
drivers/char/drm/sis_mm.c |1 +
6 files changed, 5 insertions(+), 1
+
3 files changed, 5 insertions(+), 2 deletions(-)
Dave Airlie (1):
radeon: set the address to access the GART table on the CPU side correctly
Roel Kluin (1):
drm/sis: missing mutex unlock in error path.
diff --git a/drivers/char/drm/radeon_cp.c b/drivers/char/drm/radeon_cp.c
ind
>
> In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
> right? Can we be sure that a single flush is sufficient? Is there any
> window between when we flush and when we start accessing memory with
> the device that we could get into more caching trouble?
Not that I can
rce
stuff.
Regards,
Dave.From b9dcf514d0f1f61dc482cac622ffd2d79d500bf8 Mon Sep 17 00:00:00 2001
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 15:14:03 +1000
Subject: [PATCH] agp: add chipset flushing support to AGP interface
This bumps the AGP interface to 0.103.
Certain Intel
On 10/15/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Hmm, OK. It looks like DRM vmallocs memory (which gives highmem).
>
> I meant I'm not sure if it uses that memory uncached. I admit
> not quite understanding that code. There used to be at least
> one place where it set UC for an user mapping t
> > But it *is* a key press!
>
> To get somewhat back on track: volume and brightness (and similar - lid
> close etc) events clearly are keypresses.
>
> However, I would also argue that a keypress that is acted on by the
> firmware automatically is *different* from a keypress that hasn't been
> act
s/char/agp/amd-k7-agp.c |9 ++---
drivers/char/agp/backend.c| 12
drivers/char/agp/generic.c| 19 +--
drivers/char/agp/i460-agp.c |4 ++--
drivers/char/agp/intel-agp.c |6 --
7 files changed, 50 insertions(+), 34 deletions(-)
Dave
oval
0x1106, 0x7204 is unknown and thus is not an IGP/GPU.
0x1106, 0x3304 is K8M800 hostbridge, not an IGP/GPU.
None of them are in drm git tree.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit eed0f722b3fccb1eb27
On 10/14/07, Németh Márton <[EMAIL PROTECTED]> wrote:
> From: Márton Németh <[EMAIL PROTECTED]>
>
> As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
> drivers/char/drm/drmP.h), it is not worth doing this again. At some
> other places the ending "\n" was added.
>
> Signed-off-by: M
On 10/14/07, Thomas Bächler <[EMAIL PROTECTED]> wrote:
> Dave Airlie schrieb:
> >> I'm sorry, I forgot to mention that: As I _thought_ it had worked with
> >> rc6, I already found that commit. I reverted it and got a panic again
> >> (no trace, as I was in
On 10/14/07, Thomas Bächler <[EMAIL PROTECTED]> wrote:
> Dave Airlie schrieb:
> > lets start with:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4a7b1d1d90d202a030688ab5b177c3c0f15ee3e
> >
> > and work from there..
>
>
On 10/14/07, Thomas Bächler <[EMAIL PROTECTED]> wrote:
> I first discovered this problem when updating to 2.6.23 final on x86_64.
> When I launched google earth, the kernel paniced. When I tried to
> reproduce, it oopsed instead of panicing.
>
> dri/drm seems to work generally, as I am running bery
Call For Presentations
==
We are happy to announce that the Call for Presentations for LCA
Kernel Miniconf is now open.
LCA Kernel Miniconf is part of linux.conf.au, the annual
Australian Linux & open source developers' conference.
When: 29th January 2008
Where: Melbourne Univer
n Sep 17 00:00:00 2001
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Fri, 28 Sep 2007 11:46:28 +1000
Subject: [PATCH] i915: make vbl interrupts work properly on i965g/gm hw.
This code is ported from the DRM git tree and allows the vblank interrupts
to function on the i965 hw. It also requires
o that it can all be
> disabled with one selection.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Fine by me.. some day we might move the directories but this is a good start..
Acked-by: Dave Airlie <[EMAIL PROTECTED]>
Dave.
> ---
> drivers/char/Kconfig
> > But now I'm talking about another issue -- a regression since rc4-mm1,
> > where X
> > server is unable to bind agp memory (those x logs above). The clflush issue
> > has
> > solved andi in
> > http://lkml.org/lkml/2007/9/19/334
> > recently
>
> Tried that, my laptop still bricks the instant
> >> Fatal server error:
> >> Couldn't bind memory for front buffer
> >>
> >> I thought I'd seen a thread about this issue, but I can't find it now. Is
> >> it
> >> known or am I seeing ghosts yet, Andrew?
> >>
> >
> > Can you send me a complete Xorg log file?
>
> Maybe you are rather interested i
On 9/20/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 09/19/2007 09:54 PM, Andi Kleen wrote:
> >> Yeah. (But X doesn't run -- this is maybe the known issue in this release).
> >
> > What do you mean with not run?
>
> (II) intel(0): Initializing HW Cursor
> (II) intel(0): xf86BindGARTMemory: bind k
effort to
unmapping and freeing pages. My kernel no longer hangs with this
patch...
Jiri can you confirm?
I'll look at the other issue separately..
Dave.
From 225696d75e7ec0bafbb47b935bd700e3fbeefbde Mon Sep 17 00:00:00 2001
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Thu, 20 Sep 2007 1
On 9/20/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 19, 2007 at 12:10:17PM -0700, Andrew Morton wrote:
> > On Wed, 19 Sep 2007 16:59:04 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote:
> >
> > > -8<-8<-8<-8<-8<-8<
> > > That means
> > > voi
2001
From: Dave Airlie <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 00:08:01 +1000
Subject: [PATCH] intel-agp: Fix i830 mask variable that changed with G33 support
The mask on i830 should be 0x70 always, later chips 0xF0 should be okay.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
I sent this mail to David Airlie two weeks ago but I haven't gotten a
reply so far, that's why I'm posting to LKML this time. Short summary:
874808c6dd429f7431b906a32c7f78a68e7636af broke intel_agp.ko for me, I'm
getting a garbled screen.
I'm travelling, and I'll try and get Zhenyu to take a l
What other info needed?
I'm seeing this on my 965gm chipset with Andi's clflush patches on x86
32-bit, it looks like an interaction with the agp code which does a big
bunch of change page attr to allocate the AGP aperture backed memory..
I think the code might have worked in a previous iter
Subject: [PATCH] [AGPGART] intel_agp: fix GTT map size on G33
G33 has 1MB GTT table range. Fix GTT mapping
in case like 512MB aperture size.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
Acked-by: Dave Airlie <[EMAIL PROTECTED]>
Ditto. What happens if this patch isn't i
travelling is still in
progress, so if you could send them to Linus...
Acked-by: Dave Airlie <[EMAIL PROTECTED]>
---
drivers/char/agp/intel-agp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-ag
Note the slab has a memory tracking feature that accounts memory to
callers of the allocator. IF that's not enough for you please help
improving the common code instead of inventing your own.
Christoph that code was written over 6-7 years ago, feel free to provide a
patch for it to use the sl
On Tue, 28 Aug 2007, Christoph Hellwig wrote:
On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote:
Hello,
As there are many places in drm code where drm_alloc + memset is used
this patch series introduces drm_zalloc and also makes use of drm_calloc where
needed. Most of t
Hi,
I've got an HP 2510p with a 965 mobile chipset and ICH8, lspci is at
http://people.freedesktop.org/~airlied/hp2510p/hp-lspci-vv.txt
Resume is failing on the hard disk resume by the looks of it (no video
to prove it..) but I've rmmod nearly everything and my network
interface comes back and I
2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
Signed-off-by: Scott Thompson hushmail.com>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 32ddef98f232585f20bc8
-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 22c806c23fe17f9c744d19edfe650cfd6496bc2a
Author: Simon Farnsworth <[EMAIL PROTECTED]>
Date: Mon Jul 23 18:32:01 2007 +1000
drm/via: Fix dmablit when blit queue is full
fd.o bug 11542
Acked-by: Thomas Hellstrom
Signed-of
On 8/24/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Could someone please explain why do we need block_all_signals() ?
>
> I can't understand what was the intended behaviour, but anyway
> I suspect it doesn't work as expected.
http://dri.sourceforge.net/doc/drm_low_level.html
Section 4.1 explai
> Blame intel ;)
>
> > Any other ideas and suggestions?
>
> Without knowing exactly what you are doing:
>
> - Copies to uncached memory are very expensive on an x86 processor
> (so it might be faster not to write and flush)
> - Its not clear from your description how intelligent your transfer
> sys
>
> Write-combining access seems the correct thing here, followed by a
> wmb(). Uncached writing would be horrendously slow.
>
> [snip]
> > So after all that I'd like to have some sort of uncached page list I
> > can allocate pages from
>
> This is exactly what Intel's PAT mechanism exists for - ju
Hi all,
I've started doing some work with using the new DRM memory manager
from TG for pixmaps in the X server using Intel 9xx series hardware.
The intel hardware pretty much requires pages to be uncached for the
GPU to access them. It can use cached memory for some operations but
it isn't very u
It would really be nice to actually see the patches that go along with this.
Otherwise you are not giving outside reviewers any chance at all to evaluate
these fixes.
Or were they posted on LKML, and I missed them?
In this case I think I picked up all of these patches from LKML by
searchin
On Fri, 27 Jul 2007, Dave Airlie wrote:
Hi Linus,
Please pull the 'agp-patches' branch from
git://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches
and of course I find the old version of my script..
that should be
ssh://master.kernel.org/pub/scm/linux/
/sgi-agp.c |1 -
6 files changed, 22 insertions(+), 18 deletions(-)
commit f191f144079b0083c6fa7d01a4acbd7263fb5032
Author: Alan Hourihane <[EMAIL PROTECTED]>
Date: Fri Jul 27 10:56:43 2007 +1000
agp: AMD AGP is used on UP1100 & UP1500 alpha boxen
Signed-off-by:
On Thu, Jul 26, 2007 at 07:26:53AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-07-25 at 13:19 +0200, Nick Piggin wrote:
> > Hi,
> >
> > Does this patch solve the X problem? Does anyone see anything wrong
> > with it or know why agp was locking the pages?
>
> We need to do a little bit of
Is this with a binary-only module? We saw an issue with that in SLES9
where the module is returning a locked page from its nopage handler
when it isn't really supposed to. It might be fixed in latest drivers,
have you tried them?
Doesn't sound like it he mentions radeon drm module which is open
DRM
Subject : wine locks up system
References : http://lkml.org/lkml/2007/7/17/128
Last known good : ?
Submitter : Charles Gagalac <[EMAIL PROTECTED]>
Caused-By : commit d4e2cbe9cb9219fc924191a6baa2369140cb5ea8
Dave Airlie <[EMAIL
they need to grow a userpsace
cmpxchg as davem mentioned to go along with this, changing the drm now
isn't possible due to backwards compat..
For reference purposes, that position is not acceptable. We _never_ accept the
"oh I can't change my proposed kernel interface because I already have
On 7/19/07, David Miller <[EMAIL PROTECTED]> wrote:
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 00:05:49 -0700
> What's that code doing anyway? driver-private locking primitives?
It's an atomic lock shared with userspace. Whatever implementation is
used to do the lock on th
arm:
drivers/char/drm/drm_lock.c: In function `drm_lock_take':
drivers/char/drm/drm_lock.c:221: error: implicit declaration of function
`cmpxchg'
You might be able to use atomic_cmpxchg, which _is_ present
on all architectures. Or use a spinlock.
What's that code doing anyway? driver-priv
On 7/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Thu, 19 Jul 2007 18:15:03 +1000 "Dave Airlie" <[EMAIL PROTECTED]> wrote:
> Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
That would certainly be better than adding a sprinkle of arc
On 7/17/07, charles gagalac <[EMAIL PROTECTED]> wrote:
starting an application under wine 0.9.41 locks up my system. bisect
generated the following commit:
commit d4e2cbe9cb9219fc924191a6baa2369140cb5ea8
Should be fixed now, I missed a patch chunk in that series..
Dave.
-
To unsubscribe fro
Please pull the 'drm-patches' branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
Could you re-pull?
There are two patches, one fixes a missed typedef for Sis and one adds the
idr_init that fell out of the drawable changeset.. which should fix any
h
I really think this or the previous tree is buggy.
I've got this to reproduce on my machine, this code came from DRM git and
has been okay in there for a few weeks, I'll do some digging it may be
something to do with the idr + context/drawable code..
Dave.
Trying to start any 3D client j
les changed, 93 insertions(+), 312 deletions(-)
commit d4e2cbe9cb9219fc924191a6baa2369140cb5ea8
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Tue Jul 17 10:55:47 2007 +1000
drm: convert drawable code to using idr
This converts the code for allocating drawables to the Linux idr,
Fixes
-)
commit ff4135aeb1f9a0201f8e22400ebc1d570df9016e
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Mon Jul 16 13:53:57 2007 +1000
drm: remove core typedefs from the ioc32 wrappers
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit bd63cb52c05bbb154f539369cae4fb9c9b6277
On 7/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Mon, 16 Jul 2007, Dave Airlie wrote:
>
> Please pull the 'drm-patches' branch from the drm git tree.
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> drm-patches
This totally
s/char/drm/via_verifier.h |6 +-
76 files changed, 2444 insertions(+), 2173 deletions(-)
commit bd63cb52c05bbb154f539369cae4fb9c9b6277da
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Thu Jul 12 10:35:02 2007 +1000
drm: remove sarea typedefs
Leave the userspace typedefs in p
Linus has decreed the evil of typedefs in the kernel, and the DRM is
the proud winner of the "HEY MA: I CAN USE TYPEDEF" award,
So I've cleaned up most of the typedefs in the Linux drm core (I did
this in the kernel tree as I'd like to push it there first and
backport it to the hell of the DRM gi
rt SiS based XGI chips to SiS DRM.
This adds support for some of the XGI Volari family that are based on the
SiS.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
---
drivers/char/drm/drm_pciids.h |2 ++
drivers/char/drm/sis_drv.h|8
2 files changed, 6 insertions(+), 4 deleti
Most of the tasklet uses are in rarely used or arcane drivers - in fact
none of my 10 test-boxes utilizes _any_ tasklet in any way that could
even get close to mattering to performance. In other words: i just
cannot test this, nor do i think that others will really test this. I.e.
if we dont appr
>
> The drm_locked_tasklet() function seems to have multiple bugs anyway,
> so getting rid of it can only help, and it avoids exporting a new
> tasklet_is_scheduled() interface.
That's exactly what I though when looking over this code. There's
some really crappy in code in that area, and it shou
>
> The thing is here, this is PCIE, so if there is a GPU plugged into the
> PCIE 16x slot in theory the main onboard graphics should disable, AGP
> code is used to control the GART for the onboard chip, in this case a
> plugged in card will not use AGP, I wonder have Intel tested with a
> pcie c
Right now, I'm at a loss to explain the corruption, so it's
difficult to suggest what to try.
The thing is here, this is PCIE, so if there is a GPU plugged into the
PCIE 16x slot in theory the main onboard graphics should disable, AGP
code is used to control the GART for the onboard chip, in th
On 6/14/07, Carlo Wood <[EMAIL PROTECTED]> wrote:
On Thu, Jun 14, 2007 at 11:17:50AM +1000, Dave Airlie wrote:
> How do you have a 965G in an amd64 box? does not compute.
Why not? It's the ASUS P5B Deluxe motherboard with an
Intel P965/ICH8R chipset. The cpu is a QX6700 2.66
On 6/14/07, Carlo Wood <[EMAIL PROTECTED]> wrote:
On Wed, Jun 13, 2007 at 12:29:25PM -0400, Dave Jones wrote:
> For the sake of AGP, we only use the on-CPU GART.
> The (nvidia) chipset one is ignored.
>
> If amd64-agp isn't working for you, attach your dmesg.
> (You can also confirm its working b
on_ioc32.c | 26 +++
5 files changed, 110 insertions(+), 18 deletions(-)
commit 9b01bd5b284bbf519b726b39f1352023cb5e9e69
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Sun Jun 10 16:00:27 2007 +1000
drm: fix radeon setparam on 32/64 bit systems.
The alignment on 64-bit is diff
On 6/10/07, John Richard Moser <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This has been an on-going issue for I don't know how long. I
reported it a while ago but it's still in 2.6.22.
Here's another error log. Loaded the Via driver in Xorg with kernel
2.6.22
On 5/30/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
Hi Linus,
Please pull the 'drm-patches' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
It contains a fix for a kmalloc 0, along with new pci ids for the radeon rs480
and a spinlock
On 5/31/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Thursday 31 May 2007 00:07:45 Dave Airlie wrote:
> Depending on split all lowmem is below 1GB which isn't exactly
> optimal, I'd llike all 4GB for DMA.
Well it would be for a quite specialized limited use case:
- Mem
Depending on split all lowmem is below 1GB which isn't exactly
optimal, I'd llike all 4GB for DMA.
Dave.
On 5/31/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Dave Airlie wrote:
> Just a question,
>
> So we have GFP_DMA32 on x86-64 to gives us memory below 4G? so we n
Just a question,
So we have GFP_DMA32 on x86-64 to gives us memory below 4G? so we not
have the same on PAE based x86 machines so I can use a consistent API
from the drm?
Otherwise it'll be stick some ifdefs in the drm to deal with it..
Dave.
-
To unsubscribe from this list: send the line "unsu
ions(-)
commit c4814f9001a8dd28e39311a919beac34f778f76d
Author: Michel D??nzer <[EMAIL PROTECTED]>
Date: Sat May 26 04:37:08 2007 +1000
drm: make sure the drawable code doesn't call malloc(0).
Signed-off-by: Michel D??nzer <[EMAIL PROTECTED]>
Signed-off-by: Dave Ai
On 5/22/07, Philipp Klaus Krause <[EMAIL PROTECTED]> wrote:
Benjamin Herrenschmidt schrieb:
>> In collaboration with the FB guys, we've been working on enhancing
>> the
>> kernel's graphics subsystem in an attempt to bring some sanity to the
>> Linux graphics world and avoid the situation we have
These are not isolated problems. Linux needs a properly designed
graphics subsystem. One way to achieve that is to design it all on
paper first so that we can try and locate the interactions between
modules. For example the current mode setting design is definitely
broken for multi-seat support, t
On 5/22/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
On 5/21/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Jon, that's why I'm posting this stuff in the first place! :) Again, if
> you have specific problems with the proposed interfaces (problems that
> would preclude your wishlist from being fully
> Did I say the X server? There are policy decisions that are root only
> also authorisation of processes to render etc..
Root only today, maybe, but this thread is talking about future
directions. Don't lock your design into a coarse-grained security model.
We can add a new capability bit bu
What I don't want is a permanent root priv process hanging around in
the system. It simply isn't needed and I have prototyped a system that
runs without root so I know it can be done. With minor mods DRI can
run without the need for root, with more major mods the X server can
run without the need
It is a quite sensible idea.
The userspace X server SHOULD be running under a non-root user, with
appropriate fine-grained privs granted to it.
"I need root to do graphics" is a myopic, antiquated view of the world.
Did I say the X server? There are policy decisions that are root only
also aut
On 5/21/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
On 5/21/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > You are describing a transition plan without knowing what the final
> > design is going to look like. We really need to hash out the final
> > design so
You are describing a transition plan without knowing what the final
design is going to look like. We really need to hash out the final
design so that the right path is taken to get there.
For example I didn't have per CRTC device nodes or user space consoles
in my original design, but after talk
On 5/21/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
On 5/21/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
> This just needs a userspace console again a parallel problem that
> really isn't much to do with the problem set this work is trying to
> solve... it should enable it..
1) Be upwards compatible with the existing fbdev drivers. This lets us
avoid rewriting the 90 existing drivers. New drivers shouldn't break
any old apps.
done.
2) Address the long outstanding issue of multi-seat at the console
level. My solution to this is the one device per CRTC model.
do
, holes: 10, sum holes: 45 */
/* bit holes: 2, sum bit holes: 62 bits */
/* padding: 8 */
/* last cacheline: 32 bytes */
Signed-off-by: Davi E. M. Arnaut <[EMAIL PROTECTED]>
Cc: Dave Airlie <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
No problems from
What about modifying the existing fbdev API? You could start with one
fbdev device per CRTC and then add a new IOCTL to control the output
device. I haven't seen anything yet that justifies abandoning the
existing fbdev API.
Then you can't aribtrate properly output hooking is a root level
thing
801 - 900 of 1069 matches
Mail list logo
