[U-Boot] [PATCH 3/7] eSPI: add eSPI controller support

[Mike Frysinger <vapier@gentoo.org>]

On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote:
> From: Mike Frysinger [mailto:vapier at 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.hu@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090316/bf0c2261/attachment-0001.pgp