Re: Mali-ization
On 17/04/13 19:11, the mail apparently from Jon Medhurst (Tixy) included: On Wed, 2013-04-17 at 16:28 +0530, Tushar Behera wrote: On 04/16/2013 09:46 AM, 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 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? It would always help to have the Mali driver synced with latest upstream and getting merged into 'llct'. The LT's who need to use this driver can have their modifications (if any) on top of it. Each LT will have to make sure that their changes are suitably guarded with #ifdefs to avoid stepping on each other's toes. But then that isn't going to work with a multi-platform kernel. So the changes are going to need to be made run-time configurable based on device-tree or something. Speaking of device-tree, do the Mali drivers have device-tree support? Nope... this will be a basis that other branches patch on top of if they want to modify. If it does happen that xyz-LT had special sauce, they'll have a branch like xyz-mali-t6xx-tracking which is mali-t6xx-tracking with their patches on top, and they'll follow by rebase. Having been there before and survived 2,500 patch loads on top of a rebase tree, trust me this one is trivial to deal with. Obviously it is nicer if eventually the changes for supporting different IP revisions cleanly, and any member special sauces (if any) are merged in one tree. But it is not necessary and everyone is ahead just by having a basis tree for the OOT module that actually builds againt llct, as Tushar noted. -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
Re: Mali-ization
On Wed, 2013-04-17 at 16:28 +0530, Tushar Behera wrote: > On 04/16/2013 09:46 AM, 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 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? > > > > It would always help to have the Mali driver synced with latest upstream > and getting merged into 'llct'. The LT's who need to use this driver can > have their modifications (if any) on top of it. Each LT will have to make sure that their changes are suitably guarded with #ifdefs to avoid stepping on each other's toes. But then that isn't going to work with a multi-platform kernel. So the changes are going to need to be made run-time configurable based on device-tree or something. Speaking of device-tree, do the Mali drivers have device-tree support? -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 04/16/2013 09:46 AM, 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 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? > It would always help to have the Mali driver synced with latest upstream and getting merged into 'llct'. The LT's who need to use this driver can have their modifications (if any) on top of it. > Anyone who dealt with this code or at ARM (Tixy?) > > FWIW our TSC rep is aware of this and I believe would support whatever > the best-looking of these solutions is. > > -Andy > >> On 16 April 2013 07:50, John Stultz wrote: >>> On 04/13/2013 03:22 AM, Andy Green wrote: On 13/04/13 09:07, the mail apparently from Andy Green included: > I'm hoping someone else will write the patches ^^ but if not I'll try > to sort something out. The attached series gets it building cleanly against current llct with ION. >>> >>> >>> Cool. Although the patches look like they are all against the ump >>> driver(which I'm not familiar with), as opposed to changes to the ION >>> infrastructure itself. So they won't apply to the AOSP trees, and I >>> can't >>> send them upstream. >>> >>> I assume the ump code is part of the out-of-tree mali driver? Looking at >>> llct, I don't see a drivers/base/ump directory. >>> >>> https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking >>> >>> >>> But I'm guessing this is the point of your original mail in this >>> thread: we >>> need a mali tree upon which fixes like these can be applied and then >>> pulled >>> into llct. >>> >>> Or even better, can we get the mali devs to publish a repo of their >>> latest >>> work (to which fixes like Andy's can be submitted to) which can also be >>> pulled into llct? >>> >>> thanks >>> -john >>> >>> >>> >>> ___ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev > > -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 16/04/13 17:39, the mail apparently from Selina Kuo included: On 16 April 2013 16:20, Andy Green 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
Re: Mali-ization
On 16 April 2013 16:20, Andy Green 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
Re: Mali-ization
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 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
Re: Mali-ization
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.) > 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? -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
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 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?) FWIW our TSC rep is aware of this and I believe would support whatever the best-looking of these solutions is. -Andy On 16 April 2013 07:50, John Stultz wrote: On 04/13/2013 03:22 AM, Andy Green wrote: On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. Cool. Although the patches look like they are all against the ump driver(which I'm not familiar with), as opposed to changes to the ION infrastructure itself. So they won't apply to the AOSP trees, and I can't send them upstream. I assume the ump code is part of the out-of-tree mali driver? Looking at llct, I don't see a drivers/base/ump directory. https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking But I'm guessing this is the point of your original mail in this thread: we need a mali tree upon which fixes like these can be applied and then pulled into llct. Or even better, can we get the mali devs to publish a repo of their latest work (to which fixes like Andy's can be submitted to) which can also be pulled into llct? thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- 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
Re: Mali-ization
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 ^^ On 16 April 2013 07:50, John Stultz wrote: > On 04/13/2013 03:22 AM, Andy Green wrote: >> >> On 13/04/13 09:07, the mail apparently from Andy Green included: >> >>> I'm hoping someone else will write the patches ^^ but if not I'll try >>> to sort something out. >> >> >> The attached series gets it building cleanly against current llct with >> ION. > > > Cool. Although the patches look like they are all against the ump > driver(which I'm not familiar with), as opposed to changes to the ION > infrastructure itself. So they won't apply to the AOSP trees, and I can't > send them upstream. > > I assume the ump code is part of the out-of-tree mali driver? Looking at > llct, I don't see a drivers/base/ump directory. > > https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking > > But I'm guessing this is the point of your original mail in this thread: we > need a mali tree upon which fixes like these can be applied and then pulled > into llct. > > Or even better, can we get the mali devs to publish a repo of their latest > work (to which fixes like Andy's can be submitted to) which can also be > pulled into llct? > > thanks > -john > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 04/13/2013 03:22 AM, Andy Green wrote: On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. Cool. Although the patches look like they are all against the ump driver(which I'm not familiar with), as opposed to changes to the ION infrastructure itself. So they won't apply to the AOSP trees, and I can't send them upstream. I assume the ump code is part of the out-of-tree mali driver? Looking at llct, I don't see a drivers/base/ump directory. https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking But I'm guessing this is the point of your original mail in this thread: we need a mali tree upon which fixes like these can be applied and then pulled into llct. Or even better, can we get the mali devs to publish a repo of their latest work (to which fixes like Andy's can be submitted to) which can also be pulled into llct? thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 13/04/13 18:22, the mail apparently from Andy Green included: On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. It can't be tested on my side atm. There's one funny, WARNING: "v7_dma_flush_range" [/projects/linaro/mali-t624/kernel/drivers/base/ump/src/ump.ko] undefined! that does seem to still be around in arch/arm/mm/cache-v7.S, maybe it's not exported suitably or I missed the point (and perhaps someone who recognizes this kind of thing can educate me). The version we got is not Device Tree -ready either. The probe() in gpu/arm/t6xx/kbase/src/linux/mali_kbase_core_linux.c insists on platform_data. However they seems to use an accessor kbasep_get_config_value() in gpu/arm/t6xx/kbase/src/common/mali_kbase_config.c to touch that structured platform_data in a way that would make it simple to add DT support. The code doesn't conform to kernel style much, but that's not hard to fix... has anyone thought of actually upstreaming this? -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
Re: Mali-ization
On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. It can't be tested on my side atm. There's one funny, WARNING: "v7_dma_flush_range" [/projects/linaro/mali-t624/kernel/drivers/base/ump/src/ump.ko] undefined! that does seem to still be around in arch/arm/mm/cache-v7.S, maybe it's not exported suitably or I missed the point (and perhaps someone who recognizes this kind of thing can educate me). -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 clean-mali-t624.tar.gz Description: application/gzip ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
ng: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[5]: *** [/projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.o] Error 1 make[4]: *** [_module_/projects/linaro/mali-t624/kernel/drivers/base/ump/src] Error 2 make[3]: *** [sub-make] Error 2 make[2]: *** [all] Error 2 make[2]: Leaving directory `/projects/linaro/linux-2.6/panda' make[1]: *** [all] Error 2 make[1]: Leaving directory `/projects/linaro/mali-t624/kernel/drivers/base/ump/src' make: *** [all] Error 2 They don't look too horrible but having barely survived dealing with SGX in Omap, if we can make all this completely turnkey to consume we will have done a great thing, I think. I could work around the problems myself, but it seems to me this might be something that Linaro could solve centrally, dealing with it using the Androidization model - sync a Linaro repo against code drops coming from "upstream", ie, ARM, but keep it always building against llct inbetween. Perhaps even inside llct. The idea of having a mali-ization tree sounds like a reasonable approach. That said, if there are any patches against the ION code needed, I'd be interested in seeing them. Right now is a particularly good time for getting Android dependent patches into AOSP, as linux-linaro isn't very far from the latest AOSP branch, and we've had some good success here over the last week or so. I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. FYI if I disabled ION (but actually, we try to have one kernel for vanilla and android with android all on) CC [M] /projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_js_policy_cfs.o /projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_js_policy_cfs.c: In function ‘kbasep_js_policy_init_ctx’: /projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_js_policy_cfs.c:910:35: error: ‘MAX_RT_PRIO’ undeclared (first use in this function) /projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_js_policy_cfs.c:910:35: note: each undeclared identifier is reported only once for each function it appears in make[5]: *** [/projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_js_policy_cfs.o] Error 1 So there are probably a few more little rottings. -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
Re: Mali-ization
On 04/12/2013 05:34 PM, Andy Green wrote: Hi - At the moment the Mali T624 OOT module sources I have do not build against 3.9-rcX / linux-linaro-core-tracking. A colleague checked it and it does build against 3.4. The problems I saw are around ION compatibility but they didn't look tremendously bad. Any details on what the ION compatibility issues are? I could work around the problems myself, but it seems to me this might be something that Linaro could solve centrally, dealing with it using the Androidization model - sync a Linaro repo against code drops coming from "upstream", ie, ARM, but keep it always building against llct inbetween. Perhaps even inside llct. The idea of having a mali-ization tree sounds like a reasonable approach. That said, if there are any patches against the ION code needed, I'd be interested in seeing them. Right now is a particularly good time for getting Android dependent patches into AOSP, as linux-linaro isn't very far from the latest AOSP branch, and we've had some good success here over the last week or so. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Mali-ization
Hi - At the moment the Mali T624 OOT module sources I have do not build against 3.9-rcX / linux-linaro-core-tracking. A colleague checked it and it does build against 3.4. The problems I saw are around ION compatibility but they didn't look tremendously bad. I could work around the problems myself, but it seems to me this might be something that Linaro could solve centrally, dealing with it using the Androidization model - sync a Linaro repo against code drops coming from "upstream", ie, ARM, but keep it always building against llct inbetween. Perhaps even inside llct. I know we're not the only LT in this boat, Anmar mentioned Arndale acceleration is pending, a central Mali-ization tree will also solve that, especially if it's always there and always building in llct already. There may be stuff to take care about for support for different IP revision. But there aren't that many AFAIK. How does this sound to folks? -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
