Re: 3D support for Displaylink devices
On 03-06-2011 00:16, Alan Cox wrote: The window system needs support for splitting rendering and display. In X these are currently tied together. The only real obstacle is fixing this in X. However, this is a lot of work. Dave Airlie has started working on this, but it's not really usable yet. See: http://airlied.livejournal.com/71734.html http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer In the windows world it basically works by 'borrowing' the real graphics card for rendering and then doing the damage list/compression/uplink. So its basically a *very* strange CRTC/scanout. To most intents and purposes plugging one into an i915 say is an extra i915 head, and indeed you can sensibly display the same scanout buffer on both real and link heads. Alan Why not tell X that DisplayLink device connected is a monitor (like connecting a projector) so that Intel driver will take care of all the 3D support (at least for Compiz) and video acceleration, only mode setting and data transfer from memory can be taken care by a DisplayLink driver. This may be a **very** bad way of implementing and may be hypothetical but if there is a possibility it will dramatically improve multi monitor support in X. I guess "Rotate and Resize" extensions can be supported easily if such a thing is implemented. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Trivial PATCH 0/5] treewide: Use angle brackets for system includes
Just neatening. Joe Perches (5): drbd: Use angle brackets for system includes drm: Use angle brackets for system includes aix94xx: Use angle brackets for system includes ALSA: asihpi: Use angle brackets for system includes staging: msm: Use angle brackets for system includes drivers/block/drbd/drbd_int.h |2 +- drivers/block/drbd/drbd_nl.c |4 ++-- drivers/gpu/drm/drm_ioctl.c |2 +- drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++-- drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +- drivers/gpu/drm/ttm/ttm_agp_backend.c |6 +++--- drivers/gpu/drm/ttm/ttm_bo.c |6 +++--- drivers/gpu/drm/ttm/ttm_bo_manager.c |6 +++--- drivers/gpu/drm/ttm/ttm_bo_util.c |4 ++-- drivers/gpu/drm/ttm/ttm_execbuf_util.c|6 +++--- drivers/gpu/drm/ttm/ttm_lock.c|4 ++-- drivers/gpu/drm/ttm/ttm_memory.c |6 +++--- drivers/gpu/drm/ttm/ttm_module.c |2 +- drivers/gpu/drm/ttm/ttm_object.c |4 ++-- drivers/gpu/drm/ttm/ttm_page_alloc.c |4 ++-- drivers/gpu/drm/ttm/ttm_tt.c |8 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c|4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |6 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |4 ++-- drivers/scsi/aic94xx/aic94xx_dump.c |2 +- drivers/staging/msm/ebi2_l2f.c|2 +- drivers/staging/msm/ebi2_tmd20.c |2 +- drivers/staging/msm/mddihost.h|2 +- drivers/staging/msm/mdp_ppp.c |2 +- drivers/staging/msm/mdp_ppp_v20.c |2 +- drivers/staging/msm/mdp_ppp_v31.c |2 +- drivers/staging/msm/msm_fb.h |2 +- include/drm/ttm/ttm_bo_driver.h | 12 ++-- include/drm/ttm/ttm_execbuf_util.h|2 +- include/drm/ttm/ttm_lock.h|2 +- include/linux/drbd_tag_magic.h|2 +- sound/pci/asihpi/hpidspcd.c |2 +- 39 files changed, 80 insertions(+), 80 deletions(-) -- 1.7.5.rc3.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Trivial PATCH 2/5] drm: Use angle brackets for system includes
Use the normal include style.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_ioctl.c |2 +-
drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c |6 +++---
drivers/gpu/drm/ttm/ttm_bo.c |6 +++---
drivers/gpu/drm/ttm/ttm_bo_manager.c |6 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c |4 ++--
drivers/gpu/drm/ttm/ttm_execbuf_util.c|6 +++---
drivers/gpu/drm/ttm/ttm_lock.c|4 ++--
drivers/gpu/drm/ttm/ttm_memory.c |6 +++---
drivers/gpu/drm/ttm/ttm_module.c |2 +-
drivers/gpu/drm/ttm/ttm_object.c |4 ++--
drivers/gpu/drm/ttm/ttm_page_alloc.c |4 ++--
drivers/gpu/drm/ttm/ttm_tt.c |8
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c|4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |4 ++--
include/drm/ttm/ttm_bo_driver.h | 12 ++--
include/drm/ttm/ttm_execbuf_util.h|2 +-
include/drm/ttm/ttm_lock.h|2 +-
27 files changed, 67 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..ab230ea 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,7 +36,7 @@
#include "drmP.h"
#include "drm_core.h"
-#include "linux/pci.h"
+#include
/**
* Get the bus id.
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 82d70fd..9d13be4 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -25,8 +25,8 @@
*
*/
-#include "linux/string.h"
-#include "linux/bitops.h"
+#include
+#include
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 9c56331..37998f6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -39,11 +39,11 @@
#define NOUVEAU_FAMILY 0x
#define NOUVEAU_FLAGS0x
-#include "ttm/ttm_bo_api.h"
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
-#include "ttm/ttm_memory.h"
-#include "ttm/ttm_module.h"
+#include
+#include
+#include
+#include
+#include
struct nouveau_fpriv {
struct ttm_object_file *tfile;
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 1c4a72f..7d9e531 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -29,10 +29,10 @@
* Keith Packard.
*/
-#include "ttm/ttm_module.h"
-#include "ttm/ttm_bo_driver.h"
+#include
+#include
#ifdef TTM_HAS_AGP
-#include "ttm/ttm_placement.h"
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2e618b5..021976e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -28,9 +28,9 @@
* Authors: Thomas Hellstrom
*/
-#include "ttm/ttm_module.h"
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
+#include
+#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 038e947..0fe5cec 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -28,9 +28,9 @@
* Authors: Thomas Hellstrom
*/
-#include "ttm/ttm_module.h"
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
+#include
+#include
+#include
#include "drm_mm.h"
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 77dbf40..b6285d7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -28,8 +28,8 @@
* Authors: Thomas Hellstrom
*/
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
+#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3832fe1..2a17bbc 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -25,9 +25,9 @@
*
**/
-#include "ttm/ttm_execbuf_util.h"
-#include "ttm/ttm_bo_driver.h"
[PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 872747c..21058e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1113,7 +1113,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
if (card_res->count_fbs >= fb_count) {
copied = 0;
fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
- list_for_each_entry(fb, &file_priv->fbs, head) {
+ list_for_each_entry(fb, &file_priv->fbs, filp_head) {
if (put_user(fb->base.id, fb_id + copied)) {
ret = -EFAULT;
goto out;
--
1.7.5.3
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 --- Comment #16 from Seth Forshee 2011-06-03 13:53:31 --- Adding here some of the information that I added to the freedesktop.org bugzilla here: https://bugs.freedesktop.org/show_bug.cgi?id=36003 It seems to me that nothing being done currently in the radeon and switcheroo code guarantees that the ATI card is powered on before probing the hardware. I tried adding a call to the ATPX method to turn on power from radeon_register_atpx_handler(), but this doesn't seem to be helping. Can anyone comment on what steps need to be taken to ensure that the card is powered on before proceeding with hardware initialization? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3D support for Displaylink devices
On Fri, Jun 3, 2011 at 5:00 AM, Prasanna Kumar T S M wrote: > On 03-06-2011 00:16, Alan Cox wrote: >>> >>> The window system needs support for splitting rendering and display. >>> In X these are currently tied together. The only real obstacle is >>> fixing this in X. However, this is a lot of work. Dave Airlie has >>> started working on this, but it's not really usable yet. See: >>> http://airlied.livejournal.com/71734.html >>> http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer >> >> In the windows world it basically works by 'borrowing' the real graphics >> card for rendering and then doing the damage list/compression/uplink. >> >> So its basically a *very* strange CRTC/scanout. To most intents and >> purposes plugging one into an i915 say is an extra i915 head, and indeed >> you can sensibly display the same scanout buffer on both real and link >> heads. >> >> Alan >> > Why not tell X that DisplayLink device connected is a monitor (like > connecting a projector) so that Intel driver will take care of all the 3D > support (at least for Compiz) and video acceleration, only mode setting and > data transfer from memory can be taken care by a DisplayLink driver. This > may be a **very** bad way of implementing and may be hypothetical but if > there is a possibility it will dramatically improve multi monitor support in > X. I guess "Rotate and Resize" extensions can be supported easily if such a > thing is implemented. > Patches welcome. It's still a lot of work. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/atom: initialize dig phy a bit later
On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen wrote: > Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors > attached to a dual head radeon gpu to have inverted colors (until the first > suspend/resume). Initializing dig phy a bit later fixes the problem. Strange, I don't see why that would make a difference, I guess perhaps there's some strange interaction between the hpd setup or the initial clock/voltage setup on DCE5 hw. What chip are you using? Anyway, should be fine. Acked-by: Alex Deucher > > --- > drivers/gpu/drm/radeon/radeon_display.c | 8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c > b/drivers/gpu/drm/radeon/radeon_display.c > index ae247ee..ddff2cf 100644 > --- a/drivers/gpu/drm/radeon/radeon_display.c > +++ b/drivers/gpu/drm/radeon/radeon_display.c > @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) > return ret; > } > > - /* init dig PHYs */ > - if (rdev->is_atom_bios) > - radeon_atom_encoder_init(rdev); > - > /* initialize hpd */ > radeon_hpd_init(rdev); > > @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) > radeon_fbdev_init(rdev); > drm_kms_helper_poll_init(rdev->ddev); > > + /* init dig PHYs */ > + if (rdev->is_atom_bios) > + radeon_atom_encoder_init(rdev); > + > return 0; > } > > -- > 1.7.4.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Trivial PATCH 2/5] drm: Use angle brackets for system includes
On Fri, 3 Jun 2011 02:28:47 -0700, Joe Perches wrote: > drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++-- Acked-by: Keith Packard Dave -- if you want to just merge this to your tree, that's fine with me. -- keith.pack...@intel.com pgpfKcfQohl1E.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH]remove warning for drivers/gpu/drm/i915/intel_ringbuffer.c
On Fri, 3 Jun 2011 21:09:39 +0800, Harry Wei wrote: (process:18294): gmime-CRITICAL **: g_mime_stream_filter_add: assertion `GMIME_IS_FILTER (filter)' failed > From: Harry Wei > When i compile kernel, it shows me two warnings > like below, so this patch can fix them. This fix is already upstream; it wasn't included in the stable patch as it wasn't 'necessary' to fix the bug which is causing the warning (which ended up removing the last use of this function). -- keith.pack...@intel.com pgpPWyDM6d8Zi.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled
https://bugs.freedesktop.org/show_bug.cgi?id=37220 --- Comment #4 from Jure Repinc 2011-06-03 10:52:24 PDT --- I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg server is 1.10.2, Linux kernel is 2.6.38.4 and KDE us also 4.6.3 -- 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 37785] [r600g Evergreen] GPU lockup on Blender 2.57 when moving objects
https://bugs.freedesktop.org/show_bug.cgi?id=37785 Antti Lahtinen changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Antti Lahtinen 2011-06-03 11:47:46 PDT --- It seems this was fixed by: b5518834e3ae117eafb32cfc5c7e7af51b4a1078 r600g: cs init fixes 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
Re: [PATCH] drm/radeon/kms/atom: initialize dig phy a bit later
I'm using ASUS EAH3650SILENTMG/HTDP. I got the feeling that in my case, radeon_atom_encoder_prepare needed to be called before radeon_atom_encoder_init (the call occurred during radeon_fbdev_init). That ensured radeon_encoder->enc_priv->dig_encoder to have a value other than -1 in the first call of atombios_dig_transmitter_setup (with action=ATOM_TRANSMITTER_ACTION_INIT). But I don't know the code well enough to be sure about that. Ari 2011/6/3 Alex Deucher : > On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen > wrote: >> Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors >> attached to a dual head radeon gpu to have inverted colors (until the first >> suspend/resume). Initializing dig phy a bit later fixes the problem. > > Strange, I don't see why that would make a difference, I guess perhaps > there's some strange interaction between the hpd setup or the initial > clock/voltage setup on DCE5 hw. What chip are you using? > > Anyway, should be fine. > > Acked-by: Alex Deucher > >> >> --- >> drivers/gpu/drm/radeon/radeon_display.c | 8 >> 1 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_display.c >> b/drivers/gpu/drm/radeon/radeon_display.c >> index ae247ee..ddff2cf 100644 >> --- a/drivers/gpu/drm/radeon/radeon_display.c >> +++ b/drivers/gpu/drm/radeon/radeon_display.c >> @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) >> return ret; >> } >> >> - /* init dig PHYs */ >> - if (rdev->is_atom_bios) >> - radeon_atom_encoder_init(rdev); >> - >> /* initialize hpd */ >> radeon_hpd_init(rdev); >> >> @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) >> radeon_fbdev_init(rdev); >> drm_kms_helper_poll_init(rdev->ddev); >> >> + /* init dig PHYs */ >> + if (rdev->is_atom_bios) >> + radeon_atom_encoder_init(rdev); >> + >> return 0; >> } >> >> -- >> 1.7.4.1 >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/atom: initialize dig phy a bit later
On Fri, Jun 3, 2011 at 4:03 PM, Ari Savolainen wrote: > I'm using ASUS EAH3650SILENTMG/HTDP. > > I got the feeling that in my case, radeon_atom_encoder_prepare needed to be > called before radeon_atom_encoder_init (the call occurred during > radeon_fbdev_init). That ensured radeon_encoder->enc_priv->dig_encoder to have > a value other than -1 in the first call of atombios_dig_transmitter_setup > (with > action=ATOM_TRANSMITTER_ACTION_INIT). But I don't know the code well enough > to > be sure about that. NACK on the patch for now. Let's try and sort this out. INIT needs to be called before the mode is set, so this needs to come before fbdev sets the mode. I'll send out a patch soon. Alex > > Ari > > 2011/6/3 Alex Deucher : >> On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen >> wrote: >>> Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors >>> attached to a dual head radeon gpu to have inverted colors (until the first >>> suspend/resume). Initializing dig phy a bit later fixes the problem. >> >> Strange, I don't see why that would make a difference, I guess perhaps >> there's some strange interaction between the hpd setup or the initial >> clock/voltage setup on DCE5 hw. What chip are you using? >> >> Anyway, should be fine. >> >> Acked-by: Alex Deucher >> >>> >>> --- >>> drivers/gpu/drm/radeon/radeon_display.c | 8 >>> 1 files changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/radeon/radeon_display.c >>> b/drivers/gpu/drm/radeon/radeon_display.c >>> index ae247ee..ddff2cf 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_display.c >>> +++ b/drivers/gpu/drm/radeon/radeon_display.c >>> @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) >>> return ret; >>> } >>> >>> - /* init dig PHYs */ >>> - if (rdev->is_atom_bios) >>> - radeon_atom_encoder_init(rdev); >>> - >>> /* initialize hpd */ >>> radeon_hpd_init(rdev); >>> >>> @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) >>> radeon_fbdev_init(rdev); >>> drm_kms_helper_poll_init(rdev->ddev); >>> >>> + /* init dig PHYs */ >>> + if (rdev->is_atom_bios) >>> + radeon_atom_encoder_init(rdev); >>> + >>> return 0; >>> } >>> >>> -- >>> 1.7.4.1 >>> >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/atom: fix PHY init
The PHY was not initialized correctly after
ac89af1e1010640db072416c786f97391b85790f since
the function bailed early as an encoder was not
assigned. The encoder isn't necessary for PHY init
so just assign to 0 for init so that the table
is executed.
Reported-by: Ari Savolainen
Cc: Ari Savolainen
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 13e4fa0..302248b 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -949,10 +949,15 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
int dp_lane_count = 0;
int connector_object_id = 0;
int igp_lane_info = 0;
+ int dig_encoder = dig->dig_encoder;
- if (action == ATOM_TRANSMITTER_ACTION_INIT)
+ if (action == ATOM_TRANSMITTER_ACTION_INIT) {
connector = radeon_get_connector_for_encoder_init(encoder);
- else
+ /* just needed to avoid bailing in the encoder check. the
encoder
+* isn't used for init
+*/
+ dig_encoder = 0;
+ } else
connector = radeon_get_connector_for_encoder(encoder);
if (connector) {
@@ -968,7 +973,7 @@ atombios_dig_transmitter_setup(struct drm_encoder *encoder,
int action, uint8_t
}
/* no dig encoder assigned */
- if (dig->dig_encoder == -1)
+ if (dig_encoder == -1)
return;
if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_DP)
@@ -1018,7 +1023,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
if (dig->linkb)
args.v3.acConfig.ucLinkSel = 1;
- if (dig->dig_encoder & 1)
+ if (dig_encoder & 1)
args.v3.acConfig.ucEncoderSel = 1;
/* Select the PLL for the PHY
@@ -1068,7 +1073,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
args.v3.acConfig.fDualLinkConnector = 1;
}
} else if (ASIC_IS_DCE32(rdev)) {
- args.v2.acConfig.ucEncoderSel = dig->dig_encoder;
+ args.v2.acConfig.ucEncoderSel = dig_encoder;
if (dig->linkb)
args.v2.acConfig.ucLinkSel = 1;
@@ -1095,7 +1100,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
} else {
args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
- if (dig->dig_encoder)
+ if (dig_encoder)
args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
else
args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/atom: fix PHY init
I tested the patch and it fixed the problem.
Thanks,
Ari
2011/6/3 Alex Deucher :
> The PHY was not initialized correctly after
> ac89af1e1010640db072416c786f97391b85790f since
> the function bailed early as an encoder was not
> assigned. The encoder isn't necessary for PHY init
> so just assign to 0 for init so that the table
> is executed.
>
> Reported-by: Ari Savolainen
>
> Cc: Ari Savolainen
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_encoders.c | 17 +++--
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
> b/drivers/gpu/drm/radeon/radeon_encoders.c
> index 13e4fa0..302248b 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -949,10 +949,15 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> int dp_lane_count = 0;
> int connector_object_id = 0;
> int igp_lane_info = 0;
> + int dig_encoder = dig->dig_encoder;
>
> - if (action == ATOM_TRANSMITTER_ACTION_INIT)
> + if (action == ATOM_TRANSMITTER_ACTION_INIT) {
> connector = radeon_get_connector_for_encoder_init(encoder);
> - else
> + /* just needed to avoid bailing in the encoder check. the
> encoder
> + * isn't used for init
> + */
> + dig_encoder = 0;
> + } else
> connector = radeon_get_connector_for_encoder(encoder);
>
> if (connector) {
> @@ -968,7 +973,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> }
>
> /* no dig encoder assigned */
> - if (dig->dig_encoder == -1)
> + if (dig_encoder == -1)
> return;
>
> if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_DP)
> @@ -1018,7 +1023,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
>
> if (dig->linkb)
> args.v3.acConfig.ucLinkSel = 1;
> - if (dig->dig_encoder & 1)
> + if (dig_encoder & 1)
> args.v3.acConfig.ucEncoderSel = 1;
>
> /* Select the PLL for the PHY
> @@ -1068,7 +1073,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> args.v3.acConfig.fDualLinkConnector = 1;
> }
> } else if (ASIC_IS_DCE32(rdev)) {
> - args.v2.acConfig.ucEncoderSel = dig->dig_encoder;
> + args.v2.acConfig.ucEncoderSel = dig_encoder;
> if (dig->linkb)
> args.v2.acConfig.ucLinkSel = 1;
>
> @@ -1095,7 +1100,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> } else {
> args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
>
> - if (dig->dig_encoder)
> + if (dig_encoder)
> args.v1.ucConfig |=
> ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
> else
> args.v1.ucConfig |=
> ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
> --
> 1.7.1.1
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36812] GPU lockup in Team Fortress 2
https://bugs.freedesktop.org/show_bug.cgi?id=36812 --- Comment #9 from Sven Arvidsson 2011-06-03 13:54:28 PDT --- I noticed that a few piglit tests causes GPU hang/resets when run with MESA_GLSL=nopt. Is this to be expected or is it worth to file bugs? The failing tests are glsl-fs-atan-2, glsl-fs-lots-of-tex, glsl-orangebook-ch06-bump and possibly others. They run without problems if nopt isn't used. -- 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: [PULL] drm-intel-next
Here's another handful of fixes that I had merged to drm-intel-next. Once these are merged, I'll move drm-intel-fixes and start putting stuff there for 3.0. The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0: drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge (2011-05-18 15:14:39 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Chris Wilson (5): drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/ drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0 drm/i915/crt: Explicitly return false if connected to a digital monitor drm/i915: Remove unused enum "chip_family" drm/i915: Share the common force-audio property between connectors Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler Daniel Vetter (3): drm/i915: Only print out the actual number of fences for i915_error_state drm/i915: not finding a fence is a non-recoverable condition drm/915: fix relaxed tiling on gen2: tile height Jason Stubbs (1): drm/i915: fix regression after clock gating init split Nicolas Kaiser (1): drm: i915: correct return status in intel_hdmi_mode_valid() drivers/gpu/drm/i915/i915_debugfs.c |2 +- drivers/gpu/drm/i915/i915_drv.h |8 +--- drivers/gpu/drm/i915/i915_gem.c | 28 +- drivers/gpu/drm/i915/i915_irq.c |2 +- drivers/gpu/drm/i915/intel_crt.c |4 ++ drivers/gpu/drm/i915/intel_display.c | 89 -- drivers/gpu/drm/i915/intel_dp.c | 15 +- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_hdmi.c| 16 +- drivers/gpu/drm/i915/intel_modes.c | 30 +++ drivers/gpu/drm/i915/intel_sdvo.c| 14 +- 11 files changed, 80 insertions(+), 129 deletions(-) -- keith.pack...@intel.com pgpifQuJdV3aE.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28622] radeon video lockup
https://bugzilla.kernel.org/show_bug.cgi?id=28622 --- Comment #9 from Daniel Poelzleithner 2011-06-04 00:34:36 --- the 2.6.38 was sligthly more stable then the 2.6.39 is. the current lockup shows: [17052.294941] runnable tasks: [17052.294942] task PID tree-key switches prio exec-runtime sum-execsum-sleep [17052.294943] -- [17052.294967] [17240.142256] SysRq : Show Blocked State [17240.142266] taskPC stack pid father [17240.142285] XorgD 8800c68b69d8 0 1979 1917 0x0044 [17240.142290] 8800c640d598 0082 8800 8800c640d538 [17240.142293] 0282 8800c640dfd8 8800c640c000 8800c640dfd8 [17240.142296] 81a0b020 8800c68b6640 81bf1f40 0001c640d5d0 [17240.142299] Call Trace: [17240.142306] [] schedule_timeout+0x173/0x2e0 [17240.142311] [] ? cascade+0xa0/0xa0 [17240.142348] [] radeon_fence_wait+0x1ee/0x3d0 [radeon] [17240.142352] [] ? wake_up_bit+0x40/0x40 [17240.142367] [] radeon_sync_obj_wait+0x11/0x20 [radeon] [17240.142377] [] ttm_bo_wait+0xfd/0x1b0 [ttm] [17240.142385] [] ttm_bo_move_accel_cleanup+0x226/0x2a0 [ttm] [17240.142399] [] radeon_move_blit.clone.0+0x120/0x180 [radeon] [17240.142414] [] radeon_bo_move+0xbb/0x180 [radeon] [17240.142422] [] ttm_bo_handle_move_mem+0x12e/0x360 [ttm] [17240.142425] [] ? _raw_spin_unlock_irqrestore+0x10/0x30 [17240.142432] [] ttm_bo_evict+0x150/0x360 [ttm] [17240.142439] [] ? ttm_eu_list_ref_sub+0x3b/0x50 [ttm] [17240.142445] [] ttm_mem_evict_first+0x1a6/0x250 [ttm] [17240.142452] [] ttm_bo_mem_space+0x2fd/0x390 [ttm] [17240.142459] [] ttm_bo_move_buffer+0xec/0x160 [ttm] [17240.142477] [] ? drm_mm_kmalloc+0x32/0xd0 [drm] [17240.142484] [] ttm_bo_validate+0x96/0x120 [ttm] [17240.142490] [] ttm_bo_init+0x2fe/0x380 [ttm] [17240.142505] [] radeon_bo_create+0x16d/0x270 [radeon] [17240.142520] [] ? radeon_create_ttm_backend_entry+0x50/0x50 [radeon] [17240.142537] [] radeon_gem_object_create+0x5d/0x100 [radeon] [17240.142554] [] radeon_gem_create_ioctl+0x58/0xd0 [radeon] [17240.142570] [] ? radeon_gem_wait_idle_ioctl+0xf9/0x120 [radeon] [17240.142581] [] drm_ioctl+0x3ec/0x4d0 [drm] [17240.142598] [] ? radeon_gem_pwrite_ioctl+0x30/0x30 [radeon] [17240.142602] [] ? __hrtimer_start_range_ns+0x193/0x460 [17240.142606] [] do_vfs_ioctl+0x8f/0x530 [17240.142610] [] ? vfs_read+0x120/0x180 [17240.142613] [] sys_ioctl+0x91/0xa0 [17240.142616] [] system_call_fastpath+0x16/0x1b i attach the full dmsg output -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28622] radeon video lockup
https://bugzilla.kernel.org/show_bug.cgi?id=28622 --- Comment #10 from Daniel Poelzleithner 2011-06-04 00:36:02 --- Created an attachment (id=60712) --> (https://bugzilla.kernel.org/attachment.cgi?id=60712) 2.6.39 lockup -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Questions about libdrm_intel and way to share physical memory between CPU and GPU
On Thu, 2 Jun 2011 19:42:03 +0100, Alan Cox wrote: > On Sat, 28 May 2011 09:54:01 +0100 > Chris Wilson wrote: > > > On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" > > wrote: > > > Hello gurus, > > > > > > I have two question mostly regarding libdrm_intel > > > > > > 1/ What is the difference between drm_intel_bo_map and > > > drm_intel_gem_bo_map_gtt ? > > bo_map uses the CPU domain, and so is CPU linear (needs sw detiling). > > bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear > > (detiling is performed by the hardware using a fence). > > > > > 2/ Will it be possible (or is it already possible) to directly share a > > > regularly allocated piece of physical memory? Typical use case is the > > > following one using OpenCL API: > > > > Yes. I've proposed a vmap interface to bind user-pages into the GTT, > > similar to a completely unused bit of TTM functionality. > > It seems to me that stolen memory and other things could all be sorted > out somewhat if the GEM layer and GEM as shmemfs backing were split apart > a bit. A 'privately backed' GEM object wouldn't be able to support > flink() but I can't find much else that would break ? > > Wondering about this for things like the GMA500, and also to get back all > that memory the i9xx driver burns on a PC. I'd much rather be able to just hand that memory off to the kernel to use along with everything else and have there be nothing magic about it. But as I recall, the mtrr mappings of that memory was often goofy, so it may take some work to clean it up. pgpHhXyCWlMXR.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Semantics of the 'dumb' interface
On Fri, Jun 3, 2011 at 4:37 AM, Alan Cox wrote: > I have GEM allocation working on the GMA 500 and I can scribble in a > framebuffer (minus an odd 'last page' bug which is an off by one > somewhere I imagine) and display it with nice modetest stripes. > > If I kill the program however it all goes kerblam > > drm_release calls into fb_release which duely destroys the user frame > buffer. This drops the gem object reference and we start to release all > the resources but it blows up because the GEM object is still pinned in > the GTT as it's still being used as scanout. > > Where I'm a bit lost right now is understanding what is supposed to > happen at this point, and how the scanout is supposed to have ended up > cleaned up and reset to the system frame buffer beforehand thus unpinning > the scanout from the GTT. I think the intel driver forces a reset to the system scanout on release. I've actually never found a test to indicate it was completely necessary on other GPUs since they scan out of real VRAM which isn't going to get unbound from the card. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37911] New: supertuxkart crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37911 Summary: supertuxkart crashes with r300g Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pawler...@gmail.com When I want to start a race in Supertuxkart it crashes: Irrlicht Engine version 1.8.0-alpha Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 Could not load sprite bank because the file does not exist: #DefaultFont [FileManager] Data files will be fetched from: '/usr/share/games/supertuxkart/' Env var LANG = 'pl_PL.UTF-8' Adding language fallback pl [IrrDriver] Creating NULL device Irrlicht Engine version 1.8.0-alpha Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 Could not load sprite bank because the file does not exist: #DefaultFont [IrrDriver] Trying OpenGL rendering. [IrrDriver] Trying to create device with 32 bits r300: DRM version: 2.8.0, Name: ATI RV530, ID: 0x71c0, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES Mesa: User error: GL_INVALID_ENUM in glProvokingVertexEXT(0xfeffb090) [IrrDriver Temp Logger] Level 3: Could not load sprite bank because the file does not exist: #DefaultFont Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT(textarget=0x3) Mesa: User error: GL_INVALID_ENUM in glFramebufferRenderbufferEXT(renderbufferTarget) [Irrlicht Error] FBO has invalid draw buffer [Irrlicht Error] FBO error supertuxkart: COpenGLTexture.cpp:888: bool irr::video::checkFBOStatus(irr::video::COpenGLDriver*): Warunek zapewnienia `!(true)' nie zosta? spe?niony. Przerwane I'm using this repository: https://launchpad.net/~oibaf/+archive/graphics-drivers/ -- 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] drm/radeon/kms/atom: initialize dig phy a bit later
Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors attached to a dual head radeon gpu to have inverted colors (until the first suspend/resume). Initializing dig phy a bit later fixes the problem. --- drivers/gpu/drm/radeon/radeon_display.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index ae247ee..ddff2cf 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) return ret; } - /* init dig PHYs */ - if (rdev->is_atom_bios) - radeon_atom_encoder_init(rdev); - /* initialize hpd */ radeon_hpd_init(rdev); @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) radeon_fbdev_init(rdev); drm_kms_helper_poll_init(rdev->ddev); + /* init dig PHYs */ + if (rdev->is_atom_bios) + radeon_atom_encoder_init(rdev); + return 0; } -- 1.7.4.1
3D support for Displaylink devices
On 03-06-2011 00:16, Alan Cox wrote: >> The window system needs support for splitting rendering and display. >> In X these are currently tied together. The only real obstacle is >> fixing this in X. However, this is a lot of work. Dave Airlie has >> started working on this, but it's not really usable yet. See: >> http://airlied.livejournal.com/71734.html >> http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer > In the windows world it basically works by 'borrowing' the real graphics > card for rendering and then doing the damage list/compression/uplink. > > So its basically a *very* strange CRTC/scanout. To most intents and > purposes plugging one into an i915 say is an extra i915 head, and indeed > you can sensibly display the same scanout buffer on both real and link > heads. > > Alan > Why not tell X that DisplayLink device connected is a monitor (like connecting a projector) so that Intel driver will take care of all the 3D support (at least for Compiz) and video acceleration, only mode setting and data transfer from memory can be taken care by a DisplayLink driver. This may be a **very** bad way of implementing and may be hypothetical but if there is a possibility it will dramatically improve multi monitor support in X. I guess "Rotate and Resize" extensions can be supported easily if such a thing is implemented.
[Trivial PATCH 0/5] treewide: Use angle brackets for system includes
Just neatening. Joe Perches (5): drbd: Use angle brackets for system includes drm: Use angle brackets for system includes aix94xx: Use angle brackets for system includes ALSA: asihpi: Use angle brackets for system includes staging: msm: Use angle brackets for system includes drivers/block/drbd/drbd_int.h |2 +- drivers/block/drbd/drbd_nl.c |4 ++-- drivers/gpu/drm/drm_ioctl.c |2 +- drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++-- drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +- drivers/gpu/drm/ttm/ttm_agp_backend.c |6 +++--- drivers/gpu/drm/ttm/ttm_bo.c |6 +++--- drivers/gpu/drm/ttm/ttm_bo_manager.c |6 +++--- drivers/gpu/drm/ttm/ttm_bo_util.c |4 ++-- drivers/gpu/drm/ttm/ttm_execbuf_util.c|6 +++--- drivers/gpu/drm/ttm/ttm_lock.c|4 ++-- drivers/gpu/drm/ttm/ttm_memory.c |6 +++--- drivers/gpu/drm/ttm/ttm_module.c |2 +- drivers/gpu/drm/ttm/ttm_object.c |4 ++-- drivers/gpu/drm/ttm/ttm_page_alloc.c |4 ++-- drivers/gpu/drm/ttm/ttm_tt.c |8 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c|4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |6 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |4 ++-- drivers/scsi/aic94xx/aic94xx_dump.c |2 +- drivers/staging/msm/ebi2_l2f.c|2 +- drivers/staging/msm/ebi2_tmd20.c |2 +- drivers/staging/msm/mddihost.h|2 +- drivers/staging/msm/mdp_ppp.c |2 +- drivers/staging/msm/mdp_ppp_v20.c |2 +- drivers/staging/msm/mdp_ppp_v31.c |2 +- drivers/staging/msm/msm_fb.h |2 +- include/drm/ttm/ttm_bo_driver.h | 12 ++-- include/drm/ttm/ttm_execbuf_util.h|2 +- include/drm/ttm/ttm_lock.h|2 +- include/linux/drbd_tag_magic.h|2 +- sound/pci/asihpi/hpidspcd.c |2 +- 39 files changed, 80 insertions(+), 80 deletions(-) -- 1.7.5.rc3.dirty
[Trivial PATCH 2/5] drm: Use angle brackets for system includes
Use the normal include style.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_ioctl.c |2 +-
drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +-
drivers/gpu/drm/ttm/ttm_agp_backend.c |6 +++---
drivers/gpu/drm/ttm/ttm_bo.c |6 +++---
drivers/gpu/drm/ttm/ttm_bo_manager.c |6 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c |4 ++--
drivers/gpu/drm/ttm/ttm_execbuf_util.c|6 +++---
drivers/gpu/drm/ttm/ttm_lock.c|4 ++--
drivers/gpu/drm/ttm/ttm_memory.c |6 +++---
drivers/gpu/drm/ttm/ttm_module.c |2 +-
drivers/gpu/drm/ttm/ttm_object.c |4 ++--
drivers/gpu/drm/ttm/ttm_page_alloc.c |4 ++--
drivers/gpu/drm/ttm/ttm_tt.c |8
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c|4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |4 ++--
include/drm/ttm/ttm_bo_driver.h | 12 ++--
include/drm/ttm/ttm_execbuf_util.h|2 +-
include/drm/ttm/ttm_lock.h|2 +-
27 files changed, 67 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..ab230ea 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,7 +36,7 @@
#include "drmP.h"
#include "drm_core.h"
-#include "linux/pci.h"
+#include
/**
* Get the bus id.
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 82d70fd..9d13be4 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -25,8 +25,8 @@
*
*/
-#include "linux/string.h"
-#include "linux/bitops.h"
+#include
+#include
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 9c56331..37998f6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -39,11 +39,11 @@
#define NOUVEAU_FAMILY 0x
#define NOUVEAU_FLAGS0x
-#include "ttm/ttm_bo_api.h"
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
-#include "ttm/ttm_memory.h"
-#include "ttm/ttm_module.h"
+#include
+#include
+#include
+#include
+#include
struct nouveau_fpriv {
struct ttm_object_file *tfile;
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 1c4a72f..7d9e531 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -29,10 +29,10 @@
* Keith Packard.
*/
-#include "ttm/ttm_module.h"
-#include "ttm/ttm_bo_driver.h"
+#include
+#include
#ifdef TTM_HAS_AGP
-#include "ttm/ttm_placement.h"
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2e618b5..021976e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -28,9 +28,9 @@
* Authors: Thomas Hellstrom
*/
-#include "ttm/ttm_module.h"
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
+#include
+#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 038e947..0fe5cec 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -28,9 +28,9 @@
* Authors: Thomas Hellstrom
*/
-#include "ttm/ttm_module.h"
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
+#include
+#include
+#include
#include "drm_mm.h"
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 77dbf40..b6285d7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -28,8 +28,8 @@
* Authors: Thomas Hellstrom
*/
-#include "ttm/ttm_bo_driver.h"
-#include "ttm/ttm_placement.h"
+#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3832fe1..2a17bbc 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -25,9 +25,9 @@
*
**/
-#include "ttm/ttm_execbuf_util.h"
-#include "ttm/ttm_bo_driver.h"
-#include
[PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 872747c..21058e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1113,7 +1113,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
if (card_res->count_fbs >= fb_count) {
copied = 0;
fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
- list_for_each_entry(fb, &file_priv->fbs, head) {
+ list_for_each_entry(fb, &file_priv->fbs, filp_head) {
if (put_user(fb->base.id, fb_id + copied)) {
ret = -EFAULT;
goto out;
--
1.7.5.3
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 --- Comment #16 from Seth Forshee 2011-06-03 13:53:31 --- Adding here some of the information that I added to the freedesktop.org bugzilla here: https://bugs.freedesktop.org/show_bug.cgi?id=36003 It seems to me that nothing being done currently in the radeon and switcheroo code guarantees that the ATI card is powered on before probing the hardware. I tried adding a call to the ATPX method to turn on power from radeon_register_atpx_handler(), but this doesn't seem to be helping. Can anyone comment on what steps need to be taken to ensure that the card is powered on before proceeding with hardware initialization? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
3D support for Displaylink devices
On Fri, Jun 3, 2011 at 5:00 AM, Prasanna Kumar T S M wrote: > On 03-06-2011 00:16, Alan Cox wrote: >>> >>> The window system needs support for splitting rendering and display. >>> In X these are currently tied together. ?The only real obstacle is >>> fixing this in X. ?However, this is a lot of work. ?Dave Airlie has >>> started working on this, but it's not really usable yet. ? See: >>> http://airlied.livejournal.com/71734.html >>> http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvlayer >> >> In the windows world it basically works by 'borrowing' the real graphics >> card for rendering and then doing the damage list/compression/uplink. >> >> So its basically a *very* strange CRTC/scanout. To most intents and >> purposes plugging one into an i915 say is an extra i915 head, and indeed >> you can sensibly display the same scanout buffer on both real and link >> heads. >> >> Alan >> > Why not tell X that DisplayLink device connected is a monitor (like > connecting a projector) so that Intel driver will take care of all the 3D > support (at least for Compiz) and video acceleration, only mode setting and > data transfer from memory can be taken care by a DisplayLink driver. This > may be a **very** bad way of implementing and may be hypothetical but if > there is a possibility it will dramatically improve multi monitor support in > X. I guess "Rotate and Resize" extensions can be supported easily if such a > thing is implemented. > Patches welcome. It's still a lot of work. Alex
[PATCH] drm/radeon/kms/atom: initialize dig phy a bit later
On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen wrote: > Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors > attached to a dual head radeon gpu to have inverted colors (until the first > suspend/resume). Initializing dig phy a bit later fixes the problem. Strange, I don't see why that would make a difference, I guess perhaps there's some strange interaction between the hpd setup or the initial clock/voltage setup on DCE5 hw. What chip are you using? Anyway, should be fine. Acked-by: Alex Deucher > > --- > ?drivers/gpu/drm/radeon/radeon_display.c | ? ?8 > ?1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c > b/drivers/gpu/drm/radeon/radeon_display.c > index ae247ee..ddff2cf 100644 > --- a/drivers/gpu/drm/radeon/radeon_display.c > +++ b/drivers/gpu/drm/radeon/radeon_display.c > @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) > ? ? ? ? ? ? ? ?return ret; > ? ? ? ?} > > - ? ? ? /* init dig PHYs */ > - ? ? ? if (rdev->is_atom_bios) > - ? ? ? ? ? ? ? radeon_atom_encoder_init(rdev); > - > ? ? ? ?/* initialize hpd */ > ? ? ? ?radeon_hpd_init(rdev); > > @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) > ? ? ? ?radeon_fbdev_init(rdev); > ? ? ? ?drm_kms_helper_poll_init(rdev->ddev); > > + ? ? ? /* init dig PHYs */ > + ? ? ? if (rdev->is_atom_bios) > + ? ? ? ? ? ? ? radeon_atom_encoder_init(rdev); > + > ? ? ? ?return 0; > ?} > > -- > 1.7.4.1 >
[Trivial PATCH 2/5] drm: Use angle brackets for system includes
On Fri, 3 Jun 2011 02:28:47 -0700, Joe Perches wrote: > drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++-- Acked-by: Keith Packard Dave -- if you want to just merge this to your tree, that's fine with me. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/5f738a51/attachment.pgp>
[PATCH]remove warning for drivers/gpu/drm/i915/intel_ringbuffer.c
On Fri, 3 Jun 2011 21:09:39 +0800, Harry Wei wrote: (process:18294): gmime-CRITICAL **: g_mime_stream_filter_add: assertion `GMIME_IS_FILTER (filter)' failed > From: Harry Wei > When i compile kernel, it shows me two warnings > like below, so this patch can fix them. This fix is already upstream; it wasn't included in the stable patch as it wasn't 'necessary' to fix the bug which is causing the warning (which ended up removing the last use of this function). -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/5715ca05/attachment.pgp>
[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled
https://bugs.freedesktop.org/show_bug.cgi?id=37220 --- Comment #4 from Jure Repinc 2011-06-03 10:52:24 PDT --- I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg server is 1.10.2, Linux kernel is 2.6.38.4 and KDE us also 4.6.3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37785] [r600g Evergreen] GPU lockup on Blender 2.57 when moving objects
https://bugs.freedesktop.org/show_bug.cgi?id=37785 Antti Lahtinen changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Antti Lahtinen 2011-06-03 11:47:46 PDT --- It seems this was fixed by: b5518834e3ae117eafb32cfc5c7e7af51b4a1078 r600g: cs init fixes Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms/atom: initialize dig phy a bit later
I'm using ASUS EAH3650SILENTMG/HTDP. I got the feeling that in my case, radeon_atom_encoder_prepare needed to be called before radeon_atom_encoder_init (the call occurred during radeon_fbdev_init). That ensured radeon_encoder->enc_priv->dig_encoder to have a value other than -1 in the first call of atombios_dig_transmitter_setup (with action=ATOM_TRANSMITTER_ACTION_INIT). But I don't know the code well enough to be sure about that. Ari 2011/6/3 Alex Deucher : > On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen > wrote: >> Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors >> attached to a dual head radeon gpu to have inverted colors (until the first >> suspend/resume). Initializing dig phy a bit later fixes the problem. > > Strange, I don't see why that would make a difference, I guess perhaps > there's some strange interaction between the hpd setup or the initial > clock/voltage setup on DCE5 hw. ?What chip are you using? > > Anyway, should be fine. > > Acked-by: Alex Deucher > >> >> --- >> ?drivers/gpu/drm/radeon/radeon_display.c | ? ?8 >> ?1 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_display.c >> b/drivers/gpu/drm/radeon/radeon_display.c >> index ae247ee..ddff2cf 100644 >> --- a/drivers/gpu/drm/radeon/radeon_display.c >> +++ b/drivers/gpu/drm/radeon/radeon_display.c >> @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) >> ? ? ? ? ? ? ? ?return ret; >> ? ? ? ?} >> >> - ? ? ? /* init dig PHYs */ >> - ? ? ? if (rdev->is_atom_bios) >> - ? ? ? ? ? ? ? radeon_atom_encoder_init(rdev); >> - >> ? ? ? ?/* initialize hpd */ >> ? ? ? ?radeon_hpd_init(rdev); >> >> @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) >> ? ? ? ?radeon_fbdev_init(rdev); >> ? ? ? ?drm_kms_helper_poll_init(rdev->ddev); >> >> + ? ? ? /* init dig PHYs */ >> + ? ? ? if (rdev->is_atom_bios) >> + ? ? ? ? ? ? ? radeon_atom_encoder_init(rdev); >> + >> ? ? ? ?return 0; >> ?} >> >> -- >> 1.7.4.1 >> >
[PATCH] drm/radeon/kms/atom: initialize dig phy a bit later
On Fri, Jun 3, 2011 at 4:03 PM, Ari Savolainen wrote: > I'm using ASUS EAH3650SILENTMG/HTDP. > > I got the feeling that in my case, radeon_atom_encoder_prepare needed to be > called before radeon_atom_encoder_init (the call occurred during > radeon_fbdev_init). That ensured radeon_encoder->enc_priv->dig_encoder to have > a value other than -1 in the first call of atombios_dig_transmitter_setup > (with > action=ATOM_TRANSMITTER_ACTION_INIT). ?But I don't know the code well enough > to > be sure about that. NACK on the patch for now. Let's try and sort this out. INIT needs to be called before the mode is set, so this needs to come before fbdev sets the mode. I'll send out a patch soon. Alex > > Ari > > 2011/6/3 Alex Deucher : >> On Thu, Jun 2, 2011 at 5:20 PM, Ari Savolainen >> wrote: >>> Commit ac89af1e1010640db072416c786f97391b85790f caused one of the monitors >>> attached to a dual head radeon gpu to have inverted colors (until the first >>> suspend/resume). Initializing dig phy a bit later fixes the problem. >> >> Strange, I don't see why that would make a difference, I guess perhaps >> there's some strange interaction between the hpd setup or the initial >> clock/voltage setup on DCE5 hw. ?What chip are you using? >> >> Anyway, should be fine. >> >> Acked-by: Alex Deucher >> >>> >>> --- >>> ?drivers/gpu/drm/radeon/radeon_display.c | ? ?8 >>> ?1 files changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/radeon/radeon_display.c >>> b/drivers/gpu/drm/radeon/radeon_display.c >>> index ae247ee..ddff2cf 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_display.c >>> +++ b/drivers/gpu/drm/radeon/radeon_display.c >>> @@ -1346,10 +1346,6 @@ int radeon_modeset_init(struct radeon_device *rdev) >>> ? ? ? ? ? ? ? ?return ret; >>> ? ? ? ?} >>> >>> - ? ? ? /* init dig PHYs */ >>> - ? ? ? if (rdev->is_atom_bios) >>> - ? ? ? ? ? ? ? radeon_atom_encoder_init(rdev); >>> - >>> ? ? ? ?/* initialize hpd */ >>> ? ? ? ?radeon_hpd_init(rdev); >>> >>> @@ -1359,6 +1355,10 @@ int radeon_modeset_init(struct radeon_device *rdev) >>> ? ? ? ?radeon_fbdev_init(rdev); >>> ? ? ? ?drm_kms_helper_poll_init(rdev->ddev); >>> >>> + ? ? ? /* init dig PHYs */ >>> + ? ? ? if (rdev->is_atom_bios) >>> + ? ? ? ? ? ? ? radeon_atom_encoder_init(rdev); >>> + >>> ? ? ? ?return 0; >>> ?} >>> >>> -- >>> 1.7.4.1 >>> >> >
[PATCH] drm/radeon/kms/atom: fix PHY init
The PHY was not initialized correctly after
ac89af1e1010640db072416c786f97391b85790f since
the function bailed early as an encoder was not
assigned. The encoder isn't necessary for PHY init
so just assign to 0 for init so that the table
is executed.
Reported-by: Ari Savolainen
Cc: Ari Savolainen
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 13e4fa0..302248b 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -949,10 +949,15 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
int dp_lane_count = 0;
int connector_object_id = 0;
int igp_lane_info = 0;
+ int dig_encoder = dig->dig_encoder;
- if (action == ATOM_TRANSMITTER_ACTION_INIT)
+ if (action == ATOM_TRANSMITTER_ACTION_INIT) {
connector = radeon_get_connector_for_encoder_init(encoder);
- else
+ /* just needed to avoid bailing in the encoder check. the
encoder
+* isn't used for init
+*/
+ dig_encoder = 0;
+ } else
connector = radeon_get_connector_for_encoder(encoder);
if (connector) {
@@ -968,7 +973,7 @@ atombios_dig_transmitter_setup(struct drm_encoder *encoder,
int action, uint8_t
}
/* no dig encoder assigned */
- if (dig->dig_encoder == -1)
+ if (dig_encoder == -1)
return;
if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_DP)
@@ -1018,7 +1023,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
if (dig->linkb)
args.v3.acConfig.ucLinkSel = 1;
- if (dig->dig_encoder & 1)
+ if (dig_encoder & 1)
args.v3.acConfig.ucEncoderSel = 1;
/* Select the PLL for the PHY
@@ -1068,7 +1073,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
args.v3.acConfig.fDualLinkConnector = 1;
}
} else if (ASIC_IS_DCE32(rdev)) {
- args.v2.acConfig.ucEncoderSel = dig->dig_encoder;
+ args.v2.acConfig.ucEncoderSel = dig_encoder;
if (dig->linkb)
args.v2.acConfig.ucLinkSel = 1;
@@ -1095,7 +1100,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
} else {
args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
- if (dig->dig_encoder)
+ if (dig_encoder)
args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
else
args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
--
1.7.1.1
[PATCH] drm/radeon/kms/atom: fix PHY init
I tested the patch and it fixed the problem.
Thanks,
Ari
2011/6/3 Alex Deucher :
> The PHY was not initialized correctly after
> ac89af1e1010640db072416c786f97391b85790f since
> the function bailed early as an encoder was not
> assigned. ?The encoder isn't necessary for PHY init
> so just assign to 0 for init so that the table
> is executed.
>
> Reported-by: Ari Savolainen
>
> Cc: Ari Savolainen
> Signed-off-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon_encoders.c | ? 17 +++--
> ?1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
> b/drivers/gpu/drm/radeon/radeon_encoders.c
> index 13e4fa0..302248b 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -949,10 +949,15 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> ? ? ? ?int dp_lane_count = 0;
> ? ? ? ?int connector_object_id = 0;
> ? ? ? ?int igp_lane_info = 0;
> + ? ? ? int dig_encoder = dig->dig_encoder;
>
> - ? ? ? if (action == ATOM_TRANSMITTER_ACTION_INIT)
> + ? ? ? if (action == ATOM_TRANSMITTER_ACTION_INIT) {
> ? ? ? ? ? ? ? ?connector = radeon_get_connector_for_encoder_init(encoder);
> - ? ? ? else
> + ? ? ? ? ? ? ? /* just needed to avoid bailing in the encoder check. ?the
> encoder
> + ? ? ? ? ? ? ? ?* isn't used for init
> + ? ? ? ? ? ? ? ?*/
> + ? ? ? ? ? ? ? dig_encoder = 0;
> + ? ? ? } else
> ? ? ? ? ? ? ? ?connector = radeon_get_connector_for_encoder(encoder);
>
> ? ? ? ?if (connector) {
> @@ -968,7 +973,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> ? ? ? ?}
>
> ? ? ? ?/* no dig encoder assigned */
> - ? ? ? if (dig->dig_encoder == -1)
> + ? ? ? if (dig_encoder == -1)
> ? ? ? ? ? ? ? ?return;
>
> ? ? ? ?if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_DP)
> @@ -1018,7 +1023,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
>
> ? ? ? ? ? ? ? ?if (dig->linkb)
> ? ? ? ? ? ? ? ? ? ? ? ?args.v3.acConfig.ucLinkSel = 1;
> - ? ? ? ? ? ? ? if (dig->dig_encoder & 1)
> + ? ? ? ? ? ? ? if (dig_encoder & 1)
> ? ? ? ? ? ? ? ? ? ? ? ?args.v3.acConfig.ucEncoderSel = 1;
>
> ? ? ? ? ? ? ? ?/* Select the PLL for the PHY
> @@ -1068,7 +1073,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?args.v3.acConfig.fDualLinkConnector = 1;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?} else if (ASIC_IS_DCE32(rdev)) {
> - ? ? ? ? ? ? ? args.v2.acConfig.ucEncoderSel = dig->dig_encoder;
> + ? ? ? ? ? ? ? args.v2.acConfig.ucEncoderSel = dig_encoder;
> ? ? ? ? ? ? ? ?if (dig->linkb)
> ? ? ? ? ? ? ? ? ? ? ? ?args.v2.acConfig.ucLinkSel = 1;
>
> @@ -1095,7 +1100,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
> *encoder, int action, uint8_t
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
>
> - ? ? ? ? ? ? ? if (dig->dig_encoder)
> + ? ? ? ? ? ? ? if (dig_encoder)
> ? ? ? ? ? ? ? ? ? ? ? ?args.v1.ucConfig |=
> ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
> ? ? ? ? ? ? ? ?else
> ? ? ? ? ? ? ? ? ? ? ? ?args.v1.ucConfig |=
> ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
> --
> 1.7.1.1
>
>
[Bug 36812] GPU lockup in Team Fortress 2
https://bugs.freedesktop.org/show_bug.cgi?id=36812 --- Comment #9 from Sven Arvidsson 2011-06-03 13:54:28 PDT --- I noticed that a few piglit tests causes GPU hang/resets when run with MESA_GLSL=nopt. Is this to be expected or is it worth to file bugs? The failing tests are glsl-fs-atan-2, glsl-fs-lots-of-tex, glsl-orangebook-ch06-bump and possibly others. They run without problems if nopt isn't used. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PULL] drm-intel-next
Here's another handful of fixes that I had merged to drm-intel-next. Once these are merged, I'll move drm-intel-fixes and start putting stuff there for 3.0. The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0: drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge (2011-05-18 15:14:39 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git drm-intel-next Chris Wilson (5): drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/ drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0 drm/i915/crt: Explicitly return false if connected to a digital monitor drm/i915: Remove unused enum "chip_family" drm/i915: Share the common force-audio property between connectors Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler Daniel Vetter (3): drm/i915: Only print out the actual number of fences for i915_error_state drm/i915: not finding a fence is a non-recoverable condition drm/915: fix relaxed tiling on gen2: tile height Jason Stubbs (1): drm/i915: fix regression after clock gating init split Nicolas Kaiser (1): drm: i915: correct return status in intel_hdmi_mode_valid() drivers/gpu/drm/i915/i915_debugfs.c |2 +- drivers/gpu/drm/i915/i915_drv.h |8 +--- drivers/gpu/drm/i915/i915_gem.c | 28 +- drivers/gpu/drm/i915/i915_irq.c |2 +- drivers/gpu/drm/i915/intel_crt.c |4 ++ drivers/gpu/drm/i915/intel_display.c | 89 -- drivers/gpu/drm/i915/intel_dp.c | 15 +- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_hdmi.c| 16 +- drivers/gpu/drm/i915/intel_modes.c | 30 +++ drivers/gpu/drm/i915/intel_sdvo.c| 14 +- 11 files changed, 80 insertions(+), 129 deletions(-) -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/df92d7d5/attachment.pgp>
Questions about libdrm_intel and way to share physical memory between CPU and GPU
On Thu, 2 Jun 2011 19:42:03 +0100, Alan Cox wrote: > On Sat, 28 May 2011 09:54:01 +0100 > Chris Wilson wrote: > > > On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" > at intel.com> wrote: > > > Hello gurus, > > > > > > I have two question mostly regarding libdrm_intel > > > > > > 1/ What is the difference between drm_intel_bo_map and > > > drm_intel_gem_bo_map_gtt ? > > bo_map uses the CPU domain, and so is CPU linear (needs sw detiling). > > bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear > > (detiling is performed by the hardware using a fence). > > > > > 2/ Will it be possible (or is it already possible) to directly share a > > > regularly allocated piece of physical memory? Typical use case is the > > > following one using OpenCL API: > > > > Yes. I've proposed a vmap interface to bind user-pages into the GTT, > > similar to a completely unused bit of TTM functionality. > > It seems to me that stolen memory and other things could all be sorted > out somewhat if the GEM layer and GEM as shmemfs backing were split apart > a bit. A 'privately backed' GEM object wouldn't be able to support > flink() but I can't find much else that would break ? > > Wondering about this for things like the GMA500, and also to get back all > that memory the i9xx driver burns on a PC. I'd much rather be able to just hand that memory off to the kernel to use along with everything else and have there be nothing magic about it. But as I recall, the mtrr mappings of that memory was often goofy, so it may take some work to clean it up. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110603/c296ad8e/attachment.pgp>
[Bug 37911] New: supertuxkart crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37911 Summary: supertuxkart crashes with r300g Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: pawlerson at gmail.com When I want to start a race in Supertuxkart it crashes: Irrlicht Engine version 1.8.0-alpha Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 Could not load sprite bank because the file does not exist: #DefaultFont [FileManager] Data files will be fetched from: '/usr/share/games/supertuxkart/' Env var LANG = 'pl_PL.UTF-8' Adding language fallback pl [IrrDriver] Creating NULL device Irrlicht Engine version 1.8.0-alpha Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 Could not load sprite bank because the file does not exist: #DefaultFont [IrrDriver] Trying OpenGL rendering. [IrrDriver] Trying to create device with 32 bits r300: DRM version: 2.8.0, Name: ATI RV530, ID: 0x71c0, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES Mesa: User error: GL_INVALID_ENUM in glProvokingVertexEXT(0xfeffb090) [IrrDriver Temp Logger] Level 3: Could not load sprite bank because the file does not exist: #DefaultFont Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT(textarget=0x3) Mesa: User error: GL_INVALID_ENUM in glFramebufferRenderbufferEXT(renderbufferTarget) [Irrlicht Error] FBO has invalid draw buffer [Irrlicht Error] FBO error supertuxkart: COpenGLTexture.cpp:888: bool irr::video::checkFBOStatus(irr::video::COpenGLDriver*): Warunek zapewnienia `!(true)' nie zosta? spe?niony. Przerwane I'm using this repository: https://launchpad.net/~oibaf/+archive/graphics-drivers/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH]remove warning for drivers/gpu/drm/i915/intel_ringbuffer.c
From: Harry Wei
When i compile kernel, it shows me two warnings
like below, so this patch can fix them.
[...]
CC [M] drivers/gpu/drm/i915/intel_dvo.o
CC [M] drivers/gpu/drm/i915/intel_ringbuffer.o
drivers/gpu/drm/i915/intel_ringbuffer.c:603: warning:
?ring_get_irq? defined but not used
drivers/gpu/drm/i915/intel_ringbuffer.c:620: warning:
?ring_put_irq? defined but not used
CC [M] drivers/gpu/drm/i915/intel_overlay.o
CC [M] drivers/gpu/drm/i915/intel_opregion.o
[...]
Signed-off-by: Harry Wei
Index: prj/drivers/gpu/drm/i915/intel_ringbuffer.c
===
--- prj.orig/drivers/gpu/drm/i915/intel_ringbuffer.c2011-06-03
20:37:35.523539547 +0800
+++ prj/drivers/gpu/drm/i915/intel_ringbuffer.c 2011-06-03 20:38:07.279539574
+0800
@@ -599,23 +599,6 @@
return 0;
}
-static bool
-ring_get_irq(struct intel_ring_buffer *ring, u32 flag)
-{
- struct drm_device *dev = ring->dev;
- drm_i915_private_t *dev_priv = dev->dev_private;
-
- if (!dev->irq_enabled)
- return false;
-
- spin_lock(&ring->irq_lock);
- if (ring->irq_refcount++ == 0)
- ironlake_enable_irq(dev_priv, flag);
- spin_unlock(&ring->irq_lock);
-
- return true;
-}
-
static void
ring_put_irq(struct intel_ring_buffer *ring, u32 flag)
{
