LWN: Comments on "Destaging ION"

ION is removed

yashi — Tue, 21 Jan 2025 06:10:46 +0000

FYI: ION never graduated from the staging tree. Instead, it was removed in commit
https://git.kernel.org/torvalds/c/e722a295cf493388dae4747...

Destaging ION

excors — Thu, 11 Jul 2019 19:23:07 +0000

> I'd like to see the vendor specific gralloc HAL be replaced with a generic implementation with a fstab style config file that simply maps buffer usage to heap name

If I remember correctly, the gralloc implementation is responsible for calculating the sizes of image buffers, which might be in some vendor-specific GPU-efficient tiled layout with funny padding etc. mali_gralloc_ion.cpp has the AFBC code too. That kind of logic wouldn't fit in a config file, so I don't see how you can get away from needing a vendor-specific gralloc implementation.

Destaging ION

jhoblitt — Thu, 11 Jul 2019 19:10:56 +0000

(disclosure: I am not an android dev; just a user)

Aww, I didn't realize that there was a hal between surface flinger and the kernel. I suppose that means the kernel buf interface is essentially outside the scope of AOSP, in that the gralloc implementation could be anything so long as the GSI boots?

Destaging ION

jstultz — Thu, 11 Jul 2019 18:37:57 +0000

So the ION interfaces are usually accessed via vendor specific gralloc HAL code, so its not something we can shift all of AOSP to in one step. Each vendor has to move their out of tree ION heap implementations over and also rework their custom gralloc HAL to use the new API, so there will likely be a transition period. I've got such an gralloc implementation ready to be submitted to AOSP for the HiKey960 board already so there will be a reference example.

Personally, I'd like to see the vendor specific gralloc HAL be replaced with a generic implementation with a fstab style config file that simply maps buffer usage to heap name, so vendors only have to provide that config file, but I know there is always hesitancy to remove the ability for the vendors to have fully custom HAL implementations, so that may not be widely adopted.

I have been keeping the Google developers in the loop, and there has been no objections, and they do seem motivated to get vendors to to use proper upstream kernel interfaces, so while I can't speak for them, I believe they are on board with this new API.

Destaging ION

jhoblitt — Thu, 11 Jul 2019 02:32:52 +0000

Is there in indication that AOSP intends to convert to the new API or is this a completely independent effort?