On 16/04/13 17:39, the mail apparently from Selina Kuo included:
On 16 April 2013 16:20, Andy Green <andy.gr...@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-gpu-kernel-device-drivers/
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-tracking.git;a=summary
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 sync
This 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/#!/linaroorg - http://linaro.org/linaro-blog
--
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/#!/linaroorg - http://linaro.org/linaro-blog
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
