First, thanks for your replies. I am sorry. I left town for the weekend and I forgot to include all the details. Jonathan Cameron wrote: > nforrester-/d+BM93fTQY@public.gmane.org wrote: > >> I am as sea right now, with very limited email access. If you can >> wait until Wed or Thursday of next week, I might be of more help. In >> the mean time perhaps someone else will reply. >> >> Since the orignal author, Stephen Steet, became silent on this driver, >> I and several others have submitted patches for it. I use an >> extensivley modified version of pxa2xx_spi.c for one of my projects >> and thus I have some familiarity with the driver, though somewhat less >> with the details of SPI (I use the TI synchonous mode) and none at all >> with flash on SPI. I also work on a PXA255, and the PXA270 has some >> differences. >> > I can offer a few additional comments on this (as a PXA271 spi user) > Good. We have a nice set of different HW. Sorry to hear that Steve became quiet. > >>> I am using a custom PXA270 board and tried to use the SSP port to >>> communication with a SPI Flash. After reading docs on how to configure >>> the spi_master and spi devices, I have the device driver's probe being >>> called. But I cannot get the pxa2xx_spi driver to work correctly. I >>> can connect either a SD card or a M26P16 Flash chip to the SPI port on >>> my board. Neither device driver can completely operate their device. >>> >>> It looks like it is impossible for the device drivers to control the >>> chip select (CS) line. If I use the manual cs_control callback, the >>> timing is invalid because the SSP clock keeps running. >>> >> The cs_control() callback is the normal way of controlling chip select >> with this driver. That allows you to assign any GPIO pin or polarity. >> I understand that this differs from way that the spi core expects chip >> select to be handeled; in particular, the driver does not honor the >> SPI_CS_HIGH nor SPI_LSB_FIRST bits in the spi_device.mode. The PXA >> SSP controllers do not have a dedicated chipselect mechanism >> associated with the SSP controllers (outside of the single FRAME pin, >> which may or may not do what you want), thus the use of GPIO lines is >> required. >> >> What version of the kernel/driver are you using? There have been some >> recent changes, and there may still be a bug regarding CS changes that >> was discussed in: >> Re: [spi-devel-general] odd behaviour of chipselect with bitbang driver? >> on about 04/24/08 15:55. I raised the question but, since I don't use >> chipselect at all, I have not produced a patch. >> >> I am using 2.6.24.4 on custom HW. I am using the FRAME pin as the chip select so I was hoping I did not have to use cs_control(). I'll look up that patch, thanks. >> The fact that the clock free runs strikes me as strange, I don't think >> any of the supported SPI_MODE_n combinations can produce a free >> running clock, though they do control polarity and phase of the clock. >> If your problem involves one extra clock edge, you may have the wrong >> setting for SPI_MODE_n.` >> > Although the clock can free run in some of the other (non spi modes) > the driver doesn't support this which means the behaviour is somewhat > odd! Any chance you can make available a picture of an oscilloscope trace > showing SFRM and the clock? That'll probably give sufficient clues to > allow us to figure out what is going wrong. I've used gpio based chip > selects on the pxa271 wihout problems (though it does tend to slow down > your transfers somewhat so is best avoided where possible). > I attached a Logic Analyzer screen shot of m25p80 driver starting to query the device. The RX line is floating when the m25pxx chip is not driving it. But notice that the clocks are running before the FRM/CS line is active. If I use cs_control(), then there would be several clock edges (when using high speeds) before the PXA SSP controller would start clocking data. >>> That means that >>> several bits are clocked out before the SSP controller starts to drive >>> the TX line correctly. If the SFRM signal is used, it does not allow >>> the driver to keep CS active for multiple transactions as they expect >>> and assume. The spi_sync call takes an spi_message which contains a >>> list of transactions to send. Normally, the device will need the CS >>> active during the complete message. But the SSP controller deactivates >>> SFRM when it is done with each buffer. For instance, the M25P16 >>> datasheet indicates that CS has to stay active from the READ command >>> through the complete data transfer. When it goes high, it resets the >>> command interface. >>> >> The driver should honor the per-transfer spi_transfer.cs_change flag >> when used with a cs_control routine. If you want the CS to stay >> asserted between transfers, be sure the cs_change flag is 0. >> > > Indeed it should but it doesn't. Unfortunately the hardware doesn't > seem to have the ability to do this, so it will only work if using > a gpio as the chip select. Guess we really ought to add some stuff to > the docs to make this clear (it wasted a good few hours of my time > failing to understand why it didn't do anything!) For short > transfers (sub 16 x 32bits) you can get away with doing the endianess > changes necessary and sending as a single multiword transfer. > Afraid I'm usually dealing with sensors, adc's etc and they don't > tend to need larger transfers than this between deasserting the chip > select. > > >>> It looks like the SSP port needs to have a register bit to turn off >>> the clock when there is nothing to transmit. Or a bit to tell the SSP >>> controller to leave CS active. Or I can change the HW so CS gates the >>> clock and a manual CS chip operates the device CS pin. I might also >>> try the bitbanging SPI driver next to see if that can operate with the >>> Flash chip. >>> >> pxa2xx_spi.c uses format SSCR0_Motorola. I think, as I said above, >> that this mode does not allow the clock to free run. I expect that >> you have some other problem. As I understand it (and I may be wrong, >> since I don't use Motorola SPI format) the clock is only active if >> data is being transfered, and data is only transferred if there is >> something the in the transmit FIFO to go out (and thus something to >> receive at the same time). >> > > That should certainly be the case. I guess it's just possible that SSCR1 > is preset by something else to continuous clock mode? Don't think the driver > explicitly clears it and a quick glance suggests elements of that register > are set from chip specific data. > Here are the registers: root@inhand-ft4 [~] # md 0x41000000 0x3f 00000000 87 19 00 00 00 00 00 00 24 f0 00 00 00 00 00 00 |........$.......| 00000010 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000030 >> I wonder if you have a zero byte in the TX >> FIFO when you think you have nothing. Perhaps spi_transfer.len is not >> set right. >> >> >>> Is there some other setting I am missing here? Is anyone else using >>> the M25P16 chip with PXA270 SPI driver? >>> > Not that chip, but I've got a good scope wired up to spi on > a pxa271 so should be able to debug this without the chip. > I may be able to send you a chip if you like. I did some further research on this and found that the spidev driver works to at least query the flash chip. From userspace, I simply use a single transfer (via IOCTL) for each command. But that does not give me the m25p80 driver on top of the SPI; I would be re-inventing the wheel. I also modified spi.c file to make spi_write_then_read() use one transfer so the m25p80 driver's JEDEC probe works. It is an example of the difference that would have to be done to get the pxa27x to work right. --- ./src.old/drivers/spi/spi.c 2008-03-24 14:49:18.000000000 -0400 +++ ./src.cache/drivers/spi/spi.c 2008-08-11 17:49:50.000000000 -0400 @@ -564,7 +566,6 @@ #define SPI_BUFSIZ max(32,SMP_CACHE_BYTES) static u8 *buf; - /** * spi_write_then_read - SPI synchronous write followed by read * @spi: device with which data will be exchanged @@ -592,7 +593,7 @@ int status; struct spi_message message; - struct spi_transfer x[2]; + struct spi_transfer x; u8 *local_buf; /* Use preallocated DMA-safe buffer. We can't avoid copying here, @@ -603,15 +604,9 @@ return -EINVAL; spi_message_init(&message); - memset(x, 0, sizeof x); - if (n_tx) { - x[0].len = n_tx; - spi_message_add_tail(&x[0], &message); - } - if (n_rx) { - x[1].len = n_rx; - spi_message_add_tail(&x[1], &message); - } + memset(&x, 0, sizeof x); + x.len = n_tx + n_rx; + spi_message_add_tail(&x, &message); /* ... unless someone else is using the pre-allocated buffer */ if (!mutex_trylock(&lock)) { @@ -622,15 +617,15 @@ local_buf = buf; memcpy(local_buf, txbuf, n_tx); - x[0].tx_buf = local_buf; - x[1].rx_buf = local_buf + n_tx; + x.tx_buf = local_buf; + x.rx_buf = local_buf; /* do the i/o */ status = spi_sync(spi, &message); if (status == 0) - memcpy(rxbuf, x[1].rx_buf, n_rx); + memcpy(rxbuf, x.rx_buf + n_tx, n_rx); - if (x[0].tx_buf == buf) + if (x.tx_buf == buf) mutex_unlock(&lock); else kfree(local_buf); Let me know if there is anything else I can do to clarify this. I want to know what the SPI is capable of and what the limitations are. Vernon Sauder