Age | Commit message (Collapse) | Author | Files | Lines |
|
Consistently use int for register values and long for register offsets.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Otherwise print "unknown" for dac and backlight status.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
Let the user know that we actually hit an error.
Also add a missing newline in one error message.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
using tables from rv100 on js22 machine, not sure what 0xa op in init2 table is
these tables are found in the open firmware device tree,
/proc/device-tree/pci@800000020000202/display@1/ on the js22
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
detect the chip family and dump appropriately.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
simple reg dumper for different families.
radeonreg regs <set>
<set>
radeon - r128, r1xx-r4xx
avivo - r5xx, rs600/690/740, r600, rv610/630/670
dce3 - rv620/635/770/710/730/740, rs780/880
dce4 - evergreen
dce5 - ni
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fix radeontool also
|
|
|
|
|
|
Running ‘radeontool regmatch '*'’ with an ATI Rage 128 Mobility M3 LF
(AGP) locks up the system.
The register reads that lock up are CRTC2_CRNT_FRAME and
CRTC2_VLINE_CRNT_VLINE; it is not clear to me why. From the
xf86-video-r128 source I can see that this is one of the handful of
r128 chips that supports dual-head operation, but at the time of the
lockup, the CRTC2_GEN_CNTL register had value 0x0 (i.e., CRTC2
disabled); maybe that’s why.
Presumably these two registers would only be relevant if CRTC2 is
enabled, so as a safety measure, check for that before displaying them
with ‘radeontool regmatch [pattern]’.
A similar crash was reported on 2009-12-02 on #radeon for an R300, so
presumably this problem is not restricted to pre-Radeon cards.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
A hard lock-up is always an unpleasant event, but it can be less
unpleasant if any unrelated pending I/O is finished first. Make
‘radeontool regmatch '*'’ a little safer by calling sync().
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Register reads might take a long time or lock up the system. Let the
user know which register before such an event occurs.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
With the previous commit (radeontool: handle r128 again, 2010-03-23),
the rules for finding the control area and framebuffer became more
lax. It is possible that some cards have multiple regions satisfying
the new criteria, in which case the code makes a silly arbitrary
choice. Better to error out and make it clear what happened in such a
case.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
An r128 has a tiny (16 KiB) control region and a small (64 MiB)
framebuffer, but radeontool can handle it anyway.
In particular, this gets 'radeontool light off' (and 'on'), which is
often used to work around bugs in Dell suspend support, working again
for the r128. It hasn’t been working since the change to use
libpciaccess.
Analysis-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Do not blithely use an uninitialized value when the expected
memory areas cannot be found.
This is triggered by trying to use radeontool on an r128.
Noticed-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
radeontool looks for the control and fb regions for early cards
with --skip even though that they are not going to be used. If
radeontool fails to detect one of those regions for the chosen
card, the result can be a setup with one region from one card
and the other from another.
This also improves error handling: if only one card is present
but --skip=1 was supplied, then without this patch radeontool
will not actually error out.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Erik Edelmann <erik.edelmann@iki.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Luigi Gangitano <luigi@debian.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
- fix some issues with power mode dumping on pre-atom
- dump power tables on atom
|
|
|
|
|
|
|
|
|
|
|
|
|