drm-radeon-testing, RS780 [ 379.169870] [drm:radeon_set_power_state], Setting: e: 0 [ 379.169938] divide error: 0000 [#1] PREEMPT SMP (...) [ 379.170077] Call Trace: [ 379.170105] [<f96e20e6>] ? rs690_bandwidth_update+0x96/0xb60 [radeon] Will provide more info.
Created attachment 36467 [details] dmesg with div by 0 call trace
Created attachment 36489 [details] dmesg with some own debugging messages Alex could you take a look at this?
Created attachment 36495 [details] vbios
Created attachment 36496 [details] dmesg: power states picked by driver Please note downclocked mode is marked as performance one :|
Created attachment 36497 [details] [review] fix div by 0 This should fix the issue. IGP chips have the same clocks for the low performance and battery states, so it doesn't matter which we choose.
Created attachment 36498 [details] dmesg with patch It works fine, hope that's what you expected :) Can you submit to Dave?
Could you by the way explain that magic cycling through the power states? I thought of doing same patch for r100.c, but there exists another condition: if (rdev->pm.current_power_state_index == 0) is that alright? I guess patch for r100.c is nod needed then?
(In reply to comment #6) > Created an attachment (id=36498) [details] > dmesg with patch > > It works fine, hope that's what you expected :) > > Can you submit to Dave? Will do. (In reply to comment #7) > Could you by the way explain that magic cycling through the power states? > > I thought of doing same patch for r100.c, but there exists another condition: > > if (rdev->pm.current_power_state_index == 0) > > is that alright? I guess patch for r100.c is nod needed then? Yes, r100 doesn't need a similar patch as the power states are ordered differently.
Patch sent.
(In reply to comment #7) > Could you by the way explain that magic cycling through the power states? Ping? :) Why do we cycle through the (all?) power states?
(In reply to comment #10) > > Why do we cycle through the (all?) power states? It's a simple algo :) I suppose the alternative would be to just switch between a low and high one. It's easier for the plls to lock after a small change, so there's less of a delay when making small changes to the clocks, but that's about it. If we had more advanced pm algos there might be advantages to staying in intermediate states for certain reasons (e.g., to maintain enough bandwidth or performance for certain tasks, etc.).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.