| Message ID | 1411808085-27792-8-git-send-email-maxime.ripard@free-electrons.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Sat, Sep 27, 2014 at 10:54:43AM +0200, Maxime Ripard wrote: > The previous code was relying on the fact that the slave_caps were to be > defined on a per channel basis. > > However, this proved to be a bit overkill, since every driver filling these so > far were hardcoding it, disregarding which channel was actually given. > > Add these capabilities to the dma_device structure, so that drivers can just > provide them at probe time, and be done with it. This is also buggy for the same reason as patch 6. The only way to do this is to either have a flag day, fixing all drivers at once (which isn't going to happen) or leave the caps code as-is, and provide a library function which drivers can hook into the caps callback which retrieves the information from dma_device. That way, DMA engine drivers which are using the new method can just install the new function, and those which haven't been updated with capabilities can carry on as they are, and are detectable to drivers. What would be acceptable is to have the DMA engine registration function spot the lack of DMA caps function and print a warning at boot to encourage people to add it.
On Sat, Sep 27, 2014 at 10:28:47AM +0100, Russell King - ARM Linux wrote: > On Sat, Sep 27, 2014 at 10:54:43AM +0200, Maxime Ripard wrote: > > The previous code was relying on the fact that the slave_caps were to be > > defined on a per channel basis. > > > > However, this proved to be a bit overkill, since every driver filling these so > > far were hardcoding it, disregarding which channel was actually given. > > > > Add these capabilities to the dma_device structure, so that drivers can just > > provide them at probe time, and be done with it. > > This is also buggy for the same reason as patch 6. Indeed > The only way to do this is to either have a flag day, fixing all drivers > at once (which isn't going to happen) or leave the caps code as-is, and > provide a library function which drivers can hook into the caps callback > which retrieves the information from dma_device. > > That way, DMA engine drivers which are using the new method can just > install the new function, and those which haven't been updated with > capabilities can carry on as they are, and are detectable to drivers. Which is pretty much the current behaviour, isn't it? > What would be acceptable is to have the DMA engine registration function > spot the lack of DMA caps function and print a warning at boot to > encourage people to add it. That would be an option too. Maxime
On Wed, Oct 01, 2014 at 10:27:05AM +0200, Maxime Ripard wrote: > On Sat, Sep 27, 2014 at 10:28:47AM +0100, Russell King - ARM Linux wrote: > > The only way to do this is to either have a flag day, fixing all drivers > > at once (which isn't going to happen) or leave the caps code as-is, and > > provide a library function which drivers can hook into the caps callback > > which retrieves the information from dma_device. > > > > That way, DMA engine drivers which are using the new method can just > > install the new function, and those which haven't been updated with > > capabilities can carry on as they are, and are detectable to drivers. > > Which is pretty much the current behaviour, isn't it? Yes, because the ASoC code has obviously already thought about this and solved the lack-of-caps-function problem in a way that permits existing solutions to continue working.
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index cfcbee145898..e25a365b808c 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -594,6 +594,14 @@ struct dma_tx_state { * @fill_align: alignment shift for memset operations * @dev_id: unique device ID * @dev: struct device reference for dma mapping api + * @src_addr_widths: bit mask of src addr widths the device supports + * @dst_addr_widths: bit mask of dst addr widths the device supports + * @directions: bit mask of slave direction the device supports since + * the enum dma_transfer_direction is not defined as bits for + * each type of direction, the dma controller should fill (1 << + * <TYPE>) and same should be checked by controller as well + * @residue_granularity: granularity of the transfer residue reported + * by tx_status * @device_alloc_chan_resources: allocate resources and return the * number of allocated descriptors * @device_free_chan_resources: release DMA channel's resources @@ -643,6 +651,11 @@ struct dma_device { int dev_id; struct device *dev; + u32 src_addr_widths; + u32 dst_addr_widths; + u32 directions; + enum dma_residue_granularity residue_granularity; + int (*device_alloc_chan_resources)(struct dma_chan *chan); void (*device_free_chan_resources)(struct dma_chan *chan); @@ -783,6 +796,11 @@ static inline int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_cap if (!test_bit(DMA_SLAVE, device->cap_mask.bits)) return -ENXIO; + caps->src_addr_widths = device->src_addr_widths; + caps->dst_addr_widths = device->dst_addr_widths; + caps->directions = device->directions; + caps->residue_granularity = device->residue_granularity; + caps->cmd_pause = !!device->device_pause; caps->cmd_terminate = !!device->device_terminate_all;
The previous code was relying on the fact that the slave_caps were to be defined on a per channel basis. However, this proved to be a bit overkill, since every driver filling these so far were hardcoding it, disregarding which channel was actually given. Add these capabilities to the dma_device structure, so that drivers can just provide them at probe time, and be done with it. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- include/linux/dmaengine.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)