From: Mark Brown <broonie@kernel.org>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Sowjanya Komatineni <skomatineni@nvidia.com>,
thierry.reding@gmail.com, jonathanh@nvidia.com,
robh+dt@kernel.org, lukas@wunner.de, bbrezillon@kernel.org,
p.yadav@ti.com, tudor.ambarus@microchip.com,
linux-spi@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 5/9] spi: spi-mem: Allow masters to transfer dummy cycles directly by hardware
Date: Mon, 14 Dec 2020 16:23:15 +0000 [thread overview]
Message-ID: <20201214162315.GA4880@sirena.org.uk> (raw)
In-Reply-To: <20201212115715.31a8d755@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]
On Sat, Dec 12, 2020 at 11:57:15AM +0100, Boris Brezillon wrote:
> Sowjanya Komatineni <skomatineni@nvidia.com> wrote:
> > This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers
> > that support transfer of dummy cycles by the hardware directly.
> Hm, not sure this is a good idea. I mean, if we expect regular SPI
> devices to use this feature, then why not, but if it's just for
> spi-mem, I'd recommend implementing a driver-specific exec_op() instead
> of using the default one.
I *have* seen other high speed devices which had padding bits in the
transfer (see regmap's pad_bits feature), I think that corresponds to
flash dummy bits but haven't checked that the hardware support lines up.
I'm not sure it's ever been seen as something that we particularly
needed to speed up with hardware offload though.
> If we go for those core changes, we should at least add a
> ctrl->max_dummy_cycles field so the core can fallback to regular writes
> when the number of dummy cycles in the spi_mem_op exceeds what the
> controller can do.
That seems sensible if there's a risk of controllers being too limited,
which knowing hardware seems likely.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-14 16:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 21:15 [PATCH v3 0/9] Add Tegra Quad SPI driver Sowjanya Komatineni
2020-12-11 21:15 ` [PATCH v3 1/9] dt-bindings: clock: tegra: Add clock ID TEGRA210_CLK_QSPI_PM Sowjanya Komatineni
2020-12-15 16:03 ` Rob Herring
2020-12-11 21:15 ` [PATCH v3 2/9] dt-bindings: spi: Add Tegra Quad SPI device tree binding Sowjanya Komatineni
2020-12-15 16:13 ` Rob Herring
2020-12-11 21:15 ` [PATCH v3 3/9] MAINTAINERS: Add Tegra Quad SPI driver section Sowjanya Komatineni
2020-12-11 21:15 ` [PATCH v3 4/9] spi: tegra210-quad: Add support for Tegra210 QSPI controller Sowjanya Komatineni
2020-12-12 12:06 ` Lukas Wunner
2020-12-11 21:15 ` [PATCH v3 5/9] spi: spi-mem: Allow masters to transfer dummy cycles directly by hardware Sowjanya Komatineni
2020-12-12 10:57 ` Boris Brezillon
2020-12-12 17:28 ` Sowjanya Komatineni
2020-12-13 9:54 ` Boris Brezillon
2020-12-13 11:28 ` Boris Brezillon
2020-12-13 17:34 ` Sowjanya Komatineni
2020-12-14 16:23 ` Mark Brown [this message]
2020-12-11 21:16 ` [PATCH v3 6/9] spi: tegra210-quad: Add support for hardware dummy cycles Sowjanya Komatineni
2020-12-13 10:14 ` Boris Brezillon
2020-12-11 21:16 ` [PATCH v3 7/9] arm64: tegra: Enable QSPI on Jetson Nano Sowjanya Komatineni
2020-12-11 21:16 ` [PATCH v3 8/9] arm64: tegra: Add QSPI nodes on Tegra194 Sowjanya Komatineni
2020-12-11 21:16 ` [PATCH v3 9/9] arm64: tegra: Enable QSPI on Jetson Xavier NX Sowjanya Komatineni
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=20201214162315.GA4880@sirena.org.uk \
--to=broonie@kernel.org \
--cc=bbrezillon@kernel.org \
--cc=boris.brezillon@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=p.yadav@ti.com \
--cc=robh+dt@kernel.org \
--cc=skomatineni@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=tudor.ambarus@microchip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).