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/[email protected]/
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