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

[Hu Mingkai-B21284]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Mike Frysinger
> Sent: Thursday, August 27, 2009 1:54 PM
> To: Hu Mingkai-B21284
> Cc: u-boot at lists.denx.de; Fleming Andy-AFLEMING
> Subject: Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support
> 
> On Wednesday 26 August 2009 23:01:52 Hu Mingkai-B21284 wrote:
> > From: Mike Frysinger [mailto:vapier at gentoo.org]
> > > On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote:
> > > > 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 ?
> >
> > IIRC every transaction byte length control every transaction.
> 
> but what if you dont know the length of the transaction ahead 
> of time ?  if you look at the spi flash framework, it'll 
> write a few bytes (like the opcode to read the status 
> register) and then it'll just keep reading 1 byte at a time 
> (polling the status register).  there is no way of knowing 
> the length ahead of time.  most of the SPI code in u-boot 
> operates this way.
> 

So the driver use the length passed by SPI flash read function.
If the length is greater than the max value that is limited by the
transaction length register's bitfiled, the driver couldn't read
anything.
We'll dig into this issue for the furture.

> > > > 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).
> >
> > As above, we can't use the start/end flags parameter.
> 
> then your controller wont be able to work with most (any?) of 
> the code in u- boot.  you need to reject every transfer that 
> snt done with both BEGIN and END flags set.
Looks like now.
> -mike
> 

Thanks,
Mingkai