On Wed, Aug 21, 2013 at 12:03:50AM +0900, Akinobu Mita wrote: > The discussion in that thread is useful. Also, I found that Russell King > proposed replacing the boilerplate by using dma_coerce_mask_and_coherent() > in his patch set "Preview of DMA mask changes". > https://patchwork.kernel.org/patch/2837359/ That is an attempt to pull all that stuff into one central place so we don't have loads of drivers dealing with it in their own way. As far as I can gather from those who deal with DT, such as Arnd, is that they believe it to be wrong that the DT code sets up the DMA masks, and they think that stuff will break if the DT code does set these pointers up. The big problem which we have is we have a whole bunch of drivers which don't bother at all with the DMA set mask functions (because they've been fiddling with the mask directly) and sorting that mess out is going to be pretty damn difficult. So, the above series is all about bringing stuff to a central place where we can then start thinking about changing the behaviour and not have to patch lots of drivers throughout the tree for every change that's made. The way I envision the change happening is this: 1. Introduce the notion of mask coercion (drivers forcing the mask to a particular value.) 2. Add dma_set_mask() and similar functions to these drivers incrementally. 3. Move the initialization of the mask up to the device creation level (iow, the DT code) and out of the drivers (this can be done by adding it to the DT code, and removing it from the mask coercion code.) 4. Remove dma_coerce_mask_and_coherent() from the kernel once complete. So, why bother with dma_coerce_mask_and_coherent()? Not only does it centralise the "hack" but it also provides a means to identify drivers which need work and/or have been missed (you just have to grep for the direct assignments to the DMA masks.) Not only that but once the hack is centralised, it removes some of the variability in the drivers, and provides a step where we can allow things to be tested hopefully without causing any regressions. At least that's the theory. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
