From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ned Forrester Subject: Re: PXA270 SSP DMA Corruption Date: Wed, 12 Nov 2008 18:14:29 -0500 Message-ID: <491B6355.3030706@whoi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "J. Scott Merritt" To: spi-devel Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org missed spi-devel on distribution... -------- Original Message -------- Subject: Re: PXA270 SSP DMA Corruption Date: Wed, 12 Nov 2008 18:10:01 -0500 From: Ned Forrester Organization: Woods Hole Oceanographic Institution To: J. Scott Merritt CC: linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW@public.gmane.org, stephen-nl6u4wocdmy51APUEpUfAkEOCMrvLtNR@public.gmane.org, David Brownell References: <20080211174339.73ca7ed5.merrij3-IL7dBOYR4Vg@public.gmane.org> <47B0D9A4.6080104-/d+BM93fTQY@public.gmane.org> <20081107184819.54baa679.merrij3-IL7dBOYR4Vg@public.gmane.org> J. Scott Merritt wrote: > Long ago, I posted a message on linux-arm-kernel describing data > corruption that I was seeing on PXA270 SSP transfers using DMA: > http://marc.info/?l=linux-arm-kernel&m=117780219128682&w=2 > > I have recently upgraded to Kernel 2.6.27.4 and am now using the IOCTL > interface provided by spidev ... and unfortunately am still seeing > data corruption with DMA transfers. > > I have managed to reproduce the problem using the internal loopback > facility of the PXA270 SSP hardware so it should be possible to > test this problem in other environments. On my system, the program > below reports an error within 30-50 attempts. From the data reported, > it would appear the the DMA controller (or memory cache) is transferring > the contents of the previous buffer rather than the current buffer. > > I have also included the platform data that initializes the SSP > device drivers. Perhaps I have misconfigured or misued this in some > way ??? Note that simply disabling DMA in the platform data allows > the test to run indefinitely without errors. [snip code] Sorry for the delayed reply. I have looked over your code, and tried to familiarize myself with spidev. I cannot easily test your code because I am still using 2.6.20, and spidev is was not introduced until 2.6.22. I don't see any obvious problems with either your test code or spidev. Certainly, spidev is of similar complexity to pxa2xx_spi, so I would say that they are similarly likely to have issues. I don't know how much use spidev has gotten, but it is probably more than pxa2xx_spi, because it works across platforms. There are a couple of things to consider: 1. spidev ought to allocate "buffer" using the __GFP_DMA flag. I think you already showed that this is not causing your problem. I think that on ARM, all memory can be used for DMA; that is not true on all architectures and some apparently will silently allocate bounce buffers for non-dma-accessible memory. 2. spidev uses the same buffer for tx and rx. That is supposed to be allowed, but I don't think pxa2xx_spi handles this case correctly. pxa2xx_spi handles NULL buffers (for uni-directional transfers), and it uses dma_map_single to map the rx buffers as DMA_FROM_DEVICE, and the tx buffer as DMA_TO_DEVICE, without checking whether the rx and tx buffers are the same. Thus if they are the same, the memory is mapped twice. "Linux Device Drivers", Corbet, et al. does not address this possibility, but I bet it is not a good thing to do. If you are willing, it looks simple to modify spidev to use two buffers, and test whether that works better. I agree that spidev should work either way, but this would be a quick test. If that works, I will submit a patch for pxa2xx_spi to fix the case of same buffers. Alternatively, you might prefer to try fixing map_dma_buffers() and unmap_dma_buffers() in pxa2xx_spi.c to test this theory. If it works, that would be the proper fix, anyway. Basically it needs to trap the case of same address (or even overlapping ranges) and do one dma_map_single using the DMA_BIDIRECTIONAL flag. Unmapping has to use the same flag. I think I would choose to make it fail on overlapped but unequal ranges, and perform correctly for the cases of separate or equal. -- A couple of things that might improve your performance, but probably are not the cause of the problem: I notice that you don't set the bits_per_word in struct pxa2xx_spi_chip. The default is 8. Presumably that is what you want. There is a transfer timeout that is built into pxa2xx_spi.c and that is loaded to the timeout register in the SSP device. It defaults to "1000" arbitrary units (actually counts of an unspecified-by-Intel clock that is measured to be 99.5MHz on the PXA255 NSSP port, but I don't know what it is on the PXA270). This is a very short time of 10usec, and the result is extra interrupts to service during a transfer. You might try setting this value to 1,000,000 (10msec), or whatever makes sense in your application. You do this by changing the value of the struct pxa2xx_spi_chip.timeout parameter. You have the default value of 1000 in that location. The values of 12 and 4 for the thresholds are sub-optimal. They should probably be 8 and 8 for DMA. A patch has already been submitted by Vernon Sauder (it will appear in 2.6.28) to fix the documentation, and variously improve the defaults for unspecified values in struct pxa2xx_spi_chip. -- Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 -- Ned Forrester nforrester-/d+BM93fTQY@public.gmane.org Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/