From: Colin Foster <colin.foster@in-advantage.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: Asymmetric regmap read/write reg
Date: Thu, 10 Mar 2022 13:54:08 -0800 [thread overview]
Message-ID: <20220310215408.GA3149079@euler> (raw)
Hi Mark, Regmap Abstraction realm,
I'm writing the driver for Ocelot chips over SPI. My latest RFC can be
found here, specifically the patch that utilzes regmap.
https://patchwork.kernel.org/project/netdevbpf/patch/20220307021208.2406741-11-colin.foster@in-advantage.com/
There's an interesting issue that comes about that isn't currently
supported by regmap - specifically in bus read / write operations.
The Ocelot chip has requires 100ns between address write and when the
address is ready to be clocked out. This can be dealt with in three
different ways:
1. Use a slow enough clock speed
2. Use a delay between address write and value read
3. Clock out N padding bytes to account for the 100ns access time
Forcing a slow clock speed is obviously not ideal, and forcing a delay
between "write_then_read" sounds too driver-specific, so option 3 seems
like the best option - especially if bulk reads are utilized.
Where regmap comes in is specifically the padding bytes. Reads require
the padding bytes, and writes don't. So this brings in new requirements
where a specific map->format.format_write would actually become
map->format_tx.format_write and map->format_rx.format_write. Several
other parameters (format_reg, work_buf) would also be affected.
In other words: 32-bit register writes could be
| A | A | A | V1 | V2 | V3 | V4 |
while reads could be:
| A | A | A | P | P | V1 | V2 | V3 | V4 |
and sequential R/W operations wouldn't require padding.
So my questions:
Is this a valid use-case (extension) of the regmap bus? And something
that might want to be supported?
Has this type of work been considered previously?
My other options are to fall back to a slower clock speed and try to
use regmap-spi bus as-is. The addresses get down-shifted by two, so
there's a smaller complication there. But this should allow for async
writes, which I came across when trying to apply a heartbeat trigger to
an attached GPIO LED.
Or I can continue with my current implementation of just using single
register reads / writes and forego the regmap_bus entirely. Though using
bulk reads alone would probably provide ~150% performance increase.
Do you have any suggestions / initial feedback? Maybe there's something
I'm missing.
Thank you very much,
Colin Foster
next reply other threads:[~2022-03-10 21:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 21:54 Colin Foster [this message]
2022-03-11 13:26 ` Asymmetric regmap read/write reg Mark Brown
2022-03-11 19:27 ` Colin Foster
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=20220310215408.GA3149079@euler \
--to=colin.foster@in-advantage.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@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