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:   Fri, 11 Mar 2022 11:27:30 -0800
From:   Colin Foster <colin.foster@in-advantage.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: Asymmetric regmap read/write reg
Message-ID: <20220311192730.GA265@COLIN-DESKTOP1.localdomain>
References: <20220310215408.GA3149079@euler>
 <YitOBbJd4mY3hjSA@sirena.org.uk>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YitOBbJd4mY3hjSA@sirena.org.uk>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Jcl8erm0IDJJER1tEKhy1lvuZv3FDZwEXfjQHpq+SulMiYgf2hKupyxxrFoI?=
 =?us-ascii?Q?9nC/aXIDNE7rqjMmLb12L4/Q6Mk9TWyb0JOl5JO8+gTq0VsN8ESZhWj4y+Ai?=
 =?us-ascii?Q?0tMy4HkcFnNTwDDBGnnn+ukbucXL2HajvNjI6CKKyXctdmC7+QeB/zg3LuRE?=
 =?us-ascii?Q?NcU9OfZ5NZMX1hpWaDo7CTV20GC9xmo+i4hHcluQ/XeoIEQOrojU/1424WsD?=
 =?us-ascii?Q?fieiW5TdLvr7Atyy3ZYvcoE+VaOJ6HVuxhshhZpUAOIkXS1c2WiWesX3Qf5o?=
 =?us-ascii?Q?Mll17hFKEz34dyGd95PiKbRnZH4orKrxyICLm4hp6q9dotyokITZY3j3Ag+2?=
 =?us-ascii?Q?boSENxo+0ocGltMtasUMGZsZxb2LuvvJf5lp8ZNfHtMDpEm1jLdymdOChaVW?=
 =?us-ascii?Q?ubDqQjUCJhvx7HdpZa8ZjXd1hYvczedCAepdLPuMrOeaEu2XWbGi4SHU/S58?=
 =?us-ascii?Q?/uFoVM0FkpLi6RKPMJI4SIJXQx/3llfeVe3UEc3Ni/nyGDI03wWY2Y9IXhO0?=
 =?us-ascii?Q?1rVL/Tx+jhJ6YHjiimTVtYntji0eH7en4clD6tJha5t2A86Ni5XzqALQg2So?=
 =?us-ascii?Q?YH5fGpaiwLoxm2XTMKljhfsEd606Nxo/mS8XGpvvssAIOiZUy+2/v8CSzHr7?=
 =?us-ascii?Q?w0wCGe4LGpMDpmHHAIILWO4FUvMtNg9uwlZLW7yBt7u5ABvf0WN3NmhXzQWh?=
 =?us-ascii?Q?s8kH8JBE53WCbZxiX93NERvlMdzEBu8sS2XAkgBWc6mw1ALIntvpwRboscNd?=
 =?us-ascii?Q?FSEgJccNaufdpTh0429n7D+8YfCbQrk6SktPv/DYv1HTmeaeewIeD0FPlz2b?=
 =?us-ascii?Q?GiSBHBepBTUY7MuaV9OuGR+lnh13lXAPRTGSz+mN8VTWeUzyLUKQhU8PntM6?=
 =?us-ascii?Q?1WsYikqD9pQemIlVI6XkEYDtmbkTITyFOGgT7rPiFHe5fqc3paKKG0Btwkma?=
 =?us-ascii?Q?wgSnA5IswAk7EsWRBPvy4hPWo/Bp9v0ijf0d8fPYg/xC5kE69MTvEyv1wO78?=
 =?us-ascii?Q?CH1q11LFgrmCQrGbrznEvaaKiwKptSsBxE+boeCGDeQAW0dVtSHqySjTj5qZ?=
 =?us-ascii?Q?OX+sEKWB/fHGzLj3jnF/7D2JF1bAJFcLN6Oxqwz2XJ5u0Ho+PYmYqvOeORnw?=
 =?us-ascii?Q?OERSnS+1WPATuU/lA4kio/uDV1vM/q10DXd5ZAqabN1T6LpV6fhFnbpt+osN?=
 =?us-ascii?Q?1htaZ+DghDgj2wz6/AKja7BHyKPQOV3SZe2yVgNF2EQV4IxoKihD/6AkgCTf?=
 =?us-ascii?Q?WBX+NhosWI2SmBSb4gxwbM4++OsCBdVQQC/9NEibXsgmlCygMk1JnSAXMvKD?=
 =?us-ascii?Q?Pay6UdtfAzKHBG0ZgVprKLyNQ1Gv1xWDBZOvm8oSsiTTi+nInOKoDSMTSmXM?=
 =?us-ascii?Q?UlY+I9Ae2PSTTaZS5zu8eqOSJMdaWJh/DR1lPxVg4jgdDVAIGSBC/NwomGvQ?=
 =?us-ascii?Q?IHi6cpsItYeetpBbCQFiTZZyetWMVj+p9UPKnFnLDeKWPbdWAb2SDw=3D=3D?=
X-OriginatorOrg: in-advantage.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e84f98c6-d1c0-48eb-2440-08da039531eb
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2351.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2022 19:27:35.2288
 (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: 3PrpzW87zgkUmLp2lOVC0sXZaQxESnCuCmAtecgaS4SpSm3RkZEpvSLmExqV2K1TljSQxy4JVX9n6QTcl2NoxmZ6i7SYPXBK6m9CO1nJHPE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4843
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

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!