[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9cb48440-c71e-4a73-8104-4780f0e98e72@sirena.org.uk>
Date: Mon, 8 Apr 2024 17:40:32 +0100
From: Mark Brown <broonie@...nel.org>
To: Théo Lebrun <theo.lebrun@...tlin.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Vaishnav Achath <vaishnav.a@...com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Rob Herring <robh@...nel.org>, linux-spi@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mips@...r.kernel.org,
Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
Gregory CLEMENT <gregory.clement@...tlin.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Tawfik Bayouk <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH v2 08/11] spi: cadence-qspi: add early busywait to
cqspi_wait_for_bit()
On Mon, Apr 08, 2024 at 04:42:43PM +0200, Théo Lebrun wrote:
> On Mon Apr 8, 2024 at 4:16 PM CEST, Mark Brown wrote:
> > On Fri, Apr 05, 2024 at 05:02:18PM +0200, Théo Lebrun wrote:
> > > The reason is to avoid hrtimer interrupts on the system. All read
> > > operations take less than 100µs.
> > Why would this be platform specific, this seems like a very standard
> > optimisation technique?
> It does not make sense if you know that all read operations take more
> than 100µs. I preferred being conservative. If you confirm it makes
> sense I'll remove the quirk.
It does seem plausible at least, and the time could be made a tuneable
with quirks or otherwise if that's needed. I think I'd expect the MIPS
platform you're working with to be towards the lower end of performance
for systems that are new enough to have this hardware.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists