search for: map_sg

.../drivers/gpu/drm/nouveau/core/subdev/vm/base.c b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c > > index ef3133e..5833851 100644 > > --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c > > +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c > > @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta, u64 length, > > { > > struct nouveau_vm *vm = vma->vm; > > struct nouveau_vmmgr *vmm = vm->vmm; > > - int big = vma->node->type != vmm->spg_shift; > > + u32 shift = vma->node->type; > > + int big...

.../nouveau/core/subdev/vm/base.c b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c >> > index ef3133e..5833851 100644 >> > --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c >> > +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c >> > @@ -84,10 +84,11 @@ nouveau_vm_map_sg_table(struct nouveau_vma *vma, u64 delta, u64 length, >> > { >> > struct nouveau_vm *vm = vma->vm; >> > struct nouveau_vmmgr *vmm = vm->vmm; >> > - int big = vma->node->type != vmm->spg_shift; >> > + u32 shift = vma->node-&...

...d thus I'm on the right track) : This patch (which needs cleanups, and probably be broken down for bisectability) makes it work for me. I've disabled nouveau_dri for now as this has its own problems related to Ajax recent gallium endian changes. Note the horrible duplication of nouveau_vm_map_sg... I think to fix it "cleanly" we probably need to slightly change the ->map_sg API to the vmmr. However, I do have a question whose answer might make things a LOT easier if "yes" can make things a lot easier: Can we guarantee that that such an sg object (I assume this is a...

...track) : > This patch (which needs cleanups, and probably be broken down for > bisectability) makes it work for me. I've disabled nouveau_dri for now > as this has its own problems related to Ajax recent gallium endian > changes. > > Note the horrible duplication of nouveau_vm_map_sg... > > I think to fix it "cleanly" we probably need to slightly change the > ->map_sg API to the vmmr. However, I do have a question whose answer > might make things a LOT easier if "yes" can make things a lot easier: > > Can we guarantee that that such an s...

...+1000, Ben Skeggs wrote: > > Additionally the current code is broken in that the upper layer in > > vm/base.c doesn't increment "pte" by the right amount. > > > > Now, if those two assertions can be made always true: > > > > - Those two functions (map_sg and map_sg_table) never deal with the > > "big" case. > > > > - An object is always mapped at a card address that is a multiple > > of PAGE_SIZE (ie, invividual PAGE_SIZE pages don't cross pde boundaries > > when mapped) > I think these two restricti...

...; >> > Additionally the current code is broken in that the upper layer in >> > vm/base.c doesn't increment "pte" by the right amount. >> > >> > Now, if those two assertions can be made always true: >> > >> > - Those two functions (map_sg and map_sg_table) never deal with the >> > "big" case. >> > >> > - An object is always mapped at a card address that is a multiple >> > of PAGE_SIZE (ie, invividual PAGE_SIZE pages don't cross pde boundaries >> > when mapped) > >>...

...ptop. You can see a picture of it here: >> https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg >> >> This issue is most likely in the i915 driver and is most likely caused >> by the driver not respecting the return value of the >> dma_map_ops::map_sg function. You can see the driver ignoring the >> return value here: >> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 >> >> Previously this didn?t cause issues because the intel map_sg always &gt...

On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote: > > This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here: > > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > > > Previously this didn?t cause issues because the intel map_sg always returned...

Hi folks ! So I've been trying to figure out what it would take to make nouveau work properly on architectures where PAGE_SIZE isn't 4k such as most ppc64's. An initial patch from Dave fixed a bogon in nv41.c nv41_vm_map_sg() which was trying to handle the case at that low level, but this isn't enough, and after a bit of digging, I also think that's not the right approach: So, from what I can tell, subdev/vm/base.c is not clean vs. PAGE_SIZE in a number of places unless I'm mistaken. For example, in nouve...

...piece of card > address space in the card VM and thus shouldn't be concerned by the > system PAGE_SIZE at all, right ? Former, but the code entangles system PAGE_SIZE and card PAGE_SIZE/SHIFT/MASK in some cases. > IE. The only one we should actually care about here is > nouveau_vm_map_sg_table() or am I missing an important piece of the > puzzle ? nouveau_vm_map_sg too. nouveau_vm_map is special, and also used to map VRAM into BAR1/BAR3 by subdev/bar code. > Additionally, nv41.c has only map_sg() callbacks, no map() callbacks, > should I assume that means that nouveau_vm_...

Andy, to make it obvious which version is the latest, here is a branch The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861: Linux 4.3 (2015-11-01 16:05:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git dma for you to fetch changes up to fc7f9754db6ce0c12281da4055281f731d36bdee: s390/dma: Allow

Andy, to make it obvious which version is the latest, here is a branch The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861: Linux 4.3 (2015-11-01 16:05:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git dma for you to fetch changes up to fc7f9754db6ce0c12281da4055281f731d36bdee: s390/dma: Allow

...cpu_addr, get_order(size)); -} - -static dma_addr_t alpha_noop_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, - enum dma_data_direction dir, - struct dma_attrs *attrs) -{ - return page_to_pa(page) + offset; -} - -static int alpha_noop_map_sg(struct device *dev, struct scatterlist *sgl, int nents, - enum dma_data_direction dir, struct dma_attrs *attrs) -{ - int i; - struct scatterlist *sg; - - for_each_sg(sgl, sg, nents, i) { - void *va; - - BUG_ON(!sg_page(sg)); - va = sg_virt(sg); - sg_dma_address(sg) = (dma_addr_t)virt_to_...

...cpu_addr, get_order(size)); -} - -static dma_addr_t alpha_noop_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, - enum dma_data_direction dir, - struct dma_attrs *attrs) -{ - return page_to_pa(page) + offset; -} - -static int alpha_noop_map_sg(struct device *dev, struct scatterlist *sgl, int nents, - enum dma_data_direction dir, struct dma_attrs *attrs) -{ - int i; - struct scatterlist *sg; - - for_each_sg(sgl, sg, nents, i) { - void *va; - - BUG_ON(!sg_page(sg)); - va = sg_virt(sg); - sg_dma_address(sg) = (dma_addr_t)virt_to_...

...screen of my > laptop. You can see a picture of it here: > https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > > This issue is most likely in the i915 driver and is most likely caused > by the driver not respecting the return value of the > dma_map_ops::map_sg function. You can see the driver ignoring the > return value here: > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > Previously this didn?t cause issues because the intel map_sg always > returned the s...

Andy, this is the next and hopefully last version. Seems to work fine when replacing the previous patches in your tree. I have some reviews/acks for patch 2 and 3. patch 1 still needs one ack. Can you replace the patches in your tree and carry them along with your changes? old introduction: ----- There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use

Andy, this is the next and hopefully last version. Seems to work fine when replacing the previous patches in your tree. I have some reviews/acks for patch 2 and 3. patch 1 still needs one ack. Can you replace the patches in your tree and carry them along with your changes? old introduction: ----- There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use

It seems the problems running mthca in a Xen domU have uncovered a bug in mthca: mthca uses dma_sync_single in mthca_arbel_write_mtt_seg() and mthca_arbel_map_phys_fmr() to sync the MTTs that get written. However, Documentation/DMA-API.txt says: void dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) synchronise a single

...t; I won't be surprised. If yes I suggested a way to mitigate the overhead. > > > > Did we get better results (lower regression due to indirect calls) with > > the suggested mitigation ? Just curious. > > I'm referring to this: > I wonder whether we can support map_sg and friends being NULL, then use > that when mapping is an identity. A conditional branch there is likely > very cheap. > > I don't think anyone tried implementing this yes. I've done something very similar in the thread I posted a few years ago. I plan to get a version of t...

...t; I won't be surprised. If yes I suggested a way to mitigate the overhead. > > > > Did we get better results (lower regression due to indirect calls) with > > the suggested mitigation ? Just curious. > > I'm referring to this: > I wonder whether we can support map_sg and friends being NULL, then use > that when mapping is an identity. A conditional branch there is likely > very cheap. > > I don't think anyone tried implementing this yes. I've done something very similar in the thread I posted a few years ago. I plan to get a version of t...