>
> All the good that's done us and our users. After more than *5 years* of
> various memory manager efforts we can't support basic OpenGL 1.0 (yes,
> 1.0) functionality in a performant manner (i.e., glCopyTexImage and
> friends). We have to get over this "it has to be perfect or it will
> neve
>
> For radeon the plan was to return error from superioctl as during
> superioctl and validation i do know if there is enough gart/vram to do
> the things. Then i think it's up to upper level to properly handle such
> failure from superioctl
You really want to work this out in advance, at sup
>
> 1) The ideal thing would be for the card contents to be quickly copied
> to backing-store and suspend is done.
> However, this requires pinning as much physical pages as there is VRAM.
>
> 2) The other approach is to have a backing object of some sort, either a
> list of swap-entries or per
>
> Spliting the cmd before they get submited is the way to go, likely we can
> ask the kernel for estimate of available memory and so userspace can stop
> building cmd stream but this isn't easy. Well anyway this would be a
> userspace problem. Anyway we still will have to fail in superioctl if
>
> So possibilities are:
> - batchbuffer starvation -- has
> - over-throttling in swapbuffers -- I think we used to let it get
> two frames ahead - has this changed?
I would suspect this broke somehow at some point..
Dave.
-
Hi,
So I've been growing more annoyed with the current layout of the drm
tree in the kernel,
a) it lives under char.
b) everything in one directory.
c) header files in one directory.
d) no header files exposed to userspace.
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdi
On Thu, May 29, 2008 at 2:23 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Thu, May 29, 2008 at 10:46:22AM +1000, Dave Airlie wrote:
>> Hi,
>>
>> So I've been growing more annoyed with the current layout of the drm
>> tree in the kernel,
>>
>&g
On Thu, May 29, 2008 at 9:02 PM, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-05-29 at 10:46 +1000, Dave Airlie wrote:
>> Hi,
>>
>> So I've been growing more annoyed with the current layout of the drm
>> tree in the kernel,
>>
>&g
> I can easily trigger an endless stream of the following three lines
>
> [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held,
> held 0 owner eb0908c0 eb0908c0
> [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
> held 0 owner eb0908c0 eb0908c0
> [drm:rade
>
> Backtrace:
> 0: X(xf86SigHandler+0x80) [0x80d29f0]
> 1: [0xb7f54400]
> 2: /usr/lib/xorg/modules/input//evdev_drv.so [0xb7aab90e]
> 3: X [0x80d2b87]
> 4: X [0x80b6065]
> 5: [0xb7f54400]
> 6: X(Dispatch+0x81) [0x808d5d1]
> 7: X(main+0x485) [0x8074bb5]
> 8: /lib/libc.so.6(__libc_start_main+0xdc)
Oops I thought I'd pushed it, but my repos were messed up..
I've pushed my current tree now..
Dave.
On Wed, 2008-06-04 at 09:50 +0800, Wu, Nian wrote:
> Hi, Jesse:
>
> When compiled intel driver branch intel-kernelmode, it failed with
> error info:
>
> gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W
>
> Hi Brian,
>
> It seems like people are mostly concerned about gallium stability
> right now. How stable wioll the interfaces be in the future ? Maybe if
> you could tell us, that'd help others jump in.
Even when it might make it to master, is it planned to land in master..
I would assume Me
>
> Gallium might ultimately wind up in its own repository as a stand-alone
> project. Afterall, Gallium drivers could be used by APIs other than OpenGL.
The question is mainly from a distro point of view what do we need to ship
a gallium driver. The current method would mean we need a Mesa t
> Dave,
>
> Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted
> the --enable-ttm-api flag in mesa now ??
I think it will have to not have DRI2 by default unless Kristian does
the decoupling from the mm interface.
Dave.
-
> Each of the following changes individually fixes the problem:
>
> 1) Do not overwrite the same region of the framebuffer in every iteration;
> instead, use a different framebuffer region for every iteration.
>
> 2) Add a sleep(1) before glReadPixels.
>
> 3) Add a sleep(1) after glReadPixels.
>
> Hmm, the radeon_cp_idle() should purge the destination cache (and wait
> for it too, including checking the DC_BUSY bit).
> At least the r200 driver has a comment in r200SpanRenderStart (including
> a dodgy workaround) which sure looks like the same issue to me.
We may purge the cache but no
> *GEARS* (Should be GPU bound)
> i915tex (TTM):1035fps @ 70% CPU
> GEM, no buffer reuse: 863fps @ 95% CPU
> GEM, buffer reuse: 1000fps @ 80% CPU
> Unichrome CX700 1009fps @ 70% CPU
So just to try and do some testing off my own, I can't get TTM code from
i91
>
> However so far I can't get glxgears on TTM to not flicker as do all my
> other apps. Am I missing something?
>
> Granted my gears numbers are better with TTM, but the flicker does leave
> me to think something broke.
Ah keithp pointed out single buffered rendering due to visual failure.
I
12:56 2008 +1000
drm/i915: add support for Intel series 4 chipsets.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 21efa2bac91b8d12064617c5a35492ec982544eb
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Thu J
oops fixed in the ioctl handler, fixed the oops but had a side effect
on some driver ioctls. Looks like I have to audit the driver ioctls by
hand.
So I've pushed the fix for that as well.
commit 858a3685bcf3ac199128e4aa85eaae2fb9d191b5
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Fr
gt;> This enforces us to use the drm ioctl types so read/write works
> >> correctly and not believe
> >> what userspace tells us.
> >>
> >> It does this hopefully without breaking the drm api.
> >>
> >> Fixes bug from thread:
> Is anyone working on cleaning up the drm code so that it works with
> the latest -mm sources. I sure would like to use r500 drm with an -mm
> kernel.
The upstream drm already contains r500 support so the -mm kernel should
have anything you need, you shouldn't need to build out-of-tree drm
aga
ar.gz
SHA1: 007903c738df3bc2a3cdab0289635baa95a2ed7a libdrm-2.3.1.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.3.1.tar.bz2
MD5: 620fe7dd02c3236c3e9881a3a238173d libdrm-2.3.1.tar.bz2
SHA1: 775dc69fcabb324552b0b9fe3a67eceb324be194 libdrm-2.3.1.tar.bz2
I'd include a real changelog but real
>
> You may consider this offtopic, but I wondering
> about status of graphical development.
Yes.
> And lastly, just for a thought, maybe it is better to do one thing at
> time, for example stabilize kernel modesetting, put it in kernel, then
> release gem driver and stabilize it, and then ad
So I've got a problem with the aperture space check if the cliprect mode
changes and blits flush the relocs and aperture spaces.
However in trying to fix, I've noticed we never set the
batch->cliprect_mode anywhere I can see except to IGNORE_CLIPRECTS in
intel_batchbuffer.h.
I'm going wtf.. b
On Fri, Jul 11, 2008 at 1:17 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Thursday, July 10, 2008 3:59 pm Tiago Vignatti wrote:
>> Simon Thum escreveu:
>> > But all this in the kernel is an impedance mismatch to me. What could it
>> > buy us we don't have today?
>>
>> Improve heavy-load behavio
lude}/drm/drm_memory_debug.h (100%)
rename {drivers/char => include}/drm/drm_os_linux.h (100%)
rename {drivers/char => include}/drm/drm_pciids.h (100%)
rename {drivers/char => include}/drm/drm_sarea.h (100%)
rename {drivers/char => include}/drm/drm_sman.h (100%)
rename {drivers/char =
> >
> > Please pull the 'drm-reorg' branch from
> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> > drm-reorg
> >
> > This contains a moving around of a lot of the DRM into a more Linux like
> > tree and makes it a lot nicer going forward for merging new features.
>
>
rs/gpu/drm/radeon/radeon_cp.c |2 +-
include/drm/drmP.h |1 +
3 files changed, 7 insertions(+), 1 deletions(-)
commit 242e3df80b8d25ed681c278512df0993725f25dd
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Tue Jul 15 15:48:05 2008 +1000
drm/radeon: fixup issue
> Hi David,
>
> it affects stable (2.6.26) too?
yes I've already sent a patch to stable maintainers.
Dave.
>
> On 7/15/08, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > Hi Linus,
> >
> > Please pull the 'drm-fixes' branch from
>
> After seeing that i830_drm.h was just added as a userspace header
> I wondered whether there's really a non-empty intersection of
> kernel >= 2.6.27 users and users of such an ancient X.
>
> I doubt it, and therefore suggest this patch to remove the driver.
NAK I'm generally against removing o
On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> drm_lock_take(); and drm_lock_free(); are called from
> drm_locked_tasklet_func(); which disables interrupts when grabbing its
> spinlock.
>
> Don't allow these locking functions to re-enable interrupts when
> the tasklet expe
> I've started to see "hangs" with X on an ATI RS690 with a 2.6.26 kernel.
> The symptoms are that load average goes up, X stops accepting keypresses
> or mouse clicks, but the cursor still moves around the screen in
> response to the mouse being moved. I can't switch to a VT but can ssh in
> remo
On Tue, Jul 29, 2008 at 5:31 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 28 Jul 2008 22:32:45 +0200 Thomas Hellstr__m <[EMAIL PROTECTED]>
> wrote:
>
>> Dave Airlie wrote:
>> > On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby <[EMAIL PROTECTED]&
> > What do you think?
>
> We try to keep #ifdef's out of the code and in drm_compat.h instead.
> Something like
>
> #if linuxversion >= 2.6.27
> #define drm_on_each_cpu(handler, data, wait) ...
> #else
> ...
> #endif
>
> and then just user drm_on_each_cpu in the code.
>
I'd prefer n
> > Wow, there are a lot ifdefs in the code.
> Exactly what I was thinking when I saw the patch. ;) But I was too lazy to
> think for a solution. Thanks for doing that for me. :)
> Here comes the result.
>
Thanks for looking at this, but I dislike both of these ideas, I'll just
move the old no
>
> Well, if the overhead of merging upstream is a concern, then how about
> not worrying about bc at all and let people who want to back port deal
> with it? Oh, and what about just keeping the drm drivers in a linux
> kernel tree? That'll make upstream merging even easier yet...
The less cra
> >
> > Personally, I only use the existing DRM repo on old kernels because that's
> > how
> > it's structured. It's actually more work for me to download & build a
> > recent
> > kernel, then update & build the DRM drivers against it that it is to simply
> > update the DRM drivers and build aga
>
> Managing a fake linear address space just to match some existing
> arbitrary API requirements is insane. Creating the right interface for
> my UMA environment is my goal. I'm not sure precisely what that API
> should be, but at least this one is obviously wrong.
Isn't that also what you are t
>
> Yes, with a 1-1 mapping between GPU objects and file objects. You can
> use the normal read/write/mmap API on them. The reason we aren't using
> fds now is just that the kernel cannot handle this many fds per process.
Well it can now, we just need to fix the X server :)
>
> I want to map t
> >
> > Then this, the thing is to keep it building you need compat code, code
> > that can't go into Linus tree, so we end up with a tree that isn't like
> > Linus tree, and we still have to patch manage transitions so we don't save
> > anything doing this over what we have now.
>
> I was thinki
On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 9, 2008 at 7:28 PM, Dave Airlie <[EMAIL PROTECTED]> wrote:
>> On Wed, Aug 6, 2008 at 2:23 AM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
>>> On Tue, Aug 5, 2008 at
_SIS=y is not a legal configuration.
Reported-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 8ba0be53102f8d8509ee2958d15142bdd2fd433f
Author: Dave Airlie <[EMAIL PROTECTE
> Quite frankly, I'm not going to take this.
>
> None of what you describe sounds like regressions, and this is just TOO
> F*CKING LATE to take big changes like this, to a fragile subsystem that
> has historically easily introduced new regressions.
>
> Can you please make a branch with ONLY RE
/gpu/drm/radeon/radeon_cp.c | 38 +++
drivers/gpu/drm/radeon/radeon_drv.h | 19 ++--
6 files changed, 225 insertions(+), 86 deletions(-)
commit 3e5fc80a404a24c858468030b63555cccfb3e79c
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Sun Aug 24 17:02:26 2008 +1000
drm: don't set
> >
> > Your reply now serves as place to point people at when they ask why Red
> > Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine
> > with that.
>
> 6 months sounds too long, there's at least one merge window in such a
> time-frame.
Not every distro rebases their k
Hi Thomas,
I've made some changes you might be interested in on the
modesetting-gem branch of the main repo.
1. removed all the TTM interfaces and ioctls from the kernel API.
2. removed drm_bo_lock.c (we need to discuss what we want that for)
3. built a radeon GEM interface on top of the TTM inte
On Wed, Aug 27, 2008 at 5:23 AM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Jesse Barnes wrote:
>> The DRM design includes ioctls to allow a userland driver to tell the kernel
>> driver when to register its interrupt handler and on what IRQ. This is a
>> really bad idea for several reasons, and
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess
and I've pasted it in below this for discussion.
some other points:
a) People are pushing for a process change, we will have something
change, however this isn't a who shouts loudest competition, so more
than likely yo
On Wed, Aug 27, 2008 at 11:35 AM, Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 06:20:43PM -0700, Dave Airlie wrote:
>> linux-core/radeon_encoders.c | 15 +++
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
>> Okay I've put some thoughts up at:
>> http://dri.freedesktop.org/wiki/DRMProcess
>>
>> and I've pasted it in below t
On Wed, Aug 27, 2008 at 11:45 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Aug 2008 18:02:24 +1000
> "Dave Airlie" <[EMAIL PROTECTED]> wrote:
>
>> 4. added clean flag for buffers that get migrated to VRAM immediately.
>>- with pixmaps w
v is the problem. But 2.6.25 was fine with it. Then I tried the
> 2.6.27 kernels in koji.fedoraproject.org. They had the same problem.
>
> I saw that the thing in common between the 2.6.26 and the 2.6.27 is
> that Dave Airlie added drm-patches and fixes in the fedora kernels.
> Wi
On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Dave,
>
> This process looks ok to me,
> but I think some clarifications are needed:
>
> Dave Airlie wrote:
>>
>> Okay I've put some thoughts up at:
>> http://dri.freedeskt
On Thu, Aug 28, 2008 at 9:32 PM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
>>
>> On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Dave,
>>>
>>> This process l
On Tue, Aug 26, 2008 at 9:04 PM, roel kluin <[EMAIL PROTECTED]> wrote:
> In drivers/char/drm/drm_sysfs.c:187, function drm_sysfs_device_add():
>
> for (i = 0; i < ARRAY_SIZE(device_attrs); i++) {
>err = device_create_file(&minor->kdev, &device_attrs[i]);
>if (err)
>g
2008/9/4 Jesse Barnes <[EMAIL PROTECTED]>:
> On Wednesday, September 03, 2008 6:11 am Stefano Avallone wrote:
>> On Wednesday 03 September 2008 13:36:21 Maksym Veremeyenko wrote:
>> > Jesse Barnes написав(ла):
>> > [...]
>> >
>> > >> I am very interesting in getting drmWaitVBlank works on 945GME...
> > > > Sep 6 10:24:31 poppero1 kernel: [ 186.138774] [drm:radeon_cp_start]
> > > > *ERROR* radeon_cp_start called without lock held, held 0 owner
> > > > f726bc80 f68f6840
> > > > Sep 6 10:24:31 poppero1 kernel: [ 186.138968] [drm:radeon_cp_idle]
> > > > *ERROR* radeon_cp_idle called with
On Wed, Sep 10, 2008 at 8:03 PM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
>>
>> Hi Thomas,
>>
>> I've made some changes you might be interested in on the
>> modesetting-gem branch of the main repo.
>>
>> 1. removed all
On Fri, Sep 26, 2008 at 1:39 AM, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Keith Packard wrote:
>>
>> On Thu, 2008-09-25 at 00:19 -0700, Thomas Hellström wrote:
>>
>>>
>>> If data is
>>> dirtied in VRAM or the page(s) got discarded
>>> we need new pages and to set up a copy operation.
>>>
>>
On Fri, Oct 17, 2008 at 9:38 AM, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> Hi Linus,
>
> Please pull the 'drm-next' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
>
> This contains two patches outside the DRM t
rivers/gpu/drm/i915/i915_suspend.c
commit 9d512dc0c924f3c75e8d8446c32b4ef77fe15913
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Fri Oct 17 09:29:14 2008 +1000
drm: make CONFIG_DRM depend on CONFIG_SHMEM.
This can be removed later when DRM doesn't depend on shmem.
. We haven't tried to write actual exploit code though.
It only affects the Intel G33 series and newer.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 9e0b97e37fddaf5419d8af24362015ab684eff7e
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Fri Oct 17 09:29:1
2008/10/18 Linus Torvalds <[EMAIL PROTECTED]>:
>
>
> On Fri, 17 Oct 2008, Dave Airlie wrote:
>>
>> Please pull the 'drm-next' branch from
>> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
>
> Grr.
>
> Thi
-by: Eric Anholt <[EMAIL PROTECTED]>
Acked-by: Michel Dänzer <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 49568873705e45a0de77b7824a9a46d3201019a7
Author: Eric Anholt <[EMAIL PROTECTED]>
Date: Tue Oct 21 11:38:50 2008 -070
isplays. Originally based on the X.Org Randr 1.2
>> > implementation, the code has since been heavily changed by Dave Airlie
>> > with contributions by Jesse Barnes, Jakob Bornecrantz and others.
>> >
>> > This one should probably be split up a bit; I think
> We must split out TTM from anything that goes into DRM next for now, as
> we're about to re-add it in a device dependant
> form with a well defined kernel only API. (This is probably going to
> happen within a couple of weeks).
>
> A minimal user-space API will be added when there are drivers
le aperture size.
This will let userland know when to submit its batchbuffers, before they get
too big to fit in the aperture.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 4e270e9b8a9d246290f3901f1fb6c5efd
> Andrew please apply, if no comments or a better patch from drm
> fellows comes.
>
> As the accesses to the mmio member are not protected by anything, they
> seem to be racy with the open/clsoe anyways, setting this down there
> too.
We got a patch last week from Jesse Barnes to fix this, I'll
it to
index 0x21, and make sure everyone uses the defined value instead of
hard-coded constants.
Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit afa21e0584f78964c092981fad94e45d38cda249
Author: Dave Airlie <[EMA
On Tue, Nov 11, 2008 at 6:29 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Tue, 11 Nov 2008 08:15:26 +0000 (GMT) Dave Airlie <[EMAIL PROTECTED]>
> wrote:
>
>> commit 78538bf14995a136c2d9a22159ada49937359119
>> Author: Dave Airlie <[EMAIL PROTECTED]>
&g
this register across suspend/resume.
Signed-off-by: Peng Li <[EMAIL PROTECTED]>
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 52440211dcdc52c0b757f8b34d122e11b12cdd50
Author: Keith Packard <[EMAIL PROTECTE
id BUG_ONs on VT switch" commit.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
-
This SF.Net email is sponsored by the Moblin Your Move Dev
On Thu, Dec 18, 2008 at 8:08 AM, Eric Anholt wrote:
> The values are really going to continue meaning pipe, not plane, and that's
> what they're called in the kernel copy of the header. Userland hasn't ever
> made the switch to pipe!=plane, since userland checks are based on DRM
> version, which
rs/gpu/drm/i915/i915_dma.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem.c |9 -
3 files changed, 19 insertions(+), 2 deletions(-)
commit ac5c4e76180a74c7f922f6fa71ace0cef45fa433
Author: Dave Airlie
Date: Fri Dec 19 15:38:34 2008 +1000
On Sat, Dec 20, 2008 at 3:10 AM, Julia Lawall wrote:
> From: Julia Lawall
>
> If the NULL test is necessary, then the dereference should be moved below
> the NULL test.
>
> The semantic patch that makes this change is as follows:
> (http://www.emn.fr/x-info/coccinelle/). The result has been modi
On Sat, Dec 20, 2008 at 9:19 AM, Eric Anholt wrote:
> On Tue, 2008-12-09 at 14:00 -0500, Ben Gamari wrote:
>> Hey everyone,
>>
>> This is the latest version of my procfs file handling patch. I have
>> ported the old proc files to use the seq_file interface greatly
>> simplifying the code. I have a
>
> Is available at
> http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commit;h=3a911a216742e4ab998f3281409d46a62f252716
>
>
> Please let me know, should I need to resend this patch for :
> 1. git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> OR
> 2. git kernel.org:/pub/
deletions(-)
commit 077ebed54fe66612f58b076628a72eca2be8df90
Author: Dave Airlie
Date: Mon Dec 22 17:11:02 2008 +1000
drm/radeon: fix correctness of irq_enabled check for radeon.
This check was introduced with the logic the wrong way around.
Fixes regres
On Wed, Dec 24, 2008 at 5:11 PM, wrote:
> To whom it may concern:
>This patch contains the modification on the header files for the VIA
> Chrome9 DRM kernel module based on kernel 2.6.28-RC9. The header files
> include:
> 1. via_chrome9_3d_reg.h
> 2. via_chrome9_dma.h
> 3. via_chrome9_drv.h
el_tv.c
create mode 100644 include/drm/drm_crtc.h
create mode 100644 include/drm/drm_crtc_helper.h
create mode 100644 include/drm/drm_edid.h
create mode 100644 include/drm/drm_mode.h
commit aa5966296675a5092505f68d72563d5939a92353
Author: Dave Airlie
Date: Mon Dec 29 16:35:02 2008 +1000
d
From: Dave Airlie
The gem gtt mapping code didn't use the drm_vm.c accounting open/close,
it did call the initial drm_vm_open_locked, so it should always do this.
I'm not 100% sure it doesn't need a special open/close pair, but this at
least makes /proc/dri/0/vma not end up wi
On Sat, Jan 3, 2009 at 11:44 AM, Eric Anholt wrote:
> On Mon, 2008-12-29 at 09:08 +0000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> The gem gtt mapping code didn't use the drm_vm.c accounting open/close,
>> it did call the initial drm_vm_open_locked, so it shou
2137d7591e
Author: Dave Airlie
Date: Wed Jan 7 11:54:57 2009 +1000
drm: fix ordering of driver unload vs agp unload.
For KMS drivers, we really need to cleanup the driver before disabling
the AGP subsystem.
Signed-off-by: Dave Airli
On Mon, Jan 5, 2009 at 5:19 AM, Gabriel C wrote:
> Dave Airlie wrote:
>
> Hi Dave ,
>
> ...
>
>
>
>> Please pull the 'drm-next' branch from
>> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
>>
>> Major high
gging into GDM the X server hangs before launching the
>> > desktop (it appears to be trying to run glxinfo) on my Thinkpad T61
>> > (i915 graphics). Bisection shows this happens after applying this
>> > commit:
>> >
>>
On Sat, Jan 10, 2009 at 7:58 PM, Richard Purdie wrote:
>
> On Sat, 2009-01-10 at 12:04 +1000, Dave Airlie wrote:
>> On Sat, Jan 10, 2009 at 11:13 AM, Richard Purdie
>> wrote:
>> > On Fri, 2009-01-09 at 18:03 +, Richard Purdie wrote:
>> >> On Fri, 20
On Sun, Jan 11, 2009 at 9:19 PM, Ralf Baechle wrote:
> On Sat, Jan 10, 2009 at 07:16:22PM +0100, Martin Michlmayr wrote:
>
>> Your patch "drm: Add GEM ("graphics execution manager") to i915
>> driver" [1] broke compilation on MIPS because agp.h doesn't exist.
>>
>> CALLscripts/checksyscalls.
|7 ++
include/drm/drm_crtc.h |2 +-
include/drm/drm_crtc_helper.h|2 +-
10 files changed, 406 insertions(+), 69 deletions(-)
commit 34b8686e12eaf9878aaab89e9060c3e7cc48
Author: Dave Airlie
Date: Thu Jan 15 14:03:07 2009 +1000
drm/i915: lock cor
der the do-we-have-AGP ifdef
This fixes the MIPS with DRM build.
Signed-off-by: Eric Anholt
Tested-by: Martin Michlmayr
Signed-off-by: Dave Airlie
commit 4942f8b23b56a3f9a713d4436338710579329ffc
Author: Jesse Barnes
Date: Thu Jan 22 22:23:53 2009 +1000
drm: d
> Dave,
>
> given that agpmem->memory->memory[] gets always populated using
> virt_to_gart(), shouldn't the arguments to __va() here accordingly be
> passed through gart_to_phys() (and then it would probably be simpler
> to not go through a va at all, but rather convert the pa directly to a
> str
On Tue, Jan 27, 2009 at 4:23 AM, Linus Torvalds
wrote:
>
>
> Dave,
> you have some odd and slightly git usage model, which shows up in various
> commits. Lookie here as an example from comit 335041ed:
>
>Author: Jesse Barnes 2009-01-22 04:22:06
> Committe
> Schedule a vblank signal, kill the process, and we'll go walking over freed
> memory. Given that no open-source userland exists using this, nor have I
> ever heard of a consumer, just let this code die.
>
> Signed-off-by: Eric Anholt
I'm quite happy to push this, if nobody objects with a goo
> Hi,
>
> I hope to have addressed this email to the right people.
Does the attached patch help?
Dave.
>
> Since around kernel v2.6.29-rc1 (after
> bb26c6c29b7cc9f39e491b074b09f3c284738d36
> to be exact) I haven't had working 3D acceleration on my HP nx9005.
> First due to (since fixed):
>
>
On Wed, 28 Jan 2009, Shunichi Fuji wrote:
> oh I filled bugzilla.kernel.org right now ...
>
> On Wed, 28 Jan 2009 09:31:32 + (GMT)
> Dave Airlie wrote:
> > Does the attached patch help?
>
> I also think so once,
> but it will be bad with cant_use_aperture
On Fri, Jan 30, 2009 at 10:30 AM, Andrew Morton
wrote:
> (cc's added)
>
> On Wed, 21 Jan 2009 13:27:48 +0100
> Sami Kerola wrote:
>
>> I compiled the Torvalds git kernel 2.6.29-rc2-00013 and I got an oops.
>> The oops happens when ever X starts. Initially I was booting with run
>> level 5 and it
On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton
wrote:
> On Fri, 30 Jan 2009 11:06:47 +1000 Dave Airlie wrote:
>
>> On Fri, Jan 30, 2009 at 10:30 AM, Andrew Morton
>> wrote:
>> > (cc's added)
>> >
>> > On Wed, 21 Jan 2009 13:27:48 +0100
On Mon, Feb 2, 2009 at 3:55 PM, Benjamin Herrenschmidt
wrote:
> The DRM uses its own wrappers to obtain resources from PCI devices,
> which currently convert the resource_size_t into an unsigned long.
>
> This is broken on 32-bit platforms with >32-bit physical address
> space.
>
> This fixes them
On Tue, Feb 3, 2009 at 7:21 AM, Benjamin Herrenschmidt
wrote:
>
>>
>> Could this comment instead be maybe:
>>
>> Because the kernel-userspace ABI is fixed at a 32-bit offset, while PCI
>> resources may live above that, we ignore the map offset for maps of type
>> _DRM_FRAMEBUFFER or _DRM_REGISTERS
On Mon, Jan 5, 2009 at 7:55 AM, Kristian Høgsberg wrote:
> Under kernel modesetting, we manage the device at all times, regardless
> of VT switching and X servers, so the only decent thing to do is to
> claim the PCI device. In that case, we call the suspend/resume hooks
> directly from the pci d
901 - 1000 of 1512 matches
Mail list logo
