Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

From: Laurent Pinchart
Date: Wed Apr 19 2017 - 08:42:12 EST


Hi Daniel,

On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> > Most of the items have been taken care of by a clean up series. Remove
> > the completed items and add a few new ones.
> >
> > Signed-off-by: Laura Abbott <labbott@xxxxxxxxxx>
> > ---
> >
> > drivers/staging/android/TODO | 21 ++++-----------------
> > 1 file changed, 4 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..5f14247 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> >
> > @@ -7,23 +7,10 @@ TODO:
> > ion/
> >
> > - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel
> > internal - interface on top of dma-buf. flush_for_device needs to be
> > added to dma-buf - first.
> > - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in
> > some - vendor trees. Should be replaced with an ioctl on the dma-buf to
> > expose the - begin/end_cpu_access hooks to userspace.
> > - - Clarify the tricks ion plays with explicitly managing coherency behind
> > the - dma api's back (this is absolutely needed for high-perf gpu
> > drivers): Add an - explicit coherency management mode to
> > flush_for_device to be used by drivers - which want to manage caches
> > themselves and which indicates whether cpu caches - need flushing.
> > - - With those removed there's probably no use for ION_IOC_IMPORT anymore
> > either - since ion would just be the central allocator for shared
> > buffers. - - Add dt-binding to expose cma regions as ion heaps, with the
> > rule that any - such cma regions must already be used by some device
> > for dma. I.e. ion only - exposes existing cma regions and doesn't
> > reserve unecessarily memory when - booting a system which doesn't use
> > ion.
> > + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This
> > would + involve putting appropriate bindings in a memory node for Ion
> > to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> > + - Better test framework (integration with VGEM was suggested)
>
> Found another one: Integrate the ion kernel-doc into
> Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.

If ion is a generic-purpose allocator, should its documentation really reside
in Documentation/gpu/ ?

> There's a lot of api and overview stuff already around, would be great to
> make this more accessible.
>
> But I wouldn't put this as a de-staging blocker, just an idea.
>
> On the series: Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>
> No full review since a bunch of stuff I'm not too familiar with, but I
> like where this is going.
> -Daniel
>
> > Please send patches to Greg Kroah-Hartman <greg@xxxxxxxxx> and Cc:
> > Arve Hjønnevåg <arve@xxxxxxxxxxx> and Riley Andrews
> > <riandrews@xxxxxxxxxxx>

--
Regards,

Laurent Pinchart