Re: [PATCH] radeon: Allow disabling UVD
On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote: > Apparently UVD doesn't yet work everywhere - so allow it to be > disabled. Shaves off some reboot and suspend/resume time on machines > where it doesn't work. Might be useful for problematic chips in the > future as well. > > Patch attached as well as inline below. > > Signed-off-by: Parag Warudkar [...] > @@ -168,6 +169,9 @@ int radeon_fastfb = 0; > MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers"); > module_param_named(no_wb, radeon_no_wb, int, 0444); > > +MODULE_PARM_DESC(no_uvd, "Disable UVD"); > +module_param_named(no_uvd, radeon_no_uvd, int, 0444); No more negative boolean options please. > diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c > b/drivers/gpu/drm/radeon/radeon_uvd.c > index 906e5c0..93a7dbb 100644 > --- a/drivers/gpu/drm/radeon/radeon_uvd.c > +++ b/drivers/gpu/drm/radeon/radeon_uvd.c > @@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev) > unsigned long bo_size; > const char *fw_name; > int i, r; > - > + if (radeon_no_uvd) > + return -EINVAL; > INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler); Returning -EINVAL here results in rather misleading dmesg output I think. This should probably be handled more gracefully. Anyway, the return statement would need to be indented per the kernel coding style, and please leave empty lines before the if and after the return. -- 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 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #5 from Mike Lothian --- I'm afraid it doesn't fix it - I'm going to be out of the country for a week now - I'll bisect it when I get back if it still isn't working -- 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: linux-next: manual merge of the drm-intel tree with Linus' tree
On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from Linus' tree and commit
> e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> Daniel, I assume all this stuff being added to the drm-intel tree is
> going upstream very soon?
Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff
through (since we just keep on merging features to
drm-intel-next-queued to avoid stalls), but that's obviously not what
you want for linux-next. My apologies for that mess. I've now created
a for-linux-next branch which will not contain patches heading for
3.x+1 while 3.x-rc1 hasn't been released yet.
Can you please switch over to that branch for inclusion into linux-next?
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Allow disabling UVD
Am 07.05.2013 09:02, schrieb Michel Dänzer: On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote: Apparently UVD doesn't yet work everywhere - so allow it to be disabled. Shaves off some reboot and suspend/resume time on machines where it doesn't work. Might be useful for problematic chips in the future as well. Patch attached as well as inline below. Signed-off-by: Parag Warudkar The patch shouldn't be necessary because just removing the firmware should have pretty much the same effect. On the other hand we only have three reports of failed VCPU bootup, while it just seems to be a setup problems in two of those cases (identical hardware seems to work for other people). The only case where we indeed seems to have a problem are Macs with integrated cards, and we can always just blacklist those if the problem doesn't seems to be solvable. Christian. [...] @@ -168,6 +169,9 @@ int radeon_fastfb = 0; MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers"); module_param_named(no_wb, radeon_no_wb, int, 0444); +MODULE_PARM_DESC(no_uvd, "Disable UVD"); +module_param_named(no_uvd, radeon_no_uvd, int, 0444); No more negative boolean options please. diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c index 906e5c0..93a7dbb 100644 --- a/drivers/gpu/drm/radeon/radeon_uvd.c +++ b/drivers/gpu/drm/radeon/radeon_uvd.c @@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev) unsigned long bo_size; const char *fw_name; int i, r; - + if (radeon_no_uvd) + return -EINVAL; INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler); Returning -EINVAL here results in rather misleading dmesg output I think. This should probably be handled more gracefully. Anyway, the return statement would need to be indented per the kernel coding style, and please leave empty lines before the if and after the return. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64320] New: WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 Priority: medium Bug ID: 64320 Assignee: dri-devel@lists.freedesktop.org Summary: WebGL support in Chrome causes GPU lockup Severity: normal Classification: Unclassified OS: Linux (All) Reporter: marvi...@gmx.de Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa googles chrome browser causes gpu lockup on my RS880 while showing maps.google.com and enabling WebGL renderer. For this to work, you need to manually override gpu blacklist with "--enable-webgl --ignore-gpu-blacklist" on the command prompt. Check with about:gpu that hw accel is enabled. Mesa/LLVM/drm/ddx is from today (May 7th) and kernel is 3.9. dmesg shows: [ 3889.414104] radeon :01:05.0: GPU lockup CP stall for more than 1msec [ 3889.414116] radeon :01:05.0: GPU lockup (waiting for 0xcba7 last fence id 0xcba6) [ 3889.415314] radeon :01:05.0: Saved 2617 dwords of commands on ring 0. [ 3889.415325] radeon :01:05.0: GPU softreset: 0x0009 [ 3889.415330] radeon :01:05.0: R_008010_GRBM_STATUS = 0xA2723030 [ 3889.415336] radeon :01:05.0: R_008014_GRBM_STATUS2 = 0x0103 [ 3889.415341] radeon :01:05.0: R_000E50_SRBM_STATUS = 0x20001040 [ 3889.415346] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [ 3889.415350] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x8002 [ 3889.415355] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x8086 [ 3889.415360] radeon :01:05.0: R_008680_CP_STAT = 0x80018645 [ 3889.415365] radeon :01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3889.496650] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEF [ 3889.496702] radeon :01:05.0: SRBM_SOFT_RESET=0x0100 [ 3889.55] radeon :01:05.0: R_008010_GRBM_STATUS = 0xA0003030 [ 3889.57] radeon :01:05.0: R_008014_GRBM_STATUS2 = 0x0003 [ 3889.58] radeon :01:05.0: R_000E50_SRBM_STATUS = 0x20009040 [ 3889.59] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [ 3889.511120] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x [ 3889.511122] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x [ 3889.511123] radeon :01:05.0: R_008680_CP_STAT = 0x8010 [ 3889.511124] radeon :01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3889.511128] radeon :01:05.0: GPU reset succeeded, trying to resume [ 3889.525400] [drm] PCIE GART of 512M enabled (table at 0xC004). [ 3889.525469] radeon :01:05.0: WB enabled [ 3889.525471] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x8801140fec00 [ 3889.525473] radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8801140fec0c [ 3889.525748] radeon :01:05.0: setting latency timer to 64 [ 3889.561733] [drm] ring test on 0 succeeded in 0 usecs [ 3889.561789] [drm] ring test on 3 succeeded in 1 usecs [ 3889.663696] Watchdog[27005]: segfault at 0 ip 7fa72ac7fc0e sp 7fa71e139580 error 6 in chrome[7fa729f89000+56b2000] [ 3900.242063] radeon :01:05.0: GPU lockup CP stall for more than 1msec [ 3900.242076] radeon :01:05.0: GPU lockup (waiting for 0xcbf8 last fence id 0xcba9) [ 3900.242099] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). [ 3900.242107] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-16). [ 3900.242113] radeon :01:05.0: ib ring test failed (-16). [ 3900.243281] radeon :01:05.0: GPU softreset: 0x0009 [ 3900.243287] radeon :01:05.0: R_008010_GRBM_STATUS = 0xA2723030 [ 3900.243292] radeon :01:05.0: R_008014_GRBM_STATUS2 = 0x0103 [ 3900.243296] radeon :01:05.0: R_000E50_SRBM_STATUS = 0x2040 [ 3900.243301] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [ 3900.243306] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x8002 [ 3900.243311] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x8086 [ 3900.243315] radeon :01:05.0: R_008680_CP_STAT = 0x80018645 [ 3900.243320] radeon :01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3900.299679] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEF [ 3900.299732] radeon :01:05.0: SRBM_SOFT_RESET=0x0100 [ 3900.302183] radeon :01:05.0: R_008010_GRBM_STATUS = 0xA0003030 [ 3900.302184] radeon :01:05.0: R_008014_GRBM_STATUS2 = 0x0003 [ 3900.302186] radeon :01:05.0: R_000E50_SRBM_STATUS = 0x20008040 [ 3900.302187] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [ 3900.302188] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x [ 3900.302190] radeon :01:05.0: R_00867C_CP_BUSY_STAT
Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote: > On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote: >> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote: >>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: Signed-off-by: Andy Lutomirski --- This needs careful review. I don't really know what this code does, nor do I have the hardware. (I don't understand AGP and the associated caching implications.) >>> >>> This patch is wrong (I didn't update the matching mtrr_del), and I'm >>> reworking this whole series. But I may need some help on this one: >>> why is the mtrr handle of a map (whatever a map is) exported to >>> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is >>> userspace supposed to do with it? Do I need to return a valid MTRR >>> register number? Is there any userspace code at all that sets >>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment >>> and needs the MTRR, for which the drm driver doesn't already add the >>> MTRR? >>> >>> --Andy >> >> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >> cover it with a write combine MTRR. The whole ioctl is use by some ddx >> or maybe even directly the XServer to do this mtrr mess in userspace. > > Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to > work fine, but almost nothing uses it. > > I'm amazed this stuff works in the current code, though. Apparently > the memory type (WC or UC) of a drm mapping is determined by the mtrr > the driver set, but if one part of the BAR is textures or the > framebuffer and another part is an outgoing command ring, won't one of > them end up with the wrong memory type? A lot of old chips used to put the registers and framebuffer in the same BAR. IIRC, the xserver and later libpciaccess had workarounds to deal with this. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64320] WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 --- Comment #1 from Alex Deucher --- Is this a regression? If so, can you bisect? Please attach your xorg log and dmesg output. -- 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 64320] WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 --- Comment #2 from Alex Deucher --- It was noted on IRC that the lockups only happen with llvm. This is probably a duplicate of bug 64257. -- 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 64320] WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 --- Comment #3 from Marc Dietrich --- I don't see Kwin corruptions as reported in bug 64257. Also this bug says nothing about GPU lockups. But what I also see is a "dark glxgears" effect. It's kinda hard to bisect this because r600 now depends on llvm and different mesa versions may require different llvm versions. I can try using the llvm version as written in LLVM_REVISION.TXT, but that may take some time. -- 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 64320] WebGL support in Chrome causes GPU lockup when using llvm
https://bugs.freedesktop.org/show_bug.cgi?id=64320 Alex Deucher changed: What|Removed |Added Summary|WebGL support in Chrome |WebGL support in Chrome |causes GPU lockup |causes GPU lockup when ||using llvm -- 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 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #22 from Michel Dänzer --- (In reply to comment #21) > Yup. Did the same process for the 32-bit drivers. Same result. Works For Me™... Did you verify with LIBGL_DEBUG=verbose that it's picking up the right radeonsi_dri.so? -- 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 62466] r600g hyperz lockups with KSP 0.19
https://bugs.freedesktop.org/show_bug.cgi?id=62466 --- Comment #10 from Jerome Glisse --- Patch was against mesa, but patch is now included in mesa except in mesa 9.1 branch, i will push something shortly. If you want to make a donation make one to EFF https://www.eff.org/ Or buy me a beer if you ever bump into me. -- 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 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #5 from Jerome Glisse --- 7.10 is old please try with at least 9.1 -- 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 63979] s3tc not working with radeonsi driver
https://bugs.freedesktop.org/show_bug.cgi?id=63979 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jerome Glisse --- Closing works with what gonna be 3.10 -- 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 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #6 from runetmem...@gmail.com --- Isn't 7.1.0 is latest version of the driver? http://www.x.org/wiki/radeon If you talking about Mesa - sure, I already tried Mesa 9.1.1 and 9.2-git. -- 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: linux-next: manual merge of the drm-intel tree with Linus' tree
Hi Daniel, On Tue, 7 May 2013 10:43:17 +0200 Daniel Vetter wrote: > > On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell > wrote: > > > > Daniel, I assume all this stuff being added to the drm-intel tree is > > going upstream very soon? > > Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff > through (since we just keep on merging features to > drm-intel-next-queued to avoid stalls), but that's obviously not what > you want for linux-next. My apologies for that mess. I've now created > a for-linux-next branch which will not contain patches heading for > 3.x+1 while 3.x-rc1 hasn't been released yet. > > Can you please switch over to that branch for inclusion into linux-next? Done. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpD_n6cE5bNG.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #13 from Erdem U. Altinyurt --- Oops! LLVM 3.3 is branched today. I wish this bug vanished from LLVM before release of v3.3 in June Updated today's mesa and llvm-trunks... Without "-v1" flag, "bfgminer --benchmark" reports: [2013-05-08 03:37:54] Error -11: Building Program (clBuildProgram) [2013-05-08 03:37:54] input.cl:197:7: error: initializing 'uint' (aka 'unsigned int') with an expression of incompatible type 'unsigned int __attribute__((ext_ve ctor_type(2)))' uint r = rot(W[3].x,25u)^rot(W[3].x,14u)^((W[3].x)>>3U); @Aaron, could you use pyrit or any other OpenCL tools with yours HD6850 without lockup? Regards. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix error return code in exynos_drm_ipp_set_property()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
ipp_create_cmd_work() return ERR_PTR() on error and never return
NULL, so use IS_ERR() instead of IS_ERR_OR_NULL().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 29d2ad3..b0d6431 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -521,20 +521,23 @@ int exynos_drm_ipp_set_property(struct drm_device
*drm_dev, void *data,
c_node->state = IPP_STATE_IDLE;
c_node->start_work = ipp_create_cmd_work();
- if (IS_ERR_OR_NULL(c_node->start_work)) {
+ if (IS_ERR(c_node->start_work)) {
DRM_ERROR("failed to create start work.\n");
+ ret = PTR_ERR(c_node->start_work);
goto err_clear;
}
c_node->stop_work = ipp_create_cmd_work();
- if (IS_ERR_OR_NULL(c_node->stop_work)) {
+ if (IS_ERR(c_node->stop_work)) {
DRM_ERROR("failed to create stop work.\n");
+ ret = PTR_ERR(c_node->stop_work);
goto err_free_start;
}
c_node->event_work = ipp_create_event_work();
- if (IS_ERR_OR_NULL(c_node->event_work)) {
+ if (IS_ERR(c_node->event_work)) {
DRM_ERROR("failed to create event work.\n");
+ ret = PTR_ERR(c_node->event_work);
goto err_free_stop;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix error return code in exynos_drm_load()
From: Wei Yongjun
Fix to return -ENOMEM in the exynos_plane_init() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ba6d995..3a10373 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -91,8 +91,10 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
unsigned int possible_crtcs = (1 << MAX_CRTC) - 1;
plane = exynos_plane_init(dev, possible_crtcs, false);
- if (!plane)
+ if (!plane) {
+ ret = -ENOMEM;
goto err_release_iommu_mapping;
+ }
}
ret = drm_vblank_init(dev, MAX_CRTC);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: fix error return code in exynos_drm_ipp_set_property()
Hi Wei Yongjun, On 7 May 2013 18:54, Wei Yongjun wrote: > From: Wei Yongjun > > Fix to return a negative error code from the error handling > case instead of 0, as done elsewhere in this function. > ipp_create_cmd_work() return ERR_PTR() on error and never return > NULL, so use IS_ERR() instead of IS_ERR_OR_NULL(). > > Signed-off-by: Wei Yongjun > --- I have submitted a patch [1] to use IS_ERR instead of IS_ERR_OR_NULL() for all incorrect instances in this driver. Please base your patch fixing the return code on top of my patch. [1] http://lists.freedesktop.org/archives/dri-devel/2013-April/038059.html -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Tue, May 7, 2013 at 7:08 AM, Alex Deucher wrote: > On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote: >> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote: >>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote: On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > > This needs careful review. I don't really know what this code does, nor > do I have the hardware. (I don't understand AGP and the associated > caching implications.) This patch is wrong (I didn't update the matching mtrr_del), and I'm reworking this whole series. But I may need some help on this one: why is the mtrr handle of a map (whatever a map is) exported to userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is userspace supposed to do with it? Do I need to return a valid MTRR register number? Is there any userspace code at all that sets _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment and needs the MTRR, for which the drm driver doesn't already add the MTRR? --Andy >>> >>> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >>> cover it with a write combine MTRR. The whole ioctl is use by some ddx >>> or maybe even directly the XServer to do this mtrr mess in userspace. >> >> Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to >> work fine, but almost nothing uses it. >> >> I'm amazed this stuff works in the current code, though. Apparently >> the memory type (WC or UC) of a drm mapping is determined by the mtrr >> the driver set, but if one part of the BAR is textures or the >> framebuffer and another part is an outgoing command ring, won't one of >> them end up with the wrong memory type? > > A lot of old chips used to put the registers and framebuffer in the > same BAR. IIRC, the xserver and later libpciaccess had workarounds to > deal with this. I think I read the code wrong (so my patch is garbage). Maybe there's actually no problem -- if DRM_AGP and DRM_FRAME_BUFFER are always WC, DRM_REGISTERS is only WC if explicitly requested, and DRM_SHM is always WB, so everything should be covered. Anything using libpciaccess ought to be unaffected by my changes -- I don't want to change /proc/mtrr or the sysfs stuff. The only possible issue is if there's a memtype conflict, but that's nothing new. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: refactor call to request_module
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_encoder_slave.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index 48c52f7..0cfb60f 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -54,16 +54,12 @@ int drm_i2c_encoder_init(struct drm_device *dev,
struct i2c_adapter *adap,
const struct i2c_board_info *info)
{
- char modalias[sizeof(I2C_MODULE_PREFIX)
- + I2C_NAME_SIZE];
struct module *module = NULL;
struct i2c_client *client;
struct drm_i2c_encoder_driver *encoder_drv;
int err = 0;
- snprintf(modalias, sizeof(modalias),
-"%s%s", I2C_MODULE_PREFIX, info->type);
- request_module(modalias);
+ request_module("%s%s", I2C_MODULE_PREFIX, info->type);
client = i2c_new_device(adap, info);
if (!client) {
--
1.7.9.5
--
Kees Cook
Chrome OS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Allow disabling UVD
On Tue, May 7, 2013 at 4:44 AM, Christian König wrote: > > The patch shouldn't be necessary because just removing the firmware should > have pretty much the same effect. Soon distros will ship the UVD firmware by default and then users will need to manually remove it and then do the same with every update. Besides, I just discovered that when UVD is enabled suspend resume breaks - tried 3 times with SUMO_uvd loaded - machine suspends but resumes instantly. Without SUMO_uvd.bin - suspends fine and only wakes up when I want it to. > The only case where we indeed seems to have a problem are Macs with > integrated cards, and we can always just blacklist those if the problem > doesn't seems to be solvable. I happen to have the problematic card in my iMac - I'd be glad to provide any info or try any patches. Just let me know. For now I will remove the firmware - I reboot /suspend-resume often and it is a bit annoying to have to go through those mdelays only to fail. Thanks, Parag ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote: > On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: >> >> >> >> However if we don't set a dma mask on the usb device, the mapping >> >> ends up using swiotlb on machines that have it enabled, which >> >> is less than desireable. >> >> >> >> Signed-off-by: Dave Airlie >> > >> > Fyi for everyone else who was not on irc when Dave&I discussed this: >> > This really shouldn't be required and I think the real issue is that >> > udl creates a dma_buf attachement (which is needed for device dma >> > only), but only really wants to do cpu access through vmap/kmap. So >> > not attached the device should be good enough. Cc'ing a few more lists >> > for better fyi ;-) >> >> Though I've looked at this a bit more, and since I want to be able to expose >> shared objects as proper GEM objects from the import side I really >> need that list of pages. > > Hm, what does "proper GEM object" mean in the context of udl? One that appears the same as a GEM object created by userspace. i.e. mmap works. Dave.
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
>>> One that appears the same as a GEM object created by userspace. i.e. mmap >>> works. >> >> Oh, we have an mmap interface in the dma_buf thing for that, and iirc >> Rob Clark even bothered to implement the gem->dma_buf mmap forwarding >> somewhere. And iirc android's ion-on-dma_buf stuff is even using the >> mmap interface stuff. > > fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap > for the dmabuf object by fwd'ing it to my normal gem mmap code. Might > be the opposite of what you are looking for here. Although I suppose > the reverse could work to, I hadn't really thought about it yet. > Yeah thats the opposite, I want to implement my GEM mmap ioctls using dma-buf mmaps :) Dave.
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
Make data/link N value power of two") from Linus' tree and commit
e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Daniel, I assume all this stuff being added to the drm-intel tree is
going upstream very soon?
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_reg.h
index 83f9c26,a470103..000
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@@ -2648,18 -2768,19 +2768,19 @@@
* which is after the LUTs, so we want the bytes for our color format.
* For our current usage, this is always 3, one byte for R, G and B.
*/
- #define _PIPEA_GMCH_DATA_M0x70050
- #define _PIPEB_GMCH_DATA_M0x71050
+ #define _PIPEA_DATA_M_G4X 0x70050
+ #define _PIPEB_DATA_M_G4X 0x71050
/* Transfer unit size for display port - 1, default is 0x3f (for TU size 64)
*/
-#define PIPE_GMCH_DATA_M_TU_SIZE_MASK (0x3f << 25)
-#define PIPE_GMCH_DATA_M_TU_SIZE_SHIFT 25
+#define TU_SIZE(x) (((x)-1) << 25) /* default size 64 */
+#define TU_SIZE_MASK (0x3f << 25)
+ #define TU_SIZE_SHIFT25
-#define PIPE_GMCH_DATA_M_MASK (0xff)
+#define DATA_LINK_M_N_MASK (0xff)
+#define DATA_LINK_N_MAX (0x80)
- #define _PIPEA_GMCH_DATA_N0x70054
- #define _PIPEB_GMCH_DATA_N0x71054
+ #define _PIPEA_DATA_N_G4X 0x70054
+ #define _PIPEB_DATA_N_G4X 0x71054
-#define PIPE_GMCH_DATA_N_MASK (0xff)
/*
* Computing Link M and N values for the Display Port link
@@@ -2672,16 -2793,18 +2793,16 @@@
* Attributes and VB-ID.
*/
- #define _PIPEA_DP_LINK_M 0x70060
- #define _PIPEB_DP_LINK_M 0x71060
+ #define _PIPEA_LINK_M_G4X 0x70060
+ #define _PIPEB_LINK_M_G4X 0x71060
-#define PIPEA_DP_LINK_M_MASK(0xff)
- #define _PIPEA_DP_LINK_N 0x70064
- #define _PIPEB_DP_LINK_N 0x71064
+ #define _PIPEA_LINK_N_G4X 0x70064
+ #define _PIPEB_LINK_N_G4X 0x71064
-#define PIPEA_DP_LINK_N_MASK(0xff)
- #define PIPE_GMCH_DATA_M(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_M,
_PIPEB_GMCH_DATA_M)
- #define PIPE_GMCH_DATA_N(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_N,
_PIPEB_GMCH_DATA_N)
- #define PIPE_DP_LINK_M(pipe) _PIPE(pipe, _PIPEA_DP_LINK_M, _PIPEB_DP_LINK_M)
- #define PIPE_DP_LINK_N(pipe) _PIPE(pipe, _PIPEA_DP_LINK_N, _PIPEB_DP_LINK_N)
+ #define PIPE_DATA_M_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_M_G4X,
_PIPEB_DATA_M_G4X)
+ #define PIPE_DATA_N_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_N_G4X,
_PIPEB_DATA_N_G4X)
+ #define PIPE_LINK_M_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_M_G4X,
_PIPEB_LINK_M_G4X)
+ #define PIPE_LINK_N_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_N_G4X,
_PIPEB_LINK_N_G4X)
/* Display & cursor control */
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/6d4211ee/attachment.pgp>
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
>> >> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >> cover it with a write combine MTRR. The whole ioctl is use by some ddx >> or maybe even directly the XServer to do this mtrr mess in userspace. > > Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to > work fine, but almost nothing uses it. > > I'm amazed this stuff works in the current code, though. Apparently > the memory type (WC or UC) of a drm mapping is determined by the mtrr > the driver set, but if one part of the BAR is textures or the > framebuffer and another part is an outgoing command ring, won't one of > them end up with the wrong memory type? Nobody sane puts the command ring in VRAM. Dave.
[PATCH] radeon: Allow disabling UVD
On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote: > Apparently UVD doesn't yet work everywhere - so allow it to be > disabled. Shaves off some reboot and suspend/resume time on machines > where it doesn't work. Might be useful for problematic chips in the > future as well. > > Patch attached as well as inline below. > > Signed-off-by: Parag Warudkar [...] > @@ -168,6 +169,9 @@ int radeon_fastfb = 0; > MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers"); > module_param_named(no_wb, radeon_no_wb, int, 0444); > > +MODULE_PARM_DESC(no_uvd, "Disable UVD"); > +module_param_named(no_uvd, radeon_no_uvd, int, 0444); No more negative boolean options please. > diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c > b/drivers/gpu/drm/radeon/radeon_uvd.c > index 906e5c0..93a7dbb 100644 > --- a/drivers/gpu/drm/radeon/radeon_uvd.c > +++ b/drivers/gpu/drm/radeon/radeon_uvd.c > @@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev) > unsigned long bo_size; > const char *fw_name; > int i, r; > - > + if (radeon_no_uvd) > + return -EINVAL; > INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler); Returning -EINVAL here results in rather misleading dmesg output I think. This should probably be handled more gracefully. Anyway, the return statement would need to be indented per the kernel coding style, and please leave empty lines before the if and after the return. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #5 from Mike Lothian --- I'm afraid it doesn't fix it - I'm going to be out of the country for a week now - I'll bisect it when I get back if it still isn't working -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/7167868e/attachment.html>
linux-next: manual merge of the drm-intel tree with Linus' tree
On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell
wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from Linus' tree and commit
> e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> Daniel, I assume all this stuff being added to the drm-intel tree is
> going upstream very soon?
Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff
through (since we just keep on merging features to
drm-intel-next-queued to avoid stalls), but that's obviously not what
you want for linux-next. My apologies for that mess. I've now created
a for-linux-next branch which will not contain patches heading for
3.x+1 while 3.x-rc1 hasn't been released yet.
Can you please switch over to that branch for inclusion into linux-next?
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] radeon: Allow disabling UVD
Am 07.05.2013 09:02, schrieb Michel D?nzer: > On Mon, 2013-05-06 at 19:11 -0400, Parag Warudkar wrote: >> Apparently UVD doesn't yet work everywhere - so allow it to be >> disabled. Shaves off some reboot and suspend/resume time on machines >> where it doesn't work. Might be useful for problematic chips in the >> future as well. >> >> Patch attached as well as inline below. >> >> Signed-off-by: Parag Warudkar The patch shouldn't be necessary because just removing the firmware should have pretty much the same effect. On the other hand we only have three reports of failed VCPU bootup, while it just seems to be a setup problems in two of those cases (identical hardware seems to work for other people). The only case where we indeed seems to have a problem are Macs with integrated cards, and we can always just blacklist those if the problem doesn't seems to be solvable. Christian. > [...] > >> @@ -168,6 +169,9 @@ int radeon_fastfb = 0; >> MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers"); >> module_param_named(no_wb, radeon_no_wb, int, 0444); >> >> +MODULE_PARM_DESC(no_uvd, "Disable UVD"); >> +module_param_named(no_uvd, radeon_no_uvd, int, 0444); > No more negative boolean options please. > > >> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c >> b/drivers/gpu/drm/radeon/radeon_uvd.c >> index 906e5c0..93a7dbb 100644 >> --- a/drivers/gpu/drm/radeon/radeon_uvd.c >> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c >> @@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev) >>unsigned long bo_size; >>const char *fw_name; >>int i, r; >> - >> + if (radeon_no_uvd) >> + return -EINVAL; >>INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler); > Returning -EINVAL here results in rather misleading dmesg output I > think. This should probably be handled more gracefully. > > Anyway, the return statement would need to be indented per the kernel > coding style, and please leave empty lines before the if and after the > return. > >
[Bug 64320] New: WebGL support in Chrome causes GPU lockup
00:01:05.0: R_00867C_CP_BUSY_STAT = 0x [ 3900.302191] radeon :01:05.0: R_008680_CP_STAT = 0x8010 [ 3900.302192] radeon :01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3900.302195] radeon :01:05.0: GPU reset succeeded, trying to resume [ 3900.304477] [drm] PCIE GART of 512M enabled (table at 0xC004). [ 3900.304572] radeon :01:05.0: WB enabled [ 3900.304575] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x8801140fec00 [ 3900.304576] radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8801140fec0c [ 3900.304820] radeon :01:05.0: setting latency timer to 64 [ 3900.341039] [drm] ring test on 0 succeeded in 1 usecs [ 3900.341096] [drm] ring test on 3 succeeded in 1 usecs [ 3900.341115] [drm] ib test on ring 0 succeeded in 0 usecs [ 3900.341127] [drm] ib test on ring 3 succeeded in 1 usecs [ 3900.344205] radeon :01:05.0: GPU softreset: 0x0040 [ 3900.344208] radeon :01:05.0: R_008010_GRBM_STATUS = 0xA0003030 [ 3900.344210] radeon :01:05.0: R_008014_GRBM_STATUS2 = 0x0003 [ 3900.344211] radeon :01:05.0: R_000E50_SRBM_STATUS = 0x20009040 [ 3900.344213] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [ 3900.344214] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x [ 3900.344215] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x [ 3900.344217] radeon :01:05.0: R_008680_CP_STAT = 0x8010 [ 3900.344218] radeon :01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3900.408220] radeon :01:05.0: SRBM_SOFT_RESET=0x2000 [ 3900.422569] radeon :01:05.0: R_008010_GRBM_STATUS = 0xA0003030 [ 3900.422571] radeon :01:05.0: R_008014_GRBM_STATUS2 = 0x0003 [ 3900.422572] radeon :01:05.0: R_000E50_SRBM_STATUS = 0x20001040 [ 3900.422574] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [ 3900.422575] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x [ 3900.422577] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x [ 3900.422579] radeon :01:05.0: R_008680_CP_STAT = 0x8010 [ 3900.422580] radeon :01:05.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3900.422584] radeon :01:05.0: GPU reset succeeded, trying to resume [ 3900.437060] [drm] PCIE GART of 512M enabled (table at 0xC004). [ 3900.437245] radeon :01:05.0: WB enabled [ 3900.437247] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x8801140fec00 [ 3900.437249] radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8801140fec0c [ 3900.437632] radeon :01:05.0: setting latency timer to 64 [ 3900.473423] [drm] ring test on 0 succeeded in 1 usecs [ 3900.473480] [drm] ring test on 3 succeeded in 1 usecs [ 3900.473494] [drm] ib test on ring 0 succeeded in 0 usecs [ 3900.473505] [drm] ib test on ring 3 succeeded in 1 usecs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/debafa15/attachment-0001.html>
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote: > On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote: >> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski >> wrote: >>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski >>> wrote: Signed-off-by: Andy Lutomirski --- This needs careful review. I don't really know what this code does, nor do I have the hardware. (I don't understand AGP and the associated caching implications.) >>> >>> This patch is wrong (I didn't update the matching mtrr_del), and I'm >>> reworking this whole series. But I may need some help on this one: >>> why is the mtrr handle of a map (whatever a map is) exported to >>> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is >>> userspace supposed to do with it? Do I need to return a valid MTRR >>> register number? Is there any userspace code at all that sets >>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment >>> and needs the MTRR, for which the drm driver doesn't already add the >>> MTRR? >>> >>> --Andy >> >> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >> cover it with a write combine MTRR. The whole ioctl is use by some ddx >> or maybe even directly the XServer to do this mtrr mess in userspace. > > Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to > work fine, but almost nothing uses it. > > I'm amazed this stuff works in the current code, though. Apparently > the memory type (WC or UC) of a drm mapping is determined by the mtrr > the driver set, but if one part of the BAR is textures or the > framebuffer and another part is an outgoing command ring, won't one of > them end up with the wrong memory type? A lot of old chips used to put the registers and framebuffer in the same BAR. IIRC, the xserver and later libpciaccess had workarounds to deal with this. Alex
[Bug 64320] WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 --- Comment #1 from Alex Deucher --- Is this a regression? If so, can you bisect? Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/9ad65253/attachment.html>
[Bug 64320] WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 --- Comment #2 from Alex Deucher --- It was noted on IRC that the lockups only happen with llvm. This is probably a duplicate of bug 64257. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/c78c5773/attachment.html>
[Bug 64320] WebGL support in Chrome causes GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=64320 --- Comment #3 from Marc Dietrich --- I don't see Kwin corruptions as reported in bug 64257. Also this bug says nothing about GPU lockups. But what I also see is a "dark glxgears" effect. It's kinda hard to bisect this because r600 now depends on llvm and different mesa versions may require different llvm versions. I can try using the llvm version as written in LLVM_REVISION.TXT, but that may take some time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/1e3920e5/attachment.html>
[Bug 64320] WebGL support in Chrome causes GPU lockup when using llvm
https://bugs.freedesktop.org/show_bug.cgi?id=64320 Alex Deucher changed: What|Removed |Added Summary|WebGL support in Chrome |WebGL support in Chrome |causes GPU lockup |causes GPU lockup when ||using llvm -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/1c28de12/attachment.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #22 from Michel D?nzer --- (In reply to comment #21) > Yup. Did the same process for the 32-bit drivers. Same result. Works For Me?... Did you verify with LIBGL_DEBUG=verbose that it's picking up the right radeonsi_dri.so? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/17b50108/attachment.html>
[Bug 62466] r600g hyperz lockups with KSP 0.19
https://bugs.freedesktop.org/show_bug.cgi?id=62466 --- Comment #10 from Jerome Glisse --- Patch was against mesa, but patch is now included in mesa except in mesa 9.1 branch, i will push something shortly. If you want to make a donation make one to EFF https://www.eff.org/ Or buy me a beer if you ever bump into me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/2b284d2b/attachment.html>
[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #5 from Jerome Glisse --- 7.10 is old please try with at least 9.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/606c96ff/attachment.html>
[Bug 63979] s3tc not working with radeonsi driver
https://bugs.freedesktop.org/show_bug.cgi?id=63979 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jerome Glisse --- Closing works with what gonna be 3.10 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/ab1e70bf/attachment.html>
[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #6 from runetmember at gmail.com --- Isn't 7.1.0 is latest version of the driver? http://www.x.org/wiki/radeon If you talking about Mesa - sure, I already tried Mesa 9.1.1 and 9.2-git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130507/cdbe96c6/attachment.html>
[PATCH] drm/exynos: fix error return code in exynos_drm_ipp_set_property()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
ipp_create_cmd_work() return ERR_PTR() on error and never return
NULL, so use IS_ERR() instead of IS_ERR_OR_NULL().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 29d2ad3..b0d6431 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -521,20 +521,23 @@ int exynos_drm_ipp_set_property(struct drm_device
*drm_dev, void *data,
c_node->state = IPP_STATE_IDLE;
c_node->start_work = ipp_create_cmd_work();
- if (IS_ERR_OR_NULL(c_node->start_work)) {
+ if (IS_ERR(c_node->start_work)) {
DRM_ERROR("failed to create start work.\n");
+ ret = PTR_ERR(c_node->start_work);
goto err_clear;
}
c_node->stop_work = ipp_create_cmd_work();
- if (IS_ERR_OR_NULL(c_node->stop_work)) {
+ if (IS_ERR(c_node->stop_work)) {
DRM_ERROR("failed to create stop work.\n");
+ ret = PTR_ERR(c_node->stop_work);
goto err_free_start;
}
c_node->event_work = ipp_create_event_work();
- if (IS_ERR_OR_NULL(c_node->event_work)) {
+ if (IS_ERR(c_node->event_work)) {
DRM_ERROR("failed to create event work.\n");
+ ret = PTR_ERR(c_node->event_work);
goto err_free_stop;
}
[PATCH] drm/exynos: fix error return code in exynos_drm_load()
From: Wei Yongjun
Fix to return -ENOMEM in the exynos_plane_init() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ba6d995..3a10373 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -91,8 +91,10 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
unsigned int possible_crtcs = (1 << MAX_CRTC) - 1;
plane = exynos_plane_init(dev, possible_crtcs, false);
- if (!plane)
+ if (!plane) {
+ ret = -ENOMEM;
goto err_release_iommu_mapping;
+ }
}
ret = drm_vblank_init(dev, MAX_CRTC);
[PATCH] drm/exynos: fix error return code in exynos_drm_ipp_set_property()
Hi Wei Yongjun, On 7 May 2013 18:54, Wei Yongjun wrote: > From: Wei Yongjun > > Fix to return a negative error code from the error handling > case instead of 0, as done elsewhere in this function. > ipp_create_cmd_work() return ERR_PTR() on error and never return > NULL, so use IS_ERR() instead of IS_ERR_OR_NULL(). > > Signed-off-by: Wei Yongjun > --- I have submitted a patch [1] to use IS_ERR instead of IS_ERR_OR_NULL() for all incorrect instances in this driver. Please base your patch fixing the return code on top of my patch. [1] http://lists.freedesktop.org/archives/dri-devel/2013-April/038059.html -- With warm regards, Sachin
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Tue, May 7, 2013 at 7:08 AM, Alex Deucher wrote: > On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski > wrote: >> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote: >>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski >>> wrote: On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > > This needs careful review. I don't really know what this code does, nor > do I have the hardware. (I don't understand AGP and the associated > caching implications.) This patch is wrong (I didn't update the matching mtrr_del), and I'm reworking this whole series. But I may need some help on this one: why is the mtrr handle of a map (whatever a map is) exported to userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is userspace supposed to do with it? Do I need to return a valid MTRR register number? Is there any userspace code at all that sets _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment and needs the MTRR, for which the drm driver doesn't already add the MTRR? --Andy >>> >>> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >>> cover it with a write combine MTRR. The whole ioctl is use by some ddx >>> or maybe even directly the XServer to do this mtrr mess in userspace. >> >> Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to >> work fine, but almost nothing uses it. >> >> I'm amazed this stuff works in the current code, though. Apparently >> the memory type (WC or UC) of a drm mapping is determined by the mtrr >> the driver set, but if one part of the BAR is textures or the >> framebuffer and another part is an outgoing command ring, won't one of >> them end up with the wrong memory type? > > A lot of old chips used to put the registers and framebuffer in the > same BAR. IIRC, the xserver and later libpciaccess had workarounds to > deal with this. I think I read the code wrong (so my patch is garbage). Maybe there's actually no problem -- if DRM_AGP and DRM_FRAME_BUFFER are always WC, DRM_REGISTERS is only WC if explicitly requested, and DRM_SHM is always WB, so everything should be covered. Anything using libpciaccess ought to be unaffected by my changes -- I don't want to change /proc/mtrr or the sysfs stuff. The only possible issue is if there's a memtype conflict, but that's nothing new. --Andy
[PATCH] drm: refactor call to request_module
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook
---
drivers/gpu/drm/drm_encoder_slave.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index 48c52f7..0cfb60f 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -54,16 +54,12 @@ int drm_i2c_encoder_init(struct drm_device *dev,
struct i2c_adapter *adap,
const struct i2c_board_info *info)
{
- char modalias[sizeof(I2C_MODULE_PREFIX)
- + I2C_NAME_SIZE];
struct module *module = NULL;
struct i2c_client *client;
struct drm_i2c_encoder_driver *encoder_drv;
int err = 0;
- snprintf(modalias, sizeof(modalias),
-"%s%s", I2C_MODULE_PREFIX, info->type);
- request_module(modalias);
+ request_module("%s%s", I2C_MODULE_PREFIX, info->type);
client = i2c_new_device(adap, info);
if (!client) {
--
1.7.9.5
--
Kees Cook
Chrome OS Security
[PATCH] radeon: Allow disabling UVD
On Tue, May 7, 2013 at 4:44 AM, Christian K?nig wrote: > > The patch shouldn't be necessary because just removing the firmware should > have pretty much the same effect. Soon distros will ship the UVD firmware by default and then users will need to manually remove it and then do the same with every update. Besides, I just discovered that when UVD is enabled suspend resume breaks - tried 3 times with SUMO_uvd loaded - machine suspends but resumes instantly. Without SUMO_uvd.bin - suspends fine and only wakes up when I want it to. > The only case where we indeed seems to have a problem are Macs with > integrated cards, and we can always just blacklist those if the problem > doesn't seems to be solvable. I happen to have the problematic card in my iMac - I'd be glad to provide any info or try any patches. Just let me know. For now I will remove the firmware - I reboot /suspend-resume often and it is a bit annoying to have to go through those mdelays only to fail. Thanks, Parag
