J. Scott Merritt 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.
I have worked with this driver extensively, so I took a look. It seems that you are right. The these bits are set at the end of pump_transfers(), based on internal values that are configured in setup(). The SSCR1 register is initialized with default data in probe(), but this default value is not influenced from any other configuration data. SSCR1 contains the interrupt enables and dma service request enables. As such, it is set as the very last task in pump_transfers(), after all other setup, including the call to cs_control(). If I recall correctly, in some modes of operation, it is important that this register not be written when activity is already in progress, and so it is only set if changed at the end of pump_transfers(). It appears that there needs to be a check for changed clock mode in pump_transfers(), prior to setting chip select. It is important to do this carefully, so as not to interfere with on-going operations. I will take a closer look at this. I know that normally each of these SPI transfers is independent, but I worked with Stephen Street (the maintainer) over a year ago to prep this driver for some external master data steaming that I needed, and I know we worked in this area of the driver. It is possible that we messed this up, as I don't use 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 > > -- Ned Forrester [EMAIL PROTECTED] 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: 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
