linaro-kernel

linaro-kernel@lists.linaro.org

10094 discussions

[ACTIVITY] (Deepak Saxena) 2011-05-09 - 2011-05-13

by Deepak Saxena

== Deepak Saxena <dsaxena> == === Highlights === * Attended LDS === Plans === * Summarize blueprint next steps for kernel team & put together and send off first pass of 11.11 assignments/priorities for team review * Start coordinating 1:1s with team members * Meetings: platform team, release, kernel team meeting planning with Mounir * Follow up with Nicolas on monthly kernel drops

13 years, 11 months

[ACTIVITY] (Per Forlin) 2011-05-09 - 2011-05-13

by Per Forlin

== Per Forlin <perfor> == === Highlights === * Attending LDS * SDIO single IRQ patch merged === Plans === * Update blueprints * Submit mmc async patch with common parallel request handling in core.c * 2 days absence planned for this week due to child with otitis

13 years, 11 months

[ACTIVITY] (John Stultz) May 9th-13th

by John Stultz

=== Highlights === * Did a full audit of the RTC drivers to catch boot time hangs due to un-initialized drvdata. * Submitted along with revised fixes from community for 2.6.39. * Thomas merged them into -tip * Sent out updated v2 of task->comm locking patch queue, with %ptc printk formatting method * Got good feedback, and sent out v3 patchset as well * Attended LDS Android upstreaming meeting remotely * 3-5minute audio lag was a problem * Submitted time() fix for 2.6.32-longterm * Worked with IBMer on suspend-blocker-like driver being used to keep systems from suspending while firmware updates are running * Spent time reading over and trying to make use of pm_stay_awake/pm_relax api * So far, no luck. Mailed Rafael with questions. * Updated Linaro+Android kernel git tree. === Plans === * Continue to push task->comm fixes in * Continue working on pm_stay_awake/pm_relax infrastructure * Try to adapt Arve's earlier RTC suggestions into suspend/resume path * Catch up on LDS discussions I missed. === Issues === * NA

13 years, 11 months

REMINDER: kernel and landing team discussion at 2pm in room jozsef

by Deepak Saxena

13 years, 11 months

*** Kernel meetings schedule changes ***

by Deepak Saxena

Hi all, I have a couple of schedule changes for tomorrow to announce: 1. The kernel wg + landing team discussion has been moved from 5pm to 2pm in the TAS room. Scott B. synced up with me and Nicolas is leaving at 4pm and it is critical that he be involved in this discussion hence the move. 2. The kernel working group team meeting that was scheduled for 2pm tomorrow obviously not happening at the same time and will be reschedule for a different time and send out and update. Thanks, ~Deepak

13 years, 11 months

ARM subarchitecture maintainership meeting: noon today Budapest time, Ond (Room 19)

by Paul E. McKenney

Hello! Demonstrating dynamic scheduling due to the inevitable conflicts... The meeting to discuss upstreaming has been moved from Tuesday 10AM to Monday at noon. It is in the Ond meeting room (room 19). Thanx, Paul

13 years, 11 months

[ACTIVITY] (Shawn Guo) 2011-05-02 - 2011-05-06

by Guo Shawn-R65073

== 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

13 years, 11 months

[ACTIVITY] (Deepak Saxena) 2011-05-02 - 2011-05-06

by Deepak Saxena

== 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

13 years, 11 months

mmc blkqueue is empty even if there are pending reads in do_generic_file_read()

by Per Forlin

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

13 years, 11 months

[ACTIVITY] (Per Forlin) 2011-05-02 - 2011-05-06

by Per Forlin

== 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

13 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel