lkml.org 
[lkml]   [2019]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] nouveau/hmm: map pages after migration
On Thu, Aug 08, 2019 at 02:29:34PM -0700, Ralph Campbell wrote:
>>> {
>>> struct nouveau_fence *fence;
>>> unsigned long addr = args->start, nr_dma = 0, i;
>>> for (i = 0; addr < args->end; i++) {
>>> args->dst[i] = nouveau_dmem_migrate_copy_one(drm, args->vma,
>>> - addr, args->src[i], &dma_addrs[nr_dma]);
>>> + args->src[i], &dma_addrs[nr_dma], &pfns[i]);
>>
>> Nit: I find the &pfns[i] way to pass the argument a little weird to read.
>> Why not "pfns + i"?
>
> OK, will do in v2.
> Should I convert to "dma_addrs + nr_dma" too?

I'll fix it up for v3 of the migrate_vma series. This is a leftover
from passing an args structure.

On something vaguely related to this patch:

You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
a little odd as we only ever set these bits, but they also don't seem
to appear to be in values that are directly fed to the hardware.

On the other hand mmu/vmm.h defines a set of NVIF_VMM_PFNMAP_V0_*
constants with similar names and identical values, and those are used
in mmu/vmmgp100.c and what appears to finally do the low-level dma
mapping and talking to the hardware. Are these two sets of constants
supposed to be the same? Are the actual hardware values or just a
driver internal interface?

\
 
 \ /
  Last update: 2019-08-10 13:13    [W:0.070 / U:11.936 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site