From: Mark Brown <broonie@kernel.org>
To: Tudor.Ambarus@microchip.com
Cc: fancer.lancer@gmail.com, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH] spi: Limit the spi device max speed to controller's max speed
Date: Thu, 10 Dec 2020 18:16:30 +0000 [thread overview]
Message-ID: <20201210181630.GE4747@sirena.org.uk> (raw)
In-Reply-To: <6e182961-fb4e-d7f6-fe05-abfdd99d2ac5@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
On Thu, Dec 10, 2020 at 04:32:02PM +0000, Tudor.Ambarus@microchip.com wrote:
> On 12/10/20 5:33 PM, Mark Brown wrote:
> > It does work for now but it'd be nicer if we were doing this through
> > recording the decision on the transfer.
> Ok, we can drop the patch, as nobody complained about this until now. I can
TBH I've actually got it queued to apply and test, we can make things
better incrementally but it seems fine for now and it's backportable if
someone does run into trouble.
> work on a better approach. Are you saying that we should calibrate/adjust the
> maximum supported frequency on each operation/command? Most of the commands
> can work at the same frequency. I know an exception: on SPI NOR flashes, the
It's the way that everything else works. It's a bit inefficent though.
> jesd216 standard specifies that the READ SFDP command should be run at 50MHz,
> even though the rest of the commands/opcodes can run at a higher frequency.
> It is common that flashes can run this command at 50+ MHz, and nobody bothered
> about adjusting the frequency at run-time until now. That being said, maybe we
> can calibrate/adjust a generic max frequency for most of the commands and
> treat the exceptions on a per operation basis.
If the spec says 50MHz for that one op we should probably stick to that
by default - the chances of it making a difference seem low but better
to stay in spec if we can.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-10 18:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 17:35 [PATCH] spi: Limit the spi device max speed to controller's max speed Tudor Ambarus
2020-12-09 19:46 ` Serge Semin
2020-12-09 19:54 ` Mark Brown
2020-12-09 20:15 ` Serge Semin
2020-12-09 20:25 ` Mark Brown
2020-12-09 20:30 ` Serge Semin
2020-12-10 8:58 ` Tudor.Ambarus
2020-12-10 15:33 ` Mark Brown
2020-12-10 16:32 ` Tudor.Ambarus
2020-12-10 18:16 ` Mark Brown [this message]
2020-12-11 17:51 ` Mark Brown
2020-12-15 14:24 ` Geert Uytterhoeven
2020-12-16 8:25 ` Tudor.Ambarus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201210181630.GE4747@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Tudor.Ambarus@microchip.com \
--cc=fancer.lancer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).