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 implementation is that dmaengine_slave_config() has already been called and as a result, the dmaengine driver has either src_* or dst_* attributes populated depending on the direction of the channel. Given that, the call to dma_get_channel_caps() needs to provide the direction in order for the driver to know which of src_*/dst_* attributes are valid in order to do the max segment size calculation. An alternative, since the slave driver is the one that provided the info in the first place is: struct dmaengine_chan_caps *dma_get_channel_caps(struct dma_chan *chan, enum dma_slave_buswidth addr_width, u32 maxburst); where the attributes required by the edma driver to find the max segment size are now explicitly provided. This approach also removes the ordering requirement of calling dmaengine_slave_config() first. Is this what you had in mind? -Matt -- 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
