linaro-kernel April 2011

linaro-kernel@lists.linaro.org

37 participants
56 discussions

[PATCH] mmc: sdhci: add support for pre_req and post_req

by Shawn Guo

pre_req() runs dma_map_sg() post_req() runs dma_unmap_sg. If not calling pre_req() before sdhci_request(), request() will prepare the cache just like it did it before. It is optional to use pre_req() and post_req(). Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- I worked out the patch by referring to Per's patch below. omap_hsmmc: add support for pre_req and post_req It adds pre_req and post_req support for sdhci based host drivers to work with Per's non-blocking optimization. But I only have imx esdhc based hardware to test. Unfortunately, I can not measure the performance gain using mmc_test, because the current esdhc driver on mainline fails on the test. So I just did a quick test using 'dd', but sadly, I did not see noticeable performance gain here. The followings are possible reasons I can think of right away. * The patch did not add pre_req and post_req correctly. Please help review to catch the mistakes if any. * The imx esdhc driver uses SDHCI_SDMA (max_segs is 1) than SDHCI_ADAM (max_segs is 128), due to the broken ADMA support on imx esdhc. So can people holding other sdhci based hardware give a try on the patch? Hopefully, I can find some time to have a close look at the mmc_test failure and the broken ADMA with imx esdhc. Regards, Shawn drivers/mmc/host/sdhci.c | 95 ++++++++++++++++++++++++++++++++++++++------ include/linux/mmc/sdhci.h | 7 +++ 2 files changed, 89 insertions(+), 13 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 9e15f41..becce9a 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -408,6 +408,44 @@ static void sdhci_set_adma_desc(u8 *desc, u32 addr, int len, unsigned cmd) dataddr[0] = cpu_to_le32(addr); } +static int sdhci_pre_dma_transfer(struct sdhci_host *host, + struct mmc_data *data, + struct sdhci_next *next) +{ + int sg_count; + + if (!next && data->host_cookie && + data->host_cookie != host->next_data.cookie) { + printk(KERN_WARNING "[%s] invalid cookie: data->host_cookie %d" + " host->next_data.cookie %d\n", + __func__, data->host_cookie, host->next_data.cookie); + data->host_cookie = 0; + } + + /* Check if next job is already prepared */ + if (next || + (!next && data->host_cookie != host->next_data.cookie)) { + sg_count = dma_map_sg(mmc_dev(host->mmc), data->sg, + data->sg_len, + (data->flags & MMC_DATA_WRITE) ? + DMA_TO_DEVICE : DMA_FROM_DEVICE); + } else { + sg_count = host->next_data.sg_count; + host->next_data.sg_count = 0; + } + + if (sg_count == 0) + return -EINVAL; + + if (next) { + next->sg_count = sg_count; + data->host_cookie = ++next->cookie < 0 ? 1 : next->cookie; + } else + host->sg_count = sg_count; + + return sg_count; +} + static int sdhci_adma_table_pre(struct sdhci_host *host, struct mmc_data *data) { @@ -445,9 +483,8 @@ static int sdhci_adma_table_pre(struct sdhci_host *host, goto fail; BUG_ON(host->align_addr & 0x3); - host->sg_count = dma_map_sg(mmc_dev(host->mmc), - data->sg, data->sg_len, direction); - if (host->sg_count == 0) + host->sg_count = sdhci_pre_dma_transfer(host, data, NULL); + if (host->sg_count < 0) goto unmap_align; desc = host->adma_desc; @@ -587,8 +624,9 @@ static void sdhci_adma_table_post(struct sdhci_host *host, } } - dma_unmap_sg(mmc_dev(host->mmc), data->sg, - data->sg_len, direction); + if (!data->host_cookie) + dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, + direction); } static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_data *data) @@ -757,11 +795,7 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data) } else { int sg_cnt; - sg_cnt = dma_map_sg(mmc_dev(host->mmc), - data->sg, data->sg_len, - (data->flags & MMC_DATA_READ) ? - DMA_FROM_DEVICE : - DMA_TO_DEVICE); + sg_cnt = sdhci_pre_dma_transfer(host, data, NULL); if (sg_cnt == 0) { /* * This only happens when someone fed @@ -850,9 +884,11 @@ static void sdhci_finish_data(struct sdhci_host *host) if (host->flags & SDHCI_USE_ADMA) sdhci_adma_table_post(host, data); else { - dma_unmap_sg(mmc_dev(host->mmc), data->sg, - data->sg_len, (data->flags & MMC_DATA_READ) ? - DMA_FROM_DEVICE : DMA_TO_DEVICE); + if (!data->host_cookie) + dma_unmap_sg(mmc_dev(host->mmc), data->sg, + data->sg_len, + (data->flags & MMC_DATA_READ) ? + DMA_FROM_DEVICE : DMA_TO_DEVICE); } } @@ -1116,6 +1152,35 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power) * * \*****************************************************************************/ +static void sdhci_pre_req(struct mmc_host *mmc, struct mmc_request *mrq, + bool is_first_req) +{ + struct sdhci_host *host = mmc_priv(mmc); + + if (mrq->data->host_cookie) { + mrq->data->host_cookie = 0; + return; + } + + if (host->flags & SDHCI_REQ_USE_DMA) + if (sdhci_pre_dma_transfer(host, mrq->data, &host->next_data) < 0) + mrq->data->host_cookie = 0; +} + +static void sdhci_post_req(struct mmc_host *mmc, struct mmc_request *mrq, + int err) +{ + struct sdhci_host *host = mmc_priv(mmc); + struct mmc_data *data = mrq->data; + + if (host->flags & SDHCI_REQ_USE_DMA) { + dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, + (data->flags & MMC_DATA_WRITE) ? + DMA_TO_DEVICE : DMA_FROM_DEVICE); + data->host_cookie = 0; + } +} + static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq) { struct sdhci_host *host; @@ -1285,6 +1350,8 @@ out: } static const struct mmc_host_ops sdhci_ops = { + .pre_req = sdhci_pre_req, + .post_req = sdhci_post_req, .request = sdhci_request, .set_ios = sdhci_set_ios, .get_ro = sdhci_get_ro, @@ -1867,6 +1934,8 @@ int sdhci_add_host(struct sdhci_host *host) if (caps & SDHCI_TIMEOUT_CLK_UNIT) host->timeout_clk *= 1000; + host->next_data.cookie = 1; + /* * Set host parameters. */ diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h index 83bd9f7..924e84b 100644 --- a/include/linux/mmc/sdhci.h +++ b/include/linux/mmc/sdhci.h @@ -17,6 +17,11 @@ #include <linux/io.h> #include <linux/mmc/host.h> +struct sdhci_next { + unsigned int sg_count; + s32 cookie; +}; + struct sdhci_host { /* Data set by hardware interface driver */ const char *hw_name; /* Hardware bus name */ @@ -145,6 +150,8 @@ struct sdhci_host { unsigned int ocr_avail_sd; unsigned int ocr_avail_mmc; + struct sdhci_next next_data; + unsigned long private[0] ____cacheline_aligned; }; #endif /* __SDHCI_H */ -- 1.7.4.1

13 years

blueprints step by step

by Mounir Bsaibes

I have created a step by step how to create a blueprint, specification and how to make a Technical Requirement blueprint dependant on the engineering blueprint. This is meant to be for new assignees or as a refresher. If you are comfortable in creating blueprints and know the process, you can ignore this note. https://wiki.linaro.org/WorkingGroups/Kernel/GettingStarted/blueprintStepby… If you need clarification on the steps or recommendation for enhancement to this step-by-step, please let me know. Regards, Mounir

13 years

[ACTIVITY] (Arnd Bergmann) 2011-04-18 - 2011-04-21

by Arnd Bergmann

* Spent the entire week catching up on email that accumulated during ELC * DMA memory management * MMC patch review * AXI bus driver * UIO * PTP * macvtap

13 years

[ACTIVITY] (Per Forlin) 2011-04-18 - 2011-04-22

by Per Forlin

== Per Forlin <perfor> == === Highlights === * Discussing mmc nonblock implementation on mmc-mailing list. * Studied block layer and found out that block read request for mmc are often added one by one to the mmc blockdev, this is not the case for scsi disk blockdev. === Absence === 3 days off due to Eastern holiday and chicken pox === Plans === * Make draft for 11.11 specs * Try out different configurations for io-sched

13 years

[ACTIVITY] April 18 - April 22

by Jason Hui

== Jason Liu <Jasnliu> == === Highlights === ====Misc==== * Some u-boot patch upsreaming: MX5: Keep L2 cache enabled before jump to kernel http://lists.denx.de/pipermail/u-boot/2011-April/090437.html MX5: clock: Add clock config interface http://lists.denx.de/pipermail/u-boot/2011-April/090438.html PMIC: Add dialog pmic support http://lists.denx.de/pipermail/u-boot/2011-April/090440.html MX53: loco: Add power init support http://lists.denx.de/pipermail/u-boot/2011-April/090441.html === Plans === * ===Issues=== *

13 years

[ACTIVITY] (Shawn Guo) 2011-04-18 - 2011-04-22

by Shawn Guo

== Device Tree == * The .dtb support has been available in hwpack daily build and lmc v0.0.4. Tested it on mx51 babbage and it works out of box. * With the help from Dave and Nico, the failure of John Bonesio's append-dtb patch on babbage was killed. It's caused by the use of static variable in uncompressed.h, which will not be relocated because it's not in .bss section. * Caught the problem of babbage.dtb memory node, which misses 'device_type' property. == Non-blocking MMC testing == * Added pre_req and post_req for SDHCI driver, but did not see performance gain on mx51 esdhc. No comments from Per Forlin on that so far. * Added pre_req and post_req for for mxs-mmc driver and saw ~4% performance improvement at the best case. Per Forlin gave some comments saying pre_req and post_req were not added correctly. But I do not completely understand his comments and asked him for clarification. No further response yet so far. == Misc == * Respond to Wolfram's comments on sdhci-pltfm&of-consolidation patch set. Will work on the v2 next week. * Reviewed a few mxs/mxc patches. -- Regards, Shawn

13 years

[ACTIVITY] (John Stultz) April 18th - 22nd

by john stultz

== John Stultz <jstultz_vm> == === Highlights === * Pushed out updated Linaro Android tree which resolves the omap3 USB issue and supports HDMI output on PandaBoard, allowing the Android UI to now function on Panda. * Sent out the Posix Alarm Timers patch queue to lkml for review/inclusion. * Rebuilt the Android Trivial tree from latest Android tree: http://git.linaro.org/gitweb?p=people/jstultz/android-trivial.git;a=summary * Sent out an MM patch for review from the Android Trivial Tree. * Sent out six MMC patches for review from the Android Trivial Tree. * Sent clocksource cleanup patch to Magnus Damm to follow up on a conversation we had at ELC. * Submitted a LPC BoF discussion on Kconfig fragments for internal review. * Reviewed and commented on Paul's ASDF presentation * Sent some background info and links to slides to Andy Green for his Android talk in Taiwan. * Synced with Paul about ELC discussions. === Plans === * Continue working on the trivial tree to send out cpufreq and cgroup branches. * Follow up on the trivial tree patches sent out this week. * Nag tglx to queue the Alarm Timers for 2.6.40 * Try to send the virtual battery driver in linaro+android tree out for review. * Try to get time to look at ADB support for Android kernels === Issues === * None.

13 years

[ACTIVITY] (Paul E. McKenney) 2011-04-18 - 2011-04-22

by Paul E. McKenney

== Paul E. McKenney <paulmck> == === Highlights == * Working RCU priority boosting bug: Cheng Xu encountered same bug with user-level program, so this is officially a scheduler bug. Fortunately, my workarounds still are working. * Sent Sedat Dilek two sets of diagnostics thus far, working up a third set. Problem is in wake-up path for per-CPU kthread. * Email and IRC with Thomas Gleixner, Andrew Morton, and Linus Torvalds on maintainership issue. * Interviewed two candidates for Kernel WG, both are +1. A third candidate was no-show. Will set up interview with fourth candidate as soon as I receive contact information. * Pre-Budapest definition/scheduling work. * Met with the incoming Kernel WG lead to review draft plans (which is only fair, given that he will be leading them up). We will put a transition plan together in Budapest. * Debriefed John Stultz on his meeting with the Android guys. John's discussions unearthed an additional suspend-blocker requirement, which I added to the list at [[https://wiki.linaro.org/WorkingGroup/KernelConsolidation/Projects/AndroidSu…. == Miscellaneous == * Another iteration on Lai Jiangshan's RCU_PREEMPT inlining patches

13 years

ASoC conference

by Loïc Minier

Hey Just came across this ASoC end Embedded ALSA Conference: http://www.slimlogic.co.uk/?p=268 Anybody interested in going? Cheers, -- Loïc Minier

13 years

Question on compressed vmlinux .got and .bss sections

by Shawn Guo

Hi toolchain, kernel folks, I'm seeing an interesting thing on .got and .bss sections of arch/arm/boot/compressed/vmlinux, and really need your expertise to shed some lights. I have an uninitialized variable 'uart_base' defined in misc.c. static unsigned long uart_base; $ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o Disassembly of section .bss: 00000000 <uart_base>: 0: 00000000 andeq r0, r0, r0 00000004 <__machine_arch_type>: 4: 00000000 andeq r0, r0, r0 [...] And section layout looks like the following. $ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux SECTIOINS { ... _etext = .; _got_start = .; .got : { *(.got) } _got_end = .; .got.plt : { *(.got.plt) } _edata = .; . = ALIGN(4); __bss_start = .; .bss : { *(.bss) } _end = .; ... } $ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux arch/arm/boot/compressed/vmlinux: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 001c474c 00000000 00000000 00008000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .got 00000028 001c474c 001c474c 001cc74c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .got.plt 0000000c 001c4774 001c4774 001cc774 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .bss 00000020 001c4780 001c4780 001cc780 2**2 ALLOC 4 .stack 00001000 001c47a0 001c47a0 001cc780 2**0 ALLOC 5 .comment 0000002a 00000000 00000000 001cc780 2**0 CONTENTS, READONLY 6 .ARM.attributes 00000031 00000000 00000000 001cc7aa 2**0 CONTENTS, READONLY I'm able to see uart_base in vmlinux objdump ... $ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux [relevant only, and sorted] 00000000 l d .text 00000000 .text 001c474c l d .got 00000000 .got 001c4774 l d .got.plt 00000000 .got.plt 001c4780 l d .bss 00000000 .bss 003968e4 g *ABS* 00000000 _image_size 001c474c g *ABS* 00000000 _got_start 001c4774 g *ABS* 00000000 _got_end 001c4780 g *ABS* 00000000 _edata 001c4780 g *ABS* 00000000 __bss_start 001c4780 l O .bss 00000004 uart_base 001c4798 g O .bss 00000004 malloc_ptr 001c478c g O .bss 00000004 output_ptr 001c479c g O .bss 00000004 malloc_count 001c4794 g O .bss 00000004 free_mem_end_ptr 001c4788 g O .bss 00000004 output_data 001c4784 g O .bss 00000004 __machine_arch_type 001c4790 g O .bss 00000004 free_mem_ptr 001c47a0 g *ABS* 00000000 _end ... but I can not see it in the zImage (all others in .bss seem still there). $ xxd arch/arm/boot/zImage | tail 01c4740: 3ef1 1400 be52 9f58 e468 3900 4c47 1c00 >....R.X.h9.LG.. ^_got_start (why is it?) 01c4750: 9847 1c00 1043 0000 8c47 1c00 9c47 1c00 .G...C...G...G.. ^malloc_ptr ^output_ptr 01c4760: 9447 1c00 080a 0000 8847 1c00 8447 1c00 .G.......G...G.. ^free_mem_end_ptr ^__machine_arch_type 01c4770: 9047 1c00 0000 0000 0000 0000 0000 0000 .G.............. ^free_mem_ptr The following is a run-time memdump at _got_start. Before recalculation: 9056304C: 001C474C 001C4798 00004310 001C478C 001C479C 001C4794 00000A08 001C4788 ^_got_start (why is it?) 9056306C: 001C4784 001C4790 00000000 00000000 00000000 EDFE0DD0 4C010000 38000000 After recalculation (for .bss entries, the delta is 9039EA50, for others in .got, delta is 9039E900): 9056304C: 9056304C 905631E8 903A2C10 905631DC 905631EC 905631E4 9039F308 905631D8 9056306C: 905631D4 905631E0 00000000 00000000 00000000 73FBC000 4C010000 38000000 QUESTION: Where is the .bss section of uart_base? Now, I remove the 'static' to have 'unsigned long uart_base', and dump the same stuff to compare. $ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o Disassembly of section .bss: 00000000 <__machine_arch_type>: 0: 00000000 andeq r0, r0, r0 00000004 <uart_base>: 4: 00000000 andeq r0, r0, r0 I'm able to see uart_base in vmlinux objdump ... $ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux [relevant only, and sorted] 00000000 l d .text 00000000 .text 001c4720 l d .got 00000000 .got 001c474c l d .got.plt 00000000 .got.plt 001c4758 l d .bss 00000000 .bss 003968e4 g *ABS* 00000000 _image_size 001c4720 g *ABS* 00000000 _got_start 001c474c g *ABS* 00000000 _got_end 001c4758 g *ABS* 00000000 _edata 001c4758 g *ABS* 00000000 __bss_start 001c475c g O .bss 00000004 uart_base 001c4770 g O .bss 00000004 malloc_ptr 001c4764 g O .bss 00000004 output_ptr 001c4774 g O .bss 00000004 malloc_count 001c476c g O .bss 00000004 free_mem_end_ptr 001c4760 g O .bss 00000004 output_data 001c4758 g O .bss 00000004 __machine_arch_type 001c4768 g O .bss 00000004 free_mem_ptr 001c4778 g *ABS* 00000000 _end ... and I can also see it in the final zImage. $ xxd arch/arm/boot/zImage | tail 01c4710: 221f f1b3 3ef1 1400 be52 9f58 e468 3900 "...>....R.X.h9. 01c4720: 5c47 1c00 2047 1c00 7047 1c00 e442 0000 \G.. G..pG...B.. ^uart_base 01c4730: 6447 1c00 7447 1c00 6c47 1c00 140a 0000 dG..tG..lG...... 01c4740: 6047 1c00 5847 1c00 6847 1c00 0000 0000 `G..XG..hG...... 01c4750: 0000 0000 0000 0000 ........ Surely, it's in the run-time memdump. Before recalculation: 90563020: 001C475C 001C4720 001C4770 000042E4 001C4764 001C4774 001C476C 00000A14 ^uart_base 90563040: 001C4760 001C4758 001C4768 00000000 00000000 00000000 EDFE0DD0 4C010000 After recalculation: 90563020: 905631AC 90563020 905631C0 903A2BE4 905631B4 905631C4 905631BC 9039F314 90563040: 905631B0 905631A8 905631B8 00000000 00000000 00000000 EDFE0DD0 4C010000 So it looks the non-static ('g') uninitialized variable sits in .bss sections well, while static ('l') one is not there. Is this expected? How the static one is being addressed? Or ask where the offset for static one is stored? Any info or comments are appreciated. -- Regards, Shawn

13 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel April 2011