On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa <tf...@chromium.org> wrote:
> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <a...@arndb.de> wrote:
>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>
>> I'd say that this is something that has been consistently tried to be
>> avoided by V4L2 and that's why it's so tightly integrated with DMA
>> mapping. IMHO re-implementing the code that's already there in
>> videobuf2 again in the driver, only because, for no good reason
>> mentioned as for now, having a loadable module providing DMA ops was
>> disliked.
>
> Sorry, I intended to mean:
>
> IMHO re-implementing the code that's already there in videobuf2 again
> in the driver, only because, for no good reason mentioned as for now,
> having a loadable module providing DMA ops was disliked, would make no
> sense.
Why would we need to duplicate that code? I would expect that the videobuf2
core can simply call the regular dma_mapping interfaces, and you handle the
IOPTE generation at the point when the buffer is handed off from the core
code to the device driver. Am I missing something?
Arnd
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
