Hi Linus,
all radeon fixes, one nasty startup crash and/or memory corruption on one family of radeon hd6450s resulted in a patch to stop setting a bunch of regs in the drivers and let the BIOS set them correctly, displayport regression fix, and some off-by-one in the cursor code around the corners of the screens.
its a bit bigger than I'd like but the register setting removal had to remove the unused functions.
Dave.
The following changes since commit 9b13776977d45505469edc6decc93e9e3799afe2:
Merge branch 'for-linus' of git://git.infradead.org/users/sameo/mfd-2.6 (2011-10-02 19:23:44 -0700)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
Alex Deucher (4): drm/radeon/kms: fix regression in DP aux defer handling drm/radeon/kms: add retry limits for native DP aux defer drm/radeon/kms: Fix logic error in DP HPD handler drm/radeon/kms: fix channel_remap setup (v2)
Michel Dänzer (3): drm/radeon: Simplify cursor x/yorigin calculation. drm/radeon: Update AVIVO cursor coordinate origin before x/yorigin calculation. drm/radeon: Set cursor x/y to 0 when x/yorigin > 0.
Nicholas Miell (1): drm/radeon/kms: fix cursor image off-by-one error
drivers/gpu/drm/radeon/atombios_dp.c | 16 +++++--- drivers/gpu/drm/radeon/evergreen.c | 44 ------------------------ drivers/gpu/drm/radeon/ni.c | 32 ----------------- drivers/gpu/drm/radeon/radeon_connectors.c | 8 ++-- drivers/gpu/drm/radeon/radeon_cursor.c | 40 ++++++++++----------- drivers/gpu/drm/radeon/rv770.c | 51 ---------------------------- 6 files changed, 33 insertions(+), 158 deletions(-)
On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie airlied@linux.ie wrote:
all radeon fixes, one nasty startup crash and/or memory corruption on one family of radeon hd6450s resulted in a patch to stop setting a bunch of regs in the drivers and let the BIOS set them correctly, displayport regression fix, and some off-by-one in the cursor code around the corners of the screens.
Has this been tested with suspend/resume on a lot of machines?
In general, the registers that get set on boot correctly absolutely do *not* get set on resume.
So the registers that you now no longer set at boot-time should almost certainly still be saved and restored across suspend/resume. I don't know the code well enough to read the diffs, but a quick grep seems to show that when you removed the boot-time setup, you also removed the resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be used anywhere any more: it may be that it's saved-restores in some kind of "loop over all registers" that wouldn't have triggered the grep).
I pulled, but please verify that whole thing.
Linus
On Tue, Oct 4, 2011 at 12:58 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie airlied@linux.ie wrote:
all radeon fixes, one nasty startup crash and/or memory corruption on one family of radeon hd6450s resulted in a patch to stop setting a bunch of regs in the drivers and let the BIOS set them correctly, displayport regression fix, and some off-by-one in the cursor code around the corners of the screens.
Has this been tested with suspend/resume on a lot of machines?
In general, the registers that get set on boot correctly absolutely do *not* get set on resume.
So the registers that you now no longer set at boot-time should almost certainly still be saved and restored across suspend/resume. I don't know the code well enough to read the diffs, but a quick grep seems to show that when you removed the boot-time setup, you also removed the resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be used anywhere any more: it may be that it's saved-restores in some kind of "loop over all registers" that wouldn't have triggered the grep).
I pulled, but please verify that whole thing.
It's safe. The hw default value is fine (value in the register at asic power up). On most cards the hw default value is is fine. If it needs to be overridden in certain cases, that's handled by the asic_init vbios table which is executed at boot by the vbios and by the driver at resume time.
Alex
dri-devel@lists.freedesktop.org