ANDROID: staging: ion: reserve specific heap ids for known heap types.
Since its inception, ion used heap types and heap ids interchangeably.
The 'heap type' is not part of the UAPI but 'heap ids' are. The sad part
is that heap ids are dynamically generated and heap types aren't. This
causes all sorts of problems trying to support following things
1. No UAPI breakage for ION in GKI
2. Support multiple CMA heaps (i.e. heap with same type but
different ids)
3. Allow Android system code to reliably talk to any ION
driver using the standard / reserved heap types. etc.
4. Allow someone to override standard heap implementation.
5. Allow for new heap types to register to ion core.
With this change, we start the process of reserving heap ids for
long known heap types like system, carveout etc. In order to not
break ABI and UAPI, we continue to use 32-bits with following caveats
1. BIT(0)-BIT(15) are reserved for standard / GKI heap ids
that Android platform can use from now on reliably.
2. BIT(16)-BIT(31) are reserved for custom heap types that
only vendor specific processes can rely upon.
3. BIT(3)-BIT(7) are reserved for CARVEOUT heaps.
4. BIT(8)-BIT(15) are reserved for CMA / DMA heaps that manage
different CMA regions. The heap ids will be allocated in ascending
order and are first come first served.
Bug: 133508579
Test:ion-unit-tests
Change-Id: I53af694113b62d29e0d2933fbcf7079d845099e9
Signed-off-by:
Sandeep Patil <sspatil@google.com>
Loading
Please register or sign in to comment