Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Dave Airlie airl...@gmail.com: 2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? That could be possible, though if a reclock takes a full scanout to operate we've got other issues as it would never be possible by the sounds of it. I might be seeing something like this O_o [ 257.583603] [drm] not in vbl for pm change 00020002 at entry [ 257.583609] [drm] Setting: e: 22000 m: 3 p: 16 (no warning at exit) I have wait queue fix in place... I also see some unsynched reclocks. On a somewhat unrelated note the current clock selection code does not work well with the tables defined on my card (M76): [ 156.577741] ATOM BIOS: ASUS_F3Sa [ 156.577794] [drm] Clocks initialized ! [ 156.577833] [drm] 5 Power State(s) [ 156.577871] [drm] State 0 Default (default) [ 156.577909] [drm]16 PCIE Lanes [ 156.577946] [drm]3 Clock Mode(s) [ 156.577984] [drm]0 engine/memory: 22/30 [ 156.578023] [drm]1 engine/memory: 22/30 [ 156.578063] [drm]2 engine/memory: 22/30 [ 156.578102] [drm] State 1 Performance [ 156.578139] [drm]16 PCIE Lanes [ 156.578177] [drm]3 Clock Mode(s) [ 156.578214] [drm]0 engine/memory: 22/252000 [ 156.578253] [drm]1 engine/memory: 22/30 [ 156.578292] [drm]2 engine/memory: 50/40 [ 156.578332] [drm] State 2 Battery [ 156.578369] [drm]16 PCIE Lanes [ 156.578406] [drm]3 Clock Mode(s) [ 156.578444] [drm]0 engine/memory: 22/252000 [ 156.578483] [drm]1 engine/memory: 22/252000 [ 156.578522] [drm]2 engine/memory: 22/30 [ 156.578561] [drm] State 3 Performance [ 156.578599] [drm]16 PCIE Lanes [ 156.578636] [drm]3 Clock Mode(s) [ 156.578674] [drm]0 engine/memory: 30/40 [ 156.578713] [drm]1 engine/memory: 30/40 [ 156.578752] [drm]2 engine/memory: 50/40 [ 156.578791] [drm] State 4 Battery [ 156.578828] [drm]16 PCIE Lanes [ 156.578866] [drm]3 Clock Mode(s) [ 156.578903] [drm]0 engine/memory: 22/30 [ 156.578942] [drm]1 engine/memory: 22/30 [ 156.578981] [drm]2 engine/memory: 22/30 radeon_pick_power_state with a mobility chip only uses battery and powersave states. Luca -- 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: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This patch adds a check on avivo chips to see if we are in the VBL region for the active crtcs when we trigger the engine change. I appear to have glitches locally on pm transistion (not sure all fixes are in yet) and this at least seems to be correct here, maybe others can test on systems with no glitches. Because we are totally out of sync with VBLANK. If we correctly sync with it, it's just a lucky case. Please check my [PATCH] drm/radeon/kms: really wait for VBLANK in PM code and reply in thread where I posted it. + /* check if we are in vblank */ + radeon_pm_debug_check_in_vbl(rdev, false); radeon_set_power_state(rdev); + radeon_pm_debug_check_in_vbl(rdev, true); rdev-pm.planned_action = PM_ACTION_NONE; It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some #ifdef RADEON_PM_DEBUG ? -- Rafał -- Download Intelreg; 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: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Rafał Miłecki zaj...@gmail.com: 2010/2/18 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This patch adds a check on avivo chips to see if we are in the VBL region for the active crtcs when we trigger the engine change. I appear to have glitches locally on pm transistion (not sure all fixes are in yet) and this at least seems to be correct here, maybe others can test on systems with no glitches. Because we are totally out of sync with VBLANK. If we correctly sync with it, it's just a lucky case. Please check my [PATCH] drm/radeon/kms: really wait for VBLANK in PM code and reply in thread where I posted it. Yeah I'll put this in when I've ran it here, it looks sane. It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some #ifdef RADEON_PM_DEBUG I don't think it'll be a major overhead, though doing it under a debug would be fine, but it would be nice to make it into a WARN_ON so we could track where this actually happens for ppl with something like kerneloops. Dave. -- Download Intelreg; 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: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Dave. -- Download Intelreg; 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: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? -- Rafał -- Download Intelreg; 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: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? That could be possible, though if a reclock takes a full scanout to operate we've got other issues as it would never be possible by the sounds of it. The check on the way out could be toned down alright, its probably not as important, btw I've still got problems even with that other patch applied, I get reclocking in the middle of the frame, Reverting 73a6d3fc104827db574e4bd206a025299fef0bb1 drm/radeon/kms: use wait queue (events) for VBLANK sync still fixes it for me here. Dave. -- Download Intelreg; 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
