anged, 456 insertions(+), 254 deletions(-)
commit 5ef5f72febfea420ce58f670bad83830a5e5e3de
Author: Dave Airlie
Date: Mon Aug 17 13:11:23 2009 +1000
drm/kms: teardown crtc correctly when fb is destroyed.
If userspace destroys a framebuffer that is in use on a crtc,
don't j
On Wed, Aug 19, 2009 at 9:31 AM, Luc Verhaegen wrote:
> On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
>> On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegen wrote:
>> > On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
>> >> On Wed, Aug 19, 2009 a
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>> > I think the bug in question was because somebody (Jon Smirl??)
>> > removed the emp
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
> I think the bug in question was because somebody (Jon Smirl??) removed the
> empty & apparently unused poll implementation from the drm fd, only to
> discover that the X server was actually polling the fd.
>
> If this code adds to, extends
> +#undef set_base
> +
> struct drm_prop_enum_list {
> int type;
> char *name;
> @@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
> EXPORT_SYMBOL(drm_framebuffer_cleanup);
>
> /**
> + * drm_crtc_async_flip - do a set_base call from a work queue
> + * @w
On Tue, Aug 18, 2009 at 9:54 AM, Kristian Høgsberg wrote:
> On Mon, Aug 17, 2009 at 7:14 PM, Dave Airlie wrote:
>>>>
>>>> A couple of years ago, any attempt to return anything else than 0 from
>>>> drm poll resulted in an X server error.
>>>> h
>>
>> A couple of years ago, any attempt to return anything else than 0 from
>> drm poll resulted in an X server error.
>> http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. The fix mentioned
>> in the bug was actually to return 0 from drm poll, and a comment about
>> this is still present in dr
From: Dave Airlie
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
---
drivers/gpu/drm/drm_crtc.c |
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gem.c| 22
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gem.c| 22
From: Dave Airlie
These are needed for Occulsion Query support.
Signed-off-by: Dave Airlie
---
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/drm/radeon/r300.c
index 1e4f6cd
gt; /* Detailed mode timing */
> >> if (timing->pixel_clock) {
> >> newmode = drm_mode_detailed(dev, edid,
> >> timing, quirks);
> >
> > Yeah I've sent this before too, but I think it got missed. Dav
On Sat, Aug 15, 2009 at 3:45 AM, Jesse Barnes wrote:
> On Fri, 14 Aug 2009 10:38:31 -0700
> Anssi Hannula 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
>> EDID Implementation Guide only sa
===
> Bruce C. Chang(???)
> VIA Technologies, Inc.
> 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
>
>
> -Origi
these resources. This document
introduces the operation of the VGA arbiter implemented for Linux kernel.
Signed-off-by: Tiago Vignatti
Signed-off-by: Dave Airlie
---
drivers/gpu/Makefile |2 +-
drivers/gpu/vga/Kconfig | 10 +
drivers/gpu/vga/Makefile |1 +
d
From: Dave Airlie
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 in the single d
are pretty pointless
Reviewed-by: Jesse Barnes
Signed-off-by: Dave Airlie
commit 8d3457ec3198a569dd14dc9e3ae8b6163bcaa0b5
Author: Paul Rolland
Date: Sun Aug 9 12:24:01 2009 +1000
drm: silence pointless vblank warning.
Some applications/hardware combinations are trig
On Sat, Aug 8, 2009 at 7:51 AM, Jerome Glisse 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 that were made.
I
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/radeon_device.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff
how the bo driver and GTT memory
type was initialized.
Signed-off-by: Jerome Glisse
Signed-off-by: Dave Airlie
commit 6502fbfaf81b09b3f474bb7b3796257e9450273e
Author: Alex Deucher
Date: Tue Aug 4 11:24:24 2009 -0400
drm/radeon: Add support for RS880 chips
These are n
ew AMD IGP chips
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deploy
> 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 Mon, 2009-07-20 at 13:48 +0800, yakui.z...@intel.com wrote:
> From: Zhao Yakui
>
> 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 in the macro de
Roel Kluin
Date: Mon Aug 3 14:22:53 2009 +0200
drm/ttm: Read buffer overflow
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin
Signed-off-by: Dave Airlie
commit fa99239cb73dbf419bea9f334b85ba94ac88a532
Author: Roel Kluin
Date:
From: Dave Airlie
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 lifetime.
Signed
start = page_to_pfn(pages[i]) << PAGE_SHIFT;
> > end = start + PAGE_SIZE;
> > if (reserve_memtype(start, end, _PAGE_CACHE_UC_MINUS, NULL))
> > goto err_out;
>
> ok, that's a bug introduced in .29 but which was latent u
On Sun, Aug 2, 2009 at 12:48 AM, Jerome Glisse 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 properly synchronize
> d
>
> 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 h
c9222e7d0a35d97521e904223
Author: Dave Airlie
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
commit b42db2b12df7b4f7b2ace581a7726cb5bcb2d658
Author:
2009/7/28 Michel Dänzer :
> From: Michel Dänzer
>
> 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 /dev/mem, but that's hardly a
On Thu, Jul 23, 2009 at 9:24 AM, Keith Whitwell wrote:
> On Wed, 2009-07-22 at 15:35 -0700, Jerome Glisse wrote:
>> On Wed, 2009-07-22 at 21:13 +0200, Thomas Hellström wrote:
>> > Jerome Glisse wrote:
>> > > On Wed, 2009-07-22 at 15:16 +0200, Michel Dänzer wrote:
>> > >
>> > >> On Tue, 2009-07-21 a
>
> 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 unfortun
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/r100.c |
2009/7/21 Stephane Marchesin :
> 2009/7/20 Thomas Hellström :
>>
>> 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 their Chrome9 DRM merged int
2009/7/21 Thomas Hellström :
> Stephane Marchesin wrote:
>>>
>>> You obviously got all this completely wrong.
>>>
>>> I avoid writing closed source drivers whenever I can, I'm not whining and
>>> I'm not trying to push any of them. The code VIA is trying to submit has
>>> not
>>> been written by me
2009/7/21 Peter Zijlstra :
> 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 clearly stated,
On Fri, Jul 17, 2009 at 9:37 PM, Harald Welte wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
>> On Fri, Jul 17, 2009 at 4:36 PM, wrote:
>> > To whom it may ceoncern:
>> > The following 3 patches are the DRM kernel module that support VIA
>
On Fri, Jul 17, 2009 at 4:36 PM, 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 documentation to wr
> 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.
> +
> +stru
uc,wc pages.
>
> 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
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/ttm/Makefile
>fld;
//
Signed-off-by: Julia Lawall
Signed-off-by: Dave Airlie
commit ba0ab82358a12e7a7f2872d6b65c437157c6888f
Author: Jesse Barnes
Date: Fri Jul 3 11:24:46 2009 -0700
fb/intelfb: conflict with DRM_I915 and hide by default
Users get confused by this dr
From: Dave Airlie
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-by: Dave Airlie
From: Dave Airlie
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 that)
Signed-off-by: Dave
2009/6/30 Thomas Hellström :
> 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 Glisse
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
From: Dave Airlie
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,
you actually move it
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/radeon_cursor.c |2 +-
drivers/gpu/drm/radeon
> 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
Acked-by: Dave Airlie
Dave.
> ---
> include/drm/drm_memory.h |2 --
> 1 files cha
From: Dave Airlie
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. Note rotate
From: Dave Airlie
1. rv370 can accept 40-bit addresses - also at 24-bit shift not 4 bits
2. rs480 table can be in 40-bit space. - 4 bit shift for top 8 bits
3. rs480 table entries can be in 40-bit space.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r100.c|2 +-
drivers
From: Dave Airlie
If there is a problem then this is hiding it, we shouldn't
ever need to flush the IB. Either the buffers are:
WB - caching just works.
WC - no need to do explicit flush, the MB + readback will do it
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_ring.c |
From: Dave Airlie
Unsigned long is incorrect for 64-bit resources on 32-bit hw.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index
From: Dave Airlie
This undoes some stupid from earlier, wbinvd *does* need ipi,
clflush doesn't.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_cache.c | 18 +++-
drivers/gpu/drm/ttm/ttm_tt.c | 61 +
include/drm/drm_cache.h |
Some patches I had sitting on one development box, cleaned up a bit,
but I think they should all make sense.
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
2009/6/29 Michel Dänzer :
> On Mon, 2009-06-29 at 11:21 +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> 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 t
From: Dave Airlie
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 it isn't
t
s should enable GEM on PAE to work
> a lot better as we can pass highmem pages to the PAT code and it will
> do the right thing with them.
>
> Signed-off-by: Dave Airlie
>
--
--
>
> 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
On Thu, Jun 25, 2009 at 10:01 PM, Jerome Glisse 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.
>
My original v
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/r100.c
Date: Wed Jun 24 16:31:50 2009 +1000
drm: remove unused #include 's
Remove unused #include ('s) in
drivers/gpu/drm/ttm/ttm_bo_util.c
drivers/gpu/drm/ttm/ttm_bo_vm.c
drivers/gpu/drm/ttm/ttm_tt.c
Signed-off-by: Huang Weiyi
Signe
From: Dave Airlie
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 but not sure for
On Tue, Jun 23, 2009 at 9:35 PM, Peter Zijlstra 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 messy when you
> > 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.
> >
> >
> 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 spa
>
>
> 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
> > > cra
>
>
> 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
> >
>
> 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
> >
> > 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/
>
> Someth
stuffed in the unused lower bits of the
page address are lost.
Signed-off-by: Pierre Willenbrock
Signed-off-by: Dave Airlie
commit a95fe463e73b8c7b2d97606ac86ce261f1270726
Author: Dave Airlie
Date: Fri Jun 19 10:52:57 2009 +1000
agp: add user mapping support to ATI
deletions(-)
create mode 100644 drivers/gpu/drm/radeon/r300.h
delete mode 100644 include/drm/drm_memory_debug.h
commit a95fe463e73b8c7b2d97606ac86ce261f1270726
Author: Dave Airlie
Date: Fri Jun 19 10:52:57 2009 +1000
agp: add user mapping support to ATI AGP bridge.
This should fix
From: Dave Airlie
Its quite valid to have VRAM < aperture size.
Signed-off-by: Dave Airlie
---
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/radeon/r100.c
index 5225f5b..8f41
On Wed, Jun 17, 2009 at 8:26 PM, Thomas Hellstrom 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 your drm-linus
From: Dave Airlie
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
---
drivers/gpu/drm/radeon/radeon_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon
On Fri, Jun 12, 2009 at 1:56 PM, Allen Akin wrote:
> On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote:
> | On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin wrote:
> | > On the other hand, if there's no mechanism for implicitly flushing the
> | > GL command stream o
On Wed, Jun 17, 2009 at 6:52 AM, Linus
Torvalds 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 f
On Wed, Jun 17, 2009 at 4:20 AM, Linus
Torvalds 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
>
> late_initcall(radeon_ini
On Mon, Jun 15, 2009 at 10:48 AM, Dave Airlie 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
>> us
On Mon, Jun 15, 2009 at 12:22 PM, Greg KH 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
>
s
ATOMBIOS - add support for looking up these values from the bios table
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
commit 771fe6b912fca54f03e8a72eb63058b582775362
Author: Jerome Glisse
Date: Fri Jun 5 14:42:42 2009 +0200
drm/radeon: introduce kernel modesetting
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 (the usual VGA DDC link) when there isn't a
> VGA monitor connected.
On Sun, 14 Jun 2009, Ryan Hope wrote:
> commit 85adafcf5d18e58c60d9fdbb718abe9149661736
> Author: Ryan Hope
> 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 b/drivers/gpu/drm/ttm/Ma
>
> > 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 e2c
hashtab header
Signed-off-by: Dave Airlie
commit f2cb5d86e1af175a9b210241800f03a447f92621
Author: Jerome Glisse
Date: Wed Apr 8 17:16:24 2009 +0200
drm: Export hash table functionality.
add exports so TTM module can use these functions.
Signed-off-by: Thomas
On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin wrote:
> On Fri, Jun 12, 2009 at 06:58:44AM +1000, Dave Airlie wrote:
> | All I've got is the glXMakeCurrent error to go on,
> | GLXBadCurrentWindow is generated if there are pending GL commands for
> | the previous
On Fri, Jun 12, 2009 at 5:33 AM, Allen Akin 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 glXMakeCu
2009/6/11 Kristian Høgsberg :
> On Wed, 2009-06-10 at 15:20 +1000, Dave Airlie wrote:
>> Hi Kristian et al
>>
>> So you wrote YALL for glxAllContexts and like all good linked list
>> re-implementations it didn't work :-)
>
> Well that's how we do data
> 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
> befor
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
> >
> > 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 c
On Fri, Jun 5, 2009 at 3:42 PM, Markus
Trippelsdorf 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.gi
-)
commit fc43896630a421321a19d7970bac27ac94e9d162
Author: Adam Jackson
Date: Thu Jun 4 10:20:34 2009 +1000
drm: ignore EDID with really tiny modes.
Some EDIDs lie and report tiny modes that aren't possible. Ignore
these modes.
Signed-off-by: Adam Jackson
Signed-off-by: Dave
From: Dave Airlie
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 driver.
Signed-off-by
> 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
> >
> > 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
ns(+), 32 deletions(-)
commit 42beefc0093725ec0f8cea340cc54c36ccaceea0
Author: Dave Airlie
Date: Wed May 6 09:04:52 2009 +1000
drm/r128: fix r128 ioremaps to use ioremap_wc.
This should allow r128 to start working again since PAT changes.
taken from F-11 kernel.
From: Dave Airlie
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
---
drivers/gpu/drm/drm_edid.c |8 +++-
1 files changed, 7 inser
On Tue, Mar 24, 2009 at 6:48 AM, Arjan van de Ven wrote:
> >From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00 2001
> From: Arjan van de Ven
> Date: Mon, 23 Mar 2009 13:37:20 -0700
> Subject: [PATCH] KMS: do a faster EDID
>
> for some outputs (like LVDS), the current delays in the
On Wed, Apr 22, 2009 at 11:48 AM, Shaohua Li wrote:
> drm_lock() does:
> for (;;) {
> __set_current_state(TASK_INTERRUPTIBLE);
> ...
> if (drm_lock_take(&master->lock, lock->context)) {
> < schedule() here
>
On Wed, Apr 22, 2009 at 6:52 PM, Dave Airlie wrote:
> 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.
From: Dave Airlie
duplicate the mode into fbcon storage, so when we free modes later
we don't just lose this.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_display.c |2 ++
drivers/gpu/drm/i915/intel_fb.c | 16
2 files changed, 14 insertions(
401 - 500 of 1512 matches
Mail list logo
