2010/10/22 Alan Cox a...@lxorguk.ukuu.org.uk:
(...)
+static int mid_spi_dma_init(struct dw_spi *dws)
+{
+ struct mid_dma *dw_dma = dws-dma_priv;
+ struct intel_mid_dma_slave *rxs, *txs;
+ dma_cap_mask_t mask;
+
+ dws-txchan = NULL;
+ dws-rxchan = NULL;
+
+ /*get pci device for DMA*/
+ dws-dmac = pci_get_device(PCI_VENDOR_ID_INTEL, 0x813, NULL);
+
+ /* 1. Init rx channel */
+ rxs = dw_dma-dmas_rx;
+
+ rxs-dirn = DMA_FROM_DEVICE;
+ rxs-hs_mode = LNW_DMA_HW_HS;
+ rxs-cfg_mode = LNW_DMA_PER_TO_MEM;
+ rxs-src_width = LNW_DMA_WIDTH_16BIT;
+ rxs-dst_width = LNW_DMA_WIDTH_32BIT;
+ rxs-src_msize = LNW_DMA_MSIZE_16;
+ rxs-dst_msize = LNW_DMA_MSIZE_16;
Hm, hm hm. You go configure these channel characteristics
by derferencing and writing private data.
There *is* a generic runtime channel control interface as of
kernel 2.6.36. Compare to this snippet from the PL022 DMA
support that was merged into becoming 2.6.37 a day ago or so
(behold the beauty in drivers/spi/amba-pl022.c):
struct dma_slave_config rx_conf = {
.src_addr = SSP_DR(pl022-phybase),
.direction = DMA_FROM_DEVICE,
.src_maxburst = pl022-vendor-fifodepth 1,
};
(...)
struct dma_chan *rxchan = pl022-dma_rx_channel;
(...)
switch (pl022-read) {
case READING_NULL:
/* Use the same as for writing */
rx_conf.src_addr_width = DMA_SLAVE_BUSWIDTH_UNDEFINED;
break;
case READING_U8:
rx_conf.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
break;
case READING_U16:
rx_conf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
break;
case READING_U32:
rx_conf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
break;
}
rxchan-device-device_control(rxchan, DMA_SLAVE_CONFIG,
(unsigned long) rx_conf);
I don't know if I'm particularly biased by being infatuated by my own
interface, but can't you just implement the DMA_SLAVE_CONFIG
command for the DW DMA controller instead of this
custom stuff?
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_MEMCPY, mask);
+ dma_cap_set(DMA_SLAVE, mask);
What are you doing? Normally you want *either* a memcpy channel
(which wouldn't require the kind of setup you do above, hell memcpy
shan't be any different from the C library function memcpy()!) *or*
you want a slave channel.
Most probably you should drop dma_cap_set(DMA_MEMCPY, mask),
if it is needed your DMAengine driver is likely weird.
Then I think I get the answer later on:
+ dws-rxchan = dma_request_channel(mask, mid_spi_dma_chan_filter, dws);
Aha generic DMA engine, that's cool! :)
So then again, use the DMA-engine configuration mechanism, and
get the slave channel will ya?
(...)
+static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
(...)
+ /* 3. start the RX dma transfer */
+ if (dws-rx_dma) {
+ rxdesc = rxchan-device-device_prep_dma_memcpy(rxchan,
+ dws-rx_dma, dws-dma_addr,
+ dws-len, flag);
So you're still using the memcpy() prepare function in order to
be able to supply the endpoint address. Incidentally, that is an
additional argument that you can pass to the generic channel
control mechanism using .src_addr/.dst_addr respectively.
And the DW controller does *indeed* have a
device_prep_slave_sg hook.
My recommendation: put generic channel control into the
DMA driver you're using and inspect amba-pl022.c for an
idea on how to do this.
Since the .device_prep_slave_sg command only takes
SGlists you will have to wrap your buffers in SGlists but
I'm working on a simplifying wrapper for that.
Yours,
Linus Walleij
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
