
On 6 December 2015 at 11:33, Mugunthan V N mugunthanvnm@ti.com wrote:
On Thursday 03 December 2015 09:37 PM, Jagan Teki wrote:
On 19 November 2015 at 12:35, Mugunthan V N mugunthanvnm@ti.com wrote:
spi bus can support dual and quad wire data transfers for tx and rx. So defining dual and quad modes for both tx and rx. Also add support to parse bus width used for spi tx and rx transfers.
Signed-off-by: Mugunthan V N mugunthanvnm@ti.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Tom Rini trini@konsulko.com
drivers/spi/spi-uclass.c | 33 +++++++++++++++++++++++++++++++++ include/spi.h | 4 ++++ 2 files changed, 37 insertions(+)
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c index 58388ef..62d8da7 100644 --- a/drivers/spi/spi-uclass.c +++ b/drivers/spi/spi-uclass.c @@ -349,6 +349,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node, struct dm_spi_slave_platdata *plat) { int mode = 0;
int value; plat->cs = fdtdec_get_int(blob, node, "reg", -1); plat->max_hz = fdtdec_get_int(blob, node, "spi-max-frequency", 0);
@@ -360,6 +361,38 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node, mode |= SPI_CS_HIGH; if (fdtdec_get_bool(blob, node, "spi-half-duplex")) mode |= SPI_PREAMBLE;
/* Device DUAL/QUAD mode */
value = fdtdec_get_uint(blob, node, "spi-tx-bus-width", 1);
switch (value) {
case 1:
break;
case 2:
mode |= SPI_TX_DUAL;
break;
case 4:
mode |= SPI_TX_QUAD;
break;
default:
error("spi-tx-bus-width %d not supported\n", value);
break;
}
value = fdtdec_get_uint(blob, node, "spi-rx-bus-width", 1);
switch (value) {
case 1:
break;
case 2:
mode |= SPI_RX_DUAL;
break;
case 4:
mode |= SPI_RX_QUAD;
break;
default:
error("spi-rx-bus-width %d not supported\n", value);
break;
}
I think these are similar to SPI TX/RX operation modes in spi.h and I understand this is similar approach as with Linux but before this we need to do many changes on u-boot as well.
I agree that op_mode_rx/op_mode_tx can be used. I just tried to follow Linux way of implementation to have consistency between Linux and
Agreed but the way these mode or flags handling in Linux vs u-boot is different.
U-Boot. If you feel that using op_mode_(rx/tx) will be the best approach, I can repost the series with the changes.
If this is a dependent patch wrt series pls- do otherwise bypass this with your series now once we handle these mode/flags with Linux way will add till now will mark it as "Under review" on patchwork.
thanks!