[Bug 45121] New: Not all PCIID 1002:68e1 are Mobility
https://bugzilla.kernel.org/show_bug.cgi?id=45121 Summary: Not all PCIID 1002:68e1 are Mobility Product: Drivers Version: 2.5 Kernel Version: 3.5.0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: athena at fftw.org Regression: No I have a couple of HD5450 cards with pci id 1002:68e1 subsystem 1787:3000. These are HD5450 cards, even though 1002:68e1 is the pci id of HD5430 Mobility. One card is marketed as HIS H545HO512, the other as ASUS EAH5450 SL/DI/512MD3/MG(LP). (I also have another HIS H545HO512 card that reports the correct pci id 1002:68f9, and therefore not all these HIS cards are the same.) The bug is that the kernel radeon driver sets the RADEON_IS_MOBILITY flag for the 1002:68e1 cards, which prevents the power profiles from working correctly. My diagnosis of the problem is that the driver looks up the battery power profile, which does not exist, and it falls back to the default power profile, which runs at full speed all the time. I have verified that by clearing the RADEON_IS_MOBILITY flag and recompiling the kernel module, this command works as expected: echo "low" > /sys/class/drm/card0/device/power_profile Since these cards with the wrong PCI ID seem common (the two cheapest cards on newegg have this issue), it would be nice if future kernels could provide a workaround. Thanks, Matteo Frigo -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
drm/nouveau: crash regression in 3.5
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Gl?ck wrote: > On 24.07.2012 19:00, Marcin Slusarz wrote: > > Please post the crash log. > > Sorry, I was not precise: it boots until drm performs modesetting (so it > seems). The screen goes black and the machine is dead. So there is > nothing I could post here, unfortunately. > > This is a video of 3.5 booting: > http://www.odi.ch/VIDEO0010.3gp Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X? Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Marcin
[PATCH 1/6] drm/fb: Enable choosing a preferred noedid mode
This adds a "preferred" argument to drm_add_modes_noedid() which
allow drivers such as cirrusdrmfb to select a preferred mode based
on firmware configuration
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_mode.c |8 +++-
drivers/gpu/drm/drm_crtc_helper.c|2 +-
drivers/gpu/drm/drm_edid.c |7 ++-
include/drm/drm_crtc.h |2 +-
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index a44d31a..e3d2dc0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -495,13 +495,19 @@ static struct drm_encoder *cirrus_encoder_init(struct
drm_device *dev)
int cirrus_vga_get_modes(struct drm_connector *connector)
{
+ int count = 0;
+
/* Just add a static list of modes */
+ count += drm_add_modes_noedid(connector, 640, 480, false);
+ count += drm_add_modes_noedid(connector, 800, 600, false);
+ count += drm_add_modes_noedid(connector, 1024, 768, false);
+ count += drm_add_modes_noedid(connector, 1280, 1024, false);
drm_add_modes_noedid(connector, 640, 480);
drm_add_modes_noedid(connector, 800, 600);
drm_add_modes_noedid(connector, 1024, 768);
drm_add_modes_noedid(connector, 1280, 1024);
- return 4;
+ return count;
}
static int cirrus_vga_mode_valid(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..2b8612f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -126,7 +126,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = (*connector_funcs->get_modes)(connector);
if (count == 0 && connector->status == connector_status_connected)
- count = drm_add_modes_noedid(connector, 1024, 768);
+ count = drm_add_modes_noedid(connector, 1024, 768, false);
if (count == 0)
goto prune;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..38cab74 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1945,7 +1945,7 @@ EXPORT_SYMBOL(drm_add_edid_modes);
* Return number of modes added or 0 if we couldn't find any.
*/
int drm_add_modes_noedid(struct drm_connector *connector,
- int hdisplay, int vdisplay)
+int hdisplay, int vdisplay, bool preferred)
{
int i, count, num_modes = 0;
struct drm_display_mode *mode;
@@ -1973,6 +1973,11 @@ int drm_add_modes_noedid(struct drm_connector *connector,
continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
+ if (preferred && ptr->hdisplay == hdisplay &&
+ ptr->vdisplay == vdisplay) {
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+ preferred = false;
+ }
drm_mode_probed_add(connector, mode);
num_modes++;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a1a0386..e8e94b7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1033,7 +1033,7 @@ extern struct drm_display_mode
*drm_gtf_mode_complex(struct drm_device *dev,
bool interlaced, int margins, int GTF_M,
int GTF_2C, int GTF_K, int GTF_2J);
extern int drm_add_modes_noedid(struct drm_connector *connector,
- int hdisplay, int vdisplay);
+ int hdisplay, int vdisplay, bool preferred);
extern int drm_edid_header_is_valid(const u8 *raw_edid);
extern bool drm_edid_block_valid(u8 *raw_edid, int block);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/cirrus: Retrieve default mode from the device-tree if any
On the pseries machine type, qemu puts a default mode in the
device-tree based on the user request (-g option) which the
firmware uses to setup the boot screen.
Currently cirrusdrmfb ignores this and always ends up using
1280x1024. This adds support for retrieving this information
and using it to set the default mode and depth.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c |3 +--
drivers/gpu/drm/cirrus/cirrus_mode.c | 37 +
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 1345215..b0e4080 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -296,9 +296,8 @@ int cirrus_fbdev_init(struct cirrus_device *cdev)
{
struct cirrus_fbdev *gfbdev;
int ret;
- int bpp_sel = 24;
+ int bpp_sel = cdev->dev->mode_config.preferred_depth;
- /*bpp_sel = 8;*/
gfbdev = kzalloc(sizeof(struct cirrus_fbdev), GFP_KERNEL);
if (!gfbdev)
return -ENOMEM;
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 1566853..1ba73b0 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -19,6 +19,8 @@
#include "drm_crtc_helper.h"
#include
+#include
+#include
#include "cirrus_drv.h"
@@ -498,15 +500,25 @@ int cirrus_vga_get_modes(struct drm_connector *connector)
{
int count = 0;
+#ifdef CONFIG_OF
+ /*
+* Add qemu default mode as preferred on machines where it's
+* indicated in the device-tree
+*/
+ if (of_chosen) {
+ u32 width, height;
+
+ if (of_property_read_u32(of_chosen, "qemu,graphic-width",
&width) == 0 &&
+ of_property_read_u32(of_chosen, "qemu,graphic-height",
&height) == 0)
+ count += drm_add_modes_noedid(connector, width, height,
true);
+ }
+#endif /* CONFIG_OF */
+
/* Just add a static list of modes */
count += drm_add_modes_noedid(connector, 640, 480, false);
count += drm_add_modes_noedid(connector, 800, 600, false);
count += drm_add_modes_noedid(connector, 1024, 768, false);
count += drm_add_modes_noedid(connector, 1280, 1024, false);
- drm_add_modes_noedid(connector, 640, 480);
- drm_add_modes_noedid(connector, 800, 600);
- drm_add_modes_noedid(connector, 1024, 768);
- drm_add_modes_noedid(connector, 1280, 1024);
return count;
}
@@ -597,6 +609,23 @@ int cirrus_modeset_init(struct cirrus_device *cdev)
cdev->dev->mode_config.fb_base = cdev->mc.vram_base;
cdev->dev->mode_config.preferred_depth = 24;
+
+#ifdef CONFIG_OF
+ /*
+* Add qemu default depth as preferred on machines where it's
+* indicated in the device-tree
+*/
+ if (of_chosen) {
+ u32 depth;
+
+ if (!of_property_read_u32(of_chosen, "qemu,graphic-depth",
&depth)) {
+ if (depth == 8 || depth == 15 || depth == 16 ||
+ depth == 24 || depth == 32)
+ cdev->dev->mode_config.preferred_depth = depth;
+ }
+ }
+#endif /* CONFIG_OF */
+
/* don't prefer a shadow on virt GPU */
cdev->dev->mode_config.prefer_shadow = 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/cirrus: Check for pitch limits rather than bpp limits
The real HW limit that prevents from using 32bpp is a pitch
limit of 4095 bytes. 32bpp is otherwise supported and works.
This fixes the checks in the code to check the right thing
(so that a userspace request to set a mode with a supported
bpp but a too large pitch will fail appropriately).
Additionally, we make the fbdev code try reducing the bpp if
it hits the pitch limit in order to improve the chances of
displaying a console at boot if the default or requested mode
is too large to fit.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 28 +---
drivers/gpu/drm/cirrus/cirrus_main.c |4 ++--
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 9a276a5..1345215 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -109,9 +109,9 @@ static int cirrusfb_create_object(struct cirrus_fbdev
*afbdev,
int ret = 0;
drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
-
- if (bpp > 24)
+ if (mode_cmd->pitches[0] >= 4096)
return -EINVAL;
+
size = mode_cmd->pitches[0] * mode_cmd->height;
ret = cirrus_gem_create(dev, size, true, &gobj);
if (ret)
@@ -137,7 +137,29 @@ static int cirrusfb_create(struct cirrus_fbdev *gfbdev,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp + 7) / 8);
+
+ /* Reduce bpp to fit pitch constraints if necessary */
+ for (;;) {
+ mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp +
7) / 8);
+ if (mode_cmd.pitches[0] < 4096)
+ break;
+ switch(sizes->surface_bpp) {
+ case 32:
+ sizes->surface_bpp = 24;
+ break;
+ case 24:
+ sizes->surface_bpp = 16;
+ break;
+ case 16:
+ sizes->surface_bpp = 8;
+ break;
+ default:
+ return -ENOMEM;
+ }
+ DRM_INFO("Selected mode has a too high pitch, reducing to %d
bpp\n",
+sizes->surface_bpp);
+ }
+
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
size = mode_cmd.pitches[0] * mode_cmd.height;
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index e3c1225..ac1a5e5 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -64,8 +64,8 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
u32 bpp, depth;
drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
- /* cirrus can't handle > 24bpp framebuffers at all */
- if (bpp > 24)
+ /* cirrus can't handle pitch >= 4096 */
+ if (mode_cmd->pitches[0] >= 4096)
return ERR_PTR(-EINVAL);
obj = drm_gem_object_lookup(dev, filp, mode_cmd->handles[0]);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/fb: Fix depth 15 support in drm_fb_helper.c
fbset can pass var->bits_per_pixel = 15 when doing fbset -depth 15,
so we need to "correct" that to bpp 16 / depth 15.
Additionally, we make it possible to pass 15 as an argument to
drm_fb_helper_single_fb_probe() which will similarily select
a bpp of 15 and a depth of 15.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_fb_helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f546d1e..da6873c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -571,6 +571,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
}
switch (var->bits_per_pixel) {
+ case 15:
+ /*
+* There is no such thing as a packed 15bpp,
+* so in this case, assume 16bpp, depth 15
+*/
+ depth = 15;
+ var->bits_per_pixel = 16;
+ break;
case 16:
depth = (var->green.length == 6) ? 16 : 15;
break;
@@ -722,10 +730,15 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper
*fb_helper,
sizes.fb_width = (unsigned)-1;
sizes.fb_height = (unsigned)-1;
- /* if driver picks 8 or 16 by default use that
- for both depth/bpp */
+ /*
+* If driver picks 8 or 16 by default use that
+* for both depth/bpp, however convert 15 to bpp 16
+* depth 15
+*/
if (preferred_bpp != sizes.surface_bpp) {
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
+ if (preferred_bpp == 15)
+ sizes.surface_bpp = 16;
}
/* first up get a count of crtcs now in use and new min/maxes
width/heights */
for (i = 0; i < fb_helper->connector_count; i++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/cirrus: Workaround for HDR access
Qemu has an odd behaviour with the access to HDR (could be a qemu
bug, I'm investigating separately, but it affects current qemu's
so we should try to work around it).
Basically the internal counter that counts the reads of the 3c6
register in order to give you access to the HDR on the 5th access
is initialized in such a way that it overflows if you start doing
the 4-reads sequence right after reset, and thus fails to pickup
the subsequent write.
We work around this by doing a write before the 4 reads, which
resets the counter properly.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_drv.h |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 64ea597..b5685d3 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -74,6 +74,7 @@
#define WREG_HDR(v)\
do {\
+ WREG8(VGA_DAC_MASK, v); /* reset counter */ \
RREG8(VGA_DAC_MASK);\
RREG8(VGA_DAC_MASK);\
RREG8(VGA_DAC_MASK);\
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/cirrus: Proper support for depth 15 and 16
We were configuring SR7 very strangely for 16bpp and didn't properly
differenciate between depth 15 and 16. This fixes it (and both
appear to work at least on ppc)
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/cirrus/cirrus_mode.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index e3d2dc0..1566853 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -269,13 +269,14 @@ static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
sr07 = RREG8(SEQ_DATA);
sr07 &= 0xe0;
hdr = 0;
+
switch (crtc->fb->bits_per_pixel) {
case 8:
sr07 |= 0x11;
break;
case 16:
- sr07 |= 0xc1;
- hdr = 0xc0;
+ sr07 |= 0x17;
+ hdr = (crtc->fb->depth == 16) ? 0xc1 : 0xc0;
break;
case 24:
sr07 |= 0x15;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #4 from sowad...@miner.mst.edu 2012-07-25 02:43:09 PDT --- Created attachment 64641 --> https://bugs.freedesktop.org/attachment.cgi?id=64641 Picture of screen corruption -- 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 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #3 from sowad...@miner.mst.edu 2012-07-25 02:34:18 PDT --- Created attachment 64640 --> https://bugs.freedesktop.org/attachment.cgi?id=64640 Xorg log after issue is 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 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #2 from sowad...@miner.mst.edu 2012-07-25 02:33:44 PDT --- Created attachment 64639 --> https://bugs.freedesktop.org/attachment.cgi?id=64639 DMESG after restarting X a couple time to fix the 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 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #1 from sowad...@miner.mst.edu 2012-07-25 02:33:03 PDT --- Created attachment 64638 --> https://bugs.freedesktop.org/attachment.cgi?id=64638 DMESG after booting with screen corruption -- 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 52467] New: Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 Bug #: 52467 Summary: Radeon HD6450 KMS garbled screen on boot. Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: sowad...@miner.mst.edu Just recently upgraded to a Radeon HD6450. Upon boot, as soon as fbcon takes over, the screen gets corrupted. (note X is not started on boot). SSHing into the box and starting and restarting X a couple time sometimes fixes the issue, sometimes locks of the machine. -- 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
drm/nouveau: crash regression in 3.5
On 24.07.2012 19:00, Marcin Slusarz wrote: > Please post the crash log. Sorry, I was not precise: it boots until drm performs modesetting (so it seems). The screen goes black and the machine is dead. So there is nothing I could post here, unfortunately. This is a video of 3.5 booting: http://www.odi.ch/VIDEO0010.3gp Don't worry about the external monitor: same behaviour with the built-in panel. Thanks, Ortwin
drm/nouveau: crash regression in 3.5
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Gl?ck wrote: > Hi, > > My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with > 3.4. Bisected to the following commit: > > 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit > commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e > Author: Ben Skeggs > Date: Mon Apr 30 11:33:43 2012 -0500 > > drm/nouveau: create real execution engine for software object class > > Just a cleanup more or less, and to remove the need for special > handling of > software objects. > > This removes a heap of documentation on dma/graph object formats. > The info > is very out of date with our current understanding, and is far better > documented in rnndb in envytools git. > > Signed-off-by: Ben Skeggs > > lspci: > 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX > 1800M] (rev a2) > Please post the crash log. Marcin
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba v2
On Tue, Jul 24, 2012 at 5:06 PM, wrote:
> From: Jerome Glisse
>
> The external encoder need to be setup again before enabling the
> transmiter. This seems to be only needed on some trinity/aruba
> to fix dpms on.
>
> v2: Add comment, only setup again on dce6 ie aruba or newer.
>
> Cc:
> Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 486ccdf..8676b1b 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1392,10 +1392,18 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
> *encoder, int mode)
> case DRM_MODE_DPMS_ON:
> /* some early dce3.2 boards have a bug in their transmitter
> control table */
> if ((rdev->family == CHIP_RV710) || (rdev->family ==
> CHIP_RV730) ||
> - ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
> + ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
> + if (ASIC_IS_DCE6(rdev)) {
> + /* It seems we need to call
> ATOM_ENCODER_CMD_SETUP again
> +* before reenabling encoder on DPMS ON,
> otherwise we never
> +* get picture
> +*/
> + atombios_dig_encoder_setup(encoder,
> ATOM_ENCODER_CMD_SETUP, 0);
> + }
> atombios_dig_transmitter_setup(encoder,
> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
> - else
> + } else {
> atombios_dig_transmitter_setup(encoder,
> ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
> + }
> if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
> connector) {
> if (connector->connector_type ==
> DRM_MODE_CONNECTOR_eDP) {
> atombios_set_edp_panel_power(connector,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba v2
From: Jerome Glisse
The external encoder need to be setup again before enabling the
transmiter. This seems to be only needed on some trinity/aruba
to fix dpms on.
v2: Add comment, only setup again on dce6 ie aruba or newer.
Cc:
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_encoders.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 486ccdf..8676b1b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1392,10 +1392,18 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
*encoder, int mode)
case DRM_MODE_DPMS_ON:
/* some early dce3.2 boards have a bug in their transmitter
control table */
if ((rdev->family == CHIP_RV710) || (rdev->family ==
CHIP_RV730) ||
- ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
+ ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+ if (ASIC_IS_DCE6(rdev)) {
+ /* It seems we need to call
ATOM_ENCODER_CMD_SETUP again
+* before reenabling encoder on DPMS ON,
otherwise we never
+* get picture
+*/
+ atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP, 0);
+ }
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
- else
+ } else {
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
+ }
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
connector) {
if (connector->connector_type ==
DRM_MODE_CONNECTOR_eDP) {
atombios_set_edp_panel_power(connector,
--
1.7.10.4
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba
On Tue, Jul 24, 2012 at 4:41 PM, Alex Deucher wrote:
> On Tue, Jul 24, 2012 at 4:29 PM, wrote:
>> From: Jerome Glisse
>>
>> The external encoder need to be setup again before enabling the
>> transmiter. This seems to be only needed on some trinity/aruba
>> to fix dpms on.
>>
>> Cc:
>> Signed-off-by: Jerome Glisse
>> ---
>> drivers/gpu/drm/radeon/atombios_encoders.c |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index 486ccdf..5302c42 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1392,10 +1392,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
>> *encoder, int mode)
>> case DRM_MODE_DPMS_ON:
>> /* some early dce3.2 boards have a bug in their transmitter
>> control table */
>> if ((rdev->family == CHIP_RV710) || (rdev->family ==
>> CHIP_RV730) ||
>> - ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
>> + ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
>> + atombios_dig_encoder_setup(encoder,
>> ATOM_ENCODER_CMD_SETUP, 0);
>> atombios_dig_transmitter_setup(encoder,
>> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
>
> Maybe make a separate case for DCE61 here? We don't need to execute
> ATOM_ENCODER_CMD_SETUP again here on other asics. Also the current
> code already calls these two actions in the same order via
> radeon_atom_encoder_mode_set() and then
> radeon_atom_encoder_dpms_dig(). The difference being that in the
> current ordering there are calls to
>
> atombios_dig_encoder_setup(encoder,
>
> ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
>dig->panel_mode);
> and
> atombios_external_encoder_setup(encoder, ext_encoder,
>
> EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
>
> in between. Does changing the order in radeon_atom_encoder_mode_set()
> also fix the issue? e.g.
> atombios_dig_encoder_setup(encoder,
>
> ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
>dig->panel_mode);
> atombios_external_encoder_setup(encoder, ext_encoder,
>
> EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
> atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_SETUP, 0);
>
> followed by radeon_atom_encoder_dpms_dig():
> atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
>
> Alex
On dpms on we don't call encoder_mode_set
Cheers,
Jerome
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba
On Tue, Jul 24, 2012 at 4:29 PM, wrote:
> From: Jerome Glisse
>
> The external encoder need to be setup again before enabling the
> transmiter. This seems to be only needed on some trinity/aruba
> to fix dpms on.
>
> Cc:
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 486ccdf..5302c42 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1392,10 +1392,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
> *encoder, int mode)
> case DRM_MODE_DPMS_ON:
> /* some early dce3.2 boards have a bug in their transmitter
> control table */
> if ((rdev->family == CHIP_RV710) || (rdev->family ==
> CHIP_RV730) ||
> - ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
> + ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
> + atombios_dig_encoder_setup(encoder,
> ATOM_ENCODER_CMD_SETUP, 0);
> atombios_dig_transmitter_setup(encoder,
> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
Maybe make a separate case for DCE61 here? We don't need to execute
ATOM_ENCODER_CMD_SETUP again here on other asics. Also the current
code already calls these two actions in the same order via
radeon_atom_encoder_mode_set() and then
radeon_atom_encoder_dpms_dig(). The difference being that in the
current ordering there are calls to
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
dig->panel_mode);
and
atombios_external_encoder_setup(encoder, ext_encoder,
EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
in between. Does changing the order in radeon_atom_encoder_mode_set()
also fix the issue? e.g.
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
dig->panel_mode);
atombios_external_encoder_setup(encoder, ext_encoder,
EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_SETUP, 0);
followed by radeon_atom_encoder_dpms_dig():
atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
Alex
[Bug 45121] New: Not all PCIID 1002:68e1 are Mobility
https://bugzilla.kernel.org/show_bug.cgi?id=45121 Summary: Not all PCIID 1002:68e1 are Mobility Product: Drivers Version: 2.5 Kernel Version: 3.5.0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: ath...@fftw.org Regression: No I have a couple of HD5450 cards with pci id 1002:68e1 subsystem 1787:3000. These are HD5450 cards, even though 1002:68e1 is the pci id of HD5430 Mobility. One card is marketed as HIS H545HO512, the other as ASUS EAH5450 SL/DI/512MD3/MG(LP). (I also have another HIS H545HO512 card that reports the correct pci id 1002:68f9, and therefore not all these HIS cards are the same.) The bug is that the kernel radeon driver sets the RADEON_IS_MOBILITY flag for the 1002:68e1 cards, which prevents the power profiles from working correctly. My diagnosis of the problem is that the driver looks up the battery power profile, which does not exist, and it falls back to the default power profile, which runs at full speed all the time. I have verified that by clearing the RADEON_IS_MOBILITY flag and recompiling the kernel module, this command works as expected: echo "low" > /sys/class/drm/card0/device/power_profile Since these cards with the wrong PCI ID seem common (the two cheapest cards on newegg have this issue), it would be nice if future kernels could provide a workaround. Thanks, Matteo Frigo -- 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
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba
From: Jerome Glisse
The external encoder need to be setup again before enabling the
transmiter. This seems to be only needed on some trinity/aruba
to fix dpms on.
Cc:
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_encoders.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 486ccdf..5302c42 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1392,10 +1392,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
*encoder, int mode)
case DRM_MODE_DPMS_ON:
/* some early dce3.2 boards have a bug in their transmitter
control table */
if ((rdev->family == CHIP_RV710) || (rdev->family ==
CHIP_RV730) ||
- ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
+ ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+ atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP, 0);
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
- else
+ } else {
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
+ }
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
connector) {
if (connector->connector_type ==
DRM_MODE_CONNECTOR_eDP) {
atombios_set_edp_panel_power(connector,
--
1.7.10.4
Re: [PATCH] drm/radeon: fix dpms on/off on trinity/aruba v2
On Tue, Jul 24, 2012 at 5:06 PM, wrote:
> From: Jerome Glisse
>
> The external encoder need to be setup again before enabling the
> transmiter. This seems to be only needed on some trinity/aruba
> to fix dpms on.
>
> v2: Add comment, only setup again on dce6 ie aruba or newer.
>
> Cc:
> Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 486ccdf..8676b1b 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1392,10 +1392,18 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
> *encoder, int mode)
> case DRM_MODE_DPMS_ON:
> /* some early dce3.2 boards have a bug in their transmitter
> control table */
> if ((rdev->family == CHIP_RV710) || (rdev->family ==
> CHIP_RV730) ||
> - ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
> + ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
> + if (ASIC_IS_DCE6(rdev)) {
> + /* It seems we need to call
> ATOM_ENCODER_CMD_SETUP again
> +* before reenabling encoder on DPMS ON,
> otherwise we never
> +* get picture
> +*/
> + atombios_dig_encoder_setup(encoder,
> ATOM_ENCODER_CMD_SETUP, 0);
> + }
> atombios_dig_transmitter_setup(encoder,
> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
> - else
> + } else {
> atombios_dig_transmitter_setup(encoder,
> ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
> + }
> if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
> connector) {
> if (connector->connector_type ==
> DRM_MODE_CONNECTOR_eDP) {
> atombios_set_edp_panel_power(connector,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba v2
From: Jerome Glisse
The external encoder need to be setup again before enabling the
transmiter. This seems to be only needed on some trinity/aruba
to fix dpms on.
v2: Add comment, only setup again on dce6 ie aruba or newer.
Cc:
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_encoders.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 486ccdf..8676b1b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1392,10 +1392,18 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
*encoder, int mode)
case DRM_MODE_DPMS_ON:
/* some early dce3.2 boards have a bug in their transmitter
control table */
if ((rdev->family == CHIP_RV710) || (rdev->family ==
CHIP_RV730) ||
- ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
+ ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+ if (ASIC_IS_DCE6(rdev)) {
+ /* It seems we need to call
ATOM_ENCODER_CMD_SETUP again
+* before reenabling encoder on DPMS ON,
otherwise we never
+* get picture
+*/
+ atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP, 0);
+ }
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
- else
+ } else {
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
+ }
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
connector) {
if (connector->connector_type ==
DRM_MODE_CONNECTOR_eDP) {
atombios_set_edp_panel_power(connector,
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Glück wrote: > On 24.07.2012 19:00, Marcin Slusarz wrote: > > Please post the crash log. > > Sorry, I was not precise: it boots until drm performs modesetting (so it > seems). The screen goes black and the machine is dead. So there is > nothing I could post here, unfortunately. > > This is a video of 3.5 booting: > http://www.odi.ch/VIDEO0010.3gp Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X? Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #67 from Alexandre Demers 2012-07-24 06:53:33 PDT --- Created attachment 64585 --> https://bugs.freedesktop.org/attachment.cgi?id=64585 Adding an environment variable to disable VM if wanted By setting R600_VM=0, we disable the virtual address space code path. By default, the path will still be enabled and used. However, if set to 0, it will prevent some cards (mostly CAYMAN it seems) from locking up or crashing because of the VM code. It is a work around until we figure out why it is locking. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm/radeon: fix dpms on/off on trinity/aruba
On Tue, Jul 24, 2012 at 4:41 PM, Alex Deucher wrote:
> On Tue, Jul 24, 2012 at 4:29 PM, wrote:
>> From: Jerome Glisse
>>
>> The external encoder need to be setup again before enabling the
>> transmiter. This seems to be only needed on some trinity/aruba
>> to fix dpms on.
>>
>> Cc:
>> Signed-off-by: Jerome Glisse
>> ---
>> drivers/gpu/drm/radeon/atombios_encoders.c |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index 486ccdf..5302c42 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1392,10 +1392,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
>> *encoder, int mode)
>> case DRM_MODE_DPMS_ON:
>> /* some early dce3.2 boards have a bug in their transmitter
>> control table */
>> if ((rdev->family == CHIP_RV710) || (rdev->family ==
>> CHIP_RV730) ||
>> - ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
>> + ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
>> + atombios_dig_encoder_setup(encoder,
>> ATOM_ENCODER_CMD_SETUP, 0);
>> atombios_dig_transmitter_setup(encoder,
>> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
>
> Maybe make a separate case for DCE61 here? We don't need to execute
> ATOM_ENCODER_CMD_SETUP again here on other asics. Also the current
> code already calls these two actions in the same order via
> radeon_atom_encoder_mode_set() and then
> radeon_atom_encoder_dpms_dig(). The difference being that in the
> current ordering there are calls to
>
> atombios_dig_encoder_setup(encoder,
>
> ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
>dig->panel_mode);
> and
> atombios_external_encoder_setup(encoder, ext_encoder,
>
> EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
>
> in between. Does changing the order in radeon_atom_encoder_mode_set()
> also fix the issue? e.g.
> atombios_dig_encoder_setup(encoder,
>
> ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
>dig->panel_mode);
> atombios_external_encoder_setup(encoder, ext_encoder,
>
> EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
> atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_SETUP, 0);
>
> followed by radeon_atom_encoder_dpms_dig():
> atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
>
> Alex
On dpms on we don't call encoder_mode_set
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix dpms on/off on trinity/aruba
On Tue, Jul 24, 2012 at 4:29 PM, wrote:
> From: Jerome Glisse
>
> The external encoder need to be setup again before enabling the
> transmiter. This seems to be only needed on some trinity/aruba
> to fix dpms on.
>
> Cc:
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 486ccdf..5302c42 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1392,10 +1392,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
> *encoder, int mode)
> case DRM_MODE_DPMS_ON:
> /* some early dce3.2 boards have a bug in their transmitter
> control table */
> if ((rdev->family == CHIP_RV710) || (rdev->family ==
> CHIP_RV730) ||
> - ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
> + ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
> + atombios_dig_encoder_setup(encoder,
> ATOM_ENCODER_CMD_SETUP, 0);
> atombios_dig_transmitter_setup(encoder,
> ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
Maybe make a separate case for DCE61 here? We don't need to execute
ATOM_ENCODER_CMD_SETUP again here on other asics. Also the current
code already calls these two actions in the same order via
radeon_atom_encoder_mode_set() and then
radeon_atom_encoder_dpms_dig(). The difference being that in the
current ordering there are calls to
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
dig->panel_mode);
and
atombios_external_encoder_setup(encoder, ext_encoder,
EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
in between. Does changing the order in radeon_atom_encoder_mode_set()
also fix the issue? e.g.
atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
dig->panel_mode);
atombios_external_encoder_setup(encoder, ext_encoder,
EXTERNAL_ENCODER_ACTION_V3_ENCODER_SETUP);
atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_SETUP, 0);
followed by radeon_atom_encoder_dpms_dig():
atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix dpms on/off on trinity/aruba
From: Jerome Glisse
The external encoder need to be setup again before enabling the
transmiter. This seems to be only needed on some trinity/aruba
to fix dpms on.
Cc:
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_encoders.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 486ccdf..5302c42 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1392,10 +1392,12 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder
*encoder, int mode)
case DRM_MODE_DPMS_ON:
/* some early dce3.2 boards have a bug in their transmitter
control table */
if ((rdev->family == CHIP_RV710) || (rdev->family ==
CHIP_RV730) ||
- ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev))
+ ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+ atombios_dig_encoder_setup(encoder,
ATOM_ENCODER_CMD_SETUP, 0);
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE, 0, 0);
- else
+ } else {
atombios_dig_transmitter_setup(encoder,
ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0);
+ }
if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) &&
connector) {
if (connector->connector_type ==
DRM_MODE_CONNECTOR_eDP) {
atombios_set_edp_panel_power(connector,
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/prime: drop reference on imported dma-buf
On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark wrote: > From: Rob Clark > > The GEM handle takes the reference. If a driver is actually importing a > foreign dmabuf, rather than just re-importing it's own dmabuf, it needs > to do a get_dma_buf(). > > Signed-off-by: Rob Clark [Maybe mention that this is on top of my locking fixes.] We've discussed this a bit on irc and concluded that every function taking care of their own references to the dma buf works best in avoiding potential use-after-free issues when evil userspaces sneaks in a close(dma_buf_fd). Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_prime.c|7 +++ > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 > drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 > drivers/gpu/drm/nouveau/nouveau_prime.c|5 + > drivers/gpu/drm/radeon/radeon_prime.c |4 > drivers/gpu/drm/udl/udl_gem.c |4 > 6 files changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 4f80374..088e018 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > mutex_unlock(&file_priv->prime.lock); > drm_gem_object_unreference_unlocked(obj); > > + /* > +* Drop the ref we obtained w/ dma_buf_get() for the benefit of > +* drivers simply re-importing their own dma-buf.. if drivers > +* import a foreign dma-buf, they should get_dma_buf(). > +*/ > + dma_buf_put(dma_buf); > + > return 0; > > fail: > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > index f270790..f8ac75b 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > @@ -190,6 +190,9 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct > drm_device *drm_dev, > } > } > > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > attach = dma_buf_attach(dma_buf, drm_dev->dev); > if (IS_ERR(attach)) > return ERR_PTR(-EINVAL); > @@ -250,6 +253,7 @@ err_unmap_attach: > dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); > err_buf_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > > diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c > b/drivers/gpu/drm/i915/i915_gem_dmabuf.c > index cf6bdec..9d2b2eb 100644 > --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c > +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c > @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct > drm_device *dev, > } > } > > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > /* need to attach */ > attach = dma_buf_attach(dma_buf, dev->dev); > if (IS_ERR(attach)) > @@ -224,5 +227,6 @@ fail_unmap: > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c > b/drivers/gpu/drm/nouveau/nouveau_prime.c > index 4c82801..fc30886 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_prime.c > +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c > @@ -200,6 +200,10 @@ struct drm_gem_object *nouveau_gem_prime_import(struct > drm_device *dev, > } > } > } > + > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > /* need to attach */ > attach = dma_buf_attach(dma_buf, dev->dev); > if (IS_ERR(attach)) > @@ -223,6 +227,7 @@ fail_unmap: > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > > diff --git a/drivers/gpu/drm/radeon/radeon_prime.c > b/drivers/gpu/drm/radeon/radeon_prime.c > index 28f79ac..073a8d3 100644 > --- a/drivers/gpu/drm/radeon/radeon_prime.c > +++ b/drivers/gpu/drm/radeon/radeon_prime.c > @@ -195,6 +195,9 @@ struct drm_gem_object *radeon_gem_prime_import(struct > drm_device *dev, > } > } > > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > /* need to attach */ > attach = dma_buf_attach(dma_buf, dev->dev); > if (IS_ERR(attach)) > @@ -218,5 +221,6 @@ fail_unmap: > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c > index 7b
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Glück wrote: > Hi, > > My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with > 3.4. Bisected to the following commit: > > 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit > commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e > Author: Ben Skeggs > Date: Mon Apr 30 11:33:43 2012 -0500 > > drm/nouveau: create real execution engine for software object class > > Just a cleanup more or less, and to remove the need for special > handling of > software objects. > > This removes a heap of documentation on dma/graph object formats. > The info > is very out of date with our current understanding, and is far better > documented in rnndb in envytools git. > > Signed-off-by: Ben Skeggs > > lspci: > 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX > 1800M] (rev a2) > Please post the crash log. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Documentation: DocBook DRM framework documentation
Hi Laurent, I've used "behavior" when copying sections from the existing documentation. I'll unify that. Does kernel documentation favour one of the spellings ? Looking at v3.5, the American spelling is more common, but looking at how you spell favour, I think I know which one you favor :) linux-git$ grep -ri behaviour Documentation/ | wc -l 150 linux-git$ grep -ri behavior Documentation/ | wc -l 269 -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/nouveau: crash regression in 3.5
Hi, My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with 3.4. Bisected to the following commit: 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e Author: Ben Skeggs Date: Mon Apr 30 11:33:43 2012 -0500 drm/nouveau: create real execution engine for software object class Just a cleanup more or less, and to remove the need for special handling of software objects. This removes a heap of documentation on dma/graph object formats. The info is very out of date with our current understanding, and is far better documented in rnndb in envytools git. Signed-off-by: Ben Skeggs lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX 1800M] (rev a2) kernel output from a working 3.4: Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Detected an NV50 generation card (0x0a3e00a2) Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: ... appears to be valid Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Using VBIOS from PRAMIN Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: BIT BIOS found Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Bios version 70.15.43.00 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: TMDS table version 2.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: MXM: BIOS version 3.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: MXM: MXMS Version 3.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB version 4.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 00: 01000313 00010034 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 03: 080153d6 0f220020 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 04: 08015392 00020020 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 05: 080143c6 0f220010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 06: 08014382 00020010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 08: 040383b6 0f230014 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 10: 020273a6 0f220010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 11: 02027362 00020010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 13: 02049300 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 00: 0040 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 01: 1161 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 02: 1231 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 03: 01000331 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 04: 01000446 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 05: 02000546 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 06: 00010631 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 07: 00010746 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 08: 00020847 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 09: 0900 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0x7AE4 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 0x7E6B: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 0x7E6F: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0x809A Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0x951E Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0x955C Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0x97CA Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0x982F Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 0x982F: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [TTM] Zone kernel: Available graphics memory: 4008772 kiB Jul 23 19:49:57 localhost kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB Jul 23 19:49:57 localhost kernel: [TTM] Initializing pool allocator Jul 23 19:49:57 localhost kernel: [TTM] Initializing DMA pool allocator Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Detected 1024MiB VRAM (GDDR5) Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 512 MiB GART (aperture) Jul 23 19:49:57 localhost kernel: [drm]
[PATCH] Documentation: DocBook DRM framework documentation
Hi Laurent, > I've used "behavior" when copying sections from the existing documentation. > I'll unify that. Does kernel documentation favour one of the spellings ? > Looking at v3.5, the American spelling is more common, but looking at how you spell favour, I think I know which one you favor :) linux-git$ grep -ri behaviour Documentation/ | wc -l 150 linux-git$ grep -ri behavior Documentation/ | wc -l 269 -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
[PATCH] drm/prime: drop reference on imported dma-buf
Dear Rob, Am Montag, den 23.07.2012, 18:07 -0500 schrieb Rob Clark: > From: Rob Clark > > The GEM handle takes the reference. If a driver is actually importing a > foreign dmabuf, rather than just re-importing it's own dmabuf, it needs > to do a get_dma_buf(). > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/drm_prime.c|7 +++ > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 > drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 > drivers/gpu/drm/nouveau/nouveau_prime.c|5 + > drivers/gpu/drm/radeon/radeon_prime.c |4 > drivers/gpu/drm/udl/udl_gem.c |4 > 6 files changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 4f80374..088e018 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > mutex_unlock(&file_priv->prime.lock); > drm_gem_object_unreference_unlocked(obj); > > + /* > + * Drop the ref we obtained w/ dma_buf_get() for the benefit of > + * drivers simply re-importing their own dma-buf.. if drivers Is that supposed to be an ellipse or a full stop? > + * import a foreign dma-buf, they should get_dma_buf(). Would s,should,should use, be better? > + */ > + dma_buf_put(dma_buf); > + > return 0; > > fail: [?] Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120724/0046fdb4/attachment.pgp>
[Bug 51198] NV43 [GeForce 6600] nouveau in linux kernel 3.4.0 to 3.4.2 hangs at boot
https://bugs.freedesktop.org/show_bug.cgi?id=51198 loisl at email.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from loisl at email.de 2012-07-23 20:41:39 PDT --- Finaly I found out that this is the wrong Product & Component. I have filed the bug again under xorg & Drivers/nouveau sorry. *** This bug has been marked as a duplicate of bug 52411 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #66 from Alexandre Demers 2012-07-23 18:49:17 PDT --- (In reply to comment #37) > (In reply to comment #36) > > I know I can run a 3.2 kernel, I know I can compile a different version or > > bisect or submit patches, I know I can switch from Gnome Shell to another > > window manager without fancy effects or that I can disable options if I > > follow > > your advise. But this is not accessible to the average user. > > You can run an older mesa release as well. It's probably a better as a mesa > knob than a kernel knob. > > > > > Please, consider another option for the average users that will use compiled > > code available soon. > > We can add a mesa option if we aren't able to get this fixed in time for the > next mesa release, but for now I'd prefer to leave it enabled otherwise most > users will just disable it and not test the current code which won't help in > getting it fixed. So it's been a while now and no improvement (even with proposed patches or by running drm-next kernel). Could we add this flag now so it will be possible to disable VM for cayman if wanted? This way, people will still be able to use VM by default, but for those encountering this problem, it will be possible to use their card without seeing it locking up by this code. It will also be possible to enable VM for them to test for any improvement or regression. Nobody's loosing anything. I'll be able to test other commits and new features running programs and piglit tests and once in a while I'll test the VM code (or test any patches or fixes dev could suggest me). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm/prime: drop reference on imported dma-buf
On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark wrote: > From: Rob Clark > > The GEM handle takes the reference. If a driver is actually importing a > foreign dmabuf, rather than just re-importing it's own dmabuf, it needs > to do a get_dma_buf(). > > Signed-off-by: Rob Clark [Maybe mention that this is on top of my locking fixes.] We've discussed this a bit on irc and concluded that every function taking care of their own references to the dma buf works best in avoiding potential use-after-free issues when evil userspaces sneaks in a close(dma_buf_fd). Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_prime.c|7 +++ > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 > drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 > drivers/gpu/drm/nouveau/nouveau_prime.c|5 + > drivers/gpu/drm/radeon/radeon_prime.c |4 > drivers/gpu/drm/udl/udl_gem.c |4 > 6 files changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 4f80374..088e018 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > mutex_unlock(&file_priv->prime.lock); > drm_gem_object_unreference_unlocked(obj); > > + /* > +* Drop the ref we obtained w/ dma_buf_get() for the benefit of > +* drivers simply re-importing their own dma-buf.. if drivers > +* import a foreign dma-buf, they should get_dma_buf(). > +*/ > + dma_buf_put(dma_buf); > + > return 0; > > fail: > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > index f270790..f8ac75b 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c > @@ -190,6 +190,9 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct > drm_device *drm_dev, > } > } > > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > attach = dma_buf_attach(dma_buf, drm_dev->dev); > if (IS_ERR(attach)) > return ERR_PTR(-EINVAL); > @@ -250,6 +253,7 @@ err_unmap_attach: > dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); > err_buf_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > > diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c > b/drivers/gpu/drm/i915/i915_gem_dmabuf.c > index cf6bdec..9d2b2eb 100644 > --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c > +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c > @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct > drm_device *dev, > } > } > > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > /* need to attach */ > attach = dma_buf_attach(dma_buf, dev->dev); > if (IS_ERR(attach)) > @@ -224,5 +227,6 @@ fail_unmap: > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c > b/drivers/gpu/drm/nouveau/nouveau_prime.c > index 4c82801..fc30886 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_prime.c > +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c > @@ -200,6 +200,10 @@ struct drm_gem_object *nouveau_gem_prime_import(struct > drm_device *dev, > } > } > } > + > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > /* need to attach */ > attach = dma_buf_attach(dma_buf, dev->dev); > if (IS_ERR(attach)) > @@ -223,6 +227,7 @@ fail_unmap: > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > > diff --git a/drivers/gpu/drm/radeon/radeon_prime.c > b/drivers/gpu/drm/radeon/radeon_prime.c > index 28f79ac..073a8d3 100644 > --- a/drivers/gpu/drm/radeon/radeon_prime.c > +++ b/drivers/gpu/drm/radeon/radeon_prime.c > @@ -195,6 +195,9 @@ struct drm_gem_object *radeon_gem_prime_import(struct > drm_device *dev, > } > } > > + /* since we are attaching, we need to hold a ref */ > + get_dma_buf(dma_buf); > + > /* need to attach */ > attach = dma_buf_attach(dma_buf, dev->dev); > if (IS_ERR(attach)) > @@ -218,5 +221,6 @@ fail_unmap: > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > + dma_buf_put(dma_buf); > return ERR_PTR(ret); > } > diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c > index 7b
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #67 from Alexandre Demers 2012-07-24 06:53:33 PDT --- Created attachment 64585 --> https://bugs.freedesktop.org/attachment.cgi?id=64585 Adding an environment variable to disable VM if wanted By setting R600_VM=0, we disable the virtual address space code path. By default, the path will still be enabled and used. However, if set to 0, it will prevent some cards (mostly CAYMAN it seems) from locking up or crashing because of the VM code. It is a work around until we figure out why it is locking. -- 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/prime: drop reference on imported dma-buf
Dear Rob, Am Montag, den 23.07.2012, 18:07 -0500 schrieb Rob Clark: > From: Rob Clark > > The GEM handle takes the reference. If a driver is actually importing a > foreign dmabuf, rather than just re-importing it's own dmabuf, it needs > to do a get_dma_buf(). > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/drm_prime.c|7 +++ > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 > drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 > drivers/gpu/drm/nouveau/nouveau_prime.c|5 + > drivers/gpu/drm/radeon/radeon_prime.c |4 > drivers/gpu/drm/udl/udl_gem.c |4 > 6 files changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 4f80374..088e018 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > mutex_unlock(&file_priv->prime.lock); > drm_gem_object_unreference_unlocked(obj); > > + /* > + * Drop the ref we obtained w/ dma_buf_get() for the benefit of > + * drivers simply re-importing their own dma-buf.. if drivers Is that supposed to be an ellipse or a full stop? > + * import a foreign dma-buf, they should get_dma_buf(). Would s,should,should use, be better? > + */ > + dma_buf_put(dma_buf); > + > return 0; > > fail: […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
