From: Dave Airlie airl...@redhat.com
This implements the busy ioctl along with a current domain check.
returns 0 or -EBUSY
puts the current domain no matter what the answer.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon
From: Dave Airlie airl...@redhat.com
This implements the busy ioctl along with a current domain check.
returns 0 or -EBUSY
puts the current domain no matter what the answer.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon
From: Dave Airlie airl...@redhat.com
If userspace destroys a framebuffer that is in use on a crtc,
don't just null it out, tear down the crtc properly so the
hw gets turned off.
also remove unused drm_crtc_from_fb function
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm
From: Dave Airlie airl...@redhat.com
These are needed for Occulsion Query support.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r300.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu
On Sat, Aug 15, 2009 at 3:45 AM, Jesse Barnesjesse.bar...@intel.com wrote:
On Fri, 14 Aug 2009 10:38:31 -0700
Anssi Hannula anssi.hann...@iki.fi wrote:
Currently detailed timings are ignored on EDID 1.3 with the comment
EDID up to and including 1.2 may put monitor info here. However, the
compare to the X server.
Dave.
From ebb177d2afb8532a8a316489aed545ed0c170802 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Sat, 15 Aug 2009 12:25:08 +1000
Subject: [PATCH] drm/edid: fixup detailed timings like the X server.
this syncs the versioning check with the code
.
Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei
Tel: +886-2-22185452 Ext 7323
Mobile: +886-968343824
Fax: +886-2-22186282
Skype: Bruce.C.Chang
Email: brucech...@via.com.tw
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Friday, July 17, 2009 5:09 PM
From: Dave Airlie airl...@redhat.com
this patch has two components:
a) for legacy DRM drivers, we need a hook to enable/disable irqs around
arb when the command/memory is turned off.
b) for KMS drivers we provide a hook/callback to enable/disable VGA decoding.
We don't disable VGA decoding
of these resources. This document
introduces the operation of the VGA arbiter implemented for Linux kernel.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/Makefile |2 +-
drivers/gpu/vga/Kconfig | 10 +
drivers/gpu/vga/Makefile |1
On Sat, Aug 8, 2009 at 7:51 AM, Jerome Glissegli...@freedesktop.org wrote:
Investigating where time is spent in radeon/kms world when doing
rendering leaded me to question the design of CS ioctl. As i am among
the people behind it, i think i should give some historical background
on the choice
these errors are pretty pointless
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Dave Airlie airl...@redhat.com
commit 8d3457ec3198a569dd14dc9e3ae8b6163bcaa0b5
Author: Paul Rolland r...@as2917.net
Date: Sun Aug 9 12:24:01 2009 +1000
drm: silence pointless vblank
From: Dave Airlie airl...@linux.ie
we should align the GTT after VRAM no matter what, as we can
come back from resume and put in a different place and bad things happen.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_device.c |4 +++-
1 files changed, 3
to how the bo driver and GTT memory
type was initialized.
Signed-off-by: Jerome Glisse jgli...@redhat.com
Signed-off-by: Dave Airlie airl...@redhat.com
commit 6502fbfaf81b09b3f474bb7b3796257e9450273e
Author: Alex Deucher alexdeuc...@gmail.com
Date: Tue Aug 4 11:24:24 2009 -0400
These are new AMD IGP chips
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial
(indirectly) a number of
AGP drivers, since:
commit 07613ba2f464f59949266f4337b75b91eb610795
Author: Dave Airlie airl...@redhat.com
Date: Fri Jun 12 14:11:41 2009 +1000
agp: switch AGP to use page array instead of unsigned long array
I dont see how it can end up with highmem pages
From: Dave Airlie airl...@redhat.com
The driver gets the bridge device in a number of places, upcoming
vga arb code paths need the bridge device, however they need it in
under a lock, and the pci lookup can allocate memory. So clean
this code up before then and get the bridge once for the driver
On Mon, 2009-07-20 at 13:48 +0800, yakui.z...@intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
We will have to add a prefix when using the macro defintion of DRM_DEBUG_KMS
/DRM_DEBUG_DRIVER/MODE. It is not convenient. We should use the DRM_NAME
as default prefix.
So remove the prefix
I'm sending an updated patch series adding a set_config method to
drm_encoder_slave_funcs to allow dynamically changing the encoder
specific DVO port parameters (the previous API enforced them to remain
the same until the end of its life).
so I'm not a 100% sure what to do with these yet.
On Sun, Aug 2, 2009 at 12:48 AM, Jerome Glissegli...@freedesktop.org wrote:
I am working on improving 2D performances in KMS world and
i am starting to think that we don't need the split btw
read/write domain but only need one domain. My thinking is
that there is no way for the kernel to
encountered this problem myself, was able to regain access only via
remote login, then saw tons of (ratelimited)
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held
0 owner dc6513c0
dc6513c0
[drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held,
Author: Dave Airlie airl...@redhat.com
Date: Wed Jul 29 17:07:38 2009 +1000
drm/radeon: set fb aperture sizes for framebuffer handoff.
This will allow efi/vesa to handoff to radeon.
Signed-off-by: Dave Airlie airl...@redhat.com
commit
2009/7/28 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Just use the fb_mmap hook. KMS will pin when necessary. This way we aren't
wasting precious VRAM when we're e.g. in X.
This means fbdev userspace will only be able to map the framebuffer via
/dev/fb*, not via
From: Dave Airlie airl...@redhat.com
If an rn50/r100/m6/m7 GPU has 64MB RAM, i.e. 8/16/32, the
aperture used to calculate the MC_FB_LOCATION needs to be worked
out from the CONFIG_APER_SIZE register, and not the actual vram size.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu
I'm getting a kernel panic when trying to run the latest git version
of drm. I built it following the instructions from here:
http://dri.freedesktop.org/wiki/Building
It's a very very predictable panic. Log in, 'startx', exit X11, and
then after a couple seconds, panic.
I unfortunately
2009/7/21 Peter Zijlstra pet...@infradead.org:
On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote:
Politics:
It's true that sometimes some people don't like the code or what it
does. But when this is the underlying cause of NAK-ing a driver I think
it's very important that this is
2009/7/21 Stephane Marchesin marche...@icps.u-strasbg.fr:
2009/7/20 Thomas Hellström tho...@shipmail.org:
Stephane,
Some comments on how these things has been handled / could be handled.
I would like to raise a couple of real-life issues I have in mind:
* First example, let's say VIA gets
1. via_chrome9_3d_reg.h
2. via_chrome9_dma.h
3. via_chrome9_drm.h
4. via_chrome9_drv.h
5. via_chrome9_mm.h
6. via_chrome9_verifier.h
Is it possible to run a 64-bit Linux on a chrome9 chipset onnected to
a 64-bit processor? if so you'll have to fix a lot of these ioctls up.
+
+struct
On Fri, Jul 17, 2009 at 4:36 PM, brucech...@via.com.tw wrote:
To whom it may ceoncern:
The following 3 patches are the DRM kernel module that support VIA Chorme9
GFX chipset. They are based on 2.6.31-rc3. Please kindly help to integrate
into kernel.
Is there a userspace, or available
On Fri, Jul 17, 2009 at 9:37 PM, Harald Welteharaldwe...@viatech.com wrote:
On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
On Fri, Jul 17, 2009 at 4:36 PM, brucech...@via.com.tw wrote:
To whom it may ceoncern:
The following 3 patches are the DRM kernel module that support
.
Currently each pool (wc, uc) is 256 pages big, improvement would be
to tweak this according to memory pressure so we can give back memory
to system.
Signed-off-by: Dave Airlie airl...@redhat.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/Makefile |2
Signed-off-by: Julia Lawall ju...@diku.dk
Signed-off-by: Dave Airlie airl...@linux.ie
commit ba0ab82358a12e7a7f2872d6b65c437157c6888f
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Jul 3 11:24:46 2009 -0700
fb/intelfb: conflict with DRM_I915 and hide by default
From: Dave Airlie airl...@linux.ie
Doing this like the DDX seems like the most sure fire way to avoid
having to reinvent it slowly and painfully. At the moment we keep
getting things wrong with aper vs vram, so we know the DDX does it right.
booted on PCI r100, PCIE rv370, IGP rs400.
Signed-off
2009/6/30 Thomas Hellström tho...@shipmail.org:
Jerome Glisse skrev:
On Fri, 2009-06-26 at 10:00 +1000, Dave Airlie wrote:
On Thu, Jun 25, 2009 at 10:01 PM, Jerome Glissegli...@freedesktop.org
wrote:
Hi,
Thomas i attach a reworked page pool allocator based on Dave works,
this one
From: Dave Airlie airl...@linux.ie
This add support for using dma32 memory on gpus that really need it.
Currently IGPs are left without DMA32 but we might need to change
that unless we can fix rs690.
(we had started doing this as part of the allocator code but I need it
sooner than
fix the following 'make includecheck' warning:
include/drm/drm_memory.h: linux/vmalloc.h is included more than once.
Signed-off-by: Jaswinder Singh Rajput jaswinderraj...@gmail.com
Acked-by: Dave Airlie airl...@redhat.com
Dave.
---
include/drm/drm_memory.h |2 --
1 files
From: Dave Airlie airl...@redhat.com
The crtc and cursor offsets on the legacy chips are offset from
DISPLAY_BASE_ADDR. The code worked if display base addr was at 0,
but otherwise falls to pieces.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_cursor.c
From: Dave Airlie airl...@redhat.com
Normally we are free to place VRAM where we want in the GPUs
memory address space, however on IGP chips the VRAM is actual RAM,
and no special translation or aperture is used inside the GPU MC.
So when you move the VRAM aperture away from the TOM register
From: Dave Airlie airl...@redhat.com
This adds new set/get tiling interfaces where the pitch
and macro/micro tiling enables can be set. Along with
a flag to decide if this object should have a surface when mapped.
The only thing we need to allocate with a mapped surface should be
the frontbuffer
2009/6/29 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-06-29 at 11:21 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
Userspace sends us a special relocation type to sync video/exa
to vlines to avoid tearing, this deals with the relocation
in the kernel, it picks the correct
From: Dave Airlie airl...@redhat.com
This undoes some stupid from earlier, wbinvd *does* need ipi,
clflush doesn't.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_cache.c | 18 +++-
drivers/gpu/drm/ttm/ttm_tt.c | 61
From: Dave Airlie airl...@redhat.com
Unsigned long is incorrect for 64-bit resources on 32-bit hw.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b
From: Dave Airlie airl...@redhat.com
Userspace sends us a special relocation type to sync video/exa
to vlines to avoid tearing, this deals with the relocation
in the kernel, it picks the correct crtc and avoids issues
where crtcs are disabled.
This version also parses the wait until to make sure
pass highmem pages to the PAT code and it will
do the right thing with them.
Signed-off-by: Dave Airlie airl...@redhat.com
--
--
___
Dri-devel mailing list
Dri-devel
I think it's better to fix userspace to not allocate as much buffer per
frame as it does now rather than having a pool of wb pages, i removed
it because on my 64M box memory is getting tight, we need to compute
the number of page we still based on memory. Also i think it's ok
to assume that
From: Dave Airlie airl...@redhat.com
Userspace sends us a special relocation type to sync video/exa
to vlines to avoid tearing, this deals with the relocation
in the kernel, it picks the correct crtc and avoids issues
where crtcs are disabled.
Signed-off-by: Dave Airlie airl...@redhat.com
On Thu, Jun 25, 2009 at 10:01 PM, Jerome Glissegli...@freedesktop.org wrote:
Hi,
Thomas i attach a reworked page pool allocator based on Dave works,
this one should be ok with ttm cache status tracking. It definitely
helps on AGP system, now the bottleneck is in mesa vertex's dma
allocation.
weiyi.hu...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
commit 5b6345be1b41db5e70f90c3559c3b40c8abcde8b
Merge: 176f613... b5aa8a0...
Author: Dave Airlie airl...@linux.ie
Date: Wed Jun 24 16:20:19 2009 +1000
Merge remote branch 'origin/drm-intel-next' of ../drm-intel into drm-fixes
On Tue, Jun 23, 2009 at 9:35 PM, Peter Zijlstrapet...@infradead.org wrote:
On Mon, 2009-06-22 at 19:26 +0200, Jerome Glisse wrote:
We don't need to allocated contiguous pages in cs codepath
so use vmalloc instead.
Best would be to not require PAGE_SIZE allocations at all of course.
It gets
From: Dave Airlie airl...@redhat.com
This adds color tiling support for buffers in VRAM, it enables
a color tiled fbcon and a color tiled X frontbuffer.
It changes the API:
adds two new parameters to the object creation API (is this better than
a set/get tiling?) we probably still need a get
There is a ttm_fbdev_mmap() function in TTM that may help in this situation.
As with the standard ttm mmap it's using fault() which means it's possible to
move out the backing buffer object if you first reserve it and then call
unmap_mapping_range() on the relevant fbdev address space to
Date: Thu Jun 11 16:16:10 2009 +1000
radeon: remove _DRM_DRIVER from the preadded sarea map
This shouldn't be there and is what broke r600 late in the 2.6.30
release cycle with Ben's patch.
Signed-off-by: Dave Airlie airl...@redhat.com
Hi,
I
On Sun, 21 Jun 2009, Andrew Lutomirski wrote:
Anyway, here's a totally UNTESTED patch that hopefully gives a warning on
where exactly we set the invalid bits. Andy, mind trying it out? You
should get the warnign much earlier, and it should have a much more useful
back-trace.
On Sun, 21 Jun 2009, Dave Airlie wrote:
I tried this tree (specifically, a merge of Linus' fb20871 this tree) on
Fedora 11 with modesetting enabled on an integrated Radeon 2100, and
plymouthd
crashes immediately with a corrupt page table. Photo attached. After the
crash
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-linus
This is the same tree from the previous pull request + the fix from Pierre
that actually makes the PAE/GEM combination on i965 work. \o/
Something from this
I tried this tree (specifically, a merge of Linus' fb20871 this tree) on
Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd
crashes immediately with a corrupt page table. Photo attached. After the
crash, bootup stops, although ctrl-alt-del works.
You need a
to be stuffed in the unused lower bits of the
page address are lost.
Signed-off-by: Pierre Willenbrock pie...@pirsoft.de
Signed-off-by: Dave Airlie airl...@redhat.com
commit a95fe463e73b8c7b2d97606ac86ce261f1270726
Author: Dave Airlie airl...@redhat.com
Date: Fri Jun 19 10:52:57
From: Dave Airlie airl...@itt42.(none)
Its quite valid to have VRAM aperture size.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm
From: Dave Airlie airl...@linux.ie
This causes an issue since we fixed the drm mappings to do the right thing,
so its just a copy and pasto.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On Wed, Jun 17, 2009 at 8:26 PM, Thomas Hellstromthellst...@vmware.com wrote:
Dave,
I'm sending a couple of minor drm / ttm bugfixes in the hope you have time
to include them before the next pull request. (Sending as patches against
the drm-linus branch).
I also note when trying to compile
On Wed, Jun 17, 2009 at 4:20 AM, Linus
Torvaldstorva...@linux-foundation.org wrote:
On Tue, 16 Jun 2009, Ryan Hope wrote:
+#ifdef MODULE
module_init(radeon_init);
+#else
+late_initcall(radeon_init);
+#endif
You should never need something like that.
Just do
On Wed, Jun 17, 2009 at 6:52 AM, Linus
Torvaldstorva...@linux-foundation.org wrote:
On Wed, 17 Jun 2009, Dave Airlie wrote:
Linus can you pull this tree?
I hate pulling trees when I know there are _known_ bugs.
Even during the merge window. The rest of the -rc series is for fixing up
On Fri, Jun 12, 2009 at 1:56 PM, Allen Akina...@pobox.com wrote:
On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote:
| On Fri, Jun 12, 2009 at 10:01 AM, Allen Akina...@pobox.com wrote:
| On the other hand, if there's no mechanism for implicitly flushing the
| GL command stream
On Sun, 14 Jun 2009, Ryan Hope wrote:
commit 85adafcf5d18e58c60d9fdbb718abe9149661736
Author: Ryan Hope rmh3...@gmail.com
Date: Fri Jun 12 12:17:54 2009 -0400
fix ttm kconfig
Thanks I've merged this into the patchset.
Dave.
diff --git a/drivers/gpu/drm/ttm/Makefile
ATOMBIOS - add support for looking up these values from the bios table
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
commit 771fe6b912fca54f03e8a72eb63058b582775362
Author: Jerome Glisse jgli...@redhat.com
Date: Fri Jun 5 14:42:42
On Mon, Jun 15, 2009 at 12:22 PM, Greg KHg...@kroah.com wrote:
On Mon, Jun 15, 2009 at 03:08:56AM +0100, Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-linus
This is big. It contains
On Mon, Jun 15, 2009 at 10:48 AM, Dave Airlieairl...@linux.ie wrote:
On Sun, 14 Jun 2009, Keith Packard wrote:
Mac Mini's have a single GPIO line on the DVI connector, shared between the
analog link and the digital link. So, if DDC isn't detected on GPIOE (the
usual SDVO DDC link), try GPIOA
header
Signed-off-by: Dave Airlie airl...@redhat.com
commit f2cb5d86e1af175a9b210241800f03a447f92621
Author: Jerome Glisse gli...@freedesktop.org
Date: Wed Apr 8 17:16:24 2009 +0200
drm: Export hash table functionality.
add exports so TTM module can use these functions
Dave,
this is an old patch that seems to have slip through the net, without
it my i915 runs out of GTT space within seconds during firefox replays.
...and it's been acked by me.
I'll push this to Linus on Monday,
sorry I missed it.
Dave.
/Thomas
From
On Fri, Jun 12, 2009 at 5:33 AM, Allen Akina...@pobox.com wrote:
On Thu, Jun 11, 2009 at 11:58:41AM -0600, Brian Paul wrote:
| Dave Airlie wrote:
| The other open question is whether the glFinish in the glean test case
| is actually necessary,
| from reading the glXMakeCurrent manpage
So glXMakeCurrent says
GLXBadCurrentWindow is generated if there are pending GL commands for
the previous context and the current drawable is a window that is no
longer valid.
This appears to be true, we don't seem to have cleared all the pending
GL commands
before, so we
Hi Kristian et al
So you wrote YALL for glxAllContexts and like all good linked list
re-implementations it didn't work :-)
So the attached patch fixes the linked list remove function, so we do
clean up the drawable and context properly.
However now I'm getting a glean failure on the makeCurrent
On Fri, Jun 5, 2009 at 3:42 PM, Markus
Trippelsdorfmar...@trippelsdorf.de wrote:
On Thu, Jun 04, 2009 at 04:39:50AM +0100, Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-fixes
Okay Linus if you
that works fine on my intel hw but seems to have a bad effect on radeon.
Grr.
That pull request probably shouldn't have been sent to me at all. It's
clearly almost totally untested, and it was damn late in the -rc series.
Am I going to be in the situation that I simply can't
-by: Dave Airlie airl...@redhat.com
commit 6c51d1cfa0a370b48a157163340190cf5fd2346b
Author: Ben Skeggs bske...@redhat.com
Date: Tue May 26 10:35:52 2009 +1000
drm: don't associate _DRM_DRIVER maps with a master
A driver will use the _DRM_DRIVER map flag to indicate that it wants
From: Dave Airlie airl...@redhat.com
allocating devname in the i915 driver was a hack originally and I
forgot to figure out how to do this properly back then.
So this is the cleaner version that just picks devname or driver name
in the irq code.
It removes the devname allocs from the i915
Now all the DRM debug info will be printed if the boot option of
drm.debug=1 is added. Sometimes it is inconvenient. We will get too much
unrelated info.
This will separate several DRM debug levels and the debug level can be used
to print the different debug info. And the debug level is
From: Dave Airlie airl...@redhat.com
This just tries EDID detection, then falls back to the slow path code.
I think this is should detect most monitors currently available.
based on Arjan's speed-up patch.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_edid.c |8
This just tries EDID detection, then falls back to the slow path code.
I think this is should detect most monitors currently available.
I need to rework the I2C stuff so that it doesn't require the bit-bang
i2c algo; Display Port needs a custom i2c algo. As such, it seems like
the
On Tue, Mar 24, 2009 at 6:48 AM, Arjan van de Ven ar...@infradead.org wrote:
From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:37:20 -0700
Subject: [PATCH] KMS: do a faster EDID
for some outputs (like
On Wed, Apr 22, 2009 at 6:52 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@linux.ie
On radeon at least this seems to solve a lot of our monitor misdetections.
I suppose its possible if we are the end of a jiffy interval and we don't
have 2.2ms left we could timeout early
On Wed, Apr 22, 2009 at 11:48 AM, Shaohua Li shaohua...@intel.com wrote:
drm_lock() does:
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
...
if (drm_lock_take(master-lock, lock-context)) {
schedule() here
From: Dave Airlie airl...@linux.ie
On radeon at least this seems to solve a lot of our monitor misdetections.
I suppose its possible if we are the end of a jiffy interval and we don't
have 2.2ms left we could timeout early.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915
From: Dave Airlie airl...@linux.ie
We have a drm_set_config which takes a crtc/encoder/mode setup,
and checks it to see if it can shortcut and just do a base setup,
or whether a complete mode setting is required.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm
From: Dave Airlie airl...@linux.ie
duplicate the mode into fbcon storage, so when we free modes later
we don't just lose this.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/intel_display.c |2 ++
drivers/gpu/drm/i915/intel_fb.c | 16
2 files
This is more of a question than a patch...
1) Is DRM_CONTROL_ALLOW still relevant? If yes, does it make sense to add a
check for it in drm_ioctl as per the patch below?
It's relevant but not really used properly yet, I think that may be a
missing patch from kms port.
2) Is it really
-off-by: Shaohua Li shaohua...@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
commit 07f1c7a7f6736d9ec2eba57d209c5f4d841e
Author: Dave Airlie airl...@redhat.com
Date: Mon Apr 20 09:32:50 2009 +1000
drm: check for minor master before allowing drop master.
When fast
Do you want to pick it up then or do you want Dave to take it?
Since it wasn't in my driver, I was assuming airlied would pick it up.
Yup I'll grab it, I was going to leave it for the next merge window as I
dislike doing anything like this post-merge, and it arrived during this
merge.
Cleanup some leftovers from the X port. Dave you may want to just let
Eric take this since the next patch depends on this one.
Please don't send patches that will break the build, if this needs a
change in the i915 driver include it in this patch and I'll take care of
it. if I apply this
On Thu, Apr 2, 2009 at 7:52 PM, Jean Delvare kh...@linux-fr.org wrote:
Remove an include that isn't actually needed to prevent needless
rebuilds.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
Patch already sent on:
* 2009-01-13
* 2009-02-25
David, are you going to apply this patch
...@gmail.com
Date: Sun Mar 29 20:44:26 2009 -0400
drm/radeon: load the right microcode on rs780
Copy/paste error. The RV670 microcode should work ok, so it's
not a show stopper.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl
2009/3/31 Kristian Høgsberg k...@bitplanet.net:
On Tue, Mar 31, 2009 at 4:46 AM, Alan Hourihane al...@fairlite.co.uk wrote:
On Tue, 2009-03-31 at 15:43 +1000, Dave Airlie wrote:
So I've been playing a bit more with DRI2 and I'm having trouble
finding how the buffer creation was meant to work
So I've been playing a bit more with DRI2 and I'm having trouble
finding how the buffer creation was meant to work for depth buffers.
If my app uses a visual
0xbc 24 tc 0 24 0 r . . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
which is 24-bits + 16-bit depth, I don't have enough information in
will incorrectly
show the monitor is HDMI. HDMI spec tell us that any device containing IEEE
registration Identifier will be treated as HDMI device. The patch intends to
detect HDMI monitor by this rule.
Signed-off-by: Ma Ling ling...@intel.com
Signed-off-by: Dave Airlie airl
This branch has a merge in it, due to conflicts with the Intel drm tree
you already pulled. I've asked Eric to not send you direct pulls, he
mentioned you said he should, but it really screws over my tree. I don't
mind direct pulls outside the merge window as it usually smaller bug
I want clean history, but that really means (a) clean and (b) history.
People can (and probably should) rebase their _private_ trees (their own
work). That's a _cleanup_. But never other peoples code. That's a destroy
history
So the history part is fairly easy. There's only one major
Does anyone remember why we've only done macro tiling on the radeon
for the color buffer so far?
I've been playing with tiling under KMS and I've added back macro
tiling for the front/back buffers and it seems to run fine, however
micro tiling the front buffer gives me corrupt pixmaps from X on
On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie airl...@gmail.com wrote:
Does anyone remember why we've only done macro tiling on the radeon
for the color buffer so far?
/me discovers the reason ouch.
So the 2D engine can't deal with a microtiled surface as a source,
so short of using the 3D
On Sat, Mar 28, 2009 at 12:35 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Sat, 28 Mar 2009 01:54:32 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2009-03-26 at 17:43 -0700, Jesse Barnes wrote:
On Wed, 25 Mar 2009 14:45:05 -0700
Eric Anholt e...@anholt.net wrote:
On Thu, 26 Mar 2009, Ma Ling wrote:
Any comments ?
I merged this into my tree today, but I have to clean up another patch
before I can push it.
Dave.
Thanks
Ma Ling
On Tue, 2009-03-24 at 14:31 +0800, Ma Ling wrote:
Sometime we need to communicate with HDMI monitor by sending audio
We've wanted this for a few consumers that touch the pages directly (such as
the following commit), which have been doing the refcounting outside of
get/put pages.
No idea if this is a valid point or not but whenever I see refcount that
isn't a kref my internal, should this be a kref o-meter
401 - 500 of 1423 matches
Mail list logo
