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

[Hu Mingkai-B21284]

> -----Original Message-----
> From: Mike Frysinger [mailto:vapier at gentoo.org] 
> Sent: Thursday, August 27, 2009 3:23 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 Thursday 27 August 2009 02:59:34 Hu Mingkai-B21284 wrote:
> > From: Mike Frysinger [mailto:vapier at gentoo.org]
> > > On Thursday 27 August 2009 02:27:30 Hu Mingkai-B21284 wrote:
> > > > > 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.
> > >
> > > the length used by the first read covers just the length of the 
> > > opcode, not any of the data returned by the part
> > >
> > > as long as your driver rejects all of these things, it'll be 
> > > detected at runtime and it should be fine to merge -mike
> >
> > So the driver combine the opcode length and the data length 
> together, 
> > then pass to spi_xfer(for eSPI) . When return the read 
> results, skip 
> > the first opcode length bytes.
> 
> you dont get it ... there is no data length.  the code does:
> 
> spi_write(~3 bytes for opcode, BEGIN flag); while (1) {
> 	spi_read(read 1 data byte);
> 	check_result();
> }
> end_spi_transaction();
> 
> there is no "data length" which means your controller cannot 
> support the SPI flash framework -mike
> 

Sorry for the confusion, "the dirver" in my word refers to this patch 
that adds eSPI controller support. You're right, the controller can't
support the SPI framework, that's the reason why this patch comes here.
:-)

Thanks,
Mingkai