All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Alain Volmat <alain.volmat@st.com>
Cc: amelie.delaunay@st.com, mcoquelin.stm32@gmail.com,
	alexandre.torgue@st.com, linux-spi@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, fabrice.gasnier@st.com
Subject: Re: [PATCH 10/18] spi: stm32: wait for completion in transfer_one()
Date: Wed, 5 Aug 2020 11:58:45 +0100	[thread overview]
Message-ID: <20200805105845.GE5556@sirena.org.uk> (raw)
In-Reply-To: <1596610933-32599-11-git-send-email-alain.volmat@st.com>

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Alain Volmat <alain.volmat@st.com>
Cc: amelie.delaunay@st.com, alexandre.torgue@st.com,
	linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
	mcoquelin.stm32@gmail.com, fabrice.gasnier@st.com,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 10/18] spi: stm32: wait for completion in transfer_one()
Date: Wed, 5 Aug 2020 11:58:45 +0100	[thread overview]
Message-ID: <20200805105845.GE5556@sirena.org.uk> (raw)
In-Reply-To: <1596610933-32599-11-git-send-email-alain.volmat@st.com>


[-- Attachment #1.1: Type: text/plain, Size: 1085 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-08-05 13:54 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  7:01 [PATCH 00/18] spi: stm32: various driver enhancements Alain Volmat
2020-08-05  7:01 ` Alain Volmat
2020-08-05  7:01 ` [PATCH 01/18] spi: stm32-spi: driver uses reset controller only at init Alain Volmat
2020-08-05  7:01   ` Alain Volmat
2020-08-05  7:01 ` [PATCH 02/18] spi: stm32-spi: defer probe for reset Alain Volmat
2020-08-05  7:01   ` Alain Volmat
2020-08-05 10:49   ` Mark Brown
2020-08-05 10:49     ` Mark Brown
2020-08-07 13:42     ` Alain Volmat
2020-08-07 13:42       ` Alain Volmat
2020-08-07 14:01       ` Mark Brown
2020-08-07 14:01         ` Mark Brown
2020-08-05  7:01 ` [PATCH 03/18] spi: stm32h7: remove unused mode fault MODF event handling Alain Volmat
2020-08-05  7:01   ` Alain Volmat
2020-08-05 10:51   ` Mark Brown
2020-08-05 10:51     ` Mark Brown
2020-08-05  7:01 ` [PATCH 04/18] spi: stm32: use bitfield macros Alain Volmat
2020-08-05  7:01   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 05/18] spi: stm32h7: replace private SPI_1HZ_NS with NSEC_PER_SEC Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 06/18] spi: stm32h7: fix irq handler Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 07/18] spi: stm32h7: rework rx fifo read function Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 08/18] spi: stm32h7: fix dbg/warn/err conditions in irq handler Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 09/18] spi: stm32h7: fix race condition at end of transfer Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 10:53   ` Mark Brown
2020-08-05 10:53     ` Mark Brown
2020-08-05  7:02 ` [PATCH 10/18] spi: stm32: wait for completion in transfer_one() Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 10:58   ` Mark Brown [this message]
2020-08-05 10:58     ` Mark Brown
2020-08-05  7:02 ` [PATCH 11/18] spi: stm32: fix fifo threshold level in case of short transfer Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 10:59   ` Mark Brown
2020-08-05 10:59     ` Mark Brown
2020-08-05  7:02 ` [PATCH 12/18] spi: stm32: move spi disable out of irq handler Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 11:01   ` Mark Brown
2020-08-05 11:01     ` Mark Brown
2020-08-05  7:02 ` [PATCH 13/18] spi: stm32h7: fix handling of dma transfer completed Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 11:02   ` Mark Brown
2020-08-05 11:02     ` Mark Brown
2020-08-05  7:02 ` [PATCH 14/18] spi: stm32: improve suspend/resume management Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 15/18] spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 11:02   ` Mark Brown
2020-08-05 11:02     ` Mark Brown
2020-08-05  7:02 ` [PATCH 16/18] spi: stm32: always perform registers configuration prior to transfer Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05 11:03   ` Mark Brown
2020-08-05 11:03     ` Mark Brown
2020-08-05  7:02 ` [PATCH 17/18] spi: stm32: properly handle 0 byte transfer Alain Volmat
2020-08-05  7:02   ` Alain Volmat
2020-08-05  7:02 ` [PATCH 18/18] spi: stm32h7: ensure message are smaller than max size Alain Volmat
2020-08-05  7:02   ` Alain Volmat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200805105845.GE5556@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alain.volmat@st.com \
    --cc=alexandre.torgue@st.com \
    --cc=amelie.delaunay@st.com \
    --cc=fabrice.gasnier@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.