On Thu, Jun 20, 2019 at 1:48 PM Alexandre Courbot wrote:
>
> On Tue, Jun 4, 2019 at 8:20 PM Tomasz Figa wrote:
> > > +
> > > + ret = mdp_vpu_get_locked(mdp);
> > > + if (ret < 0)
> > > + goto err_load_vpu;
> >
> > This shouldn't happen in open(), but rather the latest
Hi Frederic,
On Tue, Jun 25, 2019 at 9:16 PM Frederic Chen
wrote:
>
> Dear Tomasz,
>
> Would you comment on the following points in further? Thank you for the
> review.
>
> On Thu, 2019-05-09 at 18:48 +0900, Tomasz Figa wrote:
> > Hi Frederic,
> >
>
> [snip]
>
> > > +int
From: Dave Jiang
[ Upstream commit 7560cc3ca7d9d11555f80c830544e463fcdb28b8 ]
Lockdep debug reported lock inversion related with the iommu code
caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
the device_domain_lock out of order versus the code path in
iommu_flush_dev_iotlb().
From: Lu Baolu
[ Upstream commit 66d78ad316b0e1ca5ae19663468554e2c0e31c26 ]
Set the page walk snoop to the right bit, otherwise the domain
id field will be overlapped.
Reported-by: Dave Jiang
Fixes: 6f7db75e1c469 ("iommu/vt-d: Add second level page table interface")
Signed-off-by: Lu Baolu
Hi Jonathan,
Thanks for the review, comments inline below. I saw Jean already took
in changes based on your review in his sva/api tree. This is just some
additions.
On Tue, 18 Jun 2019 17:50:59 +0100
Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:12 -0700
> Jacob Pan wrote:
>
> > From:
On Tue, Jun 25, 2019 at 02:23:45PM +0200, Helge Deller wrote:
> On 14.06.19 16:44, Christoph Hellwig wrote:
> > Only call into arch_dma_alloc if we require an uncached mapping,
> > and remove the parisc code manually doing normal cached
> > DMA_ATTR_NON_CONSISTENT allocations.
> >
> >
On Mon, Jun 24, 2019 at 12:53:49PM +0100, Will Deacon wrote:
> On Tue, Jun 18, 2019 at 06:39:33PM +0100, Will Deacon wrote:
> > On Wed, May 15, 2019 at 04:32:34PM -0700, Bjorn Andersson wrote:
> > > Describe the memory related to page table walks as non-cachable for iommu
> > > instances that are
Hi Tomasz,
On Tue, 2019-06-11 at 19:13 +0900, Tomasz Figa wrote:
> On Tue, Jun 11, 2019 at 7:07 PM Frederic Chen
> wrote:
> >
> > Hi Tomasz,
> >
> >
> > On Tue, 2019-06-11 at 17:59 +0900, Tomasz Figa wrote:
> > > On Tue, Jun 11, 2019 at 5:48 PM Frederic Chen
> > > wrote:
> > > >
> > > > Dear
Just like we do for all other block drivers. Especially as the limit
imposed at the moment might be way to pessimistic for iommus.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/queue.c
Hi everyone,
I though I got rid of all non-highmem, non-ISA block layer bounce
buffering a while ago, but I missed the MMC case. While I still plan to
also kill off the highmem bouncing there I won't get to it this merge
window, so for now I'd like to make some progress and move MMC to the
DMA
These days the DMA mapping code must bounce buffer for any not supported
address, and if they driver needs to optimize for natively supported
ranged it should use dma_get_required_mask.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 7 ---
When we remap memory as non-cached to be used as a DMA coherent buffer
we should writeback all cache and invalidate the cache lines so that
we make sure we have a clean slate. Implement this using the
cache_push() helper.
Signed-off-by: Christoph Hellwig
---
arch/m68k/Kconfig | 1 +
Hi Geert,
can you take a look at the (untested) patches below? They convert m68k
to use the generic remapping DMA allocator, which is also used by
arm64 and csky.
Changes since v2:
- fix kconfig dependencies to properly build on sun3
- updated a patch description to better explain why we are
This switche to using common code for the DMA allocations, including
potential use of the CMA allocator if configure. Also add a
comment where the existing behavior seems to be lacking.
Switching to the generic code enables DMA allocations from atomic
context, which is required by the DMA API
Hi Christoph,
On Tue, Jun 25, 2019 at 9:35 AM Christoph Hellwig wrote:
> On Tue, Jun 25, 2019 at 09:26:48AM +0200, Geert Uytterhoeven wrote:
> > > > bloat-o-meter says:
> > > >
> > > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040)
> > >
> > > What do these values stand for? The
On Tue, Jun 25, 2019 at 09:26:48AM +0200, Geert Uytterhoeven wrote:
> > > bloat-o-meter says:
> > >
> > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040)
> >
> > What do these values stand for? The code should grow a little as
> > we now need to include the the pool allocator for the
Hi Christoph,
On Tue, Jun 25, 2019 at 8:33 AM Christoph Hellwig wrote:
> On Mon, Jun 17, 2019 at 08:53:55PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote:
> > > can you take a look at the (untested) patches below? They convert m68k
> > > to use
Hi Will,
On Mon, Jun 24, 2019 at 10:33 PM Will Deacon wrote:
>
> [+Krishna]
>
> Hi Vivek,
>
> On Mon, Jun 24, 2019 at 03:58:32PM +0530, Vivek Gautam wrote:
> > On Tue, Jun 18, 2019 at 11:22 PM Will Deacon wrote:
> > > On Fri, Jun 14, 2019 at 02:48:07PM +0530, Vivek Gautam wrote:
> > > > On
On Mon, Jun 24, 2019 at 09:16:30AM +0200, Geert Uytterhoeven wrote:
> Doing
>
> - select DMA_DIRECT_REMAP if MMU && !COLDFIRE
> + select DMA_DIRECT_REMAP if MMU && !COLDFIRE && !SUN3
>
> in arch/m68k/Kconfig fixes the build.
>
> Alternatively, you could use:
>
> - select
On Mon, Jun 17, 2019 at 08:53:55PM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote:
> > can you take a look at the (untested) patches below? They convert m68k
> > to use the generic remapping DMA allocator, which is also used by
> >
On Mon, Jun 24, 2019 at 03:23:08PM +0100, Vladimir Murzin wrote:
> On 6/14/19 3:44 PM, Christoph Hellwig wrote:
> > The arm-nommu DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but
> > does not provide a cache_sync operation. This means any user of it
> > will never be able to actually
On Sun, Jun 16, 2019 at 06:08:40PM +0800, Hillf Danton wrote:
> Literally, any cpu (call it cpuW) other than pcx12 and pcx1 will no longer do
> dma alloc for any device with this patch applied.
Yes. And that is not a chance from the previous code, where only
pcx1 and pcx12 could do coherent
22 matches
Mail list logo
