On Sun, Jan 20, 2013 at 11:37:35AM -0500, Matt Porter wrote: > On Sun, Jan 20, 2013 at 12:37:34PM +0000, Vinod Koul wrote: > > On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote: > > > The call is implemented as follows: > > > > > > struct dmaengine_chan_caps > > > *dma_get_channel_caps(struct dma_chan *chan, > > > enum dma_transfer_direction dir); > > > > > > The dma transfer direction parameter may appear a bit out of place > > > but it is necessary since the direction field in struct > > > dma_slave_config was deprecated. In some cases, EDMA for one, it > > > is necessary for the dmaengine driver to have the burst and address > > > width slave configuration parameters available in order to compute > > > the maximum segment size that can be handle. Due to this requirement, > > > the calling order of this api is as follows: > > Well you are passing direction as argument so even in EDMA it doesn't seem to > > help you as you seem to need burst and width!. So why do you even need the > > direction to compute the capablities > > Yes, I need burst and width, but they are dependent on direction (dst vs > src, as stored in the slave channel config). Ok, so I think I know where > this is leading...the problem is probably that I made an implicit > dependency on burst and width here. The expectation in this And also due to wrong documentation. This is what you have put up the flow as: Due to this requirement, the calling order of this api is as follows: 1. Allocate a DMA slave channel 1a. [Optionally] Get channel capabilities 2. Set slave and controller specific parameters 3. Get a descriptor for transaction 4. Submit the transaction 5. Issue pending requests and wait for callback notification Now when we query capablities, slave parameters _are_not_set_. So seems like you have thought something and written something else! Which brings me to the point on what are we trying to query: a) API capability, dont need slave parameters for that b) Sg segment length and numbers: Well these are capabilities, so it tells you what is the maximum I can do. IMO it doesn't make sense to tie it down to burst, width etc. For that configuration you are checking maximum. What this needs to return is what is the maximum length it supports and maximum number of sg list the h/w can use. Also if you return your burst and width capablity, then any client can easily find out what is the length byte value it can hold. If you feel this computaion if client specific, though looking at doesnt make me think so, you can add a callback for this computaion given the parameters. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
