Re: [U-Boot] [PATCH 1/2] powerpc: eSPI and eSPI controller support

On Tuesday, March 15, 2011 22:53:20 Shaohui Xie wrote:
--- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -1,6 +1,8 @@ /*
- SPI flash interface
- Add support for Freescale eSPI controller
this is not the place for changelogs
[Xie Shaohui] OK, I'll drop this.
@@ -30,6 +32,7 @@ static int spi_flash_read_write(struct spi_slave *spi, unsigned long flags = SPI_XFER_BEGIN; int ret;
+#ifndef CONFIG_FSL_ESPI if (data_len == 0) flags |= SPI_XFER_END;
@@ -43,6 +46,48 @@ static int spi_flash_read_write(struct spi_slave *spi, debug("SF: Failed to transfer %zu bytes of data: %d\n", data_len, ret); } +#else
- struct espi_transfer transfer[1];
- unsigned char *buffer;
- size_t buf_len;
- if (data_in == NULL)
buf_len = cmd_len;
- else
buf_len = 2 * cmd_len;
- buffer = (unsigned char *)malloc(data_len + buf_len);
- if (!buffer) {
debug("SF: Failed to malloc memory.\n");
return 1;
- }
- memcpy(buffer, cmd, cmd_len);
- if (data_in == NULL)
memcpy(buffer + cmd_len, data_out, data_len);
- transfer[0].cmd_len = cmd_len;
- transfer[0].data_len = data_len;
- transfer[0].tx_buf = buffer;
- if (data_in == NULL)
transfer[0].rx_buf = NULL;
- else
transfer[0].rx_buf = buffer + cmd_len;
- transfer[0].flags = flags | SPI_XFER_END;
- spi->transfer = &transfer[0];
- ret = spi_xfer(spi, 0, NULL, NULL, 0);
- if (ret) {
debug("SF: Failed to send command %02x: %d\n", cmd, ret);
return ret;
- }
- if (data_in)
memcpy(data_in, transfer[0].rx_buf + cmd_len, data_len);
- free(buffer);
+#endif
return ret; }
yikes, this cant be right
[Xie Shaohui] Could you shed more light on this, I didn't get your point, I guess It's maybe the behavior the transaction being handled, for espi controller, software cannot control the chip selects directly, software need to tell the controller how long the CS signal need to be asserted. Driver need to combine the CMD and data together in one transaction, it cannot call spi_xfer two times, first for CMD, and second for data.
If this is the reason you thought it was wrong, do you have better idea to handle this kind of Espi controller?
Best Regards, Shaohui Xie

On Wednesday, March 16, 2011 04:04:42 Xie Shaohui-B21989 wrote:
On Tuesday, March 15, 2011 22:53:20 Shaohui Xie wrote:
--- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c +#ifndef CONFIG_FSL_ESPI ........ +#else ........ +#endif
yikes, this cant be right
[Xie Shaohui] Could you shed more light on this, I didn't get your point, I guess It's maybe the behavior the transaction being handled, for espi controller, software cannot control the chip selects directly, software need to tell the controller how long the CS signal need to be asserted. Driver need to combine the CMD and data together in one transaction, it cannot call spi_xfer two times, first for CMD, and second for data.
in the previous thread with Kumar, we discussed changing things to always be "atomic". so if you want to pick up killing off SPI_XFER_{BEGIN,END} in the spi flash code, then feel free. but that's the only way forward i see at this point -- bus-specific ifdef's in spi flash code isnt going to be accepted. -mike
participants (2)
-
Mike Frysinger
-
Xie Shaohui-B21989