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

_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to