ce8f53709b
- 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>
39 lines
1.9 KiB
Plaintext
39 lines
1.9 KiB
Plaintext
config DRM_RADEON_KMS
|
|
bool "Enable modesetting on radeon by default - NEW DRIVER"
|
|
depends on DRM_RADEON
|
|
depends on POWER_SUPPLY
|
|
help
|
|
Choose this option if you want kernel modesetting enabled by default.
|
|
|
|
This is a completely new driver. It's only part of the existing drm
|
|
for compatibility reasons. It requires an entirely different graphics
|
|
stack above it and works very differently from the old drm stack.
|
|
i.e. don't enable this unless you know what you are doing it may
|
|
cause issues or bugs compared to the previous userspace driver stack.
|
|
|
|
When kernel modesetting is enabled the IOCTL of radeon/drm
|
|
driver are considered as invalid and an error message is printed
|
|
in the log and they return failure.
|
|
|
|
KMS enabled userspace will use new API to talk with the radeon/drm
|
|
driver. The new API provide functions to create/destroy/share/mmap
|
|
buffer object which are then managed by the kernel memory manager
|
|
(here TTM). In order to submit command to the GPU the userspace
|
|
provide a buffer holding the command stream, along this buffer
|
|
userspace have to provide a list of buffer object used by the
|
|
command stream. The kernel radeon driver will then place buffer
|
|
in GPU accessible memory and will update command stream to reflect
|
|
the position of the different buffers.
|
|
|
|
The kernel will also perform security check on command stream
|
|
provided by the user, we want to catch and forbid any illegal use
|
|
of the GPU such as DMA into random system memory or into memory
|
|
not owned by the process supplying the command stream. This part
|
|
of the code is still incomplete and this why we propose that patch
|
|
as a staging driver addition, future security might forbid current
|
|
experimental userspace to run.
|
|
|
|
This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
|
|
(radeon up to X1950). Works is underway to provide support for R6XX,
|
|
R7XX and newer hardware (radeon from HD2XXX to HD4XXX).
|