[PATCH 06/11] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE
Daniel Vetter
daniel at ffwll.ch
Wed Jul 22 05:34:30 UTC 2020
On Tue, Jul 21, 2020 at 4:46 PM Christian König
<ckoenig.leichtzumerken at gmail.com> wrote:
>
> Am 21.07.20 um 11:24 schrieb daniel at ffwll.ch:
> > On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:
> >> The driver doesn't expose any not-mapable memory resources.
> >>
> >> Signed-off-by: Christian König <christian.koenig at amd.com>
> >> ---
> >> drivers/gpu/drm/radeon/radeon_ttm.c | 13 ++++---------
> >> 1 file changed, 4 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> >> index 54af06df865b..b474781a0920 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> >> @@ -76,7 +76,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >> switch (type) {
> >> case TTM_PL_SYSTEM:
> >> /* System memory */
> >> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> >> + man->flags = 0;
> >> man->available_caching = TTM_PL_MASK_CACHING;
> >> man->default_caching = TTM_PL_FLAG_CACHED;
> >> break;
> >> @@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >> man->func = &ttm_bo_manager_func;
> >> man->available_caching = TTM_PL_MASK_CACHING;
> >> man->default_caching = TTM_PL_FLAG_CACHED;
> >> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> >> + man->flags = 0;
> >> #if IS_ENABLED(CONFIG_AGP)
> >> if (rdev->flags & RADEON_IS_AGP) {
> >> if (!rdev->ddev->agp) {
> >> @@ -92,8 +92,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >> (unsigned)type);
> >> return -EINVAL;
> >> }
> >> - if (!rdev->ddev->agp->cant_use_aperture)
> >> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> > There is a bunch of agp drivers (alpha, ppc, that kind of stuff) with this
> > flag set. And radeon.ko did at least once work on these. And your patch to
> > disable agp only changes the default, it doesn't rip out the code.
>
> The key pint is that the flags for AGP are the same as the one for the
> PCIe path. So no functional change at all :)
I misread the code somehow, I didn't spot the unconditional setting of
FLAG_MAPPABLE for all TTM_PL_TT, irrespective of agp or not, somehow
thought that's another case.
Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> The real handling of cant_use_aperture is in radeon_ttm_io_mem_reserve().
>
> Christian.
>
> >
> > So not sure your assumption here is correct.
> > -Daniel
> >
> >> man->available_caching = TTM_PL_FLAG_UNCACHED |
> >> TTM_PL_FLAG_WC;
> >> man->default_caching = TTM_PL_FLAG_WC;
> >> @@ -103,8 +101,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >> case TTM_PL_VRAM:
> >> /* "On-card" video ram */
> >> man->func = &ttm_bo_manager_func;
> >> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> >> - TTM_MEMTYPE_FLAG_MAPPABLE;
> >> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
> >> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> >> man->default_caching = TTM_PL_FLAG_WC;
> >> break;
> >> @@ -394,7 +391,6 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, bool evict,
> >>
> >> static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
> >> {
> >> - struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
> >> struct radeon_device *rdev = radeon_get_rdev(bdev);
> >>
> >> mem->bus.addr = NULL;
> >> @@ -402,8 +398,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_
> >> mem->bus.size = mem->num_pages << PAGE_SHIFT;
> >> mem->bus.base = 0;
> >> mem->bus.is_iomem = false;
> >> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> >> - return -EINVAL;
> >> +
> >> switch (mem->mem_type) {
> >> case TTM_PL_SYSTEM:
> >> /* system memory */
> >> --
> >> 2.17.1
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list