On 5/6/20 12:30 PM, John Stultz wrote:
> On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis wrote:
>> On 5/4/20 4:50 AM, Brian Starkey wrote:
>>> On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote:
>>>> So the name we expose is the CMA name itself. So with dt i
gt;> This patch adds a linux,cma-heap property for CMA reserved memory
>>>> regions, which will be used to allow the region to be exposed via
>>>> the DMA-BUF Heaps interface
>>>>
>>>> Cc: Rob Herring
>>>> Cc: Sumit Semwal
>>>
On 4/24/20 8:44 PM, John Stultz wrote:
> On Fri, Apr 24, 2020 at 3:27 PM Andrew F. Davis wrote:
>> This new export type exposes to userspace the SRAM area as a DMA-Heap,
>> this allows for allocations as DMA-BUFs that can be consumed by various
>> DMA-BUF supporting devices
On 4/27/20 11:17 AM, Rob Herring wrote:
> On Fri, Apr 24, 2020 at 5:27 PM Andrew F. Davis wrote:
>>
>> This new export type exposes to userspace the SRAM area as a DMA-Heap,
>> this allows for allocations as DMA-BUFs that can be consumed by various
>> DMA-BUF supportin
Some clients of DMA-Heaps probe earlier than subsys_initcall(), this
can cause issues when these clients call dma_heap_add() before the
core DMA-Heaps framework has initialized. DMA-Heaps should initialize
during core startup to get ahead of all users.
Signed-off-by: Andrew F. Davis
---
drivers
This new export type exposes to userspace the SRAM area as a DMA-Heap,
this allows for allocations as DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/sram/sram.yaml| 8 +
drivers/misc/Kconfig
On 12/17/19 1:02 PM, H. Nikolaus Schaller wrote:
> and add interrupt
>
> Tested-by: H. Nikolaus Schaller # OpenPandora 600 MHz.
> Signed-off-by: H. Nikolaus Schaller
> ---
> arch/arm/boot/dts/omap34xx.dtsi | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arc
Most Kconfig options to enable a driver are in the Kconfig file
inside the relevant directory, move these two to the same.
Signed-off-by: Andrew F. Davis
---
Changes from v1:
- Rebased
drivers/gpu/drm/Kconfig| 34 --
drivers/gpu/drm/amd/amdgpu/Kconfig
Hello all,
This is a quick series to cleanup some minor naming issues in the new
DMA-BUF Heaps series on next before the names become ABI.
Thanks,
Andrew
Andrew F. Davis (2):
dma-buf: heaps: Use _IOCTL_ for userspace IOCTL identifier
dma-buf: heaps: Remove redundant heap identifier from
This is more consistent with the DMA and DRM frameworks convention. This
patch is only a name change, no logic is changed.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/dma-heap.c | 4 ++--
include/uapi/linux/dma-heap.h | 4 ++--
tools/testing
The heaps are already in a directory of heaps, adding _heap to a heap
name is redundant. This patch is only a name change, no logic is changed.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/heaps/system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma
On 12/3/19 12:26 PM, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>
> Each heap is given its ow
hanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: S
a error and ioctl compatibility testing suggested by
> Daniel Vetter to the kselftest test
>
> Thanks again for all the reviews and feedback!
> -john
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> C
On 11/6/19 12:18 PM, Andrew F. Davis wrote:
> On 11/6/19 12:03 PM, John Stultz wrote:
>> On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>>>
>>> On 11/5/19 11:22 PM, John Stultz wrote:
>>>> +unsigned int dma_heap_ioctl_cmds[] = {
>>>> +
On 11/6/19 12:03 PM, John Stultz wrote:
> On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>>
>> On 11/5/19 11:22 PM, John Stultz wrote:
>>> +unsigned int dma_heap_ioctl_cmds[] = {
>>> + DMA_HEAP_IOC_ALLOC,
>>> +};
>>> +
>>>
On 11/5/19 11:22 PM, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>
> Each heap is given its ow
On 11/5/19 4:42 AM, Daniel Vetter wrote:
> On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote:
>> On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote:
>>> On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote:
Now that the DMA BUF heaps core code has been queued, I wanted
t
On 10/30/19 11:02 AM, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being assigned with a value that is never
> read, it is being re-assigned the same value on the err0 exit
> path. The assignment is redundant and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
ounting, since any such
>> accounting should be implemented by dma-buf core or the heaps
>> themselves.
>>
>> New in v13:
>> * Re-remove symbol exports, per discussion with Brian. I'll
>> resubmit these separately in a later patch so they can be
>>
:45PM -0700, John Stultz wrote:
>>>>> On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
>>>>>> On 10/17/19 3:14 PM, John Stultz wrote:
>>>>>>> But if the objection stands, do you have a proposal for an alternative
>>>>>>
On 10/18/19 8:03 AM, Benjamin Gaignard wrote:
> Le ven. 18 oct. 2019 à 13:21, Brian Starkey a écrit :
>>
>> On Fri, Oct 18, 2019 at 05:23:22AM +, John Stultz wrote:
>>> This adds a CMA heap, which allows userspace to allocate
>>> a dma-buf of contiguous memory out of a CMA region.
>>>
>>> This
On 10/17/19 3:14 PM, John Stultz wrote:
> On Wed, Oct 16, 2019 at 10:41 AM Andrew F. Davis wrote:
>> On 10/14/19 5:07 AM, Brian Starkey wrote:
>>> Hi Andrew,
>>>
>>> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
>>>> The CMA d
Most Kconfig options to enable a driver are in the Kconfig file
inside the relevant directory, move these two to the same.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/Kconfig| 34 --
drivers/gpu/drm/amd/amdgpu/Kconfig | 18
drivers
On 10/14/19 5:07 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
>> The CMA driver that registers these nodes will have to be expanded to
>> export them using this framework as needed. We do something similar to
gested by Christoph)
>>>> * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
>>>> (suggested by Christoph)
>>>> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
>>>> Christoph)
>>>> * Get rid of needless struct s
On 5/28/19 4:11 AM, Tomi Valkeinen wrote:
> Hi,
>
> On 10/05/2019 22:42, Adam Ford wrote:
>> Currently the source code is compiled using hard-coded values
>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
>> clock divider value to be moved to the device tree and be changed
>> witho
On 6/18/19 5:07 AM, Tero Kristo wrote:
> On 07/06/2019 22:35, Andrew F. Davis wrote:
>> This patch adds a driver for the Page-based Address Translator (PAT)
>> present on various TI SoCs. A PAT device performs address translation
>> using tables stored in an internal SRAM. Ea
On 7/25/19 9:02 AM, Christoph Hellwig wrote:
>> +struct system_heap {
>> +struct dma_heap *heap;
>> +} sys_heap;
>
> It seems like this structure could be removed and if would improve
> the code flow.
>
>> +static struct dma_heap_ops system_heap_ops = {
>> +.allocate = system_heap_allocat
On 7/25/19 10:30 AM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 10:25:50AM -0400, Andrew F. Davis wrote:
>> On 7/25/19 10:11 AM, Christoph Hellwig wrote:
>>> On Thu, Jul 25, 2019 at 10:10:08AM -0400, Andrew F. Davis wrote:
>>>> Pages yes, but not "normal&
On 7/25/19 10:11 AM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 10:10:08AM -0400, Andrew F. Davis wrote:
>> Pages yes, but not "normal" pages from the kernel managed area.
>> page_to_pfn() will return bad values on the pages returned by this
>> allocator and
On 7/25/19 10:04 AM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 09:31:50AM -0400, Andrew F. Davis wrote:
>> But that's just it, dma-buf does not assume buffers are backed by normal
>> kernel managed memory, it is up to the buffer exporter where and when to
>>
On 7/25/19 8:48 AM, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 07:38:07AM -0400, Laura Abbott wrote:
>> It's not just an optimization for Ion though. Ion was designed to
>> let the callers choose between system and multiple CMA heaps.
>
> Who cares about ion? That some out of tree android
On 7/25/19 8:50 AM, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 11:46:01AM -0400, Andrew F. Davis wrote:
>> https://patchwork.kernel.org/patch/10863957/
>>
>> It's actually a more simple heap type IMHO, but the logic inside is
>> incompatible with the syst
On 7/24/19 2:59 AM, Christoph Hellwig wrote:
> On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote:
>> Apologies, I'm not sure I'm understanding your suggestion here.
>> dma_alloc_contiguous() does have some interesting optimizations
>> (avoiding allocating single page from cma), though its
On 7/24/19 2:55 AM, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 01:09:55PM -0700, Rob Clark wrote:
>> On Mon, Jul 22, 2019 at 9:09 PM John Stultz wrote:
>>>
>>> On Thu, Jul 18, 2019 at 3:06 AM Christoph Hellwig
>>> wrote:
Is there any exlusion between mmap / vmap and the device
window for which an incoming transaction will be
translated.
Signed-off-by: Andrew F. Davis
---
drivers/soc/ti/Kconfig | 9 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pat.c | 569
include/uapi/linux/ti-pat.h | 44 +++
4 files changed, 623
s,
Andrew
[0] http://www.ti.com/lit/pdf/spruil1
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
[2] https://lkml.org/lkml/2019/6/6/1211
Andrew F. Davis (2):
dt-bindings: soc: ti: Add TI PAT bindings
soc: ti: Add Suppor
, 64KB, or 1MB of addresses in a window for which an incoming
transaction will be translated.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/misc/ti,pat.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/ti
On 4/1/19 2:13 AM, Daniel Vetter wrote:
> On Fri, Mar 29, 2019 at 11:52:01AM -0500, Andrew F. Davis wrote:
>> The docs state the callback is optional but it is not, make it optional.
>>
>> Signed-off-by: Andrew F. Davis
>
> There's a bunch of dummy mmap implement
The docs state the callback is optional but it is not, make it optional.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/dma-buf.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b
Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Xu YiPing
> Cc: &qu
Found with scripts/coccinelle/misc/boolconv.cocci.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3
On 3/29/19 10:30 AM, Benjamin Gaignard wrote:
> Le ven. 29 mars 2019 à 16:19, Andrew F. Davis a écrit :
>>
>> On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
>>> Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
>>>>
>>>> This adds a CMA heap, whic
ION implementation, so
>> thanks to its original author and maintainters:
>> Benjamin Gaignard, Laura Abbott, and others!
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Pratik Patel
>> Cc: Bria
rs:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
>
counting to system/cma heaps
> * Make the kselftest more useful
> * Add other heaps folks see as useful (would love to get
> some help from actual carveout/chunk users)!
>
> That said, the main user-interface is shaping up and I wanted
> to get some input on the device model
rs:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dr
On 3/19/19 9:26 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:30PM -0800, John Stultz wrote:
>
> ...
>
>> +
>> +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
>> +{
>> +struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
>> +
>> +
The map_atomic/unmap_atomic callbacks have been removed, remove
the related comments.
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/d
Other function have inline documentation, a couple still have
theirs at the top of the structure, update the docs and move
them inline.
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a
This new export type exposes to userspace the SRAM area as a DMA-Heap,
this allows for allocations as DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew F. Davis
---
Hello all,
This is an example user of the currently RFC DMA-HEAP framework. It
exports a
On 3/20/19 4:16 AM, Benjamin Gaignard wrote:
> Le mar. 19 mars 2019 à 23:36, John Stultz a écrit :
>>
>> On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote:
>>>
>>> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote:
>>>>
>>>> On 3/19/19
On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> Le mer. 13 mars 2019 à 23:31, John Stultz a écrit :
>>
>> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:
Eventual TODOS:
* Reimplement page-pool for system heap (working on this)
* Add
On 3/19/19 7:08 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
>> From: "Andrew F. Davis"
>
> [snip]
>
>> +
>> +#define NUM_HEAP_MINORS 128
>> +static DEFINE_IDR(dma_heap_idr);
>>
On 3/15/19 4:06 AM, Christoph Hellwig wrote:
>> +ret = remap_pfn_range(vma, addr, page_to_pfn(page), len,
>> + vma->vm_page_prot);
>
> So the same chunk could be mapped to userspace and vmap, and later on
> also DMA mapped. Who is going to take care of
On 3/15/19 3:18 PM, Laura Abbott wrote:
> On 3/5/19 12:54 PM, John Stultz wrote:
>> +DMA-BUF HEAPS FRAMEWORK
>> +M: Laura Abbott
>> +R: Liam Mark
>> +R: Brian Starkey
>> +R: "Andrew F. Davis"
>> +R: John Stultz
>> +S: Maintai
On 3/15/19 3:54 AM, Christoph Hellwig wrote:
>> +static int dma_heap_release(struct inode *inode, struct file *filp)
>> +{
>> +filp->private_data = NULL;
>> +
>> +return 0;
>> +}
>
> No point in clearing ->private_data, the file is about to be freed.
>
This was leftover from when release
On 3/13/19 5:57 PM, Liam Mark wrote:
> On Wed, 13 Mar 2019, Andrew F. Davis wrote:
>
>> On 3/13/19 3:18 PM, Liam Mark wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:
>>>
>>>> Add generic helper dmabuf ops for dma heaps, so we can reduce
>>&g
mentation, so
>> thanks to its original authors and maintainters:
>> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian
On 3/6/19 1:03 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>>
>> On 3/5/19 2:54 PM, John Stultz wrote:
>>> From: "Andrew F. Davis"
>>>
>>> This framework allows a unified userspace interface for dma-buf
&
On 3/6/19 12:19 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>>
>> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
>>> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>>>>
>>>> Add very trivial allocation test fo
ott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Chenbo Feng
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stu
On 3/5/19 2:54 PM, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of
> memory for use in dma-buf sharing.
>
> Each heap is given its ow
On 3/4/19 7:16 PM, John Stultz wrote:
> On Mon, Mar 4, 2019 at 6:53 AM Andrew F. Davis wrote:
>> On 3/1/19 6:06 AM, Brian Starkey wrote:
>>> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
>>>> +static long dma_heap_ioctl(struct file *filp, unsigne
On 3/1/19 6:06 AM, Brian Starkey wrote:
> Hi Andrew,
>
> Sorry for not managing to comment on this sooner, I've had a crazy few
> days.
>
> As the others have said, I quite like the direction here.
>
> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrot
On 2/27/19 3:55 PM, John Stultz wrote:
> On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis wrote:
>>
>> On 2/26/19 5:40 PM, John Stultz wrote:
>>> On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote:
>>> I've updated the patches here:
>>> kernel:
On 2/26/19 5:40 PM, John Stultz wrote:
> On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote:
>>
>> On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis wrote:
>>> On 2/26/19 12:20 AM, John Stultz wrote:
>>>> It boots w/ AOSP, and allocations seem to work, but t
On 2/26/19 8:12 AM, Benjamin Gaignard wrote:
> Le lun. 25 févr. 2019 à 15:36, Andrew F. Davis a écrit :
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf
On 2/26/19 12:20 AM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
&
On 2/25/19 9:53 PM, Sumit Semwal wrote:
> On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
>&
On 2/25/19 6:55 PM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>> unsigned int flags)
>> +{
>> + struct dma_heap_buffer *buffer;
>> + int fd, ret;
On 2/25/19 6:20 PM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
&
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Signed-off-by: Andrew F
rough RFC over the weekend if that is okay with you (not trying to walk
over your work here or anything, just want to show what I'm thinking if
any of the above doesn't make sense) :)
Thanks,
Andrew
> thanks
> -john
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit S
ems to make the most sense here. Even heap type
doesn't look like a good thing to expose, it is just as static and
one-off as heap name, I don't see it having all that much use :/
Andrew
>> Cc: Laura Abbott
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Sta
its own permissions/sepolicy rules.
>>
>> Feedback would be greatly appreciated!
>> thanks
>> -john
>>
>> Cc: Laura Abbott
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Alistair Strachan
>
On 2/15/19 1:01 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>>
>> Hi John,
>>
>> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>>>
>> [snip]
>>
>>> Some thoughts, as this ABI break has the potential to be pretty painful.
>>>
>>> 1) Unfortunately, th
On 2/15/19 1:58 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>>
>> On 2/15/19 1:01 PM, John Stultz wrote:
>>> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>>>> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wr
On 1/29/19 5:44 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Liam Mark wrote:
>
>> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/18/19 12:37 PM, Liam Mark wrote:
>>>> The ION begin_cpu_access and end_cpu_access functions use the
>>>> dma
;)
Signed-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the
On 1/24/19 9:24 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 01:28:35PM -0600, Andrew F. Davis wrote:
>> Previously the heap to allocate from was selected by a mask of allowed
>> heap types. This may have been done as a primitive form of constraint
>&
On 1/23/19 11:11 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 10:51:24AM -0600, Andrew F. Davis wrote:
>> On 1/22/19 11:33 AM, Sumit Semwal wrote:
>>> Hello everyone,
>>>
>>> Sincere apologies for chiming in a bit late here,
ned-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the other ta
On 1/22/19 9:23 PM, Sumit Semwal wrote:
> Hello everyone,
>
> (Thanks to Dan for letting me know my last email got corrupted :/ -
> resending it here)
>
Hmm, this one seems a bit messed up also (Thunderbird doesn't seem to
like it at least).
[snip]
> - from dma-buf PoV, ION is an exporter of d
ittle different in each email, so I'd like to respond
to bits of both, I'll fix up the formatting.
> Also, adding Daniel Vetter to the mix, since he has been one of the
> core guys who shaped up dma-buf as it is today.
>
> On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis w
On 1/21/19 4:12 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
>>> The main use case is for allowing clients to pass in
>>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance
>>> which happen
On 1/21/19 4:18 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 2:20 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/21/19 1:44 PM, Liam Mark wrote:
>>>>> On Mon, 21 Ja
On 1/21/19 5:22 AM, Brian Starkey wrote:
> Hi,
>
> Sorry for being a bit sporadic on this. I was out travelling last week
> with little time for email.
>
> On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
>> On 1/17/19 7:11 PM, Liam Mark wrote:
>>&
On 1/21/19 2:20 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 1:44 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>>>
>>>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
>&
On 1/21/19 1:44 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
And who is going to decide which ones to pass? And who documents
which ones are safe?
I'd much rather have explicit, well doc
On 1/18/19 3:43 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/17/19 7:04 PM, Liam Mark wrote:
>>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>>>> On Wed, 16 Jan
On 1/18/19 2:19 PM, Laura Abbott wrote:
> On 1/16/19 8:05 AM, Andrew F. Davis wrote:
>> On 1/15/19 12:58 PM, Laura Abbott wrote:
>>> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>>>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>>>> On 1/11/19 10:0
On 1/18/19 1:53 PM, Laura Abbott wrote:
> On 1/16/19 9:12 AM, Andrew F. Davis wrote:
>> On 1/16/19 9:28 AM, Brian Starkey wrote:
>>> Hi Andrew,
>>>
>>> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>>>> The heap name can be used f
On 1/18/19 2:31 PM, Laura Abbott wrote:
> On 1/17/19 8:13 AM, Andrew F. Davis wrote:
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19 10:38
On 1/18/19 12:37 PM, Liam Mark wrote:
> The ION begin_cpu_access and end_cpu_access functions use the
> dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> maintenance.
>
> Currently it is possible to apply cache maintenance, via the
> begin_cpu_access and end_cpu_access APIs, t
a_sync_sg_for_cpu
>
The window for this seems really small, but it does seem technically
possible, good find. for what it's worth:
Acked-by: Andrew F. Davis
> Fix this by getting the ion_buffer lock before freeing the sg table memory.
>
> Fixes: 2a55e7b5e544 ("staging: andr
On 1/17/19 7:11 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:54 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 9:19 AM, Brian Starkey wrote:
>>>>> Hi :-)
>
On 1/17/19 7:04 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
>> When enabled the helpers functions for creating carveout and chunk heaps
>> should have declarations in the ION header.
>
> Why? No one calls these from what I
1 - 100 of 143 matches
Mail list logo
