Re: provide more common DMA API functions V2
On Wed, 19 Aug 2015 10:08:14 +0200 Christoph Hellwig h...@lst.de wrote: On Tue, Aug 18, 2015 at 09:51:07AM +0200, Ingo Molnar wrote: I.e. shouldn't this be: I'll merge these 5 patches for 4.4. That means I'll release them into linux-next after 4.2 is released. [...] Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.3 material. Once 4.2 is released and the 4.3 merge window opens, linux-next is open for 4.4 material. ? That would make a lot more sense. But also be said as I intended these as the simple part of the dma work I'd like to get into 4.3. Andrew, if you think it's not 4.3 material I'd rather keep them in my git tree for now so that I can stack additional patches I have in progress on top. A non-git based tree like yours is unfortunately very bad for patches that are dependencies for others. I think these will be OK for 4.3. It's all quiet so far and any problems will probably show up at compile time so they'll get fixed promptly. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
Hi Andrew (sorry, I can't tell who made the incorrect statement below that I am replying to), On Wed, 19 Aug 2015 14:36:56 -0700 Andrew Morton a...@linux-foundation.org wrote: On Wed, 19 Aug 2015 10:08:14 +0200 Christoph Hellwig h...@lst.de wrote: On Tue, Aug 18, 2015 at 09:51:07AM +0200, Ingo Molnar wrote: I.e. shouldn't this be: I'll merge these 5 patches for 4.4. That means I'll release them into linux-next after 4.2 is released. [...] Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.3 material. Once 4.2 is released and the 4.3 merge window opens, linux-next is open for 4.4 material. Just to be clear: the above should read Once 4.2 is released and the 4.3 merge window *closes* (i.e. v4.3-rc1 is released), linux-next is open for 4.4 material. -- Cheers, Stephen Rothwells...@canb.auug.org.au ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
On Thu, 2015-08-20 at 09:52 +1000, Stephen Rothwell wrote: Hi Andrew (sorry, I can't tell who made the incorrect statement below that I am replying to), On Wed, 19 Aug 2015 14:36:56 -0700 Andrew Morton a...@linux-foundation.org wrote: On Wed, 19 Aug 2015 10:08:14 +0200 Christoph Hellwig h...@lst.de wrote: On Tue, Aug 18, 2015 at 09:51:07AM +0200, Ingo Molnar wrote: I.e. shouldn't this be: I'll merge these 5 patches for 4.4. That means I'll release them into linux-next after 4.2 is released. [...] Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.3 material. Once 4.2 is released and the 4.3 merge window opens, linux-next is open for 4.4 material. Just to be clear: the above should read Once 4.2 is released and the 4.3 merge window *closes* (i.e. v4.3-rc1 is released), linux-next is open for 4.4 material. /me registers www.whatdamnkernelversionareweuptoagain.com cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
On Tue, Aug 18, 2015 at 09:51:07AM +0200, Ingo Molnar wrote: I.e. shouldn't this be: I'll merge these 5 patches for 4.4. That means I'll release them into linux-next after 4.2 is released. [...] Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.3 material. Once 4.2 is released and the 4.3 merge window opens, linux-next is open for 4.4 material. ? That would make a lot more sense. But also be said as I intended these as the simple part of the dma work I'd like to get into 4.3. Andrew, if you think it's not 4.3 material I'd rather keep them in my git tree for now so that I can stack additional patches I have in progress on top. A non-git based tree like yours is unfortunately very bad for patches that are dependencies for others. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
Hi Andrew, On Tue, 18 Aug 2015 07:53:15 +0200 Christoph Hellwig h...@lst.de wrote: On Mon, Aug 17, 2015 at 10:45:52PM -0700, Andrew Morton wrote: I'll merge these 5 patches for 4.3. That means I'll release them into linux-next after 4.2 is released. So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the wrong way around? Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.2 material. Once 4.2 is released, linux-next is open for 4.3 material. Hmm, I'm pretty sure there's tons of 4.3 material in linux-next at the moment, at least I got merge warning messages from Stephen about some yesterday. Yeah, we are at v4.2-rc7 so linux-next is full of stuff to be merged by Linus for v4.3. Nothing for v4.4 should be in linux-next until after v4.3-rc1 is released in 3-4 weeks i.e. after the next merge window closes. -- Cheers, Stephen Rothwells...@canb.auug.org.au ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
* Andrew Morton a...@linux-foundation.org wrote: On Tue, 18 Aug 2015 07:38:25 +0200 Christoph Hellwig h...@lst.de wrote: On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote: 110254 bytes saved, shrinking the kernel by a whopping 0.17%. Thoughts? Sounds fine to me. OK, I'll clean it up a bit, check that each uninlining actually makes sense and then I'll see how it goes. I'll merge these 5 patches for 4.3. That means I'll release them into linux-next after 4.2 is released. So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the wrong way around? Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.2 material. Once 4.2 is released, linux-next is open for 4.3 material. Isn't that off by one? I.e. shouldn't this be: I'll merge these 5 patches for 4.4. That means I'll release them into linux-next after 4.2 is released. [...] Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.3 material. Once 4.2 is released and the 4.3 merge window opens, linux-next is open for 4.4 material. ? Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
On Mon, Aug 17, 2015 at 10:45:52PM -0700, Andrew Morton wrote: I'll merge these 5 patches for 4.3. That means I'll release them into linux-next after 4.2 is released. So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the wrong way around? Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.2 material. Once 4.2 is released, linux-next is open for 4.3 material. Hmm, I'm pretty sure there's tons of 4.3 material in linux-next at the moment, at least I got merge warning messages from Stephen about some yesterday. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote: 110254 bytes saved, shrinking the kernel by a whopping 0.17%. Thoughts? Sounds fine to me. I'll merge these 5 patches for 4.3. That means I'll release them into linux-next after 4.2 is released. So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the wrong way around? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
On Tue, 18 Aug 2015 07:38:25 +0200 Christoph Hellwig h...@lst.de wrote: On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote: 110254 bytes saved, shrinking the kernel by a whopping 0.17%. Thoughts? Sounds fine to me. OK, I'll clean it up a bit, check that each uninlining actually makes sense and then I'll see how it goes. I'll merge these 5 patches for 4.3. That means I'll release them into linux-next after 4.2 is released. So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the wrong way around? Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.2 material. Once 4.2 is released, linux-next is open for 4.3 material. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: provide more common DMA API functions V2
On Mon, 17 Aug 2015 09:06:51 +0200 Christoph Hellwig h...@lst.de wrote:
Since 2009 we have a nice asm-generic header implementing lots of DMA API
functions for architectures using struct dma_map_ops, but unfortunately
it's still missing a lot of APIs that all architectures still have to
duplicate.
This series consolidates the remaining functions, although we still
need arch opt outs for two of them as a few architectures have very
non-standard implementations.
Looks nice.
This sets us up for a mass deinlining. I took a quick shot at that and
for x86-64 defconfig I'm seeing
textdata bss dechex filename
62851694 7016109 4483008 7435081146e80db (TOTALS)
62741440 7016109 4483008 7424055746cd22d (TOTALS)
110254 bytes saved, shrinking the kernel by a whopping 0.17%.
Thoughts?
I'll merge these 5 patches for 4.3. That means I'll release them into
linux-next after 4.2 is released.
--- a/include/asm-generic/dma-mapping-common.h~a
+++ a/include/asm-generic/dma-mapping-common.h
@@ -8,174 +8,53 @@
#include linux/dma-attrs.h
#include asm-generic/dma-coherent.h
-static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
+dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
size_t size,
enum dma_data_direction dir,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
- dma_addr_t addr;
-
- kmemcheck_mark_initialized(ptr, size);
- BUG_ON(!valid_dma_direction(dir));
- addr = ops-map_page(dev, virt_to_page(ptr),
-(unsigned long)ptr ~PAGE_MASK, size,
-dir, attrs);
- debug_dma_map_page(dev, virt_to_page(ptr),
- (unsigned long)ptr ~PAGE_MASK, size,
- dir, addr, true);
- return addr;
-}
-
-static inline void dma_unmap_single_attrs(struct device *dev, dma_addr_t addr,
+ struct dma_attrs *attrs);
+void dma_unmap_single_attrs(struct device *dev, dma_addr_t addr,
size_t size,
enum dma_data_direction dir,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
-
- BUG_ON(!valid_dma_direction(dir));
- if (ops-unmap_page)
- ops-unmap_page(dev, addr, size, dir, attrs);
- debug_dma_unmap_page(dev, addr, size, dir, true);
-}
-
+ struct dma_attrs *attrs);
/*
* dma_maps_sg_attrs returns 0 on error and 0 on success.
* It should never return a value 0.
*/
-static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
+int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
- int i, ents;
- struct scatterlist *s;
-
- for_each_sg(sg, s, nents, i)
- kmemcheck_mark_initialized(sg_virt(s), s-length);
- BUG_ON(!valid_dma_direction(dir));
- ents = ops-map_sg(dev, sg, nents, dir, attrs);
- BUG_ON(ents 0);
- debug_dma_map_sg(dev, sg, nents, ents, dir);
-
- return ents;
-}
-
-static inline void dma_unmap_sg_attrs(struct device *dev, struct scatterlist
*sg,
+ struct dma_attrs *attrs);
+void dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction dir,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
-
- BUG_ON(!valid_dma_direction(dir));
- debug_dma_unmap_sg(dev, sg, nents, dir);
- if (ops-unmap_sg)
- ops-unmap_sg(dev, sg, nents, dir, attrs);
-}
-
-static inline dma_addr_t dma_map_page(struct device *dev, struct page *page,
+ struct dma_attrs *attrs);
+dma_addr_t dma_map_page(struct device *dev, struct page *page,
size_t offset, size_t size,
- enum dma_data_direction dir)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
- dma_addr_t addr;
-
- kmemcheck_mark_initialized(page_address(page) + offset, size);
- BUG_ON(!valid_dma_direction(dir));
- addr = ops-map_page(dev, page, offset, size, dir, NULL);
- debug_dma_map_page(dev, page, offset, size, dir, addr, false);
-
- return addr;
-}
-
-static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
- size_t size, enum dma_data_direction dir)
-{
-
provide more common DMA API functions V2
Since 2009 we have a nice asm-generic header implementing lots of DMA API functions for architectures using struct dma_map_ops, but unfortunately it's still missing a lot of APIs that all architectures still have to duplicate. This series consolidates the remaining functions, although we still need arch opt outs for two of them as a few architectures have very non-standard implementations. Changes since V1: - keep a modified comment about dma_alloc_noncoherent vs dma_cache_sync in the ARM asm/dma-mapping.h - keep the ARM dma_set_mask instances to deal with dmabounce ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
