On Mon, Dec 10, 2018 at 01:51:13PM -0800, Luck, Tony wrote:
> But the ia64 build fails with:
Yes, I just got the same complaint form the buildbot, unfortunately
I don't have a good ia64 cross compiler locally given that Debian
is lacking one, and the one provided by the buildbot doesn't build on
On Mon, Dec 10, 2018 at 03:06:47PM +, Jean-Philippe Brucker wrote:
> On 27/11/2018 18:53, Michael S. Tsirkin wrote:
> > On Tue, Nov 27, 2018 at 06:10:46PM +, Jean-Philippe Brucker wrote:
> >> On 27/11/2018 18:04, Michael S. Tsirkin wrote:
> >>> On Tue, Nov 27, 2018 at 05:50:50PM +,
On Fri, Dec 07, 2018 at 11:07:05AM -0800, Christoph Hellwig wrote:
> This works is based on the dma-mapping tree, so you probably want to
> want this git tree for testing:
>
> git://git.infradead.org/users/hch/misc.git dma-direct-calls.2
Pulled this tree. Got HEAD
33b9fc015171
On Mon, 10 Dec 2018, Robin Murphy wrote:
> dma-debug is now capable of adding new entries to its pool on-demand if
> the initial preallocation was insufficient, so the IOMMU_LEAK logic no
> longer needs to explicitly change the pool size. This does lose it the
> ability to save a couple of
On 12/10/18 12:00 PM, Tim Chen wrote:
>> @@ -528,6 +538,9 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
>> dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n",
>> size);
>> return SWIOTLB_MAP_ERROR;
>> found:
>> +#ifdef CONFIG_DEBUG_FS
>> +io_tlb_used
On 12/9/18 4:37 PM, Dongli Zhang wrote:
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 045930e..3979c2c 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -35,6 +35,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_DEBUG_FS
> +#include
>
From: Christoph Hellwig
Date: Mon, 10 Dec 2018 20:22:28 +0100
> On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
>> From: Christoph Hellwig
>> Date: Mon, 10 Dec 2018 17:32:56 +0100
>>
>> > Dave, can you pick the series up through the sparc tree? I could also
>> > merge it through
ping?
On Tue, Dec 04, 2018 at 08:06:19AM -0800, Christoph Hellwig wrote:
> We already zero the memory after allocating it from the pool that
> this function fills, and having the memset here in this form means
> we can't support CMA highmem allocations.
>
> Signed-off-by: Christoph Hellwig
>
On Mon, Dec 10, 2018 at 07:19:30PM +, Robin Murphy wrote:
> On 08/12/2018 17:36, Christoph Hellwig wrote:
>> There is no need to have an additional kernel mapping for a contiguous
>> allocation if the device already is DMA coherent, so skip it.
>
> FWIW, the "need" was that it kept the code in
On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
> From: Christoph Hellwig
> Date: Mon, 10 Dec 2018 17:32:56 +0100
>
> > Dave, can you pick the series up through the sparc tree? I could also
> > merge it through the dma-mapping tree, but given that there is no
> > dependency on it
On 08/12/2018 17:36, Christoph Hellwig wrote:
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
FWIW, the "need" was that it kept the code in this path simple and the
mapping behaviour consistent with the
On Sat, Dec 08, 2018 at 07:52:04PM -0300, Ezequiel Garcia wrote:
> > #ifdef CONFIG_DMA_API_DEBUG
> > @@ -773,7 +791,7 @@ static void *__dma_alloc(struct device *dev, size_t
> > size, dma_addr_t *handle,
> >
> > if (cma)
> > buf->allocator = _allocator;
> > - else if
On Mon, Dec 10, 2018 at 08:26:48AM +0100, Sascha Hauer wrote:
> > the ARM imx27/31 ports and various sh boards use
> > dma_declare_coherent_memory on main memory taken from the memblock
> > allocator.
> >
> > Is there any good reason these couldn't be switched to CMA areas?
> > Getting rid of
From: Christoph Hellwig
Date: Mon, 10 Dec 2018 17:32:56 +0100
> Dave, can you pick the series up through the sparc tree? I could also
> merge it through the dma-mapping tree, but given that there is no
> dependency on it the sparc tree seem like the better fit.
I thought that some of this is a
On 12/9/18 4:37 PM, Dongli Zhang wrote:
> The device driver will not be able to do dma operations once swiotlb buffer
> is full, either because the driver is using so many IO TLB blocks inflight,
> or because there is memory leak issue in device driver. To export the
> swiotlb buffer usage via
On 12/9/18 4:37 PM, Dongli Zhang wrote:
> This patch uses io_tlb_used to help check whether swiotlb buffer is full.
> io_tlb_used is no longer used for only debugfs. It is also used to help
> optimize swiotlb_tbl_map_single().
>
> Suggested-by: Joe Jin
> Signed-off-by: Dongli Zhang
Dave, can you pick the series up through the sparc tree? I could also
merge it through the dma-mapping tree, but given that there is no
dependency on it the sparc tree seem like the better fit.
___
iommu mailing list
iommu@lists.linux-foundation.org
On 07/12/2018 20:41, Souptick Joarder wrote:
On Fri, Dec 7, 2018 at 7:17 PM Robin Murphy wrote:
On 06/12/2018 18:43, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
Next step: 64ecd2c160bbef31465c4d34efc0f076a2aad4df (powerpc/dma: use
phys_to_dma instead of get_dma_offset)
The P5020 board boots and the PASEMI onboard ethernet works.
-- Christian
On 09 December 2018 at 7:26PM, Christian Zigotzky wrote:
Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a
On 12/10/18 9:00 AM, Robin Murphy wrote:
> Hi all,
>
> Here's some assorted cleanup and improvements to dma-debug which grew
> out of the problem that certain drivers use very large numbers of DMA
> mappings, and knowing when to override "dma_debug_entries=..." and what
> value to override it
On 27/11/2018 18:53, Michael S. Tsirkin wrote:
> On Tue, Nov 27, 2018 at 06:10:46PM +, Jean-Philippe Brucker wrote:
>> On 27/11/2018 18:04, Michael S. Tsirkin wrote:
>>> On Tue, Nov 27, 2018 at 05:50:50PM +, Jean-Philippe Brucker wrote:
On 23/11/2018 22:02, Michael S. Tsirkin wrote:
DMA debug entries are one of those things which aren't that useful
individually - we will always want some larger quantity of them - and
which we don't really need to manage the exact number of - we only care
about having 'enough'. In that regard, the current behaviour of creating
them one-by-one
With the only caller now gone, we can clean up this part of dma-debug's
exposed internals and make way to tweak the allocation behaviour.
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v3: Add Christoph's review tag
include/linux/dma-debug.h | 7 --
kernel/dma/debug.c
Now that we can dynamically allocate DMA debug entries to cope with
drivers maintaining excessively large numbers of live mappings, a driver
which *does* actually have a bug leaking mappings (and is not unloaded)
will no longer trigger the "DMA-API: debugging out of memory - disabling"
message
dma-debug is now capable of adding new entries to its pool on-demand if
the initial preallocation was insufficient, so the IOMMU_LEAK logic no
longer needs to explicitly change the pool size. This does lose it the
ability to save a couple of megabytes of RAM by reducing the pool size
below its
Certain drivers such as large multi-queue network adapters can use pools
of mapped DMA buffers larger than the default dma_debug_entry pool of
65536 entries, with the result that merely probing such a device can
cause DMA debug to disable itself during boot unless explicitly given an
appropriate
Expose nr_total_entries in debugfs, so that {num,min}_free_entries
become even more meaningful to users interested in current/maximum
utilisation. This becomes even more relevant once nr_total_entries
may change at runtime beyond just the existing AMD GART debug code.
Reviewed-by: Christoph
Use pr_fmt() to generate the "DMA-API: " prefix consistently. This
results in it being added to a couple of pr_*() messages which were
missing it before, and for the err_printk() calls moves it to the actual
start of the message instead of somewhere in the middle.
Reviewed-by: Christoph Hellwig
Hi all,
Here's some assorted cleanup and improvements to dma-debug which grew
out of the problem that certain drivers use very large numbers of DMA
mappings, and knowing when to override "dma_debug_entries=..." and what
value to override it with can be a less-than-obvious task for users.
The
On 30/11/2018 11:14, John Garry wrote:
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
respective device NUMA node. The ternary operator which would be for
alloc_pages_node() is tidied along with this.
The motivation for this change is to
On Fri, Dec 07, 2018 at 05:57:42PM +, John Garry wrote:
> A friendly reminder. Can you please let me know your position on this patch?
I am waiting for a Reviewed-by or at least Acked-by from Robin on it
before I put it in my tree.
Regards,
Joerg
Hi Lu Baolu,
On Mon, Dec 10, 2018 at 10:57:22AM +0800, Lu Baolu wrote:
> > /* Check if a device supports a given feature of the IOMMU-API */
> > bool iommu_dev_has_feature(struct device *dev, enum iommu_dev_features
> > *feat);
>
> Here we pass in a pointer of "enum iommu_dev_features",
Hi Kevin,
On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
> Can I interpret above as that you agree with the aux domain concept (i.e. one
> device can be linked to multiple domains) in general, and now we're just
> trying
> to address the remaining open in API level?
Yes, I thouht
On Fri, Dec 07, 2018 at 04:34:32PM +0100, Christoph Hellwig wrote:
> Hi all,
>
> the ARM imx27/31 ports and various sh boards use
> dma_declare_coherent_memory on main memory taken from the memblock
> allocator.
>
> Is there any good reason these couldn't be switched to CMA areas?
> Getting rid
34 matches
Mail list logo
