On Tue, Mar 5, 2019 at 10:05 AM Andrew F. Davis wrote:
> On 3/4/19 7:16 PM, John Stultz wrote:
> > The current patchset against v5.0 (with hikey960 patches), which
> > includes the flags and other suggested changes is here:
> >
> >
On Mon, Mar 04, 2019 at 08:53:42AM -0600, Andrew F. Davis wrote:
> On 3/1/19 6:06 AM, Brian Starkey wrote:
> >
> > Am I right in thinking "cmd" comes from userspace? It might be a good
> > idea to not trust _IOC_SIZE(cmd) and use our own. I'm looking at
> >
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, unsigned int cmd, unsigned
long
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, unsigned int cmd, unsigned
> >> long arg)
> >> +{
> >> +switch (cmd) {
> >>
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 wrote:
>> This framework allows a
On Thu, Feb 28, 2019 at 9:21 AM Andrew F. Davis wrote:
>
> On 2/27/19 3:55 PM, John Stultz wrote:
> > On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis wrote:
> >>
> >> We can always add back the free op, the alternative is to have the heap
> >> export the fd.
> >>
> >> I'm not sure either is
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 wrote:
> This framework allows a unified userspace interface for dma-buf
> exporters,
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 Wed, Feb 27, 2019 at 3:22 PM Laura Abbott wrote:
> On 2/25/19 6:36 AM, Andrew F. Davis wrote:
> > +
> > +dev_t dma_heap_devt;
> > +struct class *dma_heap_class;
>
> Can we make sure this gets reviewed by Greg sooner rather than
> later when we drop the RFC? I think the use of this here
> is
On 2/25/19 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.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the
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:
> > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> >
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 there's something
wrong with the
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 there's something
> > > wrong with the dmabuf mmaping which casues the homescreen
On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis wrote:
> On 2/26/19 12:20 AM, John Stultz wrote:
> > On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
> >> It all needs a bit more work, and I'm sure I'll find missing parts when
> >> I add some more heaps, but hopefully this framework is
On Tue, Feb 26, 2019 at 3:12 PM Benjamin Gaignard
wrote:
> Overall I like the idea but I think "dma_heap" will be confusing like
> dma_buf is because it isn't
> related to DMA engine.
It wouldn't be the only place, in Device Tree we use "dma-ranges" in the
PCI bus host bindings to define how
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 sharing.
>>
>> Each heap is
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.
>>
>> Each heap is given its
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.
>>
>> Each heap is given its own
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 sharing.
>
> Each heap is given its own device node, which a user can allocate
> a
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;
>> +
>> + buffer =
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.
>>
>> Each heap is given its
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.
>
> Each heap is given its own device node, which a user can allocate
> a
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.
>
> Each heap is given its own device node, which a user can allocate
> a
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;
> +
> + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> + if
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.
>
> Each heap is given its own device node, which a user can allocate
> a
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.
>
> Each heap is given its own device node, which a user can allocate
> a
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.
27 matches
Mail list logo
