On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote:
> Or maybe I'll just send a patch for that
> separately seeing it doesn't depend on anything and is pretty simple. I
> can do that next week.
Yes, please just send that patch linux-nvme, we should be able to get
it into 4.12.
On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote:
> Convert the kmap and kmap_atomic uses to the sg_map function. We now
> store the flags for the kmap instead of a boolean to indicate
> atomicitiy. We also propogate a possible kmap error down and create
> a new
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..b95934b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -37,6 +37,9 @@
>
> #include
>
> +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */
> +#undef
On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote:
> This is a straight forward conversion in two places. Should kmap fail,
> the code will return an INVALD_DATA error in the completion.
It really should be using nvmet_copy_from_sgl to make things safer,
as we don't want to rely on
On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in all four spots.
I think the right fix here is to switch dm-crypt to the ahash API
that takes a scatterlist.
___
Intel-gfx mailing
On Tue, Apr 25, 2017 at 12:20:48PM -0600, Logan Gunthorpe wrote:
> This patch introduces functions which kmap the pages inside an sgl.
> These functions replace a common pattern of kmap(sg_page(sg)) that is
> used in more than 50 places within the kernel.
>
> The motivation for this work is to
On Tue, Apr 25, 2017 at 12:20:49PM -0600, Logan Gunthorpe wrote:
> This is a prep patch to add a new error code to libiscsi. We want to
> rework some kmap calls to be able to fail. When we do, we'd like to
> use this error code.
The kmap case in iscsi_tcp_segment_map can already fail. Please add
On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote:
> Ok, well for starters I think you are mistaken about kmap being able to
> fail. I'm having a hard time finding many users of that function that
> bother to check for an error when calling it.
A quick audit of the arch code shows
> + in_params[0].buffer.pointer = (u8 *)
Any idea why the pointer is defined as a u8 * in union acpi_object
instead of a void?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> for (i = 0; i < NFIT_UUID_MAX; i++)
> - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
> + if (!guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid))
> return i;
I think this should be guid_equal without the "!"
> - if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> - CPER_SEC_PLATFORM_MEM)) {
> + if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) {
The "!" here seems incorrect.
> #ifdef CONFIG_ACPI_APEI_PCIEAER
> - else if
> @@ -165,11 +165,11 @@ static int extlog_print(struct notifier_block *nb,
> unsigned long val,
> err_seq++;
> gdata = (struct acpi_hest_generic_data *)(tmp + 1);
> if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
> - fru_id = (uuid_le *)gdata->fru_id;
> +
On Mon, Jun 05, 2017 at 07:19:43PM +0300, Andy Shevchenko wrote:
> Thanks!
> Are you going to fixup when applying or better me to send an updated
> version?
I'd prefer a resend so that all the maintainers can carefully re-review
the patches.
___
On Thu, Jun 01, 2017 at 12:42:30AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, May 31, 2017 10:41:52 PM Andy Shevchenko wrote:
> > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> > bytes. Instead we convert them to use guid_t type. At the same time we
> > convert current
On Wed, May 31, 2017 at 10:41:47PM +0300, Andy Shevchenko wrote:
> This series converts ACPI and users of acpi_evaluate_dsm() to new UUID
> API which includes new types and methods.
>
> Patches are based on uuid tree [1] from Christoph Hellwig and supposed to
> go through it.
>
On Mon, Jun 05, 2017 at 10:37:41PM +0200, Rafael J. Wysocki wrote:
> On Mon, Jun 5, 2017 at 6:20 PM, Andy Shevchenko
> <andriy.shevche...@linux.intel.com> wrote:
> > On Mon, 2017-06-05 at 18:03 +0200, Christoph Hellwig wrote:
> >> > + in_params[0].buffer.pointer
On Fri, May 05, 2017 at 10:06:06AM +0300, Amir Goldstein wrote:
> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems code).
Yeah.
> IMO, you should acknowledge that the common use case for
On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
> To complete the picture for folks not cc'ed on my patches,
> xfs use case suggests there is also justification for the additional helpers:
>
> uuid_is_null() / uuid_equal()
> guid_is_null() / guid_equal()
The is_null is useful and
On Mon, Jun 05, 2017 at 08:10:42PM +0300, Andy Shevchenko wrote:
> I hope Christoph can replace old version of this series with new one in
> his uuid branch. URL in cover letter, repeating for your convenience:
>
> [1]: git://git.infradead.org/users/hch/uuid.git
Yeah, but I had to drop it again
On Mon, Jun 05, 2017 at 07:23:05PM +0300, Andy Shevchenko wrote:
> > From a quick look over the tree it seems like both fru_id and
> > section_type should be declared as guid_t in
> > struct acpi_hest_generic_data.
>
>
> They are arrays of 16 u8:s.
As is the guid_t.
> And since it's defined in
On Wed, May 09, 2018 at 03:02:55PM +1000, Stephen Rothwell wrote:
> > - ret = of_dma_configure(dev, NULL);
> > + ret = of_dma_configure(dev, NULL, true);
> > if (ret < 0) {
> > DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
> > return ret;
> > --
> > 2.17.0
>
>
On Wed, May 02, 2018 at 11:05:01AM +0100, Chris Wilson wrote:
> This extends the warning suppression from commit d0bc0c2a31c9 ("swiotlb:
> suppress warning when __GFP_NOWARN is set") to suppress the warnings
> when DMA_ATTR_NO_WARN is given by caller. In such cases the caller wants
> to handle the
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
> Does this still guarantee that requests for 16k will not cross a 16k boundary?
> It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to start with,
and you can get not naturally
On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> Perhaps a hint as to how we can fix this up? This is the first time
> I've heard of the comedi code not handling dma properly.
It can be fixed by:
a) never calling virt_to_page (or vmalloc_to_page for that matter)
on dma allocation
On Fri, Jun 14, 2019 at 03:01:22PM +, David Laight wrote:
> I'm pretty sure there is a lot of code out there that makes that assumption.
> Without it many drivers will have to allocate almost double the
> amount of memory they actually need in order to get the required alignment.
> So instead
The memory returned from dma_alloc_coherent is opaqueue to the user,
thus the exact way of page refcounting shall not matter either.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/s390/net/ism_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/broadcom/cnic.c | 4 ++--
1 file changed, 2 insertions
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/qib/qib_iba6120.c | 2 +-
drivers/infiniband/hw/qib
as well.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-contiguous.h | 8 +---
kernel/dma/contiguous.c| 17 +++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index c05d4e661489
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/hfi1/init.c | 22 +++---
1 file changed
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> > On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > > Perhaps a hint as to how we can fix this up? This is the first time
> > > I'
management inside the DMA
allocator is hidden from the callers.
Fixes: a8f3c203e19b ("[media] videobuf-dma-contig: add cache support")
Signed-off-by: Christoph Hellwig
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 23 +++
1 file changed, 8 insertions(+), 15
Hi all,
various architectures have used exact memory allocations for dma
allocations for a long time, but x86 and thus the common code based
on it kept using our normal power of two allocator, which tends to
waste a lot of memory for certain allocations.
Switching to a slightly cleaned up
Remove usage of the legacy drm PCI DMA wrappers, and with that the
incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
and SetPageReserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/ati_pcigart.c | 27 +++
include/drm/ati_pcigart.h | 5
.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 17 -
kernel/dma/mapping.c | 9 +
2 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0a75058c11f3..86135feb2c05 100644
--- a/arch
No need to duplicate the logic over two functions that are almost the
same.
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 5 +++--
mm/page_alloc.c | 39 +++
2 files changed, 10 insertions(+), 34 deletions(-)
diff --git a/include/linux/gfp.h
These functions are rather broken in that they try to pass __GFP_COMP
to dma_alloc_coherent, call virt_to_page on the return value and
mess with PageReserved. And not actually used by any modern driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c | 85
We are not allowed to call virt_to_page on pages returned from
dma_alloc_coherent, as in many cases the virtual address returned
is aactually a kernel direct mapping. Also there generally is no
need to mark dma memory as reserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 3 +--
drivers/net/wireless
comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
can call virt_to_page on the result, and the just remap it as uncached
using vmap. Disable the driver until this API abuse has been fixed.
Signed-off-by: Christoph Hellwig
---
drivers/staging/comedi/Kconfig | 1 +
1 file
This fits in with the naming scheme used by alloc_pages_node.
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 4 ++--
mm/page_ext.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index
Remove usage of the legacy drm PCI DMA wrappers, and with that the
incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
and SetPageReserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/i915_gem.c| 30 +-
drivers/gpu/drm/i915
On Fri, Jun 14, 2019 at 04:05:33PM +0100, Robin Murphy wrote:
> That said, I don't believe this particular patch should make any
> appreciable difference - alloc_pages_exact() is still going to give back
> the same base address as the rounded up over-allocation would, and
> PAGE_ALIGN()ing the
On Wed, Jun 19, 2019 at 01:29:03PM -0300, Jason Gunthorpe wrote:
> > Yes. This will blow up badly on many platforms, as sq->queue
> > might be vmapped, ioremapped, come from a pool without page backing.
>
> Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
>
> Potnuri, you
> drivers/infiniband/hw/cxgb4/qp.c
>129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
>130 {
>131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> sq->memsize,
>132 &(sq->dma_addr), GFP_KERNEL);
>
Please fix up the > 80 char line. Otherwise:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
> Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
> but it turns out that because we didn't filter valid gfp_t flags
> on the DMA allocator, a bunch of drivers were passing __GFP_COMP
> to it, whi
On Tue, Jul 02, 2019 at 11:48:44AM +0200, Arend Van Spriel wrote:
> You made me look ;-) Actually not touching my drivers so I'm off the hook.
> However, I was wondering if drivers could know so I decided to look into
> the DMA-API.txt documentation which currently states:
>
> """
> The flag
On Fri, Aug 16, 2019 at 01:30:29PM +0100, Chris Wilson wrote:
> Quoting Christoph Hellwig (2019-08-16 13:26:44)
> > Please, report the actual problem. Blindly reverting a patch without
> > even an explanation of your regressions is not the way to do it.
>
> As stated, the s
Please, report the actual problem. Blindly reverting a patch without
even an explanation of your regressions is not the way to do it.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Aug 20, 2019 at 12:13:59PM +0900, Sergey Senozhatsky wrote:
> Always put_filesystem() in i915_gemfs_init().
>
> Signed-off-by: Sergey Senozhatsky
> ---
> - v2: rebased (i915 does not remount gemfs anymore)
Which means it real doesn't need its mount anyore, and thus can use
plain old
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> Though personally I'm averse to managing "f"objects through
> "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> on the virtual address of a mapping, but the huge-or-not alignment of
> that mapping must have been
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
cult to use interface.
>
> Signed-off-by: Jason Gunthorpe
Looks good:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
e read-side coherency.
>
> Signed-off-by: Jason Gunthorpe
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
calls it under lock.
>
> Also add a lockdep_assert to check that the callers are holding the lock
> as expected.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Jason Gunthorpe
Looks good:
Reviewed-by: Christoph Hellwig
___
On Wed, Oct 30, 2019 at 02:44:44PM +0800, Jason Wang wrote:
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA.
On Thu, Mar 12, 2020 at 11:14:22AM +0100, Christian König wrote:
> > > The page pointer is set to NULL and only the DMA address,
> > > length and offset values are valid.
> > NAK. The only valid way to fill DMA address in scatterlists is
> > dma_map_sg / dma_map_sg_attr.
>
> How can we then map
On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
> But how should we then deal with all the existing interfaces which already
> take a scatterlist/sg_table ?
>
> The whole DMA-buf design and a lot of drivers are build around
> scatterlist/sg_table and to me that actually makes
On Wed, Mar 11, 2020 at 02:51:53PM +0100, Christian König wrote:
> This can be used by drivers to setup P2P DMA between device
> memory which is not backed by struct pages.
>
> The drivers of the involved devices are responsible for
> setting up and tearing down DMA addresses as necessary
> using
On Wed, Apr 08, 2020 at 09:44:37AM +0800, Zhenyu Wang wrote:
> On 2020.04.04 11:40:58 +0200, Christoph Hellwig wrote:
> > No Xen support anywhere here. Remove a dead declaration and an unused
> > include.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
>
&g
On Mon, Apr 06, 2020 at 11:08:46PM -0400, Yan Zhao wrote:
> hi
> we were removing this code. see
> https://lore.kernel.org/kvm/20200313031109.7989-1-yan.y.z...@intel.com/
This didn't make 5.7-rc1.
> The implementation of vfio_dma_rw() has been in vfio next tree.
>
Signed-off-by: Christoph Hellwig
Acked-by: Michael S. Tsirkin [vhost]
---
drivers/usb/gadget/function/f_fs.c | 4
drivers/vhost/vhost.c | 3 ---
fs/io-wq.c | 8 ++--
fs/io_uring.c | 4
kernel/kthread.c | 6 +
Hi all,
this series improves the use_mm / unuse_mm interface by better
documenting the assumptions, and my taking the set_fs manipulations
spread over the callers into the core API.
Changes since v1:
- drop a few patches
- fix a comment typo
- cover the newly merged use_mm/unuse_mm caller in
ed-off-by: Christoph Hellwig
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +--
drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +--
drivers/usb/gadget/function/f_fs.c | 4 +--
drivers/usb/gadget/legacy/inode.c | 4 +--
drivers/vfio/vfio_iommu_t
These helpers are only for use with kernel threads, and I will tie them
more into the kthread infrastructure going forward. Also move the
prototypes to kthread.h - mmu_context.h was a little weird to start with
as it otherwise contains very low-level MM bits.
Signed-off-by: Christoph Hellwig
On Mon, Apr 13, 2020 at 08:04:10PM -0400, Yan Zhao wrote:
> > I can't think of another way for a kernel thread to have a mm indeed.
> for example, before calling to vfio_dma_rw(), a kernel thread has already
> called use_mm(), then its current->mm is not null, and it has flag
> PF_KTHREAD.
> in
On Thu, Apr 16, 2020 at 08:17:44PM -0700, Matthew Wilcox wrote:
> On Thu, Apr 16, 2020 at 07:31:55AM +0200, Christoph Hellwig wrote:
> > this series improves the use_mm / unuse_mm interface by better
> > documenting the assumptions, and my taking the set_fs manipulations
On Mon, Mar 16, 2020 at 10:41:42AM +0100, Christian König wrote:
> Well I would prefer if the drivers can somehow express their requirements
> and get IOVA structures already in the form they need.
>
> Converting the IOVA data from one form to another is sometimes quite costly.
> Especially when
On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote:
> The non-page scatterlist is also a big concern for RDMA as we have
> drivers that want the page list, so even if we did as this series
> contemplates I'd have still have to split the drivers and create the
> notion of a dma-only
On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote:
> > On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote:
> > > The non-page scatterlist is also a big concern for RDMA as we
These helpers are only for use with kernel threads, and I will tie them
more into the kthread infrastructure going forward. Also move the
prototypes to kthread.h - mmu_context.h was a little weird to start with
as it otherwise contains very low-level MM bits.
Signed-off-by: Christoph Hellwig
Use the proper API instead.
Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD")
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_a
ed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +--
drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +--
drivers/usb/gadget/function/f_fs.c | 4 +--
drivers/usb/gadget/legacy/inode.c | 4 +--
drivers/vhost/vhost.c | 4 +--
fs/i
No Xen support anywhere here. Remove a dead declaration and an unused
include.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/gvt.c | 1 -
drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers
Use the proper API instead.
Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API")
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gp
Hi all,
this series improves the use_mm / unuse_mm interface by better
documenting the assumptions, and my taking the set_fs manipulations
spread over the callers into the core API.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/function/f_fs.c | 4
drivers/vhost/vhost.c | 3 ---
fs/io-wq.c | 8 ++--
fs/io_uring.c | 4
kernel/kthread.c | 6 ++
5 files changed, 8 insertions(+), 17
On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote:
> 1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use
>a proper sg_table entries and call respective DMA-mapping functions
>and adapt current code to it
That sounds reasonable to me. Those could be
er braces here.
> + * Return: 0 or -ERRNO with one of the following status codes:
Maybe say something like:
* Returns 0 on success or one of the following error codes:
Otherwise this looks good:
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Apr 21, 2020 at 09:21:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
> because of a special page vs any other error case.
Looks good,
Reviewed-by: Chris
On Wed, Apr 22, 2020 at 09:39:11AM -0300, Jason Gunthorpe wrote:
> > Nice callchain from hell.. Unfortunately such "code listings" tend to
> > get out of date very quickly, so I'm not sure it is worth keeping in
> > the code. What would be really worthile is consolidating the two
> > different
On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote:
> +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range
> *range,
> + u64 *ioctl_addr)
> {
> unsigned long i, npages;
>
> + /*
> + * The ioctl_addr prepared here is
Currently all drivers provide a feature kconfig that will disable use of
> DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if
> they don't want the overhead.
>
> Signed-off-by: Jason Gunthorpe
Looks good,
Reviewed-by: Christoph Hellwig
On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > Err, why does i915 implements its own uncached memcpy instead of relying
> > on core functionality to start with?
>
> What is this core functionality that provides movntqda?
A sensible name might be memcpy_uncached or
On Wed, Sep 09, 2020 at 09:43:09AM +0800, Lu Baolu wrote:
> + /*
> +* The Intel graphic device driver is used to assume that the
> returned
> +* sg list is not combound. This blocks the efforts of converting
> the
This adds pointless overly long lines.
> +* Intel
On Thu, Sep 03, 2020 at 09:18:37PM +0100, Tom Murphy wrote:
> Disable combining sg segments in the dma-iommu api.
> Combining the sg segments exposes a bug in the intel i915 driver which
> causes visual artifacts and the screen to freeze. This is most likely
> because of how the i915 handles the
On Tue, Sep 08, 2020 at 06:36:19AM +0100, Christoph Hellwig wrote:
> On Mon, Sep 07, 2020 at 09:18:50PM +0100, Tom Murphy wrote:
> > Yeah we talked about passing an attr to map_sg to disable merging at
> > the following microconfernce:
> > https://linuxplumbersconf.org/even
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote:
> Do you mind telling where can I find Marek's series?
[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse
on various lists including the iommu one.
___
Intel-gfx mailing list
On Mon, Sep 07, 2020 at 09:18:50PM +0100, Tom Murphy wrote:
> Yeah we talked about passing an attr to map_sg to disable merging at
> the following microconfernce:
> https://linuxplumbersconf.org/event/7/contributions/846/
> As far as I can remember everyone seemed happy with that solution. I
>
Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/Kconfig | 3 +++
mm/vmalloc.c| 45
vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.
Signed-off-by: Christoph Hellwig
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++
1 file changed, 18 insertions(+), 58
lling from NMI context to avoid a double
negative
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index be4724b916b3e7..8770260419a
Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range. To support callers
that only need the pre-faulting, make the callback optional.
Based on a patch from Minchan Kim .
Signed-off-by: Christoph Hellwig
---
mm/memory.c | 16
Hi Andrew,
this series removes alloc_vm_area, which was left over from the big
vmalloc interface rework. It is a rather arkane interface, basicaly
the equivalent of get_vm_area + actually faulting in all PTEs in
the allocated area. It was originally addeds for Xen (which isn't
modular to start
doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Signed-off-by: Christoph Hellwig
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 127
1 - 100 of 533 matches
Mail list logo
