| Message ID | 20180402142656.26815-3-robert.jarzmik@free.fr (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > + > +static const struct dma_slave_map pxa_slave_map[] = { > + /* PXA25x, PXA27x and PXA3xx common entries */ > + { "pxa-pcm-audio", "ac97_mic_mono", PDMA_FILTER_PARAM(LOWEST, 8) }, > + { "pxa-pcm-audio", "ac97_aux_mono_in", PDMA_FILTER_PARAM(LOWEST, 9) }, > + { "pxa-pcm-audio", "ac97_aux_mono_out", PDMA_FILTER_PARAM(LOWEST, 10) }, > + { "pxa-pcm-audio", "ac97_stereo_in", PDMA_FILTER_PARAM(LOWEST, 11) }, > + { "pxa-pcm-audio", "ac97_stereo_out", PDMA_FILTER_PARAM(LOWEST, 12) }, > + { "pxa-pcm-audio", "ssp1_rx", PDMA_FILTER_PARAM(LOWEST, 13) }, > + { "pxa-pcm-audio", "ssp1_tx", PDMA_FILTER_PARAM(LOWEST, 14) }, > + { "pxa-pcm-audio", "ssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, > + { "pxa-pcm-audio", "ssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, > + { "pxa2xx-ir", "rx", PDMA_FILTER_PARAM(LOWEST, 17) }, > + { "pxa2xx-ir", "tx", PDMA_FILTER_PARAM(LOWEST, 18) }, > + { "pxa2xx-mci.0", "rx", PDMA_FILTER_PARAM(LOWEST, 21) }, > + { "pxa2xx-mci.0", "tx", PDMA_FILTER_PARAM(LOWEST, 22) }, > + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, > + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, > + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, This one is interesting, as you are dealing with an off-chip device, and the channel number is '-'1. How does this even work? Does it mean > + /* PXA25x specific map */ > + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, > + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, > + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, > + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, > + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, > + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, > + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, > + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, > + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, > + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, > + > + /* PXA27x specific map */ > + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, > + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, > + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, > + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, > + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, > + > + /* PXA3xx specific map */ > + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, > + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, > + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, > + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, > + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, > + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, > + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, > +}; Since more than half the entries in here are chip specific, maybe it would be better to split that table into three and have a copy for each one in arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? Does that mean it's actually a memory-to-memory transfer with a device being on the external SRAM interface? Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an off-chip device, > and the channel number is '-'1. How does this even work? Does it > mean This relies on pxa_dma, in which the "-1" for a requestor line means "no requestor" or said in another way "always requesting". As a consequence, as soon as the DMA descriptors are queued, the transfer begins, and it is supposed implicitely that the FIFO output availability is at least as quick as the system bus and the DMA size is perfectly fit for the FIFO available bytes. This is what has been the underlying of DMA transfers of smc91x(x) on the PXA platforms, where the smc91x(s) are directly wired on the system bus (the same bus having DRAM, SRAM, IO-mapped devices). > >> + /* PXA25x specific map */ >> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, >> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, >> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >> + >> + /* PXA27x specific map */ >> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, >> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, >> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, >> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, >> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, >> + >> + /* PXA3xx specific map */ >> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, >> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, >> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, >> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, >> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, >> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, >> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, >> +}; > > Since more than half the entries in here are chip specific, maybe it would be > better to split that table into three and have a copy for each one in > arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? Mmmh, today the split is : - 16 common entries - 10 pxa25x specific entries - 5 pxa27x specific entries - 7 pxa3xx specific entries => total of 38 lines After the split we'll have : - 26 pxa25x specific entries - 21 pxa27x specific entries - 23 pxa3xx specific entries => total of 70 lines That doubles the number of lines, not counting the declarations, and amending of pxa2xx_set_dmac_info(). If you think it's worth it, what is the driving benefit behind ? > Does that mean it's actually a memory-to-memory transfer with a device being > on the external SRAM interface? I'm taking this is the follow up to the "-1" question :0 Cheers.
On Tue, Apr 3, 2018 at 5:18 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > Arnd Bergmann <arnd@arndb.de> writes: > >>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >>> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, >> >> This one is interesting, as you are dealing with an off-chip device, >> and the channel number is '-'1. How does this even work? Does it >> mean > > This relies on pxa_dma, in which the "-1" for a requestor line means "no > requestor" or said in another way "always requesting". As a consequence, as soon > as the DMA descriptors are queued, the transfer begins, and it is supposed > implicitely that the FIFO output availability is at least as quick as the system > bus and the DMA size is perfectly fit for the FIFO available bytes. > > This is what has been the underlying of DMA transfers of smc91x(x) on the PXA > platforms, where the smc91x(s) are directly wired on the system bus (the same > bus having DRAM, SRAM, IO-mapped devices). Ok, I looked at the driver in more detail now and found the scary parts. So it's using the async DMA interface to do synchronous DMA in interrupt context in order to transfer the rx data faster than an readsl() would, correct? It still feels odd to me that there is an entry in the slave map for a device that does not have a request line. However, it also seems that the entire code in those two drivers that deals with DMA is specific to PXA anyway, so maybe it can be done differently: instead of calling dma_request_slave_channel_compat() or dma_request_chan() with a fake request line, how about calling dma_request_channel() with an NULL filter function and data, and have the driver handle the empty data case the same way as the rq=-1 case today? >>> + /* PXA25x specific map */ >>> + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, >>> + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, >>> + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >>> + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >>> + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >>> + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >>> + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, >>> + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, >>> + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, >>> + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, >>> + >>> + /* PXA27x specific map */ >>> + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, >>> + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, >>> + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, >>> + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, >>> + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, >>> + >>> + /* PXA3xx specific map */ >>> + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, >>> + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, >>> + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, >>> + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, >>> + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, >>> + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, >>> + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, >>> +}; >> >> Since more than half the entries in here are chip specific, maybe it would be >> better to split that table into three and have a copy for each one in >> arch/arm/mach-pxa/pxa{25x.27x.3xx}.c? > Mmmh, today the split is : > - 16 common entries > - 10 pxa25x specific entries > - 5 pxa27x specific entries > - 7 pxa3xx specific entries > => total of 38 lines > > After the split we'll have : > - 26 pxa25x specific entries > - 21 pxa27x specific entries > - 23 pxa3xx specific entries > => total of 70 lines > > That doubles the number of lines, not counting the declarations, and amending of > pxa2xx_set_dmac_info(). > > If you think it's worth it, what is the driving benefit behind ? It seems a bit cleaner to only register the tables for the dma lines that are actually present on a given chip. >> Does that mean it's actually a memory-to-memory transfer with a device being >> on the external SRAM interface? > I'm taking this is the follow up to the "-1" question :0 Right. Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
... chop chop removing unneeded recipients .... Arnd Bergmann <arnd@arndb.de> writes: > Ok, I looked at the driver in more detail now and found the scary parts. > So it's using the async DMA interface to do synchronous DMA in > interrupt context in order to transfer the rx data faster than an readsl() > would, correct? That's correct, at least for the smc91x. > It still feels odd to me that there is an entry in the slave map for > a device that does not have a request line. However, it also seems > that the entire code in those two drivers that deals with DMA is specific > to PXA anyway, so maybe it can be done differently: instead of > calling dma_request_slave_channel_compat() or dma_request_chan() > with a fake request line, how about calling dma_request_channel() > with an NULL filter function and data, and have the driver handle > the empty data case the same way as the rq=-1 case today? Okay, in this case : - the channel priority cannot be passed anymore - and I don't see how this can work : dma_request_channel() __dma_request_channel() find_candidate() private_candidate(mask, device, fn, fn_param); /* Here, fn == NULL and fn_param == NULL as per your proposal */ This function will find the first available dma channel, all right, but no function will be called in pxa_dma driver, and therefore the last requestor of the channel will be used, which is bad. >> If you think it's worth it, what is the driving benefit behind ? > It seems a bit cleaner to only register the tables for the dma lines that > are actually present on a given chip. Okay, let's do this. Cheers.
On Tue, Apr 3, 2018 at 10:19 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > ... chop chop removing unneeded recipients .... > > Arnd Bergmann <arnd@arndb.de> writes: > >> Ok, I looked at the driver in more detail now and found the scary parts. >> So it's using the async DMA interface to do synchronous DMA in >> interrupt context in order to transfer the rx data faster than an readsl() >> would, correct? > That's correct, at least for the smc91x. > >> It still feels odd to me that there is an entry in the slave map for >> a device that does not have a request line. However, it also seems >> that the entire code in those two drivers that deals with DMA is specific >> to PXA anyway, so maybe it can be done differently: instead of >> calling dma_request_slave_channel_compat() or dma_request_chan() >> with a fake request line, how about calling dma_request_channel() >> with an NULL filter function and data, and have the driver handle >> the empty data case the same way as the rq=-1 case today? > Okay, in this case : > - the channel priority cannot be passed anymore Right, but it could just always use a static priority, right? > - and I don't see how this can work : > dma_request_channel() > __dma_request_channel() > find_candidate() > private_candidate(mask, device, fn, fn_param); > /* Here, fn == NULL and fn_param == NULL as per your proposal */ > > This function will find the first available dma channel, all right, but > no function will be called in pxa_dma driver, and therefore the last > requestor of the channel will be used, which is bad. Can't you just reset those in pxad_free_chan_resources()? Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> writes: > On Tue, Apr 3, 2018 at 10:19 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: >> ... chop chop removing unneeded recipients .... >> >> Arnd Bergmann <arnd@arndb.de> writes: >>> It still feels odd to me that there is an entry in the slave map for >>> a device that does not have a request line. However, it also seems >>> that the entire code in those two drivers that deals with DMA is specific >>> to PXA anyway, so maybe it can be done differently: instead of >>> calling dma_request_slave_channel_compat() or dma_request_chan() >>> with a fake request line, how about calling dma_request_channel() >>> with an NULL filter function and data, and have the driver handle >>> the empty data case the same way as the rq=-1 case today? >> Okay, in this case : >> - the channel priority cannot be passed anymore > > Right, but it could just always use a static priority, right? Yes, an implicit default priority. I'm not a big fan of implicit parameters, yet I can do it. >> - and I don't see how this can work : >> dma_request_channel() >> __dma_request_channel() >> find_candidate() >> private_candidate(mask, device, fn, fn_param); >> /* Here, fn == NULL and fn_param == NULL as per your proposal */ >> >> This function will find the first available dma channel, all right, but >> no function will be called in pxa_dma driver, and therefore the last >> requestor of the channel will be used, which is bad. > > Can't you just reset those in pxad_free_chan_resources()? I can, let's see what happens next ... Cheers.
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c index d7c9a8476d57..da67ebe9a7d5 100644 --- a/arch/arm/mach-pxa/devices.c +++ b/arch/arm/mach-pxa/devices.c @@ -4,6 +4,8 @@ #include <linux/init.h> #include <linux/platform_device.h> #include <linux/dma-mapping.h> +#include <linux/dma/pxa-dma.h> +#include <linux/dmaengine.h> #include <linux/spi/pxa2xx_spi.h> #include <linux/platform_data/i2c-pxa.h> @@ -1202,9 +1204,62 @@ void __init pxa2xx_set_spi_info(unsigned id, struct pxa2xx_spi_master *info) platform_device_add(pd); } +#define PDMA_FILTER_PARAM(_prio, _requestor) (&(struct pxad_param) { \ + .prio = PXAD_PRIO_##_prio, .drcmr = _requestor }) + +static const struct dma_slave_map pxa_slave_map[] = { + /* PXA25x, PXA27x and PXA3xx common entries */ + { "pxa-pcm-audio", "ac97_mic_mono", PDMA_FILTER_PARAM(LOWEST, 8) }, + { "pxa-pcm-audio", "ac97_aux_mono_in", PDMA_FILTER_PARAM(LOWEST, 9) }, + { "pxa-pcm-audio", "ac97_aux_mono_out", PDMA_FILTER_PARAM(LOWEST, 10) }, + { "pxa-pcm-audio", "ac97_stereo_in", PDMA_FILTER_PARAM(LOWEST, 11) }, + { "pxa-pcm-audio", "ac97_stereo_out", PDMA_FILTER_PARAM(LOWEST, 12) }, + { "pxa-pcm-audio", "ssp1_rx", PDMA_FILTER_PARAM(LOWEST, 13) }, + { "pxa-pcm-audio", "ssp1_tx", PDMA_FILTER_PARAM(LOWEST, 14) }, + { "pxa-pcm-audio", "ssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, + { "pxa-pcm-audio", "ssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, + { "pxa2xx-ir", "rx", PDMA_FILTER_PARAM(LOWEST, 17) }, + { "pxa2xx-ir", "tx", PDMA_FILTER_PARAM(LOWEST, 18) }, + { "pxa2xx-mci.0", "rx", PDMA_FILTER_PARAM(LOWEST, 21) }, + { "pxa2xx-mci.0", "tx", PDMA_FILTER_PARAM(LOWEST, 22) }, + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, + + /* PXA25x specific map */ + { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) }, + { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) }, + { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) }, + { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) }, + { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) }, + { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) }, + { "pxa-pcm-audio", "nssp2_rx", PDMA_FILTER_PARAM(LOWEST, 15) }, + { "pxa-pcm-audio", "nssp2_tx", PDMA_FILTER_PARAM(LOWEST, 16) }, + { "pxa-pcm-audio", "nssp3_rx", PDMA_FILTER_PARAM(LOWEST, 23) }, + { "pxa-pcm-audio", "nssp3_tx", PDMA_FILTER_PARAM(LOWEST, 24) }, + + /* PXA27x specific map */ + { "pxa-pcm-audio", "ssp3_rx", PDMA_FILTER_PARAM(LOWEST, 66) }, + { "pxa-pcm-audio", "ssp3_tx", PDMA_FILTER_PARAM(LOWEST, 67) }, + { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) }, + { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) }, + { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) }, + + /* PXA3xx specific map */ + { "pxa-pcm-audio", "ssp4_rx", PDMA_FILTER_PARAM(LOWEST, 2) }, + { "pxa-pcm-audio", "ssp4_tx", PDMA_FILTER_PARAM(LOWEST, 3) }, + { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) }, + { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) }, + { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) }, + { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) }, + { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) }, +}; + static struct mmp_dma_platdata pxa_dma_pdata = { .dma_channels = 0, .nb_requestors = 0, + .slave_map = pxa_slave_map, + .slave_map_cnt = ARRAY_SIZE(pxa_slave_map), }; static struct resource pxa_dma_resource[] = {
In order to remove the specific knowledge of the dma mapping from PXA drivers, add a default slave map for pxa architectures. This is the first step, and once all drivers are converted, pxad_filter_fn() will be made static, and the DMA resources removed from device.c. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Reported-by: Arnd Bergmann <arnd@arndb.de> --- arch/arm/mach-pxa/devices.c | 55 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+)