Hello All
ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release.
For those people maintaining kernel trees here is what this means...
- If your kernels are including the linux-linaro-core-tracking [2] branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release.
- For Ubuntu kernels not including linux-linaro-core-tracking (and not being released from the common linux-linaro branch) then you should replace your existing gator topic branch (or add one if it is missing). This new topic branch can be created by pulling from the ARM Landing Team's tree [3], we have tree topic branches available for the last three kernel versions...
tracking-armlt-gator (3.4-rc7) 3.3-armlt-gator-5.10 3.2-armlt-gator-5.10
The code in these branches is identical, they are just rebased onto different Linux versions to make pulling easier.
- For Android kernels, if your kernel already includes the Gator topic, then this should be updated as above. If it doesn't already have Gator then you can add this topic now, or, leave it for the time being. (Some Android builds are using a separate Gator git repo in their manifest and this will continue to work for now.)
If anyone has any questions or if anything is unclear, please do hesitate to contact me.
For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK.
Cheers
Thanks for the heads up Tixy. Adding Amit, Anmar and Usman.
On 16 May 2012 10:58, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Hello All
ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release.
For those people maintaining kernel trees here is what this means...
- If your kernels are including the linux-linaro-core-tracking [2]
branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release.
- For Ubuntu kernels not including linux-linaro-core-tracking (and not
being released from the common linux-linaro branch) then you should replace your existing gator topic branch (or add one if it is missing). This new topic branch can be created by pulling from the ARM Landing Team's tree [3], we have tree topic branches available for the last three kernel versions...
tracking-armlt-gator (3.4-rc7) 3.3-armlt-gator-5.10 3.2-armlt-gator-5.10
The code in these branches is identical, they are just rebased onto different Linux versions to make pulling easier.
- For Android kernels, if your kernel already includes the Gator topic,
then this should be updated as above. If it doesn't already have Gator then you can add this topic now, or, leave it for the time being. (Some Android builds are using a separate Gator git repo in their manifest and this will continue to work for now.)
If anyone has any questions or if anything is unclear, please do hesitate to contact me.
For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK.
Cheers
-- Tixy
[1] Gator is the ARM target device components for ARM's Streamline Performance Analyzer which is part of their Developer Studio (DS-5). http://www.arm.com/products/tools/software-tools/ds-5/streamline.php
[2] http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git%3Ba=shortlog...
[3] git://git.linaro.org/landing-teams/working/arm/kernel.git
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 16/05/12 23:58, Somebody in the thread at some point said:
Hi -
ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release.
For those people maintaining kernel trees here is what this means...
- If your kernels are including the linux-linaro-core-tracking [2]
branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release.
I suspect we'll be issuing tilt-3.3 again, so even though we're on llct for tracking we'll have to revert and update.
For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK.
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. Presumably that then needs coordination about matching userlands in multiple LTs which will need some time. Even if Mali is in good sync today between multiple LTs the architecture of each LT having their own copy of what's meant to be permanently in sync invites problems.
-Andy
On 05/17/2012 05:12 AM, Andy Green wrote:
On 16/05/12 23:58, Somebody in the thread at some point said:
Hi -
ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release.
For those people maintaining kernel trees here is what this means...
- If your kernels are including the linux-linaro-core-tracking [2]
branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release.
I suspect we'll be issuing tilt-3.3 again, so even though we're on llct for tracking we'll have to revert and update.
For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK.
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. Presumably that then needs coordination about matching userlands in multiple LTs which will need some time. Even if Mali is in good sync today between multiple LTs the architecture of each LT having their own copy of what's meant to be permanently in sync invites problems.
True, Mali driver code should move to core part. As of now, Samsung LT is maintaining a version of it, which was part of linux-linaro-2012.04 release.
-Andy
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.
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.
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
On 17 May 2012 08:37, Jon Medhurst (Tixy) tixy@linaro.org wrote:
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
I am fully agree with this. Is there any plan to push ARM driver into the mainline ?
to converge code-lines between teams. Especially when engineering resources are spread so thin.
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.
-- Tixy
On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote:
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?).
Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM).
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.
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.
It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant.
Scott
On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambrough@linaro.org wrote:
On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote:
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?).
Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM).
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.
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.
It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant.
Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack.
cheers, Jesse
Scott
-- Scott Bambrough Technical Director, Member Services Linaro Ltd.
On 17/05/12 21:26, Somebody in the thread at some point said:
On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambrough@linaro.org wrote:
On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote:
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?).
Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM).
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.
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.
It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant.
Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack.
What does this mean for the unified kernel effort then?
We should attempt to unify kernels excluding Mali, or we should wrap or capture the differences in Mali?
Is there anything that the unified kernel effort can do (I mean in terms of slotting things in llct and the like) that can converge with where UMM-uber-alles is headed?
-Andy
On Thu, May 17, 2012 at 3:33 PM, Andy Green andy.green@linaro.org wrote:
On 17/05/12 21:26, Somebody in the thread at some point said:
On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambrough@linaro.org wrote:
On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote:
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?).
Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM).
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.
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.
It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant.
Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack.
What does this mean for the unified kernel effort then?
We should attempt to unify kernels excluding Mali, or we should wrap or capture the differences in Mali?
Is there anything that the unified kernel effort can do (I mean in terms of slotting things in llct and the like) that can converge with where UMM-uber-alles is headed?
Naive question alert...
If the Mali driver is an out-of-tree module, does it matter?
cheers, Jesse
-Andy
-- Andy Green | TI 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
On 17/05/12 22:44, Somebody in the thread at some point said:
On Thu, May 17, 2012 at 3:33 PM, Andy Greenandy.green@linaro.org wrote:
On 17/05/12 21:26, Somebody in the thread at some point said:
On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambrough@linaro.org wrote:
On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote:
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?).
Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM).
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.
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.
It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant.
Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack.
What does this mean for the unified kernel effort then?
We should attempt to unify kernels excluding Mali, or we should wrap or capture the differences in Mali?
Is there anything that the unified kernel effort can do (I mean in terms of slotting things in llct and the like) that can converge with where UMM-uber-alles is headed?
Naive question alert...
If the Mali driver is an out-of-tree module, does it matter?
Last time I looked in Dec, it and its lovely symlinks were in-tree.
Who are you asking "does it matter" to? If you are asking, does it help the unified kernel effort, sure, OOT module succeeds to hide the poop.
In the larger sense of Linaro's legacy, meaning, value...
-Andy
-
Andy Green -
Jesse Barker -
Jon Medhurst (Tixy) -
Sangwook Lee -
Scott Bambrough -
Tushar Behera -
Zach Pfeffer