On 04/17/2018 11:13 PM, Vinod Koul wrote:
On Tue, Apr 17, 2018 at 09:12:43AM -0700, 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.
Why, can you point out the upstream drivers which broke.. They are none, so
we are not obliged to revert this, sorry!
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.
You can submit your driver along with revert, we can give it due
consideration and suggest you fixes to get your driver supported.
Thanks Vinod, we're actually working on submitting series of drivers for
upstream consideration. I am trying to submit
the first dmaengine driver for review end of next week. As far as this
request, we're also looking into using device_prep_dma_memcpy, and consumer
using dma_chan->device->dev for their mapping. This way, if clients
recycles the buffer they can also use dma_sync apis
for recycling the mapping.
Also as a minor optimization, we're planning to return
dma_async_tx_descriptor for prep_dma_memcpy only if EOT flags is set.
Otherwise
we will return NULL on success. This way we avoid memory allocation per
packet. Do you have any concern with that approach?
Thanks
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....
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
