dmaengine: Add support for BCM2835
Subsystems (4)
PATCH v5 1/1 dmaengine: Add support for BCM2835
Add support for DMA controller of BCM2835 as used in the Raspberry Pi. Currently it only supports cyclic DMA.
---
Fifth version with better error handling in probe.
.../devicetree/bindings/dma/bcm2835-dma.txt | 56 ++ drivers/dma/Kconfig | 6 + drivers/dma/Makefile | 1 + drivers/dma/bcm2835-dma.c | 749 +++++++++++++++++++++ 4 files changed, 812 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/bcm2835-dma.txt create mode 100644 drivers/dma/bcm2835-dma.c
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +56 -0
@@ -0,0 +1,56 @@ +* BCM2835 DMA controller + +Required properties: +- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order. + First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- brcm,dma-channel-mask: Bit mask representing the channels + not used by the firmware. + +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18 + 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>; + + #dma-cells = <1>; + brcm,dma-channel-mask = <0x7f35>; +}; + +DMA clients connected to the BCM2835 DMA controller must use the format +described in the dma.txt file, using a two-cell specifier for each channel: +a phandle plus one integer cells. +The two cells in order are: + +1. A phandle pointing to the DMA controller. +2. The DREQ number. + +Example: + +bcm2835_i2s: i2s@7e203000 { + compatible = "brcm,bcm2835-i2s"; + reg = < 0x7e203000 0x20 + 0x7e101098 0x02>; + + dmas = <&dma 2 + &dma 3>; + dma-names = "tx", "rx"; +};
drivers/dma/Kconfig +6 -0
@@ -300,6 +300,12 @@ config DMA_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS +config DMA_BCM2835 + tristate "BCM2835 DMA engine support" + depends on (ARCH_BCM2835 || MACH_BCM2708) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + config TI_CPPI41 tristate "AM33xx CPPI41 DMA support" depends on ARCH_OMAP
drivers/dma/Makefile +1 -0
@@ -38,6 +38,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o obj-$(CONFIG_DMA_OMAP) += omap-dma.o +obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o obj-$(CONFIG_TI_CPPI41) += cppi41.o
drivers/dma/bcm2835-dma.c new file +749 -0
749 lines not on this page · raw message
Signature · 7 lines
1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Florian Meier
Add support for DMA controller of BCM2835 as used in the Raspberry Pi. Currently it only supports cyclic DMA.
trivial style notes:
drivers/dma/bcm2835-dma.c
Quoted 1 line
drivers/dma/bcm2835-dma.c +0
-0
[]
drivers/dma/bcm2835-dma.c line 105
Quoted 8 lines
drivers/dma/bcm2835-dma.c +8
-0+/* DMA CS Control and Status bits */ +#define BCM2835_DMA_ACTIVE (1 << 0) +#define BCM2835_DMA_INT (1 << 2) +#define BCM2835_DMA_ISPAUSED (1 << 4)/* Pause requested or not active */ +#define BCM2835_DMA_ISHELD (1 << 5)/* Is held by DREQ flow control */ +#define BCM2835_DMA_ERR (1 << 8) +#define BCM2835_DMA_ABORT (1 << 30)/* stop current CB, go to next, WO */ +#define BCM2835_DMA_RESET (1 << 31)/* WO, self clearing */
These could use the BIT macro
drivers/dma/bcm2835-dma.c line 118
Quoted 4 lines
drivers/dma/bcm2835-dma.c +4
-0+#define BCM2835_DMA_DATA_TYPE_S8 1 +#define BCM2835_DMA_DATA_TYPE_S16 2 +#define BCM2835_DMA_DATA_TYPE_S32 4 +#define BCM2835_DMA_DATA_TYPE_S128 16
Are these sizeof(s8), sizeof(s16), sizeof(s32)?
Is there a S64's? Are there any s128's?
drivers/dma/bcm2835-dma.c line 153
Quoted 4 lines
drivers/dma/bcm2835-dma.c +4
-0+static int bcm2835_dma_abort (void __iomem *dma_chan_base) +{ +unsigned long int cs; +int rc =0 ;
Perhaps better without using an automatic for rc
and using direct returns.
drivers/dma/bcm2835-dma.c line 157
Quoted 4 lines
drivers/dma/bcm2835-dma.c +4
-0+ + cs =readl (dma_chan_base +BCM2835_DMA_CS ); + +if (BCM2835_DMA_ACTIVE & cs) {
if (!(cs & BCM2835_DMA_ACTIVE)) return 0;
and avoid the indent level and use consistent
(cs & bit) style through the routine instead
of mixing (bit & cs) and (cs & bit)
drivers/dma/bcm2835-dma.c line 158
Quoted 1 line
drivers/dma/bcm2835-dma.c +1
-0+long int timeout =10000 ;
Move timeout to start of routine.
drivers/dma/bcm2835-dma.c line 169
Quoted 10 lines
drivers/dma/bcm2835-dma.c +10
-0+/* write 0 to the active bit - pause the DMA */ +writel (0 , dma_chan_base +BCM2835_DMA_CS ); + +/* wait for any current AXI transfer to complete */ +while ((cs &BCM2835_DMA_ISPAUSED ) && --timeout >=0 ) + cs =readl (dma_chan_base +BCM2835_DMA_CS ); + +if (cs &BCM2835_DMA_ISPAUSED ) { +/* we'll un-pause when we set of our next DMA */ + rc = -ETIMEDOUT ;
return -ETIMEDOUT;
and avoid another indentation level.
drivers/dma/bcm2835-dma.c line 182
Quoted 13 lines
drivers/dma/bcm2835-dma.c +13
-0+ + }else if (BCM2835_DMA_ACTIVE & cs) { +/* terminate the control block chain */ +writel (0 , dma_chan_base +BCM2835_DMA_NEXTCB ); + +/* abort the whole DMA */ +writel (BCM2835_DMA_ABORT |BCM2835_DMA_ACTIVE , + dma_chan_base +BCM2835_DMA_CS ); + } + } + +return rc; +}
So perhaps this becomes:
static int bcm2835_dma_abort(void __iomem *dma_chan_base)
{
unsigned long int cs;
long timeout;
cs = readl(dma_chan_base + BCM2835_DMA_CS);
+ if (!(cs & BCM2835_DMA_ACTIVE))
return 0;
/* write 0 to the active bit - pause the DMA */
writel(0, dma_chan_base + BCM2835_DMA_CS);
/* wait for any current AXI transfer to complete */
timeout = 10000;
while ((cs & BCM2835_DMA_ISPAUSED) && --timeout >= 0)
cs = readl(dma_chan_base + BCM2835_DMA_CS);
/* we'll un-pause when we set of our next DMA */
if (cs & BCM2835_DMA_ISPAUSED)
return -ETIMEDOUT;
if (!(cs & BCM2835_DMA_ACTIVE))
return 0;
/* terminate the control block chain */
writel(0, dma_chan_base + BCM2835_DMA_NEXTCB);
/* abort the whole DMA */
writel(BCM2835_DMA_ABORT | BCM2835_DMA_ACTIVE,
dma_chan_base + BCM2835_DMA_CS);
return 0;
}[]
drivers/dma/bcm2835-dma.c line 260
Quoted 4 lines
drivers/dma/bcm2835-dma.c +4
-0+static size_t bcm2835_dma_desc_size_pos (struct bcm2835_desc *d,dma_addr_t addr) +{ +unsigned i; +size_t size;
Please set size to 0 here and not in the for loop
drivers/dma/bcm2835-dma.c line 262
Quoted 2 lines
drivers/dma/bcm2835-dma.c +2
-0+ +for (size = i =0 ; i < d->frames; i++) {
[]
Quoted 6 lines
drivers/dma/bcm2835-dma.c +5
-0+static struct dma_async_tx_descriptor *bcm2835_dma_prep_dma_cyclic ( +struct dma_chan *chan,dma_addr_t buf_addr,size_t buf_len, +size_t period_len,enum dma_transfer_direction direction, +unsigned long flags,void *context) +{
drivers/dma/bcm2835-dma.c line 387
Quoted 10 lines
drivers/dma/bcm2835-dma.c +10
-0+/* Allocate memory for control blocks */ + d->control_block_size = d->frames *sizeof (struct bcm2835_dma_cb ); + d->control_block_base =dma_alloc_coherent (chan->device->dev, + d->control_block_size, &d->control_block_base_phys, +GFP_NOWAIT ); + +if (!d->control_block_base) { +kfree (d); +dev_err (chan->device->dev, +"%s: Memory allocation error\n" , __func__);
Please use dma_zalloc_coherent and the OOM message isn't necessary as dma_alloc_coherent has a generic OOM message.
drivers/dma/bcm2835-dma.c line 391
Quoted 4 lines
drivers/dma/bcm2835-dma.c +4
-0+return NULL ; + } + +memset (d->control_block_base,0 , d->control_block_size);
unnecessary with dma_zalloc_coherent
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · Joe Perches
drivers/dma/bcm2835-dma.c line 260
Quoted 4 lines · Florian Meier
drivers/dma/bcm2835-dma.c new file +4
-0+static size_t bcm2835_dma_desc_size_pos (struct bcm2835_desc *d,dma_addr_t addr) +{ +unsigned i; +size_t size;Please set size to 0 here and not in the for loop
drivers/dma/bcm2835-dma.c line 262
Quoted 2 lines
drivers/dma/bcm2835-dma.c new file +2
-0+ +for (size = i =0 ; i < d->frames; i++) {
I disagree with that comment; I think the above is not only cleaner, but also more obvious that _this_ loop is calculating _this_ size.
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Joe Perches
drivers/dma/bcm2835-dma.c line 260
Quoted 4 lines · Florian Meier
drivers/dma/bcm2835-dma.c new file +4
-0+static size_t bcm2835_dma_desc_size_pos (struct bcm2835_desc *d,dma_addr_t addr) +{ +unsigned i; +size_t size;Please set size to 0 here and not in the for loop
Quoted 5 lines
Quoted 2 lines
drivers/dma/bcm2835-dma.c line 262
Quoted 2 lines
drivers/dma/bcm2835-dma.c new file +2
-0+ +for (size = i =0 ; i < d->frames; i++) {I disagree with that comment; I think the above is not only cleaner, but also more obvious that _this_ loop is calculating _this_ size.
I think that using
size_t size = 0;
is not only _much_ more commonly used throughout the kernel but makes it clearer that the initialization of the return value is done before the loop.
Reasonable minds can differ and there is no style guide that prefers one over the other.
No matter really to me.
As I said, it's trivial.
cheers, Joe
Quoted 2 lines · Florian Meier
Add support for DMA controller of BCM2835 as used in the Raspberry Pi. Currently it only supports cyclic DMA.
Few comments below.
drivers/dma/bcm2835-dma.c line 7
Quoted 9 lines
+++
b/drivers/dma/bcm2835-dma.cdrivers/dma/bcm2835-dma.c new file +7
-0@@ -0,0 +1,749 @@ +/* +* BCM2835 DMA engine support +* +* This driver only supports cyclic DMA transfers +* as needed for the I2S module. +* +* Author: Florian Meier, <[email protected]>
Comma there a bit inconvenient. It would be easier to copy'n'paste address w/o it.
Up to you.
drivers/dma/bcm2835-dma.c line 10
Quoted 3 lines
drivers/dma/bcm2835-dma.c new file +3
-0+* Copyright 2013 +* +* based on
Maybe 'Based on'?
[]
drivers/dma/bcm2835-dma.c line 73
Quoted 3 lines
drivers/dma/bcm2835-dma.c new file +2
-0+struct bcm2835_chan { +int dma_ch;
Do you really need this dma_ prefix?
drivers/dma/bcm2835-dma.c line 77
Quoted 2 lines
drivers/dma/bcm2835-dma.c new file +2
-0+void __iomem *dma_chan_base; +int dma_irq_number;
Ditto.
drivers/dma/bcm2835-dma.c line 105
Quoted 2 lines
drivers/dma/bcm2835-dma.c new file +2
-0+#define BCM2835_DMA_ABORT (1 << 30)/* stop current CB, go to next, WO */ +#define BCM2835_DMA_RESET (1 << 31)/* WO, self clearing */
You have different style of comments in the file: some of them starts from capital letter, some not. It would be better to have one style.
drivers/dma/bcm2835-dma.c line 118
Quoted 4 lines
drivers/dma/bcm2835-dma.c new file +4
-0+#define BCM2835_DMA_DATA_TYPE_S8 1 +#define BCM2835_DMA_DATA_TYPE_S16 2 +#define BCM2835_DMA_DATA_TYPE_S32 4 +#define BCM2835_DMA_DATA_TYPE_S128 16
Indentation?
Quoted 1 line
+#define
BCM2835_DMA_CHANIO(dma_base, n)((dma_base) +BCM2835_DMA_CHAN(n))
dma_base -> base ?
[]
drivers/dma/bcm2835-dma.c line 260
Quoted 4 lines
drivers/dma/bcm2835-dma.c new file +4
-0+static size_t bcm2835_dma_desc_size_pos (struct bcm2835_desc *d,dma_addr_t addr) +{ +unsigned i; +size_t size;
size = 0 here is better.
drivers/dma/bcm2835-dma.c line 271
Quoted 10 lines
drivers/dma/bcm2835-dma.c new file +10
-0+for (size = i =0 ; i < d->frames; i++) { +struct bcm2835_dma_cb *control_block = + &d->control_block_base[i]; +size_t this_size = control_block->length; +dma_addr_t dma; + +if (d->dir ==DMA_DEV_TO_MEM ) + dma = control_block->dst; +else + dma = control_block->src;
Do you think it must be dependent on the direction?
Do you have information of how many bytes transferred already in the DMA controller registers? Would it be better to use it?
drivers/dma/bcm2835-dma.c line 276
Quoted 4 lines
drivers/dma/bcm2835-dma.c new file +4
-0+if (size) + size += this_size; +else if (addr >= dma && addr < dma + this_size) + size += dma + this_size - addr;
+= -> =
[]
drivers/dma/bcm2835-dma.c line 312
Quoted 6 lines
drivers/dma/bcm2835-dma.c new file +5
-0+static enum dma_status bcm2835_dma_tx_status (struct dma_chan *chan, +dma_cookie_t cookie,struct dma_tx_state *txstate) +{ + } else { + txstate->residue =0 ;
Not needed since it's default by dmaengine.
drivers/dma/bcm2835-dma.c line 334
Quoted 6 lines
drivers/dma/bcm2835-dma.c new file +5
-0+static void bcm2835_dma_issue_pending (struct dma_chan *chan) +{ +} + +
Redundant empty line
drivers/dma/bcm2835-dma.c line 440
Quoted 6 lines
drivers/dma/bcm2835-dma.c new file +5
-0+static struct dma_async_tx_descriptor *bcm2835_dma_prep_dma_cyclic ( +/* The following fields are not used here */ + control_block->stride = 0; + control_block->pad[0 ] =0 ; + control_block->pad[1 ] =0 ;
You have already them zeroed by memset.
[]
drivers/dma/bcm2835-dma.c line 454
Quoted 6 lines
drivers/dma/bcm2835-dma.c new file +5
-0+static int bcm2835_dma_slave_config (struct bcm2835_chan *c, +struct dma_slave_config *cfg) +{ + (cfg->direction != DMA_DEV_TO_MEM && + cfg->direction != DMA_MEM_TO_DEV)) {
We have a helper for those two above.
[]
drivers/dma/bcm2835-dma.c line 534
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +5
-0+static int bcm2835_dma_chan_init (struct bcm2835_dmadev *d,int chan_id,int irq) +{ +struct bcm2835_chan *c; + + c =kzalloc (sizeof (*c),GFP_KERNEL );
Why this can't be devm_kzalloc?
[]
drivers/dma/bcm2835-dma.c line 625
Quoted 7 lines
drivers/dma/bcm2835-dma.c new file +6
-0+static int bcm2835_dma_probe (struct platform_device *pdev) +{ +struct resource *dma_res =NULL ; +void __iomem *dma_base =NULL ; +int rc =0 ; +int i =0 ;
Useless assignments.
[]
drivers/dma/bcm2835-dma.c line 635
Quoted 7 lines
drivers/dma/bcm2835-dma.c new file +7
-0+if (!pdev->dev.dma_mask) + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; + + rc =dma_set_mask (&pdev->dev,DMA_BIT_MASK (32 )); +if (rc) +return rc; +dma_set_coherent_mask (&pdev->dev,DMA_BIT_MASK (32 ));
There is nice helper you may use instead of those two above and remove 'if' condition as well.
[]
Quoted 1 line
+}
[]
Quoted 1 line
+module_platform_driver(bcm2835_dma_driver);
Is it possible to get driver initialized after that one that uses it?
Signature · 12 lines
Andy Shevchenko <[email protected]> Intel Finland Oy --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Quoted 7 lines · Andriy
drivers/dma/bcm2835-dma.c line 260
Quoted 4 lines · Florian Meier
drivers/dma/bcm2835-dma.c new file +4
-0+static size_t bcm2835_dma_desc_size_pos (struct bcm2835_desc *d,dma_addr_t addr) +{ +unsigned i; +size_t size;size = 0 here is better.
See my other comment to Joe.
Quoted 4 lines
Quoted 4 lines
drivers/dma/bcm2835-dma.c new file +4
-0+for (size = i =0 ; i < d->frames; i++) { +struct bcm2835_dma_cb *control_block = + &d->control_block_base[i]; +size_t this_size = control_block->length;
Quoted 8 lines
drivers/dma/bcm2835-dma.c line 271
Quoted 6 lines
drivers/dma/bcm2835-dma.c new file +6
-0+dma_addr_t dma; + +if (d->dir ==DMA_DEV_TO_MEM ) + dma = control_block->dst; +else + dma = control_block->src;Do you think it must be dependent on the direction?
Of course it does. Take a moment to think about it please.
Quoted 9 lines
Do you have information of how many bytes transferred already in the DMA controller registers? Would it be better to use it?
drivers/dma/bcm2835-dma.c line 276
Quoted 4 lines
drivers/dma/bcm2835-dma.c new file +4
-0+if (size) + size += this_size; +else if (addr >= dma && addr < dma + this_size) + size += dma + this_size - addr;+= -> =
No functional change, as 'size' has to be initialised anyway. The code is fine.
Quoted 10 lines
drivers/dma/bcm2835-dma.c line 635
Quoted 7 lines
drivers/dma/bcm2835-dma.c new file +7
-0+if (!pdev->dev.dma_mask) + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; + + rc =dma_set_mask (&pdev->dev,DMA_BIT_MASK (32 )); +if (rc) +return rc; +dma_set_coherent_mask (&pdev->dev,DMA_BIT_MASK (32 ));There is nice helper you may use instead of those two above and remove 'if' condition as well.
There is _now_ but at the time this is being developed, it wasn't there. Such a change is probably only appropriate at least after -rc1 has happened. Since I'm the one who introduced that helper, and I haven't said to use it yet in this driver, that suggests I've already thought about this point...
Quoted 3 lines
Quoted 1 line
+module_platform_driver(bcm2835_dma_driver);
Is it possible to get driver initialized after that one that uses it?
Doesn't quite make sense. If you're asking whether other drivers can try to make use of this driver before it's initialised, then the answer is no. We have mechanisms to cope with that - see deferred probing.
A message that is not in the archive (sent off-list or not yet received): CAHp75Vf3CJNgSiSjoZ6dYjRRHWN4bTpMxRTLG37+wwtEsQbq4g@mail.gmail.com
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Andriy
Quoted 4 lines
Quoted 2 lines
+module_platform_driver(bcm2835_dma_driver);
Is it possible to get driver initialized after that one that uses it?
Doesn't quite make sense. If you're asking whether other drivers can try to make use of this driver before it's initialised, then the answer is no. We have mechanisms to cope with that - see deferred probing.
The reason why I was asking about I'm just wondering what we have to do with existing drivers. Shall we convert them to be initialized as normal platform drivers instead of subsys_initcall?
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 3 lines · Andy Shevchenko
The reason why I was asking about I'm just wondering what we have to do with existing drivers. Shall we convert them to be initialized as normal platform drivers instead of
subsys_initcall?
We should in general be moving in that direction however it does need a
bit of care to make sure that there aren't any dependencies which do
things like discard error codes, fail to check errors or treat errors as
hard failures.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131116/b35b6ef1/attachment.sig>
Quoted 10 lines · Mark Brown
Quoted 3 lines · Andy Shevchenko
The reason why I was asking about I'm just wondering what we have to do with existing drivers. Shall we convert them to be initialized as normal platform drivers instead of
subsys_initcall?We should in general be moving in that direction however it does need a bit of care to make sure that there aren't any dependencies which do things like discard error codes, fail to check errors or treat errors as hard failures.
I don't agree: on platforms which have done this, it's very difficult to tell from reading the kernel message log whether things came up correctly because there's soo much spew from deferred probing it's virtually impossible to tell whether component X initialised or whether that error about resource Y missing was ever resolved.
The only way that can be checked is when things work (or don't) from userspace.
It's soo bad on some platforms that reading the kernel boot log is a total waste of time; you don't get any useful information from it.
If we want kernel boot logs to be useful, we really need to shut up *all* the drivers and subsystems whinging about being deferred probing, and only have the driver model core reporting this status - maybe only allow output about why at debug level or similar.
Quoted 7 lines · Russell King - ARM Linux
Quoted 4 lines · Mark Brown
We should in general be moving in that direction however it does need a bit of care to make sure that there aren't any dependencies which do things like discard error codes, fail to check errors or treat errors as hard failures.
Quoted 5 lines
I don't agree: on platforms which have done this, it's very difficult to tell from reading the kernel message log whether things came up correctly because there's soo much spew from deferred probing it's virtually impossible to tell whether component X initialised or whether that error about resource Y missing was ever resolved.
I do agree that deferred programming is far too chatty - there's a usability issue there. This bites me a lot on some of my systems too, I tend to read my logs with grep a lot which isn't awesome.
Quoted 4 lines
If we want kernel boot logs to be useful, we really need to shut up *all* the drivers and subsystems whinging about being deferred probing, and only have the driver model core reporting this status - maybe only allow output about why at debug level or similar.
Yes, some sort of standardisation of how this stuff gets reported would
give us much better control of these things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131116/77ea498d/attachment.sig>
Group:
This is a request to augment with comments the DREQ explanation in the Broadcom BCM2835
pdf on page 61 regarding DMA peripheral
mapping. Specifically, how to identify a pin on the 26 pin
header to use for DMA reads. More specifically, if a clock signal,
like GPCLK0 is output to the peripheral device (like an A/D converter) how we specify PERMAP in the DMA TI register. Your users would be infinitely grateful.
thank you,