Asymmetric regmap read/write reg

Asymmetric regmap read/write reg

[Colin Foster]

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

Re: Asymmetric regmap read/write reg

[Mark Brown]

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

On Thu, Mar 10, 2022 at 01:54:08PM -0800, Colin Foster wrote:

> 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

Why not implement this using a delay?  That seems both more
straightforward and likely tending to be more accurate given that clock
rates for SPI devices tend to be a bit vague.  Much less disruptive to
implement too.

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

Re: Asymmetric regmap read/write reg

[Colin Foster]

On Fri, Mar 11, 2022 at 01:26:29PM +0000, Mark Brown wrote:
> On Thu, Mar 10, 2022 at 01:54:08PM -0800, Colin Foster wrote:
> 
> > 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
> 
> Why not implement this using a delay?  That seems both more
> straightforward and likely tending to be more accurate given that clock
> rates for SPI devices tend to be a bit vague.  Much less disruptive to
> implement too.

Hi Mark,

Thanks, that's a good idea. I'll reconsider that strategy, especially
since I now have a better understanding of the SPI <> Regmap <> bus
interactions.

Much appreciated!