A bit delayed report, but nevertheless I hope it is useful:
Links:
Weekly meetings (IRC logs)
TUE:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-06-14
THU:
http://salemcenter.dyndns.org/~fboudra/linarobot/linaro-multimedia/2011/lin…
Status link is :
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Status/2011-06-…
Highlights:
* 11.06 release: libjpeg-turbo release activity ongoing - libjpeg-turbo
and the new patches applied from android work.
* Going through past TRs which are not closed in order to reframe their
scope within the 11.11 cycle. Definition of TRs for 11.11 public plan
review, identification of engineering (work) blueprints and specs. Team
to populate the specifications. Priority given to
o openmax (krtaylor - to identify the Khronos representatives for
the survey, and to set up call with Jim and Thierry to define OpenMAX
colaboration model) as well as all member company reps from MMWG need to
find their OMX IL code and share
o memory management - robclark and benjiG to prioritize Mem Mgmt
actions from summit
* Then priority work involves
o Audio - start looking at ASoC and UCM - specifically at the panda
UCM definitions
o Codecs, libjpeg-turbo work
o NEON optimization forum: identify some topic areas and work with
kiko and krtaylor to help kick off NEON optimization forum
* Team wiki redesigned. Notable additions: glossary section - get your
self acquainted with multimedia lingo!
Upcoming Deliverables
* Draft for the public plan review
* TRs for the perusal of the team
* 11.06 release for the libjpeg-turbo work
BR,
--
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
Hi Nicolas,
Could you pull the fix for [Bug 754254] imx51 randomly truncates
serial input at 31 characters?
It extends the card CD/WP support for mx5 platforms, and adds the
board level configuration for mx51evk to fix bug 754254 on this
particular board. Other boards need to add their board level
configuration to actually enable the support.
The following changes since commit dcd71f6729fbee40d28a99cb645c979c3db7b545
ARM: footbridge: fix clock event support
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git fix-754254
Chris Ball (2):
mmc: Replace SDHCI_QUIRK_FORCE_BLK_SZ_2048 with a platform hook.
mmc: Replace SDHCI_QUIRK_NO_MULTIBLOCK with a platform hook.
Shawn Guo (9):
mmc: sdhci: make sdhci-pltfm device drivers self registered
mmc: sdhci: eliminate sdhci_of_host and sdhci_of_data
mmc: sdhci: make sdhci-of device drivers self registered
mmc: sdhci: merge two sdhci-pltfm.h into one
mmc: sdhci: change sdhci-pltfm into a module
* mmc: sdhci: fix interrupt storm from card detection
* mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared
* mmc: sdhci-esdhc-imx: remove "WP" from flag ESDHC_FLAG_GPIO_FOR_CD_WP
* mmc: sdhci-esdhc-imx: extend card_detect and write_protect support for mx5
[ The last four patches marked with '*' are the actual fixing,
and the others are prerequisite patches from mmc-next tree. ]
arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c | 3 +-
arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c | 3 +-
arch/arm/mach-imx/mach-mx25_3ds.c | 2 +
arch/arm/mach-imx/mach-pcm043.c | 2 +
arch/arm/mach-mx5/board-mx51_babbage.c | 24 ++-
.../plat-mxc/devices/platform-sdhci-esdhc-imx.c | 12 +
arch/arm/plat-mxc/include/mach/esdhc.h | 25 ++-
drivers/mmc/host/Kconfig | 49 ++--
drivers/mmc/host/Makefile | 18 +-
drivers/mmc/host/sdhci-cns3xxx.c | 44 ++++-
drivers/mmc/host/sdhci-dove.c | 43 ++++-
drivers/mmc/host/sdhci-esdhc-imx.c | 218 ++++++++++++-----
drivers/mmc/host/sdhci-esdhc.h | 3 +-
drivers/mmc/host/sdhci-of-core.c | 253 --------------------
drivers/mmc/host/sdhci-of-esdhc.c | 93 ++++++--
drivers/mmc/host/sdhci-of-hlwd.c | 67 +++++-
drivers/mmc/host/sdhci-of.h | 42 ----
drivers/mmc/host/sdhci-pltfm.c | 216 ++++++++---------
drivers/mmc/host/sdhci-pltfm.h | 90 +++++++-
drivers/mmc/host/sdhci-tegra.c | 117 +++++++---
drivers/mmc/host/sdhci.c | 32 ++-
drivers/mmc/host/sdhci.h | 2 +
include/linux/mmc/sdhci-pltfm.h | 35 ---
include/linux/mmc/sdhci.h | 8 +-
24 files changed, 763 insertions(+), 638 deletions(-)
On Mon, Jun 20, 2011 at 05:33:12PM +0530, ashishj3 wrote:
> --- a/drivers/regulator/da9052-regulator.c
> +++ b/drivers/regulator/da9052-regulator.c
> @@ -24,7 +24,7 @@
> #include <linux/mfd/da9052/reg.h>
> #include <linux/mfd/da9052/pdata.h>
>
> -/* Buck step size Macros */
> +/* Buck step size */
> #define DA9052_BUCK_PERI_3uV_STEP 100000
> #define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV 24
> #define DA9052_CONST_3uV 3000000
This appears to be an incremental patch against some previous version of
the driver. Since this driver is not yet part of Linux you need to send
it as a new patch, as a result I've not read the rest of the patch and
must once more urge you to read and follow the instructions in
SubmittingPatches.
Given the very substantial problems that this process appears to be
causing you I strongly urge you to accept the offers of help that the
Linaro team have made recently.
Meeting minutes
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-06-15
Status summary
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Status/2011-06-15
Highlights:
* Unity/NUX: getting along pretty good. Sorted out the GL errors
experienced before. Working now on bug
https://bugs.launchpad.net/unity-gles/+bug/798829. Jesse will setup a
meeting with Jay Taoko for NUX (where we are and what happens next,
syncup type of meeting). Other issue still happening is blend not
working properly - Travis has a workaround. Also a nice to have would be
the build system for unity to turn GLES on/off as necessary.
* discussed the code freeze prior to the milestone release: a
maturization period may be needed, but the duration needs to be checked
project by project. Certainly not all components need a week of freeze.
* Also discussed: the location of our releases was discussed:
tarball or debian packages. Debian packages in fact need a tarball as
starting point.
Absences this running week:
Sumit will be on training 23-28 June
Ilias will be on vac on Friday June 24
--
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris
Hi all,
I've recently become aware that a few packages are causing alignment
faults on ARM, and are relying on the alignment fixup emulation code in
the kernel in order to work.
Such faults are very expensive in terms of CPU cycles, and can generally
only result from wrong code (for example, C/C++ code which violates the
relevant language standards, assembler which makes invalid assumptions,
or functions called with misaligned pointers due to other bugs).
Currently, on a natty Ubuntu desktop image I observe no faults except
from firefox and mono-based apps (see below).
As part of the general effort to make open source on ARM better, I think
it would be great if we can disable the alignment fixups (or at least
enable logging) and work with upstreams to get the affected packages
fixed.
For release images we might want to be more forgiving, but for development
we have the option of being more aggressive.
The number of affected packages and bugs appears small enough for the
fixing effort to be feasible, without temporarily breaking whole
distros.
For ARM, we can achieve the goal by augmenting the default kernel command-
line options: either
alignment=3
Fix up each alingment fault, but also log the faulting address
and name of the offending process to dmesg.
alignment=5
Pass each alignment fault to the user process as SIGBUS (fatal
by default) and log the faulting address and name of the
offending process to dmesg.
Fault statistics cat also be obtained at runtime by reading
/proc/cpu/alignment.
For other architectures, there may be other arch-specific ways of
achieving something similar.
I'd be interested in people's views on this.
Cheers
---Dave
More background:
Two known instances of misbehaving userland apps are:
1) firefox-4.x (bug report pending)
A char array declared as a container for C++ objects is cast
directly to an object pointer type and deferenced, without
ensuring proper alignment.
By sheer luck, the presence of an extra member in the containing
class in firefox-3.x means that the char array has a different
alignment and so the faults don't occur.
2) gtk-sharp2 (https://bugs.launchpad.net/bugs/798315) (affecting
mono-based GUI apps such as banshee and tomboy)
char pointers are cast to 64-bit integer pointers and
deferenced, as an attempt at comparing string prefixes faster.
These apps typically generate hundreds or thousands of faults per session,
but not millions, but it's still quite a lot of noise in syslog.
I think these are likely to be representative of typical causes of
alignment faults: i.e., attempted optimisations which break the rules of
the language, and which only show in certain builds, or as side-effects
of routine maintenance.
Code like that is going to be a massive own goal for performance on ARM and
other architectures which fault unaligned accesses, since the resulting faults
are likely to cost thousands of cycles per instance.
Hi everyone.
I'm online but my xchat-gnome is crashing on startup. I'm trying to
figure out what might be causing this.
zyga@W510:~$ gdb xchat-gnome
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/xchat-gnome...(no debugging symbols
found)...done.
(gdb) r
Starting program: /usr/bin/xchat-gnome
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffed6fe700 (LWP 5355)]
[New Thread 0x7fffe2f8f700 (LWP 5356)]
XChat CRITICAL *** default event text failed to build!
Program received signal SIGABRT, Aborted.
0x00007ffff3f65d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff3f65d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff3f69ab6 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000045cfc0 in pevent_make_pntevts ()
#3 0x0000000000460a0f in ?? ()
#4 0x0000000000461535 in main ()
(gdb)
Best regards
ZK
How significant is the cache maintenance over head?
It depends, the eMMC are much faster now
compared to a few years ago and cache maintenance cost more due to
multiple cache levels and speculative cache pre-fetch. In relation the
cost for handling the caches have increased and is now a bottle neck
dealing with fast eMMC together with DMA.
The intention for introducing none blocking mmc requests is to minimize the
time between a mmc request ends and another mmc request starts. In the
current implementation the MMC controller is idle when dma_map_sg and
dma_unmap_sg is processing. Introducing none blocking mmc request makes it
possible to prepare the caches for next job parallel with an active
mmc request.
This is done by making the issue_rw_rq() none blocking.
The increase in throughput is proportional to the time it takes to
prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
a request and how fast the memory is. The faster the MMC/SD is
the more significant the prepare request time becomes. Measurements on U5500
and Panda on eMMC and SD shows significant performance gain for large
reads when running DMA mode. In the PIO case the performance is unchanged.
There are two optional hooks pre_req() and post_req() that the host driver
may implement in order to move work to before and after the actual mmc_request
function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
the dma descriptor and post_req runs the dma_unmap_sg.
Details on measurements from IOZone and mmc_test:
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
Changes since v4:
* rebase on top of linux 3.0
Per Forlin (12):
mmc: add none blocking mmc request function
omap_hsmmc: use original sg_len for dma_unmap_sg
omap_hsmmc: add support for pre_req and post_req
mmci: implement pre_req() and post_req()
mmc: mmc_test: add debugfs file to list all tests
mmc: mmc_test: add test for none blocking transfers
mmc: add member in mmc queue struct to hold request data
mmc: add a block request prepare function
mmc: move error code in mmc_block_issue_rw_rq to a separate function.
mmc: add a second mmc queue request member
mmc: test: add random fault injection in core.c
mmc: add handling for two parallel block requests in issue_rw_rq
drivers/mmc/card/block.c | 534 ++++++++++++++++++++++++-----------------
drivers/mmc/card/mmc_test.c | 361 +++++++++++++++++++++++++++-
drivers/mmc/card/queue.c | 184 +++++++++-----
drivers/mmc/card/queue.h | 33 ++-
drivers/mmc/core/core.c | 165 ++++++++++++-
drivers/mmc/core/debugfs.c | 5 +
drivers/mmc/host/mmci.c | 146 ++++++++++-
drivers/mmc/host/mmci.h | 8 +
drivers/mmc/host/omap_hsmmc.c | 90 +++++++-
include/linux/mmc/core.h | 6 +-
include/linux/mmc/host.h | 24 ++
lib/Kconfig.debug | 11 +
12 files changed, 1237 insertions(+), 330 deletions(-)
--
1.7.4.1