linux-sunxi.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Maxim Kiselev' <bigunclemax@gmail.com>,
	Icenowy Zheng <icenowy@aosc.io>,
	Samuel Holland <samuel@sholland.org>,
	Mark Brown <broonie@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
	Heiko Stuebner <heiko.stuebner@vrull.eu>,
	Maxime Ripard <mripard@kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-sunxi@lists.linux.dev" <linux-sunxi@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v3 2/5] spi: sun6i: change OF match data to a struct
Date: Wed, 10 May 2023 11:13:06 +0100	[thread overview]
Message-ID: <20230510111306.52e30f26@donnerap.cambridge.arm.com> (raw)
In-Reply-To: <1592f46b0f794b24a87a964d7208da68@AcuMS.aculab.com>

On Wed, 10 May 2023 08:55:27 +0000
David Laight <David.Laight@ACULAB.COM> wrote:

Hi David,

> From: Maxim Kiselev
> > Sent: 10 May 2023 09:34
> > 
> > Hi, David
> >   
> > > Is it worth doing a structure copy at this point?
> > > The 'cfg' data is short and constant and it would make

Sorry, I don't really get the reason for this. Since the data is constant,
wouldn't it make much more sense to keep it there in the const section,
which we need anyway? What would a second copy bring us?

> > > the code that uses it smaller and faster.  

Smaller: Do you mean the generated code? Not sure that really matters, but
your sketch below hints that the C code would get larger, more error prone
(you mention yourself that you skipped over the error checking) and most
importantly harder to read.

Faster: Do you have numbers that back that up, or does that solve a
particular problem of yours?
This is programming a SPI controller transfer, which runs in the vicinity
of a few Mbits/s. I doubt that saving a few memory accesses (once
per transfer, not per word) matters even the slightest?
The actual MMIO access to program the controller registers already takes
a few dozen to a few hundred cycles, so I doubt that doing a struct copy
saves us anything here, in practice.

Besides: Copying the pointer is the most common pattern in the kernel, I
believe. I just sampled 21 SPI drivers in the tree, 17 out of them do
this. The other either copy the members of the struct into the driver data
(which would be an option for us, too), or immediately consume the data in
the probe() routine.

If you have some good reason to optimise this, please send a patch (on
top).

Cheers,
Andre.

> > 
> > I'm sorry but I don't fully understand what you are suggesting.
> > In patch 3\5 we extend the sun6i_spi_cfg structure with the has_clk_ctl field.  
> 
> You are still only adding a second integer.
> 
> I'm suggesting that instead of sspi->cfg being a pointer to the
> config data it is a copy of the config data.
> So the assignment below becomes (ignoring error checks)
> 	memcpy(&sspi->cfg, of_device_get_match_data(&pdev->dev), sizeof sspi->cfg);
> and the code that needs the values is:
> 	sspi->cfg.fifo_depth
> (etc)
> 
> 	David
> 
> > 
> > пн, 8 мая 2023 г. в 12:47, David Laight <David.Laight@aculab.com>:  
> > >
> > > From: Maksim Kiselev  
> > > > Sent: 07 May 2023 00:26
> > > >
> > > > As we're adding more properties to the OF match data, convert it to a
> > > > struct now.
> > > >  
> > > ...  
> > > > -     sspi->fifo_depth = (unsigned long)of_device_get_match_data(&pdev->dev);
> > > > +     sspi->cfg = of_device_get_match_data(&pdev->dev);  
> > >
> > > Is it worth doing a structure copy at this point?
> > > The 'cfg' data is short and constant and it would make
> > > the code that uses it smaller and faster.
> > >
> > >         David
> > >
> > > -
> > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > Registration No: 1397386 (Wales)
> > >  
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)


  reply	other threads:[~2023-05-10 10:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-06 23:26 [PATCH v3 0/5] Allwinner R329/D1/R528/T113s SPI support Maksim Kiselev
2023-05-06 23:26 ` [PATCH v3 1/5] dt-bindings: spi: sun6i: add DT bindings for Allwinner R329/D1/R528/T113s SPI Maksim Kiselev
     [not found]   ` <835082fe07b77db8598aebabe98a74c2c5ac47d1.camel@aosc.io>
2023-05-07  7:43     ` Krzysztof Kozlowski
2023-05-07  9:50     ` Andre Przywara
2023-05-07  7:43   ` Krzysztof Kozlowski
2023-05-06 23:26 ` [PATCH v3 2/5] spi: sun6i: change OF match data to a struct Maksim Kiselev
2023-05-08  9:47   ` David Laight
2023-05-10  8:33     ` Maxim Kiselev
2023-05-10  8:55       ` David Laight
2023-05-10 10:13         ` Andre Przywara [this message]
2023-05-06 23:26 ` [PATCH v3 3/5] spi: sun6i: add quirk for in-controller clock divider Maksim Kiselev
2023-05-07  9:51   ` Andre Przywara
2023-05-07 15:09     ` Maxim Kiselev
2023-05-06 23:26 ` [PATCH v3 4/5] spi: sun6i: add support for R329/D1/R528/T113s SPI controllers Maksim Kiselev
2023-05-07  9:52   ` Andre Przywara
2023-05-06 23:26 ` [PATCH v3 5/5] riscv: dts: allwinner: d1: Add SPI controllers node Maksim Kiselev
2023-05-07  9:52   ` Andre Przywara

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=20230510111306.52e30f26@donnerap.cambridge.arm.com \
    --to=andre.przywara@arm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=aou@eecs.berkeley.edu \
    --cc=bigunclemax@gmail.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko.stuebner@vrull.eu \
    --cc=icenowy@aosc.io \
    --cc=jernej.skrabec@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mripard@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.org \
    --cc=wens@csie.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).