[EARLY RFC][PATCH 2/4] ion: Initial hack to create per heap devices

John Stultz john.stultz at linaro.org
Tue Feb 19 21:36:31 UTC 2019


On Tue, Feb 19, 2019 at 1:17 PM Laura Abbott <labbott at redhat.com> wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > One of the issues w/ the /dev/ion interface is that we have to
> > provide the complexity of a heap query interface and we end up
> > multiplexing all the heap access through that one interface via
> > a bit mask (which currently limits the heaps to 32).
> >
> > There has been a long running todo to provide per-heap devices
> > which would make the heap discovery/query interface "ls", and
> > would allow for different heaps to have different permisisons
> > and sepolicy rules.
> >
> > TODOs:
> > * Android doesn't use udev so "ion_heaps/%s" names don't
> >    automatically create a /dev/ subdir. I need to rework
> >    from miscdev to creating a proper device class and add
> >    a "subsystem" entry for the DeviceHandler to match with
> >
> > * Each CMA region is exposed via a separate heap, not sure
> >    if this is desired or not, and we may need to improve the
> >    naming.
> >
>
> Every CMA region getting exposed was a side effect of doing
> the eneumeration without tying it to devicetree or other firmware.
> I'm not opposed to limiting the heaps exposed if we can find
> a good way to do so that's still compliant with devicetree/whatever.
>

I suspect this will actually be preferred in the end.  Its just that
having the CMA heaps (and whatever ill thought naming was used in the
dts) more visible made my nose crinkle a bit. But now its a good
motivator for more clear names in the dts' of future devices. But
allowing for separate cma heaps that can be logically partitioned
between uses doesn't seem like a negative to me.

thanks
-john


More information about the dri-devel mailing list