| Message ID | 20200626151946.1.I06134fd669bf91fd387dc6ecfe21d44c202bd412@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 638d8488ae00d2e5dd5033804e82b458d3cf85b1 |
| Headers | show |
| Series | spi: spi-geni-qcom: Don't set the cs if it was already right | expand |
On Fri, Jun 26, 2020 at 03:19:50PM -0700, Douglas Anderson wrote: > Setting the chip select on the Qualcomm geni SPI controller isn't > exactly cheap. Let's cache the current setting and avoid setting the > chip select if it's already right. Seems like it'd be worth pushing this up to the core - if we're constantly setting the same CS value then perhaps we ought to just stop doing that?
On Fri, 26 Jun 2020 15:19:50 -0700, Douglas Anderson wrote: > Setting the chip select on the Qualcomm geni SPI controller isn't > exactly cheap. Let's cache the current setting and avoid setting the > chip select if it's already right. > > Using "flashrom" to read or write the EC firmware on a Chromebook > shows roughly a 25% reduction in interrupts and a 15% speedup. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: spi-geni-qcom: Don't set the cs if it was already right commit: 638d8488ae00d2e5dd5033804e82b458d3cf85b1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Hi, On Mon, Jun 29, 2020 at 4:53 AM Mark Brown <broonie@kernel.org> wrote: > > On Fri, Jun 26, 2020 at 03:19:50PM -0700, Douglas Anderson wrote: > > Setting the chip select on the Qualcomm geni SPI controller isn't > > exactly cheap. Let's cache the current setting and avoid setting the > > chip select if it's already right. > > Seems like it'd be worth pushing this up to the core - if we're > constantly setting the same CS value then perhaps we ought to just stop > doing that? Posted: spi: Avoid setting the chip select if we don't need to https://lore.kernel.org/r/20200629164103.1.Ied8e8ad8bbb2df7f947e3bc5ea1c315e041785a2@changeid I see that you applied my patch to "spi-geni-qcom". If the patch to the core looks OK to you and lands, I think the one for the driver can be reverted (though it doesn't hurt). -Doug
diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c index 5b1dca1fff79..e99a9d57449f 100644 --- a/drivers/spi/spi-geni-qcom.c +++ b/drivers/spi/spi-geni-qcom.c @@ -79,6 +79,7 @@ struct spi_geni_master { unsigned int oversampling; spinlock_t lock; int irq; + bool cs_flag; }; static int get_spi_clk_cfg(unsigned int speed_hz, @@ -146,10 +147,15 @@ static void spi_geni_set_cs(struct spi_device *slv, bool set_flag) struct geni_se *se = &mas->se; unsigned long time_left; - pm_runtime_get_sync(mas->dev); if (!(slv->mode & SPI_CS_HIGH)) set_flag = !set_flag; + if (set_flag == mas->cs_flag) + return; + + mas->cs_flag = set_flag; + + pm_runtime_get_sync(mas->dev); spin_lock_irq(&mas->lock); reinit_completion(&mas->cs_done); if (set_flag)
Setting the chip select on the Qualcomm geni SPI controller isn't exactly cheap. Let's cache the current setting and avoid setting the chip select if it's already right. Using "flashrom" to read or write the EC firmware on a Chromebook shows roughly a 25% reduction in interrupts and a 15% speedup. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/spi/spi-geni-qcom.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)