[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200805105845.GE5556@sirena.org.uk>
Date: Wed, 5 Aug 2020 11:58:45 +0100
From: Mark Brown <broonie@...nel.org>
To: Alain Volmat <alain.volmat@...com>
Cc: amelie.delaunay@...com, mcoquelin.stm32@...il.com,
alexandre.torgue@...com, linux-spi@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
fabrice.gasnier@...com
Subject: Re: [PATCH 10/18] spi: stm32: wait for completion in transfer_one()
On Wed, Aug 05, 2020 at 09:02:05AM +0200, Alain Volmat wrote:
> We could make transfer_one() blocking till the end of the transfer
> and bypass the wait/timeout mechanism in spi_transfer_one_message().
> But if for some reason, we never get either an error (OVR, SUSP) event
> or end of transfer (EOT) event, xfer_completion will never "complete".
> That's why a timeout is useful here to avoid a hang. Timeout delay is
> deducted from the transfer length, the real speed and the optional delay
> we can add between each data frames. Timeout delay is doubled compared to
> the theorical transfer duration.
> While doing it to address irq mode only, take benefit of the new
> code structure and wait also in dma mode so an eventual error can be
> returned to the framework.
I can't tell from this changelog what this change is intended to do
which makes it very difficult to review. If the timeout is too short
for some systems under extreme load it would be better to provide a
generic way of configuring it rather than open coding timeouts, or
otherwise improve the generic code.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists