* Discussion to generalize the maintenance process of kernel branches
> for the periodic Linaro releases. This still needs documenting in the
> wiki.
>
> * Merged a set of patches put together by Anand Gadiyar to add display
> support to the PandaBoard.
>
> * Merged the following additional patches:
>
> * d983450 cpufreq: Add documentation for sampling_down_factor
> * 054fcd5 ARM: S5P: Fix end address in memory resource information for UART devices
> * bf47520 ARM: make SWP emulation explicit on !CPU_USE_DOMAINS
> * 459967a ARM: fixup SMP alternatives in modules
> * 7144fbc ARM: 6654/1: perf/oprofile: fix off-by-one in stack check
> * 067dfdf ARM: 6659/1: Thumb-2: Make CONFIG_OABI_COMPAT depend on !CONFIG_THUMB2_KERNEL
> * cc0f308 ARM: 6656/1: hw_breakpoint: avoid UNPREDICTABLE behaviour when reading DBGDSCR
> * 40ef21c ARM: 6657/1: hw_breakpoint: fix ptrace breakpoint advertising on unsupported arch
> * 9e97118 ARM: ptrace: remove single-step emulation code
>
== Upstream oriented activities ==
* Review of Arnd Bergmann's flash card article for LWN.
* Incorporation of feedback to the patch adding Thumb2 support to the
P2V branch.
* Another look at the Thumb-2 compatibility fixes for OMAP from Dave
Martin.
* Review of a patch series adding support for SDHCI v3.00.
* Posted patches:
* Rework of the kernel decompressor code to improve efficiency
* Removal of the 4x expansion presumption while decompressing the kernel
* kprobes insn decoding fix
* Ignore mdesc->boot_params if out of range
* Fold lookup_machine_type() into setup_machine()
== Linaro kernel activities ==
* Looked at some bugs:
* Bug 660811
* Bug 720055
* Merged 2.6.37.1 into linaro-2.6.37
* Merged Dave Martin's Thumb2 compatibility patches for OMAP.
* Merged core ARM ffixes from RMK.
* Merged OMAP fixes from Tony Lindgren.
* Opened up the linaro-2.6.38 branch.
Nicolas
Hi,
I am working on minimizing the latency between two block requests in
the mmc framework. The approach is simple. If there are more than one
request in the block queue the 2nd request will be prepared while the
1st request is being transfered. When the 1 st request is completed
the 2nd request will start with minimal latency cost.
For writes this work fine:
root@(none):/ dd of=/dev/mmcblk0p2 if=/dev/zero bs=4k count=2560
2560+0 records in
2560+0 records out
root@(none):/ dmesg
[mmc_queue_thread] req d97a2ac8 blocks 1024
[mmc_queue_thread] req d97a2ba0 blocks 1024
[mmc_queue_thread] req d97a2c78 blocks 1024
[mmc_queue_thread] req d97a2d50 blocks 1024
[mmc_queue_thread] req d97a2e28 blocks 1024
[mmc_queue_thread] req d97a2f00 blocks 1024
[mmc_queue_thread] req d954c9b0 blocks 1024
[mmc_queue_thread] req d954c800 blocks 1024
[mmc_queue_thread] req d954c728 blocks 1024
[mmc_queue_thread] req d954c650 blocks 1024
[mmc_queue_thread] req d954c578 blocks 1024
[mmc_queue_thread] req d954c4a0 blocks 1024
[mmc_queue_thread] req d954c8d8 blocks 1024
[mmc_queue_thread] req d954c3c8 blocks 1024
[mmc_queue_thread] req d954c2f0 blocks 1024
[mmc_queue_thread] req d954c218 blocks 1024
[mmc_queue_thread] req d954c140 blocks 1024
[mmc_queue_thread] req d954c068 blocks 1024
[mmc_queue_thread] req d954cde8 blocks 1024
[mmc_queue_thread] req d954cec0 blocks 1024
mmc block queue is never empty. All the mmc request preparations can
run in parallel with an ongoing transfer.
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req (null) blocks 0
"req (null)" indicates there are no requests pending in the mmc block
queue. This is expected since there are no more requests to process.
For reads on the other hand it look like this
root@(none):/ dd if=/dev/mmcblk0 of=/dev/null bs=4k count=256
256+0 records in
256+0 records out
root@(none):/ dmesg
[mmc_queue_thread] req d954cec0 blocks 32
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 64
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 128
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req (null) blocks 0
There are never more than one read request in the mmc block queue. All
the mmc request preparations will be serialized and the cost for this
is roughly 10% lower bandwidth (verified on ARM platforms ux500 and
Pandaboard).
> page_not_up_to_date:
> /* Get exclusive access to the page ... */
> error = lock_page_killable(page);
I looked at the code in do_generic_file_read(). lock_page_killable
waits until the current read ahead is completed.
Is it possible to configure the read ahead to push multiple read
request to the block device queue?
Thanks,
Per
Without device_type property set as memory for the node, the generated
dtb can still work when it gets passed to kernel by u-boot, since
u-boot will fix it up. But kernel will not boot due to that it fails
to parse the memory node, when the dtb is appended to kernel image as
it is.
The patch adds a property device_type="memory" for memory node to fix
the problem.
Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org>
---
It applies on branch devicetree/test.
arch/arm/boot/dts/babbage.dts | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/babbage.dts b/arch/arm/boot/dts/babbage.dts
index 8f9b47c..4805168 100644
--- a/arch/arm/boot/dts/babbage.dts
+++ b/arch/arm/boot/dts/babbage.dts
@@ -21,6 +21,7 @@
interrupt-parent = <&tzic>;
memory {
+ device_type = "memory";
reg = <0x90000000 0x20000000>;
};
--
1.7.4.1
Andy Green has worked on a set of patches adding many features to OMAP4
such as HDMI audio/video, FM receiver, etc. Before I merge that into
the Linaro kernel tree I need some assurance that this won't break
existing OMAP3 support, especially video. The branch is available in
the linux-linaro-2.6.38 Git repository on git.linaro.org, in the
"testing" branch.
So please if you have an OMAP3 board and can perform some testing that
would be appreciated.
Nicolas
I have created the UDS-session blueprints (blueprints to schedule the UDS
sessions) as
discussed in the meeting this morning. Take a look at the sessions
specially the ownership
and make sure you agree, you will have to run the session at UDS if you are
the assignee (owner).
As it turned out, each major Technical Requirement will have one session,
with the exception of k1
where k1.1 (fix arm/linus interface) will have 5 daily sessions. So, most
of the sessions cover
multiple topics, you may need have to co-ordinate with others to run your
session.
https://wiki.linaro.org/WorkingGroups/Kernel/Cycle11.11SessionsSetup
Paul,
you need to approve all these blueprints in order to start scheduling them.
Grant,
You have registered sessions for boot architecture and DT, please send me
the blueprints links so I can add them to this table.
Regards,
Mounir
== John Stultz <jstultz_vm> ==
=== Highlights ===
* Posix Alarm Timers were pulled into -tip for 2.6.40!
* However, some config related build issues were discovered, but
I've sent a proposed fix to handle it.
* Arve from Google commented on one of the Alarm Timer patches,
suggesting a way to avoid error accumulation each suspend/resume cycle.
* Reviewed Andy Green's slides for his talk and provided feedback.
* Submitted the virtual battery driver, which is an out of tree patch
in the Linaro+Android kernel tree, for review on lkml. After feedback
from maintainer, I worked to merge the same functionality into the
test_power driver and submitted that for inclusion.
* Worked on Android Kernel Blueprints/Specs
* Got some complaints on an old patch of mine that changed some of the
task->comm locking rules, so submitted a rough draft patch on how to
address the issue. Currently in discussion there.
* Submitted Linux Plumbers conf BoF on Kconfig fragment work queued for
11.11 cycle
=== Plans ===
* Handle any last minute alarmtimer changes for -tip.
* Try to adapt Arve's RTC suggestions into the tree.
* Take another shot at the task->comm issue.
* Continue working on the trivial tree to send out cpufreq and cgroup
branches.
* Follow up on the trivial tree patches sent out this week.
* Try to get time to look at ADB support for Android kernels
=== Issues ===
* I've got Jury Duty on Weds, so will be out for most of the day.
Hi,
I am working on minimizing the latency between two block requests in
the mmc framework. The approach is simple. If there are more than one
request in the block queue the 2nd request will be prepared while the
1st request is being transfered. When the 1 st request is completed
the 2nd request will start with minimal latency cost.
For writes this work fine:
root@(none):/ dd of=/dev/mmcblk0p2 if=/dev/zero bs=4k count=2560
2560+0 records in
2560+0 records out
root@(none):/ dmesg
[mmc_queue_thread] req d97a2ac8 blocks 1024
[mmc_queue_thread] req d97a2ba0 blocks 1024
[mmc_queue_thread] req d97a2c78 blocks 1024
[mmc_queue_thread] req d97a2d50 blocks 1024
[mmc_queue_thread] req d97a2e28 blocks 1024
[mmc_queue_thread] req d97a2f00 blocks 1024
[mmc_queue_thread] req d954c9b0 blocks 1024
[mmc_queue_thread] req d954c800 blocks 1024
[mmc_queue_thread] req d954c728 blocks 1024
[mmc_queue_thread] req d954c650 blocks 1024
[mmc_queue_thread] req d954c578 blocks 1024
[mmc_queue_thread] req d954c4a0 blocks 1024
[mmc_queue_thread] req d954c8d8 blocks 1024
[mmc_queue_thread] req d954c3c8 blocks 1024
[mmc_queue_thread] req d954c2f0 blocks 1024
[mmc_queue_thread] req d954c218 blocks 1024
[mmc_queue_thread] req d954c140 blocks 1024
[mmc_queue_thread] req d954c068 blocks 1024
[mmc_queue_thread] req d954cde8 blocks 1024
[mmc_queue_thread] req d954cec0 blocks 1024
mmc block queue is never empty. All the mmc request preparations can
run in parallel with an ongoing transfer.
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req (null) blocks 0
"req (null)" indicates there are no requests pending in the mmc block
queue. This is expected since there are no more requests to process.
For reads on the other hand it look like this
root@(none):/ dd if=/dev/mmcblk0 of=/dev/null bs=4k count=256
256+0 records in
256+0 records out
root@(none):/ dmesg
[mmc_queue_thread] req d954cec0 blocks 32
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 64
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 128
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cde8 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req d954cec0 blocks 256
[mmc_queue_thread] req (null) blocks 0
[mmc_queue_thread] req (null) blocks 0
There are never more than one read request in the mmc block queue. All
the mmc request preparations will be serialized and the cost for this
is roughly 10% lower bandwidth (verified on ARM platforms ux500 and
Pandaboard).
> page_not_up_to_date:
> /* Get exclusive access to the page ... */
> error = lock_page_killable(page);
I looked at the code in do_generic_file_read(). lock_page_killable
waits until the current read ahead is completed.
Is it possible to configure the read ahead to push multiple read
request to the block device queue?
Thanks,
Per
Hi Jerry & Wolfgang,
The following series fixes a bug in the device tree code and
eliminates the CONFIG_OF_LIBFDT dependency on CONFIG_SYS_BOOTMAPSZ.
It also adds parsing of the reserved mem regions so that U-Boot
doesn't decide to use a regions set aside for another purpose.
Finally, the last patch adds CONFIG_OF_LIBFDT to a bunch of boards.
I'm not expecting the last patch to be picked up in mainline (yet),
but it will be picked up into the Linaro tree for the 11.05 release.
John, this same series applies cleanly on the linaro-stable u-boot
tree. Can you pick them up please? Or would you prefer me to send
you a pull request?
g.
---
Grant Likely (6):
Stop passing around bootmem_base value.
Default to bootm_size() when CONFIG_SYS_BOOTMAPSZ is not defined
Remove device tree booting dependency on CONFIG_SYS_BOOTMAPSZ
Fix off-by-one error in passing initrd end address via device tree
Respect memreserve regions specified in the device tree
Add CONFIG_OF_LIBFDT to more boards.
README | 16 ++++++++-
arch/arm/lib/bootm.c | 5 ++-
arch/m68k/lib/bootm.c | 7 +---
arch/powerpc/lib/bootm.c | 19 +++++-----
common/cmd_bootm.c | 7 ++--
common/fdt_support.c | 2 +
common/image.c | 72 +++++++++++++++++++++++++++++----------
include/configs/ca9x4_ct_vxp.h | 2 +
include/configs/devkit8000.h | 2 +
include/configs/efikamx.h | 2 +
include/configs/igep0020.h | 2 +
include/configs/igep0030.h | 2 +
include/configs/mx51evk.h | 2 +
include/configs/mx53evk.h | 2 +
include/configs/omap3_beagle.h | 7 ----
include/configs/omap3_overo.h | 2 +
include/configs/omap3_pandora.h | 2 +
include/configs/omap3_sdp3430.h | 2 +
include/configs/omap3_zoom1.h | 2 +
include/configs/omap3_zoom2.h | 2 +
include/configs/omap4_panda.h | 2 +
include/configs/omap4_sdp4430.h | 2 +
include/configs/tegra2-common.h | 1 +
include/image.h | 10 +++--
24 files changed, 122 insertions(+), 52 deletions(-)
--
Signature
