On Wednesday 02 September 2009, Barry Song wrote: > David, > I am really surprised the kmalloc memory can keep DMA-safe. Then you need to internalize more of the docs on the DMA calls ... :) Notably see in Documentation/DMA-mapping.txt the section up top where it describes what memory can be used for DMA, and very explicitly states stack data is not appropriate. > Check the > code, no matter spi_write_then_read and spi_init, they only get memory > by a simple > kmalloc(SPI_BUFSIZ, GFP_KERNEL); > I can't find map_single or dma coherent operations at all. So did I > lose something? When the SPI master controller driver uses DMA and the caller doesn't set up mappings, that controller driver does the DMA mapping operations. That's what those code paths rely on. You're writing code sitting a layer above that driver for the SPI master controller. Your code won't know whether DMA will be used or not, so your code must either (a) use DMA-safe buffers in the first place, or else (b) use spi_write_then_read() which provides a small bounce buffer. A non-option is (c) write your code so it breaks on controllers that use DMA. - Dave > Thanks > Barry > > On 9/2/09, David Brownell <david-b@xxxxxxxxxxx> wrote: > > On Tuesday 01 September 2009, Song, Barry wrote: > >> >> + spi_message_add_tail(&t, &m); > >> >> + ret = spi_sync(spi, &m); > >> > > >> >cant you use spi_write_then_read() ? dont let the u8* prototype scare > >> >you, it should work with writing 16bits and then reading 16bits. > >> > >> I have never been scared by any u8* or something else. I only prefer > >> to use raw spi API, which can show the bottom level timing and SPI > >> bus feature better. > > > > In this case spi_write_then_read() is required, since > > your tx and rx buffers are on the stack and hence not > > DMA-safe. > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
