So this is only build tested as i am away from hardware right now.
Idea is to provide reliable way to check if swiotlb is in use for
a device or not. It seems swiotlb_nr_tbl() is no longer reliable
for that.
Please test.
Cheers,
Jérôme Glisse
From: Jérôme Glisse
Some device like GPU do things differently if swiotlb is in use. We
use to rely on swiotlb_nr_tbl() to know if swiotlb was enabled or not
but this is unreliable. Patch add a simple helpers to check if any of
the dma_ops associated with a device points to the swiotlb function
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérome Glisse
I hate doing this but it hurts my eyes to go over code that does not
comply with indentation rules. Only thing that is not only space change
is in atom.c all other files are space indentation issues.
Signed-off-by: Jérôme Glisse
Cc: Alex Deucher
---
drivers/gpu/drm/rade
From: Jérome Glisse
Quite few suspend/hibernation bugs are related to this block. Add
an option to disable those as a work around.
Signed-off-by: Jérôme Glisse
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_asic.c | 3 ++
From: Jérome Glisse
We need to unpin on suspend and pin on resume. This shuffle code around
to do just that.
Signed-off-by: Jérôme Glisse
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/radeon/radeon_uvd.c | 61 -
drivers/gpu/drm/radeon/radeon
From: Jerome Glisse
Forbid allocating buffer bigger than VRAM or GTT, also properly set
lpfn field of placement if VRAM is too small.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_object.c | 19 ++-
drivers/gp
From: Jerome Glisse
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c | 36 ++-
1 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/gp
From: Jerome Glisse
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c | 34 ++-
1 files changed, 28 insertions(+)
From: Jerome Glisse
GTT/VRAM overlapping test had a typo which leaded to not
detecting case when vram_end > gtt_end. This patch fix the
logic and should fix #16574
cc: stable
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
1 files changed, 1 insertions(+), 1
From: Jerome Glisse
GPU is prone to lockup if we deallocate shader bo right after
submitting command using the shader. Force shader cache flush
after each batch submission seems to fix the issue. It could
fix some of the lockup people were experiencing.
Signed-off-by: Jerome Glisse
---
drivers
From: Jerome Glisse
GPU is prone to lockup if we deallocate shader bo right after
submitting command using the shader. Force shader cache flush
after each batch submission seems to fix the issue. It could
fix some of the lockup people were experiencing.
V2 move shader flush after pipeline flush
From: Jerome Glisse
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
Cc: stable
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c |
From: Jerome Glisse
Forbid allocating buffer bigger than visible VRAM or GTT, also
properly set lpfn field.
v2 - use max macro
- silence warning
v3 - don't explicitly set range limit
- use min macro
v4 - use max btw GTT & VRAM size
Cc: stable
Signed-off-by: Jerome Glisse
---
drivers/g
From: Jerome Glisse
Check if there is a big enough dp clock & enough dp lane to
drive the video mode provided.
Signed-off-by: Jerome Glisse
Cc:
---
drivers/gpu/drm/radeon/atombios_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_
19 matches
Mail list logo
