[PATCH] drm/radeon: make 64bit fences more robust
>>> >>> It might be related to a hardware bug, or the algorithm is flawed in a way I currently don't see. Anyway the old code we had wasn't so picky about such problems and the patch just tries to make the current code as robust as the old code was, which indeed seems to solve the problems we see. The wrap around detection still works (tested by setting the initial fence value to 0xfff0 and letting it wrap around shortly after start), so I think it we can safely commit this. Can we start fences off so we wrap around after say 15-20 minutes? that would ensure a) its tested b) we see failure in a lifetime. Dave.
[PATCH 3/5] nouveau: Add interface to detect optimus support
On Tue, Sep 11, 2012 at 2:25 AM, Lekensteyn wrote:
> Hi Dave,
>
>> +bool nouveau_is_optimus(void) {
>> + return nouveau_dsm_priv.optimus_detected;
>> +}
> This will only work for new Optimus laptops, not the older ones such as your
> Lenovo T410s or on a Dell Vostro 3500 with a GT 310M. Is that intended? If
> not, check for those models too:
>
Works fine on my T410s from what I can see, though yes I understand
the older ones probably won't work
I'm still not 100% sure how best to deal with the older ones.
Dave.
[PATCH] drm/edid: fix interlace mode name
On 09/10/2012 09:48 PM, Alex Deucher wrote: > On Mon, Sep 10, 2012 at 7:35 AM, Paul Menzel > wrote: >> Am Montag, den 10.09.2012, 19:23 +0900 schrieb Joonyoung Shim: >>> The some modes to support interlace have "i" character at the end of >> In `drm_mode_set_name()` from `drivers/gpu/drm/drm_modes.c` interlace >> modes have the character ?i? appended to their name. >> >>> name from drm_mode_set_name(). >> From what file? (See above.) >> >>> For consistency, this patch adds "i" >>> character at the end of name of interlaced modes defined in >>> drm_edid_modes.h file. >>> >>> Signed-off-by: Joonyoung Shim >>> Signed-off-by: Kyungmin Park >> I think, you already sent that patch to the list, did not you? Please >> mark this by tagging the subject line with [RESENT]. >> >> With the updated commit message this is >> >> Acked-by: Paul Menzel > It was actually Russell King: > http://lists.freedesktop.org/archives/dri-devel/2012-August/026303.html > I missed that. Thanks.
runtime PM and special power switches
Hi Rafael, I've been investigating runtime PM support for some use-cases on GPUs. In some laptops we have a secondary GPU (optimus) that can be powered up for certain 3D tasks and then turned off when finished with. Now I did an initial pass on supporting it without using the kernel runtime PM stuff, but Alan said I should take a look so here I am. While I've started to get a handle on things, we have a bit of an extra that I'm not sure we cater for. Currently we get called from the PCI layer which after we are finished with our runtime suspend callback, will go put the device into the correct state etc, however on these optimus/powerxpress laptops we have a separate ACPI or platform driver controlled power switch that we need to call once the PCI layer is finished the job. This switch effectively turns the power to the card completely off leaving it drawing no power. No we can't hit the switch from the driver callback as the PCI layer will get lost, so I'm wondering how you'd envisage we could plug this in. Dave.
[Bug 47321] crash with drm/radeon on hp dm1 4100ed laptop with amd 6320
https://bugzilla.kernel.org/show_bug.cgi?id=47321 --- Comment #9 from Marcel Pol 2012-09-11 05:59:30 --- I thought about it for a while. For me personally the bug is fixed. But it should be that if the driver doesn't find the software, then it should degrade gracefully. Maybe not load the driver, or just do nothing. -- 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 1/2] nouveau: convert to dev_pm_ops
From: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 93 +--
1 file changed, 67 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 9fb56b3..bb51a00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -391,17 +391,12 @@ nouveau_drm_remove(struct pci_dev *pdev)
}
int
-nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t pm_state)
+nouveau_do_suspend(struct drm_device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_cli *cli;
int ret;
- if (dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
- pm_state.event == PM_EVENT_PRETHAW)
- return 0;
-
NV_INFO(drm, "suspending fbcon...\n");
nouveau_fbcon_set_suspend(dev, 1);
@@ -425,13 +420,6 @@ nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t
pm_state)
goto fail_client;
nouveau_agp_fini(drm);
-
- pci_save_state(pdev);
- if (pm_state.event == PM_EVENT_SUSPEND) {
- pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
- }
-
return 0;
fail_client:
@@ -444,24 +432,33 @@ fail_client:
return ret;
}
-int
-nouveau_drm_resume(struct pci_dev *pdev)
+int nouveau_pmops_suspend(struct device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nouveau_cli *cli;
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;
- if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
- NV_INFO(drm, "re-enabling device...\n");
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- ret = pci_enable_device(pdev);
+ ret = nouveau_do_suspend(drm_dev);
if (ret)
return ret;
- pci_set_master(pdev);
+
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+
+ return 0;
+}
+
+int
+nouveau_do_resume(struct drm_device *dev)
+{
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct nouveau_cli *cli;
+
+ NV_INFO(drm, "re-enabling device...\n");
nouveau_agp_reset(drm);
@@ -482,6 +479,42 @@ nouveau_drm_resume(struct pci_dev *pdev)
return 0;
}
+int nouveau_pmops_resume(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ int ret;
+
+ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ return 0;
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+ pci_set_master(pdev);
+
+ return nouveau_do_resume(drm_dev);
+}
+
+static int nouveau_pmops_freeze(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return nouveau_do_suspend(drm_dev);
+}
+
+static int nouveau_pmops_thaw(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return nouveau_do_resume(drm_dev);
+}
+
+
static int
nouveau_drm_open(struct drm_device *dev, struct drm_file *fpriv)
{
@@ -631,14 +664,22 @@ nouveau_drm_pci_table[] = {
{}
};
+static const struct dev_pm_ops nouveau_pm_ops = {
+ .suspend = nouveau_pmops_suspend,
+ .resume = nouveau_pmops_resume,
+ .freeze = nouveau_pmops_freeze,
+ .thaw = nouveau_pmops_thaw,
+ .poweroff = nouveau_pmops_freeze,
+ .restore = nouveau_pmops_resume,
+};
+
static struct pci_driver
nouveau_drm_pci_driver = {
.name = "nouveau",
.id_table = nouveau_drm_pci_table,
.probe = nouveau_drm_probe,
.remove = nouveau_drm_remove,
- .suspend = nouveau_drm_suspend,
- .resume = nouveau_drm_resume,
+ .driver.pm = &nouveau_pm_ops,
};
static int __init
--
1.7.12
nouveau runtime PM support (take two)
So I started investigating the kernel runtime PM support as per Alan's suggestion. An API with lots of interface docs and not enough examples :-) So I've mostly implemented autosuspend for nouveau with this, it could still be pushed down a lot further into the code I suspect. Also this doesn't actually turn the power switch off since runtime PM currently have no hook to do that, so it only D3s the GPU. Dave.
[PATCH 2/2] nouveau: add runtime PM support (v0.1)
From: Dave Airlie
This adds hook into the system runtime PM support to enable
dynamic PM on the nvidia device.
It doesn't hook into the power switch yet, only D3s the card.
TODO:
keep a reference if we have enabled outputs/framebuffers (??)
keep a reference if we have any requests in flight.
sprinkle mark last busy for autosuspend timeout
Signed-off-by: Dave Airlie
-
+#include
#include "drmP.h"
#include "drm_edid.h"
#include "drm_crtc_helper.h"
@@ -239,6 +239,12 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
struct nouveau_encoder *nv_partner;
struct nouveau_i2c_port *i2c;
int type;
+ int ret;
+ enum drm_connector_status conn_status = connector_status_disconnected;
+
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0)
+ return ret;
/* Cleanup the previous EDID block. */
if (nv_connector->edid) {
@@ -262,7 +268,8 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
!nouveau_dp_detect(to_drm_encoder(nv_encoder))) {
NV_ERROR(drm, "Detected %s, but failed init\n",
drm_get_connector_name(connector));
- return connector_status_disconnected;
+ conn_status = connector_status_disconnected;
+ goto out;
}
/* Override encoder type for DVI-I based on whether EDID
@@ -289,13 +296,15 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
}
nouveau_connector_set_encoder(connector, nv_encoder);
- return connector_status_connected;
+ conn_status = connector_status_connected;
+ goto out;
}
nv_encoder = nouveau_connector_of_detect(connector);
if (nv_encoder) {
nouveau_connector_set_encoder(connector, nv_encoder);
- return connector_status_connected;
+ conn_status = connector_status_connected;
+ goto out;
}
detect_analog:
@@ -310,12 +319,18 @@ detect_analog:
if (helper->detect(encoder, connector) ==
connector_status_connected) {
nouveau_connector_set_encoder(connector, nv_encoder);
- return connector_status_connected;
+ conn_status = connector_status_connected;
+ goto out;
}
}
- return connector_status_disconnected;
+ out:
+
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+
+ return conn_status;
}
static enum drm_connector_status
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index bb51a00..63b1b7c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -25,7 +25,10 @@
#include
#include
#include
-
+#include
+#include
+#include "drmP.h"
+#include "drm_crtc_helper.h"
#include
#include
#include
@@ -334,6 +337,13 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
nouveau_accel_init(drm);
nouveau_fbcon_init(dev);
+
+ pm_runtime_use_autosuspend(dev->dev);
+ pm_runtime_set_autosuspend_delay(dev->dev, 5000);
+ pm_runtime_set_active(dev->dev);
+ pm_runtime_allow(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
+ pm_runtime_mark_last_busy(dev->dev);
return 0;
fail_dispinit:
@@ -349,6 +359,7 @@ fail_ttm:
nouveau_vga_fini(drm);
fail_device:
nouveau_cli_destroy(&drm->client);
+
return ret;
}
@@ -357,6 +368,7 @@ nouveau_drm_unload(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ pm_runtime_get_noresume(dev->dev);
nouveau_fbcon_fini(dev);
nouveau_accel_fini(drm);
@@ -523,16 +535,21 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
struct nouveau_cli *cli;
int ret;
+ /* need to bring up power immediately if opening device */
+ ret = pm_runtime_get_sync(dev->dev);
+ if (ret < 0)
+ return ret;
+
ret = nouveau_cli_create(pdev, fpriv->pid, sizeof(*cli), (void **)&cli);
if (ret)
- return ret;
+ goto out_suspend;
if (nv_device(drm->device)->card_type >= NV_50) {
ret = nouveau_vm_new(nv_device(drm->device), 0, (1ULL << 40),
0x1000, &cli->base.vm);
if (ret) {
nouveau_cli_destroy(cli);
- return ret;
+ goto out_suspend;
}
}
@@ -541,7 +558,12 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
mutex_lock(&drm->client.mutex);
[PATCH v2] drm/exynos: separeated fimd_power_on into some parts.
Changelog v2:
fix pm operation when resume.
Changelog v1:
this patch separetes fimd_power_on into fimd_activate and fimd_clock and
fimd_activate function will call fimd_clock to control fimd power and
vsync interrupt.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 60 --
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 47396e1..28733cd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -747,16 +747,10 @@ static void fimd_clear_win(struct fimd_context *ctx, int
win)
writel(val, ctx->regs + SHADOWCON);
}
-static int fimd_power_on(struct fimd_context *ctx, bool enable)
+static int fimd_clock(struct fimd_context *ctx, bool enable)
{
- struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
- struct device *dev = subdrv->dev;
-
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (enable != false && enable != true)
- return -EINVAL;
-
if (enable) {
int ret;
@@ -769,18 +763,31 @@ static int fimd_power_on(struct fimd_context *ctx, bool
enable)
clk_disable(ctx->bus_clk);
return ret;
}
+ } else {
+ clk_disable(ctx->lcd_clk);
+ clk_disable(ctx->bus_clk);
+ }
+
+ return 0;
+}
+
+static int fimd_activate(struct fimd_context *ctx, bool enable)
+{
+ if (enable) {
+ int ret;
+ struct device *dev = ctx->subdrv.dev;
+
+ ret = fimd_clock(ctx, true);
+ if (ret < 0)
+ return ret;
ctx->suspended = false;
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, &ctx->irq_flags))
fimd_enable_vblank(dev);
-
- fimd_apply(dev);
} else {
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
-
+ fimd_clock(ctx, false);
ctx->suspended = true;
}
@@ -930,15 +937,15 @@ static int fimd_suspend(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
- if (pm_runtime_suspended(dev))
- return 0;
-
/*
* do not use pm_runtime_suspend(). if pm_runtime_suspend() is
* called here, an error would be returned by that interface
* because the usage_count of pm runtime is more than 1.
*/
- return fimd_power_on(ctx, false);
+ if (!pm_runtime_suspended(dev))
+ return fimd_activate(ctx, false);
+
+ return 0;
}
static int fimd_resume(struct device *dev)
@@ -950,8 +957,21 @@ static int fimd_resume(struct device *dev)
* of pm runtime would still be 1 so in this case, fimd driver
* should be on directly not drawing on pm runtime interface.
*/
- if (!pm_runtime_suspended(dev))
- return fimd_power_on(ctx, true);
+ if (pm_runtime_suspended(dev)) {
+ int ret;
+
+ ret = fimd_activate(ctx, true);
+ if (ret < 0)
+ return ret;
+
+ /*
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
+*/
+ fimd_apply(dev);
+ }
return 0;
}
@@ -964,7 +984,7 @@ static int fimd_runtime_suspend(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, false);
+ return fimd_activate(ctx, false);
}
static int fimd_runtime_resume(struct device *dev)
@@ -973,7 +993,7 @@ static int fimd_runtime_resume(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, true);
+ return fimd_activate(ctx, true);
}
#endif
--
1.7.4.1
Missing GIT tag for mesa v9.0?
Hi, I can't see it in [1], forgotten? Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/refs/tags
[Bug 35838] Savage2 crashes when running Practice
https://bugs.freedesktop.org/show_bug.cgi?id=35838 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Boll 2012-09-11 07:35:04 UTC --- (In reply to comment #1) > Appears to be fixed in > > 874a2c0b7da62f4dd08dedcec221f55b22e40e95 Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Missing GIT tag for mesa v9.0?
On 09/11/2012 09:40 AM, Sedat Dilek wrote: > Hi, > > I can't see it in [1], forgotten? Mesa 9.0 hasn't been released yet, so of course there isn't a release tag. > Regards, > - Sedat - > > [1] http://cgit.freedesktop.org/mesa/mesa/refs/tags
[Bug 29691] Lightsmark isnt rendering textures
https://bugs.freedesktop.org/show_bug.cgi?id=29691 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:01:43 UTC --- Note: classic r600 driver has been abandoned. texture rendering is fine with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26962] fbo/fbo-nodepth-test: Invalid command stream
https://bugs.freedesktop.org/show_bug.cgi?id=26962 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:46:31 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27148] Failed assertion in piglit test 'bin/fbo-flushing -auto' with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27148 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Andreas Boll 2012-09-11 09:50:53 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27149] Failed assertion in piglit test 'fbo-pbo-readpixels-small -auto' with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27149 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:52:08 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27147] piglit "fdo23670-drawpix_stencil -auto" test dumps core with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27147 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:53:44 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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: make 64bit fences more robust
0 then we got 0x which with | > become 0x2 then we get next fence value 0x 0001 and > again we increment upper 32bits so last seq become 0x3 0001. Good point. > Again this will happen after month of uptime and all it does is > decrement the amount of uptime for which 64bit fence are fine ie at > worst we over increment by 0x2 instead of 0x1 on > wrap around. How about this idea: Instead of increasing the upper 32bits we just use the upper 32bits of the last emitted fence value? E.g. see the attached patch. That both should handle random zero and out of order values more gracefully. Additionally I think that the reason we haven't had this before is that this corruption might only happens on hw (re-)initialisation, e.g. boot and resume. Currently I'm hacking together a small test app that just emits an IB with some NOP instructions, if I'm not completely wrong that should gives us a very high fence rate, so we might be able to actually test the wrap around a bit more. Christian. > Cheers, > Jerome > >> All this probably lead to questioning the usefulness of 64bits fence. >> >> Cheers, >> Jerome -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-make-64bit-fences-more-robust-v2.patch Type: text/x-patch Size: 1365 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120911/e861c51a/attachment.bin>
[PATCH] drm/radeon: make 64bit fences more robust
On Die, 2012-09-11 at 12:11 +0200, Christian K?nig wrote: > > How about this idea: Instead of increasing the upper 32bits we just use > the upper 32bits of the last emitted fence value? > E.g. see the attached patch. That both should handle random zero and out > of order values more gracefully. I like this idea. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 54767] New: [r300g] 298 failures on WebGL Conformance Test
https://bugs.freedesktop.org/show_bug.cgi?id=54767 Bug #: 54767 Summary: [r300g] 298 failures on WebGL Conformance Test Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: fabio.ped at libero.it Created attachment 66963 --> https://bugs.freedesktop.org/attachment.cgi?id=66963 298 failing WebGL tests on 2012-09-11 When running WebGL Conformance Test: https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/webgl-conformance-tests.html on r300 git on a RV530 298 tests fail. See the attachment for failing tests. If some get fixed I can later open a new bug for every test. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27141] piglit glean/vertProg1 core dumps with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27141 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Andreas Boll 2012-09-11 11:07:28 UTC --- Note: classic r600 driver has been abandoned. all glean/vertProg1 tests pass with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27324] fbotest* broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=27324 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 11:21:57 UTC --- Note: classic r600 driver has been abandoned. fbotest* pass with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #5 from Andreas Boll 2012-09-11 11:32:01 UTC --- (In reply to comment #4) > Created attachment 43951 [details] [review] > possible fix > > Does this patch help? this patch has been committed as commit 1dc204d145dc8c0b19473a7814c201a8954b6274 Author: Alex Deucher Date: Mon Feb 28 21:52:19 2011 -0500 r600g: truncate point sampled texture coordinates By default the hardware rounds texcoords. However, for point sampled textures, the expected behavior is to truncate. When we have point sampled textures, set the truncate bit in the sampler. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=25871 Signed-off-by: Alex Deucher and reverted in commit 72c6a748b9ffdaa893f82faf911f22a241a5e4f5 Author: Marek Ol??k Date: Mon May 2 01:10:19 2011 +0200 Revert "r600g: truncate point sampled texture coordinates" This reverts commit 1dc204d145dc8c0b19473a7814c201a8954b6274. MC_COORD_TRUNCATE is for MPEG and produces quite an interesting behavior on regular textures. Anyway that commit broke filtering in demos/cubemap. reassigning to r600g is this still an issue with a newer mesa (e.g. 8.0.4 or git master)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27142] piglit "glean/pbo -o -v" test dumps core
https://bugs.freedesktop.org/show_bug.cgi?id=27142 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Andreas Boll 2012-09-11 11:45:49 UTC --- Note: classic r600 driver has been abandoned. works without any segfault with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 test result: 9 tests passed, 1 tests failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28049] Failure observed while running piglit glean/pbo
https://bugs.freedesktop.org/show_bug.cgi?id=28049 Andreas Boll changed: What|Removed |Added Summary|Failure observed while |Failure observed while |running the Glean test |running piglit glean/pbo Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #3 from Andreas Boll 2012-09-11 11:53:14 UTC --- Note: classic r600 driver has been abandoned. tested with r600g (gallium driver) on my rv770 mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 test results: 9 tests passed, 1 tests failed. reassigning to r600g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27142] piglit "glean/pbo -o -v" test dumps core
https://bugs.freedesktop.org/show_bug.cgi?id=27142 --- Comment #3 from Andreas Boll 2012-09-11 11:57:28 UTC --- (In reply to comment #2) > Note: classic r600 driver has been abandoned. > > works without any segfault with r600g (gallium driver) on my rv770 > tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd > and mesa 8.0.4 > > test result: > 9 tests passed, 1 tests failed. the failing test is tracked in Bug 28049 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31423] Stars in Celestia misrendered
https://bugs.freedesktop.org/show_bug.cgi?id=31423 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Andreas Boll 2012-09-11 12:07:01 UTC --- (In reply to comment #2) > On R600g, Mesa 8.0rc2 the stars seem to have proper colors. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 47321] crash with drm/radeon on hp dm1 4100ed laptop with amd 6320
https://bugzilla.kernel.org/show_bug.cgi?id=47321 --- Comment #10 from Alex Deucher 2012-09-11 12:25:13 --- (In reply to comment #9) > I thought about it for a while. For me personally the bug is fixed. But it > should be that if the driver doesn't find the software, then it should degrade > gracefully. Maybe not load the driver, or just do nothing. It's not the driver, it's the kernel fw loader. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
libcamellocal.so 5 0.0042 libfontconfig.so.1.5.0 4 0.0034 libgdk_pixbuf-2.0.so.0.2600.1 3 0.0025 libcamelimap.so 3 0.0025 libemail-engine.so.0.0.0 2 0.0017 libemiscwidgets.so.0.0.0 2 0.0017 libeshell.so.0.0.0 2 0.0017 libevolution-mail.so.0.0.0 1 8.4e-04 libcamelsmtp.so 1 8.4e-04 libevolution-utils.so.0.0.0 1 8.4e-04 libatk-1.0.so.0.20409.1 1 8.4e-04 libnspr4.so 1 8.4e-04 libedataserver-1.2.so.16.0.0 100885 12.5352 pulseaudio CPU_CLK_UNHALT...| samples| %| -- 43817 43.4326 no-vmlinux 16451 16.3067 libpulsecommon-2.0.so 12801 12.6887 libspeexdsp.so.1.5.0 11348 11.2485 libpulsecore-2.0.so 3897 3.8628 libpulse.so.0.14.2 3080 3.0530 libc-2.13.so 2844 2.8191 libasound.so.2.0.0 2000 1.9825 libpthread-2.13.so 1622 1.6078 libprotocol-native.so 1563 1.5493 libalsa-util.so 602 0.5967 ld-2.13.so 542 0.5372 [vdso] (tgid:13180 range:0xb77a6000-0xb77a7000) 318 0.3152 librt-2.13.so 82317 10.2281 no-vmlinux 81141 10.0820 python2.7 CPU_CLK_UNHALT...| samples| %| -- 28004 34.5128 no-vmlinux 6449 7.9479 libvorbis.so.0.4.5 6322 7.7914 libgstreamer-0.10.so.0.30.0 6109 7.5289 libpulsecommon-2.0.so 5993 7.3859 libpthread-2.13.so 4524 5.5755 libglib-2.0.so.0.3200.3 4276 5.2698 libpulse.so.0.14.2 3965 4.8866 libc-2.13.so 3255 4.0115 libgstbase-0.10.so.0.30.0 3069 3.7823 libgobject-2.0.so.0.3200.3 2407 2.9664 libgstcoreelements.so 1797 2.2147 libogg.so.0.8.0 1765 2.1752 libgstaudio-0.10.so.0.25.0 885 1.0907 libgstogg.so 867 1.0685 libgstpulse.so 418 0.5152 librt-2.13.so 406 0.5004 [vdso] (tgid:13956 range:0xb76fa000-0xb76fb000) 253 0.3118 libgstvorbis.so 194 0.2391 libgstplaybin.so 83 0.1023 libsoup-2.4.so.1.5.0 44 0.0542 libgio-2.0.so.0.3200.3 35 0.0431 libgstaudioconvert.so 12 0.0148 libgstsouphttpsrc.so 3 0.0037 libX11.so.6.3.0 2 0.0025 libgdk-x11-2.0.so.0.2400.10 2 0.0025 libgtk-x11-2.0.so.0.2400.10 1 0.0012 libdbus-1.so.3.7.2 1 0.0012 libpyglib-2.0-python2.7.so.0.0.0 [?] The following packages are installed. libdrm2:i386 2.4.33-3 xserver-xorg-video-radeon 1:6.14.4-5 linux-image-3.2.0-3-686-pae 3.2.23-1 Could somebody please tell me what component (X driver, DRM, Evolution, Cairo, ?) to investigate and how? Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120911/ec155a50/attachment.pgp>
xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. > Closing Evolution the usage goes back to more or less 0 %. I'm not seeing this. Is there something in your Evolution window(s) that is constantly repainting, e.g. a spinner in the status bar, a blinking cursor, ... ? > Could somebody please tell me what component (X driver, DRM, Evolution, > Cairo, ?) to investigate and how? I'd focus on profiling the X server, making sure the profiles show symbols, ideally with call graphs. sysprof or perf might work better for this than oprofile. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120911/43a45f5d/attachment-0001.pgp>
xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
Am Dienstag, den 11.09.2012, 14:55 +0200 schrieb Michel D?nzer: > On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: > > > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and > > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. > > Closing Evolution the usage goes back to more or less 0 %. > > I'm not seeing this. Is there something in your Evolution window(s) that > is constantly repainting, e.g. a spinner in the status bar, a blinking > cursor, ... ? Now that you are mentioning it, in the bottom there is the message ?Checking for New Messages? and next to it there is an animation where something goes around a circle. Canceling that removes X?s CPU usage. Thanks a lot. Should I recommend something to the Evolution folks on how to due such animations? Or is the only way to avoid animations? > > Could somebody please tell me what component (X driver, DRM, Evolution, > > Cairo, ?) to investigate and how? > > I'd focus on profiling the X server, making sure the profiles show > symbols, ideally with call graphs. sysprof or perf might work better for > this than oprofile. Thanks. Lucky me, that this is not needed now and I can postpone how to figure out how to start X that way under Debian with GDM. Michael, thanks as always! Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120911/9b84cd57/attachment.pgp>
xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
On Tue, 11 Sep 2012 15:07:41 +0200, Paul Menzel wrote: > Am Dienstag, den 11.09.2012, 14:55 +0200 schrieb Michel D??nzer: > > I'd focus on profiling the X server, making sure the profiles show > > symbols, ideally with call graphs. sysprof or perf might work better for > > this than oprofile. > > Thanks. Lucky me, that this is not needed now and I can postpone how to > figure out how to start X that way under Debian with GDM. For future reference, sysprof and perf can be used to perform system wide profiling - that is you can launch them after starting the task you need to profile. For sysprof this is its default mode, and for perf you need 'perf record -a' A quick 'sudo perf top' is always a useful first step. For best results, make sure you have debugging symbols and frame pointers. -Chris -- Chris Wilson, Intel Open Source Technology Centre
xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
On Die, 2012-09-11 at 15:07 +0200, Paul Menzel wrote: > Am Dienstag, den 11.09.2012, 14:55 +0200 schrieb Michel D?nzer: > > On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: > > > > > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and > > > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. > > > Closing Evolution the usage goes back to more or less 0 %. > > > > I'm not seeing this. Is there something in your Evolution window(s) that > > is constantly repainting, e.g. a spinner in the status bar, a blinking > > cursor, ... ? > > Now that you are mentioning it, in the bottom there is the message > ?Checking for New Messages? and next to it there is an animation where > something goes around a circle. Canceling that removes X?s CPU usage. That's a GTK+ spinner widget, which uses RENDER trapezoids, which is a software rendering fallback with EXA. > Should I recommend something to the Evolution folks on how to due such > animations? Or is the only way to avoid animations? I don't think there's anything wrong with the animation per se. However, one issue I've found is that Evolution schedules many actions as glib idle callbacks with priority lower than G_PRIORITY_HIGH_IDLE + 20, which is the priority used by GTK+ for drawing animations. This can result in the animations delaying the completion of the actual work they're representing. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120911/fd03a4bc/attachment.pgp>
[RFC] drm dynamic power off support
At Mon, 10 Sep 2012 18:50:04 +1000, Dave Airlie wrote: > > On Mon, Sep 10, 2012 at 6:47 PM, Takashi Iwai wrote: > > At Mon, 10 Sep 2012 15:04:02 +1000, > > Dave Airlie wrote: > >> > >> On Mon, Sep 10, 2012 at 2:31 PM, Dave Airlie wrote: > >> > For optimus and powerxpress setups where we can explicitly power off > >> > the GPU I'd like to do this under control of the driver. Now that I've > >> > added X server support for secondary GPUs, it makes sense to start > >> > powering them down more often if we can. > >> > > >> > I've tested this code on two laptops, one intel/nouveau one intel/radeon > >> > It works, powertop says I use 5-6W less power. > >> > > >> > Caveats: > >> > There is a race at X server start with platform probing code, if > >> > the secondary device is off, we the wrong PCI info for it, I've > >> > got a patch that works around this I'll send to the xorg-devel. > >> > > >> > Audio seems to get screwed at least on one machine, we power up > >> > and the alsa callbacks into snd_hda_intel get called but it can't > >> > find the hw properly, need to investigate a bit further. > >> > > >> > Dave. > >> > > >> Hi Takashi, > >> > >> just wondering how well setup alsa would be for the dGPU powering > >> up/down a lot more often, > >> 139.529103] nouveau [ DRM][:01:00.0] resuming display... > >> [ 139.833960] ALSA sound/pci/hda/hda_intel.c:2533 Enabling > >> :01:00.1 via VGA-switcheroo > >> [ 139.844789] snd_hda_intel :01:00.1: Refused to change power > >> state, currently in D3 > >> [ 139.915760] snd_hda_intel :01:00.1: Refused to change power > >> state, currently in D3 > > > > These come from PCI core, and... > > > >> [ 140.917437] ALSA sound/pci/hda/hda_intel.c:813 spurious response > >> 0x0:0x3, last cmd=0x301f0500 > >> [ 140.917449] ALSA sound/pci/hda/hda_intel.c:813 spurious response > >> 0x0:0x3, last cmd=0x301f0500 > >> [ 140.917455] ALSA sound/pci/hda/hda_intel.c:813 spurious response > >> 0x0:0x3, last cmd=0x301f0500 > >> [ 140.917460] ALSA sound/pci/hda/hda_intel.c:813 spurious response > >> 0x0:0x3, last cmd=0x301f0500 > >> [ 140.917465] ALSA sound/pci/hda/hda_intel.c:813 spurious response > >> 0x0:0x3, last cmd=0x301f0500 > > > > These are from hda-codec. The verb 0x301f0500 is GET_POWER_STATE > > verb, so it looks like that the hardware doesn't respond to any h/w > > state query / change. > > > >> is just some of the things I see, if I turn off before snd_hda_intel, > >> things go badly wrong when > >> I do power up the dGPU, if I delay the power off until audio is > >> loaded, I start to see wierd things when pulseaudio starts when the > >> dGPU is off. > > > > What does your patch do? Sorry, I still haven't followed your patch > > yet. > > It turns the GPU off completely on a timer, so 5s after we have no > activity we cut the power to the GPU completely, > > but I call the switcheroo callbacks properly and it should be bringing > the power back up correctly, unless there is some initialisation delay > or the audio hw comes up in a wierd state. > > Though it should be no different than using the ON/OFF stuff that we have now. > > > The message from PCI core makes me wonder whether the GPU is really > > active at that point. Since it's just a call of > > pci_set_power_state(PCI_D0) at the beginning of resume procedure, it's > > rather a problem in a deeper level than the audio controller itself. > > The following spurious response messages are likely the result of the > > controller being still in D3. > > That can happen where the device has gone into a really wierd place > and just won't come back > > I might try adding some delays tomorrow. Does your tree contain the recent patches in sound git tree for-next branch, or it's based on 3.6-rc? The former contains some patches to make the controller going to D3, so this might have some side effect. Takashi
[Bug 51652] [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=51652 --- Comment #3 from okias 2012-09-11 13:45:48 UTC --- Created attachment 66971 --> https://bugs.freedesktop.org/attachment.cgi?id=66971 picture.jpg after upgrade from 3.6.0_rc2 to rc4 second monitor works with clone (absolute 0 0 both), but extending desktop cause this (absolute 1920 0 and 0 0) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #6 from Pierre Ossman 2012-09-11 13:51:20 UTC --- I don't have any updated systems right now, so I can't really test. Test program should still be valid though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
-next queue and EDID stuff
Ping On 09/04/2012 09:02 AM, Ian Pilcher wrote: > On 08/30/2012 12:23 AM, Ian Pilcher wrote: >> >> * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP. It won't >> work "out of the box" with the Intel driver until that driver is >> fixed to not send audio InfoFrames to non-HDMI displays (but anyone >> who has the combination will be able to add their own quirk to make >> it work). >> >> * Leave both flags, because both are accurate. The display is confused >> by any InfoFrames (audio or AVI), and it is reporting non-existent >> audio capabilities. The fact that the combination of the two flags >> makes the display work with Intel GPUs is a happy/sad/neutral >> accident, and the driver's behavior is still considered broken. >> >> (Essentially, this would mean just editing the comments to reflect the >> above reasoning.) > > Ajax - > > I *really* want to close the loop on this. If you can tell me which of > the above options you prefer, I will create a new patch set, including > the drm_monitor_has_hdmi_audio() function that you suggested in your > note on 8/30. > > Thanks! > -- Ian Pilcher arequipeno at gmail.com "If you're going to shift my paradigm ... at least buy me dinner first."
[PATCH 1/8] drm/radeon: fix VA range check
The end offset is exclusive not inclusive.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index d7bd46b..614e31a 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -732,7 +732,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
head = &vm->va;
last_offset = 0;
list_for_each_entry(tmp, &vm->va, vm_list) {
- if (bo_va->soffset >= last_offset && bo_va->eoffset <
tmp->soffset) {
+ if (bo_va->soffset >= last_offset && bo_va->eoffset <=
tmp->soffset) {
/* bo can be added before this one */
break;
}
--
1.7.9.5
[PATCH 3/8] drm/radeon: move IB pool to 1MB offset
Even GPUs can have a null pointer dereference, so move
the IB pool to another offset to catch those.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/radeon/radeon_ring.c |6 +++---
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d48bd30..55f17f9 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -123,6 +123,7 @@ extern int radeon_lockup_timeout;
#define CAYMAN_RING_TYPE_CP2_INDEX 2
/* hardcode those limit for now */
+#define RADEON_VA_IB_OFFSET(1 << 20)
#define RADEON_VA_RESERVED_SIZE(8 << 20)
#define RADEON_IB_VM_MAX_SIZE (64 << 10)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 5694421..1b1c001 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -980,7 +980,7 @@ int radeon_vm_init(struct radeon_device *rdev, struct
radeon_vm *vm)
/* map the ib pool buffer at 0 in virtual address space, set
* read only
*/
- r = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo, 0,
+ r = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo,
RADEON_VA_IB_OFFSET,
RADEON_VM_PAGE_READABLE | RADEON_VM_PAGE_SNOOPED);
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 993cf71..d90b0bc 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -79,10 +79,10 @@ int radeon_ib_get(struct radeon_device *rdev, int ring,
ib->ptr = radeon_sa_bo_cpu_addr(ib->sa_bo);
ib->vm = vm;
if (vm) {
- /* ib pool is bind at 0 in virtual address space,
-* so gpu_addr is the offset inside the pool bo
+ /* ib pool is bound at RADEON_VA_IB_OFFSET in virtual address
+* space and soffset is the offset inside the pool bo
*/
- ib->gpu_addr = ib->sa_bo->soffset;
+ ib->gpu_addr = ib->sa_bo->soffset + RADEON_VA_IB_OFFSET;
} else {
ib->gpu_addr = radeon_sa_bo_gpu_addr(ib->sa_bo);
}
--
1.7.9.5
[PATCH 4/8] drm/radeon: move and rename radeon_bo_va function
It doesn't really belong into the object functions,
also rename it to avoid collisions with struct radeon_bo_va.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|2 ++
drivers/gpu/drm/radeon/radeon_gart.c | 34
drivers/gpu/drm/radeon/radeon_gem.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c | 13
drivers/gpu/drm/radeon/radeon_object.h |2 --
5 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 55f17f9..8cca1d2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1846,6 +1846,8 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
struct ttm_mem_reg *mem);
void radeon_vm_bo_invalidate(struct radeon_device *rdev,
struct radeon_bo *bo);
+struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
+ struct radeon_bo *bo);
int radeon_vm_bo_add(struct radeon_device *rdev,
struct radeon_vm *vm,
struct radeon_bo *bo,
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 1b1c001..2c59491 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -662,7 +662,31 @@ void radeon_vm_fence(struct radeon_device *rdev,
vm->fence = radeon_fence_ref(fence);
}
-/* object have to be reserved */
+/**
+ * radeon_vm_bo_find - find the bo_va for a specific vm & bo
+ *
+ * @vm: requested vm
+ * @bo: requested buffer object
+ *
+ * Find @bo inside the requested vm (cayman+).
+ * Search inside the @bos vm list for the requested vm
+ * Returns the found bo_va or NULL if none is found
+ *
+ * Object has to be reserved!
+ */
+struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
+ struct radeon_bo *bo)
+{
+ struct radeon_bo_va *bo_va;
+
+ list_for_each_entry(bo_va, &bo->va, bo_list) {
+ if (bo_va->vm == vm) {
+ return bo_va;
+ }
+ }
+ return NULL;
+}
+
/**
* radeon_vm_bo_add - add a bo to a specific vm
*
@@ -676,6 +700,8 @@ void radeon_vm_fence(struct radeon_device *rdev,
* Add @bo to the list of bos associated with the vm and validate
* the offset requested within the vm address space.
* Returns 0 for success, error for failure.
+ *
+ * Object has to be reserved!
*/
int radeon_vm_bo_add(struct radeon_device *rdev,
struct radeon_vm *vm,
@@ -823,7 +849,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
if (vm->sa_bo == NULL)
return 0;
- bo_va = radeon_bo_va(bo, vm);
+ bo_va = radeon_vm_bo_find(vm, bo);
if (bo_va == NULL) {
dev_err(rdev->dev, "bo %p not in vm %p\n", bo, vm);
return -EINVAL;
@@ -912,7 +938,7 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo_va *bo_va;
int r;
- bo_va = radeon_bo_va(bo, vm);
+ bo_va = radeon_vm_bo_find(vm, bo);
if (bo_va == NULL)
return 0;
@@ -1009,7 +1035,7 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
*/
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (!r) {
- bo_va = radeon_bo_va(rdev->ring_tmp_bo.bo, vm);
+ bo_va = radeon_vm_bo_find(vm, rdev->ring_tmp_bo.bo);
list_del_init(&bo_va->bo_list);
list_del_init(&bo_va->vm_list);
radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 1b57b00..6cac5cc 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -461,7 +461,7 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
}
switch (args->operation) {
case RADEON_VA_MAP:
- bo_va = radeon_bo_va(rbo, &fpriv->vm);
+ bo_va = radeon_vm_bo_find(&fpriv->vm, rbo);
if (bo_va) {
args->operation = RADEON_VA_RESULT_VA_EXIST;
args->offset = bo_va->soffset;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 9024e72..2844e0b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -646,16 +646,3 @@ int radeon_bo_reserve(struct radeon_bo *bo, bool no_wait)
}
return 0;
}
-
-/* object have to be reserved */
-struct radeon_bo_va *radeon_bo_va(struct radeon_bo *rbo, struct radeon_vm *vm)
-{
- struct radeon_bo_va *bo_va;
-
- list_for_each_entry(bo_va, &rbo->va, bo_list) {
- if (bo_va->vm == vm) {
- return bo_va;
- }
- }
- return NULL;
[PATCH 2/8] drm/radeon: fix VA overlap check
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 614e31a..5694421 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -736,7 +736,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
/* bo can be added before this one */
break;
}
- if (bo_va->soffset >= tmp->soffset && bo_va->soffset <
tmp->eoffset) {
+ if (bo_va->eoffset > tmp->soffset && bo_va->soffset <
tmp->eoffset) {
/* bo and tmp overlap, invalid offset */
dev_err(rdev->dev, "bo %p va 0x%08X conflict with (bo
%p 0x%08X 0x%08X)\n",
bo, (unsigned)bo_va->soffset, tmp->bo,
--
1.7.9.5
[PATCH 5/8] drm/radeon: let bo_reserve take no_intr instead of no_wait param
The no_wait param isn't used anywhere, and actually isn't
very usefull at all.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.c |7 +++
drivers/gpu/drm/radeon/radeon_object.h |2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 2844e0b..8d23b7e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -627,18 +627,17 @@ int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
bool no_wait)
/**
* radeon_bo_reserve - reserve bo
* @bo:bo structure
- * @no_wait: don't sleep while trying to reserve (return -EBUSY)
+ * @no_intr: don't return -ERESTARTSYS on pending signal
*
* Returns:
- * -EBUSY: buffer is busy and @no_wait is true
* -ERESTARTSYS: A wait for the buffer to become unreserved was interrupted by
* a signal. Release all buffer reservations and return to user-space.
*/
-int radeon_bo_reserve(struct radeon_bo *bo, bool no_wait)
+int radeon_bo_reserve(struct radeon_bo *bo, bool no_intr)
{
int r;
- r = ttm_bo_reserve(&bo->tbo, true, no_wait, false, 0);
+ r = ttm_bo_reserve(&bo->tbo, !no_intr, false, false, 0);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
dev_err(bo->rdev->dev, "%p reserve failed\n", bo);
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 2aaf6e3..93cd491 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -52,7 +52,7 @@ static inline unsigned radeon_mem_type_to_domain(u32 mem_type)
return 0;
}
-int radeon_bo_reserve(struct radeon_bo *bo, bool no_wait);
+int radeon_bo_reserve(struct radeon_bo *bo, bool no_intr);
static inline void radeon_bo_unreserve(struct radeon_bo *bo)
{
--
1.7.9.5
[PATCH 6/8] drm/radeon: fix gem_close_object handling
Make the reserve non interruptible.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 6cac5cc..cfad667 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -134,13 +134,16 @@ void radeon_gem_object_close(struct drm_gem_object *obj,
struct radeon_device *rdev = rbo->rdev;
struct radeon_fpriv *fpriv = file_priv->driver_priv;
struct radeon_vm *vm = &fpriv->vm;
+ int r;
if (rdev->family < CHIP_CAYMAN) {
return;
}
- if (radeon_bo_reserve(rbo, false)) {
- dev_err(rdev->dev, "leaking bo va because we fail to reserve
bo\n");
+ r = radeon_bo_reserve(rbo, true);
+ if (r) {
+ dev_err(rdev->dev, "leaking bo va because "
+ "we fail to reserve bo (%d)\n", r);
return;
}
radeon_vm_bo_rmv(rdev, vm, rbo);
--
1.7.9.5
[PATCH 7/8] drm/radeon: remove radeon_bo_clear_va
It is unnecessary when we remove the va in drm_close.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 8d23b7e..d210fe5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -46,16 +46,6 @@ static void radeon_bo_clear_surface_reg(struct radeon_bo
*bo);
* function are calling it.
*/
-void radeon_bo_clear_va(struct radeon_bo *bo)
-{
- struct radeon_bo_va *bo_va, *tmp;
-
- list_for_each_entry_safe(bo_va, tmp, &bo->va, bo_list) {
- /* remove from all vm address space */
- radeon_vm_bo_rmv(bo->rdev, bo_va->vm, bo);
- }
-}
-
static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
{
struct radeon_bo *bo;
@@ -65,7 +55,6 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object
*tbo)
list_del_init(&bo->list);
mutex_unlock(&bo->rdev->gem.mutex);
radeon_bo_clear_surface_reg(bo);
- radeon_bo_clear_va(bo);
drm_gem_object_release(&bo->gem_base);
kfree(bo);
}
--
1.7.9.5
[PATCH 8/8] drm/radeon: rework the VM code a bit more
Roughly based on how nouveau is handling it. Instead of
adding the bo_va when the address is set add the bo_va
when the handle is opened, but set the address to zero
until userspace tells us where to place it.
This fixes another bunch of problems with glamor.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 30 ---
drivers/gpu/drm/radeon/radeon_gart.c | 147 ++
drivers/gpu/drm/radeon/radeon_gem.c | 47 +--
3 files changed, 153 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8cca1d2..4d67f0f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -292,17 +292,20 @@ struct radeon_mman {
/* bo virtual address in a specific vm */
struct radeon_bo_va {
- /* bo list is protected by bo being reserved */
+ /* protected by bo being reserved */
struct list_headbo_list;
- /* vm list is protected by vm mutex */
- struct list_headvm_list;
- /* constant after initialization */
- struct radeon_vm*vm;
- struct radeon_bo*bo;
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
boolvalid;
+ unsignedref_count;
+
+ /* protected by vm mutex */
+ struct list_headvm_list;
+
+ /* constant after initialization */
+ struct radeon_vm*vm;
+ struct radeon_bo*bo;
};
struct radeon_bo {
@@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,
struct radeon_bo *bo);
struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
struct radeon_bo *bo);
-int radeon_vm_bo_add(struct radeon_device *rdev,
-struct radeon_vm *vm,
-struct radeon_bo *bo,
-uint64_t offset,
-uint32_t flags);
+struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
+ struct radeon_vm *vm,
+ struct radeon_bo *bo);
+int radeon_vm_bo_set_addr(struct radeon_device *rdev,
+ struct radeon_bo_va *bo_va,
+ uint64_t offset,
+ uint32_t flags);
int radeon_vm_bo_rmv(struct radeon_device *rdev,
-struct radeon_vm *vm,
-struct radeon_bo *bo);
+struct radeon_bo_va *bo_va);
/* audio */
void r600_audio_update_hdmi(struct work_struct *work);
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2c59491..2f28ff3 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -693,51 +693,83 @@ struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm
*vm,
* @rdev: radeon_device pointer
* @vm: requested vm
* @bo: radeon buffer object
- * @offset: requested offset of the buffer in the VM address space
- * @flags: attributes of pages (read/write/valid/etc.)
*
* Add @bo into the requested vm (cayman+).
- * Add @bo to the list of bos associated with the vm and validate
- * the offset requested within the vm address space.
- * Returns 0 for success, error for failure.
+ * Add @bo to the list of bos associated with the vm
+ * Returns newly added bo_va or NULL for failure
*
* Object has to be reserved!
*/
-int radeon_vm_bo_add(struct radeon_device *rdev,
-struct radeon_vm *vm,
-struct radeon_bo *bo,
-uint64_t offset,
-uint32_t flags)
+struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
+ struct radeon_vm *vm,
+ struct radeon_bo *bo)
{
- struct radeon_bo_va *bo_va, *tmp;
- struct list_head *head;
- uint64_t size = radeon_bo_size(bo), last_offset = 0;
- unsigned last_pfn;
+ struct radeon_bo_va *bo_va;
bo_va = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
if (bo_va == NULL) {
- return -ENOMEM;
+ return NULL;
}
bo_va->vm = vm;
bo_va->bo = bo;
- bo_va->soffset = offset;
- bo_va->eoffset = offset + size;
- bo_va->flags = flags;
+ bo_va->soffset = 0;
+ bo_va->eoffset = 0;
+ bo_va->flags = 0;
bo_va->valid = false;
+ bo_va->ref_count = 1;
INIT_LIST_HEAD(&bo_va->bo_list);
INIT_LIST_HEAD(&bo_va->vm_list);
- /* make sure object fit at this offset */
- if (bo_va->soffset >= bo_va->eoffset) {
- kfree(bo_va);
- return -EINVAL;
- }
- las
[Bug 40495] r300 performance is slower on sleep resume
https://bugs.freedesktop.org/show_bug.cgi?id=40495 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/r300|Drivers/Gallium/r300 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[pull] drm-intel-fixes
On Mon, Sep 10, 2012 at 09:34:36PM +0200, Daniel Vetter wrote: > On Mon, Sep 10, 2012 at 09:28:17AM +0200, Daniel Vetter wrote: > > Hi Dave, > > > > You're pull just reminded me that I've been sitting on a few small -fixes, > > too. Nothing really major at all: > > - fixup edp setup sequence (Dave) > > - disable sdvo hotplug for real, this is a fixup for a messed-up > > regression fixer (Jani) > > - don't expose dysfunctional backlight driver (Jani) > > - properly init spinlock (only used by hsw/vlv code) from Alexander > > Shishkin > > Added one more: > - fix a regression in the gen3 pageflip complete irq handling after resume > (only affects some configurations, we've forgotten to restore a reg > value). And another small patch to shut up an overzealous WARN. The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 75c5da279e06577190abba52cabf0dc2a56edb97: drm/i915: fix up the IBX transcoder B check (2012-09-11 17:25:14 +0200) Alexander Shishkin (1): drm/i915: initialize dpio_lock spin lock Daniel Vetter (2): drm/i915: set the right gen3 flip_done mode also at resume drm/i915: fix up the IBX transcoder B check Dave Airlie (1): drm/i915/edp: get the panel delay before powering up Jani Nikula (2): drm/i915: only enable sdvo hotplug irq if needed drm/i915: do not expose a dysfunctional backlight interface to userspace drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_irq.c |3 --- drivers/gpu/drm/i915/intel_display.c |6 -- drivers/gpu/drm/i915/intel_dp.c | 11 +++ drivers/gpu/drm/i915/intel_panel.c | 31 ++- drivers/gpu/drm/i915/intel_pm.c |3 +++ drivers/gpu/drm/i915/intel_sdvo.c| 15 ++- 7 files changed, 43 insertions(+), 27 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 54662] [bisected] Kernel 3.6 breaks KMS on Radeon RV530 (black screen)
https://bugs.freedesktop.org/show_bug.cgi?id=54662 --- Comment #5 from Tony Thomas 2012-09-11 15:52:36 UTC --- (In reply to comment #4) > (In reply to comment #1) > > Recent Ubuntu versions don't come with an xorg.conf file, and "sudo Xorg > -configure" reports a fatal error, so I'm not sure how to generate a base file > to tweak. > Recent versions of Ubuntu (and others) allow for snippets of Xorg.conf in either /etc/X11/xorg.conf.d, or (as in Ubuntu) /usr/share/X11/xorg.conf.d. Just make a new file, and add a section such as this: #vi 50-mydevice.conf Section "Device" Identifier "my-radeon-card" Option "NoAccel" "TRUE" EndSection -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 47321] crash with drm/radeon on hp dm1 4100ed laptop with amd 6320
https://bugzilla.kernel.org/show_bug.cgi?id=47321 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||DOCUMENTED --- Comment #11 from Alan 2012-09-11 16:00:10 --- The firmware loading behaviour for the ke -- 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/radeon: make 64bit fences more robust
On Tue, Sep 11, 2012 at 6:23 AM, Michel D?nzer wrote: > On Die, 2012-09-11 at 12:11 +0200, Christian K?nig wrote: >> >> How about this idea: Instead of increasing the upper 32bits we just use >> the upper 32bits of the last emitted fence value? >> E.g. see the attached patch. That both should handle random zero and out >> of order values more gracefully. > > I like this idea. > Yeah this patch is better. Cheers, Jerome
[PATCH 8/8] drm/radeon: rework the VM code a bit more
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> Roughly based on how nouveau is handling it. Instead of
> adding the bo_va when the address is set add the bo_va
> when the handle is opened, but set the address to zero
> until userspace tells us where to place it.
>
> This fixes another bunch of problems with glamor.
What exactly are the fix ? I don't see why this change is needed. It
make things more complicated in my view.
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon.h | 30 ---
> drivers/gpu/drm/radeon/radeon_gart.c | 147
> ++
> drivers/gpu/drm/radeon/radeon_gem.c | 47 +--
> 3 files changed, 153 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 8cca1d2..4d67f0f 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -292,17 +292,20 @@ struct radeon_mman {
>
> /* bo virtual address in a specific vm */
> struct radeon_bo_va {
> - /* bo list is protected by bo being reserved */
> + /* protected by bo being reserved */
> struct list_headbo_list;
> - /* vm list is protected by vm mutex */
> - struct list_headvm_list;
> - /* constant after initialization */
> - struct radeon_vm*vm;
> - struct radeon_bo*bo;
> uint64_tsoffset;
> uint64_teoffset;
> uint32_tflags;
> boolvalid;
> + unsignedref_count;
unsigned refcount is a recipe for failure, if somehow you over unref
then you va will stay alive forever and this overunref will probably
go unnoticed.
> +
> + /* protected by vm mutex */
> + struct list_headvm_list;
> +
> + /* constant after initialization */
> + struct radeon_vm*vm;
> + struct radeon_bo*bo;
> };
>
> struct radeon_bo {
> @@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct radeon_device
> *rdev,
> struct radeon_bo *bo);
> struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
>struct radeon_bo *bo);
> -int radeon_vm_bo_add(struct radeon_device *rdev,
> -struct radeon_vm *vm,
> -struct radeon_bo *bo,
> -uint64_t offset,
> -uint32_t flags);
> +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
> + struct radeon_vm *vm,
> + struct radeon_bo *bo);
> +int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> + struct radeon_bo_va *bo_va,
> + uint64_t offset,
> + uint32_t flags);
> int radeon_vm_bo_rmv(struct radeon_device *rdev,
> -struct radeon_vm *vm,
> -struct radeon_bo *bo);
> +struct radeon_bo_va *bo_va);
>
> /* audio */
> void r600_audio_update_hdmi(struct work_struct *work);
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 2c59491..2f28ff3 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -693,51 +693,83 @@ struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm
> *vm,
> * @rdev: radeon_device pointer
> * @vm: requested vm
> * @bo: radeon buffer object
> - * @offset: requested offset of the buffer in the VM address space
> - * @flags: attributes of pages (read/write/valid/etc.)
> *
> * Add @bo into the requested vm (cayman+).
> - * Add @bo to the list of bos associated with the vm and validate
> - * the offset requested within the vm address space.
> - * Returns 0 for success, error for failure.
> + * Add @bo to the list of bos associated with the vm
> + * Returns newly added bo_va or NULL for failure
> *
> * Object has to be reserved!
> */
> -int radeon_vm_bo_add(struct radeon_device *rdev,
> -struct radeon_vm *vm,
> -struct radeon_bo *bo,
> -uint64_t offset,
> -uint32_t flags)
> +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
> + struct radeon_vm *vm,
> + struct radeon_bo *bo)
> {
> - struct radeon_bo_va *bo_va, *tmp;
> - struct list_head *head;
> - uint64_t size = radeon_bo_size(bo), last_offset = 0;
> - unsigned last_pfn;
> + struct radeon_bo_va *bo_va;
>
> bo_va = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
> if (bo_va == NULL) {
> - return -ENOMEM;
> + return NULL;
> }
> bo_v
[PATCH 7/8] drm/radeon: remove radeon_bo_clear_va
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> It is unnecessary when we remove the va in drm_close.
>
> Signed-off-by: Christian K?nig
NAK there is case for which drm_close is not call like ib pool and
other iirc. This clear va is really a safety net.
> ---
> drivers/gpu/drm/radeon/radeon_object.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 8d23b7e..d210fe5 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -46,16 +46,6 @@ static void radeon_bo_clear_surface_reg(struct radeon_bo
> *bo);
> * function are calling it.
> */
>
> -void radeon_bo_clear_va(struct radeon_bo *bo)
> -{
> - struct radeon_bo_va *bo_va, *tmp;
> -
> - list_for_each_entry_safe(bo_va, tmp, &bo->va, bo_list) {
> - /* remove from all vm address space */
> - radeon_vm_bo_rmv(bo->rdev, bo_va->vm, bo);
> - }
> -}
> -
> static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
> {
> struct radeon_bo *bo;
> @@ -65,7 +55,6 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object
> *tbo)
> list_del_init(&bo->list);
> mutex_unlock(&bo->rdev->gem.mutex);
> radeon_bo_clear_surface_reg(bo);
> - radeon_bo_clear_va(bo);
> drm_gem_object_release(&bo->gem_base);
> kfree(bo);
> }
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/radeon: fix gem_close_object handling
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> Make the reserve non interruptible.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gem.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 6cac5cc..cfad667 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -134,13 +134,16 @@ void radeon_gem_object_close(struct drm_gem_object *obj,
> struct radeon_device *rdev = rbo->rdev;
> struct radeon_fpriv *fpriv = file_priv->driver_priv;
> struct radeon_vm *vm = &fpriv->vm;
> + int r;
>
> if (rdev->family < CHIP_CAYMAN) {
> return;
> }
>
> - if (radeon_bo_reserve(rbo, false)) {
> - dev_err(rdev->dev, "leaking bo va because we fail to reserve
> bo\n");
> + r = radeon_bo_reserve(rbo, true);
> + if (r) {
> + dev_err(rdev->dev, "leaking bo va because "
> + "we fail to reserve bo (%d)\n", r);
> return;
> }
> radeon_vm_bo_rmv(rdev, vm, rbo);
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/radeon: let bo_reserve take no_intr instead of no_wait param
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> The no_wait param isn't used anywhere, and actually isn't
> very usefull at all.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_object.c |7 +++
> drivers/gpu/drm/radeon/radeon_object.h |2 +-
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 2844e0b..8d23b7e 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -627,18 +627,17 @@ int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
> bool no_wait)
> /**
> * radeon_bo_reserve - reserve bo
> * @bo:bo structure
> - * @no_wait: don't sleep while trying to reserve (return -EBUSY)
> + * @no_intr: don't return -ERESTARTSYS on pending signal
> *
> * Returns:
> - * -EBUSY: buffer is busy and @no_wait is true
> * -ERESTARTSYS: A wait for the buffer to become unreserved was interrupted
> by
> * a signal. Release all buffer reservations and return to user-space.
> */
> -int radeon_bo_reserve(struct radeon_bo *bo, bool no_wait)
> +int radeon_bo_reserve(struct radeon_bo *bo, bool no_intr)
> {
> int r;
>
> - r = ttm_bo_reserve(&bo->tbo, true, no_wait, false, 0);
> + r = ttm_bo_reserve(&bo->tbo, !no_intr, false, false, 0);
> if (unlikely(r != 0)) {
> if (r != -ERESTARTSYS)
> dev_err(bo->rdev->dev, "%p reserve failed\n", bo);
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
> b/drivers/gpu/drm/radeon/radeon_object.h
> index 2aaf6e3..93cd491 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -52,7 +52,7 @@ static inline unsigned radeon_mem_type_to_domain(u32
> mem_type)
> return 0;
> }
>
> -int radeon_bo_reserve(struct radeon_bo *bo, bool no_wait);
> +int radeon_bo_reserve(struct radeon_bo *bo, bool no_intr);
>
> static inline void radeon_bo_unreserve(struct radeon_bo *bo)
> {
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/radeon: fix VA overlap check
On Tue, Sep 11, 2012 at 10:09 AM, Christian K?nig
wrote:
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gart.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 614e31a..5694421 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -736,7 +736,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
> /* bo can be added before this one */
> break;
> }
> - if (bo_va->soffset >= tmp->soffset && bo_va->soffset <
> tmp->eoffset) {
> + if (bo_va->eoffset > tmp->soffset && bo_va->soffset <
> tmp->eoffset) {
> /* bo and tmp overlap, invalid offset */
> dev_err(rdev->dev, "bo %p va 0x%08X conflict with (bo
> %p 0x%08X 0x%08X)\n",
> bo, (unsigned)bo_va->soffset, tmp->bo,
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/radeon: move and rename radeon_bo_va function
On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
wrote:
> It doesn't really belong into the object functions,
> also rename it to avoid collisions with struct radeon_bo_va.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon.h|2 ++
> drivers/gpu/drm/radeon/radeon_gart.c | 34
>
> drivers/gpu/drm/radeon/radeon_gem.c|2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 13
> drivers/gpu/drm/radeon/radeon_object.h |2 --
> 5 files changed, 33 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 55f17f9..8cca1d2 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1846,6 +1846,8 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
> struct ttm_mem_reg *mem);
> void radeon_vm_bo_invalidate(struct radeon_device *rdev,
> struct radeon_bo *bo);
> +struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
> + struct radeon_bo *bo);
> int radeon_vm_bo_add(struct radeon_device *rdev,
> struct radeon_vm *vm,
> struct radeon_bo *bo,
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 1b1c001..2c59491 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -662,7 +662,31 @@ void radeon_vm_fence(struct radeon_device *rdev,
> vm->fence = radeon_fence_ref(fence);
> }
>
> -/* object have to be reserved */
> +/**
> + * radeon_vm_bo_find - find the bo_va for a specific vm & bo
> + *
> + * @vm: requested vm
> + * @bo: requested buffer object
> + *
> + * Find @bo inside the requested vm (cayman+).
> + * Search inside the @bos vm list for the requested vm
> + * Returns the found bo_va or NULL if none is found
> + *
> + * Object has to be reserved!
> + */
> +struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
> + struct radeon_bo *bo)
> +{
> + struct radeon_bo_va *bo_va;
> +
> + list_for_each_entry(bo_va, &bo->va, bo_list) {
> + if (bo_va->vm == vm) {
> + return bo_va;
> + }
> + }
> + return NULL;
> +}
> +
> /**
> * radeon_vm_bo_add - add a bo to a specific vm
> *
> @@ -676,6 +700,8 @@ void radeon_vm_fence(struct radeon_device *rdev,
> * Add @bo to the list of bos associated with the vm and validate
> * the offset requested within the vm address space.
> * Returns 0 for success, error for failure.
> + *
> + * Object has to be reserved!
> */
> int radeon_vm_bo_add(struct radeon_device *rdev,
> struct radeon_vm *vm,
> @@ -823,7 +849,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
> if (vm->sa_bo == NULL)
> return 0;
>
> - bo_va = radeon_bo_va(bo, vm);
> + bo_va = radeon_vm_bo_find(vm, bo);
> if (bo_va == NULL) {
> dev_err(rdev->dev, "bo %p not in vm %p\n", bo, vm);
> return -EINVAL;
> @@ -912,7 +938,7 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
> struct radeon_bo_va *bo_va;
> int r;
>
> - bo_va = radeon_bo_va(bo, vm);
> + bo_va = radeon_vm_bo_find(vm, bo);
> if (bo_va == NULL)
> return 0;
>
> @@ -1009,7 +1035,7 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
> radeon_vm *vm)
> */
> r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
> if (!r) {
> - bo_va = radeon_bo_va(rdev->ring_tmp_bo.bo, vm);
> + bo_va = radeon_vm_bo_find(vm, rdev->ring_tmp_bo.bo);
> list_del_init(&bo_va->bo_list);
> list_del_init(&bo_va->vm_list);
> radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 1b57b00..6cac5cc 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -461,7 +461,7 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void
> *data,
> }
> switch (args->operation) {
> case RADEON_VA_MAP:
> - bo_va = radeon_bo_va(rbo, &fpriv->vm);
> + bo_va = radeon_vm_bo_find(&fpriv->vm, rbo);
> if (bo_va) {
> args->operation = RADEON_VA_RESULT_VA_EXIST;
> args->offset = bo_va->soffset;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 9024e72..2844e0b 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -646,16 +646,3 @@ int radeon_bo_reserve(struct radeon_bo *bo, bool no_wait)
> }
> return 0;
> }
> -
[PATCH 1/8] drm/radeon: fix VA range check
On Tue, Sep 11, 2012 at 10:09 AM, Christian K?nig
wrote:
> The end offset is exclusive not inclusive.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_gart.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index d7bd46b..614e31a 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -732,7 +732,7 @@ int radeon_vm_bo_add(struct radeon_device *rdev,
> head = &vm->va;
> last_offset = 0;
> list_for_each_entry(tmp, &vm->va, vm_list) {
> - if (bo_va->soffset >= last_offset && bo_va->eoffset <
> tmp->soffset) {
> + if (bo_va->soffset >= last_offset && bo_va->eoffset <=
> tmp->soffset) {
> /* bo can be added before this one */
> break;
> }
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/radeon: move IB pool to 1MB offset
On Tue, Sep 11, 2012 at 10:09 AM, Christian K?nig
wrote:
> Even GPUs can have a null pointer dereference, so move
> the IB pool to another offset to catch those.
Reviewed-by: Jerome Glisse
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon.h |1 +
> drivers/gpu/drm/radeon/radeon_gart.c |2 +-
> drivers/gpu/drm/radeon/radeon_ring.c |6 +++---
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index d48bd30..55f17f9 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -123,6 +123,7 @@ extern int radeon_lockup_timeout;
> #define CAYMAN_RING_TYPE_CP2_INDEX 2
>
> /* hardcode those limit for now */
> +#define RADEON_VA_IB_OFFSET(1 << 20)
> #define RADEON_VA_RESERVED_SIZE(8 << 20)
> #define RADEON_IB_VM_MAX_SIZE (64 << 10)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 5694421..1b1c001 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -980,7 +980,7 @@ int radeon_vm_init(struct radeon_device *rdev, struct
> radeon_vm *vm)
> /* map the ib pool buffer at 0 in virtual address space, set
> * read only
> */
> - r = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo, 0,
> + r = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo,
> RADEON_VA_IB_OFFSET,
> RADEON_VM_PAGE_READABLE |
> RADEON_VM_PAGE_SNOOPED);
> return r;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 993cf71..d90b0bc 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -79,10 +79,10 @@ int radeon_ib_get(struct radeon_device *rdev, int ring,
> ib->ptr = radeon_sa_bo_cpu_addr(ib->sa_bo);
> ib->vm = vm;
> if (vm) {
> - /* ib pool is bind at 0 in virtual address space,
> -* so gpu_addr is the offset inside the pool bo
> + /* ib pool is bound at RADEON_VA_IB_OFFSET in virtual address
> +* space and soffset is the offset inside the pool bo
> */
> - ib->gpu_addr = ib->sa_bo->soffset;
> + ib->gpu_addr = ib->sa_bo->soffset + RADEON_VA_IB_OFFSET;
> } else {
> ib->gpu_addr = radeon_sa_bo_gpu_addr(ib->sa_bo);
> }
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #7 from Andreas Boll 2012-09-11 17:12:41 UTC --- Created attachment 66984 --> https://bugs.freedesktop.org/attachment.cgi?id=66984 captured shader I have tested your modified fp-tri-c from attachment 32446 with r600g on my rv770 . I got the following output with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4: $ ./fp-tri -fps foo2.arb !!ARBfp1.0 TEX result.color, 0.498046860099, texture[0], 2D; END GL_RENDERER = Gallium 0.4 on AMD RV770 glGetError = 0x0 12850 frames in 5.0 seconds = 2570.000 FPS Additionally I have attached a screen shot from the shader. What is the expected behavior? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 --- Comment #8 from Alex Deucher 2012-09-11 17:23:43 UTC --- might be fixed with this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f44bda17f515c411071ca8744ebd96039d9c583b -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26641] RV730 agp xf86-video-ati with kms poor performance
https://bugs.freedesktop.org/show_bug.cgi?id=26641 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Andreas Boll 2012-09-11 17:32:55 UTC --- (In reply to comment #15) > (In reply to comment #14) > > > The further commits to drt may have regressed this again - I can't be sure > > as I > > can't run todays head, but while bisecting for - > > > > https://bugs.freedesktop.org/show_bug.cgi?id=27536 > > > > I noticed on the "goods" close to the problematic commit that x11 putimage > > perf > > had regressed. > > That bug is fixed now and the perf with todays drt is OK, so as far as I am > concerned this bug is fixed. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27937] 0ad: SEGV in r700_assembler.c next_ins() with RV670 kms
https://bugs.freedesktop.org/show_bug.cgi?id=27937 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Summary|SEGV in r700_assembler.c|0ad: SEGV in |next_ins() with RV670 kms |r700_assembler.c next_ins() ||with RV670 kms --- Comment #10 from Andreas Boll 2012-09-11 17:47:22 UTC --- Note: classic r600 driver has been abandoned. 0ad works fine with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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: make buffer management work without DRM_MASTER
DRM users should be able to create/destroy/manage dumb- and frame-buffers
without DRM_MASTER. These ioctls do not affect modesetting so there is no
reason to protect them by drm-master. Particularly, destroying buffers
should always be possible as a client has only access to buffers that they
created. Hence, there is no reason to prevent a client from destroying the
buffers, considering a simple close() would destroy them, anyway.
Furthermore, a display-server currently cannot shutdown correctly if it
does not have DRM_MASTER. If some other display-server becomes active (or
the kernel console), then the background display-server is unable to
destroy its buffers.
Under special curcumstances (like monitor reconfiguration) this might even
happen during runtime.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..1490e76 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -156,14 +156,14 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY,
drm_mode_connector_property_set_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES,
drm_mode_obj_get_properties_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY,
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
};
--
1.7.12
[Bug 51344] massive corruption on RV410
https://bugs.freedesktop.org/show_bug.cgi?id=51344 --- Comment #10 from Tormod Volden 2012-09-11 18:42:32 UTC --- Created attachment 66986 --> https://bugs.freedesktop.org/attachment.cgi?id=66986 backport of Christian's v2 patch I tried backporting the v2 patch from http://lists.freedesktop.org/archives/dri-devel/2012-September/027608.html to kernel 3.5.2, see attached, but it did not help either. Maybe my card has another issue? Output from /sys/kernel/debug/dri/0/radeon_fence_info --- ring 0 --- Last signaled fence 0xdeadbeef Last emitted 0x0670 --- ring 0 --- Last signaled fence 0xdeadbeef Last emitted 0x0c44 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC 0/9] nuclear pageflip
On Sun, 9 Sep 2012 22:19:59 -0500
Rob Clark wrote:
> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > This is following a bit the approach that Ville is taking for atomic-
> > modeset, in that it is switching over to using properties for everything.
> > The advantage of this approach is that it makes it easier to add new
> > attributes to set as part of a page-flip (and even opens the option to
> > add new object types).
>
> oh, and for those wondering what the hell this is all about,
> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
> and zero or more attached plane layers, optionally changing various
> properties such as z-order (or even blending modes, etc) atomically.
> It includes the option for a test step so userspace compositor can
> test a proposed configuration (if any properties not marked as
> 'dynamic' are updated). This intended to allow, for example, weston
> compositor to synchronize updates to plane (sprite) layers with CRTC
> layer.
>
Can we please name this something different? I complained about this in
IRC, but I don't know if you hang around in #intel-gfx.
Some suggestions:
multiplane pageflip
muliplane atomic pageflip
atomic multiplane pageflip
atomic multiflip
pageflip of atomic and multiplane nature
Nuclear is not at all descriptive and requires as your response shows
:-)
> BR,
> -R
>
> > The basic principles are:
> > a) split out object state (in this case, plane and crtc, although I
> > expect more to be added as atomic-modeset is added) into seperate
> > structures that can be atomically commited or rolled back
> > b) expand the object property API (set_property()) to take a state
> > object. The obj->set_property() simply updates the state object
> > without actually applying the changes to the hw.
> > c) after all the property updates are done, the updated state can
> > be checked for correctness and against the hw capabilities, and
> > then either discarded or committed atomically.
> >
> > Since we need to include properties in the nuclear-pageflip scheme,
> > doing everything via properties avoids updating a bunch of additional
> > driver provided callbacks. Instead we just drop crtc->page_flip()
> > and plane->update_plane(). By splitting out the object's mutable
> > state into drm_{plane,crtc,etc}_state structs (which are wrapped by
> > the individual drivers to add their own hw specific state), we can
> > use some helpers (drm_{plane,crtc,etc}_set_property() and
> > drm_{plane,crtc,etc}_check_state()) to keep core error checking in
> > drm core and avoid pushing the burden of dealing with common
> > properties to the individual drivers.
> >
> > So far, I've only updated omapdrm to the new APIs, as a proof of
> > concept. Only a few drivers support drm plane, so I expect the
> > updates to convert drm-plane to properties should not be so hard.
> > Possibly for crtc/pageflip we might need to have a transition period
> > where we still support crtc->page_flip() code path until all drivers
> > are updated.
> >
> > My complete branch is here:
> >
> > https://github.com/robclark/kernel-omap4/commits/drm_nuclear
> > git://github.com/robclark/kernel-omap4.git drm_nuclear
> >
> > Rob Clark (9):
> > drm: add atomic fxns
> > drm: add object property type
> > drm: add DRM_MODE_PROP_DYNAMIC property flag
> > drm: convert plane to properties
> > drm: add drm_plane_state
> > drm: convert page_flip to properties
> > drm: add drm_crtc_state
> > drm: nuclear pageflip
> > drm/omap: update for atomic age
> >
> > drivers/gpu/drm/drm_crtc.c| 769
> > +++--
> > drivers/gpu/drm/drm_crtc_helper.c | 51 +--
> > drivers/gpu/drm/drm_drv.c |1 +
> > drivers/gpu/drm/drm_fb_helper.c | 11 +-
> > drivers/staging/omapdrm/Makefile |1 +
> > drivers/staging/omapdrm/omap_atomic.c | 270
> > drivers/staging/omapdrm/omap_atomic.h | 52 +++
> > drivers/staging/omapdrm/omap_crtc.c | 247 +--
> > drivers/staging/omapdrm/omap_drv.c|5 +
> > drivers/staging/omapdrm/omap_drv.h| 35 +-
> > drivers/staging/omapdrm/omap_fb.c | 44 +-
> > drivers/staging/omapdrm/omap_plane.c | 270 ++--
> > include/drm/drm.h |2 +
> > include/drm/drmP.h| 32 ++
> > include/drm/drm_crtc.h| 140 --
> > include/drm/drm_mode.h| 48 ++
> > 16 files changed, 1378 insertions(+), 600 deletions(-)
> > create mode 100644 drivers/staging/omapdrm/omap_atomic.c
> > create mode 100644 drivers/staging/omapdrm/omap_atomic.h
> >
> > --
> > 1.7.9.5
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ben Widawsky, Intel Open Source Technology Center
runtime PM and special power switches
Hi, On Tuesday, September 11, 2012, Dave Airlie wrote: > Hi Rafael, > > I've been investigating runtime PM support for some use-cases on GPUs. > > In some laptops we have a secondary GPU (optimus) that can be powered > up for certain 3D tasks and then turned off when finished with. Now I > did an initial pass on supporting it without using the kernel runtime > PM stuff, but Alan said I should take a look so here I am. Alan Stern or Alan Cox? :-) > While I've started to get a handle on things, we have a bit of an > extra that I'm not sure we cater for. > > Currently we get called from the PCI layer which after we are finished > with our runtime suspend callback, will go put the device into the > correct state etc, however on these optimus/powerxpress laptops we > have a separate ACPI or platform driver controlled power switch that > we need to call once the PCI layer is finished the job. This switch > effectively turns the power to the card completely off leaving it > drawing no power. > > No we can't hit the switch from the driver callback as the PCI layer > will get lost, so I'm wondering how you'd envisage we could plug this > in. Hmm. In principle we might modify pci_pm_runtime_suspend() so that it doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is set. That would actually make it work in analogy with pci_pm_suspend_noirq(), so perhaps it's not even too dangerous. Thanks, Rafael
runtime PM and special power switches
On Tue, 11 Sep 2012, Rafael J. Wysocki wrote: > Hi, > > On Tuesday, September 11, 2012, Dave Airlie wrote: > > Hi Rafael, > > > > I've been investigating runtime PM support for some use-cases on GPUs. > > > > In some laptops we have a secondary GPU (optimus) that can be powered > > up for certain 3D tasks and then turned off when finished with. Now I > > did an initial pass on supporting it without using the kernel runtime > > PM stuff, but Alan said I should take a look so here I am. > > Alan Stern or Alan Cox? :-) > > > While I've started to get a handle on things, we have a bit of an > > extra that I'm not sure we cater for. > > > > Currently we get called from the PCI layer which after we are finished > > with our runtime suspend callback, will go put the device into the > > correct state etc, however on these optimus/powerxpress laptops we > > have a separate ACPI or platform driver controlled power switch that > > we need to call once the PCI layer is finished the job. This switch > > effectively turns the power to the card completely off leaving it > > drawing no power. > > > > No we can't hit the switch from the driver callback as the PCI layer > > will get lost, so I'm wondering how you'd envisage we could plug this > > in. > > Hmm. In principle we might modify pci_pm_runtime_suspend() so that it > doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is > set. That would actually make it work in analogy with pci_pm_suspend_noirq(), > so perhaps it's not even too dangerous. This sounds more like a job for a power domain. Unless the power switch is already in the device hierarchy as a parent to the PCI device. Alan Stern
[RFC 0/9] nuclear pageflip
On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky wrote:
> On Sun, 9 Sep 2012 22:19:59 -0500
> Rob Clark wrote:
>
>> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark wrote:
>> > From: Rob Clark
>> >
>> > This is following a bit the approach that Ville is taking for atomic-
>> > modeset, in that it is switching over to using properties for everything.
>> > The advantage of this approach is that it makes it easier to add new
>> > attributes to set as part of a page-flip (and even opens the option to
>> > add new object types).
>>
>> oh, and for those wondering what the hell this is all about,
>> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
>> and zero or more attached plane layers, optionally changing various
>> properties such as z-order (or even blending modes, etc) atomically.
>> It includes the option for a test step so userspace compositor can
>> test a proposed configuration (if any properties not marked as
>> 'dynamic' are updated). This intended to allow, for example, weston
>> compositor to synchronize updates to plane (sprite) layers with CRTC
>> layer.
>>
>
> Can we please name this something different? I complained about this in
> IRC, but I don't know if you hang around in #intel-gfx.
>
> Some suggestions:
> multiplane pageflip
> muliplane atomic pageflip
> atomic multiplane pageflip
> atomic multiflip
> pageflip of atomic and multiplane nature
>
> Nuclear is not at all descriptive and requires as your response shows
> :-)
>
fair enough.. I was originally calling it atomic-pageflip until
someone (I don't remember who) started calling it nuclear-pageflip to
differentiate from atomic-modeset. But IMO we could just call the two
ioclts atomic-modeset and atomic-pageflip. (Or even modeset2 and
pageflip2, but that seems much more boring)
BR,
-R
>
>> BR,
>> -R
>>
>> > The basic principles are:
>> > a) split out object state (in this case, plane and crtc, although I
>> > expect more to be added as atomic-modeset is added) into seperate
>> > structures that can be atomically commited or rolled back
>> > b) expand the object property API (set_property()) to take a state
>> > object. The obj->set_property() simply updates the state object
>> > without actually applying the changes to the hw.
>> > c) after all the property updates are done, the updated state can
>> > be checked for correctness and against the hw capabilities, and
>> > then either discarded or committed atomically.
>> >
>> > Since we need to include properties in the nuclear-pageflip scheme,
>> > doing everything via properties avoids updating a bunch of additional
>> > driver provided callbacks. Instead we just drop crtc->page_flip()
>> > and plane->update_plane(). By splitting out the object's mutable
>> > state into drm_{plane,crtc,etc}_state structs (which are wrapped by
>> > the individual drivers to add their own hw specific state), we can
>> > use some helpers (drm_{plane,crtc,etc}_set_property() and
>> > drm_{plane,crtc,etc}_check_state()) to keep core error checking in
>> > drm core and avoid pushing the burden of dealing with common
>> > properties to the individual drivers.
>> >
>> > So far, I've only updated omapdrm to the new APIs, as a proof of
>> > concept. Only a few drivers support drm plane, so I expect the
>> > updates to convert drm-plane to properties should not be so hard.
>> > Possibly for crtc/pageflip we might need to have a transition period
>> > where we still support crtc->page_flip() code path until all drivers
>> > are updated.
>> >
>> > My complete branch is here:
>> >
>> > https://github.com/robclark/kernel-omap4/commits/drm_nuclear
>> > git://github.com/robclark/kernel-omap4.git drm_nuclear
>> >
>> > Rob Clark (9):
>> > drm: add atomic fxns
>> > drm: add object property type
>> > drm: add DRM_MODE_PROP_DYNAMIC property flag
>> > drm: convert plane to properties
>> > drm: add drm_plane_state
>> > drm: convert page_flip to properties
>> > drm: add drm_crtc_state
>> > drm: nuclear pageflip
>> > drm/omap: update for atomic age
>> >
>> > drivers/gpu/drm/drm_crtc.c| 769
>> > +++--
>> > drivers/gpu/drm/drm_crtc_helper.c | 51 +--
>> > drivers/gpu/drm/drm_drv.c |1 +
>> > drivers/gpu/drm/drm_fb_helper.c | 11 +-
>> > drivers/staging/omapdrm/Makefile |1 +
>> > drivers/staging/omapdrm/omap_atomic.c | 270
>> > drivers/staging/omapdrm/omap_atomic.h | 52 +++
>> > drivers/staging/omapdrm/omap_crtc.c | 247 +--
>> > drivers/staging/omapdrm/omap_drv.c|5 +
>> > drivers/staging/omapdrm/omap_drv.h| 35 +-
>> > drivers/staging/omapdrm/omap_fb.c | 44 +-
>> > drivers/staging/omapdrm/omap_plane.c | 270 ++--
>> > include/drm/drm.h |2 +
>> > include/drm/drmP.h| 32 ++
>> > include/drm/drm_crtc.h| 140 --
>> > include/drm/drm_mode.h
Missing GIT tag for mesa v9.0?
On Tue, Sep 11, 2012 at 10:01 AM, Ian Romanick wrote: > On 09/11/2012 09:40 AM, Sedat Dilek wrote: >> >> Hi, >> >> I can't see it in [1], forgotten? > > > Mesa 9.0 hasn't been released yet, so of course there isn't a release tag. > Hi Ian, I had my informations from [1]. As there is a "9.0" GIT branch - and this is normally setup for post-9.0 patches - I assumed these informations are true in the article I read. Regards, - Sedat - [1] http://www.h-online.com/open/features/Kernel-Log-New-tools-and-drivers-1704193.html > >> Regards, >> - Sedat - >> >> [1] http://cgit.freedesktop.org/mesa/mesa/refs/tags > >
Re: [PATCH 3/5] nouveau: Add interface to detect optimus support
Hi Dave,
> +bool nouveau_is_optimus(void) {
> + return nouveau_dsm_priv.optimus_detected;
> +}
This will only work for new Optimus laptops, not the older ones such as your
Lenovo T410s or on a Dell Vostro 3500 with a GT 310M. Is that intended? If
not, check for those models too:
return nouveau_dsm_priv.optimus_detected ||
nouveau_dsm_priv.dsm_detected;
Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] nouveau: add dynamic gpu power off support.
Hi Dave,
> +int nouveau_dynamic_power_set_state(struct drm_device *dev, int state)
> +{
> + struct nouveau_drm *drm = nouveau_drm(dev);
> + pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
> +
> + if (state == DRM_SWITCH_POWER_DYNAMIC_OFF) {
> + dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF;
In existing set_state code, this switch_power_state is first set to
DRM_SWITCH_POWER_CHANGING. Is it sensible to do the same thing here?
> + drm_kms_helper_poll_disable(drm->dev);
> + vga_switcheroo_set_dynamic_switch(dev->pdev,
> VGA_SWITCHEROO_OFF,
false);
> + nouveau_switcheroo_optimus_dsm();
> + nouveau_drm_suspend(drm->dev->pdev, pmm);
> + vga_switcheroo_set_dynamic_switch(dev->pdev,
> VGA_SWITCHEROO_OFF,
true);
> + } else if (state == DRM_SWITCH_POWER_ON) {
> + vga_switcheroo_set_dynamic_switch(dev->pdev, VGA_SWITCHEROO_ON,
true);
> + nouveau_drm_resume(dev->pdev);
> + vga_switcheroo_set_dynamic_switch(dev->pdev, VGA_SWITCHEROO_ON,
false);
> + drm_kms_helper_poll_enable(dev);
> + dev->switch_power_state = DRM_SWITCH_POWER_ON;
Same here.
> + }
> +
> + return 0;
> +}
Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
runtime PM and special power switches
Hi Rafael, I've been investigating runtime PM support for some use-cases on GPUs. In some laptops we have a secondary GPU (optimus) that can be powered up for certain 3D tasks and then turned off when finished with. Now I did an initial pass on supporting it without using the kernel runtime PM stuff, but Alan said I should take a look so here I am. While I've started to get a handle on things, we have a bit of an extra that I'm not sure we cater for. Currently we get called from the PCI layer which after we are finished with our runtime suspend callback, will go put the device into the correct state etc, however on these optimus/powerxpress laptops we have a separate ACPI or platform driver controlled power switch that we need to call once the PCI layer is finished the job. This switch effectively turns the power to the card completely off leaving it drawing no power. No we can't hit the switch from the driver callback as the PCI layer will get lost, so I'm wondering how you'd envisage we could plug this in. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47321] crash with drm/radeon on hp dm1 4100ed laptop with amd 6320
https://bugzilla.kernel.org/show_bug.cgi?id=47321 --- Comment #9 from Marcel Pol 2012-09-11 05:59:30 --- I thought about it for a while. For me personally the bug is fixed. But it should be that if the driver doesn't find the software, then it should degrade gracefully. Maybe not load the driver, or just do nothing. -- 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
Missing GIT tag for mesa v9.0?
Hi, I can't see it in [1], forgotten? Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/refs/tags ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] nouveau: convert to dev_pm_ops
From: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 93 +--
1 file changed, 67 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 9fb56b3..bb51a00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -391,17 +391,12 @@ nouveau_drm_remove(struct pci_dev *pdev)
}
int
-nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t pm_state)
+nouveau_do_suspend(struct drm_device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_cli *cli;
int ret;
- if (dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
- pm_state.event == PM_EVENT_PRETHAW)
- return 0;
-
NV_INFO(drm, "suspending fbcon...\n");
nouveau_fbcon_set_suspend(dev, 1);
@@ -425,13 +420,6 @@ nouveau_drm_suspend(struct pci_dev *pdev, pm_message_t
pm_state)
goto fail_client;
nouveau_agp_fini(drm);
-
- pci_save_state(pdev);
- if (pm_state.event == PM_EVENT_SUSPEND) {
- pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
- }
-
return 0;
fail_client:
@@ -444,24 +432,33 @@ fail_client:
return ret;
}
-int
-nouveau_drm_resume(struct pci_dev *pdev)
+int nouveau_pmops_suspend(struct device *dev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nouveau_cli *cli;
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;
- if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
- NV_INFO(drm, "re-enabling device...\n");
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- ret = pci_enable_device(pdev);
+ ret = nouveau_do_suspend(drm_dev);
if (ret)
return ret;
- pci_set_master(pdev);
+
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+
+ return 0;
+}
+
+int
+nouveau_do_resume(struct drm_device *dev)
+{
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct nouveau_cli *cli;
+
+ NV_INFO(drm, "re-enabling device...\n");
nouveau_agp_reset(drm);
@@ -482,6 +479,42 @@ nouveau_drm_resume(struct pci_dev *pdev)
return 0;
}
+int nouveau_pmops_resume(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ int ret;
+
+ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+ return 0;
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+ pci_set_master(pdev);
+
+ return nouveau_do_resume(drm_dev);
+}
+
+static int nouveau_pmops_freeze(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return nouveau_do_suspend(drm_dev);
+}
+
+static int nouveau_pmops_thaw(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return nouveau_do_resume(drm_dev);
+}
+
+
static int
nouveau_drm_open(struct drm_device *dev, struct drm_file *fpriv)
{
@@ -631,14 +664,22 @@ nouveau_drm_pci_table[] = {
{}
};
+static const struct dev_pm_ops nouveau_pm_ops = {
+ .suspend = nouveau_pmops_suspend,
+ .resume = nouveau_pmops_resume,
+ .freeze = nouveau_pmops_freeze,
+ .thaw = nouveau_pmops_thaw,
+ .poweroff = nouveau_pmops_freeze,
+ .restore = nouveau_pmops_resume,
+};
+
static struct pci_driver
nouveau_drm_pci_driver = {
.name = "nouveau",
.id_table = nouveau_drm_pci_table,
.probe = nouveau_drm_probe,
.remove = nouveau_drm_remove,
- .suspend = nouveau_drm_suspend,
- .resume = nouveau_drm_resume,
+ .driver.pm = &nouveau_pm_ops,
};
static int __init
--
1.7.12
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau runtime PM support (take two)
So I started investigating the kernel runtime PM support as per Alan's suggestion. An API with lots of interface docs and not enough examples :-) So I've mostly implemented autosuspend for nouveau with this, it could still be pushed down a lot further into the code I suspect. Also this doesn't actually turn the power switch off since runtime PM currently have no hook to do that, so it only D3s the GPU. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] nouveau: add runtime PM support (v0.1)
From: Dave Airlie
This adds hook into the system runtime PM support to enable
dynamic PM on the nvidia device.
It doesn't hook into the power switch yet, only D3s the card.
TODO:
keep a reference if we have enabled outputs/framebuffers (??)
keep a reference if we have any requests in flight.
sprinkle mark last busy for autosuspend timeout
Signed-off-by: Dave Airlie
-
+#include
#include "drmP.h"
#include "drm_edid.h"
#include "drm_crtc_helper.h"
@@ -239,6 +239,12 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
struct nouveau_encoder *nv_partner;
struct nouveau_i2c_port *i2c;
int type;
+ int ret;
+ enum drm_connector_status conn_status = connector_status_disconnected;
+
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0)
+ return ret;
/* Cleanup the previous EDID block. */
if (nv_connector->edid) {
@@ -262,7 +268,8 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
!nouveau_dp_detect(to_drm_encoder(nv_encoder))) {
NV_ERROR(drm, "Detected %s, but failed init\n",
drm_get_connector_name(connector));
- return connector_status_disconnected;
+ conn_status = connector_status_disconnected;
+ goto out;
}
/* Override encoder type for DVI-I based on whether EDID
@@ -289,13 +296,15 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
}
nouveau_connector_set_encoder(connector, nv_encoder);
- return connector_status_connected;
+ conn_status = connector_status_connected;
+ goto out;
}
nv_encoder = nouveau_connector_of_detect(connector);
if (nv_encoder) {
nouveau_connector_set_encoder(connector, nv_encoder);
- return connector_status_connected;
+ conn_status = connector_status_connected;
+ goto out;
}
detect_analog:
@@ -310,12 +319,18 @@ detect_analog:
if (helper->detect(encoder, connector) ==
connector_status_connected) {
nouveau_connector_set_encoder(connector, nv_encoder);
- return connector_status_connected;
+ conn_status = connector_status_connected;
+ goto out;
}
}
- return connector_status_disconnected;
+ out:
+
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+
+ return conn_status;
}
static enum drm_connector_status
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index bb51a00..63b1b7c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -25,7 +25,10 @@
#include
#include
#include
-
+#include
+#include
+#include "drmP.h"
+#include "drm_crtc_helper.h"
#include
#include
#include
@@ -334,6 +337,13 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
nouveau_accel_init(drm);
nouveau_fbcon_init(dev);
+
+ pm_runtime_use_autosuspend(dev->dev);
+ pm_runtime_set_autosuspend_delay(dev->dev, 5000);
+ pm_runtime_set_active(dev->dev);
+ pm_runtime_allow(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
+ pm_runtime_mark_last_busy(dev->dev);
return 0;
fail_dispinit:
@@ -349,6 +359,7 @@ fail_ttm:
nouveau_vga_fini(drm);
fail_device:
nouveau_cli_destroy(&drm->client);
+
return ret;
}
@@ -357,6 +368,7 @@ nouveau_drm_unload(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ pm_runtime_get_noresume(dev->dev);
nouveau_fbcon_fini(dev);
nouveau_accel_fini(drm);
@@ -523,16 +535,21 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
struct nouveau_cli *cli;
int ret;
+ /* need to bring up power immediately if opening device */
+ ret = pm_runtime_get_sync(dev->dev);
+ if (ret < 0)
+ return ret;
+
ret = nouveau_cli_create(pdev, fpriv->pid, sizeof(*cli), (void **)&cli);
if (ret)
- return ret;
+ goto out_suspend;
if (nv_device(drm->device)->card_type >= NV_50) {
ret = nouveau_vm_new(nv_device(drm->device), 0, (1ULL << 40),
0x1000, &cli->base.vm);
if (ret) {
nouveau_cli_destroy(cli);
- return ret;
+ goto out_suspend;
}
}
@@ -541,7 +558,12 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
mutex_lock(&drm->c
[PATCH v2] drm/exynos: separeated fimd_power_on into some parts.
Changelog v2:
fix pm operation when resume.
Changelog v1:
this patch separetes fimd_power_on into fimd_activate and fimd_clock and
fimd_activate function will call fimd_clock to control fimd power and
vsync interrupt.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 60 --
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 47396e1..28733cd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -747,16 +747,10 @@ static void fimd_clear_win(struct fimd_context *ctx, int
win)
writel(val, ctx->regs + SHADOWCON);
}
-static int fimd_power_on(struct fimd_context *ctx, bool enable)
+static int fimd_clock(struct fimd_context *ctx, bool enable)
{
- struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
- struct device *dev = subdrv->dev;
-
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (enable != false && enable != true)
- return -EINVAL;
-
if (enable) {
int ret;
@@ -769,18 +763,31 @@ static int fimd_power_on(struct fimd_context *ctx, bool
enable)
clk_disable(ctx->bus_clk);
return ret;
}
+ } else {
+ clk_disable(ctx->lcd_clk);
+ clk_disable(ctx->bus_clk);
+ }
+
+ return 0;
+}
+
+static int fimd_activate(struct fimd_context *ctx, bool enable)
+{
+ if (enable) {
+ int ret;
+ struct device *dev = ctx->subdrv.dev;
+
+ ret = fimd_clock(ctx, true);
+ if (ret < 0)
+ return ret;
ctx->suspended = false;
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, &ctx->irq_flags))
fimd_enable_vblank(dev);
-
- fimd_apply(dev);
} else {
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
-
+ fimd_clock(ctx, false);
ctx->suspended = true;
}
@@ -930,15 +937,15 @@ static int fimd_suspend(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
- if (pm_runtime_suspended(dev))
- return 0;
-
/*
* do not use pm_runtime_suspend(). if pm_runtime_suspend() is
* called here, an error would be returned by that interface
* because the usage_count of pm runtime is more than 1.
*/
- return fimd_power_on(ctx, false);
+ if (!pm_runtime_suspended(dev))
+ return fimd_activate(ctx, false);
+
+ return 0;
}
static int fimd_resume(struct device *dev)
@@ -950,8 +957,21 @@ static int fimd_resume(struct device *dev)
* of pm runtime would still be 1 so in this case, fimd driver
* should be on directly not drawing on pm runtime interface.
*/
- if (!pm_runtime_suspended(dev))
- return fimd_power_on(ctx, true);
+ if (pm_runtime_suspended(dev)) {
+ int ret;
+
+ ret = fimd_activate(ctx, true);
+ if (ret < 0)
+ return ret;
+
+ /*
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
+*/
+ fimd_apply(dev);
+ }
return 0;
}
@@ -964,7 +984,7 @@ static int fimd_runtime_suspend(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, false);
+ return fimd_activate(ctx, false);
}
static int fimd_runtime_resume(struct device *dev)
@@ -973,7 +993,7 @@ static int fimd_runtime_resume(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, true);
+ return fimd_activate(ctx, true);
}
#endif
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35838] Savage2 crashes when running Practice
https://bugs.freedesktop.org/show_bug.cgi?id=35838 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Boll 2012-09-11 07:35:04 UTC --- (In reply to comment #1) > Appears to be fixed in > > 874a2c0b7da62f4dd08dedcec221f55b22e40e95 Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Missing GIT tag for mesa v9.0?
On 09/11/2012 09:40 AM, Sedat Dilek wrote: Hi, I can't see it in [1], forgotten? Mesa 9.0 hasn't been released yet, so of course there isn't a release tag. Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/refs/tags ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: Changes to 'debian-experimental'
On Mon, Sep 10, 2012 at 1:27 AM, Michel Dänzer wrote: > On Son, 2012-09-09 at 15:33 -0700, Jordan Justen wrote: >> New branch 'debian-experimental' available with the following commits: > > I think you pushed this to the wrong repository? My apologies. I had the hook script mis-configured under my personal repo. I don't think the main drm repo was modified. -Jordan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29691] Lightsmark isnt rendering textures
https://bugs.freedesktop.org/show_bug.cgi?id=29691 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:01:43 UTC --- Note: classic r600 driver has been abandoned. texture rendering is fine with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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 26962] fbo/fbo-nodepth-test: Invalid command stream
https://bugs.freedesktop.org/show_bug.cgi?id=26962 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:46:31 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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 27148] Failed assertion in piglit test 'bin/fbo-flushing -auto' with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27148 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Andreas Boll 2012-09-11 09:50:53 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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 27149] Failed assertion in piglit test 'fbo-pbo-readpixels-small -auto' with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27149 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:52:08 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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 27147] piglit "fdo23670-drawpix_stencil -auto" test dumps core with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27147 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 09:53:44 UTC --- Note: classic r600 driver has been abandoned. works correctly with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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: make 64bit fences more robust
On 10.09.2012 18:07, Jerome Glisse wrote:
On Mon, Sep 10, 2012 at 11:52 AM, Jerome Glisse wrote:
On Mon, Sep 10, 2012 at 11:38 AM, Michel Dänzer wrote:
On Mon, 2012-09-10 at 14:02 +0200, Christian König wrote:
On 10.09.2012 13:12, Michel Dänzer wrote:
On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
Only increase the higher 32bits if we really detect a wrap around.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54129
https://bugs.freedesktop.org/show_bug.cgi?id=54662
Possible fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=846505
https://bugzilla.redhat.com/show_bug.cgi?id=845639
Signed-off-by: Christian König
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_fence.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7b737b9..4781e13 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -160,7 +160,7 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
do {
seq = radeon_fence_read(rdev, ring);
seq |= last_seq & 0xLL;
- if (seq < last_seq) {
+ if (seq < (last_seq - 0x8000LL)) {
seq += 0x1LL;
}
Can you provide a bit more explanation for this change? In particular,
how could the code previously detect a wraparound when there was none,
and why is this the proper fix?
Honestly I also don't really understand how this bug happened in the
first place.
We extend the 32bit fences supported by hardware by testing if a
previously read fence value is smaller than the value we read now:
if (seq < last_seq) {
But the problem seems to be that on some systems we do get fence values
that are decreasing, e.g. instead of 5, 6, 7, 8 we get 5, 7, 6, 8 (or
maybe 5, 6, 0, 7, 8 because somebody accidentally overwrites the fence
value).
Maybe some kind of race involving radeon_fence_write()?
It might be related to a hardware bug, or the algorithm is flawed in a
way I currently don't see. Anyway the old code we had wasn't so picky
about such problems and the patch just tries to make the current code as
robust as the old code was, which indeed seems to solve the problems we see.
The wrap around detection still works (tested by setting the initial
fence value to 0xfff0 and letting it wrap around shortly after
start), so I think it we can safely commit this.
Without knowing exactly what kind of hardware fence value pattern caused
the problem, we can't be sure that the wraparound handling will work
reliably, or that the values going backwards won't cause other problems.
I think it would be good to get more real-world data on that.
As i said in my email this patch just postpone the issue to last_fence
= 0x1 8000 0001 if fence value we read back is sometimes randomly 0.
If we received fence value out of order (which i highly doubt as old
code would have had same issue thought on smaller scale) then if fence
value 0x1 8000 0001 is received before fence value 0x1 8000 we
are right back to all future fence considered as signalled (again this
will take month of uptime).
Actually thinking back about it if fence are just received out of
order then this patch corner case is if we received 0x1
after receiving 0x1 , what will happen is that the 0x1
is the wrap over that will trigger upper 32bits to be incremented
so fence become 0x2 then we got 0x which with |
become 0x2 then we get next fence value 0x 0001 and
again we increment upper 32bits so last seq become 0x3 0001.
Good point.
Again this will happen after month of uptime and all it does is
decrement the amount of uptime for which 64bit fence are fine ie at
worst we over increment by 0x2 instead of 0x1 on
wrap around.
How about this idea: Instead of increasing the upper 32bits we just use
the upper 32bits of the last emitted fence value?
E.g. see the attached patch. That both should handle random zero and out
of order values more gracefully.
Additionally I think that the reason we haven't had this before is that
this corruption might only happens on hw (re-)initialisation, e.g. boot
and resume.
Currently I'm hacking together a small test app that just emits an IB
with some NOP instructions, if I'm not completely wrong that should
gives us a very high fence rate, so we might be able to actually test
the wrap around a bit more.
Christian.
Cheers,
Jerome
All this probably lead to questioning the usefulness of 64bits fence.
Cheers,
Jerome
>From 8737d17a45e04d7c111abb5e79e48577b224fae6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?=
Date: Sun, 9 Sep 2012 11:45:19 +0200
Subject: [PATCH] drm/radeon: make 64bit fences more robust v2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bi
Re: [PATCH] drm/radeon: make 64bit fences more robust
On Die, 2012-09-11 at 12:11 +0200, Christian König wrote: > > How about this idea: Instead of increasing the upper 32bits we just use > the upper 32bits of the last emitted fence value? > E.g. see the attached patch. That both should handle random zero and out > of order values more gracefully. I like this idea. -- 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 54767] New: [r300g] 298 failures on WebGL Conformance Test
https://bugs.freedesktop.org/show_bug.cgi?id=54767 Bug #: 54767 Summary: [r300g] 298 failures on WebGL Conformance Test Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabio@libero.it Created attachment 66963 --> https://bugs.freedesktop.org/attachment.cgi?id=66963 298 failing WebGL tests on 2012-09-11 When running WebGL Conformance Test: https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/webgl-conformance-tests.html on r300 git on a RV530 298 tests fail. See the attachment for failing tests. If some get fixed I can later open a new bug for every test. -- 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 27141] piglit glean/vertProg1 core dumps with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=27141 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #7 from Andreas Boll 2012-09-11 11:07:28 UTC --- Note: classic r600 driver has been abandoned. all glean/vertProg1 tests pass with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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 27324] fbotest* broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=27324 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andreas Boll 2012-09-11 11:21:57 UTC --- Note: classic r600 driver has been abandoned. fbotest* pass with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 -- 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 25871] nearest neighbour samples wrong texel (precision/rounding problem)
https://bugs.freedesktop.org/show_bug.cgi?id=25871 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #5 from Andreas Boll 2012-09-11 11:32:01 UTC --- (In reply to comment #4) > Created attachment 43951 [details] [review] > possible fix > > Does this patch help? this patch has been committed as commit 1dc204d145dc8c0b19473a7814c201a8954b6274 Author: Alex Deucher Date: Mon Feb 28 21:52:19 2011 -0500 r600g: truncate point sampled texture coordinates By default the hardware rounds texcoords. However, for point sampled textures, the expected behavior is to truncate. When we have point sampled textures, set the truncate bit in the sampler. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=25871 Signed-off-by: Alex Deucher and reverted in commit 72c6a748b9ffdaa893f82faf911f22a241a5e4f5 Author: Marek Olšák Date: Mon May 2 01:10:19 2011 +0200 Revert "r600g: truncate point sampled texture coordinates" This reverts commit 1dc204d145dc8c0b19473a7814c201a8954b6274. MC_COORD_TRUNCATE is for MPEG and produces quite an interesting behavior on regular textures. Anyway that commit broke filtering in demos/cubemap. reassigning to r600g is this still an issue with a newer mesa (e.g. 8.0.4 or git master)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27142] piglit "glean/pbo -o -v" test dumps core
https://bugs.freedesktop.org/show_bug.cgi?id=27142 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Andreas Boll 2012-09-11 11:45:49 UTC --- Note: classic r600 driver has been abandoned. works without any segfault with r600g (gallium driver) on my rv770 tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 test result: 9 tests passed, 1 tests failed. -- 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 28049] Failure observed while running piglit glean/pbo
https://bugs.freedesktop.org/show_bug.cgi?id=28049 Andreas Boll changed: What|Removed |Added Summary|Failure observed while |Failure observed while |running the Glean test |running piglit glean/pbo Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #3 from Andreas Boll 2012-09-11 11:53:14 UTC --- Note: classic r600 driver has been abandoned. tested with r600g (gallium driver) on my rv770 mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd and mesa 8.0.4 test results: 9 tests passed, 1 tests failed. reassigning to r600g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27142] piglit "glean/pbo -o -v" test dumps core
https://bugs.freedesktop.org/show_bug.cgi?id=27142 --- Comment #3 from Andreas Boll 2012-09-11 11:57:28 UTC --- (In reply to comment #2) > Note: classic r600 driver has been abandoned. > > works without any segfault with r600g (gallium driver) on my rv770 > tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd > and mesa 8.0.4 > > test result: > 9 tests passed, 1 tests failed. the failing test is tracked in Bug 28049 -- 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 31423] Stars in Celestia misrendered
https://bugs.freedesktop.org/show_bug.cgi?id=31423 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Andreas Boll 2012-09-11 12:07:01 UTC --- (In reply to comment #2) > On R600g, Mesa 8.0rc2 the stars seem to have proper colors. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47321] crash with drm/radeon on hp dm1 4100ed laptop with amd 6320
https://bugzilla.kernel.org/show_bug.cgi?id=47321 --- Comment #10 from Alex Deucher 2012-09-11 12:25:13 --- (In reply to comment #9) > I thought about it for a while. For me personally the bug is fixed. But it > should be that if the driver doesn't find the software, then it should degrade > gracefully. Maybe not load the driver, or just do nothing. It's not the driver, it's the kernel fw loader. -- 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
xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
Dear DRI folks, using Debian Sid/unstable with the awesome 3.4.13-1 window manager and Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. Closing Evolution the usage goes back to more or less 0 %. I am contacting this list because of the output of OProfile. After figuring out what is the culprit I would submit the appropriate bug report. $ opcontrol --version opcontrol: oprofile 0.9.6 compiled on Jul 11 2011 15:32:06 $ sudo opcontrol --separate=lib,kernel $ sudo opcontrol --start-daemon $ opreport CPU: AMD64 processors, speed 1000 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 CPU_CLK_UNHALT...| samples| %| -- 200635 24.9294 Xorg CPU_CLK_UNHALT...| samples| %| -- 102707 51.1910 no-vmlinux 20261 10.0984 radeon_drv.so 19241 9.5901 Xorg 15254 7.6029 libdrm_radeon.so.1.0.0 13290 6.6240 libpixman-1.so.0.26.0 12887 6.4231 libc-2.13.so 11086 5.5255 libexa.so 2299 1.1459 libfb.so 1409 0.7023 libdrm.so.2.4.0 717 0.3574 [vdso] (tgid:2764 range:0xb7586000-0xb7587000) 645 0.3215 libextmod.so 505 0.2517 librt-2.13.so 151 0.0753 libpthread-2.13.so 145 0.0723 evdev_drv.so 37 0.0184 libudev.so.0.13.0 1 5.0e-04 ld-2.13.so 127271 15.8137 perl CPU_CLK_UNHALT...| samples| %| -- 84842 66.6625 perl 21993 17.2804 libc-2.13.so 17668 13.8822 no-vmlinux 1858 1.4599 ld-2.13.so 413 0.3245 libsqlite3.so.0.8.6 268 0.2106 libpthread-2.13.so 70 0.0550 DBI.so 25 0.0196 libm-2.13.so 23 0.0181 libdl-2.13.so 20 0.0157 POSIX.so 14 0.0110 Socket.so 14 0.0110 SQLite.so 13 0.0102 libnss_compat-2.13.so 11 0.0086 Syslog.so 9 0.0071 Fcntl.so 6 0.0047 Cwd.so 5 0.0039 libcrypt-2.13.so 5 0.0039 libnsl-2.13.so 4 0.0031 libnss_nis-2.13.so 3 0.0024 [vdso] (tgid:3287 range:0xb77de000-0xb77df000) 3 0.0024 Util.so 1 7.9e-04 [vdso] (tgid:7099 range:0xb773c000-0xb773d000) 1 7.9e-04 [vdso] (tgid:7186 range:0xb76e4000-0xb76e5000) 1 7.9e-04 [vdso] (tgid:7270 range:0xb7792000-0xb7793000) 1 7.9e-04 libnss_files-2.13.so 118502 14.7241 evolution CPU_CLK_UNHALT...| samples| %| -- 32194 27.1675 libcairo.so.2.11200.2 24613 20.7701 libglib-2.0.so.0.3200.3 14060 11.8648 libgtk-3.so.0.400.2 11814 9.9695 libgobject-2.0.so.0.3200.3 8400 7.0885 libc-2.13.so 7502 6.3307 libpthread-2.13.so 7387 6.2337 no-vmlinux 3161 2.6675 libgdk-3.so.0.400.2 2108 1.7789 libpango-1.0.so.0.3000.0 1632 1.3772 libpixman-1.so.0.26.0 1133 0.9561 libX11.so.6.3.0 853 0.7198 libXrender.so.1.3.0 821 0.6928 libdbus-1.so.3.7.2 582 0.4911 libm-2.13.so 499 0.4211 libxcb.so.1.1.0 451 0.3806 libpangocairo-1.0.so.0.3000.0 395 0. libcogl.so.9.1.1 261 0.2202 libcamel-1.2.so.33.0.0 169 0.1426 librt-2.13.so 82 0.0692 [vdso] (tgid:5438 range:0xb771c000-0xb771d000) 77 0.0650 libgio-2.0.so.0.3200.3 65 0.0549 libgnome-keyring.so.0.2.0 62 0.0523 libgvfscommon.so 55 0.0464 libpangoft2-1.0.so.0.3000.0 36 0.0304 libfreetype.so.6.8.1 33 0.0278 libdbus-glib-1.so.2.2.2 10 0.0084 libsqlite3.so.0.8.6 8 0.0068 pango-basic-fc.so 7 0.0059 libeutil.so.0.0.0 6 0.0051 libcamellocal.so
Re: xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. > Closing Evolution the usage goes back to more or less 0 %. I'm not seeing this. Is there something in your Evolution window(s) that is constantly repainting, e.g. a spinner in the status bar, a blinking cursor, ... ? > Could somebody please tell me what component (X driver, DRM, Evolution, > Cairo, …) to investigate and how? I'd focus on profiling the X server, making sure the profiles show symbols, ideally with call graphs. sysprof or perf might work better for this than oprofile. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage
Am Dienstag, den 11.09.2012, 14:55 +0200 schrieb Michel Dänzer: > On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: > > > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and > > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU. > > Closing Evolution the usage goes back to more or less 0 %. > > I'm not seeing this. Is there something in your Evolution window(s) that > is constantly repainting, e.g. a spinner in the status bar, a blinking > cursor, ... ? Now that you are mentioning it, in the bottom there is the message »Checking for New Messages« and next to it there is an animation where something goes around a circle. Canceling that removes X’s CPU usage. Thanks a lot. Should I recommend something to the Evolution folks on how to due such animations? Or is the only way to avoid animations? > > Could somebody please tell me what component (X driver, DRM, Evolution, > > Cairo, …) to investigate and how? > > I'd focus on profiling the X server, making sure the profiles show > symbols, ideally with call graphs. sysprof or perf might work better for > this than oprofile. Thanks. Lucky me, that this is not needed now and I can postpone how to figure out how to start X that way under Debian with GDM. Michael, thanks as always! Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
