Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Arnd Bergmann
On Friday 17 June 2011, Nicolas Pitre wrote: > On Fri, 17 Jun 2011, Arnd Bergmann wrote: > > On Friday 17 June 2011 14:10:11 Dave Martin wrote: > > > > > As part of the general effort to make open source on ARM better, I think > > > it would be great if we can disable the alignment fixups (or at

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Paul Brook
> > > char buf[8]; > > > void *v = &buf[1]; > > > unsigned int *p = (unsigned int *)v; > > > > This does not (reliably) do what you expect. The compiler need not align > > buf. > > Printing the value of p should clarify this. > > And, as we can see above, the "simple" accesses

Re: LAVA Dashboard user forum

2011-06-18 Thread Zygmunt Krynicki
W dniu 17.06.2011 23:50, Zach Pfeffer pisze: On 17 June 2011 11:45, Zygmunt Krynicki wrote: W dniu 17.06.2011 18:24, Zach Pfeffer pisze: One thing I'd like to see ASAP with LAVA is to list the build that was tested on the test results page. It is listed, unless I'm mistaken: http://validat

Re: LAVA Dashboard user forum

2011-06-18 Thread Zach Pfeffer
On 18 June 2011 04:07, Zygmunt Krynicki wrote: > W dniu 17.06.2011 23:50, Zach Pfeffer pisze: >> >> On 17 June 2011 11:45, Zygmunt Krynicki >>  wrote: >>> >>> W dniu 17.06.2011 18:24, Zach Pfeffer pisze: One thing I'd like to see ASAP with LAVA is to list the build that was tested o

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Steve Langasek
On Fri, Jun 17, 2011 at 01:10:11PM +0100, Dave Martin wrote: > For ARM, we can achieve the goal by augmenting the default kernel command- > line options: either > alignment=3 > Fix up each alingment fault, but also log the faulting address > and name of the offending process t

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Andy Green
On 06/17/2011 11:53 PM, Somebody in the thread at some point said: Hi - int main(int argc, char * argv[]) { char buf[8]; void *v =&buf[1]; unsigned int *p = (unsigned int *)v; This does not (reliably) do what you expect. The compiler need not align buf. What? Somebod

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Nicolas Pitre
On Sat, 18 Jun 2011, Paul Brook wrote: > > > > char buf[8]; > > > > void *v = &buf[1]; > > > > unsigned int *p = (unsigned int *)v; > > > > > > This does not (reliably) do what you expect. The compiler need not align > > > buf. > > > > Printing the value of p should clarify th

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Nicolas Pitre
On Sat, 18 Jun 2011, Arnd Bergmann wrote: > On Friday 17 June 2011, Nicolas Pitre wrote: > > On Fri, 17 Jun 2011, Arnd Bergmann wrote: > > > On Friday 17 June 2011 14:10:11 Dave Martin wrote: > > > > > > > As part of the general effort to make open source on ARM better, I > > > > think > > > >

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Rtp
Dave Martin writes: Hi, > Hi all, > > I've recently become aware that a few packages are causing alignment > faults on ARM, and are relying on the alignment fixup emulation code in > the kernel in order to work. > > Such faults are very expensive in terms of CPU cycles, and can generally > only r

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Nicolas Pitre
On Sat, 18 Jun 2011, Nicolas Pitre wrote: > int main(int argc, char * argv[]) > { > char buf[8]; > void *v = &buf[1]; > unsigned int *p = (unsigned int *)v; > > strcpy(buf, "abcdefg"); > > printf("*%p = 0x%08x\n", p, *p); > > return 0; > } Obviously, there is a bu

Re: Getting rid of alignment faults in userspace

2011-06-18 Thread Nicolas Pitre
On Sat, 18 Jun 2011, Arnaud Patard wrote: > Dave Martin writes: > Hi, > > > Hi all, > > > > I've recently become aware that a few packages are causing alignment > > faults on ARM, and are relying on the alignment fixup emulation code in > > the kernel in order to work. > > > > Such faults are ve

[PATCH v5 00/12] mmc: use nonblock mmc requests to minimize latency

2011-06-18 Thread Per Forlin
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

[PATCH v5 01/12] mmc: add none blocking mmc request function

2011-06-18 Thread Per Forlin
Previously there has only been one function mmc_wait_for_req() to start and wait for a request. This patch adds * mmc_start_req() - starts a request wihtout waiting If there is on ongoing request wait for completion of that request and start the new one and return. Does not wait for the n

[PATCH v5 02/12] omap_hsmmc: use original sg_len for dma_unmap_sg

2011-06-18 Thread Per Forlin
Don't use the returned sg_len from dma_map_sg() as inparameter to dma_unmap_sg(). Use the original sg_len for both dma_map_sg and dma_unmap_sg according to the documentation in DMA-API.txt. Signed-off-by: Per Forlin Reviewed-by: Venkatraman S --- drivers/mmc/host/omap_hsmmc.c |5 +++-- 1 fi

[PATCH v5 03/12] omap_hsmmc: add support for pre_req and post_req

2011-06-18 Thread Per Forlin
pre_req() runs dma_map_sg(), post_req() runs dma_unmap_sg. If not calling pre_req() before omap_hsmmc_request() dma_map_sg will be issued before starting the transfer. It is optional to use pre_req(). If issuing pre_req() post_req() must be to be called as well. Signed-off-by: Per Forlin --- dri

[PATCH v5 04/12] mmci: implement pre_req() and post_req()

2011-06-18 Thread Per Forlin
pre_req() runs dma_map_sg() and prepares the dma descriptor for the next mmc data transfer. post_req() runs dma_unmap_sg. If not calling pre_req() before mmci_request(), mmci_request() will prepare the cache and dma just like it did it before. It is optional to use pre_req() and post_req() for mmci

[PATCH v5 05/12] mmc: mmc_test: add debugfs file to list all tests

2011-06-18 Thread Per Forlin
Add a debugfs file "testlist" to print all available tests Signed-off-by: Per Forlin --- drivers/mmc/card/mmc_test.c | 39 ++- 1 files changed, 38 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c index 233

[PATCH v5 06/12] mmc: mmc_test: add test for none blocking transfers

2011-06-18 Thread Per Forlin
Add four tests for read and write performance per different transfer size, 4k to 4M. * Read using blocking mmc request * Read using none blocking mmc request * Write using blocking mmc request * Write using none blocking mmc request The host dirver must support pre_req() and post_req() in orde

[PATCH v5 07/12] mmc: add member in mmc queue struct to hold request data

2011-06-18 Thread Per Forlin
The way the request data is organized in the mmc queue struct it only allows processing of one request at the time. This patch adds a new struct to hold mmc queue request data such as sg list, request, blk request and bounce buffers, and updates any functions depending on the mmc queue struct. This

[PATCH v5 08/12] mmc: add a block request prepare function

2011-06-18 Thread Per Forlin
Break out code from mmc_blk_issue_rw_rq to create a block request prepare function. This doesn't change any functionallity. This helps when handling more than one active block request. Signed-off-by: Per Forlin --- drivers/mmc/card/block.c | 224 - 1

[PATCH v5 09/12] mmc: move error code in mmc_block_issue_rw_rq to a separate function.

2011-06-18 Thread Per Forlin
Break out code without functional changes. This simplifies the code and makes way for handle two parallel request. Signed-off-by: Per Forlin --- drivers/mmc/card/block.c | 246 ++--- 1 files changed, 142 insertions(+), 104 deletions(-) diff --git a/drive

[PATCH v5 10/12] mmc: add a second mmc queue request member

2011-06-18 Thread Per Forlin
Add an additional mmc queue request instance to make way for two active block requests. One request may be active while the other request is being prepared. Signed-off-by: Per Forlin --- drivers/mmc/card/queue.c | 44 ++-- drivers/mmc/card/queue.h |3

[PATCH v5 11/12] mmc: test: add random fault injection in core.c

2011-06-18 Thread Per Forlin
This simple fault injection proved to be very useful to test the error handling in the block.c rw_rq(). It may still be useful to test if the host driver handle pre_req() and post_req() correctly in case of errors. Signed-off-by: Per Forlin --- drivers/mmc/core/core.c| 54 +

[PATCH v5 12/12] mmc: add handling for two parallel block requests in issue_rw_rq

2011-06-18 Thread Per Forlin
Change mmc_blk_issue_rw_rq() to become asynchronous. The execution flow looks like this: The mmc-queue calls issue_rw_rq(), which sends the request to the host and returns back to the mmc-queue. The mmc-queue calls issue_rw_rq() again with a new request. This new request is prepared, in isuue_rw_rq

Re: [GIT PULL] fix for bug 754254

2011-06-18 Thread Nicolas Pitre
On Fri, 17 Jun 2011, Shawn Guo wrote: > Hi Nicolas, > > Could you pull the fix for [Bug 754254] imx51 randomly truncates > serial input at 31 characters? > > It extends the card CD/WP support for mx5 platforms, and adds the > board level configuration for mx51evk to fix bug 754254 on this > part

Re: [PATCH RESEND] omap_hsmmc: use original sg_len for dma_unmap_sg

2011-06-18 Thread Chris Ball
Hi Per, On Fri, Jun 17 2011, Per Forlin wrote: > Don't use the returned sg_len from dma_map_sg() as inparameter > to dma_unmap_sg(). Use the original sg_len for both dma_map_sg > and dma_unmap_sg according to the documentation in DMA-API.txt. > > Signed-off-by: Per Forlin > Reviewed-by: Venkatram