From: Alex D. <ale...@gm...> - 2010-03-15 00:01:43
|
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. 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 |
From: Rafał M. <za...@gm...> - 2010-03-15 05:44:45
|
2010/3/15 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-15 07:26:28
|
2010/3/15 Rafał Miłecki <za...@gm...>: > 2010/3/15 Alex Deucher <ale...@gm...>: >> 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ł > |
From: Rafał M. <za...@gm...> - 2010-03-15 05:50:34
|
2010/3/15 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-15 07:26:38
|
2010/3/15 Rafał Miłecki <za...@gm...>: > 2010/3/15 Alex Deucher <ale...@gm...>: >> 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 |
From: Rafał M. <za...@gm...> - 2010-03-15 05:52:43
|
2010/3/15 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-15 07:27:00
|
2010/3/15 Rafał Miłecki <za...@gm...>: > 2010/3/15 Alex Deucher <ale...@gm...>: >> 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 |
From: Rafał M. <za...@gm...> - 2010-03-15 06:04:57
|
2010/3/15 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-15 07:26:52
|
2010/3/15 Rafał Miłecki <za...@gm...>: > 2010/3/15 Alex Deucher <ale...@gm...>: >> 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 |
From: Rafał M. <za...@gm...> - 2010-03-15 06:27:19
|
2010/3/15 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-15 07:26:45
|
2010/3/15 Rafał Miłecki <za...@gm...>: > 2010/3/15 Alex Deucher <ale...@gm...>: >> 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 |
From: Alex D. <ale...@gm...> - 2010-03-15 07:30:12
Attachments:
0001-drm-radeon-kms-pm-fix-typo-in-power-table-parsing.patch
0002-drm-radeon-kms-gfx-init-fixes-for-r6xx-r7xx.patch
0003-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch
0004-drm-radeon-kms-use-new-pre-post_xfer-i2c-bit-algo-h.patch
0005-drm-radeon-kms-add-gui_idle-callback.patch
0006-drm-radeon-kms-add-support-for-gui-idle-interrupts.patch
0007-drm-radeon-kms-wait-for-gpu-idle-before-changing-po.patch
0008-drm-radeon-kms-pm-rework-power-mode-parsing.patch
0009-drm-radeon-kms-pm-add-asic-specific-callbacks-for-s.patch
0010-drm-radeon-kms-pm-add-asic-specific-callbacks-for-g.patch
0011-drm-radeon-kms-r6xx-add-support-for-SIMD-pm.patch
|
On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher <ale...@gm...> 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/ 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 > |
From: Alex D. <ale...@gm...> - 2010-03-17 01:43:23
|
On Mon, Mar 15, 2010 at 3:30 AM, Alex Deucher <ale...@gm...> wrote: > On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher <ale...@gm...> 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 >> > |
From: Rafał M. <za...@gm...> - 2010-03-17 06:28:45
|
2010/3/17 Alex Deucher <ale...@gm...>: > On Mon, Mar 15, 2010 at 3:30 AM, Alex Deucher <ale...@gm...> wrote: >> On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher <ale...@gm...> 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ł |
From: Alex D. <ale...@gm...> - 2010-03-17 14:35:19
|
2010/3/17 Rafał Miłecki <za...@gm...>: > 2010/3/17 Alex Deucher <ale...@gm...>: >> On Mon, Mar 15, 2010 at 3:30 AM, Alex Deucher <ale...@gm...> wrote: >>> On Sun, Mar 14, 2010 at 7:01 PM, Alex Deucher <ale...@gm...> 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 |
From: Rafał M. <za...@gm...> - 2010-03-17 23:18:25
|
2010/3/17 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-18 03:27:59
|
2010/3/17 Rafał Miłecki <za...@gm...>: > 2010/3/17 Alex Deucher <ale...@gm...>: >> 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 |
From: Rafał M. <za...@gm...> - 2010-03-18 00:06:12
|
2010/3/17 Alex Deucher <ale...@gm...> > 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ł |
From: Alex D. <ale...@gm...> - 2010-03-18 03:27:49
|
2010/3/17 Rafał Miłecki <za...@gm...>: > 2010/3/17 Alex Deucher <ale...@gm...> >> 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 |
From: Rafał M. <za...@gm...> - 2010-03-18 09:05:27
|
W dniu 18 marca 2010 04:27 użytkownik Alex Deucher <ale...@gm...> napisał: > 2010/3/17 Rafał Miłecki <za...@gm...>: >> 2010/3/17 Alex Deucher <ale...@gm...> >>> 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ł |
From: Rafał M. <za...@gm...> - 2010-03-18 11:37:21
|
W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki <za...@gm...> 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ł |
From: Alex D. <ale...@gm...> - 2010-03-18 16:40:08
|
2010/3/18 Rafał Miłecki <za...@gm...>: > W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki <za...@gm...> 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 |
From: Rafał M. <za...@gm...> - 2010-03-18 16:43:34
|
W dniu 18 marca 2010 17:40 użytkownik Alex Deucher <ale...@gm...> napisał: > 2010/3/18 Rafał Miłecki <za...@gm...>: >> W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki <za...@gm...> 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-kernel&m=126730151530139&w=2 It's about setting higher priority for reclocking context or switching to busy waiting. -- Rafał |
From: Rafał M. <za...@gm...> - 2010-03-26 19:49:29
|
W dniu 18 marca 2010 17:40 użytkownik Alex Deucher <ale...@gm...> napisał: > 2010/3/18 Rafał Miłecki <za...@gm...>: >> W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki <za...@gm...> 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ł |
From: Alex D. <ale...@gm...> - 2010-03-26 19:54:13
|
2010/3/26 Rafał Miłecki <za...@gm...>: > W dniu 18 marca 2010 17:40 użytkownik Alex Deucher > <ale...@gm...> napisał: >> 2010/3/18 Rafał Miłecki <za...@gm...>: >>> W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki <za...@gm...> 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 |