FWIW I'm using the pxa2xx_spi driver from 2.6.23.9 on a pxa270 and I'm not experiencing any problems of this type. One thought - some manufacturer's interpretations of SPI invert the sense of the clock so maybe the problem is related to the chip he's talking to rather than the pxa driver.
While we're on the subject of the pxa2xx_spi driver, I've found that it has incredibly slow throughput. The problem appears to be related to the use of a tasklet in pumping messages. The initial setup and transfer is quick but then the tasklet is started and a context switch causes terrible latency. It takes around a millisecond for the tasklet to get control at which point the chip select is released and the SPI bus is available for the next transfer. This means that running as hard as it can the bus is idle 99% of the time. I've experimented with removing the tasklet from the driver and it does improve the situation markedly. Cheers, Zik On Feb 12, 2008 9:43 AM, J. Scott Merritt <[EMAIL PROTECTED]> wrote: > Reposted from linux-arm-kernel mailing list ... at the suggestion > of David Brownell. > > Using pxa2xx_spi from Kernel 2.6.21. PXA270 is SSP Master in > SPI_MODE_3 (SPO=1, SPH=1) with internal clock and GPIO's used as > external chip selects. > > On the very first message after boot, I am receiving an extra clock > pulse at the slave device (causing the whole message to be "shifted"). > > It appears that on the first message, the Chip Select is activated > before the SPO=1/SPH=1 is fully established in the PXA's SSP hardware, > resulting in an extra, positive-going transition of SSPSCLK as it > attempts to establish the proper (high) clock level for the SPH=1 > setting. > > Testing was performed on Kernal 2.6.21, but it appears that 2.6.24 > also performs the chip select call before updating SSCR0 & SSCR1. > Slave device is NXP LPC2366. > > I have tried setting the "default" in pxa2xx_spi.c to SPO=1, SPH=1; > but still have the clock riding low before the first chip select. > > ... David Brownell responds: > > Actually, the SPI_CPOL mode bit controls the clock polarity > before the chip select coes active: CPOL=0 should mean it's > forced low (if it isn't already low). > > So if that driver is doing chipselect *then* clock setup, > it's doing the wrong thing. A patch would be appreciated... > > ... > Thanks, Scott. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > spi-devel-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/spi-devel-general > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
