This migrates a bunch of DRM_DEBUG->DRM_DEBUG_KMS so we can get more modesetting related info without all the other ioctl handling easily.
Also the PM code moves to DRM_DEBUG_DRIVER mostly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
rv6xx/rv7xx/evergreen families supported; older asics did
not have an internal thermal sensor.
Note, not all oems use the internal thermal sensor, so it's
only exposed in cases where it is used.
Note also, that most laptops use an oem specific ACPI solution for
GPU thermal information rather than using the internal thermal
sensor directly.
v2: export millidegrees celsius, use hwmon device properly.
v3: fix Kconfig
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix incorrectly reporting 'default' power profile, when it is set to 'mid'.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There is a regression from 2.6.34 related to the recent radeon power
management changes, caused by attempting to cancel a delayed work
item that's never been scheduled. However, the code as is has some
other issues potentially leading to visible problems.
First, the mutex around cancel_delayed_work() in radeon_pm_suspend()
doesn't really serve any purpose, because cancel_delayed_work() only
tries to delete the work's timer. Moreover, it doesn't prevent the
work handler from running, so the handler can do some wrong things if
it wins the race and in that case it will rearm itself to do some
more wrong things going forward. So, I think it's better to wait for
the handler to return in case it's already been queued up for
execution. Also, it should be prevented from rearming itself in that
case.
Second, in radeon_set_pm_method() the cancel_delayed_work() is not
sufficient to prevent the work handler from running and queing up
itself for the next run (the failure scenario is that
cancel_delayed_work() returns 0, so the handler is run, it waits on
the mutex and then rearms itself after the mutex has been released),
so again the work handler should be prevented from rearming itself in
that case..
Finally, there's a potential deadlock in radeon_pm_fini(), because
cancel_delayed_work_sync() is called under rdev->pm.mutex, but the
work handler tries to acquire the same mutex (if it wins the race).
Fix the issues described above.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
track the current voltage level and avoid setting it
if the requested voltage is already set.
v2: check voltage type before checking current voltage
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds an additional profile, mid, to the pm profile
code which takes the place of the old low profile. The default
behavior remains the same, e.g., auto profile now selects between
mid and high profiles based on power source, however, you can now
manually force the low profile which was previously only available
as a dpms off state. Enabling the low profile when the displays
are on has been known to cause display corruption in some cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- don't rest the power state in pm_init()
We already boot up to the default power state. Note this
patch relies on:
drm/radeon/kms/pm: patch default power state with default clocks/voltages on r6xx+
To make sure the default power state matches the boot up state.
- In the pm resume path asic init will have set the power state
back to the default so reset the tracking state values.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
PM attemps to unmap objects that aren't actually mapped into userspace ever,
so just don't bother unmapping them at this point, since all you are doing
is nothing. We should be making sure all access to these objects are locked in
kernel space instead. In theory the VRAM gart table is already done, and both
the shaders and stolen vga memory blocks are never accessed at runtime.
fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16127
Reported-by: Jure Repnic <jlp.bugs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- wait for vbl for both profile and dynpm
- unify profile and dynpm code paths more
- call pm_misc before of after clocks to make
sure voltage is changed in the proper order.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Separate dynpm and profile based power management methods. You can select the pm method
by echoing the selected method ("dynpm" or "profile") to power_method in sysfs.
- Expose basic 4 profile in profile method
"default" - default clocks
"auto" - select between low and high based on ac/dc state
"low" - DC, low power mode
"high" - AC, performance mode
The current base profile is "default", but it should switched to "auto" once we've tested
on more systems. Switching the state is a matter of echoing the requested profile to
power_profile in sysfs. The lowest power states are selected automatically when dpms turns
the monitors off in all states but default.
- Remove dynamic fence-based reclocking for the moment. We can revisit this later once we
have basic pm in.
- Move pm init/fini to modesetting path. pm is tightly coupled with display state. Make sure
display side is initialized before pm.
- Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume.
- Remove dynpm module option. It's now selectable via sysfs.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The lowest power states often cause display problems, so only enable
them when all displays are off.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
GUI idle interrupts don't seem to work terribly well on r500 and earlier,
so let's use a fence instead.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- disable gui idle interrupt use
Seems to hang some r5xx chips
- move vbl range check into
existing vbl check function in
radeon_pm.c
- disable crtc mc acccess for the
whole reclocking process
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The vblank interrupt on r600 doesn't seem to be especially reliable, so
perform some sanity checks before the actual reclock.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The ttm code could take vram_mutex followed by cp_mutex, while the
reclocking code would do the reverse. Hilarity could ensue.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to choose the correct PM state to transition into before starting
the actual change. Call radeon_get_power_state() at the top of the clock
setting to do so.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The ttm bo workqueue may touch objects while we're reclocking, so make
sure it's blocked until we're done.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to block the drm core from doing anything that may touch our vram
during reclock, so take the drm mutex for the duration.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Touching vram while the card is reclocking can lead to lockups. Unmap
any pages that could be touched by the CPU and block any accesses to
vram until the reclocking is complete.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's a moderate amount of effort involved in setting the card up for
clock transitions, so unify the codepaths to make it easier to implement.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add two new sysfs attributes:
- dynpm
- power_state
Echoing 0/1 to dynpm disables/enables dynamic power management.
The driver scales the sclk dynamically based on the number of
queued fences. dynpm only scales sclk dynamically in single head
mode.
Echoing x.y to power_state selects a static power state (x) and clock
mode (y). This allows you to statically select a power state and clock
mode. Selecting a static clock mode will disable dynpm.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- remove non_clock_info struct
- track power state misc flags
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just adds overhead when the power state will never change.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This also simplifies the code and enables reclocking with multiple heads
active by tracking whether the power states are single or multi-head
capable.
Eventually, we will want to select a power state based on external
factors (AC/DC state, user selection, etc.).
(v2) Update for evergreen
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
set proper wait condition as noted by Rafał Miłecki.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Useful for certain power management operations. You
need to wait for the GUI engine (2D, 3D, CP, etc.) to be
idle before changing clocks or adjusting engine parameters.
(v2) Fix gui idle enable on pre-r6xx asics
(v3) The gui idle interrrupt status bit is permanently asserted
on pre-r6xx chips, but the interrrupt is still generated.
workaround it in the driver.
(v4) Add support for evergreen
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Look up i2c bus in the power table and expose it.
You'll need to load a hwmon driver for any chips
on the bus, this patch just exposes the bus.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
We tried to implement interruptible waiting with timeout (it was broken
anyway) which was not a good idea as explained by Andrew. It's possible
to avoid using additional variable but actually it inroduces using more
complex in-kernel tools. So simply add one variable for condition.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
AtomBIOS tables on non-mobility GPU do not contain POWERSAVE/BATTERY.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We kept pointers to requested and current clock modes in every power state.
That was useless, more /global/ pointers in power struct are enough.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@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.
This already simplifies code significally and makes it maintaible
in case of adding memory reclocking plus voltage changing in future.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The idea is to flag a power state with a certain type and use
that type to decide on what state to select. On r6xx+, we
select a state and then transition between clock modes in that
state. On pre-r6xx, we transition between states directly.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The general idea is to validate the current hw state
against the set of power states and select a power
state based on that. This patch just pulls the power
states from the bios and prints the information. It
is not currently hooked up in the actual power management
code. Hooking it up will require reworking the the current
power state selection code and will be handled in a future
patch.
Additionally, we'd need to decide on some default lower
power states for cards without power tables.
v2 - increment state_index after checking for default state
v3 - fix typo in pm init on pre-atom cards, handle pre-atom
cards without x86 bioses
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
V2: reorganize functions, fix modesetting calls
V3: rebase patch, use radeon's workqueue
V4: enable on tested chipsets only, request VBLANK IRQs
V5: enable PM on older hardware (IRQs, mode_fixup, dpms)
V6: use separate dynpm module parameter
V7: drop RADEON_ prefix, set minimum mode for dpms off
V8: update legacy encoder call, fix order in rs600 IRQ
V9: update compute_clocks call in legacy, not only DPMS_OFF
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Eric Anholt