Radeon jittery post 2.6.35
On 03/15/11 22:08, Jerome Glisse wrote: > EDID failure could very well explain it, EDID retrieval seems to fails > on some GPU under some circonstance (when there is CPU load that > interfer with i2c timing i guess). Does the log have the edid failure > message when the tv is jittering ? Or is it the otherway around ? > > Cheers, > Jerome It seems to be related to whether the TV is on (on that HDMI source) or not. Mar 16 09:50:41 mynet kernel: [ 933.060281] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:53:46 mynet kernel: [ 1117.724206] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:54:47 mynet kernel: [ 1179.218109] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:54:57 mynet kernel: [ 1189.411883] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:55:32 mynet kernel: [ 1220.050871] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 20:27:51 mynet kernel: [ 952.693085] [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID Mar 16 21:30:21 mynet kernel: [ 2272.384410] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:32:44 mynet kernel: [ 2415.931947] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:40:45 mynet kernel: [ 2896.698214] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:45:05 mynet kernel: [ 3152.643541] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:53:00 mynet kernel: [ 3631.146133] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID The TV was off at about 10 AM this morning (the HTPC was on playing music) on a couple of hours in the afternoon showing the RS690 HDMI on at 20:50-22:00 NOT showing the RS690 HDMI Unfortunately I'm not sure what the TV's state was at 20:27:51 /A
[PATCH] drm: radeon: *_cs_packet_parse_vline() cleanup
Simplify the way the return value is set a number of times (mostly on
error).
Signed-off-by: Paul Bolle
---
Should a patch like this go through the trivial tree?
Documentation/SubmittingPatches wasn't entirely clear on that.
drivers/gpu/drm/radeon/evergreen_cs.c | 24
drivers/gpu/drm/radeon/r100.c | 16 ++--
drivers/gpu/drm/radeon/r600_cs.c | 25 +
3 files changed, 23 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 345a75a..d091e70 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -292,33 +292,28 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
if (wait_reg_mem.type != PACKET_TYPE3 ||
wait_reg_mem.opcode != PACKET3_WAIT_REG_MEM) {
DRM_ERROR("vline wait missing WAIT_REG_MEM segment\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
wait_reg_mem_info = radeon_get_ib_value(p, wait_reg_mem.idx + 1);
/* bit 4 is reg (0) or mem (1) */
if (wait_reg_mem_info & 0x10) {
DRM_ERROR("vline WAIT_REG_MEM waiting on MEM rather than
REG\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* waiting for value to be equal */
if ((wait_reg_mem_info & 0x7) != 0x3) {
DRM_ERROR("vline WAIT_REG_MEM function not equal\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if ((radeon_get_ib_value(p, wait_reg_mem.idx + 2) << 2) !=
EVERGREEN_VLINE_STATUS) {
DRM_ERROR("vline WAIT_REG_MEM bad reg\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if (radeon_get_ib_value(p, wait_reg_mem.idx + 5) !=
EVERGREEN_VLINE_STAT) {
DRM_ERROR("vline WAIT_REG_MEM bad bit mask\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* jump over the NOP */
@@ -336,8 +331,7 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
obj = drm_mode_object_find(p->rdev->ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
DRM_ERROR("cannot find crtc %d\n", crtc_id);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
crtc = obj_to_crtc(obj);
radeon_crtc = to_radeon_crtc(crtc);
@@ -362,12 +356,10 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
break;
default:
DRM_ERROR("unknown crtc reloc\n");
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
}
-out:
- return r;
+ return 0;
}
static int evergreen_packet0_check(struct radeon_cs_parser *p,
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index e372f9e..fcc23e4 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1205,14 +1205,12 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser
*p)
if (waitreloc.reg != RADEON_WAIT_UNTIL ||
waitreloc.count != 0) {
DRM_ERROR("vline wait had illegal wait until segment\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if (radeon_get_ib_value(p, waitreloc.idx + 1) !=
RADEON_WAIT_CRTC_VLINE) {
DRM_ERROR("vline wait had illegal wait until\n");
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* jump over the NOP */
@@ -1230,8 +1228,7 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
obj = drm_mode_object_find(p->rdev->ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
DRM_ERROR("cannot find crtc %d\n", crtc_id);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
crtc = obj_to_crtc(obj);
radeon_crtc = to_radeon_crtc(crtc);
@@ -1253,14 +1250,13 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser
*p)
break;
default:
DRM_ERROR("unknown crtc reloc\n");
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
ib[h_idx] = header;
ib[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
}
-out:
- return r;
+
+ return 0;
}
/**
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 153095f..5bfed09 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -687,33
i915/kms regression after 2.6.38-rc8
* Chris Wilson -- Wednesday 16 March 2011: > There's only one patch directly related to i915, so you could begin there. I'll try later. Was just too obvious for now. :-} > Useful information to include is a dmesg (particularly one with > drm.debug=0xe kernel parameters) and lspci OK, thanks for that info. Attached. > (though google says you have a gm45). I didn't look it up before, I just trusted the kernel with its "i915". But you are probably right, this Acer TravelMate 5735Z-452G32Mnss is supposed to have an "Intel Graphics Media Accelerator 4500MHD". m. -- next part -- A non-text attachment was scrubbed... Name: acer_5735z_i915_blackout.log.gz Type: application/x-gzip Size: 16849 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110316/a8c5ea49/attachment-0001.bin>
Radeon jittery post 2.6.35
On 03/15/11 22:46, Alex Deucher wrote: > Try booting with radeon.audio=0 on 2.6.38rc, some TVs have problems > with the hdmi packets we send by default. disabling audio will treat > the hdmi like dvi. > > Alex You seem to be on to something there. radeon.audio=0 removes what appears to be all of the jitter. I say "appear", because during my many test runs today, I've come across moments where my brain goes "wasn't what I just noticed on the TV something abnormal?" Both in fb mode (post KMS), and in X11. It's definetly improved from useless for family use, to perfectly ok though. Back when the radeonhd and radeon X drivers where on par, HDMIAudio where first introduced in the radeonhd driver. I recall testing HDMIAudio sucessfully then, but haven't used HDMUAudio since, and have switched to the radeon driver. Now when I check for HDMIAudio (with and without that command line option), I come up blank (all I see is an S/PDIF output). Isn't HDMIAudio supported on this card? I googled up a post suggesting that it was ported to R600+ cards in the radeon driver which would suggest that the RS690 driver doesn't support it(?). If at all possible, I'd like to have HDMIAudio operational as the HW supports it. A couple of data points: * Disabling HDMIAudio in the BIOS does not change anything (GRUB bad, KMS fixes it, etc..) * A pm-suspend cycle with the TV powered on is enough to turn a jitter-free session jittery (if I don't use radeon.audio=0) Any patches I can try (either to add support, or fixup what's currently broken w/ HDMIAudio?) -Anders
i915/kms regression after 2.6.38-rc8
Ccing some relevant people (you should have done this). On 03/16/2011 06:30 PM, Melchior FRANZ wrote: > On my i915 using Acer TravelMate 5735z I could run kernel 2.6.38-rc8 > with KMS. On 2.6.38 I get a black screen instead. In case anyone > cares, just tell me what information you need. (bisect result on > request, but I assume the experts know which patch caused it.) -- js
[PATCH] radeon: merge list_del()/list_add_tail() to list_move_tail()
Merge list_del() + list_add_tail() to list_move_tail().
Signed-off-by: Nicolas Kaiser
---
drivers/gpu/drm/radeon/radeon_fence.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 171b0b2..9e59868 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -60,8 +60,7 @@ int radeon_fence_emit(struct radeon_device *rdev, struct
radeon_fence *fence)
trace_radeon_fence_emit(rdev->ddev, fence->seq);
fence->emited = true;
- list_del(>list);
- list_add_tail(>list, >fence_drv.emited);
+ list_move_tail(>list, >fence_drv.emited);
write_unlock_irqrestore(>fence_drv.lock, irq_flags);
return 0;
}
@@ -121,8 +120,7 @@ static bool radeon_fence_poll_locked(struct radeon_device
*rdev)
i = n;
do {
n = i->prev;
- list_del(i);
- list_add_tail(i, >fence_drv.signaled);
+ list_move_tail(i, >fence_drv.signaled);
fence = list_entry(i, struct radeon_fence, list);
fence->signaled = true;
i = n;
--
1.7.3.4
Just for fun (a pleasant diversion from coding)
On LinkedIn, I belong to the "Linux Users" and "Linux Experts" lists. We were having a discussion on "Linux Users" as to why corporations aren't moving to Linux desktops. Someone suggested a name like "Doors" or "Skylights" for a Linux distro to point out how 'similar Linux was to Windows'. I countered that perhaps we should market Linux as the "Low-e OS" because Linux is a "more energy-efficient, greener approach to computing than traditional Windows." Well, we could change that to KDE or Gnome and get away without paying Microsoft - especially since they cannot trademark the word "Windows" (although they did try). Okay, just a thought that might have amused you for a second. I'll let you folks get back to work now. Lots of ground to cover in making Linux worthy for most desktop computers. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110316/a7528060/attachment.html>
[Bug 35194] [r600g] Evergreen - failed to map bo
https://bugs.freedesktop.org/show_bug.cgi?id=35194 --- Comment #2 from Jussi Saarinen 2011-03-16 14:30:17 PDT --- (In reply to comment #1) > (In reply to comment #0) > > > > The game "Back to the Future: the game" crashes at many points with > > the message: > > > > radeon_bo_fixed_map failed to map bo > > EE radeon_bo.c:120 radeon_bo - failed to map bo > > > > I also have run into this same bug when running 3DMark 2001 SE in wine. > Sorry, I forgot to add this: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV740 OpenGL version string: 2.1 Mesa 7.10.1 OpenGL shading language version string: 1.20 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35194] [r600g] Evergreen - failed to map bo
https://bugs.freedesktop.org/show_bug.cgi?id=35194 --- Comment #1 from Jussi Saarinen 2011-03-16 14:28:23 PDT --- (In reply to comment #0) > > The game "Back to the Future: the game" crashes at many points with > the message: > > radeon_bo_fixed_map failed to map bo > EE radeon_bo.c:120 radeon_bo - failed to map bo > I also have run into this same bug when running 3DMark 2001 SE in wine. Motherboard: Gigabyte MA790XT-UD4P Chipset: North Bridge AMD 790X / South Bridge AMD SB750 Processor: AMD Phenom II X3 720 Display adapter: Club 3D HD 4770 512MB (RV740) Display: HP Pavilion f1940 (1280x1024) Distribution: ArchLinux x86-64 (rolling release, up to date) Installed packages: kernel: 2.6.37.4-1 xorg-server: 1.9.4.901-1 xf86-video-ati: 6.14.0-2 xf86-input-evdev: 2.6.0-2 libdrm: 2.4.23-2 mesa: 7.10.1-1 ati-dri: 7.10.1-1 libgl: 7.10.1-1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] ACPI/Intel: Rework Opregion support
> > Read the changelog and thread on the patch that disabled this logic, the > failure (or at least inconsistent behaviour with the expectations of the > HP BIOS authors) appears to be in how we initialise ACPI on the HP > machines that causes the initial value of lid state to be incorrect. Since > one of the laptops that Dave tests drm-next on is a HP, he was bitten by > the bug and temporarily (we hope) disabled the logic. Or else once again, > we will continue to light up the panel on a closed laptop. Yeah I've no idea if the ACPI implementation is wrong or not :-( I suspects its the BIOS actually, the BIOS wants _INI called before _REG. The ACPI video device isn't in the EC address space, so it ends up in the default region address space. So we'd really need to know how Windows sets up the _REG calls for the non-EC spaces and where its calls the _INI methods wrt to that. The thing is I think the actual ACPI lid device is fine, its just opregion isn't updated until we get an event later. Dave.
[Bug 35367] New: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes
https://bugs.freedesktop.org/show_bug.cgi?id=35367 Summary: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: lists at andyfurniss.entadsl.com rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. kernel d-r-t, git ddx with tiling enabled in xorg.conf. Does not affect my PCIE RV790 box. Mesa demo lodbias does not work normally since commit bdf103894026238c7e896eccb995b141161bfb70 Author: Marek Olk Date: Tue Mar 8 00:28:33 2011 +0100 st/mesa: remove unnecessary flushes The framebuffer cache flush should be implicit when calling set_framebuffer_state. There is no need to flush the command stream either. It disappears to black too quickly between 1.5 and 2.5 and the image is corrupt rather than blurring gradually during this time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=34534 --- Comment #6 from Peter Hercek 2011-03-16 12:15:23 PDT --- Adding radeon.disp_priority=2 to the kernel command line did not help. It looks the same. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] ACPI/Intel: Rework Opregion support
On Wed, Mar 16, 2011 at 2:26 AM, Indan Zupancic wrote: > On Wed, March 16, 2011 03:17, Alex Deucher wrote: >> It's not HDCP, encrypted bluray is the main issue. ?And while >> there are hacks for bluray around already, contractual obligations >> don't care whether existing hacks are available or not. > > So the contract says to keep it secret, not to make it secure. > Wonderful. > >> Without going into detail, they are very intertwined. ?The hw was >> designed long before we planned to support open source as much as we >> are now. ?Fortunately, we have been working with our hw teams to make >> future UVD implementations take the open source driver into account. > > It has nothing to do with open source, if you need to trust the > driver you're already screwed from a security point of view. > >>> >>> It would be nice to have an open source Fusion based media player/ >>> IPTV decoder, but I guess that's hoping for too much. >>> >>> I understand if AMD/ATI wants to keep its 3D driver secret, but >>> hardware video decoding?! If you have to keep it secret it means >>> shortcuts were taken and it's all insecure anyway. That if it gets >>> broken the Open source driver gets blamed is ridiculous and more >>> politics than anything else. >> >> We don't keep the 3D engine secret. ?Most of the code we've written >> and specs we've released are 3D engine stuff. ?Fortunately 3D is less >> tied up in drm compared to video. > > That's not what I said, I was talking about the driver. There are always > details not documented, and plenty of optimisation tricks that make the > hardware go fast. Just compare the performance of the Windows driver > with the open source Linux driver. It doesn't give the impression that > AMD is putting much effort in the open source drivers or that it takes > it seriously. People are over thinking and believe secret recipes is what actually make driver fast. From my experience i would say that it's just the open source driver stack that is limiting performances, mostly because it require a huge amount of work. I believe there is several hundred of engineers working on the closed driver just to optimize it and improve it while the open source stacks have couple dozen and not all working on same hw but working on AMD, Intel, NVidia. You can check that with some of the test that were in r600 demo, iirc correctly with direct hw access perf were close to theoretical hw performance. Cheers, Jerome
[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=34534 --- Comment #5 from Alex Deucher 2011-03-16 09:50:19 PDT --- Does booting with radeon.disp_priority=2 help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
On Tue, 2011-03-15 at 13:31 +0100, Julien Cristau wrote: > On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote: > > > [Digression: what is upowerd doing reading those power hungry files?] > > > Apparently, checking "docked" status every 30 seconds, by reading the > status of drm outputs. Where "docked" means "more than one output > connected". Yes, it's silly. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 > Its also now disabled by default upstream. I think he was using an 965 or GM45 laptop that seemed to not report output changes properly. Dave.
[PATCH] ACPI/Intel: Rework Opregion support
On Wed, March 16, 2011 03:17, Alex Deucher wrote: > It's not HDCP, encrypted bluray is the main issue. And while > there are hacks for bluray around already, contractual obligations > don't care whether existing hacks are available or not. So the contract says to keep it secret, not to make it secure. Wonderful. > Without going into detail, they are very intertwined. The hw was > designed long before we planned to support open source as much as we > are now. Fortunately, we have been working with our hw teams to make > future UVD implementations take the open source driver into account. It has nothing to do with open source, if you need to trust the driver you're already screwed from a security point of view. >> >> It would be nice to have an open source Fusion based media player/ >> IPTV decoder, but I guess that's hoping for too much. >> >> I understand if AMD/ATI wants to keep its 3D driver secret, but >> hardware video decoding?! If you have to keep it secret it means >> shortcuts were taken and it's all insecure anyway. That if it gets >> broken the Open source driver gets blamed is ridiculous and more >> politics than anything else. > > We don't keep the 3D engine secret. Most of the code we've written > and specs we've released are 3D engine stuff. Fortunately 3D is less > tied up in drm compared to video. That's not what I said, I was talking about the driver. There are always details not documented, and plenty of optimisation tricks that make the hardware go fast. Just compare the performance of the Windows driver with the open source Linux driver. It doesn't give the impression that AMD is putting much effort in the open source drivers or that it takes it seriously. > It's all about mitigating risk. > Imagine you run a company and someone asks you this: "Can we release > programming info for a part of our chip to support 2-3% of our market > that may put at risk 90% of our market?" What would you do? The > reason the review is taking so long is that we want to be real sure > that the risk is safe. That's what AMD doesn't get, it only has 2-3% because its drivers aren't great. If AMD had good performing open source drivers they would not only get a bigger market share, their hardware would also be used more for embedded kind of things like decoders, media boxes and who knows what. The risk you're talking about is how to best hide that the hardware is totally insecure as far as the drm goes. Well no, you wouldn't want to make that public indeed. It's probably the crazy drm's that more or less forced AMD to implement it this way, but still. >> >> This is getting more and more off-topic though, sorry for the noise. > > Agreed. Last post from me about this... Greetings, Indan
[PATCH] ACPI/Intel: Rework Opregion support
On Tue, March 15, 2011 17:06, Alex Deucher wrote: > On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote: >> They don't give their Linux devs any Fusion hardware, nor do they >> open the UVD spec, but at least they release info like this. > > They do give us fusion hw; before launch even. That's why we had > Linux support before hw was available publicly. My board just > happened to get bricked recently during a failed bios upgrade. > A new one is on the way. Okay, that's better than I thought. I remember a dev saying that no one had Fusion hardware, that's where I got this notion from. > Also we are looking into a potential release of > UVD, but unfortunately, our decode hw is intimately tied in with > our drm implementation and if someone managed to use the released > information to compromise the drm in our windows driver it would very > negatively impact our ability to sell into the windows market and > would probably get the open source graphics initiative shut down. Are you talking about HDCP or something else? Because the HDCP master key already leaked, so the whole security aspect of it is already a joke, open source UVD won't make any difference. Basically you're telling me that I or someone else should reverse engineer de Catalyst driver and break all drm before you consider opening up UVD? I'd argue that opening up UVD now is more secure because it takes away the only morivation to break UVD's drm. Alternatively, can't you open up UVD spec except the drm bits, so people can at least write their own UVD driver to watch unencrypted data? It would be nice to have an open source Fusion based media player/ IPTV decoder, but I guess that's hoping for too much. I understand if AMD/ATI wants to keep its 3D driver secret, but hardware video decoding?! If you have to keep it secret it means shortcuts were taken and it's all insecure anyway. That if it gets broken the Open source driver gets blamed is ridiculous and more politics than anything else. This is getting more and more off-topic though, sorry for the noise. Greetings, Indan
[PATCH] drm: Retry i2c transfer of EDID block after failure
On Tue, 2011-03-15 at 11:04 +, Chris Wilson wrote: > Usually EDID retrieval is fine. However, sometimes, especially when the > machine is loaded, it fails, but succeeds after a few retries. > > Based on a patch by Michael Buesch. > > Reported-by: Michael Buesch > Signed-off-by: Chris Wilson > --- I'm currently testing this. It boots, but to see if it fixes the issue, I'll have to run some more tests. Note that this patch is subject to .37-table and probably earlier releases, too. -- Greetings, Michael.
Re: [PATCH] ACPI/Intel: Rework Opregion support
On Wed, Mar 16, 2011 at 2:26 AM, Indan Zupancic in...@nul.nu wrote: On Wed, March 16, 2011 03:17, Alex Deucher wrote: It's not HDCP, encrypted bluray is the main issue. And while there are hacks for bluray around already, contractual obligations don't care whether existing hacks are available or not. So the contract says to keep it secret, not to make it secure. Wonderful. Without going into detail, they are very intertwined. The hw was designed long before we planned to support open source as much as we are now. Fortunately, we have been working with our hw teams to make future UVD implementations take the open source driver into account. It has nothing to do with open source, if you need to trust the driver you're already screwed from a security point of view. It would be nice to have an open source Fusion based media player/ IPTV decoder, but I guess that's hoping for too much. I understand if AMD/ATI wants to keep its 3D driver secret, but hardware video decoding?! If you have to keep it secret it means shortcuts were taken and it's all insecure anyway. That if it gets broken the Open source driver gets blamed is ridiculous and more politics than anything else. We don't keep the 3D engine secret. Most of the code we've written and specs we've released are 3D engine stuff. Fortunately 3D is less tied up in drm compared to video. That's not what I said, I was talking about the driver. There are always details not documented, and plenty of optimisation tricks that make the hardware go fast. Just compare the performance of the Windows driver with the open source Linux driver. It doesn't give the impression that AMD is putting much effort in the open source drivers or that it takes it seriously. People are over thinking and believe secret recipes is what actually make driver fast. From my experience i would say that it's just the open source driver stack that is limiting performances, mostly because it require a huge amount of work. I believe there is several hundred of engineers working on the closed driver just to optimize it and improve it while the open source stacks have couple dozen and not all working on same hw but working on AMD, Intel, NVidia. You can check that with some of the test that were in r600 demo, iirc correctly with direct hw access perf were close to theoretical hw performance. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: merge list_del()/list_add_tail() to list_move_tail()
Merge list_del() + list_add_tail() to list_move_tail().
Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
drivers/gpu/drm/radeon/radeon_fence.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 171b0b2..9e59868 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -60,8 +60,7 @@ int radeon_fence_emit(struct radeon_device *rdev, struct
radeon_fence *fence)
trace_radeon_fence_emit(rdev-ddev, fence-seq);
fence-emited = true;
- list_del(fence-list);
- list_add_tail(fence-list, rdev-fence_drv.emited);
+ list_move_tail(fence-list, rdev-fence_drv.emited);
write_unlock_irqrestore(rdev-fence_drv.lock, irq_flags);
return 0;
}
@@ -121,8 +120,7 @@ static bool radeon_fence_poll_locked(struct radeon_device
*rdev)
i = n;
do {
n = i-prev;
- list_del(i);
- list_add_tail(i, rdev-fence_drv.signaled);
+ list_move_tail(i, rdev-fence_drv.signaled);
fence = list_entry(i, struct radeon_fence, list);
fence-signaled = true;
i = n;
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34534] resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=34534 --- Comment #6 from Peter Hercek pher...@gmail.com 2011-03-16 12:15:23 PDT --- Adding radeon.disp_priority=2 to the kernel command line did not help. It looks the same. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms regression after 2.6.38-rc8
Ccing some relevant people (you should have done this). On 03/16/2011 06:30 PM, Melchior FRANZ wrote: On my i915 using Acer TravelMate 5735z I could run kernel 2.6.38-rc8 with KMS. On 2.6.38 I get a black screen instead. In case anyone cares, just tell me what information you need. (bisect result on request, but I assume the experts know which patch caused it.) -- js ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35367] New: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes
https://bugs.freedesktop.org/show_bug.cgi?id=35367 Summary: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: li...@andyfurniss.entadsl.com rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. kernel d-r-t, git ddx with tiling enabled in xorg.conf. Does not affect my PCIE RV790 box. Mesa demo lodbias does not work normally since commit bdf103894026238c7e896eccb995b141161bfb70 Author: Marek Olšák mar...@gmail.com Date: Tue Mar 8 00:28:33 2011 +0100 st/mesa: remove unnecessary flushes The framebuffer cache flush should be implicit when calling set_framebuffer_state. There is no need to flush the command stream either. It disappears to black too quickly between 1.5 and 2.5 and the image is corrupt rather than blurring gradually during this time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Just for fun (a pleasant diversion from coding)
On LinkedIn, I belong to the Linux Users and Linux Experts lists. We were having a discussion on Linux Users as to why corporations aren't moving to Linux desktops. Someone suggested a name like Doors or Skylights for a Linux distro to point out how 'similar Linux was to Windows'. I countered that perhaps we should market Linux as the Low-e OS because Linux is a more energy-efficient, greener approach to computing than traditional Windows. Well, we could change that to KDE or Gnome and get away without paying Microsoft - especially since they cannot trademark the word Windows (although they did try). Okay, just a thought that might have amused you for a second. I'll let you folks get back to work now. Lots of ground to cover in making Linux worthy for most desktop computers. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: radeon: *_cs_packet_parse_vline() cleanup
Simplify the way the return value is set a number of times (mostly on
error).
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Should a patch like this go through the trivial tree?
Documentation/SubmittingPatches wasn't entirely clear on that.
drivers/gpu/drm/radeon/evergreen_cs.c | 24
drivers/gpu/drm/radeon/r100.c | 16 ++--
drivers/gpu/drm/radeon/r600_cs.c | 25 +
3 files changed, 23 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 345a75a..d091e70 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -292,33 +292,28 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
if (wait_reg_mem.type != PACKET_TYPE3 ||
wait_reg_mem.opcode != PACKET3_WAIT_REG_MEM) {
DRM_ERROR(vline wait missing WAIT_REG_MEM segment\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
wait_reg_mem_info = radeon_get_ib_value(p, wait_reg_mem.idx + 1);
/* bit 4 is reg (0) or mem (1) */
if (wait_reg_mem_info 0x10) {
DRM_ERROR(vline WAIT_REG_MEM waiting on MEM rather than
REG\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* waiting for value to be equal */
if ((wait_reg_mem_info 0x7) != 0x3) {
DRM_ERROR(vline WAIT_REG_MEM function not equal\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if ((radeon_get_ib_value(p, wait_reg_mem.idx + 2) 2) !=
EVERGREEN_VLINE_STATUS) {
DRM_ERROR(vline WAIT_REG_MEM bad reg\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if (radeon_get_ib_value(p, wait_reg_mem.idx + 5) !=
EVERGREEN_VLINE_STAT) {
DRM_ERROR(vline WAIT_REG_MEM bad bit mask\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* jump over the NOP */
@@ -336,8 +331,7 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
obj = drm_mode_object_find(p-rdev-ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
DRM_ERROR(cannot find crtc %d\n, crtc_id);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
crtc = obj_to_crtc(obj);
radeon_crtc = to_radeon_crtc(crtc);
@@ -362,12 +356,10 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
break;
default:
DRM_ERROR(unknown crtc reloc\n);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
}
-out:
- return r;
+ return 0;
}
static int evergreen_packet0_check(struct radeon_cs_parser *p,
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index e372f9e..fcc23e4 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1205,14 +1205,12 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser
*p)
if (waitreloc.reg != RADEON_WAIT_UNTIL ||
waitreloc.count != 0) {
DRM_ERROR(vline wait had illegal wait until segment\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if (radeon_get_ib_value(p, waitreloc.idx + 1) !=
RADEON_WAIT_CRTC_VLINE) {
DRM_ERROR(vline wait had illegal wait until\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* jump over the NOP */
@@ -1230,8 +1228,7 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
obj = drm_mode_object_find(p-rdev-ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
DRM_ERROR(cannot find crtc %d\n, crtc_id);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
crtc = obj_to_crtc(obj);
radeon_crtc = to_radeon_crtc(crtc);
@@ -1253,14 +1250,13 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser
*p)
break;
default:
DRM_ERROR(unknown crtc reloc\n);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
ib[h_idx] = header;
ib[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
}
-out:
- return r;
+
+ return 0;
}
/**
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 153095f..5bfed09 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -687,33 +687,28 @@
Re: i915/kms regression after 2.6.38-rc8
* Chris Wilson -- Wednesday 16 March 2011: There's only one patch directly related to i915, so you could begin there. I'll try later. Was just too obvious for now. :-} Useful information to include is a dmesg (particularly one with drm.debug=0xe kernel parameters) and lspci OK, thanks for that info. Attached. (though google says you have a gm45). I didn't look it up before, I just trusted the kernel with its i915. But you are probably right, this Acer TravelMate 5735Z-452G32Mnss is supposed to have an Intel Graphics Media Accelerator 4500MHD. m. acer_5735z_i915_blackout.log.gz Description: GNU Zip compressed data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35194] [r600g] Evergreen - failed to map bo
https://bugs.freedesktop.org/show_bug.cgi?id=35194 --- Comment #1 from Jussi Saarinen juss...@mbnet.fi 2011-03-16 14:28:23 PDT --- (In reply to comment #0) The game Back to the Future: the game crashes at many points with the message: radeon_bo_fixed_map failed to map bo EE radeon_bo.c:120 radeon_bo - failed to map bo I also have run into this same bug when running 3DMark 2001 SE in wine. Motherboard: Gigabyte MA790XT-UD4P Chipset: North Bridge AMD 790X / South Bridge AMD SB750 Processor: AMD Phenom II X3 720 Display adapter: Club 3D HD 4770 512MB (RV740) Display: HP Pavilion f1940 (1280x1024) Distribution: ArchLinux x86-64 (rolling release, up to date) Installed packages: kernel: 2.6.37.4-1 xorg-server: 1.9.4.901-1 xf86-video-ati: 6.14.0-2 xf86-input-evdev: 2.6.0-2 libdrm: 2.4.23-2 mesa: 7.10.1-1 ati-dri: 7.10.1-1 libgl: 7.10.1-1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35194] [r600g] Evergreen - failed to map bo
https://bugs.freedesktop.org/show_bug.cgi?id=35194 --- Comment #2 from Jussi Saarinen juss...@mbnet.fi 2011-03-16 14:30:17 PDT --- (In reply to comment #1) (In reply to comment #0) The game Back to the Future: the game crashes at many points with the message: radeon_bo_fixed_map failed to map bo EE radeon_bo.c:120 radeon_bo - failed to map bo I also have run into this same bug when running 3DMark 2001 SE in wine. Sorry, I forgot to add this: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV740 OpenGL version string: 2.1 Mesa 7.10.1 OpenGL shading language version string: 1.20 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon jittery post 2.6.35
On 03/15/11 22:08, Jerome Glisse wrote: EDID failure could very well explain it, EDID retrieval seems to fails on some GPU under some circonstance (when there is CPU load that interfer with i2c timing i guess). Does the log have the edid failure message when the tv is jittering ? Or is it the otherway around ? Cheers, Jerome It seems to be related to whether the TV is on (on that HDMI source) or not. Mar 16 09:50:41 mynet kernel: [ 933.060281] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:53:46 mynet kernel: [ 1117.724206] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:54:47 mynet kernel: [ 1179.218109] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:54:57 mynet kernel: [ 1189.411883] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 09:55:32 mynet kernel: [ 1220.050871] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 20:27:51 mynet kernel: [ 952.693085] [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID Mar 16 21:30:21 mynet kernel: [ 2272.384410] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:32:44 mynet kernel: [ 2415.931947] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:40:45 mynet kernel: [ 2896.698214] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:45:05 mynet kernel: [ 3152.643541] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Mar 16 21:53:00 mynet kernel: [ 3631.146133] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID The TV was off at about 10 AM this morning (the HTPC was on playing music) on a couple of hours in the afternoon showing the RS690 HDMI on at 20:50-22:00 NOT showing the RS690 HDMI Unfortunately I'm not sure what the TV's state was at 20:27:51 /A ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37
https://bugzilla.kernel.org/show_bug.cgi?id=30832 --- Comment #4 from Alex Deucher alexdeuc...@gmail.com 2011-03-16 23:16:33 --- Created an attachment (id=50992) -- (https://bugzilla.kernel.org/attachment.cgi?id=50992) possible fix Does this patch help? Both pal and ntsc work for me, but my monitor is pretty forgiving. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm next tree
Hi Linus, since I see drm named in two other pull threads (staging + bkl) I suppose I should send my pull req. Highlights: core: drop i830 driver and BKL, add support to drm core to allow USB drm drivers, generic unaccelerated buffer create/map fns for simple fbdev applications (like plymouth), generic drm capabilities ioctl. ttm: add support for Xen Dom0 radeon: cayman GPU support (fw is in linux-firmware), r600 tiling + predication support nouveau: pageflipping, Z compression i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. Dave. The following changes since commit 5359533801e3dd3abca5b7d3d985b0b33fd9fe8b: drm/radeon: fix problem with changing active VRAM size. (v2) (2011-03-14 12:51:04 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next Alex Deucher (17): drm/radeon/kms: add cayman chip family drm/radeon/kms: add ucode loader for cayman drm/radeon/kms: add gpu_init function for cayman drm/radeon/kms: add support for cayman gart setup drm/radeon/kms: add support for CP setup on cayman asics drm/radeon/kms: add support for cayman irqs drm/radeon/kms: add cayman asic reset support drm/radeon/kms/cayman: add asic init/startup/fini/suspend/resume functions drm/radeon/kms: add cayman safe regs drm/radeon/kms: add radeon_asic entry for cayman drm/radeon/kms: add cayman CS check support drm/radeon/kms: additional default context regs for cayman drm/radeon/kms/cayman: always set certain VGT regs at CP init drm/radeon/kms: cayman/evergreen cs checker updates drm/radeon/kms: add cayman pci ids drm/radeon/kms: allow max clock of 340 Mhz on hdmi 1.3+ drm/radeon/kms: fix typo in atom overscan setup Alexander Lam (1): drm/i915: allow 945 to control self refresh (CxSR) automatically Arnd Bergmann (2): drm: remove i830 driver drm/i810: remove the BKL Ben Skeggs (46): drm/ttm: call driver move_notify() when doing system-tt bo moves Merge remote-tracking branch 'airlied/drm-core-next' into drm-nouveau-next drm/nouveau: move + rename some stuff in nouveau_sgdma.c drm/nouveau: introduce new gart type, and name _SGDMA more appropriately drm/nv40: implement support for on-chip PCIEGART drm/nv40: support for 39-bit dma addresses on native PCIE chipsets drm/nv84: switch to new-style semaphores drm/nvc0/pfifo: semi-handle a couple more irqs drm/nvc0: implement semaphores for inter-channel sync drm/nouveau: silence some compiler warnings drm/nv50: 0x50 needs semaphore yields too drm/nv84: use vm offsets for semaphores drm/nv50: drop explicit yields in favour of smaller PFIFO timeslice drm/nv50-nvc0: move non-sharable display state into private structure drm/nv50-nvc0: rename disp-evo to disp-master drm/nv50-nvc0: disp channels have fixed purposes, don't allocate them drm/nv50-nvc0: fix ramht entries for multiple evo channels drm/nv50-nvc0: tidy evo init failure paths drm/nv50-nvc0: include nv50_display in evo debugging drm/nouveau: make vbios parser runnable from an atomic context drm/nv50-nvc0: switch to tasklet for display isr bh drm/nv50-nvc0: request and wait on notification of modeset completion drm/nv50-nvc0: tidy evo object creation some more drm/nv50-nvc0: precalculate some fb state when creating them drm/nv50-nvc0: initialise display sync channels drm/nv50-nvc0: activate/update ds channel's framebuffer on modesets drm/nv50: enable page flipping drm/nvc0: support for sw methods + enable page flipping drm/nouveau/vbios: parse more gpio tag bits from connector table drm/nouveau: remove no_vm/mappable flags from nouveau_bo drm/nv50: simplify bo moves now that they're all through the vm drm/nouveau: pass domain rather than ttm flags to gem_new() drm/nv50-nvc0: restrict memtype to those specified at creation time drm/nv50-nvc0: move vm bind/unbind to move_notify hook drm/nv50-nvc0: unmap buffers from the vm when they're evicted drm/nvc0: allow creation of buffers with any non-compressed memtype drm/nouveau: rename nouveau_vram to nouveau_mem drm/nv50-nvc0: delay GART binding until move_notify time drm/nv50: support for compression drm/nv50: flesh out ZCULL init and match nvidia on later chipsets drm/core: add ioctl to query device/driver capabilities drm/nvc0: remove vm hack forcing large/small pages to not share a PDE drm/nouveau: add nouveau_enum_find() util function drm/nv50: decode vm faults some more drm/nv50: check for vm traps on every gr irq drm/nv40: attempt to reserve just enough vram for all 32 channels Benjamin Franzke (1): drm/nouveau: Fix pageflip event Bryan Freed (2): drm/i915: Honour
