On 17/05/12 15:37, Somebody in the thread at some point said:
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?).
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.
Well...
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.
... without underestimating the problems (which we know well from SGX), this is exactly Linaro's core business to sort out isn't it? I mean they're even nominally *Linaro* LT trees and they're divergent on a critical, expensive chunk of code and we're saying, "but it's haaaard".
My guess is those teams lose sleep over Mali same as we lost much sleep over SGX and would welcome getting a single, latest version with correct userland handed to them, so there's one thing to talk about with ARM. Then by fixing this Linaro directly and visibly has added value for the members involved.
Whatever customizations are patched on top need to come out of the woodwork and get discussed what they're for. Depending what they are they could either go in llct if acceptable to all parties or if necessary get stitched in smarter so they're enabled by flags from plat-...er DT.
-Andy