Re: How to remove –with-mode=thumb from linaro
On Thursday, 12 May 2011, AKS aungk...@gmail.com wrote: What flag I have to pass in making? I mean what to type in after CCFLAGS= in make or what to be added in Makefile. Thanks! Try using -marm. Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mainlining android fastboot support to upstream u-boot
Dear Zach, In message BANLkTi=6qpjudfjtsezf3yagyfg40ny...@mail.gmail.com you wrote: Would you be able to join us at UDS (https://wiki.linaro.org/Events/2011-05-LDS)? We can also set up a conference line as well. As discussed, I'll try and attend remotely. But Heiko Schocher, one of our engineers, will be there and attend both the linaro-kernel-o-devicetree and linaro-kernel-o-bootarchitecture sessions. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 0/5] Basic ARM devicetree support
On Wed, 11 May 2011, Russell King - ARM Linux wrote: On Wed, May 11, 2011 at 10:44:49PM +0200, Grant Likely wrote: Right now it merges cleanly with linux-next and the resulting tree builds and boots at least on qemu. Unless you really object, I'm going to ask Stephen to add the following branch to the /end/ of the list of trees for linux-next so it can easily be dropped it if it causes any problems. As far as the set of five patches looks fine to me, I don't have any objections against them. So I think we can merge them for .40. What I've always worried about is the platform stuff, and that's something I'm going to continue worrying about because I don't think we have sufficient review capacity to ensure that we don't end up with lots of stupidities. DT is certainly not a silver bullet. Good judgement will be needed as to what is put in DT and how it is represented. I don't think that it would make things worse than they are now though. I also do have some concerns about some aspects of DT which I've expressed several times in the past. However I don't think holding back those patches any longer is a solution though. So consider this as a ACK from my part to merge those patches now. This will get the ball rolling. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 0/5] Basic ARM devicetree support
Hi Grant, On Wed, 11 May 2011 22:44:49 +0200 Grant Likely grant.lik...@secretlab.ca wrote: Right now it merges cleanly with linux-next and the resulting tree builds and boots at least on qemu. Unless you really object, I'm going to ask Stephen to add the following branch to the /end/ of the list of trees for linux-next so it can easily be dropped it if it causes any problems. git://git.secretlab.ca/git/linux-2.6 devicetree/arm-next OK, given Russell's qualified agreement, I will add this tree today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgp68JBlSqAiz.pgp Description: PGP signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 00/12] mmc: use nonblock mmc requests to minimize latency
Hi Philip.. I have something question..did you test SDMA and ADMA? Actually i didn't test [patch v3] but i tested patch v2 before Per sent. I got that SDMA is faster than ADMA. (using bounce buffer and sdhci) How do you think about that? I want to know your thought. And if you can share the results, i want to know them. Regards, Jaehoon Chung Philip Rakity wrote: On May 9, 2011, at 5:34 AM, Per Forlin wrote: On 9 May 2011 04:05, Philip Rakity prak...@marvell.com wrote: Hi Per, We noticed on some of our systems if we ADMA or SDMA and a bounce buffer it is significantly faster then SDMA. I have not done work with ADMA or SDMA. Where should I look to read more about it? Are these the right places. DMA iop-dma.c and imx-sdma.c, MMC: sdhci.c. sdhci.c for ADMA and SDMA spec is at http://www.sdcard.org/developers/tech/sdcard/pls/simplified_specs/ version 3 discusses ADMA I believe ADMA will do large transfers. Another data point. Philip Thanks, Per On May 7, 2011, at 12:14 PM, Per Forlin wrote: 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 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 Under consideration: * Make pre_req and post_req private to core.c. * Generalize implementation and make it available for SDIO. Changes since v2: * Fix compile warnings in core.c and block.c * Simplify max transfer size in mmc_test * set TASK_RUNNING in queue.c before issue_req() Per Forlin (12): mmc: add none blocking mmc request function 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: add handling for two parallel block requests in issue_rw_rq mmc: test: add random fault injection in core.c 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() drivers/mmc/card/block.c | 493 +++-- drivers/mmc/card/mmc_test.c | 340 +++- drivers/mmc/card/queue.c | 180 ++-- drivers/mmc/card/queue.h | 31 ++- drivers/mmc/core/core.c | 132 ++- 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 |9 +- include/linux/mmc/host.h | 13 +- lib/Kconfig.debug | 11 + 12 files changed, 1174 insertions(+), 284 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to remove –with-mode=thumb from linaro
On Thu, May 12, 2011 at 3:07 AM, AKS aungk...@gmail.com wrote: Hi I am using Linaro gcc on Ubuntu/ARM. I am having a problem in building a package that does not support thumb nor thumb2. When I typed gcc -v I saw that –with-mode=thumb and I assume that means my gcc compiler will try to optimize some code in thumb. So I assume I need to make my Linaro compiler knows that no thumb! Please correct me if I were wrong. What flag I have to pass in making? I mean what to type in after CCFLAGS= in make or what to be added in Makefile. Thanks! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to remove –with-mode=thumb from linaro
Oops here's the text:- If you are building complete packages you may find that the package uses the compiler defaults any compiler flags you add may be discarded, depending on the package For the linaro toolchain these are armv7 thumb2 To build complete packages as arm you need to rebuild re-install the linaro cross compiler package to default to the flavour you require e.g. armv7 or armv5 etc See https://wiki.linaro.org/Platform/DevPlatform/CrossCompile and others - search flavour, cross compiler Peter On Thu, May 12, 2011 at 3:07 AM, AKS aungk...@gmail.com wrote: Hi I am using Linaro gcc on Ubuntu/ARM. I am having a problem in building a package that does not support thumb nor thumb2. When I typed gcc -v I saw that –with-mode=thumb and I assume that means my gcc compiler will try to optimize some code in thumb. So I assume I need to make my Linaro compiler knows that no thumb! Please correct me if I were wrong. What flag I have to pass in making? I mean what to type in after CCFLAGS= in make or what to be added in Makefile. Thanks! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
