[PATCH] [RFC/HACK] drm/ttm: avoid multihop moves in drivers.

[Dave Airlie]

On Tue, 20 Oct 2020 at 18:31, Christian König <christian.koenig at amd.com> wrote:
>
> Yes, please! That approach looks even better than what I had in mind.
>
> A few comments below:
>
> Am 20.10.20 um 06:16 schrieb Dave Airlie:
> > From: Dave Airlie <airlied at redhat.com>
> >
> > [SNIP]
> > +     /* don't go from system->vram in one hop,
> > +        report this back to the caller tell it
> > +        where to bounce this buffer through. */
> > +
> > +     if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> > +          new_mem->mem_type == TTM_PL_VRAM) ||
> > +         (old_mem->mem_type == TTM_PL_VRAM &&
> > +          new_mem->mem_type == TTM_PL_SYSTEM)) {
> > +             new_mem->mem_type = TTM_PL_TT;
>
> Not sure if that is such a good idea, new_mem can be some allocated
> memory in the VRAM domain at this moment.
>
> Maybe instead give the callback a separate bounce argument instead.

I've changed this in the latest posting to take a ttm_place that the
driver fills out
if it needs a hop.

> > +     /* find space in the bounce domain */
> > +     ret = ttm_bo_mem_space(bo, &bounce_placement, mem, ctx);
> > +     if (ret)
> > +             return ret;
> > +     /* move to the bounce domain */
> > +     ret = ttm_bo_handle_move_mem(bo, mem, false, ctx);
>
> Is this a recursion? I don't think it is, but I thought I better double
> check.

No it should never recurse because the driver should only return
-EMULTIHOP once,
even if a theoretical driver was to need > 1 hops it should work until
it returns something
other than -EMULTIHOP. Of course a broken driver could cause bad
things, but that is
always true.

Dave.