Userspace needs a way to detect ION ABI version at runtime to determine
heap IDs. CURRENT_ION_ABI_VERSION is set to 2 considering legacy and
upstream versions as 0 and 1.
Bug: 140916230
Test: make
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Change-Id: Ie9d9e23c2d8323620832906d33745d599cbce6be
Change the enup order for ion heap types to match how it was before so
as to not break any userspace code that depends on them.
Bug: 140507100
Test: ion-unit-tests
Change-Id: Id68c50a9bd3eda2ce46bc88a326a120c52d1110f
Signed-off-by: Sandeep Patil <sspatil@google.com>
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>
