[Bug 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #3 from Pavel Ondračka 2011-02-09 00:34:57 PST --- Created an attachment (id=43151) --> (https://bugs.freedesktop.org/attachment.cgi?id=43151) output of RADEON_DEBUG=fp,vp with mesa master -- 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 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #4 from Pavel Ondračka 2011-02-09 00:35:42 PST --- Created an attachment (id=43152) --> (https://bugs.freedesktop.org/attachment.cgi?id=43152) output of RADEON_DEBUG=fp,vp with mesa master and 8f32c6cfc6503dd234f09fb06941803866c23c65 reverted -- 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 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #5 from Tom Stellard 2011-02-09 01:46:08 PST --- Created an attachment (id=43154) View: https://bugs.freedesktop.org/attachment.cgi?id=43154 Review: https://bugs.freedesktop.org/review?bug=34030&attachment=43154 Possible Fix This patch should be applied to the master branch. Does it fix the problem? If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied. -- 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 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #6 from Pavel Ondračka 2011-02-09 02:05:40 PST --- (In reply to comment #5) > Created an attachment (id=43154) View: https://bugs.freedesktop.org/attachment.cgi?id=43154 Review: https://bugs.freedesktop.org/review?bug=34030&attachment=43154 > Possible Fix > > This patch should be applied to the master branch. Does it fix the problem? > If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied. Yes, this patch fixes the problem. Thank you. -- 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 27524] linux-2.6.33.2 radeondrm_fb, rv350, garbled console on PowerBook G4
https://bugs.freedesktop.org/show_bug.cgi?id=27524 --- Comment #14 from Michel Dänzer 2011-02-09 02:09:54 PST --- This is working for me in recent kernels. -- 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 27517] KMS breaks 3D on R200
https://bugs.freedesktop.org/show_bug.cgi?id=27517 --- Comment #7 from Michel Dänzer 2011-02-09 02:14:36 PST --- (In reply to comment #6) > I am also affected by this. It is caused by incorrect fake texture handling in > CS checker or something. More and a possible "fix" (it just disables texture > checking) here: https://bugs.freedesktop.org/show_bug.cgi?id=25544 That's fixed. Is there still a problem here? -- 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 27525] linux-2.6.33.2 radeon, rv350, glxgears locks system
https://bugs.freedesktop.org/show_bug.cgi?id=27525 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Michel Dänzer 2011-02-09 02:25:07 PST --- *** This bug has been marked as a duplicate of bug 28402 *** -- 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 28402] random radeon/kms/drm related freezes with kernel 2.6.34
https://bugs.freedesktop.org/show_bug.cgi?id=28402 Michel Dänzer changed: What|Removed |Added CC||jerem...@freedesktop.org --- Comment #99 from Michel Dänzer 2011-02-09 02:25:07 PST --- *** Bug 27525 has been marked as a duplicate of this bug. *** -- 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 23745] x11-drivers/xf86-video-ati: No DRI and wrong colors for OpenGL (Pegasos II + Radeon 9000)
https://bugs.freedesktop.org/show_bug.cgi?id=23745 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Michel Dänzer 2011-02-09 02:29:18 PST --- This should be fixed with current versions of the relevant components, at least with KMS enabled. -- 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 32888] [r600g] GL_EXT_texture_compression_s3tc support
https://bugs.freedesktop.org/show_bug.cgi?id=32888 --- Comment #4 from Tobias Jakobi 2011-02-09 02:39:22 PST --- Created an attachment (id=43156) View: https://bugs.freedesktop.org/attachment.cgi?id=43156 Review: https://bugs.freedesktop.org/review?bug=32888&attachment=43156 Disable CS check for textures To quote Keith: Seems to sort-of work for non-mipmapped textures. Tested with quake4 (where s3tc is mandatory) and FEAR. Like expected all mipmap levels are broken, which results in funny colors. Use GL_LINEAR as r_texturemode in quake-based engines to get an idea how it could look like :) -- 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 33957] G4 Mac mini Radeon 9200: Broken 3d-Acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=33957 Michel Dänzer changed: What|Removed |Added Product|xorg|Mesa Version|7.5 |unspecified Component|Driver/Radeon |Drivers/DRI/r200 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | --- Comment #5 from Michel Dänzer 2011-02-09 02:57:40 PST --- (In reply to comment #5) > Disabling the kms (radeon.modeset=0) with the forums help, it was possible to > fix a compatibility problem between radeonfb and the kms drm. If you enable KMS but disable radeonfb instead, does that work any better? > - Visual effects for gnome session -> blue coloration, windows remain visually > after being closed > - Tuxkart -> blue coloration, sound and graphic stutter > - Warsow -> blue coloration, sound and graphic stutter These are probably 3D driver issues, reassigning. -- 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: Intel i915 freeze on latest git
On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote: > Hmm, that was the only change I could spot between the two patches. Care > to disable that function and see what happens? [i.e. put a return before > we write anything to the ring] Ping? I've tried the -rc4 (there are some drm updates) but I get the same hang. Bye Francesco ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34088] New: Update autotools configuration
https://bugs.freedesktop.org/show_bug.cgi?id=34088 Summary: Update autotools configuration Product: DRI Version: XOrg CVS Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: medium Component: libdrm AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jjar...@gnome.org Created an attachment (id=43160) --> (https://bugs.freedesktop.org/attachment.cgi?id=43160) Update autotools config Replace some deprecated autoconf macros and use the new libtool I also changed the direction to report bugs -- 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 support state in libkms
> I was looking at the radeon support state in libkms and I found out the > following patch was proposed back in September, but never commented nor > merged. The patch was submitted by nobled. > > http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html > > I applied it on the latest drm git version without any problem and > compilation looks fine. Is there a reason preventing it from being merged? > > If it needs testing, make your suggestion, I'll gladly make my best to > test it. Good point. Is KMS dead? Anyone? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: add usb framework
> This adds an initial framework to plug USB graphics devices > into the drm/kms subsystem. > > I've started writing a displaylink driver using this interface. I own this hardware. Do you have early drivers that I could test. I assume also you will be cleaning up the edid code since it is very dependent on i2c code. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
The LVDS code ignores any connector for which it cannot find a fixed
mode (through an EDID, vBIOS tables or the current active mode). Some
platforms may include an LVDS header on the board and this may then be
partnered with a panel without an EDID. This results in us ignoring the
connector and not lighting up the panel.
Under UMS, it was possible to override this by specifying the mode
through the Xorg.conf. For KMS, one specifies the modeline through the
video= parameter. So we need to include this user modeline when checking
for panel fixed modes.
The machinery to parse the video= modes and generate the appropriate
drm_mode is already built into drm_fb_herlper and so we can just
extract, move it to the core and also use it from intel_lvds.c
Reported-by: Oliver Seitz
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 207 +++--
drivers/gpu/drm/drm_modes.c | 154 +++
drivers/gpu/drm/i915/intel_lvds.c | 17 +++
include/drm/drmP.h| 25 +
include/drm/drm_fb_helper.h | 16 +---
5 files changed, 233 insertions(+), 186 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6977a1c..5a80412 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -70,174 +70,50 @@ fail:
}
EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
-/**
- * drm_fb_helper_connector_parse_command_line - parse command line for
connector
- * @connector - connector to parse line for
- * @mode_option - per connector mode option
- *
- * This parses the connector specific then generic command lines for
- * modes and options to configure the connector.
- *
- * This uses the same parameters as the fb modedb.c, except for extra
- * x[M][R][-][@][i][m][eDd]
- *
- * enable/enable Digital/disable bit at the end
- */
-static bool drm_fb_helper_connector_parse_command_line(struct
drm_fb_helper_connector *fb_helper_conn,
- const char *mode_option)
-{
- const char *name;
- unsigned int namelen;
- int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
- unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
- int i;
- enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
- struct drm_fb_helper_cmdline_mode *cmdline_mode;
- struct drm_connector *connector;
-
- if (!fb_helper_conn)
- return false;
- connector = fb_helper_conn->connector;
-
- cmdline_mode = &fb_helper_conn->cmdline_mode;
- if (!mode_option)
- mode_option = fb_mode_option;
-
- if (!mode_option) {
- cmdline_mode->specified = false;
- return false;
- }
-
- name = mode_option;
- namelen = strlen(name);
- for (i = namelen-1; i >= 0; i--) {
- switch (name[i]) {
- case '@':
- namelen = i;
- if (!refresh_specified && !bpp_specified &&
- !yres_specified) {
- refresh = simple_strtol(&name[i+1], NULL, 10);
- refresh_specified = 1;
- if (cvt || rb)
- cvt = 0;
- } else
- goto done;
- break;
- case '-':
- namelen = i;
- if (!bpp_specified && !yres_specified) {
- bpp = simple_strtol(&name[i+1], NULL, 10);
- bpp_specified = 1;
- if (cvt || rb)
- cvt = 0;
- } else
- goto done;
- break;
- case 'x':
- if (!yres_specified) {
- yres = simple_strtol(&name[i+1], NULL, 10);
- yres_specified = 1;
- } else
- goto done;
- case '0' ... '9':
- break;
- case 'M':
- if (!yres_specified)
- cvt = 1;
- break;
- case 'R':
- if (cvt)
- rb = 1;
- break;
- case 'm':
- if (!cvt)
- margins = 1;
- break;
- case 'i':
- if (!cvt)
- interlace = 1;
- break;
- case 'e':
- force = DRM_FORCE_ON;
-
[Bug 30325] [RADEON:KMS:RS780:MODESET] video=1280x720@50 no longer works
https://bugs.freedesktop.org/show_bug.cgi?id=30325 Jerome Glisse changed: What|Removed |Added Summary|video=1280x720@50 no longer |[RADEON:KMS:RS780:MODESET] |works |video=1280x720@50 no longer ||works -- 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 28456] [RADEON:KMS:RS400:INIT] detects different number of pipes each boot
https://bugs.freedesktop.org/show_bug.cgi?id=28456 Jerome Glisse changed: What|Removed |Added Summary|radeon dri detects |[RADEON:KMS:RS400:INIT] |different number of pipes |detects different number of |each boot |pipes each boot --- Comment #10 from Jerome Glisse 2011-02-09 07:18:17 PST --- Till has the issue with recent kernel ? -- 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 29026] [RADEON:KMS:RV670:MODESET] garbled screen after resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29026 Jerome Glisse changed: What|Removed |Added Summary|r600: Garbled screen after |[RADEON:KMS:RV670:MODESET] |resuming from suspend (KMS) |garbled screen after ||resuming from suspend --- Comment #11 from Jerome Glisse 2011-02-09 07:20:48 PST --- Still an issue with recent kernel ? -- 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 28456] [RADEON:KMS:RS400:INIT] detects different number of pipes each boot
https://bugs.freedesktop.org/show_bug.cgi?id=28456 --- Comment #11 from Alexandre 2011-02-09 07:22:12 PST --- (In reply to comment #10) > Till has the issue with recent kernel ? kind of. The 1 vs 3 pipes happens up to 2.6.37 , inclusive. The system performance seems better no matter what's detected, though. -- 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 30329] [RADEON:KMS:CEDAR:R600C] kwin present windows effect extremely slow and has graphical glitches
https://bugs.freedesktop.org/show_bug.cgi?id=30329 Jerome Glisse changed: What|Removed |Added Summary|[r600c/evergreen] KWin |[RADEON:KMS:CEDAR:R600C] |Present Windows effect |kwin present windows effect |extremely slow and has |extremely slow and has |graphical glitches |graphical glitches --- Comment #10 from Jerome Glisse 2011-02-09 07:22:53 PST --- Can you try with r600g or more recent version of r600c ? -- 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 29833] [RADEON:KMS:M56P:R300G] crashes kicad when using modeset
https://bugs.freedesktop.org/show_bug.cgi?id=29833 Jerome Glisse changed: What|Removed |Added Summary|radeon crashes kicad when |[RADEON:KMS:M56P:R300G] |using modeset |crashes kicad when using ||modeset --- Comment #18 from Jerome Glisse 2011-02-09 07:24:46 PST --- Still an issue with more recent driver ? -- 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 30759] black texture in gearbox demo on radeon 4850 (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=30759 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jerome Glisse 2011-02-09 07:27:39 PST --- Works with current git -- 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 30693] [RADEON::RV670:R600C] kwin 4.5.2] blur does not work with RV670 (it works with the old GLSL compiler)
https://bugs.freedesktop.org/show_bug.cgi?id=30693 Jerome Glisse changed: What|Removed |Added Summary|[R600c KWin 4.5.2] Blur |[RADEON::RV670:R600C] kwin |does not work with RV670|4.5.2] blur does not work |(it works with the old GLSL |with RV670 (it works with |compiler) |the old GLSL compiler) --- Comment #8 from Jerome Glisse 2011-02-09 07:29:55 PST --- Is it still broken ? -- 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 30665] [RADEON::RS300:R200C] r200 overflow command buffer error
https://bugs.freedesktop.org/show_bug.cgi?id=30665 Jerome Glisse changed: What|Removed |Added Summary|r200 overflow command |[RADEON::RS300:R200C] r200 |buffer error|overflow command buffer ||error --- Comment #4 from Jerome Glisse 2011-02-09 07:31:58 PST --- Still an issue ? -- 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 30463] [RADEON:KMS:RV770:R600G] unsupported PIPE_FORMAT_R8G8B8A8_USCALED while running sauerbraten
https://bugs.freedesktop.org/show_bug.cgi?id=30463 Jerome Glisse changed: What|Removed |Added Summary|[R600g] unsupported |[RADEON:KMS:RV770:R600G] |PIPE_FORMAT_R8G8B8A8_USCALE |unsupported |D while running sauerbraten |PIPE_FORMAT_R8G8B8A8_USCALE ||D while running sauerbraten --- Comment #1 from Jerome Glisse 2011-02-09 07:35:06 PST --- Is this still an issue ? -- 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 30402] xorg server fails to start when using xorg state tracker
https://bugs.freedesktop.org/show_bug.cgi?id=30402 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jerome Glisse 2011-02-09 07:35:54 PST --- So it's fixed ? -- 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 30665] [RADEON::RS300:R200C] r200 overflow command buffer error
https://bugs.freedesktop.org/show_bug.cgi?id=30665 --- Comment #5 from Frederic Crozat 2011-02-09 07:36:42 PST --- I'll do more tests soon -- 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 30620] [RADEON:KMS:RS100:MODESET] no display on VGA
https://bugs.freedesktop.org/show_bug.cgi?id=30620 Jerome Glisse changed: What|Removed |Added Summary|KMS on RS100: no display on |[RADEON:KMS:RS100:MODESET] |VGA |no display on VGA -- 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 30948] [RADEON:KMS::R600G] some texture broken regression due to commit 603741a86df0e43c0b52e8c202a35c7fe2fc1d9c
https://bugs.freedesktop.org/show_bug.cgi?id=30948 Jerome Glisse changed: What|Removed |Added Summary|Regression in r600 driver: |[RADEON:KMS::R600G] some |due to commit |texture broken regression |603741a86df0e43c0b52e8c202a |due to commit |35c7fe2fc1d9c some texture |603741a86df0e43c0b52e8c202a |broken |35c7fe2fc1d9c --- Comment #2 from Jerome Glisse 2011-02-09 07:38:20 PST --- Does it works now ? -- 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 28771] [RADEON:KMS::R300C:R300G] waiting for vline forced always on
https://bugs.freedesktop.org/show_bug.cgi?id=28771 Jerome Glisse changed: What|Removed |Added Summary|Waiting for vline forced|[RADEON:KMS::R300C:R300G] |always on |waiting for vline forced ||always on -- 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 30383] [RADEON:KMS::R600C] GPU lockup / driver hang when playing ufoai
https://bugs.freedesktop.org/show_bug.cgi?id=30383 Jerome Glisse changed: What|Removed |Added Summary|r600c: GPU lockup / driver |[RADEON:KMS::R600C] GPU |hang when playing ufoai |lockup / driver hang when ||playing ufoai --- Comment #1 from Jerome Glisse 2011-02-09 07:44:09 PST --- Is this still an issue with recent kernel + recent mesa ? -- 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 31213] [RADEON:KMS:RV370:INIT] [drm] cp init fail (any kernels 2.6.3x.x)
https://bugs.freedesktop.org/show_bug.cgi?id=31213 Jerome Glisse changed: What|Removed |Added Summary|[drm] *ERROR* with KMS (any |[RADEON:KMS:RV370:INIT] |kernels 2.6.3x.x) and ati |[drm] cp init fail (any |mobility radeon X300|kernels 2.6.3x.x) --- Comment #1 from Jerome Glisse 2011-02-09 07:45:40 PST --- Is this still and issue with current kernel ? -- 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 19102] radeon: driver hangs when playing ufoai game
https://bugzilla.kernel.org/show_bug.cgi?id=19102 Jérôme Glisse changed: What|Removed |Added Status|NEW |RESOLVED CC||gli...@freedesktop.org Resolution||WILL_FIX_LATER --- Comment #2 from Jérôme Glisse 2011-02-09 15:43:18 --- Tracking this with fdo bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=30383 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb -- ___ 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
[Bug 31230] [RADEON:KMS:RV250:RESUME] corrupted screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=31230 Jerome Glisse changed: What|Removed |Added Summary|[RV250Lf] Corrupted screen |[RADEON:KMS:RV250:RESUME] |after resume|corrupted screen after ||resume --- Comment #1 from Jerome Glisse 2011-02-09 07:48:02 PST --- Is this still an issue with recent kernel ? -- 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 25717] Radeon: system locks up when sending many vertices.
https://bugs.freedesktop.org/show_bug.cgi?id=25717 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jerome Glisse 2011-02-09 07:48:42 PST --- Works here, closing -- 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 30340] [RADEON:KMS:RV280:R200C] gl applications crash when moving window
https://bugs.freedesktop.org/show_bug.cgi?id=30340 Jerome Glisse changed: What|Removed |Added Summary|gl applications crash when |[RADEON:KMS:RV280:R200C] gl |moving window |applications crash when ||moving window --- Comment #1 from Jerome Glisse 2011-02-09 07:49:52 PST --- Is this still an issue with recent kernel & mesa ? -- 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 31246] [RADEON::CYPRESS:R600C] reproducible hangs on piglit tests with HD5850
https://bugs.freedesktop.org/show_bug.cgi?id=31246 Jerome Glisse changed: What|Removed |Added Summary|Reproducible hangs on |[RADEON::CYPRESS:R600C] |piglit tests with 5850 |reproducible hangs on ||piglit tests with HD5850 --- Comment #4 from Jerome Glisse 2011-02-09 07:52:42 PST --- Do you still have issue with lastest r600c or r600g ? -- 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 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] rv670 AGP gart + gallium - GPU lockups. PCIE gart runs but stalls
https://bugs.freedesktop.org/show_bug.cgi?id=31532 Jerome Glisse changed: What|Removed |Added Summary|rv670 AGP gart + gallium - |[RADEON:KMS:RV670:AGP:R600C |GPU lockups. PCIE gart runs |-R600G] rv670 AGP gart + |but stalls. |gallium - GPU lockups. PCIE ||gart runs but stalls -- 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 21351] R600+DRI: glxgears crash
https://bugs.freedesktop.org/show_bug.cgi?id=21351 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jerome Glisse 2011-02-09 07:56:17 PST --- glxgears works here (recent kernel/mesa) on various hw with r600c/r600g -- 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 29978] [RADEON:KMS:RS780:R600G] r600c r600g GPU lockup loading savefile in vegastrike
https://bugs.freedesktop.org/show_bug.cgi?id=29978 Jerome Glisse changed: What|Removed |Added Summary|r600c, r600g, bisected: GPU |[RADEON:KMS:RS780:R600G] |lockup loading savefile in |r600c r600g GPU lockup |vegastrike |loading savefile in ||vegastrike -- 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 28995] [RADEON:KMS::R300G] gl program -> rejects command buffers
https://bugs.freedesktop.org/show_bug.cgi?id=28995 Jerome Glisse changed: What|Removed |Added Summary|[r300g] dri rejects command |[RADEON:KMS::R300G] gl |buffers |program -> rejects command ||buffers -- 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 28995] [RADEON:KMS::R300G] gl program -> rejects command buffers
https://bugs.freedesktop.org/show_bug.cgi?id=28995 --- Comment #24 from Jerome Glisse 2011-02-09 07:59:06 PST --- Is this still an issue with recent kernel + mesa ? -- 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 31619] [RADEON:KMS::DYNPM] desktop freezes quickly every now and then with dynpm
https://bugs.freedesktop.org/show_bug.cgi?id=31619 Jerome Glisse changed: What|Removed |Added Summary|Desktop freezes quickly |[RADEON:KMS::DYNPM] desktop |every now and then with |freezes quickly every now |dynpm |and then with dynpm --- Comment #3 from Jerome Glisse 2011-02-09 08:00:00 PST --- Do you still have this issue ? -- 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 31732] [RADEON:KMS:RS780:R600C-R600G] X crashes with "X: radeon_texture.c:682: radeon_store_teximage: Assertion `0' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=31732 Jerome Glisse changed: What|Removed |Added Summary|X crashes with "X: |[RADEON:KMS:RS780:R600C-R60 |radeon_texture.c:682: |0G] X crashes with "X: |radeon_store_teximage: |radeon_texture.c:682: |Assertion `0' failed." |radeon_store_teximage: ||Assertion `0' failed." --- Comment #9 from Jerome Glisse 2011-02-09 08:01:58 PST --- Do you still have this issue with more recent kernel + mesa ? -- 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 25114] [RADEON:KMS::R600C] nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
https://bugs.freedesktop.org/show_bug.cgi?id=25114 Jerome Glisse changed: What|Removed |Added Summary|[R600] Nexuiz 2.5.2 crashes |[RADEON:KMS::R600C] nexuiz |on demo5 (Silver City), |2.5.2 crashes on demo5 |errors on demo piece-o-cake |(Silver City), errors on |too |demo piece-o-cake too --- Comment #11 from Jerome Glisse 2011-02-09 08:03:04 PST --- Do you still have this issue with recent mesa+kernel ? -- 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 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel -> i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 Jerome Glisse changed: What|Removed |Added Summary|random XRandR failures (i2c |[RADEON:KMS::EDID] i2c bit |related?) |banging + preempt kernel -> ||i2c failure (random XRandR ||failures) -- 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 31842] Implement GL_FIXED support
https://bugs.freedesktop.org/show_bug.cgi?id=31842 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Jerome Glisse 2011-02-09 08:06:50 PST --- Should work now, closing -- 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 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=30227 Jerome Glisse changed: What|Removed |Added Summary|Radom X.org freeze by a GPU |[RADEON:KMS:AGP:R300:PPC] |lockup |random X freeze by a GPU ||lockup -- 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 29833] [RADEON:KMS:M56P:R300G] crashes kicad when using modeset
https://bugs.freedesktop.org/show_bug.cgi?id=29833 Fabio Varesano changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #19 from Fabio Varesano 2011-02-09 08:30:59 PST --- (In reply to comment #18) > Still an issue with more recent driver ? Nope. This was actually a bug in the program. However only some video drivers was letting this crash. For more info see: https://bugs.launchpad.net/kicad/+bug/582997 The fix has been committed in rev 2767 if you guys are interested in what was wrong. Thanks. -- 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 25717] Radeon: system locks up when sending many vertices.
https://bugs.freedesktop.org/show_bug.cgi?id=25717 Nicolas Kaiser changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Nicolas Kaiser 2011-02-09 08:37:27 PST --- Running gltestperf with r600g locks up hard at my place in benchmark 3. System environment: -- system architecture: amd64 -- Linux distribution: Gentoo -- GPU: RS780G -- Model: ATI Radeon HD 3200 -- Display connector: VGA -- xf86-video-ati: 6.14.0 -- xserver: 1.9.3.902 -- mesa: c26478680989bd3d7303c5d772f7fb2a76045191 -- drm: 550fe2ca3b29ad2191eab4fdfbed9ed21e25492d -- kernel: 2.6.38-rc3 -- 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 30693] [RADEON::RV670:R600C] kwin 4.5.2] blur does not work with RV670 (it works with the old GLSL compiler)
https://bugs.freedesktop.org/show_bug.cgi?id=30693 --- Comment #9 from darkbasic 2011-02-09 08:39:54 PST --- I don't have kwin 4.5 anymore, I can test it with kwin 4.6 if you want but I think it will work because it does work even with intel (!). -- 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 30325] [RADEON:KMS:RS780:MODESET] video=1280x720@50 no longer works
https://bugs.freedesktop.org/show_bug.cgi?id=30325 --- Comment #5 from Alex Deucher 2011-02-09 08:55:42 PST --- This was a apparently due to a drm core change: https://bugzilla.kernel.org/show_bug.cgi?id=21542 -- 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: Intel i915 freeze on latest git
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen wrote: > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote: > > Hmm, that was the only change I could spot between the two patches. Care > > to disable that function and see what happens? [i.e. put a return before > > we write anything to the ring] > > Ping? I was optimistic that we might spot the real issue... However, you appear to be not alone and so I've pushed a disabling patch onto -fixes: commit ac66808814036b4c33dd98091b2176ae6157f1a8 Author: Chris Wilson Date: Wed Feb 9 16:15:32 2011 + drm/i915: Disable RC6 on Ironlake The automatic powersaving feature is once again causing havoc, with 100% reliable hangs on boot and resume on affected machines. Reported-by: Francesco Allertsen Reported-by: Gui Rui Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 Signed-off-by: Chris Wilson That should work its way upstream shortly. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25717] Radeon: system locks up when sending many vertices.
https://bugs.freedesktop.org/show_bug.cgi?id=25717 --- Comment #7 from Marek Olšák 2011-02-09 09:25:52 PST --- Maybe gltestperf doesn't lock up, it's just slow. On my lappy, it takes 9 seconds to complete. If it takes more than 10 seconds, kernel will consider it a lock-up, even though it's not. -- 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: Intel i915 freeze on latest git
On Wed, 09 Feb 2011 17:09:10 + Chris Wilson wrote: > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > wrote: > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote: > > > Hmm, that was the only change I could spot between the two patches. Care > > > to disable that function and see what happens? [i.e. put a return before > > > we write anything to the ring] > > > > Ping? > > I was optimistic that we might spot the real issue... However, you appear > to be not alone and so I've pushed a disabling patch onto -fixes: > > commit ac66808814036b4c33dd98091b2176ae6157f1a8 > Author: Chris Wilson > Date: Wed Feb 9 16:15:32 2011 + > > drm/i915: Disable RC6 on Ironlake > > The automatic powersaving feature is once again causing havoc, with 100% > reliable hangs on boot and resume on affected machines. > > Reported-by: Francesco Allertsen > Reported-by: Gui Rui > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 > Signed-off-by: Chris Wilson > > That should work its way upstream shortly. reverting the cleanup wasn't sufficient? Francesco, if you revert the cleanup patch you bisected to, what does /sys/kernel/debug/dri/0/i915_drpc_info report? -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Intel i915 freeze on latest git
On Wed, 9 Feb 2011 09:50:47 -0800 Jesse Barnes wrote: > On Wed, 09 Feb 2011 17:09:10 + > Chris Wilson wrote: > > > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > > wrote: > > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote: > > > > Hmm, that was the only change I could spot between the two patches. Care > > > > to disable that function and see what happens? [i.e. put a return before > > > > we write anything to the ring] > > > > > > Ping? > > > > I was optimistic that we might spot the real issue... However, you appear > > to be not alone and so I've pushed a disabling patch onto -fixes: > > > > commit ac66808814036b4c33dd98091b2176ae6157f1a8 > > Author: Chris Wilson > > Date: Wed Feb 9 16:15:32 2011 + > > > > drm/i915: Disable RC6 on Ironlake > > > > The automatic powersaving feature is once again causing havoc, with 100% > > reliable hangs on boot and resume on affected machines. > > > > Reported-by: Francesco Allertsen > > Reported-by: Gui Rui > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 > > Signed-off-by: Chris Wilson > > > > That should work its way upstream shortly. > > reverting the cleanup wasn't sufficient? > > Francesco, if you revert the cleanup patch you bisected to, what > does /sys/kernel/debug/dri/0/i915_drpc_info report? In particular, I'm curious if it reports that you're in RC6, so you might need to cat it a couple of times while gfx is idle (like from the console or an ssh session while nothing is drawing). -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wed, Feb 9, 2011 at 3:59 AM, Hans Verkuil wrote:
> On Tuesday, February 08, 2011 16:28:32 Alex Deucher wrote:
>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote:
>
>
>
>> >> The driver supports an interrupt. It is used to detect plug/unplug
> events
>> > in
>> >> kernel debugs. The API for detection of such an events in V4L2 API is to
> be
>> >> defined.
>> >
>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to
> post
>> > an RFC by the end of this month. We also have a proposal for CEC support
> in
>> > the pipeline.
>>
>> Any reason to not use the drm kms APIs for modesetting, display
>> configuration, and hotplug support? We already have the
>> infrastructure in place for complex display configurations and
>> generating events for hotplug interrupts. It would seem to make more
>> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>> API. Things like CEC would be a natural fit since a lot of desktop
>> GPUs support hdmi audio/3d/etc. and are already using kms.
>
> There are various reasons for not going down that road. The most important one
> is that mixing APIs is actually a bad idea. I've done that once in the past
> and I've regretted ever since. The problem with doing that is that it is
> pretty hard on applications who have to mix two different styles of API,
> somehow know where to find the documentation for each and know that both APIs
> can in fact be used on the same device.
>
> Now, if there was a lot of code that could be shared, then that might be
> enough reason to go that way, but in practice there is very little overlap.
> Take CEC: all the V4L API will do is to pass the CEC packets from kernel to
> userspace and vice versa. There is no parsing at all. This is typically used
> by embedded apps that want to do their own CEC processing.
>
> An exception might be a PCI(e) card with HDMI input/output that wants to
> handle CEC internally. At that point we might look at sharing CEC parsing
> code. A similar story is true for EDID handling.
>
> One area that might be nice to look at would be to share drivers for HDMI
> receivers and transmitters. However, the infrastructure for such drivers is
> wildly different between how it is used for GPUs versus V4L and has been for
> 10 years or so. I also suspect that most GPUs have there own HDMI internal
> implementation so code sharing will probably be quite limited.
>
You don't need to worry about the rest of the 3D and acceleration
stuff to use the kms modesetting API. For video output, you have a
timing generator, an encoder that translates a bitstream into
voltages, and an connector that you plug into a monitor. Additionally
you may want to read an edid or generate a hotplug event and use some
modeline handling helpers. The kms api provides core modesetting code
and a set of modesetting driver callbacks for crtcs, encoders, and
connectors. The hardware implementations will vary, but modesetting
is the same. From drm_crtc_helper.h:
The driver provides the following callbacks for the crtc. The crtc
loosely refers to the part of the display pipe that generates timing
and framebuffer scanout position.
struct drm_crtc_helper_funcs {
/*
* Control power levels on the CRTC. If the mode passed in is
* unsupported, the provider must use the next lowest power
level.
*/
void (*dpms)(struct drm_crtc *crtc, int mode);
void (*prepare)(struct drm_crtc *crtc);
void (*commit)(struct drm_crtc *crtc);
/* Provider can fixup or change mode timings before modeset occurs */
bool (*mode_fixup)(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
/* Actually set the mode */
int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode, int x, int y,
struct drm_framebuffer *old_fb);
/* Move the crtc on the current fb to the given position *optional* */
int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb);
int (*mode_set_base_atomic)(struct drm_crtc *crtc,
struct drm_framebuffer *fb, int x, int y,
enum mode_set_atomic);
/* reload the current crtc LUT */
void (*load_lut)(struct drm_crtc *crtc);
/* disable crtc when not in use - more explicit than dpms off */
void (*disable)(struct drm_crtc *crtc);
};
encoders take the bitstream from the crtc and convert it into a set of
voltages understood by the monitor, e.g., TMDS or LVDS encoders. The
callbacks follow a similar pattern to crtcs.
struct drm_encoder_helper_funcs {
void (*dpms)(struct drm_encoder *encoder, int mode);
void (*save)(struct drm_encoder *encoder);
Re: Intel i915 freeze on latest git
On Wed, 9 Feb 2011 09:53:26 -0800 Jesse Barnes wrote: > On Wed, 9 Feb 2011 09:50:47 -0800 > Jesse Barnes wrote: > > > On Wed, 09 Feb 2011 17:09:10 + > > Chris Wilson wrote: > > > > > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > > > wrote: > > > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote: > > > > > Hmm, that was the only change I could spot between the two patches. > > > > > Care > > > > > to disable that function and see what happens? [i.e. put a return > > > > > before > > > > > we write anything to the ring] > > > > > > > > Ping? > > > > > > I was optimistic that we might spot the real issue... However, you appear > > > to be not alone and so I've pushed a disabling patch onto -fixes: > > > > > > commit ac66808814036b4c33dd98091b2176ae6157f1a8 > > > Author: Chris Wilson > > > Date: Wed Feb 9 16:15:32 2011 + > > > > > > drm/i915: Disable RC6 on Ironlake > > > > > > The automatic powersaving feature is once again causing havoc, with > > > 100% > > > reliable hangs on boot and resume on affected machines. > > > > > > Reported-by: Francesco Allertsen > > > Reported-by: Gui Rui > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582 > > > Signed-off-by: Chris Wilson > > > > > > That should work its way upstream shortly. > > > > reverting the cleanup wasn't sufficient? > > > > Francesco, if you revert the cleanup patch you bisected to, what > > does /sys/kernel/debug/dri/0/i915_drpc_info report? > > In particular, I'm curious if it reports that you're in RC6, so you > might need to cat it a couple of times while gfx is idle (like from the > console or an ssh session while nothing is drawing). Oh and one more request, what does "intel_reg_read 0x111b8" return on your system? I really don't want to disable RC6; it saves way too much power. So I'd like to understand what's going on here so we can either fix your system or reliably find a way to disable it on systems where the BIOS isn't allowing it... Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33957] G4 Mac mini Radeon 9200: Broken 3d-Acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=33957 --- Comment #6 from anjo.weichbr...@gmail.com 2011-02-09 10:06:03 PST --- (In reply to comment #5) > (In reply to comment #5) > > Disabling the kms (radeon.modeset=0) with the forums help, it was possible > > to > > fix a compatibility problem between radeonfb and the kms drm. > > If you enable KMS but disable radeonfb instead, does that work any better? I enabled KMS and disabled radeonfb. In KMS's default modeset, the system crashes during the boot process. With radeon.agpmode=4 the system boots fine. 3d acceleration is enabled but works only with some application and is really slow. -> regular system crashes Forcing the PCI mode with radeon.modeset=-1 the system boots fine. 3d acceleration is enabled and works (no blue tins or flickering), but is really slow: When Visual effects for gnome session are enabled, glxgears gives 20 fps, without visual effects: 400 fps. Tuxkart or Flightgear are not usable. -- 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: Intel i915 freeze on latest git
On Wed, 9 Feb 2011 09:50:47 -0800, Jesse Barnes wrote: > On Wed, 09 Feb 2011 17:09:10 + > Chris Wilson wrote: > > I was optimistic that we might spot the real issue... However, you appear > > to be not alone and so I've pushed a disabling patch onto -fixes: > > > > commit ac66808814036b4c33dd98091b2176ae6157f1a8 > > Author: Chris Wilson > > Date: Wed Feb 9 16:15:32 2011 + > > > > drm/i915: Disable RC6 on Ironlake > > reverting the cleanup wasn't sufficient? Considering we've been burnt badly by rc6 in the past, and we now have two independent regression reports of hard hangs at completely different stages, disabling it seemed the prudent course. I left a switch in place so we can continue testing. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon support state in libkms
On Wed, Feb 9, 2011 at 6:49 AM, James Simmons wrote: > >> I was looking at the radeon support state in libkms and I found out the >> following patch was proposed back in September, but never commented nor >> merged. The patch was submitted by nobled. >> >> http://lists.freedesktop.org/archives/dri-devel/2010-September/003740.html >> >> I applied it on the latest drm git version without any problem and >> compilation looks fine. Is there a reason preventing it from being merged? >> >> If it needs testing, make your suggestion, I'll gladly make my best to >> test it. > > Good point. Is KMS dead? Anyone? I was seriously hoping that Dave's dumb buffer API would go upstream and that libkms would be able to use that generic path for all KMS drivers, rather than needing shim code for every driver it supports. That said, yeah, the libkms maintainer probably should pull that code in. Who is that, anyway? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25717] Radeon: system locks up when sending many vertices.
https://bugs.freedesktop.org/show_bug.cgi?id=25717
--- Comment #8 from Nicolas Kaiser 2011-02-09 10:44:27 PST ---
(In reply to comment #7)
> Maybe gltestperf doesn't lock up, it's just slow. On my lappy, it takes 9
> seconds to complete. If it takes more than 10 seconds, kernel will consider it
> a lock-up, even though it's not.
Yes, indeed. Now I disabled lockups like this ...
drivers/gpu/drm/radeon/r100.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 5f15820..ce5ea3d 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2036,7 +2036,7 @@ bool r100_gpu_cp_is_lockup(struct radeon_device *rdev,
struct r100_gpu_lockup *l
elapsed = jiffies_to_msecs(cjiffies - lockup->last_jiffies);
if (elapsed >= 1) {
dev_err(rdev->dev, "GPU lockup CP stall for more than %lumsec\n",
elapsed);
-return true;
+//return true;
}
/* give a chance to the GPU ... */
return false;
... and gltestperf finished successfully.
According to the below results, it takes more than 13 seconds at my place:
Feb 9 19:32:40 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 1msec
Feb 9 19:32:40 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 10500msec
Feb 9 19:32:41 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11000msec
Feb 9 19:32:41 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11500msec
Feb 9 19:32:42 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12000msec
Feb 9 19:32:42 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12500msec
Feb 9 19:32:43 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 13000msec
Feb 9 19:32:54 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 1msec
Feb 9 19:32:55 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 10500msec
Feb 9 19:32:55 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11000msec
Feb 9 19:32:56 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11500msec
Feb 9 19:32:56 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12000msec
Feb 9 19:32:57 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12500msec
Feb 9 19:32:57 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 13000msec
Feb 9 19:33:09 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 1msec
Feb 9 19:33:10 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 10500msec
Feb 9 19:33:10 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11000msec
Feb 9 19:33:10 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11500msec
Feb 9 19:33:11 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12000msec
Feb 9 19:33:12 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12500msec
Feb 9 19:33:12 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 13000msec
Feb 9 19:33:24 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 1msec
Feb 9 19:33:24 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 10500msec
Feb 9 19:33:25 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11000msec
Feb 9 19:33:25 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11500msec
Feb 9 19:33:26 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12000msec
Feb 9 19:33:26 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12500msec
Feb 9 19:33:27 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 13000msec
Feb 9 19:33:38 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 1msec
Feb 9 19:33:39 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 10500msec
Feb 9 19:33:39 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11000msec
Feb 9 19:33:40 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 11500msec
Feb 9 19:33:40 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12000msec
Feb 9 19:33:41 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 12500msec
Feb 9 19:33:41 absol kernel: radeon :01:05.0: GPU lockup CP stall for more
than 13000msec
--
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: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wed, Feb 9, 2011 at 9:55 AM, Alex Deucher wrote:
> On Wed, Feb 9, 2011 at 3:59 AM, Hans Verkuil wrote:
>> On Tuesday, February 08, 2011 16:28:32 Alex Deucher wrote:
>>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote:
>>
>>
>>
>>> >> The driver supports an interrupt. It is used to detect plug/unplug
>> events
>>> > in
>>> >> kernel debugs. The API for detection of such an events in V4L2 API is to
>> be
>>> >> defined.
>>> >
>>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to
>> post
>>> > an RFC by the end of this month. We also have a proposal for CEC support
>> in
>>> > the pipeline.
>>>
>>> Any reason to not use the drm kms APIs for modesetting, display
>>> configuration, and hotplug support? We already have the
>>> infrastructure in place for complex display configurations and
>>> generating events for hotplug interrupts. It would seem to make more
>>> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>>> API. Things like CEC would be a natural fit since a lot of desktop
>>> GPUs support hdmi audio/3d/etc. and are already using kms.
>>
>> There are various reasons for not going down that road. The most important
>> one
>> is that mixing APIs is actually a bad idea. I've done that once in the past
>> and I've regretted ever since. The problem with doing that is that it is
>> pretty hard on applications who have to mix two different styles of API,
>> somehow know where to find the documentation for each and know that both APIs
>> can in fact be used on the same device.
>>
>> Now, if there was a lot of code that could be shared, then that might be
>> enough reason to go that way, but in practice there is very little overlap.
>> Take CEC: all the V4L API will do is to pass the CEC packets from kernel to
>> userspace and vice versa. There is no parsing at all. This is typically used
>> by embedded apps that want to do their own CEC processing.
>>
>> An exception might be a PCI(e) card with HDMI input/output that wants to
>> handle CEC internally. At that point we might look at sharing CEC parsing
>> code. A similar story is true for EDID handling.
>>
>> One area that might be nice to look at would be to share drivers for HDMI
>> receivers and transmitters. However, the infrastructure for such drivers is
>> wildly different between how it is used for GPUs versus V4L and has been for
>> 10 years or so. I also suspect that most GPUs have there own HDMI internal
>> implementation so code sharing will probably be quite limited.
>>
>
> You don't need to worry about the rest of the 3D and acceleration
> stuff to use the kms modesetting API. For video output, you have a
> timing generator, an encoder that translates a bitstream into
> voltages, and an connector that you plug into a monitor. Additionally
> you may want to read an edid or generate a hotplug event and use some
> modeline handling helpers. The kms api provides core modesetting code
> and a set of modesetting driver callbacks for crtcs, encoders, and
> connectors. The hardware implementations will vary, but modesetting
> is the same. From drm_crtc_helper.h:
>
> The driver provides the following callbacks for the crtc. The crtc
> loosely refers to the part of the display pipe that generates timing
> and framebuffer scanout position.
>
> struct drm_crtc_helper_funcs {
> /*
> * Control power levels on the CRTC. If the mode passed in is
> * unsupported, the provider must use the next lowest power
> level.
> */
> void (*dpms)(struct drm_crtc *crtc, int mode);
> void (*prepare)(struct drm_crtc *crtc);
> void (*commit)(struct drm_crtc *crtc);
>
> /* Provider can fixup or change mode timings before modeset occurs */
> bool (*mode_fixup)(struct drm_crtc *crtc,
> struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> /* Actually set the mode */
> int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode, int x, int y,
> struct drm_framebuffer *old_fb);
>
> /* Move the crtc on the current fb to the given position *optional* */
> int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
> struct drm_framebuffer *old_fb);
> int (*mode_set_base_atomic)(struct drm_crtc *crtc,
> struct drm_framebuffer *fb, int x, int y,
> enum mode_set_atomic);
>
> /* reload the current crtc LUT */
> void (*load_lut)(struct drm_crtc *crtc);
>
> /* disable crtc when not in use - more explicit than dpms off */
> void (*disable)(struct drm_crtc *crtc);
> };
>
> encoders take the bitstream from the crtc and convert it into a set of
> voltages understood by the monitor, e.g., TMDS or LVDS encoders. The
> callbacks follow a simi
[Bug 34096] New: r300: Cannot get a relocation in radeon_drm_cs_write_reloc.
https://bugs.freedesktop.org/show_bug.cgi?id=34096 Summary: r300: Cannot get a relocation in radeon_drm_cs_write_reloc. Product: Mesa Version: git Platform: Other URL: http://www.minecraft.net/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se Created an attachment (id=43168) --> (https://bugs.freedesktop.org/attachment.cgi?id=43168) more dmesg output When starting the game Minecraft, I'm getting these messages in the terminal: radeon: The kernel rejected CS, see dmesg for more information. r300: Cannot get a relocation in radeon_drm_cs_write_reloc. dmesg: [ 527.282839] [drm:r100_packet3_load_vbpntr] *ERROR* No reloc for packet3 47 [ 527.282841] [drm] ib[13751]=0xC0052F00 [ 527.282842] [drm] ib[13752]=0x0023 [ 527.282843] [drm] ib[13753]=0x08010803 [ 527.282844] [drm] ib[13754]=0x000EA840 [ 527.282845] [drm] ib[13755]=0x000EA858 [ 527.282846] [drm] ib[13756]=0x0802 [ 527.282847] [drm] ib[13757]=0x000EA84C [ 527.282849] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! If needed, I will try and bisect when I have more time. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 6.13.2 -- xserver: 1.9.4 -- mesa: 04c5cc5b8bec1f34f2405b08fd0d9ed6bd70ea61 -- drm: 2.4.23 -- kernel: 2.6.37 -- 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: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher wrote: > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: >> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: >>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: >>> > Just two quick notes. I'll try to do a full review this weekend. >>> > >>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: >>> >> == >>> >> Introduction >>> >> == >>> >> >>> >> The purpose of this RFC is to discuss the driver for a TV output >>> >> interface >>> >> available in upcoming Samsung SoC. The HW is able to generate digital and >>> >> analog signals. Current version of the driver supports only digital >>> >> output. >>> >> >>> >> Internally the driver uses videobuf2 framework, and CMA memory allocator. >>> > Not >>> >> all of them are merged by now, but I decided to post the sources to start >>> >> discussion driver's design. >> >>> > >>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to >>> > post >>> > an RFC by the end of this month. We also have a proposal for CEC support >>> > in >>> > the pipeline. >>> >>> Any reason to not use the drm kms APIs for modesetting, display >>> configuration, and hotplug support? We already have the >>> infrastructure in place for complex display configurations and >>> generating events for hotplug interrupts. It would seem to make more >>> sense to me to fix any deficiencies in the KMS APIs than to spin a new >>> API. Things like CEC would be a natural fit since a lot of desktop >>> GPUs support hdmi audio/3d/etc. and are already using kms. >>> >>> Alex >> >> I'll toss one out: lack of API documentation for driver or application >> developers to use. >> >> >> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to >> possibly get rid of reliance on the ivtv X video driver >> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation >> was really sparse. >> >> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but >> the userland API wasn't fleshed out. GEM was talked about a bit in >> there as well, IIRC. >> >> TTM documentation was essentially non-existant. >> >> I can't find any KMS documentation either. >> >> I recall having to read much of the drm code, and having to look at the >> radeon driver, just to tease out what the DRM ioctls needed to do. >> >> Am I missing a Documentation source for the APIs? Yes, My summer of code project's purpose was to create something of a tutorial for writing a KMS driver. The code, split out into something like 15 step-by-step patches, and accompanying documentation are available from Google's website. http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz My repository (doesn't include the documentation) is available here: http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary There's a 'rebased' branch that contains API changes required for the code to work with 2.6.37~. I hope it's useful to you. I can't image how the lack of documentation of an used and tested API could be a serious reason to write you own. That makes absolutely no sense to me, so I hope you'll decide to use KMS. Matt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34097] New: Screen clearing issues in Minecraft and Blender
https://bugs.freedesktop.org/show_bug.cgi?id=34097 Summary: Screen clearing issues in Minecraft and Blender Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se Created an attachment (id=43170) --> (https://bugs.freedesktop.org/attachment.cgi?id=43170) Minecraft after switching from fullscreen When switching between fullscreen and window in the game Minecraft, or when pressing F12 to render the scene in Blender, I'm getting a a corrupt screen. Sometimes it looks like it contains traces of a previously running gl application, so maybe some buffer or something isn't cleared properly? This isn't a new bug (seems to be present at least as far back as 7.9) or a very important one, but would be nice if it could be fixed. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 6.13.2 -- xserver: 1.9.4 -- mesa: 04c5cc5b8bec1f34f2405b08fd0d9ed6bd70ea61 -- drm: 2.4.23 -- kernel: 2.6.37 -- 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 34097] Screen clearing issues in Minecraft and Blender
https://bugs.freedesktop.org/show_bug.cgi?id=34097 --- Comment #1 from Sven Arvidsson 2011-02-09 11:03:42 PST --- Created an attachment (id=43171) --> (https://bugs.freedesktop.org/attachment.cgi?id=43171) Rendering in Blender -- 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 25114] [RADEON:KMS::R600C] nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
https://bugs.freedesktop.org/show_bug.cgi?id=25114 --- Comment #12 from Andy Furniss 2011-02-09 11:20:20 PST --- (In reply to comment #11) > Do you still have this issue with recent mesa+kernel ? FWIW nexuiz doesn't crash for me on rv790. The game reported errors on piece-o-cake - R_Water_ProcessPlanes: Error: texture creation failed! Turned off r_water. R_LoadTexture: bogus texture size (0x0x1x32bppx1sides = 0 bytes) also occur with swrast[g] -- 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 34097] Screen clearing issues in Minecraft and Blender
https://bugs.freedesktop.org/show_bug.cgi?id=34097 --- Comment #2 from Sven Arvidsson 2011-02-09 11:45:52 PST --- I should also mention that this problem doesn't appear with llvmpipe, so I guess it's specific to r300g. -- 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 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #39 from Helber Maciel Guerra 2011-02-09 19:51:01 --- My git bisect log: [root@note linux-git2.6]# git bisect log git bisect start # good: [ebf53826e105f488f4f628703a108e98940d1dc5] Linux 2.6.38-rc3 git bisect good ebf53826e105f488f4f628703a108e98940d1dc5 # bad: [100b33c8bd8a3235fd0b7948338d6cbb3db3c63d] Linux 2.6.38-rc4 git bisect bad 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d # bad: [78d2978874e4e10e97dfd4fd79db45bdc0748550] CRED: Fix kernel panic upon security_file_alloc() failure. git bisect bad 78d2978874e4e10e97dfd4fd79db45bdc0748550 # good: [eb487ab4d5af0caee81bfaaa5d87b55844f60145] Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect good eb487ab4d5af0caee81bfaaa5d87b55844f60145 # good: [811aaa55ba21ab37407018cfc01770d6b037d3fb] drm: Only set DPMS ON when actually configuring a mode git bisect good 811aaa55ba21ab37407018cfc01770d6b037d3fb # good: [e98ce0d7cfa6ee0650a63d45558a5121383995d9] Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-fixes git bisect good e98ce0d7cfa6ee0650a63d45558a5121383995d9 # bad: [18ff84da29b3f0c073e0ce6e341663cc6bcb0ab7] drm/radeon/kms/evergreen: always set certain VGT regs at CP init git bisect bad 18ff84da29b3f0c073e0ce6e341663cc6bcb0ab7 # good: [f523f74eac1897b13c05c88ce6e5de0a7c34578b] drm/radeon/kms: add new pll algo for avivo asics git bisect good f523f74eac1897b13c05c88ce6e5de0a7c34578b # bad: [63a507800c8aca5a1891d598ae13f829346e8e39] drm/radeon: remove 0x4243 pci id git bisect bad 63a507800c8aca5a1891d598ae13f829346e8e39 # bad: [619efb105924d8cafa0c1dd9389e9ab506f5425d] drm/radeon/kms: Enable new pll calculation for avivo+ asics git bisect bad 619efb105924d8cafa0c1dd9389e9ab506f5425d Result of git bisect: [root@note linux-git2.6]# git bisect bad 619efb105924d8cafa0c1dd9389e9ab506f5425d is the first bad commit commit 619efb105924d8cafa0c1dd9389e9ab506f5425d Author: Alex Deucher Date: Mon Jan 31 16:48:53 2011 -0500 drm/radeon/kms: Enable new pll calculation for avivo+ asics New algo is used for r5xx+ and legacy is used for r1xx-r4xx, rv515. I've tested on all relevant GPUs and monitors that I have access to and have found no problems. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26562 https://bugzilla.kernel.org/show_bug.cgi?id=26552 May fix: https://bugs.freedesktop.org/show_bug.cgi?id=32556 Signed-off-by: Alex Deucher Cc: sta...@kernel.org Signed-off-by: Dave Airlie :04 04 956a38aa4192356c3f0b7fe34cbf7af04a4a0342 18318beec8b390a01166edd311338f3ba819e823 Mdrivers Tanks, Helber Maciel Guerra -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb -- ___ 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
Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wednesday, February 09, 2011 20:00:38 Matt Turner wrote: > On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher wrote: > > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: > >> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: > >>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: > >>> > Just two quick notes. I'll try to do a full review this weekend. > >>> > > >>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: > >>> >> == > >>> >> Introduction > >>> >> == > >>> >> > >>> >> The purpose of this RFC is to discuss the driver for a TV output > >>> >> interface > >>> >> available in upcoming Samsung SoC. The HW is able to generate digital > >>> >> and > >>> >> analog signals. Current version of the driver supports only digital > >>> >> output. > >>> >> > >>> >> Internally the driver uses videobuf2 framework, and CMA memory > >>> >> allocator. > >>> > Not > >>> >> all of them are merged by now, but I decided to post the sources to > >>> >> start > >>> >> discussion driver's design. > >> > >>> > > >>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope > >>> > to post > >>> > an RFC by the end of this month. We also have a proposal for CEC > >>> > support in > >>> > the pipeline. > >>> > >>> Any reason to not use the drm kms APIs for modesetting, display > >>> configuration, and hotplug support? We already have the > >>> infrastructure in place for complex display configurations and > >>> generating events for hotplug interrupts. It would seem to make more > >>> sense to me to fix any deficiencies in the KMS APIs than to spin a new > >>> API. Things like CEC would be a natural fit since a lot of desktop > >>> GPUs support hdmi audio/3d/etc. and are already using kms. > >>> > >>> Alex > >> > >> I'll toss one out: lack of API documentation for driver or application > >> developers to use. > >> > >> > >> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to > >> possibly get rid of reliance on the ivtv X video driver > >> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation > >> was really sparse. > >> > >> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but > >> the userland API wasn't fleshed out. GEM was talked about a bit in > >> there as well, IIRC. > >> > >> TTM documentation was essentially non-existant. > >> > >> I can't find any KMS documentation either. > >> > >> I recall having to read much of the drm code, and having to look at the > >> radeon driver, just to tease out what the DRM ioctls needed to do. > >> > >> Am I missing a Documentation source for the APIs? > > Yes, > > My summer of code project's purpose was to create something of a > tutorial for writing a KMS driver. The code, split out into something > like 15 step-by-step patches, and accompanying documentation are > available from Google's website. > > http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz Nice! What I still don't understand is if and how this is controlled via userspace. Is there some documentation of the userspace API somewhere? > My repository (doesn't include the documentation) is available here: > http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary > > There's a 'rebased' branch that contains API changes required for the > code to work with 2.6.37~. > > I hope it's useful to you. > > I can't image how the lack of documentation of an used and tested API > could be a serious reason to write you own. That never was the main reason. It doesn't help, though. > That makes absolutely no > sense to me, so I hope you'll decide to use KMS. No, we won't. A GPU driver != a V4L driver. The primary purpose of a V4L2 display driver is to output discrete frames from memory to some device. This may be a HDMI transmitter, a SDTV transmitter, a memory-to-memory codec, an FPGA, whatever. In other words, there is not necessarily a monitor on the other end. We have for some time now V4L2 APIs to set up video formats. The original ioctl was VIDIOC_G/S_STD to select PAL/NTSC/SECAM. The new ones are VIDIOC_G/S_DV_PRESETS which set up standard formats (1080p60, 720p60, etc) and DV_TIMINGS which can be used for custom bt.656/1120 digital video timings. Trying to mix KMS into the V4L2 API is just a recipe for disaster. Just think about what it would mean for DRM if DRM would use the V4L2 API for setting video modes. That would be a disaster as well. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31619] [RADEON:KMS::DYNPM] desktop freezes quickly every now and then with dynpm
https://bugs.freedesktop.org/show_bug.cgi?id=31619 --- Comment #4 from Ernst Sjöstrand 2011-02-09 12:44:44 PST --- Yes, still happens with 2.6.38-020638rc4-generic from http://kernel.ubuntu.com/~kernel-ppa/mainline/ Any reason that it should be gone? -- 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 25114] [RADEON:KMS::R600C] nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
https://bugs.freedesktop.org/show_bug.cgi?id=25114 --- Comment #13 from darkbasic 2011-02-09 12:56:44 PST --- It doesn't crash anymore, but the warnings in piece-o-cake remains (and you can't see the water). RV670 with R600g, 2.6.38-rc4, xorg-server-1.9.4, mesa git, libdrm git, xf86-video-ati git, pageflipping on, colortiling on, swapbufferwaits off. Anyway the performance is impressive: 120 fps in openarena@2560x1600 and very high quality, 65 fps in nexuiz demo5@2560x1600 and medium quality; 58 fps in demo1. We just need S3TC :( -- 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 30463] [RADEON:KMS:RV770:R600G] unsupported PIPE_FORMAT_R8G8B8A8_USCALED while running sauerbraten
https://bugs.freedesktop.org/show_bug.cgi?id=30463 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Laurent carlier 2011-02-09 13:26:58 PST --- Cannot reproduce it, so i close. -- 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 34110] New: 'high' profile does not set the engine and the memory clocks to the max value
https://bugs.freedesktop.org/show_bug.cgi?id=34110 Summary: 'high' profile does not set the engine and the memory clocks to the max value Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: darkbas...@gmail.com gentoo ~ # power-profile high Power profile set to HIGH! gentoo ~ # power-profile status profile default default engine clock: 776000 kHz current engine clock: 769500 kHz default memory clock: 1126000 kHz current memory clock: 1125000 kHz voltage: 1300 mV PCIE lanes: 16 gentoo ~ # power-profile low Power profile set to LOW! gentoo ~ # power-profile status profile low default engine clock: 776000 kHz current engine clock: 297000 kHz default memory clock: 1126000 kHz current memory clock: 1125000 kHz voltage: 1258 mV PCIE lanes: 16 Shouldn't it set the engine to 776000 and the memory to 1126000? RV670 with R600g, 2.6.38-rc4, xorg-server-1.9.4, mesa git, libdrm git, xf86-video-ati git, pageflipping on, colortiling on, swapbufferwaits off. -- 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 30693] [RADEON::RV670:R600C] kwin 4.5.2] blur does not work with RV670 (it works with the old GLSL compiler)
https://bugs.freedesktop.org/show_bug.cgi?id=30693 --- Comment #10 from darkbasic 2011-02-09 13:40:55 PST --- It does work with R600g and kwin 4.6. RV670 with R600g, 2.6.38-rc4, xorg-server-1.9.4, mesa git, libdrm git, xf86-video-ati git, pageflipping on, colortiling on, swapbufferwaits off. If you want you can close. -- 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: [BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
On Tue, Feb 8, 2011 at 4:20 PM, Alex Deucher wrote:
> On Tue, Feb 8, 2011 at 3:52 PM, Justin P. Mattock
> wrote:
>> With the current HEAD Im getting screen flickering really bad to point where
>> it looks like the screen is damaged and/or half plugged-in etc..
>>
>> the bisect pointed to here:
>>
>> commit 619efb105924d8cafa0c1dd9389e9ab506f5425d
>>
>> doing a git revert 619efb10592
>> gets the screen working properly again.
>> I havent looked much through the code to see if I can fix this. for the time
>> being I'll revert this on my machine with the current, until later on.
>
> The attached patch should fix it assuming I got your pci ids correct.
> I'm done with the pll stuff; too may fixes break other boards. Just
> add a quirk table and be done with it.
>
The attached patch builds on the previous one and fixes an additional
regression.
Alex
> Alex
>
>>
>> lspci -vv shows my card info(let me know if you need anymore)
>>
>> 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon
>> Mobility X1600] (prog-if 00 [VGA controller])
>> Subsystem: Apple Computer Inc. MacBook Pro
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 256 bytes
>> Interrupt: pin A routed to IRQ 42
>> Region 0: Memory at 4000 (32-bit, prefetchable) [size=128M]
>> Region 1: I/O ports at 3000 [size=256]
>> Region 2: Memory at 5030 (32-bit, non-prefetchable) [size=64K]
>> Expansion ROM at 5032 [disabled] [size=128K]
>> Capabilities:
>> Kernel driver in use: radeon
>> Kernel modules: radeon
>>
>>
>> Justin P. Mattock
>>
>
From c88cf9c2463629ab0cef7df8ade34750cde9b40a Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 9 Feb 2011 17:05:07 -0500
Subject: [PATCH] drm/radeon/kms: pll quirk cleanup
Default to legacy pll algo, add quirks for specific
regressions. Fixes regressions reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 52 +--
drivers/gpu/drm/radeon/radeon_mode.h |8 +
2 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 4a505ba..cc6bdd8 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -31,6 +31,11 @@
#include "atom.h"
#include "atom-bits.h"
+static enum radeon_pll_algo
+atombios_crtc_pick_pll_algo(struct drm_crtc *crtc,
+ struct drm_display_mode *mode,
+ uint32_t active_device);
+
static void atombios_overscan_setup(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -519,6 +524,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
/* reset the pll flags */
pll->flags = 0;
+ pll->algo = RADEON_PLL_ALGO_LEGACY;
if (ASIC_IS_AVIVO(rdev)) {
if ((rdev->family == CHIP_RS600) ||
@@ -584,6 +590,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder->encoder_type == DRM_MODE_ENCODER_LVDS)
pll->flags |= RADEON_PLL_USE_REF_DIV;
}
+ pll->algo = atombios_crtc_pick_pll_algo(crtc, mode, radeon_encoder->active_device);
break;
}
}
@@ -839,29 +846,54 @@ static void atombios_crtc_program_pll(struct drm_crtc *crtc,
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
}
-#define RADEON_PLL_ALGO_LEGACY 0
-#define RADEON_PLL_ALGO_AVIVO 1
-static int atombios_crtc_pick_pll_algo(struct drm_crtc *crtc, struct drm_display_mode *mode)
+static enum radeon_pll_algo
+atombios_crtc_pick_pll_algo(struct drm_crtc *crtc,
+ struct drm_display_mode *mode,
+ uint32_t active_device)
{
struct drm_device *dev = crtc->dev;
- struct radeon_device *rdev = dev->dev_private;
/* board specific quirks */
- /* funky macbooks */
+
+ /* legacy algo */
+ /* macbookpro2,2 */
if ((dev->pdev->device == 0x71C5) &&
(dev->pdev->subsystem_vendor == 0x106b) &&
(dev->pdev->subsystem_device == 0x0080)) {
return RADEON_PLL_ALGO_LEGACY;
}
- /* defaults */
- /* rv515 seems happier with the old algo */
- if (rdev->family == CHIP_RV515)
+ /* Thinkpad T60 */
+ if ((dev->pdev->device == 0x7145) &&
+ (dev->pdev->subsystem_vendor == 0x17aa) &&
+ (dev->pdev->subsystem_device == 0x2006)) {
return RADEON_PLL_ALGO_LEGACY;
- else if (ASIC_IS_AVIVO(rdev))
+ }
+
+ /* Acer RS880 */
+ if ((dev->pdev->device == 0x9712) &&
+ (dev->pdev->subsystem_vendor == 0x1025) &&
+ (dev->pdev->subsystem_device == 0x027d)) {
+ return RADEON_PLL_ALGO_LEGACY;
+ }
+
+ /* avivo algo */
+ /* PC Partner RV630 */
+ if ((dev->pdev->device == 0x9589) &&
+ (dev->pdev->subsystem_vendor == 0x174b) &&
+ (dev->pdev->subsystem_devi
[Bug 33011] HDMI-A-1 Does not work after resume (But claims it does)
https://bugs.freedesktop.org/show_bug.cgi?id=33011 --- Comment #18 from Russ Dill 2011-02-09 14:12:14 PST --- Just some notes: Power: Maxim MAX1999 Quad-ouput main power supply controller Maxim MAX8774GTL+ main power supply controller Semtech SC470 synchronous buck controller Semtech SC488 complete DDR memory power supply Nat Semi LM393 dual comparators. Chipset: ATI IXP460 SB460 ATI XPRESS RX485 ATX X1600 Broadcom BCM5788 MKFBG Netlink gigabit Ethernet controller with phy ICS ICS951462AGLF Programmable system clock chip for ATI RS/RD690 - K8 based systems Cypress CY25819 spread spectrum clock generator Super IO: Nat Semi PC87541V-VPC (Seems to be PC87591) LPC Mobile Embedded Controller Nat Semi PC87383-VS Legacy reduced super I/O Video: TI TS3DV520 5-Channel differential 10:20 multiplexer switch for DVI/HDMI applications (Single pin SEL signal) (x2) California Micro Devices CM1213 4-channel low capacitance ESD protection arrays California Micro Devices CM2009 VGA port companion circuit Silicon Image Sil1930CMU TDMS ParallelLink uC: Atmel AT89C51ICS-VL 8-bit flash microcontroller with 2-wire interface Misc: TI SN74CBT3257 4-bit 1-of-2 FET multiplexer/demultiplexer (I2C?) Maxim MAX3892 10/100/1000 base-T ethernet LAN switch Global Mixed-mode Technology Inc G528 USB high-side switch Microchip 24LC08BI 8K I2C serial EEPROM Toshiba 7W125 dual bus buffer Audio: Realtek ALC833 Value 7.1+2 HD audio codec AKM AK4113VF 192kHz 24bit DIR with 6:1 selector Maxim 9710E 3W Mono/Steria BTL audio power amps -- 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 34110] 'high' profile does not set the engine and the memory clocks to the max value
https://bugs.freedesktop.org/show_bug.cgi?id=34110 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Alex Deucher 2011-02-09 14:13:53 PST --- The values set are not always exactly the the same as the values in the table, they are as close a possible within the constraints of the pll dividers. -- 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 33011] HDMI-A-1 Does not work after resume (But claims it does)
https://bugs.freedesktop.org/show_bug.cgi?id=33011 --- Comment #19 from Russ Dill 2011-02-09 14:14:14 PST --- Created an attachment (id=43178) --> (https://bugs.freedesktop.org/attachment.cgi?id=43178) DSDT -- 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: drm_open doesnt lock before increasing dev->open_count
perfect. the whole structure's much much clearer now thanks to just that comment. atleast that did it for me maybe move the "Typically we are called (via the driver) from drm_stub_open()" to the function annotation aswell but not strictly needed with the new comment On Tue, Feb 8, 2011 at 1:18 AM, Chris Wilson wrote: > On Tue, 08 Feb 2011 08:52:52 +1000, Dave Airlie > wrote: > > On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote: > > > is this a problem? before trying to submit a solution I wanted to make > sure with the experts > > > > > > it seems open_count isn't locked and can cause problems > > > > > > and if it is a problem, and needs to be solved, should locking be done > or is it better implemented with the (as I understand standard) kref? > > > > > > > Ickle? > > > > 1a72d65d6291ec248cbc5f05df2487edd714aba6 was your doing and I'm not > > entirely sure you actually checked all the paths looking back. > > Would this clarify matters? Perhaps there is some spare annotation that > could be used here as well? > > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c > index 2ec7d48..5b4ca5b 100644 > --- a/drivers/gpu/drm/drm_fops.c > +++ b/drivers/gpu/drm/drm_fops.c > @@ -125,6 +125,13 @@ int drm_open(struct inode *inode, struct file *filp) >struct drm_minor *minor; >int retcode = 0; > > + /* Typically we are called (via the driver) from drm_stub_open() > +* as their own fops->open and so already hold the global mutex. > +* Enforce this. > +*/ > + if (WARN_ON(!mutex_is_locked(&drm_global_mutex))) > + return -EINVAL; > + >minor = idr_find(&drm_minors_idr, minor_id); >if (!minor) >return -ENODEV; > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30402] xorg server fails to start when using xorg state tracker
https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #6 from Martin Stolpe 2011-02-09 14:22:08 PST --- (In reply to comment #5) > So it's fixed ? It's been a while since I was playing with the Xorg state tracker. It did work when I booted into the graphical mode using the xf86-video-ati driver, then quit the xserver and restarting the xserver with the Xorg state tracker. It didn't work after a reboot of the system. There is a little bit more information in this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=30406 -- 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 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #40 from Alex Deucher 2011-02-09 22:35:37 --- The following patches should fix it: http://lists.freedesktop.org/archives/dri-devel/2011-February/007976.html http://lists.freedesktop.org/archives/dri-devel/2011-February/008059.html -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb -- ___ 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
Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Wed, 2011-02-09 at 15:01 +, Chris Wilson wrote:
> The LVDS code ignores any connector for which it cannot find a fixed
> mode (through an EDID, vBIOS tables or the current active mode). Some
> platforms may include an LVDS header on the board and this may then be
> partnered with a panel without an EDID. This results in us ignoring the
> connector and not lighting up the panel.
Yeah not like this.
you want to make the command line the *last* option we use, the final
fallback. LVDS panels have EDID and VBT hardcoded modes for a good
reason, they don't work with other modes that well. You always want to
use a scaler on the LVDS panel to do modes not the native mode. So if I
have a VBT or EDID and you set video= I should get a scaled mode, not
garbage.
So what I suspect you really want is to leave video= alone or enhance it
somehow, or maybe add i915.lvds_native_mode= parameter.
Dave.
>
> Under UMS, it was possible to override this by specifying the mode
> through the Xorg.conf. For KMS, one specifies the modeline through the
> video= parameter. So we need to include this user modeline when checking
> for panel fixed modes.
>
> The machinery to parse the video= modes and generate the appropriate
> drm_mode is already built into drm_fb_herlper and so we can just
> extract, move it to the core and also use it from intel_lvds.c
>
> Reported-by: Oliver Seitz
> Signed-off-by: Chris Wilson
> Cc: Dave Airlie
> ---
> drivers/gpu/drm/drm_fb_helper.c | 207
> +++--
> drivers/gpu/drm/drm_modes.c | 154 +++
> drivers/gpu/drm/i915/intel_lvds.c | 17 +++
> include/drm/drmP.h| 25 +
> include/drm/drm_fb_helper.h | 16 +---
> 5 files changed, 233 insertions(+), 186 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6977a1c..5a80412 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -70,174 +70,50 @@ fail:
> }
> EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
>
> -/**
> - * drm_fb_helper_connector_parse_command_line - parse command line for
> connector
> - * @connector - connector to parse line for
> - * @mode_option - per connector mode option
> - *
> - * This parses the connector specific then generic command lines for
> - * modes and options to configure the connector.
> - *
> - * This uses the same parameters as the fb modedb.c, except for extra
> - * x[M][R][-][@][i][m][eDd]
> - *
> - * enable/enable Digital/disable bit at the end
> - */
> -static bool drm_fb_helper_connector_parse_command_line(struct
> drm_fb_helper_connector *fb_helper_conn,
> -const char *mode_option)
> -{
> - const char *name;
> - unsigned int namelen;
> - int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
> - unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
> - int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
> - int i;
> - enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
> - struct drm_fb_helper_cmdline_mode *cmdline_mode;
> - struct drm_connector *connector;
> -
> - if (!fb_helper_conn)
> - return false;
> - connector = fb_helper_conn->connector;
> -
> - cmdline_mode = &fb_helper_conn->cmdline_mode;
> - if (!mode_option)
> - mode_option = fb_mode_option;
> -
> - if (!mode_option) {
> - cmdline_mode->specified = false;
> - return false;
> - }
> -
> - name = mode_option;
> - namelen = strlen(name);
> - for (i = namelen-1; i >= 0; i--) {
> - switch (name[i]) {
> - case '@':
> - namelen = i;
> - if (!refresh_specified && !bpp_specified &&
> - !yres_specified) {
> - refresh = simple_strtol(&name[i+1], NULL, 10);
> - refresh_specified = 1;
> - if (cvt || rb)
> - cvt = 0;
> - } else
> - goto done;
> - break;
> - case '-':
> - namelen = i;
> - if (!bpp_specified && !yres_specified) {
> - bpp = simple_strtol(&name[i+1], NULL, 10);
> - bpp_specified = 1;
> - if (cvt || rb)
> - cvt = 0;
> - } else
> - goto done;
> - break;
> - case 'x':
> - if (!yres_specified) {
> - yres = simple_strtol(&name[i+1], NULL, 10);
> - yres_specified = 1;
> - } else
> - goto done;
> - cas
Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wed, Feb 9, 2011 at 2:43 PM, Hans Verkuil wrote: > On Wednesday, February 09, 2011 20:00:38 Matt Turner wrote: >> On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher wrote: >> > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: >> >> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: >> >>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: >> >>> > Just two quick notes. I'll try to do a full review this weekend. >> >>> > >> >>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: >> >>> >> == >> >>> >> Introduction >> >>> >> == >> >>> >> >> >>> >> The purpose of this RFC is to discuss the driver for a TV output >> >>> >> interface >> >>> >> available in upcoming Samsung SoC. The HW is able to generate digital >> >>> >> and >> >>> >> analog signals. Current version of the driver supports only digital >> >>> >> output. >> >>> >> >> >>> >> Internally the driver uses videobuf2 framework, and CMA memory >> >>> >> allocator. >> >>> > Not >> >>> >> all of them are merged by now, but I decided to post the sources to >> >>> >> start >> >>> >> discussion driver's design. >> >> >> >>> > >> >>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope >> >>> > to post >> >>> > an RFC by the end of this month. We also have a proposal for CEC >> >>> > support in >> >>> > the pipeline. >> >>> >> >>> Any reason to not use the drm kms APIs for modesetting, display >> >>> configuration, and hotplug support? We already have the >> >>> infrastructure in place for complex display configurations and >> >>> generating events for hotplug interrupts. It would seem to make more >> >>> sense to me to fix any deficiencies in the KMS APIs than to spin a new >> >>> API. Things like CEC would be a natural fit since a lot of desktop >> >>> GPUs support hdmi audio/3d/etc. and are already using kms. >> >>> >> >>> Alex >> >> >> >> I'll toss one out: lack of API documentation for driver or application >> >> developers to use. >> >> >> >> >> >> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to >> >> possibly get rid of reliance on the ivtv X video driver >> >> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation >> >> was really sparse. >> >> >> >> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but >> >> the userland API wasn't fleshed out. GEM was talked about a bit in >> >> there as well, IIRC. >> >> >> >> TTM documentation was essentially non-existant. >> >> >> >> I can't find any KMS documentation either. >> >> >> >> I recall having to read much of the drm code, and having to look at the >> >> radeon driver, just to tease out what the DRM ioctls needed to do. >> >> >> >> Am I missing a Documentation source for the APIs? >> >> Yes, >> >> My summer of code project's purpose was to create something of a >> tutorial for writing a KMS driver. The code, split out into something >> like 15 step-by-step patches, and accompanying documentation are >> available from Google's website. >> >> http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz > > Nice! > > What I still don't understand is if and how this is controlled via userspace. > > Is there some documentation of the userspace API somewhere? At the moment, it's only used by Xorg ddxes and the plymouth bootsplash. For details see: http://cgit.freedesktop.org/plymouth/tree/src/plugins/renderers/drm http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/drmmode_display.c > >> My repository (doesn't include the documentation) is available here: >> http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary >> >> There's a 'rebased' branch that contains API changes required for the >> code to work with 2.6.37~. >> >> I hope it's useful to you. >> >> I can't image how the lack of documentation of an used and tested API >> could be a serious reason to write you own. > > That never was the main reason. It doesn't help, though. > >> That makes absolutely no >> sense to me, so I hope you'll decide to use KMS. > > No, we won't. A GPU driver != a V4L driver. The primary purpose of a V4L2 > display driver is to output discrete frames from memory to some device. This > may be a HDMI transmitter, a SDTV transmitter, a memory-to-memory codec, an > FPGA, whatever. In other words, there is not necessarily a monitor on the > other > end. We have for some time now V4L2 APIs to set up video formats. The original > ioctl was VIDIOC_G/S_STD to select PAL/NTSC/SECAM. The new ones are > VIDIOC_G/S_DV_PRESETS which set up standard formats (1080p60, 720p60, etc) and > DV_TIMINGS which can be used for custom bt.656/1120 digital video timings. > > Trying to mix KMS into the V4L2 API is just a recipe for disaster. Just think > about what it would mean for DRM if DRM would use the V4L2 API for setting > video modes. That would be a disaster as well. I still think there's room for cooperation here. There are GPUs out there that
[Bug 33296] gnome-shell broken possibly due to glReadPixels() error
https://bugs.freedesktop.org/show_bug.cgi?id=33296 Sam Thursfield changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Sam Thursfield 2011-02-09 16:02:26 PST --- All problems have disappeared with the latest r300g driver. Thanks guys. -- 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 26552] Screen flickering with 2.6.37 [ATI X1600]
https://bugzilla.kernel.org/show_bug.cgi?id=26552 --- Comment #41 from Helber Maciel Guerra 2011-02-10 00:20:27 --- OK. tested on git tree, solve problem. Tanks, Helber Maciel Guerra. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb -- ___ 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
[Bug 31732] [RADEON:KMS:RS780:R600C-R600G] X crashes with "X: radeon_texture.c:682: radeon_store_teximage: Assertion `0' failed."
https://bugs.freedesktop.org/show_bug.cgi?id=31732 --- Comment #10 from Alex Schuster 2011-02-09 17:19:21 PST --- Whoops, thanks for reminding me. I was using the fglrx driver, it was very stable, but somehow it seems that there is a memory problem, my system was swapping a lot after a day of being logged into KDE4. So I tried the radeon driver again. And it seems to work now, I did not have a crash since. No __glXDRIbindTexImage messaegs any more. There are some slight graphics distortions, mostly when scrolling stuff. But this effect does not always happen and had been much, much worse half a year ago, so I do not care much. Oh, now that I try it I see that Quake3 is really slow, about 5 FPS. Nexuiz has 10 FPS and is also unplayable. That's bad. KDE4 desktop effets are okay though. X uses about 20% CPU when I have them enabled, that's a little high, but I think it was the same with fglrx. I am now running xorg-server 1.7.7-r1, mesa 7.10, radeon 6.14.0. This gallium stuff is disabled. -- 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: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wed, 2011-02-09 at 02:12 -0500, Alex Deucher wrote: > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: > > On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: > >> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: > >> > Just two quick notes. I'll try to do a full review this weekend. > >> > > >> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: > >> >> == > >> >> Introduction > >> >> == > >> >> > >> >> The purpose of this RFC is to discuss the driver for a TV output > >> >> interface > >> >> available in upcoming Samsung SoC. The HW is able to generate digital > >> >> and > >> >> analog signals. Current version of the driver supports only digital > >> >> output. > >> >> > >> >> Internally the driver uses videobuf2 framework, and CMA memory > >> >> allocator. > >> > Not > >> >> all of them are merged by now, but I decided to post the sources to > >> >> start > >> >> discussion driver's design. > > > >> > > >> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to > >> > post > >> > an RFC by the end of this month. We also have a proposal for CEC support > >> > in > >> > the pipeline. > >> > >> Any reason to not use the drm kms APIs for modesetting, display > >> configuration, and hotplug support? We already have the > >> infrastructure in place for complex display configurations and > >> generating events for hotplug interrupts. It would seem to make more > >> sense to me to fix any deficiencies in the KMS APIs than to spin a new > >> API. Things like CEC would be a natural fit since a lot of desktop > >> GPUs support hdmi audio/3d/etc. and are already using kms. > >> > >> Alex > > > > I'll toss one out: lack of API documentation for driver or application > > developers to use. > > > > > > When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to > > possibly get rid of reliance on the ivtv X video driver > > http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation > > was really sparse. > > > > DRM had the most documentation under Documentation/DocBook/drm.tmpl, but > > the userland API wasn't fleshed out. GEM was talked about a bit in > > there as well, IIRC. > > > > TTM documentation was essentially non-existant. > > > > I can't find any KMS documentation either. > > > > I recall having to read much of the drm code, and having to look at the > > radeon driver, just to tease out what the DRM ioctls needed to do. > > > > Am I missing a Documentation source for the APIs? > > > > Documentation is somewhat sparse compared to some other APIs. Mostly > inline kerneldoc comments in the core functions. It would be nice to > improve things. The modesetting API is very similar to the xrandr > API in the xserver. > > At the moment a device specific surface manager (Xorg ddx, or some > other userspace lib) is required to use kms due to device specific > requirements with respect to memory management and alignment for > acceleration. The kms modesetting ioctls are common across all kms > drm drivers, but the memory management ioctls are device specific. > GEM itself is an Intel-specific memory manager, although radeon uses > similar ioctls. TTM is used internally by radeon, nouveau, and svga > for managing memory gpu accessible memory pools. Drivers are free to > use whatever memory manager they want; an existing one shared with a > v4l or platform driver, TTM, or something new. > There is no generic > userspace kms driver/lib although Dave and others have done some work > to support that, but it's really hard to make a generic interface > flexible enough to handle all the strange acceleration requirements of > GPUs. All of the above unfortunately says to me that the KMS API has a fairly tightly coupled set of userspace components, because userspace applications need have details about the specific underlying hardware embeeded in the application to effectively use the API. If so, that's not really conducive to getting application developers to write applications to the API, since applications will get tied to specific sets of hardware. Lack of documentation on the API for userpace application writers to use exacerbates that issue, as there are no clearly stated guarantees on device node conventions ioctl's arguments and bounds on the arguments expected error return values behavior on error return and meaning of error return which are mandatory, which are optional how to perform "atomic" transactions Behavior of other fops: Are multiple opens allowed or not? Is llseek() meaningful? Is poll() meaningful? Does final close() deallocate all memory objects? sysfs nodes location expected names data formats how compliant or not any one driver is with the KMS APIcontrol
[PATCH] drm/radeon: fix race between GPU reset and TTM delayed delete thread.
From: Dave Airlie
My evergreen has been in a remote PC for week and reset has never once
saved me from certain doom, I finally relocated to the box with a
serial cable and noticed an oops when the GPU resets, and the TTM
delayed delete thread tries to remove something from the GTT.
This stops the delayed delete thread from executing across the GPU
reset handler, and woot I can GPU reset now.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_device.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 0d47893..4954e2d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -936,8 +936,11 @@ int radeon_resume_kms(struct drm_device *dev)
int radeon_gpu_reset(struct radeon_device *rdev)
{
int r;
+ int resched;
radeon_save_bios_scratch_regs(rdev);
+ /* block TTM */
+ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
radeon_suspend(rdev);
r = radeon_asic_reset(rdev);
@@ -946,6 +949,7 @@ int radeon_gpu_reset(struct radeon_device *rdev)
radeon_resume(rdev);
radeon_restore_bios_scratch_regs(rdev);
drm_helper_resume_force_mode(rdev->ddev);
+ ttm_bo_unlock_delayed_workqueue(&rdev->mman.bdev, resched);
return 0;
}
/* bad news, how to tell it to userspace ? */
--
1.7.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BISECTED] commit 619efb1059 makes the MacBookPro2, 2 screen flicker like its broken or half plugged in
On Feb 9, 2011, at 2:09 PM, Alex Deucher wrote: On Tue, Feb 8, 2011 at 4:20 PM, Alex Deucher wrote: On Tue, Feb 8, 2011 at 3:52 PM, Justin P. Mattock wrote: With the current HEAD Im getting screen flickering really bad to point where it looks like the screen is damaged and/or half plugged-in etc.. the bisect pointed to here: commit 619efb105924d8cafa0c1dd9389e9ab506f5425d doing a git revert 619efb10592 gets the screen working properly again. I havent looked much through the code to see if I can fix this. for the time being I'll revert this on my machine with the current, until later on. The attached patch should fix it assuming I got your pci ids correct. I'm done with the pll stuff; too may fixes break other boards. Just add a quirk table and be done with it. The attached patch builds on the previous one and fixes an additional regression. Alex <0001-drm-radeon-kms-pll-quirk-cleanup.patch> alright... didn't mean to keep you waiting(out of my office for most of the day).. Anyways patch applied, and everything looks good no screen jitters or flickering etc.. Reported-and-Tested-by: Justin P. Mattock Thanks for sending this my way so my machine works.. cheers, Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 23513] Radeon AGP KMS don't work or is too slow.
https://bugs.freedesktop.org/show_bug.cgi?id=23513 --- Comment #3 from gijs.hillen...@gmail.com 2011-02-09 23:16:22 PST --- On the thinkwiki mailing list, there are a few more users reporting this, including me. Running Debian/testing & unstable (I guess that says enough) on a Thinkpad Z61m. which has a VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400. KMS is enabled by default on Linux kernel 2.6.32-5-68, and on Testing/Unstable X (X.Org X Server 1.9.4) won't work if you disable it.. My previous work-around (disabling KMS in /etc/modprobe/radeon-kms.conf) had to be undone. It currently boots fine, but the screen will start flickering after a while. Sometimes the flickering is so fast everything turns into a blur, and sometimes you can still see what is on the screen.. Not sure what is the matter, but on the thinkwiki mailing list it was described as: "The GPU loses somehow its synchronization over time." It resets if I close the lid of the laptop. But it is no fun doing that every 30 seconds or so :-)... -- 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 23513] Radeon AGP KMS don't work or is too slow.
https://bugs.freedesktop.org/show_bug.cgi?id=23513 --- Comment #4 from Alex Deucher 2011-02-09 23:21:41 PST --- (In reply to comment #3) > On the thinkwiki mailing list, there are a few more users reporting this, > including me. > > Running Debian/testing & unstable (I guess that says enough) on a Thinkpad > Z61m. > which has a VGA compatible controller: ATI Technologies Inc Radeon Mobility > X1400. KMS is enabled by default on Linux kernel 2.6.32-5-68, and on > Testing/Unstable X (X.Org X Server 1.9.4) won't work if you disable it.. Your cards are not AGP and the symptoms are not related to this bug at all. Please file a new bug and include your xorg log and dmesg output. -- 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
[PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: > On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: >> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: >> > Just two quick notes. I'll try to do a full review this weekend. >> > >> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: >> >> == >> >> ?Introduction >> >> == >> >> >> >> The purpose of this RFC is to discuss the driver for a TV output interface >> >> available in upcoming Samsung SoC. The HW is able to generate digital and >> >> analog signals. Current version of the driver supports only digital >> >> output. >> >> >> >> Internally the driver uses videobuf2 framework, and CMA memory allocator. >> > Not >> >> all of them are merged by now, but I decided to post the sources to start >> >> discussion driver's design. > >> > >> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to >> > post >> > an RFC by the end of this month. We also have a proposal for CEC support in >> > the pipeline. >> >> Any reason to not use the drm kms APIs for modesetting, display >> configuration, and hotplug support? ?We already have the >> infrastructure in place for complex display configurations and >> generating events for hotplug interrupts. ?It would seem to make more >> sense to me to fix any deficiencies in the KMS APIs than to spin a new >> API. ?Things like CEC would be a natural fit since a lot of desktop >> GPUs support hdmi audio/3d/etc. and are already using kms. >> >> Alex > > I'll toss one out: lack of API documentation for driver or application > developers to use. > > > When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to > possibly get rid of reliance on the ivtv X video driver > http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation > was really sparse. > > DRM had the most documentation under Documentation/DocBook/drm.tmpl, but > the userland API wasn't fleshed out. ?GEM was talked about a bit in > there as well, IIRC. > > TTM documentation was essentially non-existant. > > I can't find any KMS documentation either. > > I recall having to read much of the drm code, and having to look at the > radeon driver, just to tease out what the DRM ioctls needed to do. > > Am I missing a Documentation source for the APIs? > Documentation is somewhat sparse compared to some other APIs. Mostly inline kerneldoc comments in the core functions. It would be nice to improve things. The modesetting API is very similar to the xrandr API in the xserver. At the moment a device specific surface manager (Xorg ddx, or some other userspace lib) is required to use kms due to device specific requirements with respect to memory management and alignment for acceleration. The kms modesetting ioctls are common across all kms drm drivers, but the memory management ioctls are device specific. GEM itself is an Intel-specific memory manager, although radeon uses similar ioctls. TTM is used internally by radeon, nouveau, and svga for managing memory gpu accessible memory pools. Drivers are free to use whatever memory manager they want; an existing one shared with a v4l or platform driver, TTM, or something new. There is no generic userspace kms driver/lib although Dave and others have done some work to support that, but it's really hard to make a generic interface flexible enough to handle all the strange acceleration requirements of GPUs. kms does however provide a legacy kernel fb interface. While the documentation is not great, the modesetting API is solid and it would be nice to get more people involved and working on it (or at least looking at it) rather than starting something equivalent from scratch or implementing a device specific modesetting API. If you have any questions about it, please ask on dri-devel (CCed). Alex > > > For V4L2 and DVB on ther other hand, one can point to pretty verbose > documentation that application developers can use: > > ? ? ? ?http://linuxtv.org/downloads/v4l-dvb-apis/ > > > > Regards, > Andy > > >
[Bug 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #3 from Pavel Ondra?ka 2011-02-09 00:34:57 PST --- Created an attachment (id=43151) --> (https://bugs.freedesktop.org/attachment.cgi?id=43151) output of RADEON_DEBUG=fp,vp with mesa master -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #4 from Pavel Ondra?ka 2011-02-09 00:35:42 PST --- Created an attachment (id=43152) --> (https://bugs.freedesktop.org/attachment.cgi?id=43152) output of RADEON_DEBUG=fp,vp with mesa master and 8f32c6cfc6503dd234f09fb06941803866c23c65 reverted -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #5 from Tom Stellard 2011-02-09 01:46:08 PST --- Created an attachment (id=43154) View: https://bugs.freedesktop.org/attachment.cgi?id=43154 Review: https://bugs.freedesktop.org/review?bug=34030&attachment=43154 Possible Fix This patch should be applied to the master branch. Does it fix the problem? If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34030] [bisected] Starcraft 2: some effects are corrupted or too big
https://bugs.freedesktop.org/show_bug.cgi?id=34030 --- Comment #6 from Pavel Ondra?ka 2011-02-09 02:05:40 PST --- (In reply to comment #5) > Created an attachment (id=43154) View: https://bugs.freedesktop.org/attachment.cgi?id=43154 Review: https://bugs.freedesktop.org/review?bug=34030&attachment=43154 > Possible Fix > > This patch should be applied to the master branch. Does it fix the problem? > If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied. Yes, this patch fixes the problem. Thank you. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27524] linux-2.6.33.2 radeondrm_fb, rv350, garbled console on PowerBook G4
https://bugs.freedesktop.org/show_bug.cgi?id=27524 --- Comment #14 from Michel D?nzer 2011-02-09 02:09:54 PST --- This is working for me in recent kernels. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
