From 06b6476d6b291473d0928ed242158a001d50c0f0 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexdeucher@gmail.com> Date: Tue, 5 Jan 2010 11:27:29 -0500 Subject: drm/radeon/kms: detect sideport memory on IGP chips This detects if the sideport memory is enabled and if it is VRAM is evicted on suspend/resume. This should fix s/r issues on some IGPs. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> --- drivers/gpu/drm/radeon/rs400.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/gpu/drm/radeon/rs400.c') diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c index 368415d..bf7b3cf 100644 --- a/drivers/gpu/drm/radeon/rs400.c +++ b/drivers/gpu/drm/radeon/rs400.c @@ -356,6 +356,7 @@ static int rs400_mc_init(struct radeon_device *rdev) rdev->mc.vram_location = G_00015C_MC_FB_START(tmp) << 16; rdev->mc.gtt_location = 0xFFFFFFFFUL; r = radeon_mc_setup(rdev); + rdev->mc.igp_sideport_enabled = radeon_combios_sideport_present(rdev); if (r) return r; return 0; -- cgit v1.1 From cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd Mon Sep 17 00:00:00 2001 From: Jerome Glisse <jglisse@redhat.com> Date: Thu, 7 Jan 2010 12:39:21 +0100 Subject: drm/radeon/kms: Schedule host path read cache flush through the ring V2 R300 family will hard lockup if host path read cache flush is done through MMIO to HOST_PATH_CNTL. But scheduling same flush through ring seems harmless. This patch remove the hdp_flush callback and add a flush after each fence emission which means a flush after each IB schedule. Thus we should have same behavior without the hard lockup. Tested on R100,R200,R300,R400,R500,R600,R700 family. V2: Adjust fence counts in r600_blit_prepare_copy() Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> --- drivers/gpu/drm/radeon/rs400.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/gpu/drm/radeon/rs400.c') diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c index bf7b3cf..9f54189 100644 --- a/drivers/gpu/drm/radeon/rs400.c +++ b/drivers/gpu/drm/radeon/rs400.c @@ -396,6 +396,7 @@ static int rs400_startup(struct radeon_device *rdev) return r; /* Enable IRQ */ r100_irq_set(rdev); + rdev->config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL); /* 1M ring buffer */ r = r100_cp_init(rdev, 1024 * 1024); if (r) { -- cgit v1.1 From 655efd3dc92cd0d37292157178d33deb0430aeaa Mon Sep 17 00:00:00 2001 From: Jerome Glisse <jglisse@redhat.com> Date: Tue, 2 Feb 2010 11:51:45 +0100 Subject: drm/radeon/kms: don't call suspend path before cleaning up GPU In suspend path we unmap the GART table while in cleaning up path we will unbind buffer and thus try to write to unmapped GART leading to oops. In order to avoid this we don't call the suspend path in cleanup path. Cleanup path is clever enough to desactive GPU like the suspend path is doing, thus this was redondant. Tested on: RV370, R420, RV515, RV570, RV610, RV770 (all PCIE) Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> --- drivers/gpu/drm/radeon/rs400.c | 2 -- 1 file changed, 2 deletions(-) (limited to 'drivers/gpu/drm/radeon/rs400.c') diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c index 9f54189..eeeb0d6 100644 --- a/drivers/gpu/drm/radeon/rs400.c +++ b/drivers/gpu/drm/radeon/rs400.c @@ -448,7 +448,6 @@ int rs400_suspend(struct radeon_device *rdev) void rs400_fini(struct radeon_device *rdev) { - rs400_suspend(rdev); r100_cp_fini(rdev); r100_wb_fini(rdev); r100_ib_fini(rdev); @@ -527,7 +526,6 @@ int rs400_init(struct radeon_device *rdev) if (r) { /* Somethings want wront with the accel init stop accel */ dev_err(rdev->dev, "Disabling GPU acceleration\n"); - rs400_suspend(rdev); r100_cp_fini(rdev); r100_wb_fini(rdev); r100_ib_fini(rdev); -- cgit v1.1 From a17538f93c16f0e15e35dc31eedad87e2d9c5c26 Mon Sep 17 00:00:00 2001 From: Dave Airlie <airlied@redhat.com> Date: Fri, 5 Feb 2010 13:41:54 +1000 Subject: drm/radeon/kms: rs400/480 MC setup is different than r300. Boot testing on my rs480 laptop found the MC idle never happened on startup, a quick check with AMD found the idle bit is in a different place on the rs4xx than r300. Implement a new rs400 mc idle function to fix this. Signed-off-by: Dave Airlie <airlied@redhat.com> --- drivers/gpu/drm/radeon/rs400.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) (limited to 'drivers/gpu/drm/radeon/rs400.c') diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c index eeeb0d6..287fceb 100644 --- a/drivers/gpu/drm/radeon/rs400.c +++ b/drivers/gpu/drm/radeon/rs400.c @@ -223,15 +223,31 @@ int rs400_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr) return 0; } +int rs400_mc_wait_for_idle(struct radeon_device *rdev) +{ + unsigned i; + uint32_t tmp; + + for (i = 0; i < rdev->usec_timeout; i++) { + /* read MC_STATUS */ + tmp = RREG32(0x0150); + if (tmp & (1 << 2)) { + return 0; + } + DRM_UDELAY(1); + } + return -1; +} + void rs400_gpu_init(struct radeon_device *rdev) { /* FIXME: HDP same place on rs400 ? */ r100_hdp_reset(rdev); /* FIXME: is this correct ? */ r420_pipes_init(rdev); - if (r300_mc_wait_for_idle(rdev)) { - printk(KERN_WARNING "Failed to wait MC idle while " - "programming pipes. Bad things might happen.\n"); + if (rs400_mc_wait_for_idle(rdev)) { + printk(KERN_WARNING "rs400: Failed to wait MC idle while " + "programming pipes. Bad things might happen. %08x\n", RREG32(0x150)); } } @@ -370,8 +386,8 @@ void rs400_mc_program(struct radeon_device *rdev) r100_mc_stop(rdev, &save); /* Wait for mc idle */ - if (r300_mc_wait_for_idle(rdev)) - dev_warn(rdev->dev, "Wait MC idle timeout before updating MC.\n"); + if (rs400_mc_wait_for_idle(rdev)) + dev_warn(rdev->dev, "rs400: Wait MC idle timeout before updating MC.\n"); WREG32(R_000148_MC_FB_LOCATION, S_000148_MC_FB_START(rdev->mc.vram_start >> 16) | S_000148_MC_FB_TOP(rdev->mc.vram_end >> 16)); -- cgit v1.1