From: Mark Brown <broonie@kernel.org>
To: kernel@martin.sperl.org
Cc: Jon Hunter <jonathanh@nvidia.com>,
linux-tegra <linux-tegra@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-spi@vger.kernel.org
Subject: Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
Date: Tue, 15 Jan 2019 19:26:19 +0000 [thread overview]
Message-ID: <20190115192619.GG5522@sirena.org.uk> (raw)
In-Reply-To: <AAA7943B-B1F1-4389-AAC3-8621EC6E38B8@martin.sperl.org>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
On Tue, Jan 15, 2019 at 06:39:27PM +0100, kernel@martin.sperl.org wrote:
> Is it possible that the specific flash is not using the “normal”
> spi_pump_message, but spi_controller_mem_ops operations?
Right, that's my best guess at the minute as well.
> Maybe we are missing the teardown in that driver or something is
> changing flags there.
> grepping a bit:
> I see spi_mem_access_start calling spi_flush_queue, which is calling
> pump_message, which - if there is no transfer - will trigger a delayed
> tear-down, while it maybe should not be doing that.
If nothing else it's inefficient.
> Maybe spi_mem_access_end needs a call to spi_flush_queue as well?
Hrm, or needs to schedule the queue at any rate (though this will only
have an impact in the fairly unusual case where there's something
sharing the bus with a flash).
> Unfortunately this is theoretical work and quite a lot of guesswork
> without an actual device available for testing...
Indeed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-01-15 19:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 15:35 Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed Jon Hunter
[not found] ` <7C4A5EFC-8235-40C8-96E1-E6020529DF72@martin.sperl.org>
2019-01-15 14:26 ` Jon Hunter
2019-01-15 15:10 ` Mark Brown
2019-01-15 16:09 ` Jon Hunter
2019-01-15 19:27 ` Mark Brown
2019-01-15 17:39 ` kernel
2019-01-15 19:26 ` Mark Brown [this message]
2019-01-15 20:58 ` Martin Sperl
2019-01-15 21:25 ` Mark Brown
2019-01-16 11:01 ` Jon Hunter
2019-01-18 17:11 ` kernel
2019-01-18 19:12 ` Mark Brown
2019-01-20 11:24 ` kernel
2019-01-23 17:56 ` Mark Brown
2019-05-09 19:47 ` Martin Sperl
2019-05-12 8:54 ` Mark Brown
2019-01-16 10:58 ` Jon Hunter
2019-01-22 9:36 ` Geert Uytterhoeven
2019-01-23 8:26 ` Marek Szyprowski
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=20190115192619.GG5522@sirena.org.uk \
--to=broonie@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=kernel@martin.sperl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox