Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1592312
| From | Vignesh R <vigneshr@ti.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support |
| Date | 2017-03-03 23:10 +0100 |
| Message-ID | <tgAn1-3FV-45@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <tg7l0-8hz-19@gated-at.bofh.it> <tgaiR-2ds-7@gated-at.bofh.it> <tgbHY-334-23@gated-at.bofh.it> <tgfLA-5N5-7@gated-at.bofh.it> <tguUi-8v7-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
>>>> >>> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM >>> cortex-a15) wherein pages allocated by vmalloc are in highmem region >>> that are not addressable using 32 bit addresses and is backed by LPAE. >>> So, a 32 bit DMA cannot access these buffers at all. >>> When dma_map_sg() is called to map these pages by spi_map_buf() the >>> physical address is just truncated to 32 bit in pfn_to_dma() (as part of >>> dma_map_sg() call). This results in random crashes as DMA starts >>> accessing random memory during SPI read. >>> >>> IMO, there may be more undiscovered caveat with using dma_map_sg() for >>> non kmalloc'd buffers and its better that spi-nor starts handling these >>> buffers instead of relying on spi_map_msg() and working around every >>> time something pops up. >>> >> Ok, I had a closer look at the SPI framework, and it seems there's a >> way to tell to the core that a specific transfer cannot use DMA >> (->can_dam()). The first thing you should do is fix the spi-davinci >> driver: >> >> 1/ implement ->can_dma() >> 2/ patch davinci_spi_bufs() to take the decision to do DMA or not on a >> per-xfer basis and not on a per-device basis >> This would lead to poor perf defeating entire purpose of using DMA. >> Then we can start thinking about how to improve perfs by using a bounce >> buffer for large transfers, but I'm still not sure this should be done >> at the MTD level... If its at SPI level, then I guess each individual drivers which cannot handle vmalloc'd buffers will have to implement bounce buffer logic. Or SPI core can be extended in a way similar to this RFC. That is, SPI master driver will set a flag to request SPI core to use of bounce buffer for vmalloc'd buffers. And spi_map_buf() just uses bounce buffer in case buf does not belong to kmalloc region based on the flag. Mark, Cyrille, Is that what you prefer? -- Regards Vignesh
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Vignesh R <vigneshr@ti.com> - 2017-03-01 09:00 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Cyrille Pitchen <cyrille.pitchen@atmel.com> - 2017-03-01 12:10 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Frode Isaksen <fisaksen@baylibre.com> - 2017-03-01 12:50 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-01 13:40 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-01 15:30 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Cyrille Pitchen <cyrille.pitchen@atmel.com> - 2017-03-01 15:40 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Cyrille Pitchen <cyrille.pitchen@atmel.com> - 2017-03-01 15:30 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Mark Brown <broonie@kernel.org> - 2017-03-01 17:00 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-01 17:20 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-01 18:00 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Frode Isaksen <fisaksen@baylibre.com> - 2017-03-02 10:10 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-02 16:00 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Frode Isaksen <fisaksen@baylibre.com> - 2017-03-02 16:20 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-02 17:00 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Frode Isaksen <fisaksen@baylibre.com> - 2017-03-03 10:10 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Cyrille Pitchen <cyrille.pitchen@atmel.com> - 2017-03-02 17:50 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Mark Brown <broonie@kernel.org> - 2017-03-02 19:20 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-03 04:20 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Mark Brown <broonie@kernel.org> - 2017-03-03 14:20 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Vignesh R <vigneshr@ti.com> - 2017-03-06 12:50 +0100
Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support Vignesh R <vigneshr@ti.com> - 2017-03-03 23:10 +0100
csiph-web