This allows you to force specific power levels within a power
state. Due to hardware restrictions between generations, the
interface is limited to the following 3 selections:
auto: all levels enabled
low: forced to the lowest power level
high: forced to the highest power level
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
r1xx asics have a slightly different surface register
setup compared to newer asics. There is no specific
enable bit for macro tiling, rather, to disable macro
tiling, you need to set the surface pitch to 0.
With this fixed, the special rn50 handling can go.
Noticed-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Certain older rv770 asics have both a performance and
a 3D performance state rather than just multiple performance
levels in the state power state. The current code would
select the performance state rather than the 3D performance
state when the "performance" profile was selected. This change
switches to the "balanced" profile by default which ends up being
the internal performance profile. When the user selects the
"performance" profile, it selects the internal 3D performance
state so the user can select the higher performance modes.
For most asics this changes nothing. For certain rv770 asics
with static performance and 3D performance states, this allows
you to select between then using by selecting the "balanced"
and "performance" dpm profiles.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix patching of vddc values for SI and enable manually forcing
clocks to default levels as per NI.
This improves the out of the box performance with SI asics.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For chips without debugfs dpm support say that it's not
implemented rather than not supported to avoid confusion
about DPM support in general.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Was disabled due to stability issues on certain boards
caused by the a bug in the parsing of the atom mc reg tables.
That's fixed now so re-enable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Was disabled due to stability issues on certain boards
caused by the a bug in the parsing of the atom mc reg tables.
That's fixed now so re-enable.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- Various fixes that make surviving concurrent piglit more possible.
- Buffer object deletion no longer synchronous
- Context/register initialisation updates that have been reported to
solve some stability issues (particularly on some problematic GF119
chips)
- Kernel side support for VP2 video decoding engines
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (44 commits)
drm/nvd0-/disp: handle case where display engine is missing/disabled
drm/gr/nvc0-: merge nvc0/nve0 ucode, and use cpp instead of m4
drm/nouveau/bsp/nv84: initial vp2 engine implementation
drm/nouveau/vp/nv84: initial vp2 engine implementation
drm/nouveau/core: xtensa engine base class implementation
drm/nouveau/vdec: fork vp3 implementations from vp2
drm/nouveau/core: move falcon class to engine/
drm/nouveau/kms: don't fail if there's no dcb table entries
drm/nouveau: remove limit on gart
drm/nouveau/vm: perform a bar flush when flushing vm
drm/nvc0/gr: cleanup register lists, and add nvce/nvcf to switches
drm/nvc8/gr: update initial register/context values
drm/nvc4/gr: update initial register/context values
drm/nvc1/gr: update initial register/context values
drm/nvc3/gr: update initial register/context values
drm/nvc0/gr: update initial register/context values
drm/nvd9/gr: update initial register/context values
drm/nve4/gr: update initial register/context values
drm/nvc0-/gr: bump maximum gpc/tpc limits
drm/nvf0/gr: initial register/context setup
...
Not really "core" per-se. About to merge Ilia's work adding another
similar class for the VP2 xtensa engines, so, seems like a good time to
move all these to engine/.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most graphics cards nowadays have a multiple of this limit as their vram,
so limiting GART doesn't seem to make much sense.
Signed-off-by: Maarten >Lnkhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
internally".
nvidia always seems to do this flush after writing values.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Alex Deucher