Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux
On Sat, Oct 8, 2011 at 11:09 AM, Barry Song 21cn...@gmail.com wrote:
+static void __init u300_pmx_dumpregs(struct u300_pmx *upmx)
+{
+ u16 regval;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(u300_pmx_registers); i++) {
+ regval = readw(upmx-virtbase + u300_pmx_registers[i]);
+ dev_info(upmx-dev, PMX%u: 0x%04x\n, i, regval);
+ }
+}
is this a debug information or do you want it to be in mainline?
Debug info, I'll delete it. Not that it hurt, but I'll kill it.
+ /* Create state holders etc for this driver */
+ upmx = devm_kzalloc(pdev-dev, sizeof(struct u300_pmx), GFP_KERNEL);
and this would be devm_kzalloc(pdev-dev, sizeof(*upmx), GFP_KERNEL); ?
Same semantic effect, but if you prefer it that way, sure :-)
I've seen both used in the kernel before...
Can I have your Reviewed-by: tag after this?
Linus Walleij
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux
2011/10/9 tommy.hong hongjiuj...@126.com: [Barry] is this a debug information or do you want it to be in mainline? Hi,Barry,should dumpregs function need CONFIG_XXX_DEBUG when probe ?and if driver meet some issue or error,we can use dumpregs to trace? You can add any debug stuff you want if it helps development and/or transparance of the driver, but this stuff I just deleted, it is not needed anymore. I just used it to figure out the default reset-values of the registers. Yours, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pin control subsystem v9
On Sun, Oct 9, 2011 at 11:36 AM, Shawn Guo shawn@freescale.com wrote: + * @hog_on_boot: if this is set to true, the regulator subsystem will itself ^ s/regulator/pinmux? Yep! +#endif /* !CONFIG_PINCTRL */ s/!CONFIG_PINCTRL/CONFIG_PINMUX? Yep! Foldes into original patch with a fixup comment. Can I have your Reviewed-by: tag on this subsystem? Yours, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro CI hwpack name improvements
Hello, I am working on improving the hwpack names delivered by the Linaro Kernel Continuous Integration. To start on this I needed inputs from the kernel team. currently the hwpack containing the newly built kernel debian package is named for example as hwpack_linaro-panda_20111004-1126_armel_supported.tar.gz and it includes 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in mmdd format along with the time in hhmm format. The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ? -- Thanks and Regards, Deepti Infrastructure Team Member, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux
2011/10/10 Linus Walleij linus.wall...@linaro.org:
On Sat, Oct 8, 2011 at 11:09 AM, Barry Song 21cn...@gmail.com wrote:
+static void __init u300_pmx_dumpregs(struct u300_pmx *upmx)
+{
+ u16 regval;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(u300_pmx_registers); i++) {
+ regval = readw(upmx-virtbase + u300_pmx_registers[i]);
+ dev_info(upmx-dev, PMX%u: 0x%04x\n, i, regval);
+ }
+}
is this a debug information or do you want it to be in mainline?
Debug info, I'll delete it. Not that it hurt, but I'll kill it.
+ /* Create state holders etc for this driver */
+ upmx = devm_kzalloc(pdev-dev, sizeof(struct u300_pmx),
GFP_KERNEL);
and this would be devm_kzalloc(pdev-dev, sizeof(*upmx), GFP_KERNEL); ?
Same semantic effect, but if you prefer it that way, sure :-)
I've seen both used in the kernel before...
coding style document says :
Chapter 14: Allocating memory
The kernel provides the following general purpose memory allocators:
kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc(). Please refer to
the API documentation for further information about them.
The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);
The alternative form where struct name is spelled out hurts readability and
introduces an opportunity for a bug when the pointer variable type is changed
but the corresponding sizeof that is passed to a memory allocator is not.
Can I have your Reviewed-by: tag after this?
yes. of course.
Linus Walleij
Thanks
barry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v10] pinctrl: add a driver for the U300 pinmux
2011/10/10 Linus Walleij linus.wall...@stericsson.com: From: Linus Walleij linus.wall...@linaro.org This adds a driver for the U300 pinmux portions of the system controller SYSCON. It also serves as an example of how to use the pinmux subsystem. This driver also houses the platform data for the only supported platform. This deletes the old U300 driver in arch/arm/mach-u300 and replace it with a driver using the new subsystem. The new driver is considerably fatter than the old one, but it also registers all 467 pins of the system and adds the power and EMIF pin groups and corresponding functions. The idea is to use this driver as a a reference for other implementation so it needs to be as complete and verbose as possible. Signed-off-by: Linus Walleij linus.wall...@linaro.org Reviewed-by: Barry Song 21cn...@gmail.com --- ChangeLog v9 - v10 - Removed debug register dump (review from Barry Song) - Allocate sizeof(*ptr) instead of sizeof(struct foo) -barry ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Mon, Oct 10, 2011, Deepti Kalakeri wrote: 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in mmdd format along with the time in hhmm format. The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ? We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config). -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pin control subsystem v9
On Mon, Oct 10, 2011 at 10:23:53AM +0200, Linus Walleij wrote:
On Sun, Oct 9, 2011 at 11:36 AM, Shawn Guo shawn@freescale.com wrote:
+ * @hog_on_boot: if this is set to true, the regulator subsystem will
itself
^
s/regulator/pinmux?
Yep!
+#endif /* !CONFIG_PINCTRL */
s/!CONFIG_PINCTRL/CONFIG_PINMUX?
Yep!
Foldes into original patch with a fixup comment.
Can I have your Reviewed-by: tag on this subsystem?
Sorry, not yet. This is not a full review. I'm trying to migrate imx
pinctrl to the subsystem. And all these are just some random spotting.
Another couple of typo on pinctrl.txt?
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
new file mode 100644
index 000..2915fea
--- /dev/null
+++ b/Documentation/pinctrl.txt
@@ -0,0 +1,951 @@
[...]
+The example 8x8 PGA package above will have pin numbers 0 thru 63 assigned to
+its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
+pinctrl_register_pins_[sparse|dense]() and a suitable data set as shown
It should just be pinctrl_register_pins()?
+earlier.
[...]
+System pinmux hogging
+=
+
+A system pinmux map entry, i.e. a pinmux setting that does not have a device
+associated with it, can be hogged by the core when the pin controller is
+registered. This means that the core will attempt to call regulator_get() and
+regulator_enable() on it immediately after the pin control device has been
+registered.
s/regulator_get/pinmux_get, and s/regulator_enable/pinmux_enable
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier loic.min...@linaro.org wrote: On Mon, Oct 10, 2011, Deepti Kalakeri wrote: 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in mmdd format along with the time in hhmm format. The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ? We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config). (note that in the case of kernel CI we currently use pure defconfig configurations) What I asked deepti to work on is to make the CI hwpacks exported through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able to the actual CI job they are coming from. Instead of exploding the hwpack name with more info, we could also introduce a new directory level in the kernel_hwpack directory like: kernel_hwpack/ci_job_name/HWPACK1,2,3 ... and then leave the hwpack names as they are now. Maybe improve the version to rather use the git describe version of the kernel tree and not the kind of meaningless timestamp. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] drivers: create a pin control subsystem v9
On Mon, Oct 10, 2011 at 2:30 PM, Shawn Guo shawn@freescale.com wrote:
+The example 8x8 PGA package above will have pin numbers 0 thru 63 assigned
to
+its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
+pinctrl_register_pins_[sparse|dense]() and a suitable data set as shown
It should just be pinctrl_register_pins()?
Yep, fixed it.
+System pinmux hogging
+=
+
+A system pinmux map entry, i.e. a pinmux setting that does not have a device
+associated with it, can be hogged by the core when the pin controller is
+registered. This means that the core will attempt to call regulator_get()
and
+regulator_enable() on it immediately after the pin control device has been
+registered.
s/regulator_get/pinmux_get, and s/regulator_enable/pinmux_enable
Fixed this too, sorry for being so hung up on the regulator subsystem,
must be that I really like it...
Thanks,
Linus Walleij
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Mon, Oct 10, 2011 at 02:22:05PM +0200, Alexander Sack wrote: On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier loic.min...@linaro.org wrote: On Mon, Oct 10, 2011, Deepti Kalakeri wrote: 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in mmdd format along with the time in hhmm format. The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ? We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config). (note that in the case of kernel CI we currently use pure defconfig configurations) What I asked deepti to work on is to make the CI hwpacks exported through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able to the actual CI job they are coming from. Instead of exploding the hwpack name with more info, we could also introduce a new directory level in the kernel_hwpack directory like: kernel_hwpack/ci_job_name/HWPACK1,2,3 ... and then leave the hwpack names as they are now. Maybe improve the version to rather use the git describe version of the kernel tree and not the kind of meaningless timestamp. Looks better, but... We need unique build IDs, and these are the critical thing we need to reference from the build. Anything else seems likely to result in fragility later. The CI infrastructure can tell us what config and sources a given build was generated from, so not only do we not need to put this information in the builds, I believe that we _should not_. Sooner or later it will get inconsistent or wrong, whereas the CI server is authoritative. Also if we try to put metadata into filenames, it will keep being found to be wrong or insufficient, so we may have to heep changing it. By putting the build ID into the kernel image .deb or the kernel release string, we can find out everything we need to know about the build, regardless of whether we start with an installed target platform, the .debs, the hwpack or the hwpack URL. For convenience only, we can put the job name and build ID into the URL and/or the hwpack filename, and possibly in the hwpack metadata, but it's important to remember that this is only a convenience and is not the authoritative source of the information. Personally, I'd recommend not putting the ID in too many places -- we would just end having to many different mechanisms for querying it, instead of having just one, robust, mechanism. Thoughts? Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LTTng 2.0 pre-release for ARM
On 09/23/2011 05:00 PM, Andy Doan wrote: On 09/23/2011 06:51 AM, Turgis, Frederic wrote: Hi, Very cool. I've added this to the wiki: https://wiki.linaro.org/Resources/HowTo/LTTng Good idea ! I could move and reference page under https://wiki.linaro.org/Platform/DevPlatform/Tools if people agree. Well, I may be speaking a bit quickly as I found out https://wiki.linaro.org/KenWerner/Sandbox/LTTng that could also be merged in. Avik, Andy, Ken ? I just renamed the page and added a link from the tools page. As per Ken's work: I'm not that familiar with LTTng, so I think it might be easier for one of you guys to merge them. Hi, sorry for the delay - I've been on vacation. The wiki page (https://wiki.linaro.org/KenWerner/Sandbox/LTTng) was created when I briefly looked at the state of some developer tools an ARM Linux. The LTTng kernel stuff was an out of tree patchset that was not part of the Linaro kernel. The ARM port of the userspace tracer (UST) was not there yet. So, the wiki page just reflects the state of LTTng on ARM Linux back then. I'm not sure this is helpful for end users. According to https://wiki.linaro.org/Platform/DevPlatform/Tools/LTTng it seems the kernel part works now. The liburcu ARM port doesn't seem to be there yet. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[REMINDER] Linaro 11.10 release dates and deliveries
Hi, This is a mail sent to remind you the coming release dates: * Linaro 11.10 components release is October 20nd, 2011. * Linaro 11.10 RC images is October 24th, 2011. * Linaro 11.10 release is October 27th, 2011. Components release will be announced this week. The release dates and deliveries information is available from the release dashboard: http://wiki.linaro.org/Cycles/1110/Release/Dashboard -- David Zinman Linaro Release Manager | Project Manager 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: vexpress and 11.08
On Mon, Sep 26, 2011 at 03:48:09PM +0100, Pawel Moll wrote: So I guess it must be no SATA because of broken PCI, True. no MMC because of FPGA bugs (now fixed), Work-arounded ;-) (hopefully really fixed in near future). no CF card because of (?). CF usability depends on the card. Most of the old cards Just Work (TM). New cards tend to have some problem with writing to them (it happens 30x slower than it should). It's on my TODO list, so sooner or later it will happen :-) Ah, and you need PATA_PLATFORM enabled. * Ethernet Was buggered, is fixed now :-) Cheers! Paweł I think that in practice USB storage tends to be fastest and most reliable. This might change in the future, but I've found that for now a USB card reader, USB stick or a real disk attached via USB works pretty well. Admittedly though, I haven't been testing the other mechanisms too much lately. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [android-kernel] Linaro and common- tree
On 6 October 2011 10:07, Andy Green andy.gr...@linaro.org wrote: On 6 October 2011 02:36, Tim Bird tim.b...@am.sony.com wrote: On 10/05/2011 08:37 AM, Andy Green wrote: Another side-issue is we are also looking at refactoring the Androidization patchset into topic branches, at the moment they're kind of reflecting the history that they were applied on plus or minus some munging around. So, all the net core patches for example would be together in one series, then all the wireless ones in a series on top of that, etc. It seems they would be easier to maintain then, opinions on that approach are also welcome. I've been working on a set of broken-out Android patches, in quilt format, with exactly the same goal. It's much easier (at least for me) to maintain the differences as distinct patches using quilt, rather than as a series (or set of branches) of git commits. But possibly I'm just missing how to do this easily with git. I would very much like to compare approaches, and possibly share Thanks a lot for the reply Tim. I can describe how I manage this flow in detail. Actually, since we would interact through pure git, it's not necessary to unify the patch management scheme to be able to cooperate. But since I spent so much time on exactly this subject I guess we both find it interesting to describe it. Further to this I have now re-ordered the patchset into 20 topics in the following order, on top of 3.1-rc9+ from yesterday: linaro-androidization-topic-base - stuff impacting core Linux linaro-androidization-topic-debug - logging, debug related features linaro-androidization-topic-wakelock - wakelock core stuff linaro-androidization-topic-earlysuspend - earlysuspend linaro-androidization-topic-mem - pmem, low memory killer linaro-androidization-topic-net-core - core network patches linaro-androidization-topic-netfilter - netfilter patches linaro-androidization-topic-net-wireless - wireless related linaro-androidization-topic-usb - usb, mostly gadget and composite linaro-androidization-topic-input - input subsystem related ./ HID linaro-androidization-topic-cpufreq - cpufreq linaro-androidization-topic-ion - ion graphical memory manager linaro-androidization-topic-mmc - mmc / sdio related linaro-androidization-topic-bluetooth - bluetooth linaro-androidization-topic-rtc - rtc / alarm linaro-androidization-topic-pm - suspend flow and other power management linaro-androidization-topic-binder - binder linaro-androidization-topic-fs - yaffs, vfat, filesystem, block linaro-androidization-topic-gpio - timed gpio linaro-androidization-topic-misc - just a compass driver right now I confirmed that the diff between the original branch we issued and this new one is absolutely null, so we can be certain the reorder makes no difference to the resulting tree. You can see what's going on easiest if you look at the last branch linaro-androidization-topic-misc, which is the output of this process http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/linaro-androidization-topic-misc and work backwards, you can see it's sitting on top of the other branches in reverse order. In terms of patch counts, it's like this linaro-androidization-topic-base 38 linaro-androidization-topic-debug 34 linaro-androidization-topic-wakelock 14 linaro-androidization-topic-earlysuspend 7 linaro-androidization-topic-mem 16 linaro-androidization-topic-net-core 19 linaro-androidization-topic-netfilter 23 linaro-androidization-topic-net-wireless 120 linaro-androidization-topic-usb 79 linaro-androidization-topic-input 27 linaro-androidization-topic-cpufreq 14 linaro-androidization-topic-ion 12 linaro-androidization-topic-mmc 22 linaro-androidization-topic-bluetooth 10 linaro-androidization-topic-rtc 7 linaro-androidization-topic-pm 11 linaro-androidization-topic-binder 6 linaro-androidization-topic-fs 8 linaro-androidization-topic-gpio 3 linaro-androidization-topic-misc 1 You can see actually the biggest series is in wireless, and that's because it seems to add a couple of wireless drivers there. USB gadget-related stuff is next. If you look at say the ion topic http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/linaro-androidization-topic-ion it seems some of them could just be simplified down to a single patch or so, incorporating all the bugfixes and changes. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Activity] Toolchain WG Weekly Status report for week ending 2011-10-07
Enclosed please find the link to the Weekly Status report for the Toolchain working group for the week ending 2011-10-07 == Meeting Minutes == https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-10-03 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-10-06 == Weekly Status Report == https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2011-10-06 == Summary == General: * 64 bit atomics patch has had first round of review in GCC * GDB: reviewing disabling address space randomisation support in gdbserver * GDB: working on core file generation when using gdbserver * Toolchain Panda auto builders are now running in the validation lab. Thanks Dave! Performance: * Working on vectorising widening shifts * Working on vectorising straight line (non-loop) code * Working on cost estimation in SMS to detect regressions and disable when likely * Looking into improving -fsched-pressure. Tricky is the few new regressions * Optimising fixed to floating point conversion using VCVT Binary toolchain: * Decided on using crosstool-NG * Requirements are ready * Reviewing Windows build steps * Prototyped up a layout 2011.10 Release: * Next week is release week * Launchpad branch scanning [LP: #808930] is still broken and causing pain * No critical bugs * Need to add headlines / acceptance criteria Best regards, Mounir -- Mounir Bsaibes Project Manager Follow Linaro.org: facebook.com/pages/Linaro/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] MMWG - weekly status report - wk40.2011 (20111003-20111007)
Status report: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport Last meeting minutes are included as IRC logs in https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-10-04 == Highlights == - 1110 Blueprints planned. See the status report (link above) for a complete list. Still some headline/acceptance items are missing due to holiday period last week for some - Optimization: Started work on the libpng optimization (see blueprint listed above) - Optimization - LJT: ltj synced with upstream, work on the 565 patch, rework of some upstream discussions on LJT lib startup - Also on LJT: based on the thread started in - http://lists.linaro.org/pipermail/linaro-dev/2011-October/007983.html here are some further points + package libjpeg-turbo with v8 compatibility mode enabled: Quoting from the thread: there is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option (arithmetic coding mode defined in the JPEG spec), left out of earlier versions due to patent issues. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. When *decoding* v8 actually produces poorer results in some cases due to using dct-based upscaling of chroma planes (this is also the cause of the slowdown). + benchmark on Android platform: blueprint addresses this https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-benchmark-libjpeg-turbo + run tjbench as part of LAVA tests: this is not planned to be covered during 11.10 - UMM: Added CMA support in rpmsg driver (syslink v3), it can give us encoders for camera use case - UMM: Working on dma-buf testing code, using scatterlist and aligning with dma-buf v3, plus adding CMA support - Benchmarking on DTS work ongoing - see thread (linaro-multimedia threads: http://lists.linaro.org/pipermail/linaro-multimedia/2011-September/80.html, and http://lists.linaro.org/pipermail/linaro-multimedia/2011-October/94.html) - Fixed some NEON functions in x264 (mru) Also continuing to work on the requirements for next quarter - discussion ongoing in the team taking also feedback from the rest of Linaro. This list needs to be cleared a bit during the next few days: - https://linaro-public.papyrs.com/public/4157/MMWG2011-UCM-FOR-ANDROID/# and also blueprint https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg-ucm4android - UMM - split discussed between Jesse Barker and Kurt Taylor. Some of the MMedia folks will look into UMM work from the userspace point of view in order to enable the usage of the UMM code on the various platforms we have. - Other requirements being looked at (missing though either blueprints and/or requirements in papyrs at the moment) + Audio DTS decoding - could be tricky, involves legal aspects which need to be carefully looked at, already done in libav? + Better video rendering integration in UI, like X11 proposal for wayland, extended dri2 + Compressed data sound support (as in http://www.linuxplumbersconf.org/2011/ocw/proposals/633) - Note that there's already an API from Intel which people are relatively happy with + Realvideo on ARM (popular in China) - needs optimization for 720p playback, VGA is ok. Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg-realvideo + armv6 optimizations for vp8, and 10-bit h264 optimization, both in libav - Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg-libav + Further enhancements and optimization for LJT - Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/engr-multimedia-codec-jpeg + 3D video stream + secure streaming (like netflix) + audio library optimization + Directfb NEON optimization - Blueprint https://blueprints.launchpad.net/linaro-multimedia-project/+spec/engr-multimedia-directfb-neon-optimization + ALSA port of ST-E drivers + Audio testing will be handled as part of the more general https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#. -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris 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: [REMINDER] Linaro 11.10 release dates and deliveries
On Mon, Oct 10, 2011 at 12:47 PM, David Zinman david.zin...@linaro.org wrote: Hi, This is a mail sent to remind you the coming release dates: * Linaro 11.10 components release is October 20nd, 2011. * Linaro 11.10 RC images is October 24th, 2011. * Linaro 11.10 release is October 27th, 2011. Components release will be announced this week. As we have people working all around the world, would be good to have a common UTC time for the releases, so the platform can coordinate the integration with the component releases. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-project-management] [REMINDER] Linaro 11.10 release dates and deliveries
On 11 October 2011 06:08, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Mon, Oct 10, 2011 at 12:47 PM, David Zinman david.zin...@linaro.org wrote: Hi, This is a mail sent to remind you the coming release dates: * Linaro 11.10 components release is October 20nd, 2011. * Linaro 11.10 RC images is October 24th, 2011. * Linaro 11.10 release is October 27th, 2011. Components release will be announced this week. As we have people working all around the world, would be good to have a common UTC time for the releases, so the platform can coordinate the integration with the component releases. The common UTC time is 16:00 UTC. It applies to components release, RC and final release. It has been mentioned several time but is missing on the official process. I'm going to fix that. Cheers, Fathi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
