On Tue, Apr 17, 2018 at 03:58:21PM -0400, Sinan Kaya wrote: > On 4/17/2018 12:12 PM, Dave Jiang wrote: > > > > On 04/13/2018 07:12 PM, Sujeev Dias wrote: > >> Hi > >> > >> Can we please revert this patch because it breaks qcom dma-engine drivers and many consumers after > >> we propagated to 4.14 kernel. > >> > >> commit: c678fa66341c7b82a57cfed0ba3656162e970f99 > >> dmaengine: remove DMA_SG as it is dead code in kernel > >> > >> I don't see any alternate methods we can use either. We cannot use standard dma_memcpy > >> api's since argument for both src and destination dma_addr. Because dma mapping has to > >> be done by dma controller (due to smmu/sid configurations), client must pass host DDR > >> address as a cpu address not dma_addr. > >> > >> Thanks > >> Sujeev > >> > > Sujeev, > > At least IMO, when you don't have in kernel upstream consumer for the > > code, it's dead code for the kernel. In the end, it's Vinod's call. > > However, I do think in the future we will need support for DMA engines > > that want to take virtual memory addresses instead of DMA addresses with > > SMMU/SID type of implementation. So something new needs to be introduced.... > > If I remember this right, another implementation was going to replace DMA_SG. > DMA_SG got reverted but the new implementation wasn't put in place for some > reason. DMA_SG was *also* removed as we have no users in tree. If a user shows up it can be added. > Given we have few users of DMA Engine, I believe we should try to keep as > much functionality as possible in the kernel to allow new features to be > developed rather than limiting people's choices. Yes but not dead functionality which is not tested and not used. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
