All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Jisheng Zhang <jszhang@marvell.com>,
	linux-pwm@vger.kernel.org, Thomas Hebb <tommyhebb@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	kernel@pengutronix.de
Subject: Re: [PATCH 2/4] pwm: berlin: Put channel config into driver data
Date: Mon, 8 Nov 2021 14:08:43 +0100	[thread overview]
Message-ID: <20211108130843.zcug25uy4ubijdcu@pengutronix.de> (raw)
In-Reply-To: <YYkThshvvjq06KNU@orome.fritz.box>

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

On Mon, Nov 08, 2021 at 01:09:42PM +0100, Thierry Reding wrote:
> On Tue, May 04, 2021 at 03:25:35PM +0200, Uwe Kleine-König wrote:
> > Instead of allocating extra data in .request() provide the needed memory
> > in struct berlin_pwm_chip. This reduces the number of allocations. A side
> > effect is that on suspend and resume the state for all four channels is
> > always saved and restored. This is easier (and probably quicker) than
> > looking up the matching pwm_device and checking its PWMF_REQUESTED bit.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> >  drivers/pwm/pwm-berlin.c | 37 ++++++-------------------------------
> >  1 file changed, 6 insertions(+), 31 deletions(-)
> 
> This doesn't look like a worthwhile change to me. The per-PWM channel
> data was originally introduced to support exactly this type of use-case,
> so I don't see why we shouldn't keep using it here.

My reasons to not use the per-channel data are:

 - up to 5 smaller mallocs instead of a single bigger one. A single
   allocation is more effective (AFAIK) regarding memory management
   overhead, memory management overhead, and cache locality

 - bad naming, this isn't per-chip data as the function name
   "pwm_set_chip_data" suggests, but per-channel ("pwm"?) data.

 - maybe subjectively the data model is easier to understand if all
   required data (clk, channel state etc) is in a single data structure

 - With an arm allmodconfig bloat-o-meter reports for my patch:

	add/remove: 0/2 grow/shrink: 0/2 up/down: 0/-376 (-376)
	Function                                     old     new   delta
	berlin_pwm_free                               44       -     -44
	berlin_pwm_suspend                           364     256    -108
	berlin_pwm_resume                            444     332    -112
	berlin_pwm_request                           112       -    -112
	Total: Before=3712, After=3336, chg -10.13%

   So code size (and probably also run time) is improved.

If "back then we considered per-channel data a good idea, so let's use
it" is really your best argument to keep the code as is, I ask you to
reconsider that.

I checked the other drivers that make use of pwm_set_chip_data, and some
of them have a really strange usage pattern. Will prepare patches for
these and let you judge if these are worthwile.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-11-08 13:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-04 13:25 [PATCH 1/4] pwm: berlin: use consistent naming for variables Uwe Kleine-König
2021-05-04 13:25 ` [PATCH 2/4] pwm: berlin: Put channel config into driver data Uwe Kleine-König
2021-06-30  6:18   ` Uwe Kleine-König
2021-09-09 14:16     ` Uwe Kleine-König
2021-11-08 11:04       ` Uwe Kleine-König
2021-11-08 12:09   ` Thierry Reding
2021-11-08 13:08     ` Uwe Kleine-König [this message]
2021-05-04 13:25 ` [PATCH 3/4] pwm: berlin: Implement .apply() callback Uwe Kleine-König
2021-05-04 13:25 ` [PATCH 4/4] pwm: berlin: Don't check the return code of pwmchip_remove() Uwe Kleine-König

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=20211108130843.zcug25uy4ubijdcu@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=jszhang@marvell.com \
    --cc=kernel@pengutronix.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tommyhebb@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.