Re: Android libjpeg
On Thu, Jun 23, 2011 at 3:30 AM, Christian Robottom Reis k...@linaro.org wrote: Hi there, I took a look at the AOSP libjpeg code which is included in git://android.git.kernel.org/platform/external/jpeg during my flight back home (which incidentally had been diverted and landed me in Rio de Janeiro; not sure if I celebrate or cry) and noted the following things: - There is a v6 implementation of the fast IDCT algorithm which lives in armv6_idct.S. - The commit which adds this implementation was added October 2010, and there haven't been any changes since. - The code that selects the decoder IDCT implementation in jddctmgr.c always uses that implementation if ANDROID_ARMV6_IDCT is defined. - Google have an ashmem backing store implementation, and have code to enable tile-based mode. It's a fairly non-intrusive change to use ashmem since it just replaces jpeg_open_backing_store. - The code is pretty much standard libjpeg without any structural changes to it. - There isn't any NEON code in this branch. - Mans has an optimized version here: http://git.mansr.com/?p=libjpeg;a=summary I don't know if he's submitted this to AOSP or not. This suggests to me that a simple drop-in of libjpeg-turbo might be actually easy to do, and that there is probably a significant performance benefit to be achieved. One thing to keep in mind is that this code still supports armv6, so we'd probably want to preserve that. sounds good. Seems like a great starter project for MM WG to get their hands dirty on android. They could have three builds: 1. plain LEB 2. LEB with mans optimized libjpeg 3. LEB with libjpeg-turbo Then benchmark all three and keep AOSP community posted on our intent, progress and results. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro monthly release cycle
On Thu, Jun 23, 2011 at 3:20 AM, Zach Pfeffer zach.pfef...@linaro.org wrote: Or we could just use continuous integration where there are no freezes, just per change regression tests. thats the idealistic goal yes, but getting even close there takes a bit and I am not sure if full continuous integration in the sense that you can land even massive patchsets the day before release just relying on your automated tests is something that can ever happen. e.g. you will always end up with some explicit release process with some kind of restrictions on what type of change is acceptable right before the release etc. Basically as long as you ever discover any issue through manual testing that you didn't catch through automation before means you are still not ready to do full continuous integration. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: u-boot: initial support for smsc95xx and TFTP boot at Panda
Hi, I tried with the precompiled u-boot and MLO and it is working fine. But failed with the sources downloaded from the link provided. Can you please any addition settngs need to be done for the sources. I have used OMAP4_PANDA_CONFIG. You can find my WIP tree at https://gitorious.org/ubuntu-experimental/linaro-u-boot/commits/u-boot-master-tftp-panda Please comment. Regards Krishna M. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH powertop2.0] Modification to fix the removal of lock_depth field
On 6/22/2011 10:12 PM, Amit Daniel Kachhap wrote: lock_depth field is removed from the power frequency events in the new linux kernel(2.6.38 onwards). So this creates issue to retrieve the lower members of the trace data. To fix this problem 2 separate structures are created and their use depends upon the format of the power_frequency events. These changes have been tested to work fine with both old and new kernels as well as on x86 and ARM platform. eh no while it was temporarily removed in an -rc, it was added back (as padding) after it was found to break powertop (and abi). or am I missing something??? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android libjpeg
Yes, I'd think we'd want to merge the v6 support into libjpeg-turbo and verify its correct operation before trying to replace the version of libjpeg in Android. Also, v6 would need to be selected using the same mechanisms (or similar) to the ones we currently use to select NEON. I also wanted to let you guys know that I have set up a libjpeg-turbo-devel list (https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel) which can be used to submit patches to the project or talk about development topics specific to the libjpeg-turbo code. You can also use the Patch tracker on Sourceforge to submit patches and discuss them. On 6/22/11 8:30 PM, Christian Robottom Reis wrote: Hi there, I took a look at the AOSP libjpeg code which is included in git://android.git.kernel.org/platform/external/jpeg during my flight back home (which incidentally had been diverted and landed me in Rio de Janeiro; not sure if I celebrate or cry) and noted the following things: - There is a v6 implementation of the fast IDCT algorithm which lives in armv6_idct.S. - The commit which adds this implementation was added October 2010, and there haven't been any changes since. - The code that selects the decoder IDCT implementation in jddctmgr.c always uses that implementation if ANDROID_ARMV6_IDCT is defined. - Google have an ashmem backing store implementation, and have code to enable tile-based mode. It's a fairly non-intrusive change to use ashmem since it just replaces jpeg_open_backing_store. - The code is pretty much standard libjpeg without any structural changes to it. - There isn't any NEON code in this branch. - Mans has an optimized version here: http://git.mansr.com/?p=libjpeg;a=summary I don't know if he's submitted this to AOSP or not. This suggests to me that a simple drop-in of libjpeg-turbo might be actually easy to do, and that there is probably a significant performance benefit to be achieved. One thing to keep in mind is that this code still supports armv6, so we'd probably want to preserve that. Thanks! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Wed, Jun 22, 2011 at 11:16 PM, James Westby james.wes...@linaro.org wrote: On Tue, 21 Jun 2011 09:04:41 +, Fathi Boudra fathi.bou...@linaro.org wrote: If not, what are the blockers to doing so? Today, the builders are unstable. They have just had new hard disk enclosures added, and should be more stable now. Let's monitor for a few days and see if they are more stable. On what day should we re-assess the situation and make another go/no-go call? can we somehow smoke test the infrastructure continuously till tomorrow and then reassess tomorrow afternoon? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] U300 and Ux500 patches for the arm-soc tree
On Tue, Jun 21, 2011 at 11:39 AM, Linus Walleij linus.wall...@linaro.org wrote: These are a number of trivial-and-simple patches that have been reviewed on the LAKML mailing list. They are independent patches that are mostly self-descriptive. Not much seems to happen in the arm-soc tree so I'm reiterating the pull request, putting last weeks patches for section misses in the compilation and the Snowball support patch set redux on top of the stuff previously included: The following changes since commit 56299378726d5f2ba8d3c8cbbd13cb280ba45e4f: Linux 3.0-rc4 (2011-06-20 20:25:46 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git for-arnd [Mirrors seem slow, try the ssh:// to the server to get the latest branch if you need it immediately, it'll be there in a few hours I guess] Linus Walleij (8): mach-ux500: add HREFv60 Kconfig option mach-ux500: fix HREFv60 regression mach-ux500: correct MMC/SDI parameters mach-ux500: activate USB in the U8500 defconfig mach-ux500: complete regulator constraints for MOP500 board mach-u300: cleanup clockevent code mach-u300: set apropriate FIFO trigger levels mach-ux500: register a clock for the SMP TWD Mathieu J. Poirier (3): mach-ux500: setting proper uart for snowball mach-ux500: Add SDI support for snowball board mach-ux500: Kconfig for snowball board Mattias Wallin (1): mach-ux500: iomap PRCMU TCDM memory Robert Marklund (4): mach-x500: fix SECTION warnings in uib mach-ux500: add basic support for snowball board mach-ux500: Add pin configuration for snowball board mach-ux500: add configs for snowball board arch/arm/configs/u8500_defconfig | 32 -- arch/arm/mach-u300/spi.c |4 +- arch/arm/mach-u300/timer.c| 33 ++ arch/arm/mach-ux500/Kconfig | 15 +++- arch/arm/mach-ux500/board-mop500-pins.c | 43 +++ arch/arm/mach-ux500/board-mop500-regulators.c |9 ++- arch/arm/mach-ux500/board-mop500-sdi.c| 61 +++--- arch/arm/mach-ux500/board-mop500-uib.c|2 +- arch/arm/mach-ux500/board-mop500.c| 154 +++-- arch/arm/mach-ux500/board-mop500.h|5 + arch/arm/mach-ux500/clock.c | 48 arch/arm/mach-ux500/cpu-db5500.c |1 + arch/arm/mach-ux500/include/mach/uncompress.h |3 +- 13 files changed, 350 insertions(+), 60 deletions(-) Thanks, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Patches from the Linaro Android Team team
On Wed, Jun 22, 2011 at 1:51 PM, Guilherme Salgado guilherme.salg...@linaro.org wrote: Hi Jim, (I'm CCing linaro-dev@ because I figure others might have similar questions) This is because the android patches are going to the 'Unknown' project[1], which is ignored when generating the statistics[2]. We currently can't automatically detect the correct project for such patches because they are all sent to linaro-dev@ instead of their own mailing list like other projects. Maybe we could try and detect the correct project from the subject's prefix (e.g. [android/bionic]), but even then I suspect these patches are not really going to AOSP, in which case they wouldn't be included in the statistics either (much like the gcc-linaro and linaro-kernel projects). If I'm mistaken we can just create android projects and move the patches from the Unknown project to them. A thread I started recently (Subject: Please help us setup patches.linaro.org) on linaro-dev@ has more information on how to do that. I thought we had worked out a special way how to ensure that patches that go to upstream gerrit get considered? Or was that just discussion that we still have to finish? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Thu, Jun 23, 2011 at 12:44 PM, Fathi Boudra fathi.bou...@linaro.org wrote: On 23 June 2011 10:06, Alexander Sack a...@linaro.org wrote: On Wed, Jun 22, 2011 at 11:16 PM, James Westby james.wes...@linaro.org wrote: On Tue, 21 Jun 2011 09:04:41 +, Fathi Boudra fathi.bou...@linaro.org wrote: If not, what are the blockers to doing so? Today, the builders are unstable. They have just had new hard disk enclosures added, and should be more stable now. Let's monitor for a few days and see if they are more stable. On what day should we re-assess the situation and make another go/no-go call? can we somehow smoke test the infrastructure continuously till tomorrow and then reassess tomorrow afternoon? we can stress the system by increasing the build cadence (temporary modify the daily build cron to trigger a build every 3h). couldn't we inject a big amount of test builds in the queue to achieve full utilization for 24 or 48 hours or so? of course, queuing them as low priority so they don't make our real builds the cycles. Lets see what james says ;). -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Switch to ubuntu-build.linaro.org
On Thu, 23 Jun 2011 14:28:42 +0200, Alexander Sack a...@linaro.org wrote: couldn't we inject a big amount of test builds in the queue to achieve full utilization for 24 or 48 hours or so? of course, queuing them as low priority so they don't make our real builds the cycles. Lets see what james says ;). We can do that, but it's easier for us to just let cron do it. There's no facility that I know of for priority in the build queue. We should be careful not to fill up the disk space by trying to do too many builds at once. Fathi, have you got anywhere on defining the build retention policy? If so we could implement that at the same time to free up some disk space. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Patches from the Linaro Android Team team
On Thu, 23 Jun 2011 14:25:18 +0200, Alexander Sack a...@linaro.org wrote: I thought we had worked out a special way how to ensure that patches that go to upstream gerrit get considered? Or was that just discussion that we still have to finish? No, we didn't agree to complete something like that at this time and so didn't implement anything. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 00/11] mmc: use nonblock mmc requests to minimize latency
On Tue, Jun 21, 2011 at 11:26:27AM +0200, Per Forlin wrote: Here are the results. It looks like this patch is either a no-op or slightly worse. As people have been telling me that dsb is rather expensive, and this patch results in less dsbs, I'm finding these results hard to believe. It seems to be saying that dsb is an effective no-op on your platform. So either people are wrong about dsb being expensive, the patch is wrong, or there's something wrong with these results/test method. You do have an error in the ported patch, as that hasn't updated the v7 cache cleaning code to remove the dsb() there, but that would only affect the write tests. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android libjpeg
On 23/06/11 11:30, Alexander Sack wrote: sounds good. Seems like a great starter project for MM WG to get their hands dirty on android. They could have three builds: 1. plain LEB 2. LEB with mans optimized libjpeg 3. LEB with libjpeg-turbo Then benchmark all three and keep AOSP community posted on our intent, progress and results. Hi folks since we have been busy to get the public plan review material going, this deliverable to Android AOSP will not make it for 11.06 under the current pressure of time. Pending Kurt and Mandeep saying otherwise, we will aim for this to happen in 11.07 Many thanks, -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH android/bionic] strftime: Use snprintf() instead of sprintf()
Merged in AOSP: http://android.git.kernel.org/?p=platform/bionic.git;a=commitdiff;h=e6cff939e603e445c2576958c3777d7b7f5d84fa On 22 June 2011 16:48, Jim Huang jim.hu...@linaro.org wrote: Code Review: https://review.source.android.com/#change,23997 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
problem with todays linux-linaro-2.6.39 and THUMB2 kernel
Nicolas, Dave, make omap4_defconfig make menuconfig and turn on THUMB2_KERNEL make . CC arch/arm/kernel/smp_twd.o CC arch/arm/kernel/machine_kexec.o AS arch/arm/kernel/relocate_kernel.o arch/arm/kernel/relocate_kernel.S: Assembler messages: arch/arm/kernel/relocate_kernel.S:10: Error: invalid offset, value too big (0xFFFC) arch/arm/kernel/relocate_kernel.S:11: Error: invalid offset, value too big (0xFFFC) arch/arm/kernel/relocate_kernel.S:58: Error: invalid offset, value too big (0xFFFC) arch/arm/kernel/relocate_kernel.S:59: Error: invalid offset, value too big (0xFFFC) make[1]: *** [arch/arm/kernel/relocate_kernel.o] Error 1 make: *** [arch/arm/kernel] Error 2 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with todays linux-linaro-2.6.39 and THUMB2 kernel
I thought this was new but it has been around for awhile. My default config was not turning on THUMB2 kernel so I only saw it today. On Thu, Jun 23, 2011 at 9:12 AM, John Rigby john.ri...@linaro.org wrote: Nicolas, Dave, make omap4_defconfig make menuconfig and turn on THUMB2_KERNEL make . CC arch/arm/kernel/smp_twd.o CC arch/arm/kernel/machine_kexec.o AS arch/arm/kernel/relocate_kernel.o arch/arm/kernel/relocate_kernel.S: Assembler messages: arch/arm/kernel/relocate_kernel.S:10: Error: invalid offset, value too big (0xFFFC) arch/arm/kernel/relocate_kernel.S:11: Error: invalid offset, value too big (0xFFFC) arch/arm/kernel/relocate_kernel.S:58: Error: invalid offset, value too big (0xFFFC) arch/arm/kernel/relocate_kernel.S:59: Error: invalid offset, value too big (0xFFFC) make[1]: *** [arch/arm/kernel/relocate_kernel.o] Error 1 make: *** [arch/arm/kernel] Error 2 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: ST-E STM Driver Review
Hi Doug,
I can set up a voice bridge to get discussion rolling - let me know if
following schedule suits all ('have tried to keep various TZ in mind)
24/June/2011, 15:30 GMT
Best regards,
Arvind
From: Deao, Douglas [mailto:d-d...@ti.com]
Sent: Wednesday, June 22, 2011 4:58 AM
To: Philippe Langlais; Arvind Chauhan
Cc: Linus Walleij; Lee Jones; Michael Hope; linaro-dev@lists.linaro.org;
pierre.peif...@stericsson.com; loic.palla...@stericsson.com
Subject: RE: ST-E STM Driver Review
Please find attached the first few sections. I have not spent any time on
formatting, but this should be enough to get us talking about requirements.
Let me know what you think.
Thanks,
Doug
From: Philippe Langlais [mailto:philippe.langl...@linaro.org]
Sent: Tuesday, June 21, 2011 3:06 AM
To: Arvind Chauhan
Cc: Deao, Douglas; Linus Walleij; Lee Jones; Michael Hope;
linaro-dev@lists.linaro.org; pierre.peif...@stericsson.com;
loic.palla...@stericsson.com
Subject: Re: ST-E STM Driver Review
Hi,
As stated by Douglas, a character driver is more natural for a printf like
usage,
therefore we need a mean to do packetizing (with optional OST header: can be
supported by generic functions in kernel hw tracing framework).
My current implementation use only one device node (/dev/stm) for all STM
channels (no minor256 restriction even for STM v2.0), each open+write on
this device node allocate dynamically a new channel and IOCTLs
are available to retrieve channel number.
This driver covers low level interface too (direct write with no overhead from
1 to 8 bytes with mmap +
IOCTLs to allocate/free/configure channels) for a usage with an optimized user
space library.
The hardware tracing framework, I started to develop, only covers trace device
register/unregister and
offers a set of common hooks to the standard kernel tracing infrastructure, all
things traced into trace ring
buffer (ftrace) could be redirected in real time towards dedicated STM
channels, it's only a draft,
we can add OST header management here and others features.
I attach my current user+kernel STM interface.
Now, I'm waiting of Doug's generic STM specification document for review and
for pursue STM driver development for future upstreaming.
Best regards,
Philippe
On 20 June 2011 14:57, Arvind Chauhan
arvind.chau...@arm.commailto:arvind.chau...@arm.com wrote:
Hi Philippe,
Some comments on stm-trace.txt, for points 1, 2, 3.
Maybe I can schedule a conference call this week to go over some of the notes,
let me know.
Best regards,
Arvind
-Original Message-
From: Philippe Langlais
[mailto:philippe.langl...@linaro.orgmailto:philippe.langl...@linaro.org]
Sent: Thursday, May 26, 2011 8:50 PM
To: Deao, Douglas; Linus Walleij; Lee Jones
Cc: Arvind Chauhan; Michael Hope;
linaro-dev@lists.linaro.orgmailto:linaro-dev@lists.linaro.org;
pierre.peif...@stericsson.commailto:pierre.peif...@stericsson.com;
loic.palla...@stericsson.commailto:loic.palla...@stericsson.com
Subject: Re: ST-E STM Driver Review
Hi Doug,
I initiate the work to build a hardware trace framework in the kernel,
I'm not started the study to
have a common userspace API for STM, thanks to this email we can start
such a work, but
it may be long (next week I'm in vacation till June 7th).
See my detailed response for all your interrogations and my thoughts
about STE STM implementation below:
On 25 May 2011 23:54, Deao, Douglas d-d...@ti.commailto:d-d...@ti.com
wrote:
Sorry it took a while to get back to you guys. I was visiting customers
last week. Most of my comments are just highlighting the differences
between TI's STM 1.0 driver and ST-E's STM 1.0 driver, but there are a
few questions, observations and suggestions. At the end I included some
discussion on TI's meta data and OST header requirements.
I have not had a chance to look at your actual implementation yet. Did
you do anything to abstract the actual HW transport ports and control
registers from the higher level driver functions?
Yes, partially I think through IOCTLs debugfs (see our stm.h userspace
API)
I realize there is a lot here to work through so if you would rather
schedule a conference call to talk through the differences I can do
that. I would like to start work on a Linaro (Unified) STM Spec next
week if I can get feedback from everybody over the next few days. I will
be out of the office on 5/27 and 5/31.
I hope this email is enough.
I am especially interested in details of what you guys have in mind for
a common trace framework to receive STM drivers. If by framework you
mean well defined APIs that are implemented for specific devices, then I
think we are in agreement. What Michael and I have talked about is a
common STM user mode experience across all Linaro supported devices,
making Linux user mode code 100% portable between our devices.
For my point of view, the trace device framework must ease the
integration of new hardware trace drivers in the kernel
(not only STM MIPI)
TI LT 3.0 Tracking branches
Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. I introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - android_omap4_defconfig that are linus' HEAD and common-3.0 (androidized nearly linus HEAD) based and have the API v4403 SGX stuff on them. The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. However, Android rootfs is able to boot to the desktop (v4403 3D accelerated) with tilt-tracking-android, and X can come up unaccelerated as usual as well on Ubuntu on tilt-tracking. So it's not a bad start. When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. -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/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro monthly release cycle
On 23 June 2011 03:45, Alexander Sack a...@linaro.org wrote: On Thu, Jun 23, 2011 at 3:20 AM, Zach Pfeffer zach.pfef...@linaro.org wrote: Or we could just use continuous integration where there are no freezes, just per change regression tests. thats the idealistic goal yes, but getting even close there takes a bit and I am not sure if full continuous integration in the sense that you can land even massive patchsets the day before release just relying on your automated tests is something that can ever happen. e.g. you will always end up with some explicit release process with some kind of restrictions on what type of change is acceptable right before the release etc. With CI loops you tend to not do massive patches, which helps things out. Your point is taken though. CI solves the end of the month problem because all the work is already done, you just scrape the results. Since you're always integrating then there's non of this back and forth with tarballs and patches, its just totally streamlined. It dramatically increases the quality and quantity of software that you can produce. Basically as long as you ever discover any issue through manual testing that you didn't catch through automation before means you are still not ready to do full continuous integration. Its a spectrum. In reality you still need to bake things. But the CI loop solves the software delivery into a common image beautifully. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Renaming miscellaneous python projects that currently abuse linaro
Hi. I'd like to update you on the rename process: For linaro-json: This project started as a huge collection of tools for JSON but was later on refocused on one important thing - schema validation. Proposed names: - json-schema-validator This project has been renamed to json-schema-validator. PyPi: http://pypi.python.org/pypi/json-schema-validator/ Documentation: http://packages.python.org/json-schema-validator/ The old linaro_json is now frozen for development except for critical bug fixes (which I don't anticipate). Thanks. ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 23 June 2011 08:51, Andy Green andy.gr...@linaro.org wrote: Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. What does this mean for the 11.06 OMAP Android release? Will it use your 3.0 kernel or will it use 2.6.35 again? I introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - android_omap4_defconfig that are linus' HEAD and common-3.0 (androidized nearly linus HEAD) based and have the API v4403 SGX stuff on them. How hard is it to just grab the OMAP-specific patches from 3.0-rclatestand move them to 2.6.39? The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. Is this something that upstream is also aware of and tracking? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 06/23/2011 05:04 PM, Somebody in the thread at some point said: On 23 June 2011 08:51, Andy Greenandy.gr...@linaro.org wrote: Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. What does this mean for the 11.06 OMAP Android release? Will it use your 3.0 kernel or will it use 2.6.35 again? I'm not certain what the android folks are doing but I have also tagged android-2.6.38-2011-06 on my repo which is a 2.6.38 branch that boots into Android fine with 3D acceleration, just with 640 x 480 raster and framebuffer. I know Zach is familiar with this and has been preparing the way, so I think we might see that one go out this month. I introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - android_omap4_defconfig that are linus' HEAD and common-3.0 (androidized nearly linus HEAD) based and have the API v4403 SGX stuff on them. How hard is it to just grab the OMAP-specific patches from 3.0-rclatestand move them to 2.6.39? Well, the point is linux-linaro-* would be a common place that all the LT kernels can contribute to. For example if this new 4430 Alsa implementation has dependencies on Alsa core stuff only in 3.0, we're back in the same bind as the forwardport of the 2.6.38 Alsa driver which has special needs in Alsa core stuff that conflicts with other LEB audio driver assumptions. In the end demand downstream of us is only for 3.0, they won't get any direct benefit from time spent servicing 2.6.39. The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. Is this something that upstream is also aware of and tracking? What the EHCI debug effort you mean? There's no fruit from it yet but sure, since we happen to be riding Linus HEAD if we find something applicable to upstream I don't doubt Jassi will send it there straight away. -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/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with todays linux-linaro-2.6.39 and THUMB2 kernel
On Thu, 23 Jun 2011, John Rigby wrote: I thought this was new but it has been around for awhile. My default config was not turning on THUMB2 kernel so I only saw it today. Old known issue. I wonder why I didn't stumble on it. Should be fixed now. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with todays linux-linaro-2.6.39 and THUMB2 kernel
On Thu, Jun 23, 2011 at 01:10:27PM -0400, Nicolas Pitre wrote: On Thu, 23 Jun 2011, John Rigby wrote: I thought this was new but it has been around for awhile. My default config was not turning on THUMB2 kernel so I only saw it today. Old known issue. I wonder why I didn't stumble on it. Should be fixed now. The patch for this has been in Russell's patch system for a while, but he's not keen on it and hasn't merged it so far: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6855/1 Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On Thu, 23 Jun 2011, Andy Green wrote: Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. $ git diff --shortstat v2.6.39..linaro-2.6.39 sound/ 158 files changed, 20097 insertions(+), 6899 deletions(-) $ git diff --shortstat linaro-2.6.39..v3.0-rc4 sound/ 65 files changed, 4586 insertions(+), 3612 deletions(-) So please lets stop that linaro-2.6.39 is just 2.6.39 rhetoric when numbers show that linaro-2.6.39 is much closer to the strictly speaking still nonexistent 3.0 than 2.6.39. When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. The base will be just as good as the contributions made by people to it. And besides a few notable exceptions such as yours, I didn't get much from people in terms of patches and/or pull requests. I'm seriously starting to question the usefulness of the Linaro kernel tree in fact. For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming. The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons. So I'm asking people for comments about this tree. - Is this useful? - Is it important? - Are _you_ using it? - Is solving the ARM fragmentation problem still a Linaro priority? - Is the Linaro kernel effective for this? Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro stable branches. If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't. One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels. Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift. Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness. If the later... well... what can I say here? In any case that doesn't make a strong case for the Linaro kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results. In practice that's what I see people doing right now anyway. Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority. I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful. I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results. Opinions anyone? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 06/23/2011 07:44 PM, Somebody in the thread at some point said: On Thu, 2011-06-23 at 09:04 -0700, Deepak Saxena wrote: The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. Is this something that upstream is also aware of and tracking? There is an easy revert for the ehci issue: git show 7e6502d577106fb5b202bbaac64c5f1b065e6daa | patch -p1 -R Awesome, I'll give it a go later. Thanks for letting us know. -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/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On Thu, Jun 23, 2011 at 2:39 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 23 Jun 2011, Andy Green wrote: Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. $ git diff --shortstat v2.6.39..linaro-2.6.39 sound/ 158 files changed, 20097 insertions(+), 6899 deletions(-) $ git diff --shortstat linaro-2.6.39..v3.0-rc4 sound/ 65 files changed, 4586 insertions(+), 3612 deletions(-) So please lets stop that linaro-2.6.39 is just 2.6.39 rhetoric when numbers show that linaro-2.6.39 is much closer to the strictly speaking still nonexistent 3.0 than 2.6.39. When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. The base will be just as good as the contributions made by people to it. And besides a few notable exceptions such as yours, I didn't get much from people in terms of patches and/or pull requests. I'm seriously starting to question the usefulness of the Linaro kernel tree in fact. For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming. The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons. So I'm asking people for comments about this tree. - Is this useful? - Is it important? - Are _you_ using it? - Is solving the ARM fragmentation problem still a Linaro priority? - Is the Linaro kernel effective for this? Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro stable branches. If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't. One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels. Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift. Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness. If the later... well... what can I say here? In any case that doesn't make a strong case for the Linaro kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results. In practice that's what I see people doing right now anyway. Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority. I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful. I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results. Opinions anyone? +1 We are still a few patches away (about 85 at my last count) from having a good experience on the mainline with the BeagleBoard-xM. I want to see that count reach 0, hopefully by whatever is next after 3.0. No out-of-mainline patches has to be the goal. Nicolas ___ 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: TI LT 3.0 Tracking branches
On Thu, 2011-06-23 at 09:04 -0700, Deepak Saxena wrote: The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. Is this something that upstream is also aware of and tracking? There is an easy revert for the ehci issue: git show 7e6502d577106fb5b202bbaac64c5f1b065e6daa | patch -p1 -R thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RFC: drivers: swarren's pinmux API concept
Linus W,
This patch is a quick-and-dirty outline of where I'd love to see the
pinmux API go, but this time in code rather than English description.
Note that I elided a bunch of stuff from the headers; some comments weren't
updated, I removed the inline functions for when pinmux is disabled, etc.
The code has not been compiled. The main idea is just to give an idea of
what I'm thinking.
Let me know if any of this looks reasonable to you; if so, I can look into
fixing the issues above, making the core pinmux code actually work in this
model, or whatever.
Thanks!
---
drivers/pinctrl/pinmux-tegra2.c | 85 ++
include/linux/pinctrl/consumer.h | 47
include/linux/pinctrl/machine.h | 47
include/linux/pinctrl/provider.h | 149 ++
4 files changed, 328 insertions(+), 0 deletions(-)
create mode 100644 drivers/pinctrl/pinmux-tegra2.c
create mode 100644 include/linux/pinctrl/consumer.h
create mode 100644 include/linux/pinctrl/machine.h
create mode 100644 include/linux/pinctrl/provider.h
diff --git a/drivers/pinctrl/pinmux-tegra2.c b/drivers/pinctrl/pinmux-tegra2.c
new file mode 100644
index 000..d010f9c
--- /dev/null
+++ b/drivers/pinctrl/pinmux-tegra2.c
@@ -0,0 +1,85 @@
+/*
+ * pinctrl driver for NVIDIA Tegra 2
+ *
+ * Author: Stephen Warren swar...@nvidia.com
+ * Copyright (C) 2011 NVIDIA, Inc.
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include linux/pinmux/provider.h
+
+struct tegra_pin {
+ struct pinctrl_pin core;
+ int reg_addr; /* e.g. for per-pin config */
+ /* And other info */
+};
+
+struct tegra_function {
+ struct pinctrl_function core;
+ int reg_value;
+ /* And other info */
+}
+
+struct tegra_group {
+ struct pinctrl_group core;
+ int reg_addr; /* e.g. for muxing and per-pin config */
+ int reg_bit;
+ /* And other info */
+}
+
+struct tegra_pin tegra_pins[] = {
+ { .core = { .name = a0, }, }, /* 0 */
+ { .core = { .name = a1, }, }, /* 1 */
+ { .core = { .name = b0, }, }, /* 2 */
+ { .core = { .name = b1, }, }, /* 3 */
+ { .core = { .name = c0, }, }, /* 4 */
+ { .core = { .name = c1, }, }, /* 5 */
+ { .core = { .name = d0, }, }, /* 6 */
+ { .core = { .name = d1, }, }, /* 7 */
+ { .core = { .name = e0, }, }, /* 8 */
+ { .core = { .name = e1, }, }, /* 9 */
+
+/* Or: */
+#define PIN_B0 2
+ .PIN_B0 = { .core = { .name = b0, }, },
+};
+
+struct tegra_function tegra_function[] = {
+ { .core = { .name = kbc-col-1:0, }, 1 }, /* 0 */
+ { .core = { .name = kbc-row-1:0, }, 2 }, /* 1 */
+ { .core = { .name = i2c0, },3 }, /* 2 */
+ { .core = { .name = uartrxtx0, }, 4 }, /* 3 */
+ { .core = { .name = spiclkdata0, }, 5 }, /* 4 */
+ { .core = { .name = gpioctrlr0, }, 0x8001}, /* 5 */
+ { .core = { .name = gpioctrlr1, }, 0x8002}, /* 6 */
+
+/* Or: */
+#define FUNC_I2C0 2
+ .FUNC_I2C0 = { .core = { .name = i2c0, }, 3},
+
+};
+
+int pins_kbca[] = { 0, 1 };
+int funcs_kbca[] = { 0, 5 };
+
+int pins_kbcb[] = { 2, 3 };
+int funcs_kbcb[] = { 1, 5 };
+
+int pins_ddca[] = { 4, 5 };
+int funcs_ddca[] = { 2, 3, 5, 6 };
+
+int pins_ddcb[] = { 6, 7 };
+int funcs_ddcb[] = { 2, 4, 5, 6 };
+
+int pins_xx[] = { 8, 9};
+int funcs_xx[] = { 5, 6};
+
+struct tegra_group tegra_groups[] = {
+ { .core = { .name = kbca, npins = 2, pins = pins_kbca, nfunctions =
2, functions = funcs_kbca} },
+ { .core = { .name = kbcb, npins = 2, pins = pins_kbcb, nfunctions =
2, functions = funcs_kbcb} },
+ { .core = { .name = ddca, npins = 2, pins = pins_ddca, nfunctions =
4, functions = funcs_ddca} },
+ { .core = { .name = ddcb, npins = 2, pins = pins_ddcb, nfunctions =
4, functions = funcs_ddcb} },
+ { .core = { .name = xx, npins = 2, pins = pins_xx, nfunctions =
2, functions = funcs_xx } },
+};
+
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
new file mode 100644
index 000..81cedf3
--- /dev/null
+++ b/include/linux/pinctrl/consumer.h
@@ -0,0 +1,47 @@
+/*
+ * pinctrl subsystem's client/consumer interface
+ *
+ * Copyright (C) 2011 ST-Ericsson SA
+ * Written on behalf of Linaro for ST-Ericsson
+ * Based on bits of regulator core, gpio core and clk core
+ *
+ * Author: Linus Walleij linus.wall...@linaro.org
+ *
+ * Copyright (C) 2011 NVIDIA, Inc.
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef __LINUX_PINCTRL_CONSUMER_H
+#define __LINUX_PINCTRL_CONSUMER_H
+
+#include linux/list.h
+#include linux/seq_file.h
+
+/* This struct is private to the core and should be regarded as a cookie */
+struct pinctrl;
+
+/* Not sure this is useful: */
+extern bool pin_is_valid(int pin);
+
+/* Basic pinmux API: */
+extern struct pinctrl *pinctrl_get(struct device *dev, const char *mapping);
+extern void pinctrl_put(struct pinctrl
Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver
On Wed, Jun 22, 2011 at 10:22 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
I have added the functions as you have suggested and the diff is
listed below. Could you please review the diff and suggest any changes
required.
Thanks Thomas. Comments below...
drivers/of/base.c | 129
include/linux/of.h | 10
2 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 632ebae..73f0144 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -596,6 +596,135 @@ struct device_node
*of_find_node_by_phandle(phandle handle)
EXPORT_SYMBOL(of_find_node_by_phandle);
/**
+ * of_read_property_u32 - Reads a indexed 32-bit property value
+ * @prop: property to read from.
+ * @offset: cell number to read.
+ * value: returned cell value
+ *
+ * Returns a indexed 32-bit value of a property cell, -EINVAL in case the
cell
+ * does not exist
+ */
+int of_read_property_u32(struct property *prop, u32 offset, u32 *value)
+{
+ if (!prop || !prop-value)
+ return -EINVAL;
Hmmm, it would probably be a good idea to differentiate return code
depending on whether or not the property was found vs. the property
data not large enough.
+ if ((offset + 1) * 4 prop-length)
+ return -EINVAL;
+
+ *value = of_read_ulong(prop-value + (offset * 4), 1);
+ return 0;
Despite the fact that this is exactly what I asked you to write, this
ends up being rather ugly. (I originally put in the '*4' to match the
behaviour of the existing of_read_number(), but that was a mistake.
tglx also pointed it out). How about this instead:
int of_read_property_u32(struct property *prop, unsigned int offset,
u32 *out_value)
{
if (!prop || !out_value)
return -EINVAL;
if (!prop-value)
return -ENODATA;
if (offset + sizeof(*out_value) prop-length)
return -EOVERFLOW;
*out_value = be32_to_cpup(prop-data + offset);
return 0;
}
int of_read_property_u64(struct property *prop, unsigned int offset,
u64 *out_value)
{
if (!prop || !out_value)
return -EINVAL;
if (!prop-value)
return -ENODATA;
if (offset + sizeof(*out_value) prop-length)
return -EOVERFLOW;
*out_value = be32_to_cpup(prop-value + offset);
*out_value = (*out_value 32) | be32_to_cpup(prop-value +
offset + sizeof(u32));
return 0;
}
+}
+EXPORT_SYMBOL(of_read_property_u32);
EXPORT_SYMBOL_GPL()
+
+/**
+ * of_getprop_u32 - Find a property in a device node and read a 32-bit value
+ * @np: device node from which the property value is to be
read.
+ * @propname name of the property to be searched.
+ * @offset: cell number to read.
+ * @value: returned value of the cell
+ *
+ * Search for a property in a device node and read a indexed 32-bit value of
a
+ * property cell. Returns the 32-bit cell value, -EINVAL in case the
property or
+ * the indexed cell does not exist.
+ */
+int
+of_getprop_u32(struct device_node *np, char *propname, int offset, u32
*value)
+{
+ return of_read_property_u32(of_find_property(np, propname, NULL),
+ offset, value);
+}
+EXPORT_SYMBOL(of_getprop_u32);
+
+/**
+ * of_read_property_u64 - Reads a indexed 64-bit property value
+ * @prop: property to read from.
+ * @offset: cell number to read (each cell is 64-bits).
+ * @value: returned cell value
+ *
+ * Returns a indexed 64-bit value of a property cell, -EINVAL in case the
cell
+ * does not exist
+ */
+int of_read_property_u64(struct property *prop, int offset, u64 *value)
+{
+ if (!prop || !prop-value)
+ return -EINVAL;
+ if ((offset + 1) * 8 prop-length)
+ return -EINVAL;
+
+ *value = of_read_number(prop-value + (offset * 8), 2);
+ return 0;
+}
+EXPORT_SYMBOL(of_read_property_u64);
+
+/**
+ * of_getprop_u64 - Find a property in a device node and read a 64-bit value
+ * @np: device node from which the property value is to be
read.
+ * @propname name of the property to be searched.
+ * @offset: cell number to read (each cell is 64-bits).
+ * @value: returned value of the cell
+ *
+ * Search for a property in a device node and read a indexed 64-bit value of
a
+ * property cell. Returns the 64-bit cell value, -EINVAL in case the
property or
+ * the indexed cell does not exist.
+ */
+int
+of_getprop_u64(struct device_node *np, char *propname, int offset, u64
*value)
+{
+ return of_read_property_u64(of_find_property(np, propname, NULL),
+ offset, value);
+}
+EXPORT_SYMBOL(of_getprop_u64);
+
+/**
+ * of_read_property_string - Returns a pointer to a indexed null terminated
Re: TI LT 3.0 Tracking branches
Hi John, On 24 June 2011 00:14, john stultz johns...@us.ibm.com wrote: On Thu, 2011-06-23 at 09:04 -0700, Deepak Saxena wrote: The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. Is this something that upstream is also aware of and tracking? There is an easy revert for the ehci issue: git show 7e6502d577106fb5b202bbaac64c5f1b065e6daa | patch -p1 -R Yes that fix the issue. Though the responsible part is inadvertently dropped TLL initialization. Thanks, Jassi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ARM Cross-Compilation
Hi, I am Marc-Andre from the FreeRDP project, an open source RDP client. I want to work on optimizing FreeRDP for ARM using the NEON processor extensions. The main computer is running Ubuntu 11.04 64-bit, while the target system is a pandaboard running Ubuntu 11.04 for ARM. I started looking into linaro because it aims at improving the current set of development tools for ARM, and I like where the project is going. Once I will have figured out how to get started, I will document the procedure specific to cross-compiling FreeRDP and redirect developers to it. It is my first time cross-compiling, so thank you for your understanding. I have asked some questions on IRC, and read various pages from the wiki, but I haven't managed to successfully cross-compile FreeRDP yet. Compiling directly on the pandaboard works, but it is atrociously slow. I have made a chroot environment following and adapting the instructions from the following wiki page: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingXdeb I took notes while setting up my chroot environment, such that I could use those notes later on for a wiki article: # bootstrap ubuntu natty sudo debootstrap natty natty-armel # chroot to new environment sudo chroot natty-armel # mount partitions mount -t proc proc /proc mount -t devpts none /dev/pts # export environment variables export LC_ALL=C # append universe after main in sources.list sed -i 's/main/main universe/' /etc/apt/sources.list # add source repository sudo echo deb [arch=armel] http://ports.ubuntu.com/ natty main universe /etc/apt/sources.list # update and install packages apt-get update apt-get install gcc-arm-linux-gnueabi xdeb I have tried both xdeb and xapt, both causing problems. You can find the regular compilation procedure here: http://www.freerdp.com/wiki/doku.php?id=compilation Following the regular procedure, one can compile directly on the pandaboard, but it's very slow. xapt: I managed to fetch and convert packages with xapt, using the following command: sudo xapt -a armel -k -b --suite natty --mirror http://ports.ubuntu.com/libssl-dev libx11-dev libxv-dev libxkbfile-dev libxcursor-dev libasound2-dev libxcb1 libxcb1-dev libdirectfb-dev libc6 libc6-dev zlib1g zlib1g-dev The problem is then that xapt will fail to install the converted packages, saying the package architecture is different from the current architecture, as well as missing dependencies. I worked around the problem with this ugly hack: cd /var/lib/xapt/output/ sudo dpkg -i --force-all *.deb Following this, I could get the FreeRDP configure script to work, even though it would fail to detect X11 properly: PKG_CONFIG_PATH=/usr/arm-linux-gnueabi/lib/pkgconfig ./configure --host=arm-linux-gnueabi --with-neon When trying to build after that, it will still fail to link in the end, complaining about missing libraries such as zlib, X11, crypto, etc. I tried installing various packages more with xapt, but I couldn't get it to work. xdeb: I tried the following: root@workstation:/# xdeb -a armel --prefer-apt libssl-dev libx11-dev libxv-dev libxkbfile-dev libxcursor-dev libasound2-dev Building source package cache ... Using file ports.ubuntu.com_dists_natty_main_source_Sources for apt cache Using file ports.ubuntu.com_dists_natty_universe_source_Sources for apt cache Using file archive.ubuntu.com_ubuntu_dists_natty_main_source_Sources for apt cache Using file archive.ubuntu.com_ubuntu_dists_natty_universe_source_Sources for apt cache Building working tree cache ... No source package found: libssl-dev Or, alternatively, the following: root@workstation:/# xdeb -a armel --convert libssl-dev libx11-dev libxv-dev libxkbfile-dev libxcursor-dev libasound2-dev Traceback (most recent call last): File /usr/bin/xdeb, line 849, in module main() File /usr/bin/xdeb, line 767, in main crossed_debs = cross_convert(options, args) File /usr/bin/xdeb, line 409, in cross_convert deb)).debcontrol() File /usr/lib/pymodules/python2.7/debian/debfile.py, line 208, in __init__ ArFile.__init__(self, filename, mode, fileobj) File /usr/lib/pymodules/python2.7/debian/arfile.py, line 47, in __init__ self.__index_archive() File /usr/lib/pymodules/python2.7/debian/arfile.py, line 52, in __index_archive fp = open(self.__fname, rb) IOError: [Errno 2] No such file or directory: './libssl-dev' Here is my sources.list file: root@workstation:/# cat /etc/apt/sources.list deb http://archive.ubuntu.com/ubuntu natty main universe deb-src http://archive.ubuntu.com/ubuntu natty main universe deb [arch=armel] http://ports.ubuntu.com/ natty main universe deb-src [arch=armel] http://ports.ubuntu.com/ natty main universe I'm stuck at this point. Can anybody point me towards possible solution paths on how to cross-compile FreeRDP for ARM, given the above information? Best regards, - Marc-Andre ___ linaro-dev mailing list linaro-dev@lists.linaro.org
Re: TI LT 3.0 Tracking branches
On 23 June 2011 11:39, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 23 Jun 2011, Andy Green wrote: When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. The base will be just as good as the contributions made by people to it. And besides a few notable exceptions such as yours, I didn't get much from people in terms of patches and/or pull requests. I'm seriously starting to question the usefulness of the Linaro kernel tree in fact. For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming. The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons. - Is solving the ARM fragmentation problem still a Linaro priority? From my POV, this is definitely a yes. - Is the Linaro kernel effective for this? This I am not 100% sure about. I've seen quite a bit of activity on linux-arm-kernel after LDS with folks moving drivers out of arch/arm and I am beginning to see DT work being posted upstream. How much of that work is being send directly to you vs you having to stay on top of various changes in the community and pull those in proactively or as in the case of the ALSA issues, reactively? In other words, how much of your time is spent on keeping up with all the changes you need to pull into the Linaro kernel? This kernel is useful as place to test patches that are headed upstream in a single tree but unless all the LTs are using it as their base and are sending you patches on a regular basis, I do wonder if you're spending cycles on this tree that could be used on more core consolidation work. Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro stable branches. If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't. One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels. Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift. Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness. If the later... well... what can I say here? I don't know that we're hearing that all vendor trees want to be on the latest kernel. What I'm reading from Andy's perspective is that it is easier to just work directly against upstream changes that to try and figure out what all changes need to be picked into 2.6.39.. From ST-E's landing team perspective, by the time they start on their work, it will be time for a 3.x tree. In any case that doesn't make a strong case for the Linaro kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results. In practice that's what I see people doing right now anyway. Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority. +1 I don't think it makes sense to have a Linaro-only tree for the sake of having a place to showcase Linaro's work. We don't want to be different from a kernel POV in my opinion. Our goal is to fix the kernel upstream, improve performance, consolidate architectures, help vendors cleanup their code. If we want to show case work, there are other ways to do it including just collating commit messages and providing high level summaries of work being done. I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful. I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results. My opinion is that if there are no patches coming in from within Linaro and all of the work you are doing is to simply integrate patches that are already upstream-bound, then we should just kill the Linaro tree and focus 100% on an upstream. Instead of having a Linaro-branded kernel, could we just have a branch in the arm-soc tree that is a consolidation branch and is widely used beyond just Linaro builds and that acts as a more public and upstream arm-next tree? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org
FYI: Linaro Validation showcase video at Computex 2011
Hello list, During the first week of June, we prepared the technical showcase[1] about Linaro powered devices and projects including LAVA[1]. To emphasize how LAVA works, we just uploaded another demo video: http://www.youtube.com/watch?v=_3dT68MOzz0 It starts at 2:27. Sincerely, -jserv [1] The overview video: ARM at Computex 2011 with Linaro http://www.youtube.com/user/ARMflix#p/a/9ABC7CFA0491638F/0/9RzbAt27qic [2] https://wiki.linaro.org/Platform/Validation/LAVA ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: FYI: Linaro Validation showcase video at Computex 2011
Neat! Any feedback from those who saw it? On Fri, Jun 24, 2011 at 12:00 AM, Jim Huang jim.hu...@linaro.org wrote: Hello list, During the first week of June, we prepared the technical showcase[1] about Linaro powered devices and projects including LAVA[1]. To emphasize how LAVA works, we just uploaded another demo video: http://www.youtube.com/watch?v=_3dT68MOzz0 It starts at 2:27. Sincerely, -jserv [1] The overview video: ARM at Computex 2011 with Linaro http://www.youtube.com/user/ARMflix#p/a/9ABC7CFA0491638F/0/9RzbAt27qic [2] https://wiki.linaro.org/Platform/Validation/LAVA ___ 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
