From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fuchs Date: Sun, 15 Jan 2012 19:36:19 +0100 Subject: [U-Boot] [PATCH] mx28: fix i.MX28 spi driver In-Reply-To: References: <4F117435.7080807@esd.eu> <4F11E0E8.8070801@esd.eu> <4F12C23A.1030704@esd.eu> Message-ID: <4F131CA3.4060702@esd.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/15/2012 04:28 PM, Fabio Estevam wrote: > On Sun, Jan 15, 2012 at 10:10 AM, Matthias Fuchs wrote: > >> That's what I also tried. But from the ref manual I got no idea. >> When we do not find a hy to deassert the chip select manually, we cannot >> avoid this read. > > I was assuming that the chip select deassertion was correctly being > handled by the > mxs_spi_end_xfer function. > > This function handles the LOCK_CS and IGNORE_CRC bits that are > responsible for chip select assertion/deassertion. > > From the MX28 Reference Manual: > > "IGNORE_CRC bit: In SPI/SSI modes: When set to 1, deassert the chip > select (SSn) pin after the command is executed." Exactly. That's the point. It says "... after the command ...". So you need a transfer after calling mxs_spi_end_xfer(). That's why the current code calls it before transferring the final byte. Matthias > > Then I tought that mxs_spi_end_xfer should be also called in the case > where bitlen==0. In current code this does not happen. > >> It seems that the mainline linux only implements a GPIO based SPI driver. >> So we cannot take it for reference. > > There is no mxs spi driver in the mainline kernel yet. > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot