> On 11.12.2019, at 14:26, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> The maximum transfer length (in a single transaction) for the Rockchip
> SPI controller is 64Kframes (i.e. 0x10000 frames) of 8bit or 16bit
> frames and is encoded as (num_frames - 1) in CTRLR1.
>
> So the 0x10000 is offset value for 64K but the actual size value would
> be 'minus 1' from 0x10000.
NAK. Please see 2 code lines below your change to see that the “minus 1”
is applied there… so a todo of 0x10000 will write 0xffff to regs->ctrlr1.
The problem must be somewhere else and this patch will only mask the
underlying issue.
>
> With the existing code of 0x10000 transfer length leads to read
> failure when we try to read the flash with > 0x10000 size like,
>
> 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
>
> This reverts commit e647decdd93c7408741329432f26758fbec04c7a.
>
> Signed-off-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>
> ---
> drivers/spi/rk_spi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
> index c04535ac44..d9a310ce80 100644
> --- a/drivers/spi/rk_spi.c
> +++ b/drivers/spi/rk_spi.c
> @@ -451,7 +451,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, 0xffff);
>
> rkspi_enable_chip(regs, false);
> writel(todo - 1, ®s->ctrlr1);
> --
> 2.18.0.321.gffc6fa0e3
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
