* [PATCH 1/3] dma: add dma_flags_set/get_*() interfaces
@ 2007-10-17 1:41 akepner
2007-10-17 3:27 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: akepner @ 2007-10-17 1:41 UTC (permalink / raw)
To: akpm
Cc: Tony Luck, Grant Grundler, Jesse Barnes, Jes Sorensen,
Randy Dunlap, Roland Dreier, James Bottomley, David Miller,
linux-kernel
Introduce the dma_flags_set/get_*() interfaces and give them
default implementations.
Architectures which allow DMA to be reordered between a device and
host memory (within a NUMA interconnect) can redefine these to allow
a driver to explicitly synchronize DMA from the device when necessary.
Signed-off-by: Arthur Kepner <akepner@sgi.com>
---
Andrew, this is the first in a series of three patches:
[1/3] dma: add dma_flags_set/get_*() interfaces
[2/3] dma: redefine dma_flags_set/get_*() for sn-ia64
[3/3] dma: document dma_flags_set/get_*()
Variants of these patches have been discussed on several
occasions, most recently in a thread beginning:
http://marc.info/?l=linux-kernel&m=119137949604365&w=2
Please consider this for 2.6.24.
Jes, Tony, please note that I added an explicit test for
CONFIG_IA64_SGI_SN2 in asm-ia64/sn/io.h (Yuck). This is
needed for IA64_GENERIC to build, since there's at least one
driver (qla1280) that includes asm-ia64/sn/io.h for
CONFIG_IA64_GENERIC.
dma-mapping.h | 18 ++++++++++++++++++
1 files changed, 18 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0ebfafb..132b559 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -106,4 +106,22 @@ static inline void dmam_release_declared_memory(struct device *dev)
}
#endif /* ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY */
+#define DMA_BARRIER_ATTR 0x1
+#ifndef ARCH_USES_DMA_ATTRS
+static inline int dma_flags_set_attr(u32 attr, enum dma_data_direction dir)
+{
+ return dir;
+}
+
+static inline int dma_flags_get_dir(int flags)
+{
+ return flags;
+}
+
+static inline int dma_flags_get_attr(int flags)
+{
+ return 0;
+}
+#endif /* ARCH_USES_DMA_ATTRS */
+
#endif
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH 1/3] dma: add dma_flags_set/get_*() interfaces
2007-10-17 1:41 [PATCH 1/3] dma: add dma_flags_set/get_*() interfaces akepner
@ 2007-10-17 3:27 ` Andrew Morton
2007-10-17 16:03 ` akepner
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2007-10-17 3:27 UTC (permalink / raw)
To: akepner
Cc: Tony Luck, Grant Grundler, Jesse Barnes, Jes Sorensen,
Randy Dunlap, Roland Dreier, James Bottomley, David Miller,
linux-kernel
On Tue, 16 Oct 2007 18:41:28 -0700 akepner@sgi.com wrote:
> +#define DMA_BARRIER_ATTR 0x1
> +#ifndef ARCH_USES_DMA_ATTRS
> +static inline int dma_flags_set_attr(u32 attr, enum dma_data_direction dir)
> +{
> + return dir;
> +}
This function takes an `enum dma_data_direction' as its second arg, but your
ia64 implementation takes an 'int'.
> +static inline int dma_flags_get_dir(int flags)
> +{
> + return flags;
> +}
> +
> +static inline int dma_flags_get_attr(int flags)
> +{
> + return 0;
> +}
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH 1/3] dma: add dma_flags_set/get_*() interfaces
2007-10-17 3:27 ` Andrew Morton
@ 2007-10-17 16:03 ` akepner
2007-10-17 20:10 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: akepner @ 2007-10-17 16:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Tony Luck, Grant Grundler, Jesse Barnes, Jes Sorensen,
Randy Dunlap, Roland Dreier, James Bottomley, David Miller,
linux-kernel
[reply to the series of three mails below]
On Tue, Oct 16, 2007 at 08:27:28PM -0700, Andrew Morton wrote:
> On Tue, 16 Oct 2007 18:41:28 -0700 akepner@sgi.com wrote:
>
> > +#define DMA_BARRIER_ATTR 0x1
> > +#ifndef ARCH_USES_DMA_ATTRS
> > +static inline int dma_flags_set_attr(u32 attr, enum dma_data_direction dir)
> > +{
> > + return dir;
> > +}
>
> This function takes an `enum dma_data_direction' as its second arg, but your
> ia64 implementation takes an 'int'.
>
This is because the dma_data_direction enum type isn't available
at the point the ia64 implementation is defined.
> > .....
> > dma_addr_t sn_dma_map_single(struct device *dev, void *cpu_addr, size_t size,
> > - int direction)
> > + int flags)
> > {
> > dma_addr_t dma_addr;
> > unsigned long phys_addr;
> > struct pci_dev *pdev = to_pci_dev(dev);
> > struct sn_pcibus_provider *provider = SN_PCIDEV_BUSPROVIDER(pdev);
> > + int dmabarrier = dma_flags_get_attr(flags) & DMA_BARRIER_ATTR;
>
> So we take an `enum data_direction' and then wedge it into a word alongside
> some extra flags?
>
> Can we do something nicer than that?
Changing the type of the last argument to dma_map_* functions
to be a bitmask? Or adding an additional argument? (Both of
which you mention below.)
> > .....
> > +DMA_BARRIER_ATTR would be set when the memory region is mapped for DMA,
> > +e.g.:
> > +
> > + int count;
> > + int flags = dma_flags_set_attr(DMA_BARRIER_ATTR, DMA_BIDIRECTIONAL);
> > + ....
> > + count = dma_map_sg(dev, sglist, nents, flags);
> > +
>
> Isn't this rather a kludge?
I prefer the term "hack".
>
> What would be the cost of doing this cleanly and either redefining
> dma_data_direction to be a field-of-bits or just leave dma_data_direction
> alone (it is quite unrelated to this work, isn't it?) and adding new
> fields/arguments to manage this new functionality?
It'd be significantly more work to do change or add arguments
to the dma_map_* functions. But if that's what I need to do to
get this accepted, I'll back up and have another go at it.
--
Arthur
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH 1/3] dma: add dma_flags_set/get_*() interfaces
2007-10-17 16:03 ` akepner
@ 2007-10-17 20:10 ` Andrew Morton
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Morton @ 2007-10-17 20:10 UTC (permalink / raw)
To: akepner
Cc: tony.luck, grundler, jbarnes, jes, randy.dunlap, rdreier,
James.Bottomley, davem, linux-kernel
On Wed, 17 Oct 2007 09:03:27 -0700
akepner@sgi.com wrote:
> >
> > What would be the cost of doing this cleanly and either redefining
> > dma_data_direction to be a field-of-bits or just leave dma_data_direction
> > alone (it is quite unrelated to this work, isn't it?) and adding new
> > fields/arguments to manage this new functionality?
>
> It'd be significantly more work to do change or add arguments
> to the dma_map_* functions. But if that's what I need to do to
> get this accepted, I'll back up and have another go at it.
I don't have any particularly strong opinions on which would be the best
way to clean this up. Hopefully someone who is more involved with the DMA
mapping interfaces can help out.
It wouldn't be efficient for you to implement something new, only to have
it criticized again. I'd suggest that you come up with a concrete
design, describe to us what you propose to do and let's take it from there.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-10-17 20:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-17 1:41 [PATCH 1/3] dma: add dma_flags_set/get_*() interfaces akepner
2007-10-17 3:27 ` Andrew Morton
2007-10-17 16:03 ` akepner
2007-10-17 20:10 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox