Re: Suggestion
On 04/28/2013 06:18 AM, Mark Brown wrote: On Wed, Apr 17, 2013 at 09:14:54AM -0400, Christopher Covington wrote: On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote: And with gerrit the patch author needs to get an account enabled with the project, produce a git commit against the current tip, I can't recall ever seeing an upload refused because it wasn't against the latest commit. What's the error message you get? Or is it possible that you might be misremembering such an incident? This is a configuration option within gerrit - you can set a repository or branch up to be fast forward only. I'm familiar with a submit- or merge-time option for this. It's not clear to me from your reply whether you're referring to this or an upload- or push-time option. Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On 04/29/2013 09:28 AM, Christopher Covington wrote: On 04/28/2013 06:18 AM, Mark Brown wrote: On Wed, Apr 17, 2013 at 09:14:54AM -0400, Christopher Covington wrote: On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote: And with gerrit the patch author needs to get an account enabled with the project, produce a git commit against the current tip, I can't recall ever seeing an upload refused because it wasn't against the latest commit. What's the error message you get? Or is it possible that you might be misremembering such an incident? This is a configuration option within gerrit - you can set a repository or branch up to be fast forward only. I'm familiar with a submit- or merge-time option for this. It's not clear to me from your reply whether you're referring to this or an upload- or push-time option. Ohhh. In talking about Gerrit I assumed a workflow that used code review, but in the case where review is bypassed and one pushes to refs/heads/$branch instead of refs/for/$branch, it makes total sense for the restrictions that are seen from the code review workflow when you hit the submit button to applied to pushes/uploads. Sorry for my confusion. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On Mon, Apr 29, 2013 at 09:28:16AM -0400, Christopher Covington wrote: I'm familiar with a submit- or merge-time option for this. It's not clear to me from your reply whether you're referring to this or an upload- or push-time option. Oh, on initial push? I've not seen that but it does strike me that it would be somewhat useful in avoiding frustration from things not merging later on - at least you know there was a chance that the change could've been merged. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
With gerrit have the ability to pull patch sets build and test. On Apr 29, 2013 10:04 PM, Mark Brown broo...@sirena.org.uk wrote: On Mon, Apr 29, 2013 at 09:28:16AM -0400, Christopher Covington wrote: I'm familiar with a submit- or merge-time option for this. It's not clear to me from your reply whether you're referring to this or an upload- or push-time option. Oh, on initial push? I've not seen that but it does strike me that it would be somewhat useful in avoiding frustration from things not merging later on - at least you know there was a chance that the change could've been merged. ___ 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: Suggestion
On Wed, Apr 17, 2013 at 09:14:54AM -0400, Christopher Covington wrote: On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote: And with gerrit the patch author needs to get an account enabled with the project, produce a git commit against the current tip, I can't recall ever seeing an upload refused because it wasn't against the latest commit. What's the error message you get? Or is it possible that you might be misremembering such an incident? This is a configuration option within gerrit - you can set a repository or branch up to be fast forward only. This is frequently done for kernels as it's relatively easy for a change in one part of the code base to interact with changes in another part (especially board changes interacting with the drivers they instantiate) so the theory is that this will force all the verification to be done with exactly the tree that ends up in gerrit. Obviously there's a tradeoff here with the rebases. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On Wed, Apr 17, 2013 at 6:21 AM, Jonathan Aquilina eagles051...@gmail.com wrote: Doesnt email run the risk of a patch slipping through the cracks? as highlighted by Deepak above, each project will use the processes/methods inherited from its 'upstream'. That's why gerrit is being used for Android activities for example. many successful open source projects are using solely email for patch submission and review, and that happens to work fine. yes, that makes lots of emails, and patches can be lost, but the general rule is that it's up to the patch author to follow-up and potentially resubmit when such things happen. for example, the Linux kernel documentation says this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v3.9-rc7#n262 nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
Totally under stand :). Hopefully come summer I will be able to get my hands on a board and start contributing :) On Wed, Apr 17, 2013 at 9:51 AM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Wed, Apr 17, 2013 at 6:21 AM, Jonathan Aquilina eagles051...@gmail.com wrote: Doesnt email run the risk of a patch slipping through the cracks? as highlighted by Deepak above, each project will use the processes/methods inherited from its 'upstream'. That's why gerrit is being used for Android activities for example. many successful open source projects are using solely email for patch submission and review, and that happens to work fine. yes, that makes lots of emails, and patches can be lost, but the general rule is that it's up to the patch author to follow-up and potentially resubmit when such things happen. for example, the Linux kernel documentation says this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v3.9-rc7#n262 nicolas -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On Wed, 2013-04-17 at 06:21 +0200, Jonathan Aquilina wrote: Doesnt email run the risk of a patch slipping through the cracks? And with gerrit the patch author needs to get an account enabled with the project, produce a git commit against the current tip, know who to pick as reviewers then rely on the people they pick to actually review the patch, then rebase and resubmit the patch because the tip has moved during the review process and then have someone with commit rights accept it. And the web interface is horrible. You may have guessed I'm not a fan ;-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
Hi Jon, On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote: On Wed, 2013-04-17 at 06:21 +0200, Jonathan Aquilina wrote: Doesnt email run the risk of a patch slipping through the cracks? And with gerrit the patch author needs to get an account enabled with the project, produce a git commit against the current tip, I can't recall ever seeing an upload refused because it wasn't against the latest commit. What's the error message you get? Or is it possible that you might be misremembering such an incident? know who to pick as reviewers then rely on the people they pick to actually review the patch I fail to see how emailing patches approaches this problem any differently. then rebase and resubmit the patch because the tip has moved during the review process Perhaps it is a small fault of the software that the configuration doesn't default to an easier-going merge method such as cherry picking. It's really easy to change, though. Admin-Projects-NAME-Project Options-Cherry Pick. It seems like emailed patches have their fair share of merge conflicts. and then have someone with commit rights accept it. I fail to see how emailing patches approaches this problem any differently. And the web interface is horrible. What's your preferred intraline diff application? You may have guessed I'm not a fan ;-) I don't necessarily think Linaro needs more Gerrit, but I would hate to see misunderstandings about software that's been good to me go uncorrected. Cheers, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
I have seen gerrit in use with libreoffice, they have it setup to where you have build bot machines which can automatically pull a patch make a build and test the patch with the build to see if it builds successfully. Also, with gerrit you dont need to assign reviewers people that have the ability and access can assign themselves to a particular patch to test. On Wed, Apr 17, 2013 at 3:55 PM, Jon Medhurst (Tixy) t...@linaro.orgwrote: On Wed, 2013-04-17 at 09:14 -0400, Christopher Covington wrote: Hi Jon, On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote: On Wed, 2013-04-17 at 06:21 +0200, Jonathan Aquilina wrote: Doesnt email run the risk of a patch slipping through the cracks? And with gerrit the patch author needs to get an account enabled with the project, produce a git commit against the current tip, I can't recall ever seeing an upload refused because it wasn't against the latest commit. What's the error message you get? Can't remember, sorry. Or is it possible that you might be misremembering such an incident? know who to pick as reviewers then rely on the people they pick to actually review the patch I fail to see how emailing patches approaches this problem any differently. It doesn't. then rebase and resubmit the patch because the tip has moved during the review process Perhaps it is a small fault of the software that the configuration doesn't default to an easier-going merge method such as cherry picking. It's really easy to change, though. Admin-Projects-NAME-Project Options-Cherry Pick. It seems like emailed patches have their fair share of merge conflicts. and then have someone with commit rights accept it. I fail to see how emailing patches approaches this problem any differently. It doesn't. And the web interface is horrible. What's your preferred intraline diff application? Not just diff, also how you comment on changes and reply to them. Email is much nicer. You may have guessed I'm not a fan ;-) I don't necessarily think Linaro needs more Gerrit, but I would hate to see misunderstandings about software that's been good to me go uncorrected. And I wasn't particularly trying to imply mailing lists solve problems that Gerrit fails to, just that Gerrit adds hurdles and awkwardness - especially for occasional contributors - and it seems to add little benefit for that extra pain. You could say it keeps track of changes and avoid them getting lost, but that only works if someone actually chases up neglected changes. And mailing lists can use something like Patchwork if they want similar tracking. I'm sure if I worked regularly on a project which used Gerrit then I would get use to it and work out the tricks. Cheers -- Tixy Cheers, Christopher -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Suggestion
Have you guys considered gerrit code review for patches? as well as setting up build bots to test build the patches? -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On Tue, Apr 16, 2013 at 3:59 PM, Jonathan Aquilina eagles051...@gmail.com wrote: Have you guys considered gerrit code review for patches? as well as setting up build bots to test build the patches? which projects at Linaro you have in mind for this request? it's already being used for Android 'stuff', see http://review.android.git.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
Wouldnt all of them benefit in a way from it? On Tue, Apr 16, 2013 at 4:04 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Tue, Apr 16, 2013 at 3:59 PM, Jonathan Aquilina eagles051...@gmail.com wrote: Have you guys considered gerrit code review for patches? as well as setting up build bots to test build the patches? which projects at Linaro you have in mind for this request? it's already being used for Android 'stuff', see http://review.android.git.linaro.org/ -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On 16 April 2013 07:06, Jonathan Aquilina eagles051...@gmail.com wrote: Wouldnt all of them benefit in a way from it? My take on this is that one of the goals of Linaro's assignee process is to teach folks how to work in the open source community and than take that knowledge back to internal teams. This means we should use communication methods and tools that are native to the upstream communities we interact with and in the case of the kernel, this means that code review should be done via email lists. ~Deepak On Tue, Apr 16, 2013 at 4:04 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Tue, Apr 16, 2013 at 3:59 PM, Jonathan Aquilina eagles051...@gmail.com wrote: Have you guys considered gerrit code review for patches? as well as setting up build bots to test build the patches? which projects at Linaro you have in mind for this request? it's already being used for Android 'stuff', see http://review.android.git.linaro.org/ -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
Doesnt email run the risk of a patch slipping through the cracks? On Tue, Apr 16, 2013 at 9:02 PM, Deepak Saxena dsax...@linaro.org wrote: On 16 April 2013 07:06, Jonathan Aquilina eagles051...@gmail.com wrote: Wouldnt all of them benefit in a way from it? My take on this is that one of the goals of Linaro's assignee process is to teach folks how to work in the open source community and than take that knowledge back to internal teams. This means we should use communication methods and tools that are native to the upstream communities we interact with and in the case of the kernel, this means that code review should be done via email lists. ~Deepak On Tue, Apr 16, 2013 at 4:04 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Tue, Apr 16, 2013 at 3:59 PM, Jonathan Aquilina eagles051...@gmail.com wrote: Have you guys considered gerrit code review for patches? as well as setting up build bots to test build the patches? which projects at Linaro you have in mind for this request? it's already being used for Android 'stuff', see http://review.android.git.linaro.org/ -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
On 18 February 2013 23:50, Serge Broslavsky serge.broslav...@linaro.org wrote: On 18.02.13 12:20 -0500, Nicolas Pitre wrote: For the record, I think what Peter is suggesting is reasonable. There must be better ways for people to find out what Linaro is participating in other than scaring them away from linaro-dev when they have no interest in the patch details. I second that. Any consensus on this? I have already stated mailing to people (who send their patches to linaro-dev) to use linaro-kernel. :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
On Thu, Feb 21, 2013 at 4:27 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On 18 February 2013 23:50, Serge Broslavsky serge.broslav...@linaro.org wrote: On 18.02.13 12:20 -0500, Nicolas Pitre wrote: For the record, I think what Peter is suggesting is reasonable. There must be better ways for people to find out what Linaro is participating in other than scaring them away from linaro-dev when they have no interest in the patch details. I second that. Any consensus on this? I have already stated mailing to people (who send their patches to linaro-dev) to use linaro-kernel. :) I don't have a strong preference one way or another about switching from linaro-dev to linaro-kernel. Don't forget to update https://wiki.linaro.org/Resources/HowTo/Git/GitSendEmail /Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
On 21 February 2013 16:34, Amit Kucheria amit.kuche...@linaro.org wrote: I don't have a strong preference one way or another about switching from linaro-dev to linaro-kernel. Don't forget to update https://wiki.linaro.org/Resources/HowTo/Git/GitSendEmail Done. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
suggestion: move kernel patches off linaro-dev
Hi; does anybody else think it would be a good idea to move all the kernel patch email traffic off linaro-dev and onto a more kernel-specific mailing list (eg, linaro-kernel, maybe) ? A quick eyeball of a few pages of my gmail folder for linaro-dev shows that something like 75% of it is kernel devs patchbombing the list. You don't see huge floods of patches here for gcc or QEMU or any of the many other projects Linaro contributes to, so why all the kernel patches? I think that moving these off to their own list would allow those who have a genuine interest in kernel internals to read and review these patches, and reduce the noise level on this (Linaro's most generic list) for everybody else. NB: I'm not suggesting no kernel discussion here; I just would like actual patchmail to go elsewhere... thanks -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
Since Peter and I were discussing this on IRC that led to this email, here is a bit of context on the current behaviour: On Mon, Feb 18, 2013 at 8:16 PM, Peter Maydell peter.mayd...@linaro.org wrote: Hi; does anybody else think it would be a good idea to move all the kernel patch email traffic off linaro-dev and onto a more kernel-specific mailing list (eg, linaro-kernel, maybe) ? A quick eyeball of a few pages of my gmail folder for linaro-dev shows that something like 75% of it is kernel devs patchbombing the list. You don't see huge floods of patches here for gcc or QEMU or any of the many other projects Linaro contributes to, so why all the kernel patches? linaro-dev was supposed to be how we kept track of all development activity that Linaro was involved in - it wasn't supposed to be restricted only to kernel. IOW, someone could subscribe to this one list to find out everything that Linaro was participating in. So much so that it was baked into our guidelines for how to use git to send patches to upstream projects[1] Admittedly, those were early days and our contributions to upstream projects have grown significantly since then. So it might be time to revisit that policy. I think that moving these off to their own list would allow those who have a genuine interest in kernel internals to read and review these patches, and reduce the noise level on this (Linaro's most generic list) for everybody else. NB: I'm not suggesting no kernel discussion here; I just would like actual patchmail to go elsewhere... thanks -- PMM [1] https://wiki.linaro.org/Resources/HowTo/Git/GitSendEmail ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
On Mon, 18 Feb 2013, Amit Kucheria wrote: Since Peter and I were discussing this on IRC that led to this email, here is a bit of context on the current behaviour: On Mon, Feb 18, 2013 at 8:16 PM, Peter Maydell peter.mayd...@linaro.org wrote: Hi; does anybody else think it would be a good idea to move all the kernel patch email traffic off linaro-dev and onto a more kernel-specific mailing list (eg, linaro-kernel, maybe) ? A quick eyeball of a few pages of my gmail folder for linaro-dev shows that something like 75% of it is kernel devs patchbombing the list. You don't see huge floods of patches here for gcc or QEMU or any of the many other projects Linaro contributes to, so why all the kernel patches? linaro-dev was supposed to be how we kept track of all development activity that Linaro was involved in - it wasn't supposed to be restricted only to kernel. IOW, someone could subscribe to this one list to find out everything that Linaro was participating in. So much so that it was baked into our guidelines for how to use git to send patches to upstream projects[1] Admittedly, those were early days and our contributions to upstream projects have grown significantly since then. So it might be time to revisit that policy. I think that moving these off to their own list would allow those who have a genuine interest in kernel internals to read and review these patches, and reduce the noise level on this (Linaro's most generic list) for everybody else. NB: I'm not suggesting no kernel discussion here; I just would like actual patchmail to go elsewhere... For the record, I think what Peter is suggesting is reasonable. There must be better ways for people to find out what Linaro is participating in other than scaring them away from linaro-dev when they have no interest in the patch details. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
On 18.02.13 12:20 -0500, Nicolas Pitre wrote: On Mon, 18 Feb 2013, Amit Kucheria wrote: Since Peter and I were discussing this on IRC that led to this email, here is a bit of context on the current behaviour: On Mon, Feb 18, 2013 at 8:16 PM, Peter Maydell peter.mayd...@linaro.org wrote: Hi; does anybody else think it would be a good idea to move all the kernel patch email traffic off linaro-dev and onto a more kernel-specific mailing list (eg, linaro-kernel, maybe) ? A quick eyeball of a few pages of my gmail folder for linaro-dev shows that something like 75% of it is kernel devs patchbombing the list. You don't see huge floods of patches here for gcc or QEMU or any of the many other projects Linaro contributes to, so why all the kernel patches? linaro-dev was supposed to be how we kept track of all development activity that Linaro was involved in - it wasn't supposed to be restricted only to kernel. IOW, someone could subscribe to this one list to find out everything that Linaro was participating in. So much so that it was baked into our guidelines for how to use git to send patches to upstream projects[1] Admittedly, those were early days and our contributions to upstream projects have grown significantly since then. So it might be time to revisit that policy. I think that moving these off to their own list would allow those who have a genuine interest in kernel internals to read and review these patches, and reduce the noise level on this (Linaro's most generic list) for everybody else. NB: I'm not suggesting no kernel discussion here; I just would like actual patchmail to go elsewhere... For the record, I think what Peter is suggesting is reasonable. There must be better ways for people to find out what Linaro is participating in other than scaring them away from linaro-dev when they have no interest in the patch details. I second that. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Best Regards, Serge Broslavsky serge.broslav...@linaro.org Project Manager, Linaro M: +37129426328 IRC: ototo Skype: serge.broslavsky http://linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: request/suggestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation
On Sat, October 22, 2011 3:52 pm, Konstantinos Margaritis wrote: On 22 October 2011 16:17, Joop Boonen joop.boo...@boonen.org wrote: Hi all, Most of the (ARM) distros are currently working on or in the transition to hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any hardfp drivers yet. To be able to have a ARM hardfp compiled X Window desktop system/notebook with 3D support we need hardfp compiled drivers. I was thinking it might be more efficient is all Linux distro's work together to get these drivers as it's equally important for all distro that wants to move to a hardfp distro. What do you all think, who wants to work together to get full hardfp support for as most as possible ARM SOC GPUs? It would be great if we can in the end even have OSS drivers. Hi, Nvidia was the first to release hardfp drivers for tegra2 gpus for armhf, and we also have working drivers for hardfloat for the Freescale i.MX51 and i.MX53 gpus, which we use on our current and upcoming products (Genesi Smarttop/Smartbooks). It took a lot of time and effort on our side to push for that, and obviously not for technical reasons -it was just a 5 minute recompile of a binary static library. I can imagine. I understood that the MX51 has a AMD Z430 GPU. Which has been renamed to Adreno 200 (AMD Z430), as Qualcomm bought the handheld graphics unit from AMD. http://en.wikipedia.org/wiki/Imageon So you probably have to go through FreeScale that might need approval from Qualcomm to build a hardfp driver. I understood that in the ARM SOC world the SOC producer is responsible for the video driver, which is very different from the PC world where the designer is delivers the driver (NVidia/AMD/Intel). But in the end it was worth it. We're getting 15-20% increase in performance on average -sometimes more- in our GLES benchmarks, and we're working to squeeze more performance out of that -I'm currently working on neon-optimizations in the GLES1 backend, which may not be current, but it's still used by some important and very much needed applications (i.e. quake3 :). So, the list is short right now, but that is the least of our problems. The real problem is getting all of the kernel gpu drivers into a single (mainline?Linaro?) kernel tree. The vendors are very resistant in releasing specs or source code, and the kernel guys are equally -if not more- resistant in accepting half-open/half-closed drivers into the kernel tree. I think this is de to GPL, that why they only allow open source modules for the kernel. That's also why the proprietary kernel modules for NVidia and AMD are not in the standard kernel. It's going to be a long road, but I think that eventually we're getting there, unless of course a miracle happens and all vendors simultaneously opensource their drivers :) I hope it will happen soon. It feels the time when NVidia and ATI didn't build any (3D) drivers for Linux. This slows down Linux development a lot and it'll limit that hardware you'll be able to use Linux on. Regards Konstantinos ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev Regards, Joop. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Suggestion for ARM related summits at Linaro Connect Q4.11 (co-hosted with UDS-P)
Hey all, As we're having the Linaro Connect Q4.11 together with UDS-P, would like to know if there is any special topic it'd be useful to cover as a summit there. Any ARM related topics that might be related with cross-distro collaboration or just related with Ubuntu/Debian should fit. Some suggestions: - Arm Hard Float Port - Next steps for Multiarch at Ubuntu/Debian - Ubuntu ARM images discussion (Linaro hwpacks and Ubuntu spice seeds) - Minimal image support (Ubuntu core discussions) - 3D Support at ARM (GL ES x OpenGL) I know Steve McIntyre is trying to have an ARM summit at Plumbers, so we can also propose a similar summit to continue the discussions at Connect/UDS too, depending on the feedback from Plumbers. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion for ARM related summits at Linaro Connect Q4.11 (co-hosted with UDS-P)
On Tue, Aug 30, 2011 at 9:55 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hey all, As we're having the Linaro Connect Q4.11 together with UDS-P, would like to know if there is any special topic it'd be useful to cover as a summit there. Any ARM related topics that might be related with cross-distro collaboration or just related with Ubuntu/Debian should fit. A session on live-build probably makes sense. Some suggestions: - Arm Hard Float Port - Next steps for Multiarch at Ubuntu/Debian - Ubuntu ARM images discussion (Linaro hwpacks and Ubuntu spice seeds) I'd suggest discussion around - an ARM based phone reference image of some sort. (probably a subtopic under images) - an ARM based tablet image with touch based input also pops to mind. (again probably a subtopic under images) - Minimal image support (Ubuntu core discussions) +2! - 3D Support at ARM (GL ES x OpenGL) I know Steve McIntyre is trying to have an ARM summit at Plumbers, so we can also propose a similar summit to continue the discussions at Connect/UDS too, depending on the feedback from Plumbers. Thanks, -- Ricardo Salveti de Araujo -- Regards, Tom We want great men who, when fortune frowns will not be discouraged. - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
