From: Laurentiu Tudor
Date: Wed, 13 Nov 2019 12:24:17 +
> From: Laurentiu Tudor
>
> This series introduces a few new dma unmap and sync api variants that,
> on top of what the originals do, return the virtual address
> corresponding to the input dma address. In order to do that a new dma
>
From: laurentiu.tu...@nxp.com
Date: Thu, 30 May 2019 17:19:45 +0300
> Depends on this pull request:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
I'm not sure how you want me to handle this.
From: laurentiu.tu...@nxp.com
Date: Sat, 27 Apr 2019 10:10:25 +0300
> @@ -1914,7 +1936,10 @@ static int fman_reset(struct fman *fman)
> static int fman_init(struct fman *fman)
> {
> struct fman_cfg *cfg = NULL;
> - int err = 0, i, count;
> + int err = 0, count;
> +#ifdef CONFIG_PPC
From: Christoph Hellwig
Date: Wed, 10 Apr 2019 18:54:30 +0200
> Dave, are you going to pick this up through the sparc tree, or do
> you expect me to send it through the dma-mapping one?
Please take it through dma-mapping as I'm a bit overloaded right now
and that would therefore help me a lot.
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:58 +0100
> We've been moving to a model where the device just sets the DMA mask
> supported by it, instead of having to fallback to something it thinks
> the platform might support. Sparc64 is the remaining holdout forcing
> drivers to supply
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:57 +0100
> We've been moving to a model where the device just sets the DMA mask
> supported by it, instead of having to fallback to something it thinks
> the platform might support. Sparc64 is the remaining holdout forcing
> drivers to supply
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:56 +0100
> Do the quirk first in the dma_supported routines, as we don't need
> any of the other checks for it, and remove the duplicate mask checking
> that is already done by the callers.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Davi
From: Christoph Hellwig
Date: Mon, 11 Feb 2019 14:19:56 +0100
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various
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 co
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
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:57 -0800
> Move the alloc / free routines down the file so that we can easily use
> the map / unmap helpers to implement non-consistent allocations.
>
> Also drop the _coherent postfix to match the method name.
>
> Signed-off-by: Christoph He
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:59 -0800
> Move the alloc / free routines down the file so that we can easily use
> the map / unmap helpers to implement non-consistent allocations.
>
> Also drop the _coherent postfix to match the method name.
>
> Signed-off-by: Christoph He
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:37:00 -0800
> Just allocate the memory and use map_page to map the memory.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-foundation.org
https
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:36:58 -0800
> Just allocate the memory and use map_page to map the memory.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-foundation.org
https
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:15 -0800
> There are enough common defintions that a single header seems nicer.
>
> Also drop the pointless include.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Sam Ravnborg
Acked-by: David S. Miller
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:14 -0800
> It has nothing to do with the content of the pci.h header.
>
> Suggested by: Sam Ravnborg
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@list
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:12 -0800
> There is no good reason to have a double indirection for the sparc32
> dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops
> instance for the different IOMMU types.
>
> Signed-off-by: Christoph Hellwig
Acked-by:
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:13 -0800
> The only thing we need to explicitly pull in is the defines for the
> CPU type.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-f
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:11 -0800
> Factor the code to remap memory returned from the DMA coherent allocator
> into two helpers that can be shared by the IOMMU and direct mapping code.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
_
From: Christoph Hellwig
Date: Sat, 8 Dec 2018 09:41:10 -0800
> No need to BUG_ON() on the cache maintainance ops - they are no-ops
> by default, and there is nothing in the DMA API contract that prohibits
> calling them on sbus devices (even if such drivers are unlikely to
> ever appear).
>
> S
From: Linus Torvalds
Date: Wed, 28 Nov 2018 10:00:06 -0800
> Not all memory is accessible even to the kernel. If you have memory
> that shows up in the last page of phys_addr_t, you just mark it
> reserved at boot-time.
It's not the physical memory at the end that needs to be reserved.
It's the
From: Christoph Hellwig
Date: Fri, 9 Nov 2018 09:46:30 +0100
> Error reporting for the dma_map_single and dma_map_page operations is
> currently a mess. Both APIs directly return the dma_addr_t to be used for
> the DMA, with a magic error escape that is specific to the instance and
> checked by
From: Sam Ravnborg
Date: Mon, 27 Aug 2018 21:15:18 +0200
> Why not fix the drivers rather than papering over the fact
> that they are missing the DMA mask?
>
> We are in the lucky situation the Meelis can test any patches.
SBUS drivers never set the mask because they never needed to and could
u
From: Christoph Hellwig
Date: Wed, 22 Aug 2018 07:36:13 +0200
> I fear you have already pushed out your tree, but otherwise it would
> be better do merge it through the dma-mapping tree.
I did and asked Linus to pull as well. Sorry :-/
___
iommu maili
From: Christoph Hellwig
Date: Fri, 3 Aug 2018 09:48:40 +0200
> any chance you would consider reviewing and applying this patch,
> which already has an ACK from Sam? It would really help me with
> some core DMA API projects planned for the next merge window.
Applied, thanks Chrisoph.
___
From: Christoph Hellwig
Date: Wed, 25 Apr 2018 07:15:27 +0200
> This code is only used by sparc, and all new iommu drivers should use the
> drivers/iommu/ framework. Also remove the unused exports.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Anshuman Khandual
Acked-by: David S. Mille
From: Anshuman Khandual
Date: Mon, 16 Apr 2018 14:26:07 +0530
> On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
>> This code is only used by sparc, and all new iommu drivers should use the
>> drivers/iommu/ framework. Also remove the unused exports.
>>
>> Signed-off-by: Christoph Hellwig
>
>
From: Christoph Hellwig
Date: Thu, 8 Jun 2017 15:25:45 +0200
> DMA_ERROR_CODE is going to go away, so don't rely on it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing list
iommu@lists.linux-foundation.org
https://l
From: Christoph Hellwig
Date: Thu, 8 Jun 2017 15:25:53 +0200
> Usually dma_supported decisions are done by the dma_map_ops instance.
> Switch sparc to that model by providing a ->dma_supported instance for
> sbus that always returns false, and implementations tailored to the sun4u
> and sun4v ca
From: Christoph Hellwig
Date: Thu, 8 Jun 2017 15:25:52 +0200
> We can just use pci32_dma_ops.
>
> Btw, given that leon is 32-bit and appears to be PCI based, do even need
> the special case for it in get_arch_dma_ops at all?
I would need to defer to the LEON developers on that, but they haven'
From: Christoph Hellwig
Date: Thu, 8 Jun 2017 15:25:27 +0200
> That way the driver doesn't have to rely on DMA_ERROR_CODE, which
> is not a public API and going away.
>
> Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
___
iommu mailing
From: Christoph Hellwig
Date: Thu, 8 Jun 2017 15:25:25 +0200
> for a while we have a generic implementation of the dma mapping routines
> that call into per-arch or per-device operations. But right now there
> still are various bits in the interfaces where don't clearly operate
> on these ops.
From: Yijing Wang
Date: Wed, 15 Oct 2014 11:07:13 +0800
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>
> Signed-off-by: Yijing Wang
Acked-by: David S. Miller
33 matches
Mail list logo
