dc2b24630b
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> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| scsi | ||
| soc | ||
| sound | ||
| target | ||
| trace | ||
| uapi | ||
| vdso | ||
| video | ||
| xen | ||
| Kbuild | ||