From: Dave Airlie
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
---
drivers/gpu/drm/drm_crtc_helper.c | 19 ---
1
From: Dave Airlie
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
---
drivers/gpu/drm/i915/intel_i2c.c |4 +++-
1
Shaohua Li
Signed-off-by: Dave Airlie
commit 07f1c7a7f6736d9ec2eba57d209c5f4d841e
Author: Dave Airlie
Date: Mon Apr 20 09:32:50 2009 +1000
drm: check for minor master before allowing drop master.
When fast user switching a lot eventually we get to the point,
whe
> 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 real
> > 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.
cher
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
Signed-off-by: Dave Airlie
commit 5f3dbedf2770cf6aeb5547b3c
On Thu, Apr 2, 2009 at 7:52 PM, Jean Delvare wrote:
> Remove an include that isn't actually needed to prevent needless
> rebuilds.
>
> Signed-off-by: Jean Delvare
> ---
> Patch already sent on:
> * 2009-01-13
> * 2009-02-25
> David, are you going to apply this patch or should I push it upstream
> 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 n
2009/3/31 Kristian Høgsberg :
> On Tue, Mar 31, 2009 at 4:46 AM, Alan Hourihane 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
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
On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie 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
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 it
>
> 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 o
> > 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
ection 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
Signed-off-b
On Sat, Mar 28, 2009 at 12:35 PM, Jesse Barnes wrote:
> On Sat, 28 Mar 2009 01:54:32 +0100
> Peter Zijlstra wrote:
>
>> On Thu, 2009-03-26 at 17:43 -0700, Jesse Barnes wrote:
>> > On Wed, 25 Mar 2009 14:45:05 -0700
>> > Eric Anholt wrote:
>> >
>> > > Since the pagefault path determines that the
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
I've no idea when a fault is likely in the fast case, i.e. will it happen
usually on the first page etc, because if it happens on the last page and
you fallback and restart the whole copy, I would think that would be
sub-optimal, granted it could get ugly quick, but this code has already
hit a
> 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-m
On Thu, Mar 19, 2009 at 2:08 PM, Greg KH wrote:
> Hi,
>
> Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the
> kernel tree.
>
> There are 4 patches that make changes to the DRM core, and one patch
> that adds the DRM driver itself. The driver is added to the
> drivers/stagin
On Sun, Mar 15, 2009 at 12:34 AM, Frans Pop wrote:
> I had the oops below today after I tried to start a second X.org session
> in a chroot using 'startx -- :1'. I think the problem here is that the
> driver was loaded, but that the corresponding device did not exist in
> /dev in the chroot (forgo
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r600_cp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index 490f353..76eb0d5 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
YAKUMO 17" for which more details are unknown.
Signed-off-by: Pantelis Koukousoulas
Signed-off-by: Dave Airlie
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0
From: Dave Airlie
Until we sort out r600 IRQs don't do this.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_drv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
From: Dave Airlie
This update was done in mainline radeon, but not in the r600.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r600_cp.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index
From: Dave Airlie
This realigns the r600 pci mapping calls with the ati pcigart ones,
fixing the direction and using the correct interface.
Suggested by Jerome Glisse.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r600_cp.c | 12 ++--
1 files changed, 6 insertions(+), 6
From: Dave Airlie
This fixes up the warnings in the debugfs code that conflicted
with the mapping fixups.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_info.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm
From: Dave Airlie
This fixes 2 bugs:
1. the AGP calculation wasn't consistent with the PCI(E) calc for the
RPTR_ADDR registers. This consolidates the writes and fixes it up.
2. The scratch address was being incorrectly calculated, this breaks
it out into a lot more linear steps.
Signed-o
From: Dave Airlie
This calls the correct idle function for the R600 and previous chips.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_cp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon
> > I ported it back.
>
> We need to bump the dri version for this so we don't deadlock on older
> kernels when the 2d drivers start using this. A second non-kms X
> server would just fail to initialize DRI before, when we add
> drmSetMaster() support they will deadlock if we don't make it
> con
> Fix deadlock in drm_setmaster_ioctl
Wow, I have this right in my rawhide tree, I must have retyped this when
I ported it back.
thanks I'll send it to Linus now.
Dave.
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 096e2a3..7c8b15b 100644
> --- a/drivers/gpu/
a21
Author: Eric Anholt
Date: Tue Feb 24 22:14:12 2009 -0800
drm/i915: Fix use-before-null-check in i915_irq_emit().
This could be triggered by a client asking to emit an irq when the device
wasn't initialized.
Signed-off-by: Eric Anholt
Signed-off-by: Dave
> Hi Roland,
>
> when you tested my radeon-rewrite was it on an r100 or r200?
>
> Can you check with a clean master checkout whether page flipping works
> for you at all?
>
please can you re-test radeon-rewrite as well, I've pushed a rewrite of
the fb handling towards eventually getting fbos g
Hi Roland,
when you tested my radeon-rewrite was it on an r100 or r200?
Can you check with a clean master checkout whether page flipping works
for you at all?
RADEON_DEBUG=ioctl ./progs/trivial/clear
for me seems to use a copy buffer but it might be a local issue.
However the drawable stamp up
Prompted by how well it worked with Intel, and changes in my personal life
leading to reduced time availability (except at 4am...) I'm going to
clarify the process for getting patches upstream now. (a...@amd also
trialed this to get r600 upstream).
1. Apart from maybe minor changes I will no l
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r600_cp.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index 54ea867..37249b2 100644
--- a/drivers/gpu/drm
From: Dave Airlie
This attempts to fixup the r600 GART accessors so they work on other arches.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r600_cp.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b
From: Dave Airlie
The readq/writeq stuff is from Dave Miller, and he
warns users to be careful about using these. Plans are only
r600 to use it so far.
Signed-off-by: Dave Airlie
---
include/drm/drm_os_linux.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff
From: Dave Airlie
Also don't setup pci_gart if we aren't going to need it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ati_pcigart.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
ind
u/drm/i915/intel_display.c |2 +-
include/drm/drm_crtc_helper.h|1 +
include/drm/drm_edid.h |4 +-
9 files changed, 97 insertions(+), 16 deletions(-)
commit e08fb4f6d1dc95eff5b3fc1d0412bcb5afcae7f2
Author: Dave Airlie
Date: Wed Feb 25 14:52:30 2009 +1000
s is the simplest for now.
Signed-off-by: Pierre Willenbrock
Signed-off-by: Dave Airlie
commit 6fb88588555a18792a27f483887fe1f2af5f9c9b
Author: Jesse Barnes
Date: Mon Feb 23 10:08:21 2009 +1000
drm/i915: fix WC mapping in non-GEM i915 code.
[airlied - taken from mai
rk so gets authorship]
Signed-off-by: etienne
Signed-off-by: Dave Airlie
commit ab00b3e5210954cbaff9207db874a9f03197e3ba
Author: Jesse Barnes
Date: Wed Feb 11 14:01:46 2009 -0800
drm/i915: Keep refs on the object over the lifetime of vmas for GTT mmap.
This fixes poten
On Mon, Feb 16, 2009 at 10:52 PM, Jiri Kosina wrote:
> On Mon, 9 Feb 2009, Tobias Klauser wrote:
>
>> The C99 specification states in section 6.11.5:
>>
>> The placement of a storage-class specifier other than at the beginning
>> of the declaration specifiers in a declaration is an obsolescent
>>
On Mon, Feb 16, 2009 at 5:33 PM, Michel Dänzer wrote:
> On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote:
>> On Friday, February 13, 2009 2:33 am Michel Dänzer wrote:
>> > On Thu, 2009-02-12 at 09:15 -0800, Jesse Barnes wrote:
>> > > It does, but take a look at that code again. If interrupts
>
> This will need to be revisited with KMS as i think we should not allow
> userspace to play with surface. Maybe we could setup surface on BO
> mapping and disable them on bo unmapping (we would to register some
> callback on vmclose).
Under KMS we can either enable swappers fulltime or just us
On Sat, Feb 14, 2009 at 4:09 PM, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Thu, 12 Feb 2009 21:35:59 +1100
>
>> Oh BTW something else to be careful with, though I suppose it's working
>> some what by accident right now... when the GART is in the frame buffer
>> it gets applied th
> > Compressed textures also seem to be broken, since they'll raise a FPE:
> > Program received signal SIGFPE, Arithmetic exception.
> > [Switching to Thread -1480239424 (LWP 11180)]
> > 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
> > target=3553, firstLevel=0,
> > lastL
On Thu, Feb 12, 2009 at 8:15 PM, David Miller wrote:
>
> David, this work is against your drm-next branch.
>
> Here are a collection of bug fixes for the Radeon DRM support. Most
> of them have to do with trying to access kernel virtual addresses
> using DRM_READ32() and DRM_WRITE32().
>
> With t
On Thu, Feb 12, 2009 at 9:09 PM, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Thu, 12 Feb 2009 21:35:59 +1100
>
>> Oh BTW something else to be careful with, though I suppose it's working
>> some what by accident right now... when the GART is in the frame buffer
>> it gets applied th
>
> r200 appears busted, but its wierd busted I'll blame the master merge and
> fix it tomorrow.
Okay r200 gears is back, I think it was an artifact of not getting a clean
build, along with fixing some warnings.
Dave.
>
> Dave.
>
> >
> > So with that in mind and not wanting to write this 3
> Hi,
>
> So I have a goal to get a radeon driver that works on a bufmgr and that
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
> work.
r200 appears busted, but its wierd busted I'll blame the master merge and
fix it tomorrow.
Dave.
>
> So with that in mind and n
Hi,
So I have a goal to get a radeon driver that works on a bufmgr and that
then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
work.
So with that in mind and not wanting to write this 3 times, I've done a
major refactoring of the radeon/r200/r300 drivers.
I've refactored
of its
own.
( There is some minor circular dependency fallout as FB_I810
and FB_INTEL also used 'depends on FB' constructs - update
those to "select FB" too. )
Reported-by: Norbert Preining
Signed-off-by: Ingo Molnar
Signed-off-by: Dave Airlie
On Mon, Feb 9, 2009 at 12:25 AM, Roel Kluin wrote:
> With a postfix decrement count will reach -1 rather than 0,
> subsequent tests fail.
Thomas can you sign off on this?
Dave.
>
> Signed-off-by: Roel Kluin
> ---
> diff --git a/drivers/gpu/drm/via/via_dma.c b/drivers/gpu/drm/via/via_dma.c
> ind
>
> So marcheu reminded me of my laziness and I built mach64 but I took a
> quick look at its API and its not 32/64 compliant by any reach.
>
> So I'd like to merge it with a version 3.0.0 API which fixes all the API
> issues I could fine, mainly using void *, unsigned long, I nuked some
> uns
> > > > On Thursday, January 29, 2009 12:50 pm a...@linux-foundation.org wrote:
>
> So I assume that it would make sense to track this as a post-2.6.28
> regression?
>
>From ac048e1734699dd98f4bdf4daf2b9592d4a4d38e Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date
On Tue, Jan 6, 2009 at 7:10 AM, Kristian Høgsberg wrote:
> The kernel shouldn't be in the business of telling user space which
> driver to load. The kernel defers mapping PCI IDs to module names
> to user space and we should do the same for DRI drivers.
>
> And in fact, that's how it does work to
>
> BTW. Do you guys want me to remove the drm_local_map_t typedef
> completely in favor of struct drm_local_map ? I have a patch here going
> part way through that, it's fairly trivial, so if you want it, I can
> easily finish it.
One less typedef is always welcome.
Dave.
>
> Cheers,
> Ben.
>
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
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, 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 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 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 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
> 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):
>
>
> 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
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
> 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
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
|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
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.
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
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 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
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 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
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
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
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
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
>
> 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/
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
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
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 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
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
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
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
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
> 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
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
> 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
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
-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
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
. 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
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.
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
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 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
501 - 600 of 1512 matches
Mail list logo
