Messages in this thread | | | Subject | RE: [PATCH] sst25l.c: simplify reading the device ManID/DevID | From | Artem Bityutskiy <> | Date | Thu, 29 Apr 2010 21:07:46 +0300 |
| |
On Thu, 2010-04-29 at 12:11 -0500, H Hartley Sweeten wrote: > On Wednesday, April 28, 2010 10:37 PM, Artem Bityutskiy wrote: > > On Tue, 2010-04-20 at 18:17 -0500, H Hartley Sweeten wrote: > >> The Read-ID command will continuously output the Manufacture ID and Device ID > >> until the command is terminated by a low to high transition on the CE# pin. > >> We can take advantage of this in the sst25l_match_device routine by reading > >> both bytes in one spi_write_then_read transaction. > >> > >> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> > >> Cc: David Woodhouse <dwmw2@infradead.org> > >> Cc: Andre Renaud <andre@bluewatersys.com> > >> Cc: Ryan Mallon <ryan@bluewatersys.com> > > > > Pushed to l2-mtd-2.6.git / dunno. > > Artem, > > I have discovered that the Read-Status-Register command has the same problem. > With the SST25L SPI flash chips, if the chip enable is deasserted after sending > a command that command will get aborted. > > I ran across this while testing a new spi master driver for the ep93xx on an > EDB9307A dev board. That board uses the processors SFRMOUT signal as part of > the chip select logic. Unfortunately the ep93xx only asserts the SFRMOUT > signal as long as the spi transmit fifo contains data. As soon as the last > bit is clocked into the receive fifo it gets deasserted. Many of the other > ep93xx based boards have that same issue. > > I have an updated patch that changes both of these into one synchronous message > which fixes the sst25l_status and sst25l_match_device functions. These changes > should be transparent to any users of this driver. > > Could you drop the current patch and I will submit the updated one for review?
Of course, just send it.
-- Best Regards, Artem Bityutskiy (Артём Битюцкий)
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |