Had a fun time tracking down two major problem on radeon, one in page flipping on r300/r400, one in the VRAM limiting that Michael at Phoronix reported.
I'm going to push these to Linus (first one is gone already), but it would be nice if people could review em.
Dave.
From: Dave Airlie airlied@redhat.com
We've been getting reports of complete system lockups with rv3xx hw on AGP and PCIE when running gnome-shell or kwin with compositing.
It appears the hw really doesn't like setting these registers while stuff is running, this moves the setting of the registers into the modeset since they aren't required to be changed anywhere else.
fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183
Reported-and-tested-by: Álmos <aaalmosss@gmail.com Signed-off-by: Dave Airlie airlied@redhat.com --- drivers/gpu/drm/radeon/r100.c | 17 ----------------- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 3 ++- 2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 93fa735..79de991 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -70,23 +70,6 @@ MODULE_FIRMWARE(FIRMWARE_R520);
void r100_pre_page_flip(struct radeon_device *rdev, int crtc) { - struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc]; - u32 tmp; - - /* make sure flip is at vb rather than hb */ - tmp = RREG32(RADEON_CRTC_OFFSET_CNTL + radeon_crtc->crtc_offset); - tmp &= ~RADEON_CRTC_OFFSET_FLIP_CNTL; - /* make sure pending bit is asserted */ - tmp |= RADEON_CRTC_GUI_TRIG_OFFSET_LEFT_EN; - WREG32(RADEON_CRTC_OFFSET_CNTL + radeon_crtc->crtc_offset, tmp); - - /* set pageflip to happen as late as possible in the vblank interval. - * same field for crtc1/2 - */ - tmp = RREG32(RADEON_CRTC_GEN_CNTL); - tmp &= ~RADEON_CRTC_VSTAT_MODE_MASK; - WREG32(RADEON_CRTC_GEN_CNTL, tmp); - /* enable the pflip int */ radeon_irq_kms_pflip_irq_get(rdev, crtc); } diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index cf0638c..78968b7 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -443,7 +443,7 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc, (target_fb->bits_per_pixel * 8)); crtc_pitch |= crtc_pitch << 16;
- + crtc_offset_cntl |= RADEON_CRTC_GUI_TRIG_OFFSET_LEFT_EN; if (tiling_flags & RADEON_TILING_MACRO) { if (ASIC_IS_R300(rdev)) crtc_offset_cntl |= (R300_CRTC_X_Y_MODE_EN | @@ -502,6 +502,7 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc, gen_cntl_val = RREG32(gen_cntl_reg); gen_cntl_val &= ~(0xf << 8); gen_cntl_val |= (format << 8); + gen_cntl_val &= ~RADEON_CRTC_VSTAT_MODE_MASK; WREG32(gen_cntl_reg, gen_cntl_val);
crtc_offset = (u32)base;
On Son, 2011-03-13 at 21:06 +1000, Dave Airlie wrote:
From: Dave Airlie airlied@redhat.com
We've been getting reports of complete system lockups with rv3xx hw on AGP and PCIE when running gnome-shell or kwin with compositing.
It appears the hw really doesn't like setting these registers while stuff is running, this moves the setting of the registers into the modeset since they aren't required to be changed anywhere else.
fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183
Reported-and-tested-by: Álmos <aaalmosss@gmail.com Signed-off-by: Dave Airlie airlied@redhat.com
Reviewed-by: Michel Dänzer michel@daenzer.net
Makes sense and definitely helps here.
From: Dave Airlie airlied@redhat.com
Iterations of this patch seemed to break active vram, this seems like a good plan for it.
second attempt to fix: https://bugs.freedesktop.org/show_bug.cgi?id=35254
Reported-by: Michael Larabel @ phoronix Signed-off-by: Dave Airlie airlied@redhat.com Cc: stable@kernel.org --- drivers/gpu/drm/radeon/radeon_object.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 7d6b8e8..620c321 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -73,9 +73,11 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) rbo->placement.lpfn = 0; rbo->placement.placement = rbo->placements; rbo->placement.busy_placement = rbo->placements; - if (domain & RADEON_GEM_DOMAIN_VRAM) + if (domain & RADEON_GEM_DOMAIN_VRAM) { rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_VRAM; + rbo->placement.lpfn = rbo->rdev->mc.active_vram_size >> PAGE_SHIFT; + } if (domain & RADEON_GEM_DOMAIN_GTT) rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT; if (domain & RADEON_GEM_DOMAIN_CPU)
On Son, 2011-03-13 at 21:06 +1000, Dave Airlie wrote:
From: Dave Airlie airlied@redhat.com
Iterations of this patch seemed to break active vram, this seems like a good plan for it.
second attempt to fix: https://bugs.freedesktop.org/show_bug.cgi?id=35254
Reported-by: Michael Larabel @ phoronix Signed-off-by: Dave Airlie airlied@redhat.com Cc: stable@kernel.org
drivers/gpu/drm/radeon/radeon_object.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 7d6b8e8..620c321 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -73,9 +73,11 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) rbo->placement.lpfn = 0; rbo->placement.placement = rbo->placements; rbo->placement.busy_placement = rbo->placements;
- if (domain & RADEON_GEM_DOMAIN_VRAM)
- if (domain & RADEON_GEM_DOMAIN_VRAM) { rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_VRAM;
rbo->placement.lpfn = rbo->rdev->mc.active_vram_size >> PAGE_SHIFT;- } if (domain & RADEON_GEM_DOMAIN_GTT) rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT; if (domain & RADEON_GEM_DOMAIN_CPU)
This can spuriously limit the BO to active_vram_size in GTT again.
I'm afraid the whole limits handling may need an overhaul...
On Son, 2011-03-13 at 13:19 +0100, Michel Dänzer wrote:
On Son, 2011-03-13 at 21:06 +1000, Dave Airlie wrote:
From: Dave Airlie airlied@redhat.com
Iterations of this patch seemed to break active vram, this seems like a good plan for it.
second attempt to fix: https://bugs.freedesktop.org/show_bug.cgi?id=35254
Reported-by: Michael Larabel @ phoronix Signed-off-by: Dave Airlie airlied@redhat.com Cc: stable@kernel.org
drivers/gpu/drm/radeon/radeon_object.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 7d6b8e8..620c321 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -73,9 +73,11 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) rbo->placement.lpfn = 0; rbo->placement.placement = rbo->placements; rbo->placement.busy_placement = rbo->placements;
- if (domain & RADEON_GEM_DOMAIN_VRAM)
- if (domain & RADEON_GEM_DOMAIN_VRAM) { rbo->placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_VRAM;
rbo->placement.lpfn = rbo->rdev->mc.active_vram_size >> PAGE_SHIFT;- } if (domain & RADEON_GEM_DOMAIN_GTT) rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT; if (domain & RADEON_GEM_DOMAIN_CPU)
This can spuriously limit the BO to active_vram_size in GTT again.
On second thought, I don't understand why this would be necessary / helpful at all. If active_vram_size is the maximum amount of VRAM that should ever be used anywhere (as opposed to the maximum amount visible to the CPU, which I was thinking of before), why is the VRAM ttm_mem_type_manager size field larger than that in the first place?
This can spuriously limit the BO to active_vram_size in GTT again.
On second thought, I don't understand why this would be necessary / helpful at all. If active_vram_size is the maximum amount of VRAM that should ever be used anywhere (as opposed to the maximum amount visible to the CPU, which I was thinking of before), why is the VRAM ttm_mem_type_manager size field larger than that in the first place?
It's a bit of a pain but we don't know we need to limit active VRAM until accel fails later on by which time we've already set the ttm manager up, my current thinking is to make fpfn/lpfn part of the per mem type placement or to force pin a large object in the second chunk of VRAM though i'm not liking that at this point to fix the regression.
Dave
-- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Michel Dänzer