[git pull] drm fix
Hi Linus, just a small fix for a possible oops in radeon. Dave. The following changes since commit 115e8e705e4be071b9e06ff72578e3b603f2ba65: Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 (2012-01-02 12:34:03 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alexander Müller (1): drm/radeon/kms/atom: fix possible segfault in pm setup drivers/gpu/drm/radeon/radeon_atombios.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-)___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38473] [egl] When program ends, monitor is switched off leaving system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=38473 --- Comment #10 from Michel Dänzer 2012-01-03 04:04:58 PST --- (In reply to comment #9) > Just tried to verify this for you Not for me. I asked because it seems to work for me with upstream Git. I just verified again it still does. > with current Debian unstable, but I can't get any EGL/DRM program to run. > Here's an example: > > % EGL_LOG_LEVEL=debug EGL_PLATFORM=drm ./gears_screen > libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl > libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module > array > libEGL debug: added egl_dri2 to module array > libEGL debug: added egl_glx to module array > libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so) > libEGL info: use DRM for display (nil) > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no > usable display) > > Not sure if I'm misconfiguring something here (since EGL_PLATFORM=drm used to > pick up the r600 just fine). I did switch from a Radeon HD 4850 to 6800 in > the > interim, but thought it was supported just fine. Not sure what's up there. Maybe the PCI ID of your new card is missing somewhere on the Mesa 7.11 branch. Anyway, it doesn't seem directly related to this bug report. -- 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 44422] New: periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 Bug #: 44422 Summary: periodic slowdowns in every 30sec Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: aaalmo...@gmail.com Rendering slows down to crawl for <1sec every 30 secs. It affects everything: 3d applications, video playback, 2d drawing (e.g. kpatience), probably because of the compositing. I suspect this is caused by r600g, because my other machine running the same distribution but r300g doesn't have this problem. Current 7.12-dev (git-2cd7e5b) seems to slow down less than 7.11, but the effect remains and it is very noticeable. -- 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 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #1 from Alex Deucher 2012-01-03 06:21:29 PST --- Please attach your xorg log, dmesg output, and glxinfo output. If it happens every 30 seconds, it may be your desktop environment polling the connectors on your video card to see what is connected. They shouldn't be doing that as the driver handles that internally and generates hotplug events automatically. -- 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: radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller wrote: > I'm facing the problem with the radeon drm driver, that I now manually need > to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just > hangs in average up to 8 seconds per minute without any real activity (X or > the video driver just seems to wait for something..). > > Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while > all following Fedora distributions including F16 have this problem. > I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. > > I did compared the sources of those kernels and the only obvious change to > me is in radeon_ring.c: radeon_ring_free_size() where those lines were added > at the top of the function: > if (rdev->wb.enabled) > rdev->cp.rptr = > le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); > > Given the problems I'm seeing (X-Windows hangs for a few seconds every time) > this fits with the idea, that the driver is waiting for a free slot but > can't find any (maybe due to wrong values returned by not-working WB?). > > I'm wondering, if "rdev->wb.enabled" is correct in this place and if > "dev_priv->writeback_works" shouldn't be used instead here? > It's possible that writeback doesn't work on your system in which case no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old UMS drm and is not used by KMS. The KMS code does not test if writeback works prior to enabling it like UMS did. The slow down you are seeing is caused by the driver waiting for the fence to be written back to memory. If writeback does not work, the fence is never written by the hw and the driver has to wait for the fence to time out. Alex > Helge > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: disable writeback on pre-R300 asics
From: Alex Deucher
We often end up missing fences on older asics with
writeback enabled which leads to delays in the userspace
accel code, so just disable it by default on those asics.
Reported-by: Helge Deller
Reported-by: Dave Airlie
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_device.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 5fcf135..420db65 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -228,8 +228,11 @@ int radeon_wb_init(struct radeon_device *rdev)
if (radeon_no_wb == 1)
rdev->wb.enabled = false;
else {
- /* often unreliable on AGP */
if (rdev->flags & RADEON_IS_AGP) {
+ /* often unreliable on AGP */
+ rdev->wb.enabled = false;
+ } else if (rdev->family < CHIP_R300) {
+ /* often unreliable on pre-r300 */
rdev->wb.enabled = false;
} else {
rdev->wb.enabled = true;
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #2 from almos 2012-01-03 07:02:44 PST --- Created attachment 55083 --> https://bugs.freedesktop.org/attachment.cgi?id=55083 dmesg Hmmm... I haven't noticed there are so many call traces in dmesg. Disturbing. -- 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 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #3 from almos 2012-01-03 07:03:33 PST --- Created attachment 55084 --> https://bugs.freedesktop.org/attachment.cgi?id=55084 Xorg.0.log -- 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 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #4 from almos 2012-01-03 07:05:17 PST --- Created attachment 55085 --> https://bugs.freedesktop.org/attachment.cgi?id=55085 glxinfo -- 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 42131] Problem with resizing OpenGL windows when using XCB
https://bugs.freedesktop.org/show_bug.cgi?id=42131
--- Comment #1 from ikrabbe@gmail.com 2012-01-03 07:05:34 PST ---
I can confirm this bug. It seems that there are some internal events, forwarded
to the DRI(2) module that get lost, as xcb doesn't use XEvents. That's why it
works, when you use the Xlib Event Loop { if (XPending(D)) XNextEvent(D,&E); }
with XSetEventQueueOwner(Xlib...);
When you use the xcb event loop mechanism, mesa does not detect the events,
that need to be reacted on by the DRI module.
So after all, this problem has to be solved within mesa, not within xcb.
Obviously there where some experiments that care about xcb and mesa, but I
haven't found a good development branch yet.
What I do about this problem now is to create a glXCreateWindow (overlay) at
full screen size and render my scene into the visible part of the window, by
translation and scaling.
--
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 42131] Problem with resizing OpenGL windows when using XCB
https://bugs.freedesktop.org/show_bug.cgi?id=42131 Alex Deucher changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core -- 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 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #5 from Alex Deucher 2012-01-03 07:18:22 PST --- Does disabling output polling in your desktop environment fix the issue? Try killing upowerd or knotify. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: Add DDC quirk for ASUS RS400
From: Alex Deucher
vbios is missing a ddc entry for the DVI-D port.
Reported by ponyofdeath on IRC.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 81fc100..b9ad45e 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2152,6 +2152,7 @@ static bool radeon_apply_legacy_quirks(struct drm_device
*dev,
struct radeon_i2c_bus_rec *ddc_i2c,
struct radeon_hpd *hpd)
{
+ struct radeon_device *rdev = dev->dev_private;
/* Certain IBM chipset RN50s have a BIOS reporting two VGAs,
one with VGA DDC and one with CRT2 DDC. - kill the CRT2 DDC one */
@@ -2170,6 +2171,14 @@ static bool radeon_apply_legacy_quirks(struct drm_device
*dev,
return false;
}
+ /* ASUS RS400 system with missing DVI port DDC */
+ if (dev->pdev->device == 0x5A41 &&
+ dev->pdev->subsystem_vendor == 0x1043 &&
+ dev->pdev->subsystem_device == 0x81C8) {
+ if (*legacy_connector == CONNECTOR_DVI_D_LEGACY)
+ *ddc_i2c = combios_setup_i2c_bus(rdev, DDC_MONID, 0, 0);
+ }
+
return true;
}
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add DDC quirk for ASUS RS400
Sorry, ignore this one for now.
Alex
On Tue, Jan 3, 2012 at 11:19 AM, wrote:
> From: Alex Deucher
>
> vbios is missing a ddc entry for the DVI-D port.
> Reported by ponyofdeath on IRC.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_combios.c | 9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 81fc100..b9ad45e 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -2152,6 +2152,7 @@ static bool radeon_apply_legacy_quirks(struct
> drm_device *dev,
> struct radeon_i2c_bus_rec *ddc_i2c,
> struct radeon_hpd *hpd)
> {
> + struct radeon_device *rdev = dev->dev_private;
>
> /* Certain IBM chipset RN50s have a BIOS reporting two VGAs,
> one with VGA DDC and one with CRT2 DDC. - kill the CRT2 DDC one */
> @@ -2170,6 +2171,14 @@ static bool radeon_apply_legacy_quirks(struct
> drm_device *dev,
> return false;
> }
>
> + /* ASUS RS400 system with missing DVI port DDC */
> + if (dev->pdev->device == 0x5A41 &&
> + dev->pdev->subsystem_vendor == 0x1043 &&
> + dev->pdev->subsystem_device == 0x81C8) {
> + if (*legacy_connector == CONNECTOR_DVI_D_LEGACY)
> + *ddc_i2c = combios_setup_i2c_bus(rdev, DDC_MONID, 0,
> 0);
> + }
> +
> return true;
> }
>
> --
> 1.7.3.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #6 from almos 2012-01-03 09:06:19 PST --- (In reply to comment #5) > Does disabling output polling in your desktop environment fix the issue? Try > killing upowerd or knotify. I killed both, but the issue remains. How can I disable output polling in kde4? -- 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 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #7 from Alex Deucher 2012-01-03 09:24:43 PST --- I'm not sure off hand. You might try some of these instructions: http://linux-tipps.blogspot.com/2009/03/fixing-high-latency-with-kde4-display.html Alternatively, you could try starting just X (no desktop) in single user mode and see if you are still getting the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
From: Michel Dänzer It can be called from atomic context, e.g. when switching to console for panic output. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 Signed-off-by: Michel Dänzer --- drivers/gpu/drm/radeon/atom.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c index 14cc88a..d99dbb6 100644 --- a/drivers/gpu/drm/radeon/atom.c +++ b/drivers/gpu/drm/radeon/atom.c @@ -666,7 +666,7 @@ static void atom_op_delay(atom_exec_context *ctx, int *ptr, int arg) if (arg == ATOM_UNIT_MICROSEC) udelay(count); else - msleep(count); + mdelay(count); } static void atom_op_div(atom_exec_context *ctx, int *ptr, int arg) -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'
https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #14 from Michel Dänzer 2012-01-03 10:07:36 PST --- (In reply to comment #13) > Yes, this fixes the hang after and MCE, and it shows the error log on the > screen. Great, thanks for testing. Note that in general a bug report shouldn't be resolved before the fix is applied or at least submitted, but anyway I've submitted it now. > Any, clues how to debug this MCE error? Unfortunately not. -- 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] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Tue, 3 Jan 2012 19:04:00 +0100 Michel Dänzer wrote: > From: Michel Dänzer > > It can be called from atomic context, e.g. when switching to console for panic > output. Is this only special cases like a panic - if so can it not be called in a way that distinguishes between normality and nasty cases. mS plus spin loops are horrendous for anyone trying to do real time, or even for keeping the clock straight. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
2012/1/3 Michel Dänzer : > From: Michel Dänzer > > It can be called from atomic context, e.g. when switching to console for panic > output. > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 I wonder how ugly it would be to check for atomic context or not, mdelay is quite a long busy delay to take a CPU, esp wrt to async driver loading stuff. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote: > 2012/1/3 Michel Dänzer : > > From: Michel Dänzer > > > > It can be called from atomic context, e.g. when switching to console for > > panic > > output. > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 > > I wonder how ugly it would be to check for atomic context or not, So do I. :) The comment in include/linux/hardirq.h that ends in 'Do not use in_atomic() in driver code.' sounds rathery scary... -- 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
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Die, 2012-01-03 at 18:09 +, Alan Cox wrote: > On Tue, 3 Jan 2012 19:04:00 +0100 > Michel Dänzer wrote: > > > From: Michel Dänzer > > > > It can be called from atomic context, e.g. when switching to console for > > panic > > output. > > Is this only special cases like a panic - if so can it not be called in a > way that distinguishes between normality and nasty cases. No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in theory it could be indirectly called from anywhere that uses ATOM BIOS. -- 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 44365] Textures aligned/move wrongly in planeshift game
https://bugs.freedesktop.org/show_bug.cgi?id=44365 --- Comment #4 from Michel Dänzer 2012-01-03 10:31:35 PST --- (In reply to comment #3) > Whilst much improved, there are frequent rendering glitches still. Are those glitches a subset of the original ones, or new ones? If the former, feel free to reopen this report with details about what the remaining glitches are. Otherwise, the new glitches should be tracked in a separate report. -- 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 44425] New: Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 Bug #: 44425 Summary: Missing textures not being rendered in planeshift game. Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: freedesk...@darkskiez.co.uk This game has gone from being unplayable in 7.11 to nearly perfect in 7.12 git, however, there is a large section of the game in between towns where you cannot see where you are going, you just get a lot of black, which can sometimes get dirty with old images, sample video supplied. Card: Radeon 6850 Planeshift: ver 0.5.8.1 DRM: [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 on minor 0 OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 7.12-devel (git-bce506f) OpenGL shading language version string: 1.20 Video Capture: http://www.darkskiez.co.uk/planeweird2.mp4 -- 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 44405] Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations
https://bugs.freedesktop.org/show_bug.cgi?id=44405 Michel Dänzer changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #2 from Michel Dänzer 2012-01-03 10:48:47 PST --- Looks like Gallium/Mesa core confusion about whether pipe_surface is a screen or context object. -- 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 44425] Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 --- Comment #1 from Alex Deucher 2012-01-03 11:45:55 PST --- If the game uses compressed textures, you will need to install libtxc_dxtn. -- 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] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Tue, Jan 03, 2012 at 07:16:25PM +0100, Michel Dänzer wrote: > On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote: > > 2012/1/3 Michel Dänzer : > > > From: Michel Dänzer > > > > > > It can be called from atomic context, e.g. when switching to console for > > > panic > > > output. > > > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 > > > > I wonder how ugly it would be to check for atomic context or not, > > So do I. :) The comment in include/linux/hardirq.h that ends in 'Do not > use in_atomic() in driver code.' sounds rathery scary... We already use in_atomic checks in similar delay code in drm/i915 for the same reasons. I think the ugly mess that results from the panic notifier calling into kms code is justification enough to neglect the the comment about not using in_atomic in drivers. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44425] Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 --- Comment #2 from Mark 2012-01-03 12:28:01 UTC --- Thats it working now! I wish there had been a way I could have discovered that, perhaps it should load some other stock texture than a fully transparent, so its at least visible in a non screen-corrupting way, and in a way people could search google and find this answer. -- 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 44425] Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG -- 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 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #8 from almos 2012-01-03 13:08:56 PST --- Now I experimented a bit and found the culprit: the dd-wrt control panel opened in firefox reloads itself every 30 seconds. It seems that page loading (or rendering?) is a real resource hog in firefox, even though this is not a slow machine (see (9) in rfc1925). Closing as notourbug. -- 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: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote:
> Hi Konrad,
>
> On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
> >> This is the first step in defining a dma buffer sharing mechanism.
> >>
> >> A new buffer object dma_buf is added, with operations and API to allow easy
> >> sharing of this buffer object across devices.
> >>
> >> The framework allows:
> >> - different devices to 'attach' themselves to this buffer, to facilitate
> >> backing storage negotiation, using dma_buf_attach() API.
> >
> > Any thoughts of adding facility to track them? So you can see who is using
> > what?
> Not for version 1, but it would be a useful addition once we start
> using this mechanism.
OK. Looking forward to V2.
>
> >
> >> - association of a file pointer with each user-buffer and associated
> >> allocator-defined operations on that buffer. This operation is called
> >> the
> >> 'export' operation.
> >
> > 'create'? or 'alloc' ?
> >
> > export implies an import somwhere and I don't think that is the case here.
> I will rephrase it as suggested by Rob as well.
>
> >
> >> - this exported buffer-object to be shared with the other entity by asking
> >> for
> >> its 'file-descriptor (fd)', and sharing the fd across.
> >> - a received fd to get the buffer object back, where it can be accessed
> >> using
> >> the associated exporter-defined operations.
> >> - the exporter and user to share the scatterlist using map_dma_buf and
> >> unmap_dma_buf operations.
> >>
> >> Atleast one 'attach()' call is required to be made prior to calling the
> >> map_dma_buf() operation.
> >
> > for the whole memory region or just for the device itself?
> Rob has very eloquently and kindly explained it in his reply.
Can you include his words of wisdom in the git description?
>
> >
> >>
>
> >> +/*
> >> + * is_dma_buf_file - Check if struct file* is associated with dma_buf
> >> + */
> >> +static inline int is_dma_buf_file(struct file *file)
> >> +{
> >> + return file->f_op == &dma_buf_fops;
> >> +}
> >> +
> >> +/**
> >
> > Wrong kerneldoc.
> I looked into scripts/kernel-doc, and
> Documentation/kernel-doc-na-HOWTO.txt => both these places mention
> that the kernel-doc comments have to start with /**, and I couldn't
> spot an error in what's wrong with my usage - would you please
> elaborate on what you think is not right?
The issue I had was with '/**' but let me double-check where I learned
that /** was a bad. Either way, it is a style-guide thing and the
Documentation/* trumps what I recall.
> >
>
> >> +/**
> >> + * struct dma_buf_attachment - holds device-buffer attachment data
> >
> > OK, but what is the purpose of it?
> I will add that in the comments.
> >
> >> + * @dmabuf: buffer for this attachment.
> >> + * @dev: device attached to the buffer.
> > ^^^ this
> >> + * @node: list_head to allow manipulation of list of dma_buf_attachment.
> >
> > Just say: "list of dma_buf_attachment"'
> ok.
> >
> >> + * @priv: exporter-specific attachment data.
> >
> > That "exporter-specific.." brings to my mind custom decleration forms. But
> > maybe that is me.
> :) well, in context of dma-buf 'exporter', it makes sense.
Or just private contents of the backend driver. But the naming is not that
important
to inhibit this patch from being merged.
>
> >
> >> + */
> >> +struct dma_buf_attachment {
> >> + struct dma_buf *dmabuf;
> >> + struct device *dev;
> >> + struct list_head node;
> >> + void *priv;
> >> +};
> >
> > Why don't you move the decleration of this below 'struct dma_buf'?
> > It would easier than to read this structure..
> I could do that, but then anyways I will have to do a
> forward-declaration of dma_buf_attachment, since I have to use it in
> dma_buf_ops. If it improves readability, I am happy to move it below
> struct dma_buf
It is more of just making the readability easier. As in reading from top bottom
one. But if it is too ugly, don't bother.
>
> >
> >> +
> >> +/**
> >> + * struct dma_buf_ops - operations possible on struct dma_buf
> >> + * @attach: allows different devices to 'attach' themselves to the given
> >
> > register?
> >> + * buffer. It might return -EBUSY to signal that backing storage
> >> + * is already allocated and incompatible with the requirements
> >
> > Wait.. allocated or attached?
> This and above comment on 'register' are already answered by Rob in
> his explanation of the sequence in earlier reply. [the Documentation
> patch [2/2] also tries to explain it]
OK. Might want to mention the user to look in the Documentation, in case you
don't
already have it.
>
> >
> >> + * of requesting device. [optional]
> >
> > What is optional? The return value? Or the 'attach' call? If the later , say
> > that in the first paragraph.
> >
> ok, sure. it is meant for the attach op.
> >
> >> + * @detach: detach a given device from thi
[Bug 43719] drm-core-next + AGP RV670 = Oops
https://bugs.freedesktop.org/show_bug.cgi?id=43719 --- Comment #2 from Jerome Glisse 2012-01-03 14:40:19 PST --- Created attachment 55095 --> https://bugs.freedesktop.org/attachment.cgi?id=55095 Fix agp on top of ttm tt rework Should fix the bug let me know -- 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: TTM and AGP conflicts
On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote:
>
> > > Hi!
> > >
> > > I updated the openchrome tree and while testing on the AGP system
> > > discovered some interesting problems with the new TTM changes. The
> > > problems center around the ttm_tt_[un]populate which I modeled after the
> > > radeon and nouveau driver.
> > > First problem I noticed was on a AGP system that my ttm_tt_populate
> > > function would oops. Tracking it down I found the problem was the
> > > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my
> > > ttm_tt_populate function would attempt to touch the dma_address it would
> > > oops. The second issue is the assumption of the cast for struct ttm_tt in
> > > both the populate and unpopulate function. For the AGP case the proper
> > > case would be to ttm_agp_backend.
> > > At this point my assumption is the ttm_bo_move function has to be
> > > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all
> > > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau
> > > drivers I don't see that testing happening. Am I just missing something?
> >
> > Happens on AGP radeons as well:
> > https://bugs.freedesktop.org/show_bug.cgi?id=43719
>
> So I'm not crazy, so this needs to be fixed. Here is what my
> understanding of the TTM layer is. My impression is that struct ttm_bo_driver
> handles multiple domains, AGP, pcie etc and in each method you have to
> handle each specific domain you support. Also *move gives the impression of
> moving between these different domains.
> Where as for struct ttm_backend_func was more for allocating from
> a specific domain. Also I never saw a clear way to handle multiple backends.
> For example my AGP systems can also do pci dma as well.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Attached is patch to fix this, so sorry about that, i must have lost my
agp change along the way when working on the patchset. This patch is not
extensively tested, i will do more testing tomorrow on more gpu, might
even found an nvidia agp i can try. Again sorry for breaking this.
Cheers,
Jerome
>From 99a6eee89a43bce155a93ab6d71ea041aac10680 Mon Sep 17 00:00:00 2001
From: Jerome Glisse
Date: Tue, 3 Jan 2012 17:37:37 -0500
Subject: [PATCH] ttm: fix agp since ttm tt rework
ttm tt rework modified the way we allocate and populate the
ttm_tt structure, the AGP side was missing some bit to properly
work. Fix those and fix radeon and nouveau AGP support.
Tested on radeon only so far.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
drivers/gpu/drm/radeon/radeon_ttm.c | 11 +++
drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 +
drivers/gpu/drm/ttm/ttm_tt.c |2 ++
include/drm/ttm/ttm_bo_driver.h |2 ++
5 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8cf4a48..724b41a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1066,6 +1066,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
return ttm_dma_populate((void *)ttm, dev->dev);
@@ -1105,6 +,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate((void *)ttm, dev->dev);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b0ebaf8..dc73d77 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -588,6 +588,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
return 0;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
@@ -624,6 +629,12 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
unsigned i;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
diff --git a/drivers/gpu/d
Re: TTM and AGP conflicts
On Tue, Jan 03, 2012 at 05:43:40PM -0500, Jerome Glisse wrote:
> On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote:
> >
> > > > Hi!
> > > >
> > > > I updated the openchrome tree and while testing on the AGP system
> > > > discovered some interesting problems with the new TTM changes. The
> > > > problems center around the ttm_tt_[un]populate which I modeled after the
> > > > radeon and nouveau driver.
> > > > First problem I noticed was on a AGP system that my
> > > > ttm_tt_populate
> > > > function would oops. Tracking it down I found the problem was the
> > > > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once
> > > > my
> > > > ttm_tt_populate function would attempt to touch the dma_address it would
> > > > oops. The second issue is the assumption of the cast for struct ttm_tt
> > > > in
> > > > both the populate and unpopulate function. For the AGP case the proper
> > > > case would be to ttm_agp_backend.
> > > > At this point my assumption is the ttm_bo_move function has to be
> > > > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all
> > > > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau
> > > > drivers I don't see that testing happening. Am I just missing something?
> > >
> > > Happens on AGP radeons as well:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=43719
> >
> > So I'm not crazy, so this needs to be fixed. Here is what my
> > understanding of the TTM layer is. My impression is that struct
> > ttm_bo_driver
> > handles multiple domains, AGP, pcie etc and in each method you have to
> > handle each specific domain you support. Also *move gives the impression of
> > moving between these different domains.
> > Where as for struct ttm_backend_func was more for allocating from
> > a specific domain. Also I never saw a clear way to handle multiple
> > backends.
> > For example my AGP systems can also do pci dma as well.
>
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Hey Jerome,
Was going to look at this week and see how it performs before (and after)
the squash ttm bind+populate operation. Any thoughts of what benchmarks I
should run?
Fyi, I've some NVidia AGP cards. We both live in Boston so could meet up.
And I could ask you about the patches I sent - not clear if you want to me
squash the patch 2 and 3 together or just redo them diffrently.
>
> Cheers,
> Jerome
> >From 99a6eee89a43bce155a93ab6d71ea041aac10680 Mon Sep 17 00:00:00 2001
> From: Jerome Glisse
> Date: Tue, 3 Jan 2012 17:37:37 -0500
> Subject: [PATCH] ttm: fix agp since ttm tt rework
>
> ttm tt rework modified the way we allocate and populate the
> ttm_tt structure, the AGP side was missing some bit to properly
> work. Fix those and fix radeon and nouveau AGP support.
>
> Tested on radeon only so far.
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
> drivers/gpu/drm/radeon/radeon_ttm.c | 11 +++
> drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 +
> drivers/gpu/drm/ttm/ttm_tt.c |2 ++
> include/drm/ttm/ttm_bo_driver.h |2 ++
> 5 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 8cf4a48..724b41a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1066,6 +1066,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
> dev_priv = nouveau_bdev(ttm->bdev);
> dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + return ttm_agp_tt_populate(ttm);
> + }
> +#endif
> +
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> return ttm_dma_populate((void *)ttm, dev->dev);
> @@ -1105,6 +,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> dev_priv = nouveau_bdev(ttm->bdev);
> dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + ttm_agp_tt_unpopulate(ttm);
> + return;
> + }
> +#endif
> +
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> ttm_dma_unpopulate((void *)ttm, dev->dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b0ebaf8..dc73d77 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -588,6 +588,11 @@ static int radeon_ttm
Re: radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller wrote: > On 01/03/2012 03:27 PM, Alex Deucher wrote: >> >> On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller wrote: >>> >>> I'm facing the problem with the radeon drm driver, that I now manually >>> need >>> to set the kernel module parameter radeon.no_wb to 1 at bootup, else X >>> just >>> hangs in average up to 8 seconds per minute without any real activity (X >>> or >>> the video driver just seems to wait for something..). >>> >>> Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while >>> all following Fedora distributions including F16 have this problem. >>> I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. >>> >>> I did compared the sources of those kernels and the only obvious change >>> to >>> me is in radeon_ring.c: radeon_ring_free_size() where those lines were >>> added >>> at the top of the function: >>> if (rdev->wb.enabled) >>> rdev->cp.rptr = >>> le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); >>> >>> Given the problems I'm seeing (X-Windows hangs for a few seconds every >>> time) >>> this fits with the idea, that the driver is waiting for a free slot but >>> can't find any (maybe due to wrong values returned by not-working WB?). >>> >>> I'm wondering, if "rdev->wb.enabled" is correct in this place and if >>> "dev_priv->writeback_works" shouldn't be used instead here? >>> >> >> It's possible that writeback doesn't work on your system in which case >> no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old >> UMS drm and is not used by KMS. The KMS code does not test if >> writeback works prior to enabling it like UMS did. The slow down you >> are seeing is caused by the driver waiting for the fence to be written >> back to memory. If writeback does not work, the fence is never >> written by the hw and the driver has to wait for the fence to time >> out. > > > Alex, thanks for the explanations. > In my opinion this is a regression then. The old code worked without > problems, while with the new driver (or only because of the added code > lines) the driver doesn't work out of the box. I just posted a patch to disable writeback by default on KMS on pre-R300 chips: http://lists.freedesktop.org/archives/dri-devel/2012-January/017829.html > Wouldn't it be an idea to port over the old UMS writeback-check-test to the > new KMS code base to avoid the issues I'm seeing? Maybe, assuming the writeback test reliably fails which I'm not sure is the case. UMS didn't utilize the hardware to the same extent that KMS does so it was less likely to be an issue there. Alex > I would be willing to test such code or even provide an initial patch if > necessary. > > Helge ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Tue, 03 Jan 2012 19:25:46 +0100 Michel Dänzer wrote: > On Die, 2012-01-03 at 18:09 +, Alan Cox wrote: > > On Tue, 3 Jan 2012 19:04:00 +0100 > > Michel Dänzer wrote: > > > > > From: Michel Dänzer > > > > > > It can be called from atomic context, e.g. when switching to console for > > > panic > > > output. > > > > Is this only special cases like a panic - if so can it not be called in a > > way that distinguishes between normality and nasty cases. > > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > theory it could be indirectly called from anywhere that uses ATOM BIOS. So lets stick to practice, and the real world. Screwing up everything else because of a crappy problem in your Atom BIOS code sucks but hey it happens. screwing up everything because of a theoretical concern is just dumb. I would start by making it some kind of context flag for your interpreter and making people involve the interpreter with a different function call if they can't sleep. At that point you'll be able to define the problem in the real kernel, document the rule and spot further people trying to jump off cliffs before they do. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/9] Remove useless on_each_cpu return value
on_each_cpu() returns as its own return value the return value of smp_call_function(). smp_call_function() in turn returns a hard coded value of zero. Some callers to on_each_cpu() waste cycles and bloat code space by checking the return value to on_each_cpu(), probably for historical reasons. This patch set refactors callers to not test on_each_cpu() (fixed) return value and then refactors on_each_cpu to return void to avoid confusing future users. In other words, this patch aims to delete 18 source code lines while not changing any functionality :-) I tested as best as I could the x86 changes and compiled some of the others, but I don't have access to all the needed hardware for testing. Reviewers and testers welcome! CC: Michal Nazarewicz CC: David Airlie CC: dri-devel@lists.freedesktop.org CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Grant Likely CC: Rob Herring CC: linuxppc-...@lists.ozlabs.org CC: devicetree-disc...@lists.ozlabs.org CC: Richard Henderson CC: Ivan Kokshaysky CC: Matt Turner CC: linux-al...@vger.kernel.org CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: x...@kernel.org CC: Tony Luck CC: Fenghua Yu CC: linux-i...@vger.kernel.org CC: Will Deacon CC: Peter Zijlstra CC: Arnaldo Carvalho de Melo CC: Russell King CC: linux-arm-ker...@lists.infradead.org Gilad Ben-Yossef (9): arm: avoid using on_each_cpu hard coded ret value ia64: avoid using on_each_cpu hard coded ret value x86: avoid using on_each_cpu hard coded ret value alpha: avoid using on_each_cpu hard coded ret value ppc: avoid using on_each_cpu hard coded ret value agp: avoid using on_each_cpu hard coded ret value drm: avoid using on_each_cpu hard coded ret value smp: refactor on_each_cpu to void returning func x86: refactor wbinvd_on_all_cpus to void function arch/alpha/kernel/smp.c |7 ++- arch/arm/kernel/perf_event.c |2 +- arch/ia64/kernel/perfmon.c | 12 ++-- arch/powerpc/kernel/rtas.c |3 +-- arch/x86/include/asm/smp.h |5 ++--- arch/x86/lib/cache-smp.c |4 ++-- drivers/char/agp/generic.c |3 +-- drivers/gpu/drm/drm_cache.c |3 +-- include/linux/smp.h |7 +++ kernel/smp.c |6 ++ 10 files changed, 17 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 7/9] drm: avoid using on_each_cpu hard coded ret value
on_each_cpu always returns a hard coded return code of zero. Removing all tests based on this return value saves run time cycles for compares and code bloat for branches. CC: Michal Nazarewicz CC: David Airlie CC: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_cache.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c index 5928653..668653c 100644 --- a/drivers/gpu/drm/drm_cache.c +++ b/drivers/gpu/drm/drm_cache.c @@ -75,8 +75,7 @@ drm_clflush_pages(struct page *pages[], unsigned long num_pages) return; } - if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0) - printk(KERN_ERR "Timed out waiting for cache flush.\n"); + on_each_cpu(drm_clflush_ipi_handler, NULL, 1); #elif defined(__powerpc__) unsigned long i; -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 8/9] smp: refactor on_each_cpu to void returning func
on_each_cpu returns the retunr value of smp_call_function
which is hard coded to 0.
Refactor on_each_cpu to a void function and the few callers
that check the return value to save compares and branches.
CC: Michal Nazarewicz
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Grant Likely
CC: Rob Herring
CC: linuxppc-...@lists.ozlabs.org
CC: devicetree-disc...@lists.ozlabs.org
CC: Richard Henderson
CC: Ivan Kokshaysky
CC: Matt Turner
CC: linux-al...@vger.kernel.org
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
CC: Tony Luck
CC: Fenghua Yu
CC: linux-i...@vger.kernel.org
CC: Will Deacon
CC: Peter Zijlstra
CC: Arnaldo Carvalho de Melo
CC: Russell King
CC: linux-arm-ker...@lists.infradead.org
---
include/linux/smp.h |7 +++
kernel/smp.c|6 ++
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 8cc38d3..050ddd4 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -99,7 +99,7 @@ static inline void call_function_init(void) { }
/*
* Call a function on all processors
*/
-int on_each_cpu(smp_call_func_t func, void *info, int wait);
+void on_each_cpu(smp_call_func_t func, void *info, int wait);
/*
* Mark the boot cpu "online" so that it can call console drivers in
@@ -126,12 +126,11 @@ static inline int up_smp_call_function(smp_call_func_t
func, void *info)
#define smp_call_function(func, info, wait) \
(up_smp_call_function(func, info))
#define on_each_cpu(func,info,wait)\
- ({ \
+ { \
local_irq_disable();\
func(info); \
local_irq_enable(); \
- 0; \
- })
+ }
static inline void smp_send_reschedule(int cpu) { }
#define num_booting_cpus() 1
#define smp_prepare_boot_cpu() do {} while (0)
diff --git a/kernel/smp.c b/kernel/smp.c
index db197d6..f66a1b2 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -687,17 +687,15 @@ void __init smp_init(void)
* early_boot_irqs_disabled is set. Use local_irq_save/restore() instead
* of local_irq_disable/enable().
*/
-int on_each_cpu(void (*func) (void *info), void *info, int wait)
+void on_each_cpu(void (*func) (void *info), void *info, int wait)
{
unsigned long flags;
- int ret = 0;
preempt_disable();
- ret = smp_call_function(func, info, wait);
+ smp_call_function(func, info, wait);
local_irq_save(flags);
func(info);
local_irq_restore(flags);
preempt_enable();
- return ret;
}
EXPORT_SYMBOL(on_each_cpu);
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/9] Remove useless on_each_cpu return value
On Tue, 03 Jan 2012 15:19:04 +0100, Gilad Ben-Yossef wrote: on_each_cpu() returns as its own return value the return value of smp_call_function(). smp_call_function() in turn returns a hard coded value of zero. Some callers to on_each_cpu() waste cycles and bloat code space by checking the return value to on_each_cpu(), probably for historical reasons. This patch set refactors callers to not test on_each_cpu() (fixed) return value and then refactors on_each_cpu to return void to avoid confusing future users. In other words, this patch aims to delete 18 source code lines while not changing any functionality :-) I tested as best as I could the x86 changes and compiled some of the others, but I don't have access to all the needed hardware for testing. Reviewers and testers welcome! Other then the lack of Signed-off-by in the patches, looks good to me, even though personally I'd choose a bottom-up approach, ie. make smp_call_function() return void and from that conclude that on_each_cpu() can return void. With those patches, we have a situation, where smp_call_function() has a return value which is then lost for no immediately apparent reason lost in on_each_cpu(). -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/9] Remove useless on_each_cpu return value
2012/1/3 Michal Nazarewicz : > On Tue, 03 Jan 2012 15:19:04 +0100, Gilad Ben-Yossef > wrote: >> >> on_each_cpu() returns as its own return value the return value of >> smp_call_function(). smp_call_function() in turn returns a hard >> coded value of zero. >> >> Some callers to on_each_cpu() waste cycles and bloat code space >> by checking the return value to on_each_cpu(), probably for >> historical reasons. >> >> This patch set refactors callers to not test on_each_cpu() >> (fixed) return value and then refactors on_each_cpu to >> return void to avoid confusing future users. >> >> In other words, this patch aims to delete 18 source code lines >> while not changing any functionality :-) >> >> I tested as best as I could the x86 changes and compiled some >> of the others, but I don't have access to all the needed hardware >> for testing. Reviewers and testers welcome! > > > Other then the lack of Signed-off-by in the patches, looks good to me, Blimey! I'll resend with a proper Signed-off-by after more people have a chance to comment. And thanks for the review. > even though personally I'd choose a bottom-up approach, ie. make > smp_call_function() return void and from that conclude that > on_each_cpu() can return void. With those patches, we have a situation, > where smp_call_function() has a return value which is then lost for no > immediately apparent reason lost in on_each_cpu(). There are so many call site of smp_call_function() that do not check the return value right now that I think we can tolerate it for just a little bit longer until that get fixed as well... :-) Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker gi...@benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com "Unfortunately, cache misses are an equal opportunity pain provider." -- Mike Galbraith, LKML ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On 01/03/2012 03:27 PM, Alex Deucher wrote: On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller wrote: I'm facing the problem with the radeon drm driver, that I now manually need to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just hangs in average up to 8 seconds per minute without any real activity (X or the video driver just seems to wait for something..). Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while all following Fedora distributions including F16 have this problem. I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. I did compared the sources of those kernels and the only obvious change to me is in radeon_ring.c: radeon_ring_free_size() where those lines were added at the top of the function: if (rdev->wb.enabled) rdev->cp.rptr = le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); Given the problems I'm seeing (X-Windows hangs for a few seconds every time) this fits with the idea, that the driver is waiting for a free slot but can't find any (maybe due to wrong values returned by not-working WB?). I'm wondering, if "rdev->wb.enabled" is correct in this place and if "dev_priv->writeback_works" shouldn't be used instead here? It's possible that writeback doesn't work on your system in which case no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old UMS drm and is not used by KMS. The KMS code does not test if writeback works prior to enabling it like UMS did. The slow down you are seeing is caused by the driver waiting for the fence to be written back to memory. If writeback does not work, the fence is never written by the hw and the driver has to wait for the fence to time out. Alex, thanks for the explanations. In my opinion this is a regression then. The old code worked without problems, while with the new driver (or only because of the added code lines) the driver doesn't work out of the box. Wouldn't it be an idea to port over the old UMS writeback-check-test to the new KMS code base to avoid the issues I'm seeing? I would be willing to test such code or even provide an initial patch if necessary. Helge ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index 0393721..3508de9 100644
--- a/drivers/gpu/drm/nouveau/nv50_pm.c
+++ b/drivers/gpu/drm/nouveau/nv50_pm.c
@@ -540,7 +540,7 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct
nouveau_pm_level *perflvl)
info->mclk_hwsq.len = 0;
if (perflvl->memory) {
clk = calc_mclk(dev, perflvl->memory, &info->mclk_hwsq);
- if (clk < 0) {
+ if ((int)clk < 0) {
ret = clk;
goto error;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44405] New: Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations
https://bugs.freedesktop.org/show_bug.cgi?id=44405 Bug #: 44405 Summary: Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: marbacz at gmail.com Created attachment 55060 --> https://bugs.freedesktop.org/attachment.cgi?id=55060 gdb bt full I'm using Mesa from git(77058335), r600g on Redwood [Radeon HD 5670], kernel 3.1.5. Spring crashes on startup, with following trace(full trace attached) #7 0x7fd1b9f858d5 in pipe_surface_reference (ptr=0x7fd1ae5a1a58, surf=) at ../../src/gallium/auxiliary/util/u_inlines.h:112 #8 st_renderbuffer_delete (rb=0x7fd1ae5a19b0) at state_tracker/st_cb_fbo.c:181 #9 0x7fd1b9f59c30 in _mesa_reference_renderbuffer_ (ptr=0x7fd1ae596998, rb=0x0) at main/renderbuffer.c:186 #10 0x7fd1b9f30b1e in _mesa_reference_renderbuffer (rb=0x0, ptr=0x7fd1ae596998) at main/renderbuffer.h:62 #11 _mesa_free_framebuffer_data (fb=0x7fd1ae596740) at main/framebuffer.c:216 #12 0x7fd1b9f30bfe in _mesa_destroy_framebuffer (fb=0x7fd1ae596740) at main/framebuffer.c:193 #13 0x7fd1b9f30cb3 in _mesa_reference_framebuffer_ (ptr=0x7fff6a0c34a8, fb=0x0) at main/framebuffer.c:253 #14 0x7fd1b9f2c304 in _mesa_reference_framebuffer (fb=0x0, ptr=0x7fff6a0c34a8) at main/framebuffer.h:62 #15 _mesa_DeleteFramebuffersEXT (n=1, framebuffers=) at main/fbobject.c:1832 and with lots of similar messages in dmesg: [14960.505619] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x136 [14960.505622] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [14960.524494] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x136 [14960.524497] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [14960.758968] unknown[16452]: segfault at 0 ip 00a84204 sp 7fff3e6ac280 error 4 in spring[40+d4a000] attached full trace and glxinfo. Let me know if you need more info. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44405] Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations
https://bugs.freedesktop.org/show_bug.cgi?id=44405 --- Comment #1 from Marcin Baczy?ski 2012-01-02 16:24:22 PST --- Created attachment 55061 --> https://bugs.freedesktop.org/attachment.cgi?id=55061 glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fix
Hi Linus, just a small fix for a possible oops in radeon. Dave. The following changes since commit 115e8e705e4be071b9e06ff72578e3b603f2ba65: Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 (2012-01-02 12:34:03 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alexander M?ller (1): drm/radeon/kms/atom: fix possible segfault in pm setup drivers/gpu/drm/radeon/radeon_atombios.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-)
[Bug 38473] [egl] When program ends, monitor is switched off leaving system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=38473 --- Comment #10 from Michel D?nzer 2012-01-03 04:04:58 PST --- (In reply to comment #9) > Just tried to verify this for you Not for me. I asked because it seems to work for me with upstream Git. I just verified again it still does. > with current Debian unstable, but I can't get any EGL/DRM program to run. > Here's an example: > > % EGL_LOG_LEVEL=debug EGL_PLATFORM=drm ./gears_screen > libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl > libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module > array > libEGL debug: added egl_dri2 to module array > libEGL debug: added egl_glx to module array > libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so) > libEGL info: use DRM for display (nil) > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no > usable display) > > Not sure if I'm misconfiguring something here (since EGL_PLATFORM=drm used to > pick up the r600 just fine). I did switch from a Radeon HD 4850 to 6800 in > the > interim, but thought it was supported just fine. Not sure what's up there. Maybe the PCI ID of your new card is missing somewhere on the Mesa 7.11 branch. Anyway, it doesn't seem directly related to this bug report. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] New: periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 Bug #: 44422 Summary: periodic slowdowns in every 30sec Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: aaalmosss at gmail.com Rendering slows down to crawl for <1sec every 30 secs. It affects everything: 3d applications, video playback, 2d drawing (e.g. kpatience), probably because of the compositing. I suspect this is caused by r600g, because my other machine running the same distribution but r300g doesn't have this problem. Current 7.12-dev (git-2cd7e5b) seems to slow down less than 7.11, but the effect remains and it is very noticeable. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #1 from Alex Deucher 2012-01-03 06:21:29 PST --- Please attach your xorg log, dmesg output, and glxinfo output. If it happens every 30 seconds, it may be your desktop environment polling the connectors on your video card to see what is connected. They shouldn't be doing that as the driver handles that internally and generates hotplug events automatically. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller wrote: > I'm facing the problem with the radeon drm driver, that I now manually need > to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just > hangs in average up to 8 seconds per minute without any real activity (X or > the video driver just seems to wait for something..). > > Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while > all following Fedora distributions including F16 have this problem. > I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. > > I did compared the sources of those kernels and the only obvious change to > me is in radeon_ring.c: radeon_ring_free_size() where those lines were added > at the top of the function: > ? ? ? ?if (rdev->wb.enabled) > ? ? ? ? ? ? ? ?rdev->cp.rptr = > le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); > > Given the problems I'm seeing (X-Windows hangs for a few seconds every time) > this fits with the idea, that the driver is waiting for a free slot but > can't find any (maybe due to wrong values returned by not-working WB?). > > I'm wondering, if "rdev->wb.enabled" is correct in this place and if > "dev_priv->writeback_works" shouldn't be used instead here? > It's possible that writeback doesn't work on your system in which case no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old UMS drm and is not used by KMS. The KMS code does not test if writeback works prior to enabling it like UMS did. The slow down you are seeing is caused by the driver waiting for the fence to be written back to memory. If writeback does not work, the fence is never written by the hw and the driver has to wait for the fence to time out. Alex > Helge > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: disable writeback on pre-R300 asics
From: Alex Deucher
We often end up missing fences on older asics with
writeback enabled which leads to delays in the userspace
accel code, so just disable it by default on those asics.
Reported-by: Helge Deller
Reported-by: Dave Airlie
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_device.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 5fcf135..420db65 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -228,8 +228,11 @@ int radeon_wb_init(struct radeon_device *rdev)
if (radeon_no_wb == 1)
rdev->wb.enabled = false;
else {
- /* often unreliable on AGP */
if (rdev->flags & RADEON_IS_AGP) {
+ /* often unreliable on AGP */
+ rdev->wb.enabled = false;
+ } else if (rdev->family < CHIP_R300) {
+ /* often unreliable on pre-r300 */
rdev->wb.enabled = false;
} else {
rdev->wb.enabled = true;
--
1.7.3.4
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #2 from almos 2012-01-03 07:02:44 PST --- Created attachment 55083 --> https://bugs.freedesktop.org/attachment.cgi?id=55083 dmesg Hmmm... I haven't noticed there are so many call traces in dmesg. Disturbing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #3 from almos 2012-01-03 07:03:33 PST --- Created attachment 55084 --> https://bugs.freedesktop.org/attachment.cgi?id=55084 Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #4 from almos 2012-01-03 07:05:17 PST --- Created attachment 55085 --> https://bugs.freedesktop.org/attachment.cgi?id=55085 glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42131] Problem with resizing OpenGL windows when using XCB
https://bugs.freedesktop.org/show_bug.cgi?id=42131
--- Comment #1 from ikrabbe.ask at gmail.com 2012-01-03 07:05:34 PST ---
I can confirm this bug. It seems that there are some internal events, forwarded
to the DRI(2) module that get lost, as xcb doesn't use XEvents. That's why it
works, when you use the Xlib Event Loop { if (XPending(D)) XNextEvent(D,&E); }
with XSetEventQueueOwner(Xlib...);
When you use the xcb event loop mechanism, mesa does not detect the events,
that need to be reacted on by the DRI module.
So after all, this problem has to be solved within mesa, not within xcb.
Obviously there where some experiments that care about xcb and mesa, but I
haven't found a good development branch yet.
What I do about this problem now is to create a glXCreateWindow (overlay) at
full screen size and render my scene into the visible part of the window, by
translation and scaling.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 42131] Problem with resizing OpenGL windows when using XCB
https://bugs.freedesktop.org/show_bug.cgi?id=42131 Alex Deucher changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #5 from Alex Deucher 2012-01-03 07:18:22 PST --- Does disabling output polling in your desktop environment fix the issue? Try killing upowerd or knotify. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: Add DDC quirk for ASUS RS400
From: Alex Deucher
vbios is missing a ddc entry for the DVI-D port.
Reported by ponyofdeath on IRC.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 81fc100..b9ad45e 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -2152,6 +2152,7 @@ static bool radeon_apply_legacy_quirks(struct drm_device
*dev,
struct radeon_i2c_bus_rec *ddc_i2c,
struct radeon_hpd *hpd)
{
+ struct radeon_device *rdev = dev->dev_private;
/* Certain IBM chipset RN50s have a BIOS reporting two VGAs,
one with VGA DDC and one with CRT2 DDC. - kill the CRT2 DDC one */
@@ -2170,6 +2171,14 @@ static bool radeon_apply_legacy_quirks(struct drm_device
*dev,
return false;
}
+ /* ASUS RS400 system with missing DVI port DDC */
+ if (dev->pdev->device == 0x5A41 &&
+ dev->pdev->subsystem_vendor == 0x1043 &&
+ dev->pdev->subsystem_device == 0x81C8) {
+ if (*legacy_connector == CONNECTOR_DVI_D_LEGACY)
+ *ddc_i2c = combios_setup_i2c_bus(rdev, DDC_MONID, 0, 0);
+ }
+
return true;
}
--
1.7.3.4
[PATCH] drm/radeon/kms: Add DDC quirk for ASUS RS400
Sorry, ignore this one for now.
Alex
On Tue, Jan 3, 2012 at 11:19 AM, wrote:
> From: Alex Deucher
>
> vbios is missing a ddc entry for the DVI-D port.
> Reported by ponyofdeath on IRC.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> ?drivers/gpu/drm/radeon/radeon_combios.c | ? ?9 +
> ?1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 81fc100..b9ad45e 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -2152,6 +2152,7 @@ static bool radeon_apply_legacy_quirks(struct
> drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct radeon_i2c_bus_rec *ddc_i2c,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct radeon_hpd *hpd)
> ?{
> + ? ? ? struct radeon_device *rdev = dev->dev_private;
>
> ? ? ? ?/* Certain IBM chipset RN50s have a BIOS reporting two VGAs,
> ? ? ? ? ? one with VGA DDC and one with CRT2 DDC. - kill the CRT2 DDC one */
> @@ -2170,6 +2171,14 @@ static bool radeon_apply_legacy_quirks(struct
> drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ?return false;
> ? ? ? ?}
>
> + ? ? ? /* ASUS RS400 system with missing DVI port DDC */
> + ? ? ? if (dev->pdev->device == 0x5A41 &&
> + ? ? ? ? ? dev->pdev->subsystem_vendor == 0x1043 &&
> + ? ? ? ? ? dev->pdev->subsystem_device == 0x81C8) {
> + ? ? ? ? ? ? ? if (*legacy_connector == CONNECTOR_DVI_D_LEGACY)
> + ? ? ? ? ? ? ? ? ? ? ? *ddc_i2c = combios_setup_i2c_bus(rdev, DDC_MONID, 0,
> 0);
> + ? ? ? }
> +
> ? ? ? ?return true;
> ?}
>
> --
> 1.7.3.4
>
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #6 from almos 2012-01-03 09:06:19 PST --- (In reply to comment #5) > Does disabling output polling in your desktop environment fix the issue? Try > killing upowerd or knotify. I killed both, but the issue remains. How can I disable output polling in kde4? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 --- Comment #7 from Alex Deucher 2012-01-03 09:24:43 PST --- I'm not sure off hand. You might try some of these instructions: http://linux-tipps.blogspot.com/2009/03/fixing-high-latency-with-kde4-display.html Alternatively, you could try starting just X (no desktop) in single user mode and see if you are still getting the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
From: Michel D?nzer It can be called from atomic context, e.g. when switching to console for panic output. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/atom.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c index 14cc88a..d99dbb6 100644 --- a/drivers/gpu/drm/radeon/atom.c +++ b/drivers/gpu/drm/radeon/atom.c @@ -666,7 +666,7 @@ static void atom_op_delay(atom_exec_context *ctx, int *ptr, int arg) if (arg == ATOM_UNIT_MICROSEC) udelay(count); else - msleep(count); + mdelay(count); } static void atom_op_div(atom_exec_context *ctx, int *ptr, int arg) -- 1.7.7.3
[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'
https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #14 from Michel D?nzer 2012-01-03 10:07:36 PST --- (In reply to comment #13) > Yes, this fixes the hang after and MCE, and it shows the error log on the > screen. Great, thanks for testing. Note that in general a bug report shouldn't be resolved before the fix is applied or at least submitted, but anyway I've submitted it now. > Any, clues how to debug this MCE error? Unfortunately not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Tue, 3 Jan 2012 19:04:00 +0100 Michel D?nzer wrote: > From: Michel D?nzer > > It can be called from atomic context, e.g. when switching to console for panic > output. Is this only special cases like a panic - if so can it not be called in a way that distinguishes between normality and nasty cases. mS plus spin loops are horrendous for anyone trying to do real time, or even for keeping the clock straight.
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
2012/1/3 Michel D?nzer : > From: Michel D?nzer > > It can be called from atomic context, e.g. when switching to console for panic > output. > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 I wonder how ugly it would be to check for atomic context or not, mdelay is quite a long busy delay to take a CPU, esp wrt to async driver loading stuff. Dave.
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote: > 2012/1/3 Michel D?nzer : > > From: Michel D?nzer > > > > It can be called from atomic context, e.g. when switching to console for > > panic > > output. > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 > > I wonder how ugly it would be to check for atomic context or not, So do I. :) The comment in include/linux/hardirq.h that ends in 'Do not use in_atomic() in driver code.' sounds rathery scary... -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Die, 2012-01-03 at 18:09 +, Alan Cox wrote: > On Tue, 3 Jan 2012 19:04:00 +0100 > Michel D?nzer wrote: > > > From: Michel D?nzer > > > > It can be called from atomic context, e.g. when switching to console for > > panic > > output. > > Is this only special cases like a panic - if so can it not be called in a > way that distinguishes between normality and nasty cases. No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in theory it could be indirectly called from anywhere that uses ATOM BIOS. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 44365] Textures aligned/move wrongly in planeshift game
https://bugs.freedesktop.org/show_bug.cgi?id=44365 --- Comment #4 from Michel D?nzer 2012-01-03 10:31:35 PST --- (In reply to comment #3) > Whilst much improved, there are frequent rendering glitches still. Are those glitches a subset of the original ones, or new ones? If the former, feel free to reopen this report with details about what the remaining glitches are. Otherwise, the new glitches should be tracked in a separate report. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44425] New: Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 Bug #: 44425 Summary: Missing textures not being rendered in planeshift game. Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: freedesktop at darkskiez.co.uk This game has gone from being unplayable in 7.11 to nearly perfect in 7.12 git, however, there is a large section of the game in between towns where you cannot see where you are going, you just get a lot of black, which can sometimes get dirty with old images, sample video supplied. Card: Radeon 6850 Planeshift: ver 0.5.8.1 DRM: [drm] Initialized radeon 2.11.0 20080528 for :01:00.0 on minor 0 OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 7.12-devel (git-bce506f) OpenGL shading language version string: 1.20 Video Capture: http://www.darkskiez.co.uk/planeweird2.mp4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44405] Spring RTS crashes using r600g (5670, Redwood), kernel rejects relocations
https://bugs.freedesktop.org/show_bug.cgi?id=44405 Michel D?nzer changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #2 from Michel D?nzer 2012-01-03 10:48:47 PST --- Looks like Gallium/Mesa core confusion about whether pipe_surface is a screen or context object. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44425] Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 --- Comment #1 from Alex Deucher 2012-01-03 11:45:55 PST --- If the game uses compressed textures, you will need to install libtxc_dxtn. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Tue, Jan 03, 2012 at 07:16:25PM +0100, Michel D?nzer wrote: > On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote: > > 2012/1/3 Michel D?nzer : > > > From: Michel D?nzer > > > > > > It can be called from atomic context, e.g. when switching to console for > > > panic > > > output. > > > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 > > > > I wonder how ugly it would be to check for atomic context or not, > > So do I. :) The comment in include/linux/hardirq.h that ends in 'Do not > use in_atomic() in driver code.' sounds rathery scary... We already use in_atomic checks in similar delay code in drm/i915 for the same reasons. I think the ugly mess that results from the panic notifier calling into kms code is justification enough to neglect the the comment about not using in_atomic in drivers. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 44425] Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 --- Comment #2 from Mark 2012-01-03 12:28:01 UTC --- Thats it working now! I wish there had been a way I could have discovered that, perhaps it should load some other stock texture than a fully transparent, so its at least visible in a non screen-corrupting way, and in a way people could search google and find this answer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44425] Missing textures not being rendered in planeshift game.
https://bugs.freedesktop.org/show_bug.cgi?id=44425 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44422] periodic slowdowns in every 30sec
https://bugs.freedesktop.org/show_bug.cgi?id=44422 almos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #8 from almos 2012-01-03 13:08:56 PST --- Now I experimented a bit and found the culprit: the dd-wrt control panel opened in firefox reloads itself every 30 seconds. It seems that page loading (or rendering?) is a real resource hog in firefox, even though this is not a slow machine (see (9) in rfc1925). Closing as notourbug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote:
> Hi Konrad,
>
> On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
> >> This is the first step in defining a dma buffer sharing mechanism.
> >>
> >> A new buffer object dma_buf is added, with operations and API to allow easy
> >> sharing of this buffer object across devices.
> >>
> >> The framework allows:
> >> - different devices to 'attach' themselves to this buffer, to facilitate
> >> ? backing storage negotiation, using dma_buf_attach() API.
> >
> > Any thoughts of adding facility to track them? So you can see who is using
> > what?
> Not for version 1, but it would be a useful addition once we start
> using this mechanism.
OK. Looking forward to V2.
>
> >
> >> - association of a file pointer with each user-buffer and associated
> >> ? ?allocator-defined operations on that buffer. This operation is called
> >> the
> >> ? ?'export' operation.
> >
> > ?'create'? or 'alloc' ?
> >
> > export implies an import somwhere and I don't think that is the case here.
> I will rephrase it as suggested by Rob as well.
>
> >
> >> - this exported buffer-object to be shared with the other entity by asking
> >> for
> >> ? ?its 'file-descriptor (fd)', and sharing the fd across.
> >> - a received fd to get the buffer object back, where it can be accessed
> >> using
> >> ? ?the associated exporter-defined operations.
> >> - the exporter and user to share the scatterlist using map_dma_buf and
> >> ? ?unmap_dma_buf operations.
> >>
> >> Atleast one 'attach()' call is required to be made prior to calling the
> >> map_dma_buf() operation.
> >
> > for the whole memory region or just for the device itself?
> Rob has very eloquently and kindly explained it in his reply.
Can you include his words of wisdom in the git description?
>
> >
> >>
>
> >> +/*
> >> + * is_dma_buf_file - Check if struct file* is associated with dma_buf
> >> + */
> >> +static inline int is_dma_buf_file(struct file *file)
> >> +{
> >> + ? ? return file->f_op == &dma_buf_fops;
> >> +}
> >> +
> >> +/**
> >
> > Wrong kerneldoc.
> I looked into scripts/kernel-doc, and
> Documentation/kernel-doc-na-HOWTO.txt => both these places mention
> that the kernel-doc comments have to start with /**, and I couldn't
> spot an error in what's wrong with my usage - would you please
> elaborate on what you think is not right?
The issue I had was with '/**' but let me double-check where I learned
that /** was a bad. Either way, it is a style-guide thing and the
Documentation/* trumps what I recall.
> >
>
> >> +/**
> >> + * struct dma_buf_attachment - holds device-buffer attachment data
> >
> > OK, but what is the purpose of it?
> I will add that in the comments.
> >
> >> + * @dmabuf: buffer for this attachment.
> >> + * @dev: device attached to the buffer.
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^ this
> >> + * @node: list_head to allow manipulation of list of dma_buf_attachment.
> >
> > Just say: "list of dma_buf_attachment"'
> ok.
> >
> >> + * @priv: exporter-specific attachment data.
> >
> > That "exporter-specific.." brings to my mind custom decleration forms. But
> > maybe that is me.
> :) well, in context of dma-buf 'exporter', it makes sense.
Or just private contents of the backend driver. But the naming is not that
important
to inhibit this patch from being merged.
>
> >
> >> + */
> >> +struct dma_buf_attachment {
> >> + ? ? struct dma_buf *dmabuf;
> >> + ? ? struct device *dev;
> >> + ? ? struct list_head node;
> >> + ? ? void *priv;
> >> +};
> >
> > Why don't you move the decleration of this below 'struct dma_buf'?
> > It would easier than to read this structure..
> I could do that, but then anyways I will have to do a
> forward-declaration of dma_buf_attachment, since I have to use it in
> dma_buf_ops. If it improves readability, I am happy to move it below
> struct dma_buf
It is more of just making the readability easier. As in reading from top bottom
one. But if it is too ugly, don't bother.
>
> >
> >> +
> >> +/**
> >> + * struct dma_buf_ops - operations possible on struct dma_buf
> >> + * @attach: allows different devices to 'attach' themselves to the given
> >
> > register?
> >> + * ? ? ? buffer. It might return -EBUSY to signal that backing storage
> >> + * ? ? ? is already allocated and incompatible with the requirements
> >
> > Wait.. allocated or attached?
> This and above comment on 'register' are already answered by Rob in
> his explanation of the sequence in earlier reply. [the Documentation
> patch [2/2] also tries to explain it]
OK. Might want to mention the user to look in the Documentation, in case you
don't
already have it.
>
> >
> >> + * ? ? ? of requesting device. [optional]
> >
> > What is optional? The return value? Or the 'attach' call? If the later , say
> > that in the first paragraph.
> >
> ok, sure. it is meant for the attach op.
> >
> >> + * @detach: detach a given device from thi
[Bug 43719] drm-core-next + AGP RV670 = Oops
https://bugs.freedesktop.org/show_bug.cgi?id=43719 --- Comment #2 from Jerome Glisse 2012-01-03 14:40:19 PST --- Created attachment 55095 --> https://bugs.freedesktop.org/attachment.cgi?id=55095 Fix agp on top of ttm tt rework Should fix the bug let me know -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
TTM and AGP conflicts
On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote: > > > > Hi! > > > > > > ? ? ? ?I updated the openchrome tree and while testing on the AGP system > > > discovered some interesting problems with the new TTM changes. The > > > problems center around the ttm_tt_[un]populate which I modeled after the > > > radeon and nouveau driver. > > > ? ? ? ?First problem I noticed was on a AGP system that my ttm_tt_populate > > > function would oops. Tracking it down I found the problem was the > > > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my > > > ttm_tt_populate function would attempt to touch the dma_address it would > > > oops. The second issue is the assumption of the cast for struct ttm_tt in > > > both the populate and unpopulate function. For the AGP case the proper > > > case would be to ttm_agp_backend. > > > ? ? ? ?At this point my assumption is the ttm_bo_move function has to be > > > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all > > > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau > > > drivers I don't see that testing happening. Am I just missing something? > > > > Happens on AGP radeons as well: > > https://bugs.freedesktop.org/show_bug.cgi?id=43719 > > So I'm not crazy, so this needs to be fixed. Here is what my > understanding of the TTM layer is. My impression is that struct ttm_bo_driver > handles multiple domains, AGP, pcie etc and in each method you have to > handle each specific domain you support. Also *move gives the impression of > moving between these different domains. > Where as for struct ttm_backend_func was more for allocating from > a specific domain. Also I never saw a clear way to handle multiple backends. > For example my AGP systems can also do pci dma as well. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel Attached is patch to fix this, so sorry about that, i must have lost my agp change along the way when working on the patchset. This patch is not extensively tested, i will do more testing tomorrow on more gpu, might even found an nvidia agp i can try. Again sorry for breaking this. Cheers, Jerome
[PATCH] ttm: fix agp since ttm tt rework
ttm tt rework modified the way we allocate and populate the
ttm_tt structure, the AGP side was missing some bit to properly
work. Fix those and fix radeon and nouveau AGP support.
Tested on radeon only so far.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
drivers/gpu/drm/radeon/radeon_ttm.c | 11 +++
drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 +
drivers/gpu/drm/ttm/ttm_tt.c |2 ++
include/drm/ttm/ttm_bo_driver.h |2 ++
5 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8cf4a48..724b41a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1066,6 +1066,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
return ttm_dma_populate((void *)ttm, dev->dev);
@@ -1105,6 +,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate((void *)ttm, dev->dev);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b0ebaf8..dc73d77 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -588,6 +588,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
return 0;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
@@ -624,6 +629,12 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
unsigned i;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 14ebd36..747c141 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -31,6 +31,7 @@
#include "ttm/ttm_module.h"
#include "ttm/ttm_bo_driver.h"
+#include "ttm/ttm_page_alloc.h"
#ifdef TTM_HAS_AGP
#include "ttm/ttm_placement.h"
#include
@@ -97,6 +98,7 @@ static void ttm_agp_destroy(struct ttm_tt *ttm)
if (agp_be->mem)
ttm_agp_unbind(ttm);
+ ttm_tt_fini(ttm);
kfree(agp_be);
}
@@ -129,4 +131,19 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device
*bdev,
}
EXPORT_SYMBOL(ttm_agp_tt_create);
+int ttm_agp_tt_populate(struct ttm_tt *ttm)
+{
+ if (ttm->state != tt_unpopulated)
+ return 0;
+
+ return ttm_pool_populate(ttm);
+}
+EXPORT_SYMBOL(ttm_agp_tt_populate);
+
+void ttm_agp_tt_unpopulate(struct ttm_tt *ttm)
+{
+ ttm_pool_unpopulate(ttm);
+}
+EXPORT_SYMBOL(ttm_agp_tt_unpopulate);
+
#endif
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 58e1fa1..2f75d20 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -191,6 +191,7 @@ int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device
*bdev,
ttm->page_flags = page_flags;
ttm->dummy_read_page = dummy_read_page;
ttm->state = tt_unpopulated;
+ ttm->swap_storage = NULL;
ttm_tt_alloc_page_directory(ttm);
if (!ttm->pages) {
@@ -222,6 +223,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct
ttm_bo_device *bdev,
ttm->page_flags = page_flags;
ttm->dummy_read_page = dummy_read_page;
ttm->state = tt_unpopulated;
+ ttm->swap_storage = NULL;
INIT_LIST_HEAD(&ttm_dma->pages_list);
ttm_dma_tt_alloc_page_directory(ttm_dma);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 2be8891..d43e892 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -1030,6 +1030,8 @@ extern struct ttm_tt *ttm_agp_tt_create(struct
ttm_bo_device *bdev,
struct agp_bridge_data *bridge,
unsigned long size, uint32_t page_flags,
struct page *dummy_read_page);
+int ttm_agp_tt_populate(struct ttm_tt *ttm);
+void ttm_agp_tt_unpopulate(struct ttm_tt *ttm);
#endif
#endif
--
1.7.5.4
--qDbXVdCdHGoSgWSk--
TTM and AGP conflicts
On Tue, Jan 03, 2012 at 05:43:40PM -0500, Jerome Glisse wrote:
> On Fri, Dec 23, 2011 at 01:19:43AM +, James Simmons wrote:
> >
> > > > Hi!
> > > >
> > > > ? ? ? ?I updated the openchrome tree and while testing on the AGP system
> > > > discovered some interesting problems with the new TTM changes. The
> > > > problems center around the ttm_tt_[un]populate which I modeled after the
> > > > radeon and nouveau driver.
> > > > ? ? ? ?First problem I noticed was on a AGP system that my
> > > > ttm_tt_populate
> > > > function would oops. Tracking it down I found the problem was the
> > > > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once
> > > > my
> > > > ttm_tt_populate function would attempt to touch the dma_address it would
> > > > oops. The second issue is the assumption of the cast for struct ttm_tt
> > > > in
> > > > both the populate and unpopulate function. For the AGP case the proper
> > > > case would be to ttm_agp_backend.
> > > > ? ? ? ?At this point my assumption is the ttm_bo_move function has to be
> > > > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all
> > > > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau
> > > > drivers I don't see that testing happening. Am I just missing something?
> > >
> > > Happens on AGP radeons as well:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=43719
> >
> > So I'm not crazy, so this needs to be fixed. Here is what my
> > understanding of the TTM layer is. My impression is that struct
> > ttm_bo_driver
> > handles multiple domains, AGP, pcie etc and in each method you have to
> > handle each specific domain you support. Also *move gives the impression of
> > moving between these different domains.
> > Where as for struct ttm_backend_func was more for allocating from
> > a specific domain. Also I never saw a clear way to handle multiple
> > backends.
> > For example my AGP systems can also do pci dma as well.
>
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Hey Jerome,
Was going to look at this week and see how it performs before (and after)
the squash ttm bind+populate operation. Any thoughts of what benchmarks I
should run?
Fyi, I've some NVidia AGP cards. We both live in Boston so could meet up.
And I could ask you about the patches I sent - not clear if you want to me
squash the patch 2 and 3 together or just redo them diffrently.
>
> Cheers,
> Jerome
> >From 99a6eee89a43bce155a93ab6d71ea041aac10680 Mon Sep 17 00:00:00 2001
> From: Jerome Glisse
> Date: Tue, 3 Jan 2012 17:37:37 -0500
> Subject: [PATCH] ttm: fix agp since ttm tt rework
>
> ttm tt rework modified the way we allocate and populate the
> ttm_tt structure, the AGP side was missing some bit to properly
> work. Fix those and fix radeon and nouveau AGP support.
>
> Tested on radeon only so far.
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
> drivers/gpu/drm/radeon/radeon_ttm.c | 11 +++
> drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 +
> drivers/gpu/drm/ttm/ttm_tt.c |2 ++
> include/drm/ttm/ttm_bo_driver.h |2 ++
> 5 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 8cf4a48..724b41a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1066,6 +1066,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
> dev_priv = nouveau_bdev(ttm->bdev);
> dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + return ttm_agp_tt_populate(ttm);
> + }
> +#endif
> +
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> return ttm_dma_populate((void *)ttm, dev->dev);
> @@ -1105,6 +,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> dev_priv = nouveau_bdev(ttm->bdev);
> dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + ttm_agp_tt_unpopulate(ttm);
> + return;
> + }
> +#endif
> +
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> ttm_dma_unpopulate((void *)ttm, dev->dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b0ebaf8..dc73d77 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -588,6 +588,11 @@ static int radeon_
radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller wrote: > On 01/03/2012 03:27 PM, Alex Deucher wrote: >> >> On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller ?wrote: >>> >>> I'm facing the problem with the radeon drm driver, that I now manually >>> need >>> to set the kernel module parameter radeon.no_wb to 1 at bootup, else X >>> just >>> hangs in average up to 8 seconds per minute without any real activity (X >>> or >>> the video driver just seems to wait for something..). >>> >>> Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while >>> all following Fedora distributions including F16 have this problem. >>> I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. >>> >>> I did compared the sources of those kernels and the only obvious change >>> to >>> me is in radeon_ring.c: radeon_ring_free_size() where those lines were >>> added >>> at the top of the function: >>> ? ? ? ?if (rdev->wb.enabled) >>> ? ? ? ? ? ? ? ?rdev->cp.rptr = >>> le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); >>> >>> Given the problems I'm seeing (X-Windows hangs for a few seconds every >>> time) >>> this fits with the idea, that the driver is waiting for a free slot but >>> can't find any (maybe due to wrong values returned by not-working WB?). >>> >>> I'm wondering, if "rdev->wb.enabled" is correct in this place and if >>> "dev_priv->writeback_works" shouldn't be used instead here? >>> >> >> It's possible that writeback doesn't work on your system in which case >> no_wb=1 is apprioriate. ?dev_priv->writeback_works is part of the old >> UMS drm and is not used by KMS. ?The KMS code does not test if >> writeback works prior to enabling it like UMS did. ?The slow down you >> are seeing is caused by the driver waiting for the fence to be written >> back to memory. ?If writeback does not work, the fence is never >> written by the hw and the driver has to wait for the fence to time >> out. > > > Alex, thanks for the explanations. > In my opinion this is a regression then. The old code worked without > problems, while with the new driver (or only because of the added code > lines) the driver doesn't work out of the box. I just posted a patch to disable writeback by default on KMS on pre-R300 chips: http://lists.freedesktop.org/archives/dri-devel/2012-January/017829.html > Wouldn't it be an idea to port over the old UMS writeback-check-test to the > new KMS code base to avoid the issues I'm seeing? Maybe, assuming the writeback test reliably fails which I'm not sure is the case. UMS didn't utilize the hardware to the same extent that KMS does so it was less likely to be an issue there. Alex > I would be willing to test such code or even provide an initial patch if > necessary. > > Helge
[RFC PATCH 0/9] Remove useless on_each_cpu return value
2012/1/3 Michal Nazarewicz : > On Tue, 03 Jan 2012 15:19:04 +0100, Gilad Ben-Yossef > wrote: >> >> on_each_cpu() returns as its own return value the return value of >> smp_call_function(). smp_call_function() in turn returns a hard >> coded value of zero. >> >> Some callers to on_each_cpu() waste cycles and bloat code space >> by checking the return value to on_each_cpu(), probably for >> historical reasons. >> >> This patch set refactors callers to not test on_each_cpu() >> (fixed) return value and then refactors on_each_cpu to >> return void to avoid confusing future users. >> >> In other words, this patch aims to delete 18 source code lines >> while not changing any functionality :-) >> >> I tested as best as I could the x86 changes and compiled some >> of the others, but I don't have access to all the needed hardware >> for testing. Reviewers and testers welcome! > > > Other then the lack of Signed-off-by in the patches, looks good to me, Blimey! I'll resend with a proper Signed-off-by after more people have a chance to comment. And thanks for the review. > even though personally I'd choose a bottom-up approach, ie. make > smp_call_function() return void and from that conclude that > on_each_cpu() can return void. ?With those patches, we have a situation, > where smp_call_function() has a return value which is then lost for no > immediately apparent reason lost in on_each_cpu(). There are so many call site of smp_call_function() that do not check the return value right now that I think we can tolerate it for just a little bit longer until that get fixed as well... :-) Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker gilad at benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com "Unfortunately, cache misses are an equal opportunity pain provider." -- Mike Galbraith, LKML
[RFC PATCH 0/9] Remove useless on_each_cpu return value
on_each_cpu() returns as its own return value the return value of smp_call_function(). smp_call_function() in turn returns a hard coded value of zero. Some callers to on_each_cpu() waste cycles and bloat code space by checking the return value to on_each_cpu(), probably for historical reasons. This patch set refactors callers to not test on_each_cpu() (fixed) return value and then refactors on_each_cpu to return void to avoid confusing future users. In other words, this patch aims to delete 18 source code lines while not changing any functionality :-) I tested as best as I could the x86 changes and compiled some of the others, but I don't have access to all the needed hardware for testing. Reviewers and testers welcome! CC: Michal Nazarewicz CC: David Airlie CC: dri-devel at lists.freedesktop.org CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Grant Likely CC: Rob Herring CC: linuxppc-dev at lists.ozlabs.org CC: devicetree-discuss at lists.ozlabs.org CC: Richard Henderson CC: Ivan Kokshaysky CC: Matt Turner CC: linux-alpha at vger.kernel.org CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: x86 at kernel.org CC: Tony Luck CC: Fenghua Yu CC: linux-ia64 at vger.kernel.org CC: Will Deacon CC: Peter Zijlstra CC: Arnaldo Carvalho de Melo CC: Russell King CC: linux-arm-kernel at lists.infradead.org Gilad Ben-Yossef (9): arm: avoid using on_each_cpu hard coded ret value ia64: avoid using on_each_cpu hard coded ret value x86: avoid using on_each_cpu hard coded ret value alpha: avoid using on_each_cpu hard coded ret value ppc: avoid using on_each_cpu hard coded ret value agp: avoid using on_each_cpu hard coded ret value drm: avoid using on_each_cpu hard coded ret value smp: refactor on_each_cpu to void returning func x86: refactor wbinvd_on_all_cpus to void function arch/alpha/kernel/smp.c |7 ++- arch/arm/kernel/perf_event.c |2 +- arch/ia64/kernel/perfmon.c | 12 ++-- arch/powerpc/kernel/rtas.c |3 +-- arch/x86/include/asm/smp.h |5 ++--- arch/x86/lib/cache-smp.c |4 ++-- drivers/char/agp/generic.c |3 +-- drivers/gpu/drm/drm_cache.c |3 +-- include/linux/smp.h |7 +++ kernel/smp.c |6 ++ 10 files changed, 17 insertions(+), 35 deletions(-)
[RFC PATCH 7/9] drm: avoid using on_each_cpu hard coded ret value
on_each_cpu always returns a hard coded return code of zero. Removing all tests based on this return value saves run time cycles for compares and code bloat for branches. CC: Michal Nazarewicz CC: David Airlie CC: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_cache.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c index 5928653..668653c 100644 --- a/drivers/gpu/drm/drm_cache.c +++ b/drivers/gpu/drm/drm_cache.c @@ -75,8 +75,7 @@ drm_clflush_pages(struct page *pages[], unsigned long num_pages) return; } - if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0) - printk(KERN_ERR "Timed out waiting for cache flush.\n"); + on_each_cpu(drm_clflush_ipi_handler, NULL, 1); #elif defined(__powerpc__) unsigned long i; -- 1.7.0.4
[RFC PATCH 8/9] smp: refactor on_each_cpu to void returning func
on_each_cpu returns the retunr value of smp_call_function
which is hard coded to 0.
Refactor on_each_cpu to a void function and the few callers
that check the return value to save compares and branches.
CC: Michal Nazarewicz
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Grant Likely
CC: Rob Herring
CC: linuxppc-dev at lists.ozlabs.org
CC: devicetree-discuss at lists.ozlabs.org
CC: Richard Henderson
CC: Ivan Kokshaysky
CC: Matt Turner
CC: linux-alpha at vger.kernel.org
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x86 at kernel.org
CC: Tony Luck
CC: Fenghua Yu
CC: linux-ia64 at vger.kernel.org
CC: Will Deacon
CC: Peter Zijlstra
CC: Arnaldo Carvalho de Melo
CC: Russell King
CC: linux-arm-kernel at lists.infradead.org
---
include/linux/smp.h |7 +++
kernel/smp.c|6 ++
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 8cc38d3..050ddd4 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -99,7 +99,7 @@ static inline void call_function_init(void) { }
/*
* Call a function on all processors
*/
-int on_each_cpu(smp_call_func_t func, void *info, int wait);
+void on_each_cpu(smp_call_func_t func, void *info, int wait);
/*
* Mark the boot cpu "online" so that it can call console drivers in
@@ -126,12 +126,11 @@ static inline int up_smp_call_function(smp_call_func_t
func, void *info)
#define smp_call_function(func, info, wait) \
(up_smp_call_function(func, info))
#define on_each_cpu(func,info,wait)\
- ({ \
+ { \
local_irq_disable();\
func(info); \
local_irq_enable(); \
- 0; \
- })
+ }
static inline void smp_send_reschedule(int cpu) { }
#define num_booting_cpus() 1
#define smp_prepare_boot_cpu() do {} while (0)
diff --git a/kernel/smp.c b/kernel/smp.c
index db197d6..f66a1b2 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -687,17 +687,15 @@ void __init smp_init(void)
* early_boot_irqs_disabled is set. Use local_irq_save/restore() instead
* of local_irq_disable/enable().
*/
-int on_each_cpu(void (*func) (void *info), void *info, int wait)
+void on_each_cpu(void (*func) (void *info), void *info, int wait)
{
unsigned long flags;
- int ret = 0;
preempt_disable();
- ret = smp_call_function(func, info, wait);
+ smp_call_function(func, info, wait);
local_irq_save(flags);
func(info);
local_irq_restore(flags);
preempt_enable();
- return ret;
}
EXPORT_SYMBOL(on_each_cpu);
--
1.7.0.4
[RFC PATCH 0/9] Remove useless on_each_cpu return value
On Tue, 03 Jan 2012 15:19:04 +0100, Gilad Ben-Yossef wrote: > on_each_cpu() returns as its own return value the return value of > smp_call_function(). smp_call_function() in turn returns a hard > coded value of zero. > > Some callers to on_each_cpu() waste cycles and bloat code space > by checking the return value to on_each_cpu(), probably for > historical reasons. > > This patch set refactors callers to not test on_each_cpu() > (fixed) return value and then refactors on_each_cpu to > return void to avoid confusing future users. > > In other words, this patch aims to delete 18 source code lines > while not changing any functionality :-) > > I tested as best as I could the x86 changes and compiled some > of the others, but I don't have access to all the needed hardware > for testing. Reviewers and testers welcome! Other then the lack of Signed-off-by in the patches, looks good to me, even though personally I'd choose a bottom-up approach, ie. make smp_call_function() return void and from that conclude that on_each_cpu() can return void. With those patches, we have a situation, where smp_call_function() has a return value which is then lost for no immediately apparent reason lost in on_each_cpu(). -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Micha? ?mina86? Nazarewicz(o o) ooo +--ooO--(_)--Ooo--
