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. > > 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
