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 least
W dniu 17.06.2011 23:50, Zach Pfeffer pisze:
On 17 June 2011 11:45, Zygmunt Krynickizygmunt.kryni...@linaro.org 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
On 18 June 2011 04:07, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote:
W dniu 17.06.2011 23:50, Zach Pfeffer pisze:
On 17 June 2011 11:45, Zygmunt Krynickizygmunt.kryni...@linaro.org
wrote:
W dniu 17.06.2011 18:24, Zach Pfeffer pisze:
One thing I'd like to see ASAP with LAVA is to
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 to
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?
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 buffer overflow
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
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
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 per.for...@linaro.org
Reviewed-by: Venkatraman S svenk...@ti.com
---
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
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 per.for...@linaro.org
---
drivers/mmc/card/queue.c | 44 ++--
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 per.for...@linaro.org
---
drivers/mmc/core/core.c|
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
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
particular
14 matches
Mail list logo
