All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andrew F. Davis" <afd@ti.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Chenbo Feng <fengc@google.com>,
	Alistair Strachan <astrachan@google.com>,
	Liam Mark <lmark@codeaurora.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
Date: Wed, 27 Feb 2019 10:38:46 -0600	[thread overview]
Message-ID: <49434598-7f93-023e-4410-208a38fd3e8c@ti.com> (raw)
In-Reply-To: <CALAqxLUHGLUuc89_P1BZB59tco9y9jAsP1w3dbsUKMD_zi78ow@mail.gmail.com>

On 2/26/19 5:40 PM, John Stultz wrote:
> On Tue, Feb 26, 2019 at 11:21 AM John Stultz <john.stultz@linaro.org> wrote:
>>
>> On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis <afd@ti.com> 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 to crash
>>>> over and over.
>>>> (userland patches updated here:
>>>> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436)
>>>>
>>>
>>> Interesting, I wonder if the caching stuff is not right here, I'll see
>>> if I can get this working on my side (AOSP on Beagle x15).
>>>
>>
>> Let me know if you figure anything out, I'll also be looking at this today.
>>
> 
> Ok. Figured out the issue. There was a missing:
>   len = PAGE_ALIGN(len)
> assignment that the core used to do before calling the heap alloc op.
> 

Ah, that was my bad then, I dropped that line thinking the heaps should
take care of it, forcing allocation to the page length does make sense
though, we cant pass any less back to userspace.

> Adding that into the heap alloc op got it booting ok w/ AOSP.
> 
> I've updated the patches here:
> kernel: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> userland: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> 
> 
>> I also realized some of Benajmin's error path improvements are going
>> to be hard to fix w/ my current code, specifically having the allocate
>> op do the allocation of the dma_heap_buffer (since we don't have a
>> free op, if something fails creating the dmabuf fd in the core, we
>> don't have a hook to release the dma_heap_buffer and heap private
>> data).
> 

We can always add back the free op, the alternative is to have the heap
export the fd.

I'm not sure either is needed though, when we
dma_buf_put(buffer->dmabuf) on the error path it should trigger the
release op, and that can cleanup the allocations in the heap.

> I also realized doing my development and testing against my
> hikey960-mainline-WIP branch, I accidentally folded in an ion hack I
> was using to reduce cache operations, so I'll need to undo that in the
> heap-helpers.c.  But at least we have a rough validation point for the
> design.
> 

Great! The details of the heap-helpers can always get fixed up at a
later point, validation of the core working is really good to hear.

Thanks,
Andrew

> thanks
> -john
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-02-27 16:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-25 14:36 [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework Andrew F. Davis
2019-02-25 18:41 ` John Stultz
2019-02-26  0:20 ` John Stultz
2019-02-26 14:02   ` Andrew F. Davis
2019-02-26  0:55 ` John Stultz
2019-02-26 14:04   ` Andrew F. Davis
2019-02-26  3:53 ` Sumit Semwal
2019-02-26 14:28   ` Andrew F. Davis
2019-02-26  6:20 ` John Stultz
2019-02-26 14:46   ` Andrew F. Davis
2019-02-26 19:21     ` John Stultz
2019-02-26 23:40       ` John Stultz
2019-02-27 16:38         ` Andrew F. Davis [this message]
2019-02-27 21:55           ` John Stultz
2019-02-28 15:20             ` Andrew F. Davis
2019-03-01 23:49               ` John Stultz
2019-02-26 14:12 ` Benjamin Gaignard
2019-02-26 15:05   ` Andrew F. Davis
2019-02-26 15:22   ` Linus Walleij
2019-02-27 23:22 ` Laura Abbott
2019-02-28  0:14   ` John Stultz
2019-03-01 12:06 ` Brian Starkey
2019-03-04 14:53   ` Andrew F. Davis
2019-03-05  1:16     ` John Stultz
2019-03-05 18:05       ` Andrew F. Davis
2019-03-05 18:45         ` John Stultz
2019-03-05 18:22     ` Brian Starkey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49434598-7f93-023e-4410-208a38fd3e8c@ti.com \
    --to=afd@ti.com \
    --cc=astrachan@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fengc@google.com \
    --cc=john.stultz@linaro.org \
    --cc=lmark@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.