* [PATCH 0/2] radeon regression fixes
@ 2011-03-13 11:06 Dave Airlie
2011-03-13 11:06 ` [PATCH 1/2] drm/radeon: fix page flipping hangs on r300/r400 Dave Airlie
2011-03-13 11:06 ` [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70 Dave Airlie
0 siblings, 2 replies; 7+ messages in thread
From: Dave Airlie @ 2011-03-13 11:06 UTC (permalink / raw)
To: dri-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/2] drm/radeon: fix page flipping hangs on r300/r400
2011-03-13 11:06 [PATCH 0/2] radeon regression fixes Dave Airlie
@ 2011-03-13 11:06 ` Dave Airlie
2011-03-13 12:20 ` Michel Dänzer
2011-03-13 11:06 ` [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70 Dave Airlie
1 sibling, 1 reply; 7+ messages in thread
From: Dave Airlie @ 2011-03-13 11:06 UTC (permalink / raw)
To: dri-devel
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;
--
1.7.3.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70
2011-03-13 11:06 [PATCH 0/2] radeon regression fixes Dave Airlie
2011-03-13 11:06 ` [PATCH 1/2] drm/radeon: fix page flipping hangs on r300/r400 Dave Airlie
@ 2011-03-13 11:06 ` Dave Airlie
2011-03-13 12:19 ` Michel Dänzer
1 sibling, 1 reply; 7+ messages in thread
From: Dave Airlie @ 2011-03-13 11:06 UTC (permalink / raw)
To: dri-devel
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)
--
1.7.3.4
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70
2011-03-13 11:06 ` [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70 Dave Airlie
@ 2011-03-13 12:19 ` Michel Dänzer
2011-03-13 12:36 ` Michel Dänzer
0 siblings, 1 reply; 7+ messages in thread
From: Michel Dänzer @ 2011-03-13 12:19 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel
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...
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70
2011-03-13 12:19 ` Michel Dänzer
@ 2011-03-13 12:36 ` Michel Dänzer
2011-03-13 19:34 ` Dave Airlie
0 siblings, 1 reply; 7+ messages in thread
From: Michel Dänzer @ 2011-03-13 12:36 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel
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?
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70
2011-03-13 12:36 ` Michel Dänzer
@ 2011-03-13 19:34 ` Dave Airlie
0 siblings, 0 replies; 7+ messages in thread
From: Dave Airlie @ 2011-03-13 19:34 UTC (permalink / raw)
To: Michel Dänzer; +Cc: dri-devel@lists.freedesktop.org
>> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-13 19:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-13 11:06 [PATCH 0/2] radeon regression fixes Dave Airlie
2011-03-13 11:06 ` [PATCH 1/2] drm/radeon: fix page flipping hangs on r300/r400 Dave Airlie
2011-03-13 12:20 ` Michel Dänzer
2011-03-13 11:06 ` [PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70 Dave Airlie
2011-03-13 12:19 ` Michel Dänzer
2011-03-13 12:36 ` Michel Dänzer
2011-03-13 19:34 ` Dave Airlie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox