On Mon, Oct 25, 2010 at 11:00 AM, Nori, Sekhar <[email protected]> wrote: > Hi Marc-André, > > On Mon, Oct 25, 2010 at 18:00:14, Marc-André Hébert wrote: >> 2010/10/25 Marc-André Hébert <[email protected]>: >> > Hi, >> > >> > I would have replied directly to the original thread but I wasn't on >> > the mailing list back then. I wanted to report I encountered some >> > problems using the [PATCH v5 1/1] davinci: spi: replace existing >> > driver. >> > >> > I am currently using the Arago tree. I also applied the required DMA >> > patch >> > (http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html). >> > I will try to test with linux-davinci but for that I would need more >> > work on the omapl138 spi first. >> > >> > Reading a block of at least 64k of data does not work with the new >> > driver. Here is how I reproduced (/dev/mtd1 is a spi flash with 256KB >> > sector size): >> > >> > dd if=/dev/mtd1 of=/dev/null count=1bs=32768 #OK >> > dd if=/dev/mtd1 of=/dev/null count=2bs=32768 #OK >> > dd if=/dev/mtd1 of=/dev/null count=1bs=65536 #Stalls in >> > davinci_spi_txrx_bufs >> > >> > Trying with a block size of 128KB also fails. I am just unsure if this >> > failure is due to me using the Arago tree (maybe something else is >> > missing) or this is really an issue with the driver. If anybody else >> > can confirm or deny, it would be great. >> > >> > Regards >> > Marc >> > >> Think I identified part of the problem (from davinci_spi_txrx_bufs in >> driver/spi/davinci_spi.c): >> tx_param.a_b_cnt = davinci_spi->wcount << 16 | data_type; >> >> With my example wcount equals the bs argument. So there is no way this >> can work if wcount requires more than 16 bits. >> Is the edma supposed to be limited to transfers with a len of 16 bits >> or less? Is the spi driver supposed to split the transfers or is there >> another way to set higher len bits? > > Good catch! The probable solution would be to use the third dimension > (C-count) > as well. A-Count is fixed to the number of bytes-per-word so the rest of the > length value should be factored into B-count * C-Count. > > I general, I guess there should be a mechanism for any spi master to specify > the maximum transfer it can handle and the spi core should be able to break > the spi message into suitable sized transfers. I briefly looked at the spi > core and found no evidence of such a facility. > > I also wonder why this issue showed up only with Brian's patches as the > original code seems to use only b-count for transfer length programming > as well. > > Thanks, > Sekhar > > I tried a quick fix where for transfers larger than 32K. I fixex bcount to 32K and set ccnt to wcount / 32K. if( davinci_spi->wcount > 0xFFFF ) { if( davinci_spi->wcount & 0x7FFF ) { dev_info(sdev, "larger SPI transfers need to be multiples of 32K\n"); return -EIO; } tx_param.a_b_cnt = 0x8000 << 16 | data_type; tx_param.ccnt = davinci_spi->wcount / 0x8000; } else { tx_param.a_b_cnt = davinci_spi->wcount << 16 | data_type; tx_param.ccnt = 1; } The transfers don't hang but the data above the first 32K is invalid. Must something different be done to use the ccnt correctly? Given my board has larger spi flash sectors, I would like to have a workaround in the driver instead than making sure all applications use small transfers.
Thanks Marc _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
