== Shawn Guo (shawnguo) ==
=== Device Tree ===
* Sent v2 of sdhci-pltfm&OF-consolidation which has been rebased on mmc-next
=== LTP Blueprint ===
* More discussion on K9.1 ltp-fix drafting with Paul Larson
=== Plan ===
* Attend LDS
--
Regards,
Shawn
== Deepak Saxena <dsaxena> ==
=== Highlights ===
* Started at Linaro!
* Had 1:1 meetings with Amit Kucheria, Angus, Grant, Jesse Barker,
Paul Larson, John Stultz
* Went through kernel bug backlog and pinged kernel team to revisit
and update with latest information
* Read through lots of documentation (blue print process, understading
our dev cycle, etc) in wiki
=== Plans ===
* Attend LDS
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
== Per Forlin <perfor> ==
=== Highlights ===
* Prepare blueprints for LDS
* K7.3 Non-Blocking Request in MMC
* K7.4 eMMC Background Maintenance
* K7.6 SDIO Single Function Support
* K7.10 DMA Engine on ARM
* K7.11 USB gadget mass storage
* Submit patch to optimize SDIO for single IRQ
* Submit patch v3 of nonblocking mmc with some minor fixes.
=== Plans ===
* Attending LDS
== Paul E. McKenney <paulmck> ==
=== Highlights ==
* Pre-Budapest specification work
* Submitted two smaller RCU-related patchsets to LKML.
* Submitted git pull request to Ingo Molnar for TREE_RCU priority boosting.
* Cheng Xu is working towards a fix to the related scheduler bug.
=== Highlights ===
* Had jury duty on weds, so was mostly out for that day.
* Met Deepak for 1:1 lunch meeting
* Lots of community bugs/issues coming out of the woodwork!
* Worked on debugging a boot-time delay seemingly caused by earlier
TSC refinement patch.
* Worked on time() bug found on P7 hardware
* Did a full audit of the rtc drivers to resolve issues with bad
initialization that was uncovered by my RTC infrastructure fixes
* Discussed methods for reducing xtime_lock contention
* Wrote up spec for Kconfig work
* Got two Alarmtimer fixes merged into -tip, worked with Thomas to
resolve some other minor alarmtimer issues.
=== Plans ===
* Spend time reviewing the pm_stay_awake/pm_relax code
* Try to adapt Arve's earlier RTC suggestions into the tree.
* Try to implement printk task_comm %P value
* Get Android Trivial branches cpufreq and cgroup sent out.
=== Issues ===
* Crazy number of community bugs taking lots of my time right now.
Hoping this calms down soon.
Hi all,
I am going through the Linaro kernel bug backlog to wrap my head
around the status of what that the kernel and landing team has been
working on. I made some simple notes for myself and want some input
from folks who've been involved longer to understand what should be
closed, what should remain open, and what should be re-prioritized
based on deliverables as we start up the 11.11 cycle so please speak
up with any thoughts. Some of these bugs have no assignees and since I
still need to figure out what everyone's availability and skill set
is, please speak up if there's a bug you are called to take.
Mounir, I think it'd be good for you and I to sit down towards the end
of LDS next week and do a review of all kernel bugs.
Starting with http://goo.gl/6k7GS - Importance field not set
645663 2.6.35-1006-linaro-omap occasional oops during boot
This was opened in September of last year on a very old kernel,
should be closed?
754247 2.6.38 halts under heavy load
This looks like it should be a medium priority bug and needs to be
reproduced
on a single board with serial console logged running latest Linaro kernel.
754248 Processes do not distribute across cores when running CoreMark
Related to WIP code for TI Panda board, needs re-testing with CPU_FREQ
disabled to validate. Importance should be low as it is a mostly known
issue and possibly needs to just be marked a dup if we already have
a bug tracking the CPU_FREQ development?
776856 uboot won't boot until running 'mmc part 0'
Needs to be tested/reproduced on latest U-Boot by John. I consider this
a low priority bug as developer's can still boot a board by running
'mmc part 0'.
Next, we have http://goo.gl/kfk7L - High and Medium priority bugs.
754254 imx51 randomly truncates serial input at 31 characters
Probably trivial to fix, just needs someone with HW to fix it.
Probably someone
from landing team?
615972 Neon registers missing in core files
In progress, patches merged into Linaro trees and headed upstream.
720055 CONFIG_OMAP2_DSS_SDI on OMAP4 causes...
Issue is resolved in linux-linaro-omap. Does it need to be pulled
into Nicolas'
tree to close out the linux-linaro component?
754254 imx51 randomly truncates serial input at 31 characters
Needs to be assigned to someone, likely in the Freescale Landing Team?
615974 Interrupted system call handling
Patch is in Linaro tree, needs submitting to RMK's patch system.
660639 twl driver failed to transfer msgs etc
Patch has been submitted upstream by Andy that possibly fixes the issue
but needs to be retested by Tom, original submitter and then likely added
to Linaro kernel tree if not already merged.
709245 panda: USB disk IO slow
Was assigned to Mian, will re-assign to Venkat.
712025 asoc: interface omap-mcbsp-dai hw params failed
Patch sent upstream, needs merging into Linaro kernel.
712175 OMAP Beagle C4: kernel does not reliably find SD card on boot
No update since April 04, probably want to retest on latest kernel.
717677 wifi is not recognized in latest netbook image on IGEP v2
No update since March 21st. Does this need testing on latest kernel?
762026 Problem with SMP IRQ affinity
Known issue, needs an assignee to fix.
768680 Boot does not complete on IGEP with Device Tree
Currently assigned to Grant. Grant, do you have time to dig into this or
should we reassign to someone else with access to HW?
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
On Mon, Apr 04, 2011 at 10:54:00PM -0600, Grant Likely wrote:
> On Fri, Apr 01, 2011 at 03:49:16PM +0800, Shawn Guo wrote:
> > On Thu, Mar 31, 2011 at 10:09:40AM -0600, Grant Likely wrote:
> > > On Fri, Mar 25, 2011 at 03:13:58PM +0800, Shawn Guo wrote:
> > > > After fec dt support is added, the following compile error will be
> > > > seen when building a pure non-dt kernel.
> > > >
> > > > drivers/net/fec.c: In function ‘fec_probe’:
> > > > drivers/net/fec.c:1383: error: implicit declaration of function ‘of_match_device’
> > > > drivers/net/fec.c:1383: warning: assignment makes pointer from integer without a cast
> > >
> > > Earlier today I suggested fixing this by adding an empty
> > > implementation of of_match_device, but I forgot that an .of_match
> > > pointer has been added to struct device for exactly this purpose. You
> > > can use that instead.
> > >
> > > That change is currently in mainline, but it has not been backported
> > > to the Linaro 2.6.38 tree (yet).
> > >
> > This simply is a fix to commit 54898b86fa9813313b3eb981c44610ff483b0067
> > "net/fec: add device tree matching support", which only sits on branch
> > devicetree/test-2.6.38 right now. However, .of_match is not available
> > on that tree yet. So I can not do anything until ether this patch
> > shows on devicetree/test or .of_match is back ported on
> > devicetree/test-2.6.38. Or you can simply ignore this patch since I
> > just want let you know such a compile error.
>
> Okay, of_match is in my devicetree/test branch now since I've rebased
> to 2.6.38-rc1. I'll happily take a fixup patch from you now. :-)
>
Sorry, Grant. I overlooked this reply, and noticed it when re-visiting
the thread today. I just sent an updated patch. Please take a look.
--
Regards,
Shawn
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
