On 17/05/12 21:26, Somebody in the thread at some point said:
On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambrough@linaro.org wrote:
On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote:
On Thu, 2012-05-17 at 07:42 +0800, Andy Green wrote:
Just curious... how many LTs have Mali stuff? If it's more than one, we should perhaps be talking about moving it to linux-linaro-core-tracking.
We have two teams with three different versions of the driver ;-) with, I suspect, custom modifications (different memory management components?).
Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM).
From my bystanders point of view, the interaction with closed source binary blobs seems to cause people enough nightmares without also trying to converge code-lines between teams. Especially when engineering resources are spread so thin.
Fortunately (?), the two teams have the drivers under different paths with different module and Kconfig option naming, so they could coexist in the same tree.
It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant.
Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack.
What does this mean for the unified kernel effort then?
We should attempt to unify kernels excluding Mali, or we should wrap or capture the differences in Mali?
Is there anything that the unified kernel effort can do (I mean in terms of slotting things in llct and the like) that can converge with where UMM-uber-alles is headed?
-Andy