On Tue, Feb 18, 2020 at 2:20 PM Christian König
wrote:
>
> Am 05.11.19 um 11:20 schrieb Daniel Vetter:
> > On Tue, Oct 29, 2019 at 11:40:45AM +0100, Christian König wrote:
> > [SNIP]
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index d377b4ca66bf..ce293cee76ed 10064
Am 05.11.19 um 11:20 schrieb Daniel Vetter:
On Tue, Oct 29, 2019 at 11:40:45AM +0100, Christian König wrote:
[SNIP]
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..ce293cee76ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -529,6
Please ignore this one, I've send out the wrong version without Daniels
latest comment nit picks fixed.
The interesting one in this series is the last patch.
Regards,
Christian.
Am 17.02.20 um 16:45 schrieb Christian König:
On the exporter side we add optional explicit pinning callbacks. Whic
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the
On Tue, Oct 29, 2019 at 11:40:45AM +0100, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. Which are
> called when the importer doesn't implement dynamic handling, move notification
> or need the DMA-buf locked in place for its use case.
>
> On the importer
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the
