* [PATCH] spi: sunxi: wait for TX/RX fifo reset done @ 2026-04-21 4:47 Yixun Lan 2026-04-29 16:20 ` Jernej Škrabec 2026-04-30 9:54 ` Andre Przywara 0 siblings, 2 replies; 4+ messages in thread From: Yixun Lan @ 2026-04-21 4:47 UTC (permalink / raw) To: u-boot; +Cc: linux-sunxi, Andre Przywara, Jagan Teki, Tom Rini, Yixun Lan Once reset SPI TX or RX fifo, the underlying hardware need to take some time to actually settle down, the two bits will automatically clear to 0, so use a poll mechanism to check status bits to make sure it's done correctly. Signed-off-by: Yixun Lan <dlan@gentoo.org> --- On Cubie A7A board which using A733 SoC, we encoutered a SPI nor flash timeout issue, it turns out that the SPI fifo reset take a few time to settle down, Add a loop to poll the status. This was the error message shows on A7A board once this issue happened. => sf probe ERROR: sun4i_spi: Timeout transferring data Failed to initialize SPI flash at 0:0 (error -2) --- drivers/spi/spi-sunxi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c index e00532a371b..cf41905c7b7 100644 --- a/drivers/spi/spi-sunxi.c +++ b/drivers/spi/spi-sunxi.c @@ -347,7 +347,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int bitlen, struct sun4i_spi_priv *priv = dev_get_priv(bus); struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev); - u32 len = bitlen / 8; + u32 rst, val, len = bitlen / 8; u8 nbytes; int ret; @@ -363,8 +363,11 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int bitlen, sun4i_spi_set_cs(bus, slave_plat->cs[0], true); /* Reset FIFOs */ - setbits_le32(SPI_REG(priv, SPI_FCR), SPI_BIT(priv, SPI_FCR_RF_RST) | - SPI_BIT(priv, SPI_FCR_TF_RST)); + rst = SPI_BIT(priv, SPI_FCR_RF_RST) | SPI_BIT(priv, SPI_FCR_TF_RST); + setbits_le32(SPI_REG(priv, SPI_FCR), rst); + ret = readl_poll_timeout(SPI_REG(priv, SPI_FCR), val, !(rst & val), 20); + if (ret) + return -EBUSY; while (len) { /* Setup the transfer now... */ --- base-commit: 88dc2788777babfd6322fa655df549a019aa1e69 change-id: 20260220-02-spi-fifo-reset-25e371314c3f Best regards, -- Yixun Lan <dlan@gentoo.org> ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] spi: sunxi: wait for TX/RX fifo reset done 2026-04-21 4:47 [PATCH] spi: sunxi: wait for TX/RX fifo reset done Yixun Lan @ 2026-04-29 16:20 ` Jernej Škrabec 2026-04-30 9:54 ` Andre Przywara 1 sibling, 0 replies; 4+ messages in thread From: Jernej Škrabec @ 2026-04-29 16:20 UTC (permalink / raw) To: u-boot, Yixun Lan Cc: linux-sunxi, Andre Przywara, Jagan Teki, Tom Rini, Yixun Lan Dne torek, 21. april 2026 ob 06:47:50 Srednjeevropski poletni čas je Yixun Lan napisal(a): > Once reset SPI TX or RX fifo, the underlying hardware need to take > some time to actually settle down, the two bits will automatically > clear to 0, so use a poll mechanism to check status bits to make sure > it's done correctly. > > Signed-off-by: Yixun Lan <dlan@gentoo.org> > --- > On Cubie A7A board which using A733 SoC, we encoutered a SPI nor flash > timeout issue, it turns out that the SPI fifo reset take a few time to > settle down, Add a loop to poll the status. > > This was the error message shows on A7A board once this issue happened. > > => sf probe > ERROR: sun4i_spi: Timeout transferring data > Failed to initialize SPI flash at 0:0 (error -2) Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Best regards, Jernej ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] spi: sunxi: wait for TX/RX fifo reset done 2026-04-21 4:47 [PATCH] spi: sunxi: wait for TX/RX fifo reset done Yixun Lan 2026-04-29 16:20 ` Jernej Škrabec @ 2026-04-30 9:54 ` Andre Przywara 2026-05-01 12:25 ` Yixun Lan 1 sibling, 1 reply; 4+ messages in thread From: Andre Przywara @ 2026-04-30 9:54 UTC (permalink / raw) To: Yixun Lan, u-boot; +Cc: linux-sunxi, Jagan Teki, Tom Rini, Jernej Skrabec Hi, On 4/21/26 06:47, Yixun Lan wrote: > Once reset SPI TX or RX fifo, the underlying hardware need to take > some time to actually settle down, the two bits will automatically > clear to 0, so use a poll mechanism to check status bits to make sure > it's done correctly. Ah, interesting, thanks for posting this! I looked into some manuals, and it seems like this self-clearing property is already used in the A10, so it's fine to use unconditionally. > > Signed-off-by: Yixun Lan <dlan@gentoo.org> Acked-by: Andre Przywara <andre.przywara@arm.com> If you don't mind, I would pull the below paragraph into the commit message, since it's useful to have in the git history. Cheers, Andre. P.S. Just curious if we need a similar fix for Linux, or are we saved by the Linux code spending more time in setup before doing a transfer? > --- > On Cubie A7A board which using A733 SoC, we encoutered a SPI nor flash > timeout issue, it turns out that the SPI fifo reset take a few time to > settle down, Add a loop to poll the status. > > This was the error message shows on A7A board once this issue happened. > > => sf probe > ERROR: sun4i_spi: Timeout transferring data > Failed to initialize SPI flash at 0:0 (error -2) > --- > drivers/spi/spi-sunxi.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c > index e00532a371b..cf41905c7b7 100644 > --- a/drivers/spi/spi-sunxi.c > +++ b/drivers/spi/spi-sunxi.c > @@ -347,7 +347,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int bitlen, > struct sun4i_spi_priv *priv = dev_get_priv(bus); > struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev); > > - u32 len = bitlen / 8; > + u32 rst, val, len = bitlen / 8; > u8 nbytes; > int ret; > > @@ -363,8 +363,11 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int bitlen, > sun4i_spi_set_cs(bus, slave_plat->cs[0], true); > > /* Reset FIFOs */ > - setbits_le32(SPI_REG(priv, SPI_FCR), SPI_BIT(priv, SPI_FCR_RF_RST) | > - SPI_BIT(priv, SPI_FCR_TF_RST)); > + rst = SPI_BIT(priv, SPI_FCR_RF_RST) | SPI_BIT(priv, SPI_FCR_TF_RST); > + setbits_le32(SPI_REG(priv, SPI_FCR), rst); > + ret = readl_poll_timeout(SPI_REG(priv, SPI_FCR), val, !(rst & val), 20); > + if (ret) > + return -EBUSY; > > while (len) { > /* Setup the transfer now... */ > > --- > base-commit: 88dc2788777babfd6322fa655df549a019aa1e69 > change-id: 20260220-02-spi-fifo-reset-25e371314c3f > > Best regards, ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] spi: sunxi: wait for TX/RX fifo reset done 2026-04-30 9:54 ` Andre Przywara @ 2026-05-01 12:25 ` Yixun Lan 0 siblings, 0 replies; 4+ messages in thread From: Yixun Lan @ 2026-05-01 12:25 UTC (permalink / raw) To: Andre Przywara; +Cc: u-boot, linux-sunxi, Jagan Teki, Tom Rini, Jernej Skrabec Hi Andre, On 11:54 Thu 30 Apr , Andre Przywara wrote: > Hi, > > On 4/21/26 06:47, Yixun Lan wrote: > > Once reset SPI TX or RX fifo, the underlying hardware need to take > > some time to actually settle down, the two bits will automatically > > clear to 0, so use a poll mechanism to check status bits to make sure > > it's done correctly. > > Ah, interesting, thanks for posting this! > I looked into some manuals, and it seems like this self-clearing > property is already used in the A10, so it's fine to use unconditionally. > > > > > Signed-off-by: Yixun Lan <dlan@gentoo.org> > > Acked-by: Andre Przywara <andre.przywara@arm.com> > > If you don't mind, I would pull the below paragraph into the commit > message, since it's useful to have in the git history. > No, feel free to adjust.. And thanks I'd assume you will handle all this? so no need from my side to post new version > Cheers, > Andre. > > P.S. Just curious if we need a similar fix for Linux, or are we saved by > the Linux code spending more time in setup before doing a transfer? > I've not looked into Linux/Kernel side, since this is a hardware feature, so yes, we should do something similar (to be safe) > > --- > > On Cubie A7A board which using A733 SoC, we encoutered a SPI nor flash > > timeout issue, it turns out that the SPI fifo reset take a few time to > > settle down, Add a loop to poll the status. > > > > This was the error message shows on A7A board once this issue happened. > > > > => sf probe > > ERROR: sun4i_spi: Timeout transferring data > > Failed to initialize SPI flash at 0:0 (error -2) > > --- > > drivers/spi/spi-sunxi.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c > > index e00532a371b..cf41905c7b7 100644 > > --- a/drivers/spi/spi-sunxi.c > > +++ b/drivers/spi/spi-sunxi.c > > @@ -347,7 +347,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int bitlen, > > struct sun4i_spi_priv *priv = dev_get_priv(bus); > > struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev); > > > > - u32 len = bitlen / 8; > > + u32 rst, val, len = bitlen / 8; > > u8 nbytes; > > int ret; > > > > @@ -363,8 +363,11 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned int bitlen, > > sun4i_spi_set_cs(bus, slave_plat->cs[0], true); > > > > /* Reset FIFOs */ > > - setbits_le32(SPI_REG(priv, SPI_FCR), SPI_BIT(priv, SPI_FCR_RF_RST) | > > - SPI_BIT(priv, SPI_FCR_TF_RST)); > > + rst = SPI_BIT(priv, SPI_FCR_RF_RST) | SPI_BIT(priv, SPI_FCR_TF_RST); > > + setbits_le32(SPI_REG(priv, SPI_FCR), rst); > > + ret = readl_poll_timeout(SPI_REG(priv, SPI_FCR), val, !(rst & val), 20); > > + if (ret) > > + return -EBUSY; > > > > while (len) { > > /* Setup the transfer now... */ > > > > --- > > base-commit: 88dc2788777babfd6322fa655df549a019aa1e69 > > change-id: 20260220-02-spi-fifo-reset-25e371314c3f > > > > Best regards, > -- Yixun Lan (dlan) ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-05-01 12:26 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-04-21 4:47 [PATCH] spi: sunxi: wait for TX/RX fifo reset done Yixun Lan 2026-04-29 16:20 ` Jernej Škrabec 2026-04-30 9:54 ` Andre Przywara 2026-05-01 12:25 ` Yixun Lan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox