Re: [PATCHES] radeon kms pm patches
On Fri, Mar 26, 2010 at 08:49:21PM +0100, Rafał Miłecki wrote: Is this possible reclocking memory in wrong moment (so missing VBLANK probably) cause lock up? I experienced few already, when I forced myself to use this code ignoring corruptions. Any other idea what can cause lock up? I'm 100% sure it's memory reclocking code related. The first thing is that memory reclocking is definitely missing vblank occasionally - but sometimes that's because the interrupt fires before we get there, and sometimes it's because we're scheduled later. I have some fixes for that. Other corruption is likely to be due to the engine reclocking, which seems to also need to be done in vblank. As far as the lockups go, I think this is due to memory access during reclock. Nothing should be coming from the cp, but we may be getting accesses from the crtc if we miss vblank (there's a bit in the crtc control that can deal with this), but more importantly we're doing nothing to prevent unaccelerated fallbacks touching vram during reclock. I can provoke lockups more easily using x11perf which probably triggers several of those, so I lean towards that being something we need to fix before looking for other potential issues. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
On Fri, 2010-03-26 at 19:56 +, Matthew Garrett wrote: As far as the lockups go, I think this is due to memory access during reclock. Nothing should be coming from the cp, but we may be getting accesses from the crtc if we miss vblank (there's a bit in the crtc control that can deal with this), but more importantly we're doing nothing to prevent unaccelerated fallbacks touching vram during reclock. I can provoke lockups more easily using x11perf which probably triggers several of those, so I lean towards that being something we need to fix before looking for other potential issues. Have you tried making RADEONPrepareAccess_CS() in the X driver always return FALSE (you may also need to prevent RADEONUploadToScreenCS() from returning FALSE if the BO isn't busy) to confirm this? That should prevent any direct CPU access to VRAM, at least as long as you don't hit any software fallbacks in the 3D driver. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 17:40 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/3/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. yeah, the similar to what I saw with dualhead. I guess we are either missing the vblank window or the reclock is taking too much time. I wonder if it would make sense to wait for a vline rather than vblank, say a vline 1/2 or 2/3 of the way down the screen, to give us some buffer time between calling the reclock function and whatever setup it does and the beginning of the actual vblank period. Did you play with this some more? Is this possible reclocking memory in wrong moment (so missing VBLANK probably) cause lock up? I experienced few already, when I forced myself to use this code ignoring corruptions. Any other idea what can cause lock up? I'm 100% sure it's memory reclocking code related. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/26 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 17:40 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/3/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. yeah, the similar to what I saw with dualhead. I guess we are either missing the vblank window or the reclock is taking too much time. I wonder if it would make sense to wait for a vline rather than vblank, say a vline 1/2 or 2/3 of the way down the screen, to give us some buffer time between calling the reclock function and whatever setup it does and the beginning of the actual vblank period. Did you play with this some more? Is this possible reclocking memory in wrong moment (so missing VBLANK probably) cause lock up? I experienced few already, when I forced myself to use this code ignoring corruptions. Any other idea what can cause lock up? I'm 100% sure it's memory reclocking code related. I get occasional lockups as well with the memory reclock. I suspect we may have to disable crtc mem requests when changing the mclk, but I haven't really had a change to play more with this. Matthew's been looking it some more this week. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 04:27 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
2010/3/17 Rafał Miłecki zaj...@gmail.com:
2010/3/17 Alex Deucher alexdeuc...@gmail.com
Another set of updated patches against drm-radeon-testing:
http://people.freedesktop.org/~agd5f/pm2/
These implement much the remaining pm functionality. So far they are
working well here.
these patches add:
- memory reclocking
- pcie lane changes
- update display watermarks as bandwidth changes
- allow power management with multi-head
- reset power mode on exit
It seems memory reclocking and SIMDs setting is disabled for r6xx with
currently available patches...?
It re-clocks memory (for single head anyway), r600_set_power_state():
/* set memory clock */
if (rdev-asic-set_memory_clock (mclk !=
rdev-pm.current_mclk)) {
radeon_sync_with_vblank(rdev);
radeon_pm_debug_check_in_vbl(rdev, false);
radeon_set_memory_clock(rdev, mclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev-pm.current_mclk = mclk;
DRM_INFO(Setting: m: %d\n, mclk);
}
The simd stuff is still disabled at the moment.
Whoops, I missed one patch. My mistake.
--
Rafał
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
Hi, the last days I am testing Alex's pm2-patches with Linus-tree - this report based on patchset as of 17-Mar-2010 22:42 [0]. Unfortunately, I cannot load radeon kernel-module with dynpm=1 (0 = disabled works fine). All testing was done in init-3 in a virtual-console. Looking into the log-files show (a) regression(s). I have prepared patches against Linux-2.6.34-rc1 [1] and also attached logs in [2]. The agdf5-pm2-with-linustree.tar.bz2 tarball contains all data (see [3]). Have fun. Kind Regards, - Sedat - References: -- [0] http://people.freedesktop.org/~agd5f/pm2/ [1] http://files.iniza.org/agdf5-pm2-with-linustree/patches/ [2] http://files.iniza.org/agdf5-pm2-with-linustree/logs/ [3] http://files.iniza.org/agdf5-pm2-with-linustree/archive/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
[1] shows: ... Mar 18 10:07:35 seduxbox kernel: [ 127.005632] [drm:r500_hw_i2c_xfer], i2c write error 0x0002 ... - Sedat - [1] http://files.iniza.org/agdf5-pm2-with-linustree/logs/debug.txt -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
Hi, hereby my new experiences with my RV515. # lspci -nnvv | grep VGA compatible controller 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M52 [Mobility Radeon X1300] [1002:714a] (prog-if 00 [VGA controller]) I applied [PATCH] drm/radeon/kms: add hw_i2c module option from [1] in addition to pm2-patches (see my last email) and rebuild radeon kernel-module: $ cd $build-dir $ make M=drivers/gpu/drm/radeon clean $ apply_patch $ make M=drivers/gpu/drm/radeon We have now a new module-option hw_i2c (0 = disabled, 1 = enabled), This requires to re-generate modules.dep and map files: # depmod Then I rebooted to check new radeon kernel-module. [init-3] # modprobe -r -v radeon # modprobe -v radeon modeset=1 dynpm=1 hw_i2c=1 That is working - no blank screen. But [2] shows also same error when there is a failure (does this error really matter?): ... Mar 18 11:56:40 seduxbox kernel: [ 62.350145] [drm:r500_hw_i2c_xfer], i2c write error 0x0002 ... Reclocking seems to work (see below) - when I start glxgears and let in run a while you see increasing e: X m: Y - closing glxgears results in downclocking. I will check if starting and closing OpenArena (Anholt benchmark) will result in a blank screen (but this was yesterday). Kind Regards, - Sedat - References: -- [1] http://marc.info/?l=dri-develm=126880645519474w=2 [2] http://files.iniza.org/agdf5-pm2-with-linustree/logs/debug_ok.txt - INVESTIGATIONS - [ 2213.179060] [drm] Requested: e: 12900 m: 13500 p: 16 [ 2213.602308] [drm] Requested: e: 21000 m: 13500 p: 16 [ 2213.621661] [drm] Setting: e: 21000 [ 2214.021304] [drm] Requested: e: 32400 m: 13500 p: 16 [ 2214.046572] [drm] Setting: e: 32400 [ 2214.446302] [drm] Requested: e: 39200 m: 3 p: 16 [ 2214.465277] [drm] Setting: e: 39200 [ 2214.465848] [drm] not in vbl for pm change 00020002 at entry [ 2214.468161] [drm] not in vbl for pm change 00020002 at exit [ 2214.468166] [drm] Setting: m: 3 [ 2214.868305] [drm] Requested: e: 39200 m: 3 p: 16 [ 2235.680072] [drm] Requested: e: 32400 m: 13500 p: 16 [ 2235.680281] [drm] Setting: e: 32400 [ 2235.690389] [drm] not in vbl for pm change 00020002 at entry [ 2235.692412] [drm] not in vbl for pm change 00020002 at exit [ 2235.692417] [drm] Setting: m: 13500 [ 2236.092069] [drm] Requested: e: 21000 m: 13500 p: 16 [ 2236.092105] [drm] GUI not idle!!! [ 2236.492071] [drm] Requested: e: 21000 m: 13500 p: 16 [ 2236.492249] [drm] Setting: e: 21000 [ 2237.292060] [drm] Requested: e: 12900 m: 13500 p: 16 [ 2237.292250] [drm] Setting: e: 12900 [ 2237.692070] [drm] Requested: e: 12900 m: 13500 p: 16 [ 2238.092068] [drm] Requested: e: 12900 m: 13500 p: 16 - EOT - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
Experiences (II) - OpenArena Mostly, I am using radeon Gallium3D driver r300g dri/statetracker. Here I can start openarena (OA) but entering fight-mode closes OA immediately. There seems to be a problem in mesa master GIT branch. commit 9d48a621d2a0e55a76a2cfd0aea3b773e907ed50 llvmpipe: Fix crashes when there is no depth buffer bound. OA is playable with classic mesa (KMS/DRI2). After Anholt's OA benchmark is finished - I get a blank screen. Log-file see [1]. - Sedat - [1] http://files.iniza.org/agdf5-pm2-with-linustree/logs/dmesg_openarena-r300classic.txt -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. yeah, the similar to what I saw with dualhead. I guess we are either missing the vblank window or the reclock is taking too much time. I wonder if it would make sense to wait for a vline rather than vblank, say a vline 1/2 or 2/3 of the way down the screen, to give us some buffer time between calling the reclock function and whatever setup it does and the beginning of the actual vblank period. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 17:40 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/3/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. yeah, the similar to what I saw with dualhead. I guess we are either missing the vblank window or the reclock is taking too much time. I wonder if it would make sense to wait for a vline rather than vblank, say a vline 1/2 or 2/3 of the way down the screen, to give us some buffer time between calling the reclock function and whatever setup it does and the beginning of the actual vblank period. If you suspect too slow resuming reclokcing context you can try tricks from: http://marc.info/?l=linux-kernelm=126730151530139w=2 It's about setting higher priority for reclocking context or switching to busy waiting. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/17 Alex Deucher alexdeuc...@gmail.com: On Mon, Mar 15, 2010 at 3:30 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher alexdeuc...@gmail.com wrote: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ Updated patches rebased against airlied's new drm-radeon-testing along with the fixes noted in Rafal's comments: http://people.freedesktop.org/~agd5f/pm2/ Another set of updated patches against drm-radeon-testing: http://people.freedesktop.org/~agd5f/pm2/ These implement much the remaining pm functionality. So far they are working well here. these patches add: - memory reclocking - pcie lane changes - update display watermarks as bandwidth changes - allow power management with multi-head - reset power mode on exit Nice, looks alright, thanks. Will test later if I manage before leaving for skiing. Do you know if we could ever recolck memory on multiple CRTCs? If not, what's the reason? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/17 Rafał Miłecki zaj...@gmail.com: 2010/3/17 Alex Deucher alexdeuc...@gmail.com: On Mon, Mar 15, 2010 at 3:30 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher alexdeuc...@gmail.com wrote: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ Updated patches rebased against airlied's new drm-radeon-testing along with the fixes noted in Rafal's comments: http://people.freedesktop.org/~agd5f/pm2/ Another set of updated patches against drm-radeon-testing: http://people.freedesktop.org/~agd5f/pm2/ These implement much the remaining pm functionality. So far they are working well here. these patches add: - memory reclocking - pcie lane changes - update display watermarks as bandwidth changes - allow power management with multi-head - reset power mode on exit Nice, looks alright, thanks. Will test later if I manage before leaving for skiing. Thanks. Do you know if we could ever recolck memory on multiple CRTCs? If not, what's the reason? I think so. It works now more or less, there's just an occasional jitter on the head not synced. I'm trying to find out how we do it internally. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/17 Alex Deucher alexdeuc...@gmail.com:
Another set of updated patches against drm-radeon-testing:
http://people.freedesktop.org/~agd5f/pm2/
Not serious thing, but still it's warning...
# git am pm2/0001*
Applying: drm/radeon/kms/atom: make sure tables are valid
/home/drm-2.6/.git/rebase-apply/patch:475: space before tab in indent.
if (atom_parse_data_header(mode_info-atom_context, index,
NULL, frev, crev, data_offset)) {
/home/drm-2.6/.git/rebase-apply/patch:476: space before tab in indent.
power_info = (union power_info
*)(mode_info-atom_context-bios + data_offset);
warning: 2 lines add whitespace errors.
--
Rafał
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/17 Alex Deucher alexdeuc...@gmail.com Another set of updated patches against drm-radeon-testing: http://people.freedesktop.org/~agd5f/pm2/ These implement much the remaining pm functionality. So far they are working well here. these patches add: - memory reclocking - pcie lane changes - update display watermarks as bandwidth changes - allow power management with multi-head - reset power mode on exit It seems memory reclocking and SIMDs setting is disabled for r6xx with currently available patches...? Otherwise it seems to work fine. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/17 Rafał Miłecki zaj...@gmail.com:
2010/3/17 Alex Deucher alexdeuc...@gmail.com:
Another set of updated patches against drm-radeon-testing:
http://people.freedesktop.org/~agd5f/pm2/
Not serious thing, but still it's warning...
# git am pm2/0001*
Applying: drm/radeon/kms/atom: make sure tables are valid
/home/drm-2.6/.git/rebase-apply/patch:475: space before tab in indent.
if (atom_parse_data_header(mode_info-atom_context, index,
NULL, frev, crev, data_offset)) {
/home/drm-2.6/.git/rebase-apply/patch:476: space before tab in indent.
power_info = (union power_info
*)(mode_info-atom_context-bios + data_offset);
warning: 2 lines add whitespace errors.
Looks like I was a little too quirk with that patch :) I'll get that fixed up.
Alex
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/17 Rafał Miłecki zaj...@gmail.com:
2010/3/17 Alex Deucher alexdeuc...@gmail.com
Another set of updated patches against drm-radeon-testing:
http://people.freedesktop.org/~agd5f/pm2/
These implement much the remaining pm functionality. So far they are
working well here.
these patches add:
- memory reclocking
- pcie lane changes
- update display watermarks as bandwidth changes
- allow power management with multi-head
- reset power mode on exit
It seems memory reclocking and SIMDs setting is disabled for r6xx with
currently available patches...?
It re-clocks memory (for single head anyway), r600_set_power_state():
/* set memory clock */
if (rdev-asic-set_memory_clock (mclk !=
rdev-pm.current_mclk)) {
radeon_sync_with_vblank(rdev);
radeon_pm_debug_check_in_vbl(rdev, false);
radeon_set_memory_clock(rdev, mclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev-pm.current_mclk = mclk;
DRM_INFO(Setting: m: %d\n, mclk);
}
The simd stuff is still disabled at the moment.
Otherwise it seems to work fine.
Thanks for testing.
Alex
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
Hi, I tried the pm2 patches from [1] on top of Linus-tree - 2.6.34-rc1-git6 to be precise. I have prepared a single patch of drm-radeon-testing GIT branch (as of 15-Mar-2010) [2]. The patch-series file against 2.6.34-rc1 looks like: [series] # upstream updates upstream/patch-2.6.34-rc1-git6 # patch from http://files.iniza.org/drm-radeon-kms/drm-radeon-testing/ drm-radeon-testing/drm-radeon-testing.patch # patches from http://people.freedesktop.org/~agd5f/pm2/ agd5f/pm2/0001-drm-radeon-kms-pm-fix-typo-in-power-table-parsing.patch agd5f/pm2/0002-drm-radeon-kms-gfx-init-fixes-for-r6xx-r7xx.patch #agd5f/pm2/0003-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch agd5f/pm2/0004-drm-radeon-kms-use-new-pre-post_xfer-i2c-bit-algo-h.patch agd5f/pm2/0005-drm-radeon-kms-add-gui_idle-callback.patch agd5f/pm2/0006-drm-radeon-kms-add-support-for-gui-idle-interrupts.patch agd5f/pm2/0007-drm-radeon-kms-wait-for-gpu-idle-before-changing-po.patch agd5f/pm2/0008-drm-radeon-kms-pm-rework-power-mode-parsing.patch agd5f/pm2/0009-drm-radeon-kms-pm-add-asic-specific-callbacks-for-s.patch agd5f/pm2/0010-drm-radeon-kms-pm-add-asic-specific-callbacks-for-g.patch agd5f/pm2/0011-drm-radeon-kms-r6xx-add-support-for-SIMD-pm.patch [/series] Happy testing... - Sedat - References: -- [1] http://people.freedesktop.org/~agd5f/pm2/ [2] http://files.iniza.org/drm-radeon-kms/drm-radeon-testing/ NOTE: - These two patches are now in latest drm-radeon-testing GIT branch: * 0001-drm-radeon-kms-pm-fix-typo-in-power-table-parsing.patch * 0002-drm-radeon-kms-gfx-init-fixes-for-r6xx-r7xx.patch You can drop this patch it is included in upstream: * 0003-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
On Mon, Mar 15, 2010 at 3:30 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher alexdeuc...@gmail.com wrote: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ Updated patches rebased against airlied's new drm-radeon-testing along with the fixes noted in Rafal's comments: http://people.freedesktop.org/~agd5f/pm2/ Another set of updated patches against drm-radeon-testing: http://people.freedesktop.org/~agd5f/pm2/ These implement much the remaining pm functionality. So far they are working well here. these patches add: - memory reclocking - pcie lane changes - update display watermarks as bandwidth changes - allow power management with multi-head - reset power mode on exit Alex Alex So far I haven't seen any corruption when changing power modes. What the patches do: - implement gui idle irq support - only change clocks when the engine is idle - add support for turning down the number of active simds in lower power modes (r6xx+) - add a pm_fini function - move set/get power state logic into asic specific callbacks. Different strategies for handling different power tables formats. Things left to do: - reset clocks to default on module unload (in pm_fini function) - add request module support for hwmon i2c thermal chip drivers - add hwmon support for internal thermal/fan support used on some r6xx/r7xx boards - add more robust power state selection - tie power state selection into external events (manual power mode selection, AC/DC state, etc.) - hook up memory reclocking - hook up pcie lane setting - hook up voltage setting Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ You can consider porting [PATCH 2/2] drm/radeon/kms: prepare for more reclocking operations You will need to sync with VBLANK few times I believe. Not sure about GUI syncing, do not know what is this. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ http://people.freedesktop.org/~agd5f/pm2/0009-drm-radeon-kms-r6xx-enable-simd-pm.patch Didn't you miss there something actually *setting* SIMD(s?)? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Rafał Miłecki zaj...@gmail.com: 2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ So far I haven't seen any corruption when changing power modes. Why don't you post them inline? It would be possible to comment any part of code. It was a lot of patches. I can post them with the message next time. 1) What is GUI? Graphical User Interface. In this case it refers to the drawing engine and related blocks (2D, 3D, CP, etc.). 2) What is SIMD? SIMD (Single Instruction Multiple Data) blocks are the computational blocks of the shader engine. Alex -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Rafał Miłecki zaj...@gmail.com: 2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ http://people.freedesktop.org/~agd5f/pm2/0003-drm-radeon-kms-add-some-comments-about-radeon_asic.patch Code you removed was needed for PM debugfs, to do not display memory clock on IGP Oh, right... debugfs support is also currently broken with multiple cards. I'll just drop this patch for now. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Rafał Miłecki zaj...@gmail.com: 2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ http://people.freedesktop.org/~agd5f/pm2/0009-drm-radeon-kms-r6xx-enable-simd-pm.patch Didn't you miss there something actually *setting* SIMD(s?)? heh... whoops. fixed. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Rafał Miłecki zaj...@gmail.com: 2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ You can consider porting [PATCH 2/2] drm/radeon/kms: prepare for more reclocking operations You will need to sync with VBLANK few times I believe. Not sure about GUI syncing, do not know what is this. I've gone ahead and rebased my patches against Dave's current drm-radeon-testing branch, so both patches should be in now. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Rafał Miłecki zaj...@gmail.com: 2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ http://people.freedesktop.org/~agd5f/pm2/0006-drm-radeon-kms-wait-for-gpu-idle-before-changing-po.patch You made same mistake I did earlier with 0 argument in condition. You should use same trick as I did in: http://people.freedesktop.org/~agd5f/pm2/0013-drm-radeon-kms-switch-to-condition-waiting-for-recl.patch Good catch! fixed. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ So far I haven't seen any corruption when changing power modes. Why don't you post them inline? It would be possible to comment any part of code. 1) What is GUI? 2) What is SIMD? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ http://people.freedesktop.org/~agd5f/pm2/0003-drm-radeon-kms-add-some-comments-about-radeon_asic.patch Code you removed was needed for PM debugfs, to do not display memory clock on IGP -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
2010/3/15 Alex Deucher alexdeuc...@gmail.com: This weekend I finally got some time to sit down with kms pm, and I created a new patch set (against drm-radeon-testing). For those that want to play with the i2c stuff for thermal chips, you'll probably grab my recent i2c patches as well. You can grab my latest pm patches here: http://people.freedesktop.org/~agd5f/pm2/ http://people.freedesktop.org/~agd5f/pm2/0006-drm-radeon-kms-wait-for-gpu-idle-before-changing-po.patch You made same mistake I did earlier with 0 argument in condition. You should use same trick as I did in: http://people.freedesktop.org/~agd5f/pm2/0013-drm-radeon-kms-switch-to-condition-waiting-for-recl.patch -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
