On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote: > From: Mike Frysinger [mailto:vap...@gentoo.org] > > On Monday 16 March 2009 02:15:27 Jean-Christophe wrote: > > > On 10:52 Mon 16 Mar , Mingkai Hu wrote: > > > > Add eSPI controller support under the SPI framework. > > > > > > > > Signed-off-by: Mingkai Hu <mingkai...@freescale.com> > > > > --- > > > > drivers/mtd/spi/spi_flash.c | 94 +++++++++++++++++- > > > > drivers/spi/Makefile | 1 + > > > > drivers/spi/fsl_espi.c | 232 > > > > +++++++++++++++++++++++++++++++++++++++++++ include/spi.h > > > > > > > > 30 ++++++ > > > > 4 files changed, 354 insertions(+), 3 deletions(-) create mode > > > > 100644 drivers/spi/fsl_espi.c > > > > > > please use the spi framework, their is no need to touch the spi_flash > > > support ti add and use the fsl_espi > > > > indeed ... i was so happy to see the spansion driver i > > glossed over this ... > > those spi_flash.c changes are almost assuredly wrong and > > indicate you arent fitting into the framework correctly. > > There is difference between the SPI and eSPI chip select signal. > Generally, the SPI chip select is controlled by GPIO, so SW can control > when to assert the chip select signal and when to stop the chip select > signal.
that is incorrect. the SPI framework does not care how the controller manages the CS. the Blackfin SPI controller for example has dedicated CS's which the controller manages automatically. > But the eSPI controller integrate the chip select into the controller > itself, it use the transfer length to control the duration of the chip > select signal. so you must tell the controller ahead of time how many bytes are going to be transferred ? this sounds like a retarded hardware implementation to me. how exactly do you support arbitrary transfer lengths ? > The spi_flash_cmd_* function split the transfer into two steps: first > the command transfer and then the data transfer. At the first step, the > transfer length is set to the command length, and when transferred the > command, the chip select will be negated, so the eSPI controller thinks the > transfer is cancelled and doesn't transfer the data again. the transfer state is passed in via the flags parameter. this way the SPI controller knows when a transfer starts (SPI_XFER_BEGIN) and when it ends (SPI_XFER_END). -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
