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 --]
next prev parent 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 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 read-only IMAP folder(s) and NNTP newsgroup(s).