[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83c4b75a-06d7-9fca-ffa0-f2e6a6ae7aed@collabora.com>
Date: Tue, 11 Jul 2023 10:28:13 +0200
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mark Brown <broonie@...nel.org>,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
Yang Yingliang <yangyingliang@...wei.com>,
Amit Kumar Mahapatra via Alsa-devel
<alsa-devel@...a-project.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Tharun Kumar P <tharunkumar.pasumarthi@...rochip.com>,
Vijaya Krishna Nivarthi <quic_vnivarth@...cinc.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-amlogic@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
linux-rockchip@...ts.infradead.org,
linux-riscv@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com,
linux-trace-kernel@...r.kernel.org, netdev@...r.kernel.org
Cc: Sanjay R Mehta <sanju.mehta@....com>,
Radu Pirea <radu_nicolae.pirea@....ro>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
Tudor Ambarus <tudor.ambarus@...aro.org>,
Serge Semin <fancer.lancer@...il.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Heiko Stuebner <heiko@...ech.de>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Chunyan Zhang <zhang.lyra@...il.com>,
Alain Volmat <alain.volmat@...s.st.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Max Filippov <jcmvbkbc@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH v2 04/15] spi: Replace open coded
spi_controller_xfer_timeout()
Il 10/07/23 17:49, Andy Shevchenko ha scritto:
> Since the new spi_controller_xfer_timeout() helper appeared,
> we may replace open coded variant in spi_transfer_wait().
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> ---
> drivers/spi/spi.c | 25 ++-----------------------
> include/linux/spi/spi.h | 6 +++++-
> 2 files changed, 7 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 125dea8fae00..c99ee4164f11 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1342,8 +1342,7 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
> {
> struct spi_statistics __percpu *statm = ctlr->pcpu_statistics;
> struct spi_statistics __percpu *stats = msg->spi->pcpu_statistics;
> - u32 speed_hz = xfer->speed_hz;
> - unsigned long long ms;
> + unsigned long ms;
>
> if (spi_controller_is_slave(ctlr)) {
> if (wait_for_completion_interruptible(&ctlr->xfer_completion)) {
> @@ -1351,29 +1350,9 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
> return -EINTR;
> }
> } else {
> - if (!speed_hz)
> - speed_hz = 100000;
> -
> - /*
> - * For each byte we wait for 8 cycles of the SPI clock.
> - * Since speed is defined in Hz and we want milliseconds,
> - * use respective multiplier, but before the division,
> - * otherwise we may get 0 for short transfers.
> - */
> - ms = 8LL * MSEC_PER_SEC * xfer->len;
> - do_div(ms, speed_hz);
> -
> - /*
> - * Increase it twice and add 200 ms tolerance, use
> - * predefined maximum in case of overflow.
> - */
> - ms += ms + 200;
> - if (ms > UINT_MAX)
> - ms = UINT_MAX;
> -
> + ms = spi_controller_xfer_timeout(ctlr, xfer);
I agree on using helpers, but the logic is slightly changing here: yes it is
unlikely (and also probably useless) to get ms == UINT_MAX, but the helper is
limiting the maximum timeout value to 500mS, which may not work for some slow
controllers/devices.
This should get validated on more than a few platforms, and I'm not sure that
this kind of validation would be "fast" to get... so, probably the best thing
to do here is to add a warning in case the timeout exceeds 500mS, print the
actual value, keep it like this for a kernel version or two and check reports:
that would allow to understand what a safe maximum timeout value could be.
Aside from that, I wouldn't drop those nice comments explaining how/why the
timeout is calculated: I know how, but not everyone knows in advance.
Regards,
Angelo
> ms = wait_for_completion_timeout(&ctlr->xfer_completion,
> msecs_to_jiffies(ms));
> -
> if (ms == 0) {
> SPI_STATISTICS_INCREMENT_FIELD(statm, timedout);
> SPI_STATISTICS_INCREMENT_FIELD(stats, timedout);
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 32c94eae8926..0ce1cb18a076 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -1270,12 +1270,16 @@ static inline bool spi_is_bpw_supported(struct spi_device *spi, u32 bpw)
> * that it would take on a single data line and take twice this amount of time
> * with a minimum of 500ms to avoid false positives on loaded systems.
> *
> + * Assume speed to be 100 kHz if it's not defined at the time of invocation.
> + *
> * Returns: Transfer timeout value in milliseconds.
> */
> static inline unsigned int spi_controller_xfer_timeout(struct spi_controller *ctlr,
> struct spi_transfer *xfer)
> {
> - return max(xfer->len * 8 * 2 / (xfer->speed_hz / 1000), 500U);
> + u32 speed_hz = xfer->speed_hz ?: 100000;
> +
> + return max(xfer->len * 8 * 2 / (speed_hz / 1000), 500U);
> }
>
> /*---------------------------------------------------------------------------*/
Powered by blists - more mailing lists