On Tue, Dec 15, 2009 at 7:58 PM, Donnie Fang donnie.f...@gmail.com wrote:
Hmm, in function ttm_bo_mem_space:
for (i = 0; i = placement-num_busy_placement; ++i) {
ret = ttm_mem_type_from_flags(placement-placement[i],
mem_type);
Is the placement-placement[i] typo error or something
From: Dave Airlie airl...@redhat.com
Not sure it ever happens in practice, spotted during code review.
spare brace snuck in
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_gem.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers
On Tue, Dec 15, 2009 at 6:58 PM, Jerome Glisse gli...@freedesktop.org wrote:
On Tue, Dec 15, 2009 at 10:38:36AM +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
If we get ERESTARTSYS we leaked the radeon_bo object here.
Signed-off-by: Dave Airlie airl...@redhat.com
NAK myself
/r600_audio.c
create mode 100644 drivers/gpu/drm/radeon/r600_hdmi.c
commit a3922105319120a48b97ebb42cb43acb5a7e4e73
Merge: ece84e0 6234077
Author: Dave Airlie airl...@redhat.com
Date: Wed Dec 16 15:58:36 2009 +1000
Merge remote branch 'korg/drm-radeon-next' into drm-linus
* korg/drm-radeon
On Wed, 16 Dec 2009, 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 contains radeon HDMI audio support, along with fixes to nouveau for
powerpc from Ben H, some build fixes
From: Dave Airlie airl...@redhat.com
This path isn't used by radeon yet, but future drivers will want it,
so fix it right.
Reported-by: Luca Barbieri l...@luca-barbieri.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
1 files changed, 1 insertions
. But there there is a pretty big chance that the 3D API
will change in the future.
Signed-off-by: Thomas Hellström thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
commit 632f61178d0473861ba77e774bb654b37bc7eccc
Author: Jakob
From: Dave Airlie airl...@redhat.com
If we get ERESTARTSYS we leaked the radeon_bo object here.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_object.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon
From: Dave Airlie airl...@redhat.com
if we fail with ERESTARTSYS during alloc, we'll get a retry from
userspace so don't report it in dmesg.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_gem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff
On Sun, 2009-12-13 at 21:31 +, Arnd Bergmann wrote:
On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote:
On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote:
And now it's obvious that my computer hates me. 12 hours of uptime, one
reboot
to check the old other version
From: Dave Airlie airl...@redhat.com
This adds support for compressed textures to the r100-r500 CS
checker, it lets me run openarena and the demos in mesa fine.
Thanks to Maciej Cencora for initial comments.
Changes since v1:
fix calculations with Maciej formulas
Signed-off-by: Dave Airlie
From: Dave Airlie airl...@redhat.com
a) the loops were going to = not , leading to illegal memory access
b) the busy placement checks were using the placement arrays not the
busy placement ones.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 10
write the
code, Red Hat cannot sign it off however much you rant at them. You also
previously said you don't want to merge stuff when the authors don't want
it merged.
I agree with a lot of what you say.
However, one point remains is that we were told, by Dave Airlie, that
they didn't want
On Fri, Dec 11, 2009 at 8:28 PM, Jeff Garzik j...@garzik.org wrote:
On 12/11/2009 04:18 AM, Alan Cox wrote:
F11 certainly shipped some bits of it for 2D support. I am not sure if
F10 shipped a purely userspace set up. Neither had it enabled as the
default driver - they used nv or vesa
Signed-off-by: Dave Airlie airl...@redhat.com
commit 9062fa6612958f35f41379425bcae9c9b4ccd68e
Author: Alex Deucher alexdeuc...@gmail.com
Date: Wed Dec 9 19:38:58 2009 -0500
drm/radeon/kms/avivo: fix typo in new_pll module description
Signed-off-by: Alex Deucher alexdeuc
Patrice Mandin patman...@gmail.com
Pekka Paalanen p...@iki.fi
Xavier Chantry shinin...@gmail.com
along with project founder Stephane Marchesin marche...@icps.u-strasbg.fr
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Dave Airlie airl...@redhat.com
2009/12/12 Stephane Marchesin stephane.marche...@gmail.com:
2009/12/11 Dave Airlie airl...@linux.ie:
Hi Linus,
Please pull the 'drm-nouveau-pony' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-nouveau-pony
This contains the nouveau driver
On Fri, Dec 11, 2009 at 4:42 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, 10 Dec 2009, Maarten Maathuis wrote:
You assume that Red Hat has full control over the project, which i
don't think is the case. The reason it isn't in staging yet (as far as
i know) is because of
2009/12/11 Rafał Miłecki zaj...@gmail.com:
Christian, I'd like to rebase your patches, correct some minor issue
with timer and try to post it.
I'm looking into your patch
0001-drm-radeon-kms-fix-HDMI-auto-detection.patch
Could you explain somehow please, why do you need to store EDID
2009/12/11 Alan Cox a...@lxorguk.ukuu.org.uk:
The big question is what we call ctxprogs: binary blobs that are
clearly executable, running somewhere in the GPU. No-one seems
to know, if those are copyrightable, or if they can be redistributed.
In their current form, they have been recorded
On Fri, Dec 11, 2009 at 9:37 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, 10 Dec 2009, Stephane Marchesin wrote:
I'm not sure why people are arguing so much over this, given that no
nouveau devs were at the kernel summit, and we only heard rumours
afterwards that there
On Fri, Dec 11, 2009 at 7:59 AM, Christian König
deathsim...@vodafone.de wrote:
Alex already fixed this if i remember correctly.
And for the RV7xx HDMI case, we managed to get it working for resolution
with lower pixel clocks (1024x768 and 640x480). but still now sound at
1280x768, 1280x1024
I realize that you have some emotional attachments to Red Hat, but ask
yourself (and answer honestly): what would you think if some random other
distro was packaging tens of thousands of lines of kernel code and not
apparently working at trying to get them upstream?
Lots of distros do this
2009/12/11 Linus Torvalds torva...@linux-foundation.org:
On Thu, 10 Dec 2009, C. Bergström wrote:
Thanks for the rather lengthly explanation, but in case you missed what
people
are trying to say here..
With all due respect Linus..
patches welcome
The problem is that I have never even
2009/12/11 Brian Paterni bpate...@gmail.com:
On Fri, 11 Dec 2009, Dave Airlie wrote:
I've rebaseed Christian's last patch and fixed up a bunch of
patchcheck violations in it,
its sitting on drm-radeon-testing branch of my git repo, please test
it if you can as I've
no HDMI audio
On Fri, Dec 11, 2009 at 5:51 AM, Thomas Hellstrom tho...@shipmail.org wrote:
Jerome Glisse wrote:
Hi,
So here is a patch which convert bo_init to use struct ttm_placement
rather than flag. It allow the driver to give placement preference
on where to create a bo. Also allow to create a bo at
Attached patch try to simplify gpu address space initialization.
By default it will place the VRAM range to cover the PCI aperture
range corresponding to VRAM.
Patch lack support for AGP and likely need to be twicked for IGP.
I am sending it for early review. The most important thing is
On Thu, Dec 10, 2009 at 3:35 AM, Jerome Glisse jgli...@redhat.com wrote:
This patch add a function which check module argument to be
valid. On invalid argument it prints a warning and setback
the default value.
This seems to screw up here and prints
radeon :06:00.0: vram limit (0) must be
Both radeon and nouveau can re-use this code so move it up a level
so they can. However the hw interfaces for aux ch are different
enough that the code to translate from mode, address, bytes
to actual hw interfaces isn't generic, so move that code into the
Intel driver.
Sounds like
On Tue, 2009-12-08 at 22:59 +0100, Arnd Bergmann wrote:
On Monday 07 December 2009, Arnd Bergmann wrote:
After upgrading one of my machines to 2.6.32, I saw hangs after one to
thirty minutes after
booting, with random data written to parts of the frame buffer. I've
bisected it down
to
From: Dave Airlie airl...@redhat.com
On resume on my rv530 laptop surface cntl was left disabled, so
wierd stuff would happen with rendering to a tiled front buffer.
This checks if the surface regs are assigned to bos and reprograms
the surface registers on resume using the same path that clears
On Wed, Dec 9, 2009 at 4:29 AM, Jerome Glisse jgli...@redhat.com wrote:
Initialize some value to safe default in case we hit an
error path which would leads to uninitialized value.
NAK,
this crashes stuff fairly badly I can see it wasn't actually booted at all.
Dave.
Signed-off-by: Jerome
From: Dave Airlie airl...@redhat.com
We only want to return here for errors, the wait functions return
a positive timeout otherwise, which gets back to userspace and
causes X to crash here.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1
On Mon, Dec 7, 2009 at 6:46 AM, Thomas Hellstrom thellst...@vmware.com wrote:
This patch series adds TTM functionality and a couple of drm exports needed
by the
vmwgfx drm driver. The patch adding the vmwgfx driver itself will be posted
later. The current driver source is available at
| ttm_tt_destroy(bo-ttm);
242| break;
Thanks,
I've pushed this patch.
From 447aeb907e417e0e837b4a4026d5081c88b6e8ca Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Tue, 8 Dec 2009 09:25:45 +1000
Subject: [PATCH] drm/ttm: fix unreachable code.
None of the in-tree
From: Dave Airlie airl...@redhat.com
The object rework moved the tiling flag setup around wrongly,
so tiling we getting setup then overwritten by fb format.
Fixes regression with drm-radeon-next on rv530 laptop tiling test.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm
From: Dave Airlie airl...@redhat.com
If we don't need the zone we need to free it.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_memory.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm
From: Dave Airlie airl...@redhat.com
This adds support for compressed textures to the r100-r500 CS
checker, it lets me run openarena and the demos in mesa fine,
If someone can check the size calcs for DXT1/35 the w//h changes
that would be nice.
Signed-off-by: Dave Airlie airl...@redhat.com
From: Dave Airlie airl...@redhat.com
Again we try to put VRAM at 0, and it didn't work on this chipset,
reports of corrupt RAM appeared on irc and bugzilla.
Fix the vram location according to what the BIOS setup, I'm not 100%
sure we don't need the same thing on rs690/rs780/rs880, we probably
On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
Disable all the possible outputs/crtcs before entering KMS mode.
We need a bit more info than this for such a large change?
At one point we wanted to do smooth startup for LVDS panels,
so
On Sat, Dec 5, 2009 at 3:33 PM, Luc Verhaegen l...@skynet.be wrote:
On Sat, Dec 05, 2009 at 12:06:56AM -0500, Alex Deucher wrote:
But as long as you stick to your case religiously, then we are certain
that all that crap was thrown justifiedly, even though connection
detection always had
Also fix an embarassing bug in standard timing subblock parsing that
would result in an infinite loop.
Thanks, all applied to drm-core-next.
Dave.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 163 ---
1 files
On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse jgli...@redhat.com wrote:
The locking protection of radeon object was somewhat messy.
This patch completely rework it to now use ttm reserve as a
protection for the radeon object structure member. It also
shrink down the various radeon object
From: Dave Airlie airl...@redhat.com
Both radeon and nouveau can re-use this code so move it up a level
so they can. However the hw interfaces for aux ch are different
enough that the code to translate from mode, address, bytes
to actual hw interfaces isn't generic, so move that code
On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse jgli...@redhat.com wrote:
This patch series add ttm range validation function. Aim is to
include this in 2.6.33 so i have time to iron out issue, comments.
I missed these first time around,
Thomas if you have any opinions on the TTM stuff please
So I'm going to change the layout of my git branches again, because my
current plan isn't working for me.
At the moment drm-next is considered the branch to base new work off
and to also for downstream trees to
pull from, this is changing.
I will now maintain
drm-core-next : a branch with all
From: Dave Airlie airl...@redhat.com
If the chip isn't initialised properly this can happen.
also fix return value in combios clocks function.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_clocks.c |4
drivers/gpu/drm/radeon/radeon_combios.c |2
From: Dave Airlie airl...@redhat.com
If we find a GPU but we can't find its BIOS and it isn't posted,
then ignore it.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c |6 ++
drivers/gpu/drm/radeon/r300.c |6 ++
drivers/gpu/drm
This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
are implemented via a ring buffer. The GPU adds interrupts vectors to
the ring and the host reads them off in the interrupt handler. The
interrupt controller requires firmware like the CP. This firmware
must be installed
This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
are implemented via a ring buffer. The GPU adds interrupts vectors to
the ring and the host reads them off in the interrupt handler. The
interrupt controller requires firmware like the CP. This firmware
must be installed
This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
are implemented via a ring buffer. The GPU adds interrupts vectors to
the ring and the host reads them off in the interrupt handler. The
interrupt controller requires firmware like the CP. This firmware
must be
I haven't published any of my work recently, but that doesn't mean I haven't
done anything that I would like to share. Not sure why you feel this is
important however.
I gave you a number of suggestions in private emails on how to fix problems
such as the merging issue and you were
On Wed, Nov 25, 2009 at 5:21 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Mon, 23 Nov 2009 07:04:51 -0500 Ed Tomlinson e...@aei.ca wrote:
Hi,
I got the following opps when leaving X with rc8:
[ 183.846716] Unpin not necessary for 88016bba2200 !
Jerome, Ed's kernel is talking
Cc: sta...@kernel.org
Signed-off-by: Dave Airlie airl...@redhat.com
commit 79cc304f3e2fda202242036326afb2aeca486156
Author: Jeremy Fitzhardinge jer...@goop.org
Date: Tue Nov 17 14:08:54 2009 -0800
drm: make sure page protections are updated after changing vm_flags
Some
On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote:
On Saturday 21 November 2009 20:09:53 Dave Airlie wrote:
I see that you deleted bsd-core dispite the requests of a number of
people that you do not.
Its git, nobody has touched any of it in ages, and none of the BSD
From: Dave Airlie airl...@redhat.com
rendercheck under kms on r600s was failing due to HDP flushing not happening.
This adds HDP flushing to the object wait function for r100-r700 families.
rendercheck passes basic tests on r600 with this change.
Signed-off-by: Dave Airlie airl...@redhat.com
I see that you deleted bsd-core dispite the requests of a number of people
that you do not.
Its git, nobody has touched any of it in ages, and none of the BSD
maintainers used it, you can just get it back by branching from the commit
before its removal, if you think revival is needed,
On Sun, Nov 22, 2009 at 9:15 AM, Rafael J. Wysocki r...@sisk.pl wrote:
Hi,
I'm not really sure where this should be reported, but here it goes.
After installing openSUSE 11.2 on my testbed nx6325 I noticed that resume
(from suspend to RAM) stopped working on it. Apparently, it hanged while
On Sat, Nov 21, 2009 at 6:48 AM, James Simmons jsimm...@infradead.org wrote:
On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
On 11/20/2009 10:01 PM, James Simmons wrote:
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
paulius.zalec...@gmail.com wrote:
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
On Thu, Nov 19, 2009 at 11:54 AM, vehemens vehem...@verizon.net wrote:
On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote:
2009/11/6 Kristian Høgsberg k...@bitplanet.net:
Hi,
This has come up a few time and it's something I think makes a lot of
sense. Since all driver
...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
commit bc5096a4771453929537605e564b32c534c869bf
Author: Dave Airlie airl...@redhat.com
Date: Wed Nov 18 13:39:34 2009 +1000
drm/radeon/kms: pick 8bpp console when 32MB or less VRAM
making the pinned console smaller gives X
-by: Thomas Schlichter thomas.schlich...@web.de
Cc: Dave Airlie airl...@redhat.com
Cc: Eric Anholt e...@anholt.net
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
include/drm/drm_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff -puN include/drm/drm_pciids.h~drm-via-add-pci-id
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
*cough* checkpatch.pl *cough*.
Dave.
---
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/i915_gem.c | 64 +-
drivers/gpu/drm/i915/i915_irq.c | 10 ++
drivers/gpu/drm/i915/i915_reg.h |2
On Fri, Oct 30, 2009 at 8:13 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 30 October 2009, Dave Airlie wrote:
Btw when I mentioned ioctls I meant more than radeon, all the KMS
ioctls in the common drm_crtc.c file suffer from this problem as well.
Hence why I still believe either my drm
2009/8/5 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
Hi Michel, sorry I lost this when we got stuck with fb reallocations.
One problem is this now underreports, I think you can just remove
gart table + fbcon from
From: Dave Airlie airl...@redhat.com
FB read/write really doesn't need to access the actual VRAM, we
can just use a scratch area. This is required for using atom displayport
calls later.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/atom.c | 32
On Mon, Nov 16, 2009 at 8:52 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Sun, Nov 15, 2009 at 4:30 PM, Mikko Vinni mmvi...@yahoo.com wrote:
Hi,
after commit a39533b4ddad388b64a20bcabd17ac125fd4ba65
(drm/radeon/r600: CS parser updates) landed in mainline
(happens still in
On Fri, Nov 6, 2009 at 12:43 AM, Jerome Glisse jgli...@redhat.com wrote:
Remove dead code in ttm_bo_handle_mem_move and add comment on
what we are doing their and why.
I haven't seen Thomas's ACK on this? I'd like to keep TTM under his control ;-)
Dave.
Signed-off-by: Jerome Glisse
On Sat, Nov 14, 2009 at 5:56 AM, Jerome Glisse jgli...@redhat.com wrote:
unused_nodes modification needs to be protected by unused_lock spinlock.
Here is an example of an usage where there is no such protection without
this patch.
Process 1: 1-drm_mm_pre_get(this function modify unused_nodes
maintainers. The rightmost column are my observations.
Below is the patch fixing these.
Ingo
Signed-off-by: Ingo Molnar mi...@elte.hu
Looks good to me for radeon bits.
Acked-by: Dave Airlie airl...@redhat.com
Dave
Hi Dave,
I was wondering about the current state of Radeon KMS, how far are we
from having it removed from staging?
I'm sort of thinking the next merge window of moving the enable option
into the kernel proper. We still have a metric shitload of work to get to
feature parity with current
I'm sort of thinking the next merge window of moving the enable option
into the kernel proper. We still have a metric shitload of work to get to
feature parity with current userspace drivers and we've done no
optimisation work on the rendering portion of the stack so I'm not sure
From: Dave Airlie airl...@linux.ie
This fixes RH bugzilla #527874.
On resume the atom posting wasn't working, however vbe posting was
going fine, after 2 weeks over irc, and 8 hrs with the hardware,
I tracked it down to the memory device table and it access the MC
registers via IIO, it appears
From: Dave Airlie airl...@linux.ie
An rv515 laptop I got wouldn't startup with a montior plugged in,
found the proper bug hopefully with us not turning off D2VGA
here when we should.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/rv515.c |9 -
1 files
Do like in the DDX don't try to load detect TV output, there is a lot
of false positive detection with those code. Seems to be isolated to
RS480/RC410 chipset thought. Need more investigations.
NAK, I've not seen any false positive bug reports other than rs480, and
I suspect that is some
24710.
Signed-off-by: Francisco Jerez curroje...@riseup.net
Signed-off-by: Dave Airlie airl...@redhat.com
commit a39533b4ddad388b64a20bcabd17ac125fd4ba65
Author: Alex Deucher alexdeuc...@gmail.com
Date: Mon Nov 9 16:41:21 2009 -0500
drm/radeon/r600: CS parser updates
Add
From: Dave Airlie airl...@redhat.com
We really don't need to process every irq that comes in, we only
really want to do SW irq processing when we are actually waiting for
a fence to pass. I'm not 100% sure this is race free esp on non-MSI systems
so it needs some testing.
Signed-off-by: Dave
From: Dave Airlie airl...@linux.ie
Once kms is enabled we don't need these, and it causes a problem
with the Lenovo W500 ACPI brightness implementation, it hangs
in a loop inside an SMI.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/rv515.c |2 ++
1 files changed
From: Dave Airlie airl...@linux.ie
The Lenovo W500 laptop hangs inside an SMI on brightness changes,
I thought it just needed the VGA disable but it turned out to require
slightly more work, setting the MC locations up just like the IGP
chip requirements seems to make it all happy again and I can
On Sat, Oct 31, 2009 at 12:39 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Oct 29, 2009 at 11:32 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
When we are evicting from VRAM-RAM we allocate the ttm object,
but we don't set the caching policy
On Wed, Oct 28, 2009 at 5:53 PM, David Miller da...@davemloft.net wrote:
From: David Miller da...@davemloft.net
Date: Tue, 27 Oct 2009 23:04:50 -0700 (PDT)
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
I'll add this to my TODO for before the next merge
From: Dave Airlie airl...@redhat.com
When we are evicting from VRAM-RAM we allocate the ttm object,
but we don't set the caching policy on it before blitting into it.
This means on AGP we end up blitting into cached pages, and
the CPU later flushes out on top of them. This was mostly seen as
font
mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Indeed this seems to be a typo, the important thing is to get someone
like Dave Airlie to pick it up.
Yup I've picked this up in my queue.
Dave
I don't think you tested this very extensively.
I'm bisecting a bug where my new Dell Inspiron 11z has corrupted LUT or
gamma tables or something. And while I have a lot of commits left to go,
only two of them still touch the i915 driver. And the two commits are:
Ive got a fix already,
So for drm KMS we wrote a bunch of ioctls that were 64-bit clean in theory.
They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user
Now I thought cool I don't need to worry about compat ioctl hackery I can
run
++--
drivers/gpu/drm/radeon/radeon_device.c |7 ++---
3 files changed, 47 insertions(+), 17 deletions(-)
commit 77de0846aed9d7a1b0ea65090620900d66fb5cfb
Author: Dave Airlie airl...@redhat.com
Date: Fri Oct 23 18:49:03 2009 +1000
drm/kms: fix kms/fbdev colormap
On Wed, Oct 28, 2009 at 12:25 PM, David Miller da...@davemloft.net wrote:
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 11:22:18 +1000
Is there really no way to avoid compat ioctls? was I delusional in
thinking there was?
If you use pointers in your interfaces in any way
On Wed, Oct 28, 2009 at 12:53 PM, Andi Kleen a...@firstfloor.org wrote:
Dave Airlie airl...@gmail.com writes:
They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user
uint64_t is actually dangerous due
On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen a...@firstfloor.org wrote:
On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
We've designed that into a/c also, we pad all 64-bit values to 64-bit
alignment on all the
ioctls we've added to the drm in the past couple of years. Just because
DrNick on irc suggested just doing:
if (is_compat_task()) ptr = 0x;
Is there a one liner I can just do in the actual ioctls instead of
adding 20 compat
ones?
Just do the right thing and pass all userland compat pointers
through the correct compat_*() macros.
I
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be, it's only working because:
1) A malicious userland hasn't put garbage in the
Please don't do this.
This is exactly what I feared people would do when is_compat_task()
was added. is_compat_task() is for situations where there is
otherwise no other way to handle the compat situation properly.
It's not that much work for you to hook up the compat ioctls properly,
From: Dave Airlie airl...@redhat.com
This fixes suspend/resume on my rc410 motherboard, it restores
the memory controller setup before posting the GPU, since it seems
to need the MC_FB_LOCATION setup correctly.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/rs400.c
On Thu, Oct 22, 2009 at 8:49 AM, Jerome Glisse gli...@freedesktop.org wrote:
Hi,
I think we should merge the read write domain of radeon KMS
into a single domains information. I don't think there is a
good reason for separate read write domain, we did copy intel
model for that and intel
On Thu, Oct 15, 2009 at 7:48 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 14 Oct 2009 14:47:22 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 11 Sep 2009 14:33:34 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
This patch adds a new flag to the drmWaitVblank
On Fri, Oct 23, 2009 at 6:16 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From a8a7d447d4f781670a849e345f5f31edb975c397 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 22 Oct 2009 16:12:34 -0400
Subject: [PATCH] drm/radeon/kms/r7xx: add regs for 40 bit CUR/GRPH
On Thu, Oct 22, 2009 at 4:51 AM, Alex Deucher alexdeuc...@gmail.com wrote:
A bunch of radeon drm patches from my local queue.
Alex
First 4 applied to send to Linus, the last one I'm leaving in drm-next
since I hate freelist
and it always seems fragile.
Dave.
On Tue, Oct 20, 2009 at 3:01 AM, Alex Deucher alexdeuc...@gmail.com wrote:
First one fixes the CS parser for large textures, second one adds a
quirk for tv-out on the acer 5102.
Alex
Sent to Linus.
Dave.
--
Come
On Sat, Oct 17, 2009 at 2:26 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From 482ec0ac012a8e4ca535ee50fc96305a1f11f43a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 16 Oct 2009 12:21:24 -0400
Subject: [PATCH] drm/radeon/kms: add support for msi
Try to enable
201 - 300 of 1423 matches
Mail list logo
