[PATCH] drm sis: initialize object_idr
From: Márton Németh The filed object_idr of struct drm_sis_private was introduced with commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6de8a748881f1cd9d795454da2b6db616d5ca3d7 . The idr_init(&dev->object_name_idr) is called instead of idr_init(&dev_priv->object_idr) by mistake, leaving object_idr uninitialized. Correct this. This patch was not tested because of lack of hardware. Signed-off-by: Márton Németh Cc: Daniel Vetter --- diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c index 30d98d1..dd14cd1 100644 --- a/drivers/gpu/drm/sis/sis_drv.c +++ b/drivers/gpu/drm/sis/sis_drv.c @@ -47,9 +47,9 @@ static int sis_driver_load(struct drm_device *dev, unsigned long chipset) if (dev_priv == NULL) return -ENOMEM; + idr_init(&dev_priv->object_idr); dev->dev_private = (void *)dev_priv; dev_priv->chipset = chipset; - idr_init(&dev->object_name_idr); return 0; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[bisected] nouveau: "Failed to idle channel x" after resume
Hi,
after resuming from suspend nouveau starts writing Failed to idle
channel x (where x is 2 or 3) to the log and X appears to stop and then
restart only to stop again. Starting Firefox after resuming triggers the
bugs every time, and bisecting leads to 03bd6efa ("drm/nv50/fifo: use
hardware channel kickoff functionality").
$ grep -i nouveau .config
CONFIG_DRM_NOUVEAU=y
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
# CONFIG_DRM_NOUVEAU_DEBUG is not set
Relevant part of the log (running v3.5-rc2-15-g4e3c8a1):
[ 79.040710] PM: resume of devices complete after 1952.375 msecs
[ 79.041735] PM: Finishing wakeup.
[ 79.064052] Restarting tasks ... done.
[ 79.064064] video LNXVIDEO:00: Restoring backlight state
[ 79.645442] tg3 :09:00.0: irq 47 for MSI/MSI-X
[ 79.707851] IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready
[ 81.288510] tg3 :09:00.0: p3p1: Link is up at 100 Mbps, full duplex
[ 81.288510] tg3 :09:00.0: p3p1: Flow control is on for TX and on for RX
[ 81.289824] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
[ 376.646417] [drm] nouveau :01:00.0: PFIFO: channel 4 unload timeout
[ 378.649010] [sched_delayed] sched: RT throttling activated
[ 384.677024] [drm] nouveau :01:00.0: Failed to idle channel 2.
[ 384.678012] [drm] nouveau :01:00.0: PFIFO: channel 2 unload timeout
[ 389.685024] [drm] nouveau :01:00.0: Failed to idle channel 3.
[ 389.686012] [drm] nouveau :01:00.0: PFIFO: channel 3 unload timeout
[ 401.534024] [drm] nouveau :01:00.0: Failed to idle channel 2.
[ 401.535012] [drm] nouveau :01:00.0: PFIFO: channel 2 unload timeout
...
[ 456.688024] [drm] nouveau :01:00.0: Failed to idle channel 3.
[ 456.689013] [drm] nouveau :01:00.0: PFIFO: channel 3 unload timeout
[ 468.372025] [drm] nouveau :01:00.0: Failed to idle channel 2.
[ 468.373013] [drm] nouveau :01:00.0: PFIFO: channel 2 unload timeout
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers
Hi Laurent, Tomasz, On 06/10/2012 11:28 PM, Laurent Pinchart wrote: Hi Tomasz, On Friday 08 June 2012 16:31:31 Tomasz Stanislawski wrote: Hi Laurent and Subash, I confirm the issue found by Subash. The function vb2_dc_kaddr_to_pages does fail for some occasions. The failures are rather strange like 'got 95 of 150 pages'. It took me some time to find the reason of the problem. I found that dma_alloc_coherent for iommu an ARM does use ioremap_page_range to map a buffer to the kernel space. The mapping is done by updating the page-table. The problem is that any process has a different first-level page-table. The ioremap_page_range updates only the table for init process. The PT present in current->mm shares a majority of entries of 1st-level PT at kernel range (above 0xc000) but *not all*. That is why vb2_dc_kaddr_to_pages worked for small buffers and occasionally failed for larger buffers. I found two ways to fix this problem. a) use&init_mm instead of current->mm while creating an artificial vma b) access the dma memory by calling *((volatile int *)kaddr) = 0; before calling follow_pfn This way a fault is generated and the PT is updated by copying entries from init_mm. What do you think about presented solutions? Just to be sure, this is a hack until dma_get_sgtable is available, and it won't make it to mainline, right ? In that case using init_mm seem easier. Although I agree adding a hack for timebeing, why not use the dma_get_sgtable() RFC itself to solve this in clean way? The hacks anyways cannot go into mainline when vb2 patches get merged. Regards, Subash ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.
Also remove the suspend function since all it does is log.
Signed-off-by: Mark Brown
Acked-by: Francisco Jerez
---
This patch has been sitting around for quite a while now, it's going to
end up blocking improvements in the I2C subsystem at some point.
drivers/gpu/drm/i2c/ch7006_drv.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..74ad254 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
}
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
{
- ch7006_dbg(client, "\n");
-
- return 0;
-}
+ struct i2c_client *client = to_i2c_device(dev);
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, "\n");
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, ch7006_ids);
+static const struct dev_pm_ops ch7006_pm_ops = {
+ .resume = ch7006_resume,
+};
+
static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
- .suspend = ch7006_suspend,
- .resume = ch7006_resume,
.driver = {
.name = "ch7006",
+ .pm = &ch7006_pm_ops,
},
.id_table = ch7006_ids,
--
1.7.10
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] first drm-intel-next for 3.6
Hooray for yet again screwing up the recipient list! /me sucks -Daniel - Forwarded message from Daniel Vetter - Date: Tue, 12 Jun 2012 10:37:51 +0200 From: Daniel Vetter To: Intel Graphics Development , "Sun, Yi" Subject: Re: Updated -next Message-ID: <20120612083751.GA5188@phenom.ffwll.local> Hi Dave, rc2 is out the door so I've figured I'll annoy you with the first -next pull request for 3.6 already. Highlights: - new wait_rendring_timeout interface (Ben) - l3 cache remapping and error uevent support (Ben) - even more infoframes work from Paulo - gen4 hotplug rework from Chris - prep work to make Laurent Pincharts original mode constification for connector->mode_fixup possible QA reported a few new bugs this time around, but no regressions afact. For 3.5 the only thing I'm aware of is the edp vdd dmesg spam Linus originally reported - it looks like that might have been introduced in 3.5. But somehow my brain is routinely offline when I work on that issue, so things seem to take forever (and atm I'm at patch v4 for that little problem). Yours, Daniel The following changes since commit 63bc620b45af8c743ac291c8725933278c712692: radeon: add radeon prime vmap support. (2012-05-31 14:14:01 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-06-04 for you to fetch changes up to 1523c310b3ed964b71a8db16f70c3bc21cc0642e: drm/i915: add min freq control to debugfs (2012-06-04 21:34:47 +0200) Ben Widawsky (8): drm/i915: timeout parameter for seqno wait drm/i915: improve i915_wait_request_begin trace drm/i915: wait render timeout ioctl drm/i915: s/i915_wait_request/i915_wait_seqno/g drm/i915: Dynamic Parity Detection handling drm/i915: enable parity error interrupts drm/i915: remap l3 on hw init drm/i915: l3 parity sysfs interface Chris Wilson (6): drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x drm/i915/hdmi: Query the live connector status bit for G4x drm/i915/dp: For consistency use the DP hotplug synonyms drm/i915/hdmi: Fix reg values for g4x_hdmi_connected Daniel Vetter (14): drm/i915: clarify preferred sdvo input mode code drm/i915: don't silently ignore sdvo mode_set failures drm/i915: there's no cxsr on ilk drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set drm/i915: s/mdelay/msleep/ in the sdvo detect function drm/i915: ivybridge_handle_parity_error should be static drm/i915: initialize the parity work only once drm/i915: simplify sysfs setup code Merge remote-tracking branch 'airlied/drm-prime-vmap' into drm-intel-next-queued drm/i915: clarify IBX dp workaround drm/i915: extract object active state flushing code drm/i915: compute the target_clock for edp directly drm/i915: adjusted_mode->clock in the dp mode_fixup drm/i915: don't chnage the original mode in dp_mode_fixup Jesse Barnes (1): drm/i915: add min freq control to debugfs Paulo Zanoni (11): drm/i915: add set_infoframes to struct intel_hdmi drm/i915: properly alternate between DVI and HDMI drm/i915: only set the HDMI port on the DIP once drm/i915: enable DIP before enabling each InfoFrame drm/i915: don't wait for vblank while writing InfoFrames drm/i915: explicitly disable the DIPs we're not using drm/i915: disable DIP while changing the port drm/i915: don't write 0 to DIP control at HDMI init drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI drm/i915: remove comment about HSW HDMI DIPs drm/i915: add some barriers when changing DIPs drivers/gpu/drm/i915/i915_debugfs.c | 66 +++ drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_gem.c | 242 +++ drivers/gpu/drm/i915/i915_irq.c | 171 - drivers/gpu/drm/i915/i915_reg.h | 56 +- drivers/gpu/drm/i915/i915_sysfs.c | 127 +++- drivers/gpu/drm/i915/i915_trace.h | 28 ++- drivers/gpu/drm/i915/intel_ddi.c|3 +- drivers/gpu/drm/i915/intel_display.c| 47 ++--- drivers/gpu/drm/i915/intel_dp.c | 53 +++--- drivers/gpu/drm/i915/intel_drv.h|9 +- drivers/gpu/drm/i915/intel_hdmi.c | 318 +-- drivers/gpu/drm/i915/intel_overlay.c|4 +- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +- drivers/gpu/drm/i915/intel_sdvo.c | 56 -- include/drm/i915_drm.h | 10 + 18 files changed, 965 insertio
[Bug 50996] New: gnome-shell, video playing fail to work properly
https://bugs.freedesktop.org/show_bug.cgi?id=50996 Bug #: 50996 Summary: gnome-shell, video playing fail to work properly Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Unichrome AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: mxondeb...@free.fr CC: k...@debian.org Created attachment 62920 --> https://bugs.freedesktop.org/attachment.cgi?id=62920 Xorg log Gnome-shell 3.4 from (Debian/wheezy) fails to start (failling back to Gnome classic). Playing video fails to, with vlc colors get corrupted (red is displayed blue or kind of). The graphic card: "VGA compatible controller: VIA Technologies, Inc. KM400/KN400/P4M800 [S3 UniChrome]" -- 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: No screens after (WW) Falling back to old probe method for modesetting
- Original Message - > From: "Rafał Miłecki" > To: xorg-de...@lists.x.org, "dri-devel" , > "Dave Airlie" > Cc: "Alex Deucher" > Sent: Monday, 11 June, 2012 8:55:56 PM > Subject: Re: No screens after (WW) Falling back to old probe method for > modesetting > > 2012/6/11 Rafał Miłecki : > > I'm trying to switch from fbdev to modesetting for my AMD Southern > > Islands VERDE card. Of course I've KMS running just fine, radeon > > module loads and sets correct resolution, dmesg looks alright > > > > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU > > the driver doesn't provide any screens/modes. It looks like this: > > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > > (WW) Falling back to old probe method for modesetting > > (II) UnloadModule: "modesetting" > > (II) Unloading modesetting > > (EE) Screen(s) found, but none have a usable configuration. > > > > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm > > using xf86-video-modesetting from today's git. Any patch/trick to > > debug this issue? > > Attaching Xorg.0.logs Try adding a BusID maybe, though I'm not sure how tested modesetting is with that old an X server. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50999] New: [r300g, bisected] piglit glsl-fs-discard-04 fails
https://bugs.freedesktop.org/show_bug.cgi?id=50999
Bug #: 50999
Summary: [r300g, bisected] piglit glsl-fs-discard-04 fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Keywords: regression
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: pavel.ondra...@email.cz
CC: e...@anholt.net, tstel...@gmail.com
Created attachment 62924
--> https://bugs.freedesktop.org/attachment.cgi?id=62924
RADEON_DEBUG=fp log
./bin/shader_runner tests/shaders/glsl-fs-discard-04.shader_test -auto -fbo
Probe at (0,0)
Expected: 0.00 1.00 0.00 0.00
Observed: 1.00 0.00 0.00 0.00
PIGLIT: {'result': 'fail' }
Regression test shows:
e21b9f1f19d2345026a7fbe095a776d0b64557ec is the first bad commit
commit e21b9f1f19d2345026a7fbe095a776d0b64557ec
Author: Eric Anholt
Date: Fri May 4 13:37:08 2012 -0700
glsl: Remove the opt_discard_simplification pass.
This conflicts with the GLSL 1.30+ rules for derivatives after a
discard has occurred.
Reviewed-by: Kenneth Graunke
llvmpipe works fine, so this may be another uncovered r300 compiler issue.
GPU:RV530
Kernel: 3.4.0-1.fc17.i686
--
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: No screens after (WW) Falling back to old probe method for modesetting
2012/6/12 David Airlie : > - Original Message - >> From: "Rafał Miłecki" >> To: xorg-de...@lists.x.org, "dri-devel" , >> "Dave Airlie" >> Cc: "Alex Deucher" >> Sent: Monday, 11 June, 2012 8:55:56 PM >> Subject: Re: No screens after (WW) Falling back to old probe method for >> modesetting >> >> 2012/6/11 Rafał Miłecki : >> > I'm trying to switch from fbdev to modesetting for my AMD Southern >> > Islands VERDE card. Of course I've KMS running just fine, radeon >> > module loads and sets correct resolution, dmesg looks alright >> > >> > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU >> > the driver doesn't provide any screens/modes. It looks like this: >> > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so >> > (WW) Falling back to old probe method for modesetting >> > (II) UnloadModule: "modesetting" >> > (II) Unloading modesetting >> > (EE) Screen(s) found, but none have a usable configuration. >> > >> > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm >> > using xf86-video-modesetting from today's git. Any patch/trick to >> > debug this issue? >> >> Attaching Xorg.0.logs > > Try adding a BusID maybe, though I'm not sure how tested modesetting is with > that old an X server. I already have it added. It's weird modesetting doesn't put any message in Xorg.0.log, it has few messages printing in source. Will put some debugging in modesetting to see what actually happens. -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50996] gnome-shell, video playing fail to work properly
https://bugs.freedesktop.org/show_bug.cgi?id=50996 kaliko changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/DRI/Unichrome |Other -- 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 51000] New: [r300g, bisected] piglit fbo-generatemipmap-formats fails
https://bugs.freedesktop.org/show_bug.cgi?id=51000
Bug #: 51000
Summary: [r300g, bisected] piglit fbo-generatemipmap-formats
fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Keywords: regression
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: pavel.ondra...@email.cz
CC: kenn...@whitecape.org
./bin/fbo-generatemipmap-formats -auto GL_EXT_texture_compression_rgtc
Using test set: GL_EXT_texture_compression_rgtc
Testing GL_COMPRESSED_RED
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RED_RGTC1_EXT
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RG
Testing GL_COMPRESSED_RED_GREEN_RGTC2_EXT
Testing GL_COMPRESSED_RED (NPOT)
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RED_RGTC1_EXT (NPOT)
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RG (NPOT)
Testing GL_COMPRESSED_RED_GREEN_RGTC2_EXT (NPOT)
PIGLIT: {'result': 'fail' }
f8d40deea5c4abbbf93c2c572ce668a5a25f95e2 is the first bad commit
commit f8d40deea5c4abbbf93c2c572ce668a5a25f95e2
Author: Kenneth Graunke
Date: Tue Jun 5 23:51:04 2012 -0700
mesa: Return 8 bits for GL_TEXTURE_RED_SIZE on RGTC formats.
From the issues section of the GL_ARB_texture_compression_rgtc extension:
15) What should glGetTexLevelParameter return for
GL_TEXTURE_GREEN_SIZE and GL_TEXTURE_BLUE_SIZE for the RGTC1
formats? What should glGetTexLevelParameter return for
GL_TEXTURE_BLUE_SIZE for the RGTC2 formats?
RESOLVED: Zero bits.
These formats always return 0.0 for these respective components
and have no bits devoted to these components.
Returning 8 bits for red size of RGTC1 and the red and green
sizes of RGTC2 makes sense because that's the maximum potential
precision for the uncompressed texels.
Thus, we need to return 8 bits for GL_TEXTURE_RED_SIZE on all RGTC formats
and 8 bits for GL_TEXTURE_GREEN_SIZE on RGTC2 formats. BLUE should be 0.
Fixes oglconform/rgtc/advanced.texture_fetch.tex_param.
Signed-off-by: Kenneth Graunke
Reviewed-by: Brian Paul
BTW llvmpipe works fine.
GPU:RV530
Kernel: 3.4.0-1.fc17.i686
--
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 13720] [2.6.30] Modesetting on Mobility Radeon X700 displays black screen
https://bugzilla.kernel.org/show_bug.cgi?id=13720 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||CODE_FIX -- 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 13720] [2.6.30] Modesetting on Mobility Radeon X700 displays black screen
https://bugzilla.kernel.org/show_bug.cgi?id=13720 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 -fixes] drm/ttm: Fix buffer object metadata accounting regression
A regression was introduced in the 3.3 rc series, commit
"drm/ttm: simplify memory accounting for ttm user v2",
causing the metadata of buffer objects created using the ttm_bo_create()
function to be accounted twice.
That causes massive leaks with the vmwgfx driver running for example
SpecViewperf Catia-03 test 2, eventually killing the app.
Furthermore, the same commit introduces a regression where
metadata accounting is leaked if a buffer object is
initialized with an illegal size. This is also fixed with this commit.
Signed-off-by: Thomas Hellstrom
Cc: Jerome Glisse
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b67cfca..4baea2f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
(*destroy)(bo);
else
kfree(bo);
+ ttm_mem_global_free(mem_glob, acc_size);
return -EINVAL;
}
bo->destroy = destroy;
@@ -1312,10 +1313,6 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
int ret;
acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
- ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
- if (unlikely(ret != 0))
- return ret;
-
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
if (unlikely(bo == NULL)) {
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression v2
A regression was introduced in the 3.3 rc series, commit
"drm/ttm: simplify memory accounting for ttm user v2",
causing the metadata of buffer objects created using the ttm_bo_create()
function to be accounted twice.
That causes massive leaks with the vmwgfx driver running for example
SpecViewperf Catia-03 test 2, eventually killing the app.
Furthermore, the same commit introduces a regression where
metadata accounting is leaked if a buffer object is
initialized with an illegal size. This is also fixed with this commit.
v2: Fixed an error path and removed an unused variable.
Signed-off-by: Thomas Hellstrom
Cc: Jerome Glisse
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b67cfca..36f4b28 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
(*destroy)(bo);
else
kfree(bo);
+ ttm_mem_global_free(mem_glob, acc_size);
return -EINVAL;
}
bo->destroy = destroy;
@@ -1307,22 +1308,14 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
struct ttm_buffer_object **p_bo)
{
struct ttm_buffer_object *bo;
- struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
size_t acc_size;
int ret;
- acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
- ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
- if (unlikely(ret != 0))
- return ret;
-
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
-
- if (unlikely(bo == NULL)) {
- ttm_mem_global_free(mem_glob, acc_size);
+ if (unlikely(bo == NULL))
return -ENOMEM;
- }
+ acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
buffer_start, interruptible,
persistent_swap_storage, acc_size, NULL, NULL);
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 07/12] drm/i915: only enable drm agp support when required
On Thu, 07 Jun 2012, Daniel Vetter wrote:
> We need it for all things ums (which essentially only means up to
> gen5) and to support b0rked XvMC userspace on gen3.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 21 -
> 1 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index e4203df..0ab5d3d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> int ret = 0, mmio_bar;
> uint32_t aperture_size;
>
> - ret = drm_pci_agp_init(dev);
> - if (ret)
> - return ret;
> -
> - if (!dev->agp) {
> - DRM_ERROR("Cannot initialize the agpgart module.\n");
> - return -EINVAL;
> - }
> -
> info = (struct intel_device_info *) flags;
>
> /* Refuse to load on gen6+ without kms enabled. */
> @@ -1453,6 +1444,18 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> dev_priv->dev = dev;
> dev_priv->info = info;
>
> + if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> + IS_GEN3(dev)) {
> + ret = drm_pci_agp_init(dev);
> + if (ret)
> + return ret;
> +
> + if (!dev->agp) {
> + DRM_ERROR("Cannot initialize the agpgart module.\n");
> + return -EINVAL;
> + }
You need to goto free_priv in the above error paths.
Should there be a deinit of drm_pci_agp_init() if something goes wrong
afterwards?
BR,
Jani.
> + }
> +
> if (i915_get_bridge_dev(dev)) {
> ret = -EIO;
> goto free_priv;
> --
> 1.7.7.6
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 07/12] drm/i915: only enable drm agp support when required
On Tue, Jun 12, 2012 at 02:58:25PM +0300, Jani Nikula wrote:
> On Thu, 07 Jun 2012, Daniel Vetter wrote:
> > We need it for all things ums (which essentially only means up to
> > gen5) and to support b0rked XvMC userspace on gen3.
> >
> > Signed-Off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 21 -
> > 1 files changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index e4203df..0ab5d3d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > int ret = 0, mmio_bar;
> > uint32_t aperture_size;
> >
> > - ret = drm_pci_agp_init(dev);
> > - if (ret)
> > - return ret;
> > -
> > - if (!dev->agp) {
> > - DRM_ERROR("Cannot initialize the agpgart module.\n");
> > - return -EINVAL;
> > - }
> > -
> > info = (struct intel_device_info *) flags;
> >
> > /* Refuse to load on gen6+ without kms enabled. */
> > @@ -1453,6 +1444,18 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > dev_priv->dev = dev;
> > dev_priv->info = info;
> >
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> > + IS_GEN3(dev)) {
> > + ret = drm_pci_agp_init(dev);
> > + if (ret)
> > + return ret;
> > +
> > + if (!dev->agp) {
> > + DRM_ERROR("Cannot initialize the agpgart module.\n");
> > + return -EINVAL;
> > + }
>
> You need to goto free_priv in the above error paths.
Nice catch, will fix.
> Should there be a deinit of drm_pci_agp_init() if something goes wrong
> afterwards?
drm core should do that for use (but currently doesn't) by deinit agp if
it's initialized. The follow-up patches to wrestle the drm driver init
paths /should/ take care of this though.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: only enable drm agp support when required
We need it for all things ums (which essentially only means up to
gen5) and to support b0rked XvMC userspace on gen3.
v2: Fixup error paths as noticed by Jani Nikula.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e4203df..1f6a36a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
int ret = 0, mmio_bar;
uint32_t aperture_size;
- ret = drm_pci_agp_init(dev);
- if (ret)
- return ret;
-
- if (!dev->agp) {
- DRM_ERROR("Cannot initialize the agpgart module.\n");
- return -EINVAL;
- }
-
info = (struct intel_device_info *) flags;
/* Refuse to load on gen6+ without kms enabled. */
@@ -1453,6 +1444,19 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
dev_priv->dev = dev;
dev_priv->info = info;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
+ IS_GEN3(dev)) {
+ ret = drm_pci_agp_init(dev);
+ if (ret)
+ goto free_priv;
+
+ if (!dev->agp) {
+ DRM_ERROR("Cannot initialize the agpgart module.\n");
+ ret = -EINVAL;
+ goto free_priv;
+ }
+ }
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: don't check intel_agp_enabled any more
We won't enabled agp unconditionally. Furthermore we do have
the right checks for agp support in place in our ->load
function.
The only thing this variable still does is enforce the module
load order we want (and I'm not even sure whether it succeeds
for that). Hence just use it in a harmless place somewhere.
v2: Fixup rebase.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |6 +-
drivers/gpu/drm/i915/i915_drv.c |6 --
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a8f8477..6290aea 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1404,6 +1404,8 @@ i915_mtrr_setup(struct drm_i915_private *dev_priv,
unsigned long base,
}
}
+extern int intel_agp_enabled;
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -1451,7 +1453,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto free_priv;
if (!dev->agp) {
- DRM_ERROR("Cannot initialize the agpgart module.\n");
+ DRM_ERROR("Cannot initialize the agpgart module,"
+ "intel_agp_enabled: %i.\n",
+ intel_agp_enabled);
ret = -EINVAL;
goto free_priv;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3390213..e4df5a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -119,7 +119,6 @@ MODULE_PARM_DESC(i915_enable_ppgtt,
"Enable PPGTT (default: true)");
static struct drm_driver driver;
-extern int intel_agp_enabled;
#define INTEL_VGA_DEVICE(id, info) { \
.class = PCI_BASE_CLASS_DISPLAY << 16, \
@@ -1093,11 +1092,6 @@ static struct pci_driver i915_pci_driver = {
static int __init i915_init(void)
{
- if (!intel_agp_enabled) {
- DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
- return -ENODEV;
- }
-
driver.num_ioctls = i915_max_ioctl;
/*
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: fixup error path after drm_fill_in_dev
On Fri, 08 Jun 2012, Daniel Vetter wrote:
> Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
> case of failures. But the callers of drm_fill_in_dev simply don't do
> anything. Now from a cursory look drm_lastclose doesn't look like the
> best cleanup function in itself, but whom am I to judge the drm error
> paths. Imo before we could tackle this we need to move more of the
> legacy drm services setup and teardown into the respective drivers,
> that way drm_lastclose would become more manageble.
>
> Anyway, make things at least consistent by adding drm_lastclose at the
> right places in the error paths for all callers of drm_fill_in_dev.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_pci.c |8 +---
> drivers/gpu/drm/drm_platform.c |8 +---
> drivers/gpu/drm/drm_usb.c |8 +---
> 3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 73218ac..40737a8 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -334,14 +334,14 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
> pci_device_id *ent,
>
> if ((ret = drm_fill_in_dev(dev, ent, driver))) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g2;
> + goto err_pci;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> pci_set_drvdata(pdev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g2;
> + goto err_drm_fill_in;
> }
>
> if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
> @@ -375,7 +375,9 @@ err_g4:
> err_g3:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g2:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_pci:
> pci_disable_device(pdev);
> err_g1:
> kfree(dev);
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index 82431dc..177893a 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -60,14 +60,14 @@ int drm_get_platform_dev(struct platform_device *platdev,
>
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_kfree;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> dev_set_drvdata(&platdev->dev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_drm_fill_in;
> }
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> @@ -103,7 +103,9 @@ err_g3:
> err_g2:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
> index 37c9a52..2e179f1 100644
> --- a/drivers/gpu/drm/drm_usb.c
> +++ b/drivers/gpu/drm/drm_usb.c
> @@ -25,13 +25,13 @@ int drm_get_usb_dev(struct usb_interface *interface,
> ret = drm_fill_in_dev(dev, NULL, driver);
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_drm_fill_in;
> }
>
> usb_set_intfdata(interface, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_kfree;
The above gotos err_drm_fill_in/err_kfree should switch places.
BR,
Jani.
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> if (ret)
> @@ -63,7 +63,9 @@ err_g3:
> drm_put_minor(&dev->primary);
> err_g2:
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> --
> 1.7.7.6
>
> ___
> 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: fixup error path after drm_fill_in_dev
Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
case of failures. But the callers of drm_fill_in_dev simply don't do
anything. Now from a cursory look drm_lastclose doesn't look like the
best cleanup function in itself, but whom am I to judge the drm error
paths. Imo before we could tackle this we need to move more of the
legacy drm services setup and teardown into the respective drivers,
that way drm_lastclose would become more manageble.
Anyway, make things at least consistent by adding drm_lastclose at the
right places in the error paths for all callers of drm_fill_in_dev.
v2: Fixup the error-path confusion in drm_usb.c, noticed by Jani
Nikula.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c |8 +---
drivers/gpu/drm/drm_platform.c |8 +---
drivers/gpu/drm/drm_usb.c |8 +---
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 73218ac..40737a8 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -334,14 +334,14 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
if ((ret = drm_fill_in_dev(dev, ent, driver))) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g2;
+ goto err_pci;
}
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
pci_set_drvdata(pdev, dev);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
- goto err_g2;
+ goto err_drm_fill_in;
}
if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
@@ -375,7 +375,9 @@ err_g4:
err_g3:
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(&dev->control);
-err_g2:
+err_drm_fill_in:
+ drm_lastclose(dev);
+err_pci:
pci_disable_device(pdev);
err_g1:
kfree(dev);
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 82431dc..177893a 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -60,14 +60,14 @@ int drm_get_platform_dev(struct platform_device *platdev,
if (ret) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g1;
+ goto err_kfree;
}
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
dev_set_drvdata(&platdev->dev, dev);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
- goto err_g1;
+ goto err_drm_fill_in;
}
ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
@@ -103,7 +103,9 @@ err_g3:
err_g2:
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(&dev->control);
-err_g1:
+err_drm_fill_in:
+ drm_lastclose(dev);
+err_kfree:
kfree(dev);
mutex_unlock(&drm_global_mutex);
return ret;
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index 37c9a52..f9d645f 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -25,13 +25,13 @@ int drm_get_usb_dev(struct usb_interface *interface,
ret = drm_fill_in_dev(dev, NULL, driver);
if (ret) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g1;
+ goto err_kfree;
}
usb_set_intfdata(interface, dev);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
- goto err_g1;
+ goto err_drm_fill_in;
ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
if (ret)
@@ -63,7 +63,9 @@ err_g3:
drm_put_minor(&dev->primary);
err_g2:
drm_put_minor(&dev->control);
-err_g1:
+err_drm_fill_in:
+ drm_lastclose(dev);
+err_kfree:
kfree(dev);
mutex_unlock(&drm_global_mutex);
return ret;
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] clear up drm/agp initialization madness
On Thu, 07 Jun 2012, Daniel Vetter wrote: > Comments, flames and reviews highly welcome. If possible I'd like to get the 3 > drm patches at the beginning in early for 3.6 so that we can decently test it > (and have some time to pile more stuff on top of this in drm/i915 land). On the series and the fixes to it, with the disclaimer that I don't have much experience with drm/i915/gtt yet: Reviewed-by: Jani Nikula ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fixup error path after drm_fill_in_dev
On Tue, 12 Jun 2012, Daniel Vetter wrote:
> Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
> case of failures. But the callers of drm_fill_in_dev simply don't do
> anything. Now from a cursory look drm_lastclose doesn't look like the
> best cleanup function in itself, but whom am I to judge the drm error
> paths. Imo before we could tackle this we need to move more of the
> legacy drm services setup and teardown into the respective drivers,
> that way drm_lastclose would become more manageble.
>
> Anyway, make things at least consistent by adding drm_lastclose at the
> right places in the error paths for all callers of drm_fill_in_dev.
>
> v2: Fixup the error-path confusion in drm_usb.c, noticed by Jani
> Nikula.
You could just claim you planted it there for me. ;)
On the series,
Reviewed-by: Jani Nikula
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_pci.c |8 +---
> drivers/gpu/drm/drm_platform.c |8 +---
> drivers/gpu/drm/drm_usb.c |8 +---
> 3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 73218ac..40737a8 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -334,14 +334,14 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
> pci_device_id *ent,
>
> if ((ret = drm_fill_in_dev(dev, ent, driver))) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g2;
> + goto err_pci;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> pci_set_drvdata(pdev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g2;
> + goto err_drm_fill_in;
> }
>
> if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
> @@ -375,7 +375,9 @@ err_g4:
> err_g3:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g2:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_pci:
> pci_disable_device(pdev);
> err_g1:
> kfree(dev);
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index 82431dc..177893a 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -60,14 +60,14 @@ int drm_get_platform_dev(struct platform_device *platdev,
>
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_kfree;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> dev_set_drvdata(&platdev->dev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_drm_fill_in;
> }
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> @@ -103,7 +103,9 @@ err_g3:
> err_g2:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
> index 37c9a52..f9d645f 100644
> --- a/drivers/gpu/drm/drm_usb.c
> +++ b/drivers/gpu/drm/drm_usb.c
> @@ -25,13 +25,13 @@ int drm_get_usb_dev(struct usb_interface *interface,
> ret = drm_fill_in_dev(dev, NULL, driver);
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_kfree;
> }
>
> usb_set_intfdata(interface, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_drm_fill_in;
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> if (ret)
> @@ -63,7 +63,9 @@ err_g3:
> drm_put_minor(&dev->primary);
> err_g2:
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> --
> 1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression v2
On Tue, Jun 12, 2012 at 01:28:42PM +0200, Thomas Hellstrom wrote:
> A regression was introduced in the 3.3 rc series, commit
> "drm/ttm: simplify memory accounting for ttm user v2",
> causing the metadata of buffer objects created using the ttm_bo_create()
> function to be accounted twice.
> That causes massive leaks with the vmwgfx driver running for example
> SpecViewperf Catia-03 test 2, eventually killing the app.
>
> Furthermore, the same commit introduces a regression where
> metadata accounting is leaked if a buffer object is
> initialized with an illegal size. This is also fixed with this commit.
>
> v2: Fixed an error path and removed an unused variable.
>
> Signed-off-by: Thomas Hellstrom
> Cc: Jerome Glisse
> Cc: sta...@vger.kernel.org
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
> 1 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index b67cfca..36f4b28 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> (*destroy)(bo);
> else
> kfree(bo);
> + ttm_mem_global_free(mem_glob, acc_size);
> return -EINVAL;
> }
> bo->destroy = destroy;
> @@ -1307,22 +1308,14 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
> struct ttm_buffer_object **p_bo)
> {
> struct ttm_buffer_object *bo;
> - struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
> size_t acc_size;
> int ret;
>
> - acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
> ttm_buffer_object));
> - ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
> - if (unlikely(ret != 0))
> - return ret;
> -
> bo = kzalloc(sizeof(*bo), GFP_KERNEL);
> -
> - if (unlikely(bo == NULL)) {
> - ttm_mem_global_free(mem_glob, acc_size);
> + if (unlikely(bo == NULL))
> return -ENOMEM;
> - }
>
> + acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
> ttm_buffer_object));
> ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
> buffer_start, interruptible,
> persistent_swap_storage, acc_size, NULL, NULL);
> --
> 1.7.7.5
>
> ___
> 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
[Bug 43367] New: radeon: NULL pointer dereference on switching to dynpm power method
https://bugzilla.kernel.org/show_bug.cgi?id=43367 Summary: radeon: NULL pointer dereference on switching to dynpm power method Product: Drivers Version: 2.5 Kernel Version: 3.5-rc2 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: haagch.christ...@googlemail.com Regression: Yes Created an attachment (id=73570) --> (https://bugzilla.kernel.org/attachment.cgi?id=73570) console log of the bug After changing to dynpm with # echo dynpm > /sys/class/drm/card0/device/power_method I immediately get the attached kernel Oops. Power profiles work fine. -- 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: increase DRM_OBJECT_MAX_PROPERTY to 24
From: Paulo Zanoni
Before Kernel 3.5, no one was checking for the return value of
drm_connector_attach_property, so we never noticed that we were unable
to create some properties. Commit "drm: WARN() when
drm_connector_attach_property fails" added a WARN when we fail to
create a property, and the transition from "connector properties" to
"object properties" changed the warning message a little bit.
On i915 machines with many TV connectors we hit the maximum number of
properties (since each TV connector uses a lot of properties), so we
get a few backtraces in our logs. This commit increases the maximum
number of properties to 24 hoping we'll have enough room for
everybody.
Chris suggested that we convert this code to "lists", but I believe
this conversion can come after we make sure people's dmesgs are not
spammed by our driver.
Signed-off-by: Paulo Zanoni
Reported-by: Dave Jones
Tested-by: Daniel Vetter
---
include/drm/drm_crtc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73e4560..bac55c2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -54,7 +54,7 @@ struct drm_mode_object {
struct drm_object_properties *properties;
};
-#define DRM_OBJECT_MAX_PROPERTY 16
+#define DRM_OBJECT_MAX_PROPERTY 24
struct drm_object_properties {
int count;
uint32_t ids[DRM_OBJECT_MAX_PROPERTY];
--
1.7.10
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: No screens after (WW) Falling back to old probe method for modesetting
2012/6/11 Rafał Miłecki : > I'm trying to switch from fbdev to modesetting for my AMD Southern > Islands VERDE card. Of course I've KMS running just fine, radeon > module loads and sets correct resolution, dmesg looks alright > > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU > the driver doesn't provide any screens/modes. It looks like this: > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > (WW) Falling back to old probe method for modesetting > (II) UnloadModule: "modesetting" > (II) Unloading modesetting > (EE) Screen(s) found, but none have a usable configuration. > > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm > using xf86-video-modesetting from today's git. Any patch/trick to > debug this issue? I don't think old X server is an issue here. The function to focus on is probe_hw_pci. This function calls "open_hw" which opens /dev/dri/card0 and return fd (9 in my case, irrelevant). Then comes the moment when probe_hw_pci calls: id = drmGetBusid(fd); devid = ms_DRICreatePCIBusID(pdev); The first one returns NULL, the second one returns "pci::03:00.0". As the "id" is NULL (empty string) probe_hw_pci returns false and the rest fails. I can't say why drmGetBusid returns NULL. My drm is from yesterday's git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK. Hacking probe_hw_pci to return TRUE allows me start X with modesetting. -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51000] [r300g, bisected] piglit fbo-generatemipmap-formats fails
https://bugs.freedesktop.org/show_bug.cgi?id=51000 Kenneth Graunke changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |e...@anholt.net |.org| QAContact||e...@anholt.net Product|Mesa|piglit Version|git |unspecified Component|Drivers/Gallium/r300|tests --- Comment #1 from Kenneth Graunke 2012-06-12 08:09:02 PDT --- Hmm. That patch shouldn't have changed the result at all---and it does look fairly close---so I think your hardware just has somewhat lower precision than mine. The Piglit test uses GL_RED_SIZE etc. to determine the tolerances/precision expected, so with the increase from 4 to 8, the test became more stringent. Normally this would make sense, but since GL_RED_SIZE and friends are /approximate/ precision for a compressed format---and in this case, the /maximum/ precision---I think we may need to lower the test's tolerances. Changing this to a Piglit bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/prime: reserve/unreserve around pin
From: Dave Airlie
I finally got to test this code a bit more and hit the ttm
no reserved assert, so add the reservations around the pinning.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_prime.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index 8ddab4c7..6bef46a 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -169,11 +169,17 @@ struct dma_buf *radeon_gem_prime_export(struct drm_device
*dev,
struct radeon_bo *bo = gem_to_radeon_bo(obj);
int ret = 0;
+ ret = radeon_bo_reserve(bo, false);
+ if (unlikely(ret != 0))
+ return ERR_PTR(ret);
+
/* pin buffer into GTT */
ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
- if (ret)
+ if (ret) {
+ radeon_bo_unreserve(bo);
return ERR_PTR(ret);
-
+ }
+ radeon_bo_unreserve(bo);
return dma_buf_export(bo, &radeon_dmabuf_ops, obj->size, flags);
}
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/prime: reserve/unreserve around pin
On Tue, Jun 12, 2012 at 11:10 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> I finally got to test this code a bit more and hit the ttm
> no reserved assert, so add the reservations around the pinning.
Good catch.
Reviewed-by: Alex Deucher
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_prime.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 8ddab4c7..6bef46a 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -169,11 +169,17 @@ struct dma_buf *radeon_gem_prime_export(struct
> drm_device *dev,
> struct radeon_bo *bo = gem_to_radeon_bo(obj);
> int ret = 0;
>
> + ret = radeon_bo_reserve(bo, false);
> + if (unlikely(ret != 0))
> + return ERR_PTR(ret);
> +
> /* pin buffer into GTT */
> ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> - if (ret)
> + if (ret) {
> + radeon_bo_unreserve(bo);
> return ERR_PTR(ret);
> -
> + }
> + radeon_bo_unreserve(bo);
> return dma_buf_export(bo, &radeon_dmabuf_ops, obj->size, flags);
> }
>
> --
> 1.7.7.6
>
> ___
> 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
[git pull] drm fixes
Hi Linus as per your -rc2 announce, this is small and urgent only, The radeon one is for a regression in 3.4 so we need this one in your tree so we can send the stable one out, code in 3.4 broke some old userspaces. The max props increase fixes spew being seen on a few machines. and a ttm regression to fix some accounting issues that affect vmwgfx. Dave. The following changes since commit cfaf025112d3856637ff34a767ef785ef5cf2ca9: Linux 3.5-rc2 (2012-06-08 18:40:09 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to a393c730ab69617c3291a3b0b2a228c9be2fc28c: drm/ttm: Fix buffer object metadata accounting regression v2 (2012-06-12 15:57:47 +0100) Jerome Glisse (1): drm/radeon: fix tiling and command stream checking on evergreen v3 Paulo Zanoni (1): drm: increase DRM_OBJECT_MAX_PROPERTY to 24 Thomas Hellstrom (1): drm/ttm: Fix buffer object metadata accounting regression v2 drivers/gpu/drm/radeon/evergreen_cs.c | 49 ++--- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/ttm/ttm_bo.c | 13 ++--- include/drm/drm_crtc.h|2 +- 4 files changed, 51 insertions(+), 16 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: No screens after (WW) Falling back to old probe method for modesetting
2012/6/12 Rafał Miłecki : > 2012/6/11 Rafał Miłecki : >> I'm trying to switch from fbdev to modesetting for my AMD Southern >> Islands VERDE card. Of course I've KMS running just fine, radeon >> module loads and sets correct resolution, dmesg looks alright >> >> Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU >> the driver doesn't provide any screens/modes. It looks like this: >> (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so >> (WW) Falling back to old probe method for modesetting >> (II) UnloadModule: "modesetting" >> (II) Unloading modesetting >> (EE) Screen(s) found, but none have a usable configuration. >> >> Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm >> using xf86-video-modesetting from today's git. Any patch/trick to >> debug this issue? > > I don't think old X server is an issue here. The function to focus on > is probe_hw_pci. > > This function calls "open_hw" which opens /dev/dri/card0 and return fd > (9 in my case, irrelevant). Then comes the moment when probe_hw_pci > calls: > id = drmGetBusid(fd); > devid = ms_DRICreatePCIBusID(pdev); > > The first one returns NULL, the second one returns "pci::03:00.0". > As the "id" is NULL (empty string) probe_hw_pci returns false and the > rest fails. > > I can't say why drmGetBusid returns NULL. My drm is from yesterday's > git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK. > Hacking probe_hw_pci to return TRUE allows me start X with > modesetting. I've hacked xf86drm.c::drmGetBusid to print some debugging messages. When we call "drmGetBusid" in "probe_hw_pci", u.unique_len gets 0 and u.unique gets "\0". However I've noticed there's one more call to "drmGetBusid". The stacktrace is: PreInit → drmOpen(NULL, BusID) → drmOpenByBusid → drmGetBusid In the above call, drmGetBusid gets u.unique_len gets 16 and u.unique gets "pci::03:00.0\0". Does it give you any hint what can happen here? -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression v2
On Tue, Jun 12, 2012 at 8:50 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jun 12, 2012 at 01:28:42PM +0200, Thomas Hellstrom wrote:
>> A regression was introduced in the 3.3 rc series, commit
>> "drm/ttm: simplify memory accounting for ttm user v2",
>> causing the metadata of buffer objects created using the ttm_bo_create()
>> function to be accounted twice.
>> That causes massive leaks with the vmwgfx driver running for example
>> SpecViewperf Catia-03 test 2, eventually killing the app.
>>
>> Furthermore, the same commit introduces a regression where
>> metadata accounting is leaked if a buffer object is
>> initialized with an illegal size. This is also fixed with this commit.
>>
>> v2: Fixed an error path and removed an unused variable.
>>
>> Signed-off-by: Thomas Hellstrom
>> Cc: Jerome Glisse
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Jerome Glisse
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
>> 1 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index b67cfca..36f4b28 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
>> (*destroy)(bo);
>> else
>> kfree(bo);
>> + ttm_mem_global_free(mem_glob, acc_size);
>> return -EINVAL;
>> }
>> bo->destroy = destroy;
>> @@ -1307,22 +1308,14 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
>> struct ttm_buffer_object **p_bo)
>> {
>> struct ttm_buffer_object *bo;
>> - struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
>> size_t acc_size;
>> int ret;
>>
>> - acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
>> ttm_buffer_object));
>> - ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
>> - if (unlikely(ret != 0))
>> - return ret;
>> -
>> bo = kzalloc(sizeof(*bo), GFP_KERNEL);
>> -
>> - if (unlikely(bo == NULL)) {
>> - ttm_mem_global_free(mem_glob, acc_size);
>> + if (unlikely(bo == NULL))
>> return -ENOMEM;
>> - }
>>
>> + acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
>> ttm_buffer_object));
>> ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
>> buffer_start, interruptible,
>> persistent_swap_storage, acc_size, NULL, NULL);
>> --
>> 1.7.7.5
>>
>> ___
>> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47519] Xorg hangs in ioCtl in path of RADEONDownloadFromScreenCS
https://bugs.freedesktop.org/show_bug.cgi?id=47519 --- Comment #13 from Jeremy Huddleston 2012-06-12 09:15:31 PDT --- *** Bug 47512 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/prime: reserve/unreserve around pin
On Die, 2012-06-12 at 16:10 +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> I finally got to test this code a bit more and hit the ttm
> no reserved assert, so add the reservations around the pinning.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_prime.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 8ddab4c7..6bef46a 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -169,11 +169,17 @@ struct dma_buf *radeon_gem_prime_export(struct
> drm_device *dev,
> struct radeon_bo *bo = gem_to_radeon_bo(obj);
> int ret = 0;
>
> + ret = radeon_bo_reserve(bo, false);
> + if (unlikely(ret != 0))
> + return ERR_PTR(ret);
> +
> /* pin buffer into GTT */
> ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> - if (ret)
> + if (ret) {
> + radeon_bo_unreserve(bo);
> return ERR_PTR(ret);
> -
> + }
> + radeon_bo_unreserve(bo);
Could just add single radeon_bo_unreserve() call right after the
radeon_bo_pin() call, but either way
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47519] Xorg hangs in ioCtl in path of RADEONDownloadFromScreenCS
https://bugs.freedesktop.org/show_bug.cgi?id=47519 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Michel Dänzer 2012-06-12 09:43:52 PDT --- Current Linux kernels disable MSI by default on these cards. -- 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 50980] [r300g, bisected] WebGL cars demo crash (r300_emit.c:865:r300_emit_vertex_arrays: Assertion `(buf)' failed)
https://bugs.freedesktop.org/show_bug.cgi?id=50980 --- Comment #1 from Pavel Ondračka 2012-06-12 12:26:19 PDT --- Created attachment 62942 --> https://bugs.freedesktop.org/attachment.cgi?id=62942 gl-max-texture-dimensions webgl test backtrace Another variation of this crash can be seen with conformance/limits/gl-max-texture-dimensions.html test from webgl conformance test suite. The backtrace is different, but regression test showed the same commit. -- 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/si: check for CE ucode as well when loading ucode
From: Alex Deucher Fixes possible segfault if the CE ucode is missing. Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/si.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 9248a91..d500911 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -1825,7 +1825,7 @@ static int si_cp_load_microcode(struct radeon_device *rdev) const __be32 *fw_data; int i; - if (!rdev->me_fw || !rdev->pfp_fw) + if (!rdev->me_fw || !rdev->pfp_fw || !rdev->ce_fw) return -EINVAL; si_cp_enable(rdev, false); -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] clear up drm/agp initialization madness
On Tue, Jun 12, 2012 at 03:46:35PM +0300, Jani Nikula wrote: > On Thu, 07 Jun 2012, Daniel Vetter wrote: > > Comments, flames and reviews highly welcome. If possible I'd like to get > > the 3 > > drm patches at the beginning in early for 3.6 so that we can decently test > > it > > (and have some time to pile more stuff on top of this in drm/i915 land). > > On the series and the fixes to it, with the disclaimer that I don't have > much experience with drm/i915/gtt yet: > > Reviewed-by: Jani Nikula Ok, I've picked up all the prep patches that don't depend upon the drm core rework. Thanks for taking a lock at these patches. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
about_radeon_dma
HI,all Now, my lab is using radeon_ati card。And, I need ati_card dma function。But, I do not clear that how the ati card know the dma address which alloced by kernel?? Can any kernel drivers for radeon card give me some advise or explain the answer? I have read the radeon driver in kernel (/driver/gpu/drm/randeon/xxx ）and the TTM manager. So, as I know, If I use GFP_KERNEL sign to alloc memory, the radeon_card work right, but any other palce ,it failed. Why and how this happened? Is there any way to tell the dma address and ring buffer address in kernel to the radeon_card ? It`s so confused! Hope for your answer! Thanks so much! zhiyig Si ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
On 06/11/2012 03:02 AM, Michel Dänzer wrote: On Son, 2012-06-10 at 11:56 +, Joakim Plate wrote: Hi, I'm currently trying to make use of OML_sync_control extension to schedule presentation of video frames in xbmc. I've run into somewhat of a snag. It seem the spec doesn't specify what time the UST clock really is, nor can i find any mention of it elsewhere in docs. Code wise it seem to be using do_gettimeofday(), which seems like a rather poor choice given that it can jump forward and back in time due to settimeofday calls. We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display of video frames, so to avoid major changes I'd need a way to convert to gettimeofday (seem same as CLOCK_REALTIME). Currently i'm trying: struct timespec mon, rel; clock_gettime(CLOCK_MONOTONIC,&mon); clock_gettime(CLOCK_REALTIME ,&rel); ticks += (rel.tv_sec - mon.tv_sec) * 10; ticks += (rel.tv_nsec - mon.tv_nsec); To convert between the two, but that is quite a hack both in the possibility of clock changes and scheduling errors. Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC in the first place? From the GLX_OML_sync_control spec: The Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter [...] So, without having thought a lot about potential ramifications, I'm inclined to say that CLOCK_MONOTONIC should indeed be used. Maybe. Isn't CLOCK_MONOTONIC per-process? UST is supposed to be relatively consistent across the system. Some relevant was elided above: "The Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system. UST is not a resource that is controlled by OpenGL, so it is not defined further as part of this extension." do_gettimeofday is definitely the wrong choice, but it was the best thing that I knew to use back in 2002(ish) when I wrote that code. I'm just not sure CLOCK_MONOTONIC is quite right either. What's behind door #3? :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.
Also remove the suspend function since all it does is log.
Signed-off-by: Mark Brown
Acked-by: Francisco Jerez
---
This patch has been sitting around for quite a while now, it's going to
end up blocking improvements in the I2C subsystem at some point.
drivers/gpu/drm/i2c/ch7006_drv.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..74ad254 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
}
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
{
- ch7006_dbg(client, "\n");
-
- return 0;
-}
+ struct i2c_client *client = to_i2c_device(dev);
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, "\n");
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, ch7006_ids);
+static const struct dev_pm_ops ch7006_pm_ops = {
+ .resume = ch7006_resume,
+};
+
static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
- .suspend = ch7006_suspend,
- .resume = ch7006_resume,
.driver = {
.name = "ch7006",
+ .pm = &ch7006_pm_ops,
},
.id_table = ch7006_ids,
--
1.7.10
[PULL] first drm-intel-next for 3.6
Hooray for yet again screwing up the recipient list! /me sucks -Daniel - Forwarded message from Daniel Vetter - Date: Tue, 12 Jun 2012 10:37:51 +0200 From: Daniel Vetter To: Intel Graphics Development , "Sun, Yi" Subject: Re: Updated -next Message-ID: <20120612083751.GA5188 at phenom.ffwll.local> Hi Dave, rc2 is out the door so I've figured I'll annoy you with the first -next pull request for 3.6 already. Highlights: - new wait_rendring_timeout interface (Ben) - l3 cache remapping and error uevent support (Ben) - even more infoframes work from Paulo - gen4 hotplug rework from Chris - prep work to make Laurent Pincharts original mode constification for connector->mode_fixup possible QA reported a few new bugs this time around, but no regressions afact. For 3.5 the only thing I'm aware of is the edp vdd dmesg spam Linus originally reported - it looks like that might have been introduced in 3.5. But somehow my brain is routinely offline when I work on that issue, so things seem to take forever (and atm I'm at patch v4 for that little problem). Yours, Daniel The following changes since commit 63bc620b45af8c743ac291c8725933278c712692: radeon: add radeon prime vmap support. (2012-05-31 14:14:01 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-06-04 for you to fetch changes up to 1523c310b3ed964b71a8db16f70c3bc21cc0642e: drm/i915: add min freq control to debugfs (2012-06-04 21:34:47 +0200) Ben Widawsky (8): drm/i915: timeout parameter for seqno wait drm/i915: improve i915_wait_request_begin trace drm/i915: wait render timeout ioctl drm/i915: s/i915_wait_request/i915_wait_seqno/g drm/i915: Dynamic Parity Detection handling drm/i915: enable parity error interrupts drm/i915: remap l3 on hw init drm/i915: l3 parity sysfs interface Chris Wilson (6): drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x drm/i915/hdmi: Query the live connector status bit for G4x drm/i915/dp: For consistency use the DP hotplug synonyms drm/i915/hdmi: Fix reg values for g4x_hdmi_connected Daniel Vetter (14): drm/i915: clarify preferred sdvo input mode code drm/i915: don't silently ignore sdvo mode_set failures drm/i915: there's no cxsr on ilk drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set drm/i915: s/mdelay/msleep/ in the sdvo detect function drm/i915: ivybridge_handle_parity_error should be static drm/i915: initialize the parity work only once drm/i915: simplify sysfs setup code Merge remote-tracking branch 'airlied/drm-prime-vmap' into drm-intel-next-queued drm/i915: clarify IBX dp workaround drm/i915: extract object active state flushing code drm/i915: compute the target_clock for edp directly drm/i915: adjusted_mode->clock in the dp mode_fixup drm/i915: don't chnage the original mode in dp_mode_fixup Jesse Barnes (1): drm/i915: add min freq control to debugfs Paulo Zanoni (11): drm/i915: add set_infoframes to struct intel_hdmi drm/i915: properly alternate between DVI and HDMI drm/i915: only set the HDMI port on the DIP once drm/i915: enable DIP before enabling each InfoFrame drm/i915: don't wait for vblank while writing InfoFrames drm/i915: explicitly disable the DIPs we're not using drm/i915: disable DIP while changing the port drm/i915: don't write 0 to DIP control at HDMI init drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI drm/i915: remove comment about HSW HDMI DIPs drm/i915: add some barriers when changing DIPs drivers/gpu/drm/i915/i915_debugfs.c | 66 +++ drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_gem.c | 242 +++ drivers/gpu/drm/i915/i915_irq.c | 171 - drivers/gpu/drm/i915/i915_reg.h | 56 +- drivers/gpu/drm/i915/i915_sysfs.c | 127 +++- drivers/gpu/drm/i915/i915_trace.h | 28 ++- drivers/gpu/drm/i915/intel_ddi.c|3 +- drivers/gpu/drm/i915/intel_display.c| 47 ++--- drivers/gpu/drm/i915/intel_dp.c | 53 +++--- drivers/gpu/drm/i915/intel_drv.h|9 +- drivers/gpu/drm/i915/intel_hdmi.c | 318 +-- drivers/gpu/drm/i915/intel_overlay.c|4 +- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +- drivers/gpu/drm/i915/intel_sdvo.c | 56 -- include/drm/i915_drm.h | 10 + 18 files changed, 965 inser
[Bug 50996] New: gnome-shell, video playing fail to work properly
https://bugs.freedesktop.org/show_bug.cgi?id=50996 Bug #: 50996 Summary: gnome-shell, video playing fail to work properly Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Unichrome AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: mxondebian at free.fr CC: kibi at debian.org Created attachment 62920 --> https://bugs.freedesktop.org/attachment.cgi?id=62920 Xorg log Gnome-shell 3.4 from (Debian/wheezy) fails to start (failling back to Gnome classic). Playing video fails to, with vlc colors get corrupted (red is displayed blue or kind of). The graphic card: "VGA compatible controller: VIA Technologies, Inc. KM400/KN400/P4M800 [S3 UniChrome]" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
No screens after (WW) Falling back to old probe method for modesetting
- Original Message - > From: "Rafa? Mi?ecki" > To: xorg-devel at lists.x.org, "dri-devel" lists.freedesktop.org>, "Dave Airlie" > Cc: "Alex Deucher" > Sent: Monday, 11 June, 2012 8:55:56 PM > Subject: Re: No screens after (WW) Falling back to old probe method for > modesetting > > 2012/6/11 Rafa? Mi?ecki : > > I'm trying to switch from fbdev to modesetting for my AMD Southern > > Islands VERDE card. Of course I've KMS running just fine, radeon > > module loads and sets correct resolution, dmesg looks alright > > > > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU > > the driver doesn't provide any screens/modes. It looks like this: > > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > > (WW) Falling back to old probe method for modesetting > > (II) UnloadModule: "modesetting" > > (II) Unloading modesetting > > (EE) Screen(s) found, but none have a usable configuration. > > > > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm > > using xf86-video-modesetting from today's git. Any patch/trick to > > debug this issue? > > Attaching Xorg.0.logs Try adding a BusID maybe, though I'm not sure how tested modesetting is with that old an X server. Dave.
[Bug 50999] New: [r300g, bisected] piglit glsl-fs-discard-04 fails
https://bugs.freedesktop.org/show_bug.cgi?id=50999
Bug #: 50999
Summary: [r300g, bisected] piglit glsl-fs-discard-04 fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Keywords: regression
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pavel.ondracka at email.cz
CC: eric at anholt.net, tstellar at gmail.com
Created attachment 62924
--> https://bugs.freedesktop.org/attachment.cgi?id=62924
RADEON_DEBUG=fp log
./bin/shader_runner tests/shaders/glsl-fs-discard-04.shader_test -auto -fbo
Probe at (0,0)
Expected: 0.00 1.00 0.00 0.00
Observed: 1.00 0.00 0.00 0.00
PIGLIT: {'result': 'fail' }
Regression test shows:
e21b9f1f19d2345026a7fbe095a776d0b64557ec is the first bad commit
commit e21b9f1f19d2345026a7fbe095a776d0b64557ec
Author: Eric Anholt
Date: Fri May 4 13:37:08 2012 -0700
glsl: Remove the opt_discard_simplification pass.
This conflicts with the GLSL 1.30+ rules for derivatives after a
discard has occurred.
Reviewed-by: Kenneth Graunke
llvmpipe works fine, so this may be another uncovered r300 compiler issue.
GPU:RV530
Kernel: 3.4.0-1.fc17.i686
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
No screens after (WW) Falling back to old probe method for modesetting
2012/6/12 David Airlie : > - Original Message - >> From: "Rafa? Mi?ecki" >> To: xorg-devel at lists.x.org, "dri-devel" > lists.freedesktop.org>, "Dave Airlie" >> Cc: "Alex Deucher" >> Sent: Monday, 11 June, 2012 8:55:56 PM >> Subject: Re: No screens after (WW) Falling back to old probe method for >> modesetting >> >> 2012/6/11 Rafa? Mi?ecki : >> > I'm trying to switch from fbdev to modesetting for my AMD Southern >> > Islands VERDE card. Of course I've KMS running just fine, radeon >> > module loads and sets correct resolution, dmesg looks alright >> > >> > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU >> > the driver doesn't provide any screens/modes. It looks like this: >> > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so >> > (WW) Falling back to old probe method for modesetting >> > (II) UnloadModule: "modesetting" >> > (II) Unloading modesetting >> > (EE) Screen(s) found, but none have a usable configuration. >> > >> > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm >> > using xf86-video-modesetting from today's git. Any patch/trick to >> > debug this issue? >> >> Attaching Xorg.0.logs > > Try adding a BusID maybe, though I'm not sure how tested modesetting is with > that old an X server. I already have it added. It's weird modesetting doesn't put any message in Xorg.0.log, it has few messages printing in source. Will put some debugging in modesetting to see what actually happens. -- Rafa?
[Bug 50996] gnome-shell, video playing fail to work properly
https://bugs.freedesktop.org/show_bug.cgi?id=50996 kaliko changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Component|Drivers/DRI/Unichrome |Other -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 51000] New: [r300g, bisected] piglit fbo-generatemipmap-formats fails
https://bugs.freedesktop.org/show_bug.cgi?id=51000
Bug #: 51000
Summary: [r300g, bisected] piglit fbo-generatemipmap-formats
fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Keywords: regression
Severity: normal
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: pavel.ondracka at email.cz
CC: kenneth at whitecape.org
./bin/fbo-generatemipmap-formats -auto GL_EXT_texture_compression_rgtc
Using test set: GL_EXT_texture_compression_rgtc
Testing GL_COMPRESSED_RED
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RED_RGTC1_EXT
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RG
Testing GL_COMPRESSED_RED_GREEN_RGTC2_EXT
Testing GL_COMPRESSED_RED (NPOT)
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RED_RGTC1_EXT (NPOT)
Probe at (1,1)
Expected: 1.00 0.00 0.00 1.00
Observed: 0.988235 0.00 0.00 1.00
Testing GL_COMPRESSED_RG (NPOT)
Testing GL_COMPRESSED_RED_GREEN_RGTC2_EXT (NPOT)
PIGLIT: {'result': 'fail' }
f8d40deea5c4abbbf93c2c572ce668a5a25f95e2 is the first bad commit
commit f8d40deea5c4abbbf93c2c572ce668a5a25f95e2
Author: Kenneth Graunke
Date: Tue Jun 5 23:51:04 2012 -0700
mesa: Return 8 bits for GL_TEXTURE_RED_SIZE on RGTC formats.
From the issues section of the GL_ARB_texture_compression_rgtc extension:
15) What should glGetTexLevelParameter return for
GL_TEXTURE_GREEN_SIZE and GL_TEXTURE_BLUE_SIZE for the RGTC1
formats? What should glGetTexLevelParameter return for
GL_TEXTURE_BLUE_SIZE for the RGTC2 formats?
RESOLVED: Zero bits.
These formats always return 0.0 for these respective components
and have no bits devoted to these components.
Returning 8 bits for red size of RGTC1 and the red and green
sizes of RGTC2 makes sense because that's the maximum potential
precision for the uncompressed texels.
Thus, we need to return 8 bits for GL_TEXTURE_RED_SIZE on all RGTC formats
and 8 bits for GL_TEXTURE_GREEN_SIZE on RGTC2 formats. BLUE should be 0.
Fixes oglconform/rgtc/advanced.texture_fetch.tex_param.
Signed-off-by: Kenneth Graunke
Reviewed-by: Brian Paul
BTW llvmpipe works fine.
GPU:RV530
Kernel: 3.4.0-1.fc17.i686
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 13720] [2.6.30] Modesetting on Mobility Radeon X700 displays black screen
https://bugzilla.kernel.org/show_bug.cgi?id=13720 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 13720] [2.6.30] Modesetting on Mobility Radeon X700 displays black screen
https://bugzilla.kernel.org/show_bug.cgi?id=13720 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression
A regression was introduced in the 3.3 rc series, commit
"drm/ttm: simplify memory accounting for ttm user v2",
causing the metadata of buffer objects created using the ttm_bo_create()
function to be accounted twice.
That causes massive leaks with the vmwgfx driver running for example
SpecViewperf Catia-03 test 2, eventually killing the app.
Furthermore, the same commit introduces a regression where
metadata accounting is leaked if a buffer object is
initialized with an illegal size. This is also fixed with this commit.
Signed-off-by: Thomas Hellstrom
Cc: Jerome Glisse
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b67cfca..4baea2f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
(*destroy)(bo);
else
kfree(bo);
+ ttm_mem_global_free(mem_glob, acc_size);
return -EINVAL;
}
bo->destroy = destroy;
@@ -1312,10 +1313,6 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
int ret;
acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
- ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
- if (unlikely(ret != 0))
- return ret;
-
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
if (unlikely(bo == NULL)) {
--
1.7.7.5
[PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression v2
A regression was introduced in the 3.3 rc series, commit
"drm/ttm: simplify memory accounting for ttm user v2",
causing the metadata of buffer objects created using the ttm_bo_create()
function to be accounted twice.
That causes massive leaks with the vmwgfx driver running for example
SpecViewperf Catia-03 test 2, eventually killing the app.
Furthermore, the same commit introduces a regression where
metadata accounting is leaked if a buffer object is
initialized with an illegal size. This is also fixed with this commit.
v2: Fixed an error path and removed an unused variable.
Signed-off-by: Thomas Hellstrom
Cc: Jerome Glisse
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b67cfca..36f4b28 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
(*destroy)(bo);
else
kfree(bo);
+ ttm_mem_global_free(mem_glob, acc_size);
return -EINVAL;
}
bo->destroy = destroy;
@@ -1307,22 +1308,14 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
struct ttm_buffer_object **p_bo)
{
struct ttm_buffer_object *bo;
- struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
size_t acc_size;
int ret;
- acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
- ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
- if (unlikely(ret != 0))
- return ret;
-
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
-
- if (unlikely(bo == NULL)) {
- ttm_mem_global_free(mem_glob, acc_size);
+ if (unlikely(bo == NULL))
return -ENOMEM;
- }
+ acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
buffer_start, interruptible,
persistent_swap_storage, acc_size, NULL, NULL);
--
1.7.7.5
[Intel-gfx] [PATCH 07/12] drm/i915: only enable drm agp support when required
On Thu, 07 Jun 2012, Daniel Vetter wrote:
> We need it for all things ums (which essentially only means up to
> gen5) and to support b0rked XvMC userspace on gen3.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 21 -
> 1 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index e4203df..0ab5d3d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> int ret = 0, mmio_bar;
> uint32_t aperture_size;
>
> - ret = drm_pci_agp_init(dev);
> - if (ret)
> - return ret;
> -
> - if (!dev->agp) {
> - DRM_ERROR("Cannot initialize the agpgart module.\n");
> - return -EINVAL;
> - }
> -
> info = (struct intel_device_info *) flags;
>
> /* Refuse to load on gen6+ without kms enabled. */
> @@ -1453,6 +1444,18 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> dev_priv->dev = dev;
> dev_priv->info = info;
>
> + if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> + IS_GEN3(dev)) {
> + ret = drm_pci_agp_init(dev);
> + if (ret)
> + return ret;
> +
> + if (!dev->agp) {
> + DRM_ERROR("Cannot initialize the agpgart module.\n");
> + return -EINVAL;
> + }
You need to goto free_priv in the above error paths.
Should there be a deinit of drm_pci_agp_init() if something goes wrong
afterwards?
BR,
Jani.
> + }
> +
> if (i915_get_bridge_dev(dev)) {
> ret = -EIO;
> goto free_priv;
> --
> 1.7.7.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] drm/i915: only enable drm agp support when required
On Tue, Jun 12, 2012 at 02:58:25PM +0300, Jani Nikula wrote:
> On Thu, 07 Jun 2012, Daniel Vetter wrote:
> > We need it for all things ums (which essentially only means up to
> > gen5) and to support b0rked XvMC userspace on gen3.
> >
> > Signed-Off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 21 -
> > 1 files changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index e4203df..0ab5d3d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > int ret = 0, mmio_bar;
> > uint32_t aperture_size;
> >
> > - ret = drm_pci_agp_init(dev);
> > - if (ret)
> > - return ret;
> > -
> > - if (!dev->agp) {
> > - DRM_ERROR("Cannot initialize the agpgart module.\n");
> > - return -EINVAL;
> > - }
> > -
> > info = (struct intel_device_info *) flags;
> >
> > /* Refuse to load on gen6+ without kms enabled. */
> > @@ -1453,6 +1444,18 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > dev_priv->dev = dev;
> > dev_priv->info = info;
> >
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> > + IS_GEN3(dev)) {
> > + ret = drm_pci_agp_init(dev);
> > + if (ret)
> > + return ret;
> > +
> > + if (!dev->agp) {
> > + DRM_ERROR("Cannot initialize the agpgart module.\n");
> > + return -EINVAL;
> > + }
>
> You need to goto free_priv in the above error paths.
Nice catch, will fix.
> Should there be a deinit of drm_pci_agp_init() if something goes wrong
> afterwards?
drm core should do that for use (but currently doesn't) by deinit agp if
it's initialized. The follow-up patches to wrestle the drm driver init
paths /should/ take care of this though.
-Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[PATCH] drm/i915: only enable drm agp support when required
We need it for all things ums (which essentially only means up to
gen5) and to support b0rked XvMC userspace on gen3.
v2: Fixup error paths as noticed by Jani Nikula.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e4203df..1f6a36a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
int ret = 0, mmio_bar;
uint32_t aperture_size;
- ret = drm_pci_agp_init(dev);
- if (ret)
- return ret;
-
- if (!dev->agp) {
- DRM_ERROR("Cannot initialize the agpgart module.\n");
- return -EINVAL;
- }
-
info = (struct intel_device_info *) flags;
/* Refuse to load on gen6+ without kms enabled. */
@@ -1453,6 +1444,19 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
dev_priv->dev = dev;
dev_priv->info = info;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
+ IS_GEN3(dev)) {
+ ret = drm_pci_agp_init(dev);
+ if (ret)
+ goto free_priv;
+
+ if (!dev->agp) {
+ DRM_ERROR("Cannot initialize the agpgart module.\n");
+ ret = -EINVAL;
+ goto free_priv;
+ }
+ }
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
--
1.7.7.6
[PATCH] drm/i915: don't check intel_agp_enabled any more
We won't enabled agp unconditionally. Furthermore we do have
the right checks for agp support in place in our ->load
function.
The only thing this variable still does is enforce the module
load order we want (and I'm not even sure whether it succeeds
for that). Hence just use it in a harmless place somewhere.
v2: Fixup rebase.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |6 +-
drivers/gpu/drm/i915/i915_drv.c |6 --
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a8f8477..6290aea 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1404,6 +1404,8 @@ i915_mtrr_setup(struct drm_i915_private *dev_priv,
unsigned long base,
}
}
+extern int intel_agp_enabled;
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -1451,7 +1453,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto free_priv;
if (!dev->agp) {
- DRM_ERROR("Cannot initialize the agpgart module.\n");
+ DRM_ERROR("Cannot initialize the agpgart module,"
+ "intel_agp_enabled: %i.\n",
+ intel_agp_enabled);
ret = -EINVAL;
goto free_priv;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3390213..e4df5a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -119,7 +119,6 @@ MODULE_PARM_DESC(i915_enable_ppgtt,
"Enable PPGTT (default: true)");
static struct drm_driver driver;
-extern int intel_agp_enabled;
#define INTEL_VGA_DEVICE(id, info) { \
.class = PCI_BASE_CLASS_DISPLAY << 16, \
@@ -1093,11 +1092,6 @@ static struct pci_driver i915_pci_driver = {
static int __init i915_init(void)
{
- if (!intel_agp_enabled) {
- DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
- return -ENODEV;
- }
-
driver.num_ioctls = i915_max_ioctl;
/*
--
1.7.7.6
[PATCH 2/2] drm: fixup error path after drm_fill_in_dev
On Fri, 08 Jun 2012, Daniel Vetter wrote:
> Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
> case of failures. But the callers of drm_fill_in_dev simply don't do
> anything. Now from a cursory look drm_lastclose doesn't look like the
> best cleanup function in itself, but whom am I to judge the drm error
> paths. Imo before we could tackle this we need to move more of the
> legacy drm services setup and teardown into the respective drivers,
> that way drm_lastclose would become more manageble.
>
> Anyway, make things at least consistent by adding drm_lastclose at the
> right places in the error paths for all callers of drm_fill_in_dev.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_pci.c |8 +---
> drivers/gpu/drm/drm_platform.c |8 +---
> drivers/gpu/drm/drm_usb.c |8 +---
> 3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 73218ac..40737a8 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -334,14 +334,14 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
> pci_device_id *ent,
>
> if ((ret = drm_fill_in_dev(dev, ent, driver))) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g2;
> + goto err_pci;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> pci_set_drvdata(pdev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g2;
> + goto err_drm_fill_in;
> }
>
> if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
> @@ -375,7 +375,9 @@ err_g4:
> err_g3:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g2:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_pci:
> pci_disable_device(pdev);
> err_g1:
> kfree(dev);
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index 82431dc..177893a 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -60,14 +60,14 @@ int drm_get_platform_dev(struct platform_device *platdev,
>
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_kfree;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> dev_set_drvdata(&platdev->dev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_drm_fill_in;
> }
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> @@ -103,7 +103,9 @@ err_g3:
> err_g2:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
> index 37c9a52..2e179f1 100644
> --- a/drivers/gpu/drm/drm_usb.c
> +++ b/drivers/gpu/drm/drm_usb.c
> @@ -25,13 +25,13 @@ int drm_get_usb_dev(struct usb_interface *interface,
> ret = drm_fill_in_dev(dev, NULL, driver);
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_drm_fill_in;
> }
>
> usb_set_intfdata(interface, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_kfree;
The above gotos err_drm_fill_in/err_kfree should switch places.
BR,
Jani.
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> if (ret)
> @@ -63,7 +63,9 @@ err_g3:
> drm_put_minor(&dev->primary);
> err_g2:
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> --
> 1.7.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fixup error path after drm_fill_in_dev
Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
case of failures. But the callers of drm_fill_in_dev simply don't do
anything. Now from a cursory look drm_lastclose doesn't look like the
best cleanup function in itself, but whom am I to judge the drm error
paths. Imo before we could tackle this we need to move more of the
legacy drm services setup and teardown into the respective drivers,
that way drm_lastclose would become more manageble.
Anyway, make things at least consistent by adding drm_lastclose at the
right places in the error paths for all callers of drm_fill_in_dev.
v2: Fixup the error-path confusion in drm_usb.c, noticed by Jani
Nikula.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c |8 +---
drivers/gpu/drm/drm_platform.c |8 +---
drivers/gpu/drm/drm_usb.c |8 +---
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 73218ac..40737a8 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -334,14 +334,14 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
if ((ret = drm_fill_in_dev(dev, ent, driver))) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g2;
+ goto err_pci;
}
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
pci_set_drvdata(pdev, dev);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
- goto err_g2;
+ goto err_drm_fill_in;
}
if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
@@ -375,7 +375,9 @@ err_g4:
err_g3:
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(&dev->control);
-err_g2:
+err_drm_fill_in:
+ drm_lastclose(dev);
+err_pci:
pci_disable_device(pdev);
err_g1:
kfree(dev);
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 82431dc..177893a 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -60,14 +60,14 @@ int drm_get_platform_dev(struct platform_device *platdev,
if (ret) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g1;
+ goto err_kfree;
}
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
dev_set_drvdata(&platdev->dev, dev);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
- goto err_g1;
+ goto err_drm_fill_in;
}
ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
@@ -103,7 +103,9 @@ err_g3:
err_g2:
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_put_minor(&dev->control);
-err_g1:
+err_drm_fill_in:
+ drm_lastclose(dev);
+err_kfree:
kfree(dev);
mutex_unlock(&drm_global_mutex);
return ret;
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index 37c9a52..f9d645f 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -25,13 +25,13 @@ int drm_get_usb_dev(struct usb_interface *interface,
ret = drm_fill_in_dev(dev, NULL, driver);
if (ret) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
- goto err_g1;
+ goto err_kfree;
}
usb_set_intfdata(interface, dev);
ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
if (ret)
- goto err_g1;
+ goto err_drm_fill_in;
ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
if (ret)
@@ -63,7 +63,9 @@ err_g3:
drm_put_minor(&dev->primary);
err_g2:
drm_put_minor(&dev->control);
-err_g1:
+err_drm_fill_in:
+ drm_lastclose(dev);
+err_kfree:
kfree(dev);
mutex_unlock(&drm_global_mutex);
return ret;
--
1.7.7.6
[PATCH 00/12] clear up drm/agp initialization madness
On Thu, 07 Jun 2012, Daniel Vetter wrote: > Comments, flames and reviews highly welcome. If possible I'd like to get the 3 > drm patches at the beginning in early for 3.6 so that we can decently test it > (and have some time to pile more stuff on top of this in drm/i915 land). On the series and the fixes to it, with the disclaimer that I don't have much experience with drm/i915/gtt yet: Reviewed-by: Jani Nikula
[PATCH] drm: fixup error path after drm_fill_in_dev
On Tue, 12 Jun 2012, Daniel Vetter wrote:
> Within drm_fill_in_dev we call drm_lastclose to clean up the dirt in
> case of failures. But the callers of drm_fill_in_dev simply don't do
> anything. Now from a cursory look drm_lastclose doesn't look like the
> best cleanup function in itself, but whom am I to judge the drm error
> paths. Imo before we could tackle this we need to move more of the
> legacy drm services setup and teardown into the respective drivers,
> that way drm_lastclose would become more manageble.
>
> Anyway, make things at least consistent by adding drm_lastclose at the
> right places in the error paths for all callers of drm_fill_in_dev.
>
> v2: Fixup the error-path confusion in drm_usb.c, noticed by Jani
> Nikula.
You could just claim you planted it there for me. ;)
On the series,
Reviewed-by: Jani Nikula
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_pci.c |8 +---
> drivers/gpu/drm/drm_platform.c |8 +---
> drivers/gpu/drm/drm_usb.c |8 +---
> 3 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 73218ac..40737a8 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -334,14 +334,14 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
> pci_device_id *ent,
>
> if ((ret = drm_fill_in_dev(dev, ent, driver))) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g2;
> + goto err_pci;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> pci_set_drvdata(pdev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g2;
> + goto err_drm_fill_in;
> }
>
> if ((ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY)))
> @@ -375,7 +375,9 @@ err_g4:
> err_g3:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g2:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_pci:
> pci_disable_device(pdev);
> err_g1:
> kfree(dev);
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index 82431dc..177893a 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -60,14 +60,14 @@ int drm_get_platform_dev(struct platform_device *platdev,
>
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_kfree;
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> dev_set_drvdata(&platdev->dev, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_drm_fill_in;
> }
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> @@ -103,7 +103,9 @@ err_g3:
> err_g2:
> if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
> index 37c9a52..f9d645f 100644
> --- a/drivers/gpu/drm/drm_usb.c
> +++ b/drivers/gpu/drm/drm_usb.c
> @@ -25,13 +25,13 @@ int drm_get_usb_dev(struct usb_interface *interface,
> ret = drm_fill_in_dev(dev, NULL, driver);
> if (ret) {
> printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
> - goto err_g1;
> + goto err_kfree;
> }
>
> usb_set_intfdata(interface, dev);
> ret = drm_get_minor(dev, &dev->control, DRM_MINOR_CONTROL);
> if (ret)
> - goto err_g1;
> + goto err_drm_fill_in;
>
> ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
> if (ret)
> @@ -63,7 +63,9 @@ err_g3:
> drm_put_minor(&dev->primary);
> err_g2:
> drm_put_minor(&dev->control);
> -err_g1:
> +err_drm_fill_in:
> + drm_lastclose(dev);
> +err_kfree:
> kfree(dev);
> mutex_unlock(&drm_global_mutex);
> return ret;
> --
> 1.7.7.6
[PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression v2
On Tue, Jun 12, 2012 at 01:28:42PM +0200, Thomas Hellstrom wrote:
> A regression was introduced in the 3.3 rc series, commit
> "drm/ttm: simplify memory accounting for ttm user v2",
> causing the metadata of buffer objects created using the ttm_bo_create()
> function to be accounted twice.
> That causes massive leaks with the vmwgfx driver running for example
> SpecViewperf Catia-03 test 2, eventually killing the app.
>
> Furthermore, the same commit introduces a regression where
> metadata accounting is leaked if a buffer object is
> initialized with an illegal size. This is also fixed with this commit.
>
> v2: Fixed an error path and removed an unused variable.
>
> Signed-off-by: Thomas Hellstrom
> Cc: Jerome Glisse
> Cc: stable at vger.kernel.org
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 13 +++--
> 1 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index b67cfca..36f4b28 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> (*destroy)(bo);
> else
> kfree(bo);
> + ttm_mem_global_free(mem_glob, acc_size);
> return -EINVAL;
> }
> bo->destroy = destroy;
> @@ -1307,22 +1308,14 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
> struct ttm_buffer_object **p_bo)
> {
> struct ttm_buffer_object *bo;
> - struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
> size_t acc_size;
> int ret;
>
> - acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
> ttm_buffer_object));
> - ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
> - if (unlikely(ret != 0))
> - return ret;
> -
> bo = kzalloc(sizeof(*bo), GFP_KERNEL);
> -
> - if (unlikely(bo == NULL)) {
> - ttm_mem_global_free(mem_glob, acc_size);
> + if (unlikely(bo == NULL))
> return -ENOMEM;
> - }
>
> + acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
> ttm_buffer_object));
> ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
> buffer_start, interruptible,
> persistent_swap_storage, acc_size, NULL, NULL);
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43367] New: radeon: NULL pointer dereference on switching to dynpm power method
https://bugzilla.kernel.org/show_bug.cgi?id=43367 Summary: radeon: NULL pointer dereference on switching to dynpm power method Product: Drivers Version: 2.5 Kernel Version: 3.5-rc2 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: haagch.christoph at googlemail.com Regression: Yes Created an attachment (id=73570) --> (https://bugzilla.kernel.org/attachment.cgi?id=73570) console log of the bug After changing to dynpm with # echo dynpm > /sys/class/drm/card0/device/power_method I immediately get the attached kernel Oops. Power profiles work fine. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm: increase DRM_OBJECT_MAX_PROPERTY to 24
From: Paulo Zanoni
Before Kernel 3.5, no one was checking for the return value of
drm_connector_attach_property, so we never noticed that we were unable
to create some properties. Commit "drm: WARN() when
drm_connector_attach_property fails" added a WARN when we fail to
create a property, and the transition from "connector properties" to
"object properties" changed the warning message a little bit.
On i915 machines with many TV connectors we hit the maximum number of
properties (since each TV connector uses a lot of properties), so we
get a few backtraces in our logs. This commit increases the maximum
number of properties to 24 hoping we'll have enough room for
everybody.
Chris suggested that we convert this code to "lists", but I believe
this conversion can come after we make sure people's dmesgs are not
spammed by our driver.
Signed-off-by: Paulo Zanoni
Reported-by: Dave Jones
Tested-by: Daniel Vetter
---
include/drm/drm_crtc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73e4560..bac55c2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -54,7 +54,7 @@ struct drm_mode_object {
struct drm_object_properties *properties;
};
-#define DRM_OBJECT_MAX_PROPERTY 16
+#define DRM_OBJECT_MAX_PROPERTY 24
struct drm_object_properties {
int count;
uint32_t ids[DRM_OBJECT_MAX_PROPERTY];
--
1.7.10
No screens after (WW) Falling back to old probe method for modesetting
2012/6/11 Rafa? Mi?ecki : > I'm trying to switch from fbdev to modesetting for my AMD Southern > Islands VERDE card. Of course I've KMS running just fine, radeon > module loads and sets correct resolution, dmesg looks alright > > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU > the driver doesn't provide any screens/modes. It looks like this: > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > (WW) Falling back to old probe method for modesetting > (II) UnloadModule: "modesetting" > (II) Unloading modesetting > (EE) Screen(s) found, but none have a usable configuration. > > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm > using xf86-video-modesetting from today's git. Any patch/trick to > debug this issue? I don't think old X server is an issue here. The function to focus on is probe_hw_pci. This function calls "open_hw" which opens /dev/dri/card0 and return fd (9 in my case, irrelevant). Then comes the moment when probe_hw_pci calls: id = drmGetBusid(fd); devid = ms_DRICreatePCIBusID(pdev); The first one returns NULL, the second one returns "pci::03:00.0". As the "id" is NULL (empty string) probe_hw_pci returns false and the rest fails. I can't say why drmGetBusid returns NULL. My drm is from yesterday's git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK. Hacking probe_hw_pci to return TRUE allows me start X with modesetting. -- Rafa?
[Bug 51000] [r300g, bisected] piglit fbo-generatemipmap-formats fails
https://bugs.freedesktop.org/show_bug.cgi?id=51000 Kenneth Graunke changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |eric at anholt.net |.org| QAContact||eric at anholt.net Product|Mesa|piglit Version|git |unspecified Component|Drivers/Gallium/r300|tests --- Comment #1 from Kenneth Graunke 2012-06-12 08:09:02 PDT --- Hmm. That patch shouldn't have changed the result at all---and it does look fairly close---so I think your hardware just has somewhat lower precision than mine. The Piglit test uses GL_RED_SIZE etc. to determine the tolerances/precision expected, so with the increase from 4 to 8, the test became more stringent. Normally this would make sense, but since GL_RED_SIZE and friends are /approximate/ precision for a compressed format---and in this case, the /maximum/ precision---I think we may need to lower the test's tolerances. Changing this to a Piglit bug. -- 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/prime: reserve/unreserve around pin
From: Dave Airlie
I finally got to test this code a bit more and hit the ttm
no reserved assert, so add the reservations around the pinning.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_prime.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index 8ddab4c7..6bef46a 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -169,11 +169,17 @@ struct dma_buf *radeon_gem_prime_export(struct drm_device
*dev,
struct radeon_bo *bo = gem_to_radeon_bo(obj);
int ret = 0;
+ ret = radeon_bo_reserve(bo, false);
+ if (unlikely(ret != 0))
+ return ERR_PTR(ret);
+
/* pin buffer into GTT */
ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
- if (ret)
+ if (ret) {
+ radeon_bo_unreserve(bo);
return ERR_PTR(ret);
-
+ }
+ radeon_bo_unreserve(bo);
return dma_buf_export(bo, &radeon_dmabuf_ops, obj->size, flags);
}
--
1.7.7.6
[PATCH] drm/radeon/prime: reserve/unreserve around pin
On Tue, Jun 12, 2012 at 11:10 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> I finally got to test this code a bit more and hit the ttm
> no reserved assert, so add the reservations around the pinning.
Good catch.
Reviewed-by: Alex Deucher
>
> Signed-off-by: Dave Airlie
> ---
> ?drivers/gpu/drm/radeon/radeon_prime.c | ? 10 --
> ?1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 8ddab4c7..6bef46a 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -169,11 +169,17 @@ struct dma_buf *radeon_gem_prime_export(struct
> drm_device *dev,
> ? ? ? ?struct radeon_bo *bo = gem_to_radeon_bo(obj);
> ? ? ? ?int ret = 0;
>
> + ? ? ? ret = radeon_bo_reserve(bo, false);
> + ? ? ? if (unlikely(ret != 0))
> + ? ? ? ? ? ? ? return ERR_PTR(ret);
> +
> ? ? ? ?/* pin buffer into GTT */
> ? ? ? ?ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> - ? ? ? if (ret)
> + ? ? ? if (ret) {
> + ? ? ? ? ? ? ? radeon_bo_unreserve(bo);
> ? ? ? ? ? ? ? ?return ERR_PTR(ret);
> -
> + ? ? ? }
> + ? ? ? radeon_bo_unreserve(bo);
> ? ? ? ?return dma_buf_export(bo, &radeon_dmabuf_ops, obj->size, flags);
> ?}
>
> --
> 1.7.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Linus as per your -rc2 announce, this is small and urgent only, The radeon one is for a regression in 3.4 so we need this one in your tree so we can send the stable one out, code in 3.4 broke some old userspaces. The max props increase fixes spew being seen on a few machines. and a ttm regression to fix some accounting issues that affect vmwgfx. Dave. The following changes since commit cfaf025112d3856637ff34a767ef785ef5cf2ca9: Linux 3.5-rc2 (2012-06-08 18:40:09 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to a393c730ab69617c3291a3b0b2a228c9be2fc28c: drm/ttm: Fix buffer object metadata accounting regression v2 (2012-06-12 15:57:47 +0100) Jerome Glisse (1): drm/radeon: fix tiling and command stream checking on evergreen v3 Paulo Zanoni (1): drm: increase DRM_OBJECT_MAX_PROPERTY to 24 Thomas Hellstrom (1): drm/ttm: Fix buffer object metadata accounting regression v2 drivers/gpu/drm/radeon/evergreen_cs.c | 49 ++--- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/ttm/ttm_bo.c | 13 ++--- include/drm/drm_crtc.h|2 +- 4 files changed, 51 insertions(+), 16 deletions(-)
No screens after (WW) Falling back to old probe method for modesetting
2012/6/12 Rafa? Mi?ecki : > 2012/6/11 Rafa? Mi?ecki : >> I'm trying to switch from fbdev to modesetting for my AMD Southern >> Islands VERDE card. Of course I've KMS running just fine, radeon >> module loads and sets correct resolution, dmesg looks alright >> >> Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU >> the driver doesn't provide any screens/modes. It looks like this: >> (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so >> (WW) Falling back to old probe method for modesetting >> (II) UnloadModule: "modesetting" >> (II) Unloading modesetting >> (EE) Screen(s) found, but none have a usable configuration. >> >> Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm >> using xf86-video-modesetting from today's git. Any patch/trick to >> debug this issue? > > I don't think old X server is an issue here. The function to focus on > is probe_hw_pci. > > This function calls "open_hw" which opens /dev/dri/card0 and return fd > (9 in my case, irrelevant). Then comes the moment when probe_hw_pci > calls: > id = drmGetBusid(fd); > devid = ms_DRICreatePCIBusID(pdev); > > The first one returns NULL, the second one returns "pci::03:00.0". > As the "id" is NULL (empty string) probe_hw_pci returns false and the > rest fails. > > I can't say why drmGetBusid returns NULL. My drm is from yesterday's > git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK. > Hacking probe_hw_pci to return TRUE allows me start X with > modesetting. I've hacked xf86drm.c::drmGetBusid to print some debugging messages. When we call "drmGetBusid" in "probe_hw_pci", u.unique_len gets 0 and u.unique gets "\0". However I've noticed there's one more call to "drmGetBusid". The stacktrace is: PreInit ? drmOpen(NULL, BusID) ? drmOpenByBusid ? drmGetBusid In the above call, drmGetBusid gets u.unique_len gets 16 and u.unique gets "pci::03:00.0\0". Does it give you any hint what can happen here? -- Rafa?
[PATCH -fixes] drm/ttm: Fix buffer object metadata accounting regression v2
On Tue, Jun 12, 2012 at 8:50 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jun 12, 2012 at 01:28:42PM +0200, Thomas Hellstrom wrote:
>> A regression was introduced in the 3.3 rc series, commit
>> "drm/ttm: simplify memory accounting for ttm user v2",
>> causing the metadata of buffer objects created using the ttm_bo_create()
>> function to be accounted twice.
>> That causes massive leaks with the vmwgfx driver running for example
>> SpecViewperf Catia-03 test 2, eventually killing the app.
>>
>> Furthermore, the same commit introduces a regression where
>> metadata accounting is leaked if a buffer object is
>> initialized with an illegal size. This is also fixed with this commit.
>>
>> v2: Fixed an error path and removed an unused variable.
>>
>> Signed-off-by: Thomas Hellstrom
>> Cc: Jerome Glisse
>> Cc: stable at vger.kernel.org
>
> Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Jerome Glisse
>> ---
>> ?drivers/gpu/drm/ttm/ttm_bo.c | ? 13 +++--
>> ?1 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index b67cfca..36f4b28 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1204,6 +1204,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
>> ? ? ? ? ? ? ? ? ? ? ? (*destroy)(bo);
>> ? ? ? ? ? ? ? else
>> ? ? ? ? ? ? ? ? ? ? ? kfree(bo);
>> + ? ? ? ? ? ? ttm_mem_global_free(mem_glob, acc_size);
>> ? ? ? ? ? ? ? return -EINVAL;
>> ? ? ? }
>> ? ? ? bo->destroy = destroy;
>> @@ -1307,22 +1308,14 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
>> ? ? ? ? ? ? ? ? ? ? ? struct ttm_buffer_object **p_bo)
>> ?{
>> ? ? ? struct ttm_buffer_object *bo;
>> - ? ? struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
>> ? ? ? size_t acc_size;
>> ? ? ? int ret;
>>
>> - ? ? acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
>> ttm_buffer_object));
>> - ? ? ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
>> - ? ? if (unlikely(ret != 0))
>> - ? ? ? ? ? ? return ret;
>> -
>> ? ? ? bo = kzalloc(sizeof(*bo), GFP_KERNEL);
>> -
>> - ? ? if (unlikely(bo == NULL)) {
>> - ? ? ? ? ? ? ttm_mem_global_free(mem_glob, acc_size);
>> + ? ? if (unlikely(bo == NULL))
>> ? ? ? ? ? ? ? return -ENOMEM;
>> - ? ? }
>>
>> + ? ? acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
>> ttm_buffer_object));
>> ? ? ? ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? buffer_start, interruptible,
>> ? ? ? ? ? ? ? ? ? ? ? ? persistent_swap_storage, acc_size, NULL, NULL);
>> --
>> 1.7.7.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47519] Xorg hangs in ioCtl in path of RADEONDownloadFromScreenCS
https://bugs.freedesktop.org/show_bug.cgi?id=47519 --- Comment #13 from Jeremy Huddleston 2012-06-12 09:15:31 PDT --- *** Bug 47512 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/prime: reserve/unreserve around pin
On Die, 2012-06-12 at 16:10 +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> I finally got to test this code a bit more and hit the ttm
> no reserved assert, so add the reservations around the pinning.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/radeon/radeon_prime.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 8ddab4c7..6bef46a 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -169,11 +169,17 @@ struct dma_buf *radeon_gem_prime_export(struct
> drm_device *dev,
> struct radeon_bo *bo = gem_to_radeon_bo(obj);
> int ret = 0;
>
> + ret = radeon_bo_reserve(bo, false);
> + if (unlikely(ret != 0))
> + return ERR_PTR(ret);
> +
> /* pin buffer into GTT */
> ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> - if (ret)
> + if (ret) {
> + radeon_bo_unreserve(bo);
> return ERR_PTR(ret);
> -
> + }
> + radeon_bo_unreserve(bo);
Could just add single radeon_bo_unreserve() call right after the
radeon_bo_pin() call, but either way
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
[Bug 47519] Xorg hangs in ioCtl in path of RADEONDownloadFromScreenCS
https://bugs.freedesktop.org/show_bug.cgi?id=47519 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Michel D?nzer 2012-06-12 09:43:52 PDT --- Current Linux kernels disable MSI by default on these cards. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 50980] [r300g, bisected] WebGL cars demo crash (r300_emit.c:865:r300_emit_vertex_arrays: Assertion `(buf)' failed)
https://bugs.freedesktop.org/show_bug.cgi?id=50980 --- Comment #1 from Pavel Ondra?ka 2012-06-12 12:26:19 PDT --- Created attachment 62942 --> https://bugs.freedesktop.org/attachment.cgi?id=62942 gl-max-texture-dimensions webgl test backtrace Another variation of this crash can be seen with conformance/limits/gl-max-texture-dimensions.html test from webgl conformance test suite. The backtrace is different, but regression test showed the same commit. -- 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/si: check for CE ucode as well when loading ucode
From: Alex Deucher Fixes possible segfault if the CE ucode is missing. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/si.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 9248a91..d500911 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -1825,7 +1825,7 @@ static int si_cp_load_microcode(struct radeon_device *rdev) const __be32 *fw_data; int i; - if (!rdev->me_fw || !rdev->pfp_fw) + if (!rdev->me_fw || !rdev->pfp_fw || !rdev->ce_fw) return -EINVAL; si_cp_enable(rdev, false); -- 1.7.7.5
[PATCH 00/12] clear up drm/agp initialization madness
On Tue, Jun 12, 2012 at 03:46:35PM +0300, Jani Nikula wrote: > On Thu, 07 Jun 2012, Daniel Vetter wrote: > > Comments, flames and reviews highly welcome. If possible I'd like to get > > the 3 > > drm patches at the beginning in early for 3.6 so that we can decently test > > it > > (and have some time to pile more stuff on top of this in drm/i915 land). > > On the series and the fixes to it, with the disclaimer that I don't have > much experience with drm/i915/gtt yet: > > Reviewed-by: Jani Nikula Ok, I've picked up all the prep patches that don't depend upon the drm core rework. Thanks for taking a lock at these patches. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
On 06/11/2012 03:02 AM, Michel D?nzer wrote: > On Son, 2012-06-10 at 11:56 +, Joakim Plate wrote: >> Hi, >> >> I'm currently trying to make use of OML_sync_control extension to schedule >> presentation of video frames in xbmc. >> >> I've run into somewhat of a snag. It seem the spec doesn't specify what >> time the UST clock really is, nor can i find any mention of it elsewhere >> in docs. >> >> Code wise it seem to be using do_gettimeofday(), which seems like a rather >> poor choice given that it can jump forward and back in time due to >> settimeofday calls. >> >> We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display >> of video frames, so to avoid major changes I'd need a way to convert to >> gettimeofday (seem same as CLOCK_REALTIME). >> >> Currently i'm trying: >>struct timespec mon, rel; >>clock_gettime(CLOCK_MONOTONIC,&mon); >>clock_gettime(CLOCK_REALTIME ,&rel); >> >>ticks += (rel.tv_sec - mon.tv_sec) * 10; >>ticks += (rel.tv_nsec - mon.tv_nsec); >> >> To convert between the two, but that is quite a hack both in the >> possibility of clock changes and scheduling errors. >> >> Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC >> in the first place? > > From the GLX_OML_sync_control spec: > > The Unadjusted System Time (or UST) is a 64-bit monotonically > increasing counter [...] > > So, without having thought a lot about potential ramifications, I'm > inclined to say that CLOCK_MONOTONIC should indeed be used. Maybe. Isn't CLOCK_MONOTONIC per-process? UST is supposed to be relatively consistent across the system. Some relevant was elided above: "The Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system. UST is not a resource that is controlled by OpenGL, so it is not defined further as part of this extension." do_gettimeofday is definitely the wrong choice, but it was the best thing that I knew to use back in 2002(ish) when I wrote that code. I'm just not sure CLOCK_MONOTONIC is quite right either. What's behind door #3? :)
[PATCH] drm/i915: ignore LVDS_PIPEB_SELECT when checking for LVDS register initialization
The Lenovo Thinkpad T410 has this bit set in the LVDS register when booted with the lid closed, even though the LVDS hasn't really been initialized. Ignore this bit so that the VBT value will be used instead. Signed-off-by: Seth Forshee --- drivers/gpu/drm/i915/intel_display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e0aa064..f81f249 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -434,7 +434,7 @@ static bool is_dual_link_lvds(struct drm_i915_private *dev_priv, * register is uninitialized. */ val = I915_READ(reg); - if (!(val & ~LVDS_DETECTED)) + if (!(val & ~(LVDS_PIPEB_SELECT | LVDS_DETECTED))) val = dev_priv->bios_lvds_val; dev_priv->lvds_val = val; }
