| Message ID | 20191221075440.6944-2-jagan@amarulasolutions.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
On 2019/12/21 下午3:54, Jagan Teki wrote: > The Rockchip SPI controller's length register only supports 16-bits, > yielding a maximum length of 64KiB (the CTRLR1 register holds "length - > 1"). Trying to transfer more than that (e.g., with a large SPI flash > read) will cause the driver to hang. > > Now, it seems that while theoretically we should be able to program > CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to > cause the core to choke, so stick with a maximum of 64K - 1 bytes -- > i.e., 0xffff. > > Note, that the size is further divided into 'minus 1' while writing > into CTRLR1. > > This change fixed two different read issues, > > 1. sf read failure when with > 0x10000 > > 2. Boot from SPI flash failed during spi_flash_read call in > common/spl/spl_spi.c > > Observed and Tested in > - Rockpro64 with Gigadevice flash > - ROC-RK3399-PC with Winbond flash > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Thanks, - Kever > --- > drivers/spi/rk_spi.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c > index c04535ac44..95eeb8307a 100644 > --- a/drivers/spi/rk_spi.c > +++ b/drivers/spi/rk_spi.c > @@ -27,6 +27,12 @@ > /* Change to 1 to output registers at the start of each transaction */ > #define DEBUG_RK_SPI 0 > > +/* > + * ctrlr1 is 16-bits, so we should support lengths of 0xffff + 1. However, > + * the controller seems to hang when given 0x10000, so stick with this for now. > + */ > +#define ROCKCHIP_SPI_MAX_TRANLEN 0xffff > + > struct rockchip_spi_params { > /* RXFIFO overruns and TXFIFO underruns stop the master clock */ > bool master_manages_fifo; > @@ -367,7 +373,7 @@ static inline int rockchip_spi_16bit_reader(struct udevice *dev, > * represented in CTRLR1. > */ > if (data && data->master_manages_fifo) > - max_chunk_size = 0x10000; > + max_chunk_size = ROCKCHIP_SPI_MAX_TRANLEN; > > // rockchip_spi_configure(dev, mode, size) > rkspi_enable_chip(regs, false); > @@ -451,7 +457,7 @@ static int rockchip_spi_xfer(struct udevice *dev, unsigned int bitlen, > > /* This is the original 8bit reader/writer code */ > while (len > 0) { > - int todo = min(len, 0x10000); > + int todo = min(len, ROCKCHIP_SPI_MAX_TRANLEN); > > rkspi_enable_chip(regs, false); > writel(todo - 1, ®s->ctrlr1);
On Mon, Dec 23, 2019 at 8:00 AM Kever Yang <kever.yang@rock-chips.com> wrote: > > > On 2019/12/21 下午3:54, Jagan Teki wrote: > > The Rockchip SPI controller's length register only supports 16-bits, > > yielding a maximum length of 64KiB (the CTRLR1 register holds "length - > > 1"). Trying to transfer more than that (e.g., with a large SPI flash > > read) will cause the driver to hang. > > > > Now, it seems that while theoretically we should be able to program > > CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to > > cause the core to choke, so stick with a maximum of 64K - 1 bytes -- > > i.e., 0xffff. > > > > Note, that the size is further divided into 'minus 1' while writing > > into CTRLR1. > > > > This change fixed two different read issues, > > > > 1. sf read failure when with > 0x10000 > > > > 2. Boot from SPI flash failed during spi_flash_read call in > > common/spl/spl_spi.c > > > > Observed and Tested in > > - Rockpro64 with Gigadevice flash > > - ROC-RK3399-PC with Winbond flash > > > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Applied to u-boot-spi/master
diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c index c04535ac44..95eeb8307a 100644 --- a/drivers/spi/rk_spi.c +++ b/drivers/spi/rk_spi.c @@ -27,6 +27,12 @@ /* Change to 1 to output registers at the start of each transaction */ #define DEBUG_RK_SPI 0 +/* + * ctrlr1 is 16-bits, so we should support lengths of 0xffff + 1. However, + * the controller seems to hang when given 0x10000, so stick with this for now. + */ +#define ROCKCHIP_SPI_MAX_TRANLEN 0xffff + struct rockchip_spi_params { /* RXFIFO overruns and TXFIFO underruns stop the master clock */ bool master_manages_fifo; @@ -367,7 +373,7 @@ static inline int rockchip_spi_16bit_reader(struct udevice *dev, * represented in CTRLR1. */ if (data && data->master_manages_fifo) - max_chunk_size = 0x10000; + max_chunk_size = ROCKCHIP_SPI_MAX_TRANLEN; // rockchip_spi_configure(dev, mode, size) rkspi_enable_chip(regs, false); @@ -451,7 +457,7 @@ static int rockchip_spi_xfer(struct udevice *dev, unsigned int bitlen, /* This is the original 8bit reader/writer code */ while (len > 0) { - int todo = min(len, 0x10000); + int todo = min(len, ROCKCHIP_SPI_MAX_TRANLEN); rkspi_enable_chip(regs, false); writel(todo - 1, ®s->ctrlr1);
The Rockchip SPI controller's length register only supports 16-bits, yielding a maximum length of 64KiB (the CTRLR1 register holds "length - 1"). Trying to transfer more than that (e.g., with a large SPI flash read) will cause the driver to hang. Now, it seems that while theoretically we should be able to program CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to cause the core to choke, so stick with a maximum of 64K - 1 bytes -- i.e., 0xffff. Note, that the size is further divided into 'minus 1' while writing into CTRLR1. This change fixed two different read issues, 1. sf read failure when with > 0x10000 2. Boot from SPI flash failed during spi_flash_read call in common/spl/spl_spi.c Observed and Tested in - Rockpro64 with Gigadevice flash - ROC-RK3399-PC with Winbond flash Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- drivers/spi/rk_spi.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)