Updated restricted chips have trouble processing multiple sequenced
operations. So remove the capability to sequence multiple operations and
reduce the maximum transfer size to 8 bytes.
Signed-off-by: Eddie James <[email protected]>
---
drivers/spi/spi-fsi.c | 27 +++++++--------------------
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-fsi.c b/drivers/spi/spi-fsi.c
index 3920cd3286d8..de359718e816 100644
--- a/drivers/spi/spi-fsi.c
+++ b/drivers/spi/spi-fsi.c
@@ -26,7 +26,7 @@
#define SPI_FSI_BASE 0x70000
#define SPI_FSI_INIT_TIMEOUT_MS 1000
#define SPI_FSI_MAX_XFR_SIZE 2048
-#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED 32
+#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED 8
#define SPI_FSI_ERROR 0x0
#define SPI_FSI_COUNTER_CFG 0x1
@@ -265,14 +265,12 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
struct fsi_spi_sequence *seq,
struct spi_transfer *transfer)
{
- bool docfg = false;
int loops;
int idx;
int rc;
u8 val = 0;
u8 len = min(transfer->len, 8U);
u8 rem = transfer->len % len;
- u64 cfg = 0ULL;
loops = transfer->len / len;
@@ -292,28 +290,17 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
return -EINVAL;
}
- if (ctx->restricted) {
- const int eidx = rem ? 5 : 6;
-
- while (loops > 1 && idx <= eidx) {
- idx = fsi_spi_sequence_add(seq, val);
- loops--;
- docfg = true;
- }
-
- if (loops > 1) {
- dev_warn(ctx->dev, "No sequencer slots; aborting.\n");
- return -EINVAL;
- }
+ if (ctx->restricted && loops > 1) {
+ dev_warn(ctx->dev,
+ "Transfer too large; no branches permitted.\n");
+ return -EINVAL;
}
if (loops > 1) {
+ u64 cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
+
fsi_spi_sequence_add(seq, SPI_FSI_SEQUENCE_BRANCH(idx));
- docfg = true;
- }
- if (docfg) {
- cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
if (transfer->rx_buf)
cfg |= SPI_FSI_COUNTER_CFG_N2_RX |
SPI_FSI_COUNTER_CFG_N2_TX |
--
2.27.0
On Wed, 24 Mar 2021 at 22:05, Eddie James <[email protected]> wrote:
>
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
>
> Signed-off-by: Eddie James <[email protected]>
Reviewed-by: Joel Stanley <[email protected]>
> ---
> drivers/spi/spi-fsi.c | 27 +++++++--------------------
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/spi/spi-fsi.c b/drivers/spi/spi-fsi.c
> index 3920cd3286d8..de359718e816 100644
> --- a/drivers/spi/spi-fsi.c
> +++ b/drivers/spi/spi-fsi.c
> @@ -26,7 +26,7 @@
> #define SPI_FSI_BASE 0x70000
> #define SPI_FSI_INIT_TIMEOUT_MS 1000
> #define SPI_FSI_MAX_XFR_SIZE 2048
> -#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED 32
> +#define SPI_FSI_MAX_XFR_SIZE_RESTRICTED 8
>
> #define SPI_FSI_ERROR 0x0
> #define SPI_FSI_COUNTER_CFG 0x1
> @@ -265,14 +265,12 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
> struct fsi_spi_sequence *seq,
> struct spi_transfer *transfer)
> {
> - bool docfg = false;
> int loops;
> int idx;
> int rc;
> u8 val = 0;
> u8 len = min(transfer->len, 8U);
> u8 rem = transfer->len % len;
> - u64 cfg = 0ULL;
>
> loops = transfer->len / len;
>
> @@ -292,28 +290,17 @@ static int fsi_spi_sequence_transfer(struct fsi_spi *ctx,
> return -EINVAL;
> }
>
> - if (ctx->restricted) {
> - const int eidx = rem ? 5 : 6;
> -
> - while (loops > 1 && idx <= eidx) {
> - idx = fsi_spi_sequence_add(seq, val);
> - loops--;
> - docfg = true;
> - }
> -
> - if (loops > 1) {
> - dev_warn(ctx->dev, "No sequencer slots; aborting.\n");
> - return -EINVAL;
> - }
> + if (ctx->restricted && loops > 1) {
> + dev_warn(ctx->dev,
> + "Transfer too large; no branches permitted.\n");
> + return -EINVAL;
> }
>
> if (loops > 1) {
> + u64 cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
> +
> fsi_spi_sequence_add(seq, SPI_FSI_SEQUENCE_BRANCH(idx));
> - docfg = true;
> - }
>
> - if (docfg) {
> - cfg = SPI_FSI_COUNTER_CFG_LOOPS(loops - 1);
> if (transfer->rx_buf)
> cfg |= SPI_FSI_COUNTER_CFG_N2_RX |
> SPI_FSI_COUNTER_CFG_N2_TX |
> --
> 2.27.0
>
On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
That's a very small limit, it would be nice to be able to identify
devices that can use the larger limit so they don't suffer needlessly.
On Thu, 2021-03-25 at 13:50 +0000, Mark Brown wrote:
> On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
>
> > Updated restricted chips have trouble processing multiple sequenced
> > operations. So remove the capability to sequence multiple
> > operations and
> > reduce the maximum transfer size to 8 bytes.
>
> That's a very small limit, it would be nice to be able to identify
> devices that can use the larger limit so they don't suffer
> needlessly.
Yes, this is only for the "restricted" controllers which are marked by
a different compatible string. I guess the commit message isn't
perfectly clear.
Thanks,
Eddie
On Thu, Mar 25, 2021 at 09:46:50AM -0500, Eddie James wrote:
> On Thu, 2021-03-25 at 13:50 +0000, Mark Brown wrote:
> > On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
> > > Updated restricted chips have trouble processing multiple sequenced
> > > operations. So remove the capability to sequence multiple
> > > operations and
> > > reduce the maximum transfer size to 8 bytes.
> > That's a very small limit, it would be nice to be able to identify
> > devices that can use the larger limit so they don't suffer
> > needlessly.
> Yes, this is only for the "restricted" controllers which are marked by
> a different compatible string. I guess the commit message isn't
> perfectly clear.
The commit message reads like there's a new version of the restricted
controllers that have even more limits.
On Wed, 24 Mar 2021 17:05:16 -0500, Eddie James wrote:
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: fsi: Remove multiple sequenced ops for restricted chips
commit: 3ed4c84cc7ac59dd383f1d77f7b04148ede2548d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark