On 16/04/13 17:39, the mail apparently from Selina Kuo included:
On 16 April 2013 16:20, Andy Green andy.green@linaro.org wrote:
On 16/04/13 14:29, the mail apparently from Jon Medhurst (Tixy) included:
On Tue, 2013-04-16 at 12:16 +0800, Andy Green wrote:
On 16/04/13 10:08, the mail apparently from Selina Kuo included:
Hi, John,
Your assumption is right. The ump code is part of the out-of-tree mali driver.
- Selina Kuo, one of Andy's colleagues ^^
As Selina says it's a code drop we got via Fujitsu from ARM for the OOT Mali driver.
However that code is all GPL2, as it should be.
I assume it's not for as yet unreleased IP and under NDA or anything. (Just thought I would throw that in there.)
Is T624 secret for ARM atm?
It's not secret for ARM. The latest version of MaliT624 kernel driver was released on 2013 March. http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-t6xx-...
The latest version on website is the same with the latest one which I got via Fujitsu from ARM.
Thanks... since that ARM page makes it clear it is GPL2, I pushed it here
https://git.linaro.org/gitweb?p=landing-teams/working/fujitsu/mali-t6xx-trac...
with our modifications as a starting point.
-Andy
It's just the kernelside bits we're talking about not the userland.
I think any of the options are good,
- make our own repo and keep it in sync with llct - privately encourage ARM to keep it in sync with Linus' HEAD,publicly
- upstream it so it's always in syncThis obviously helps of all LT who want to / can harmonize their tree on llct basis.
Tushar, do you have any opinion?
Anyone who dealt with this code or at ARM (Tixy?)
I've never dealt with this code but one thing occurs to me: how would you manage the user side binary blob? If different members have different versions of the blobs (or have tweaked them) are they all going to work with a common version of the kernel driver or have different members tweaked things for there own needs?
It's an issue but it is a bit separate.
If they will build their userland to work with a particular kernel + module at all, they all need to have module sources that work against that kernel to start with. Right now if what we have is representative, it's pretty lagging in that regard.
So this effort will give them a starting point that always builds (and hopefully works) they can maintain patches on top of. It's not for unifying all variations, unless people want to contribute and maintain them.
It's still enough that they can approach tracking Linus HEAD knowing they only need to take care of their patch content for uplevel purposes, and not take care of the bulk of the module.
-Andy
-- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog