Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Thu, 10 Mar 2022 13:54:08 -0800
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
Message-ID: <20220310215408.GA3149079@euler>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GFU0l5NrcR+SeDV0NWF0/yeOVLt5vAPnB9lCQOGIqAUGt96tZwwMBfYkBFOE?=
 =?us-ascii?Q?um0WszyaxGZT+kkkCiLHHU9gKU9UwRBmFyxHi595gD805eWwGbIouw0cPd4j?=
 =?us-ascii?Q?z/PhqXbASUjeACsrbOWO/ocr/d4cgJZZjoJvzWPhpqkF+b5GEldQkaqQUAFg?=
 =?us-ascii?Q?U6m8FZjns2ON/2kyWhBrco7g+7SWqwj1xsgqy/yHYCOxgY9ZOJzSF1fRK+Nw?=
 =?us-ascii?Q?YYoKDB4wZ2wQt8CotsKH6AR0Kn1C/GkysHVYi7TK0yDNIhmqsY/FX7XuaC1S?=
 =?us-ascii?Q?+mnyiYgDx5ALSFUyskyf/sMC33vBmtDSlHm2N4jU1bLCYEpUv46Pl9N3F1fI?=
 =?us-ascii?Q?YIRiYgiH2BCBflGVs2/y3yM7qO47xv0aAEh4SI8bkh/3Hvc5+O8/o1ajKCv+?=
 =?us-ascii?Q?nhlNrW3q3viPP1zoy7oQCW4J/P7NvKVTAPVIqKvFhQtyV+9spK9wNnswFyx+?=
 =?us-ascii?Q?eATlNcT5WWJsdh3CuUxZefwTB2+QxUQTf63/x4b0o3FpVTXNZ85LrdcqCG2t?=
 =?us-ascii?Q?Huu+hTBhsj1frw41qLD8tSXu2rlMQxkQkmYX386TAEiqr7gxAgIa4x4HGG+4?=
 =?us-ascii?Q?ZdBDf0KPlZGrvMuoNRS8FOY0ozxE9hvTtp2VzhUE6XODbvU6506HQki8lgTE?=
 =?us-ascii?Q?PVF2AAHKT4yqsUh/EVYP7R/0UXVwXT94L2XRES3T8VZptZ2tOAb5GP9iMy9U?=
 =?us-ascii?Q?R8tTO2TtyhBONJmFllivNS7XOPdDa6LIkOhsSnAg1l3uZ/iDJOA8nHN+k8fn?=
 =?us-ascii?Q?QXJg/tr1lPenwL3ADJpDruDMiOzymbwaVm/MhrbRIz1p55jkmU7mur8gcqNj?=
 =?us-ascii?Q?T7wveDEr5D5bkJHbbePjqc6fKKi5Hq1tJwm19NAqNPYvo1StwG1ZzIEqQ7bd?=
 =?us-ascii?Q?sixy23gAfQmA049XKo0wpUkATYrZzvVAlvUrUmzNLHXYET31BdVK85h4L6Rc?=
 =?us-ascii?Q?Rg96CH8UlMmK9XKBUsI/uBcpJ6fjr5pIKN6cDaYzHdUd4zKTzgyXArphXNO5?=
 =?us-ascii?Q?1hpg2gUQyZ+5x19xyLZp/S+4d59PDWXqtu1MHmeIQXyVXBxIls9iYN2toQu6?=
 =?us-ascii?Q?oSUqE8kDpBCd7QE0SeD16pazD9jfhxlH1hGOdZm2Qe8DHHdpUqoutCcl7GWH?=
 =?us-ascii?Q?EDuihRoWYgGpQ5Cc80k/JpTR/cdi7/wDWfEwV1TsorTSHIhSDbiAizDDlShf?=
 =?us-ascii?Q?YZywVAgX1juQjwtSVMVp0+Ab+ZwSDAkwu3DWLBj0f3LopqvdFPBNjCK2F2st?=
 =?us-ascii?Q?Acl7pwPtFPL3UNePw/YcflJ5KgR4NIui5cpeSscBO2c7BaFwCgWbTFY+c05X?=
 =?us-ascii?Q?AHhoY3hMzMhckTBCVd/gCH12umg9DnNy9QfxDuRWe3kBo0lbJoeyA6aT9rz5?=
 =?us-ascii?Q?X9+/90xKg5HbC4F2sk7KjOJtVtCQEYxzPC4awuNFK+DwWh2BQM+QLDSgLFL/?=
 =?us-ascii?Q?CgzsHU/L2KXU7ZyamnWfyVJit83iDjw2i/L1NYM/tXvjBTYMoVtR5QkiCw85?=
 =?us-ascii?Q?DjDdNIOtzS/Kyds=3D?=
X-OriginatorOrg: in-advantage.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78af5b52-3e52-4614-2eb1-08da02e083ea
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2351.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2022 21:54:13.8407
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 48e842ca-fbd8-4633-a79d-0c955a7d3aae
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 89TgRJKJZTOqwjrEDGD6X7oQtFkXtPYk5nDMBeefbp2DRBHusHxsDmcqS081X2xkyD05luz2QE6zacDx6PfO/1G8eKyzPKXDZ0R31NlWq9M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4805
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE,
	SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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