All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Jean Delvare <jdelvare@suse.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Thierry Reding <thierry.reding@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	linux-hwmon@vger.kernel.org, linux-pwm@vger.kernel.org,
	Markus Niebel <Markus.Niebel@ew.tq-group.com>
Subject: Re: [PATCH v4 6/6] hwmon: pwm-fan: Remove internal duplicated pwm_state
Date: Tue, 21 Jun 2022 09:22:44 +0200	[thread overview]
Message-ID: <20220621072244.72j6n2inwut36wsx@pengutronix.de> (raw)
In-Reply-To: <13043200.uLZWGnKmhe@steina-w>

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

Hello Alexander,

On Tue, Jun 21, 2022 at 08:41:37AM +0200, Alexander Stein wrote:
> Am Montag, 23. Mai 2022, 16:18:57 CEST schrieb Guenter Roeck:
> > On 5/23/22 06:55, Alexander Stein wrote:
> > > Hi Uwe,
> > > 
> > > Am Montag, 23. Mai 2022, 14:46:14 CEST schrieb Uwe Kleine-König:
> > >> * PGP Signed by an unknown key
> > >> 
> > >> Hello,
> > >> 
> > >> On Mon, May 23, 2022 at 01:05:13PM +0200, Alexander Stein wrote:
> > >>> Each pwm device has already a pwm_state. Use this one instead of
> > >>> managing an own copy of it.
> > >>> 
> > >>> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > >>> ---
> > >>> 
> > >>>   drivers/hwmon/pwm-fan.c | 49 +++++++++++++++++++++++++----------------
> > >>>   1 file changed, 30 insertions(+), 19 deletions(-)
> > >>> 
> > >>> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > >>> index e5d4b3b1cc49..e0ce81cdf5e0 100644
> > >>> --- a/drivers/hwmon/pwm-fan.c
> > >>> +++ b/drivers/hwmon/pwm-fan.c
> > >>> @@ -40,7 +40,6 @@ struct pwm_fan_ctx {
> > >>> 
> > >>>   	struct mutex lock;
> > >>>   	struct pwm_device *pwm;
> > >>> 
> > >>> -	struct pwm_state pwm_state;
> > >>> 
> > >>>   	struct regulator *reg_en;
> > >>>   	enum pwm_fan_enable_mode enable_mode;
> > >>>   	bool regulator_enabled;
> > >>> 
> > >>> @@ -142,7 +141,7 @@ static int pwm_fan_switch_power(struct pwm_fan_ctx
> > >>> *ctx, bool on)>
> > >>> 
> > >>>   static int pwm_fan_power_on(struct pwm_fan_ctx *ctx)
> > >>>   {
> > >>> 
> > >>> -	struct pwm_state *state = &ctx->pwm_state;
> > >>> +	struct pwm_state state;
> > >>> 
> > >>>   	int ret;
> > >>>   	
> > >>>   	if (ctx->enabled)
> > >>> 
> > >>> @@ -154,8 +153,9 @@ static int pwm_fan_power_on(struct pwm_fan_ctx *ctx)
> > >>> 
> > >>>   		return ret;
> > >>>   	
> > >>>   	}
> > >>> 
> > >>> -	state->enabled = true;
> > >>> -	ret = pwm_apply_state(ctx->pwm, state);
> > >>> +	pwm_get_state(ctx->pwm, &state);
> > >>> +	state.enabled = true;
> > >>> +	ret = pwm_apply_state(ctx->pwm, &state);
> > >>> 
> > >>>   	if (ret) {
> > >>>   	
> > >>>   		dev_err(ctx->dev, "failed to enable PWM\n");
> > >>>   		goto disable_regulator;
> > >> 
> > >> IMHO this isn't a net win. You trade the overhead of pwm_get_state
> > >> against some memory savings. I personally am not a big fan of the
> > >> get_state + modify + apply codeflow. The PWM framework does internal
> > >> caching of the last applied state, but the details are a bit ugly. (i.e.
> > >> pwm_get_state returns the last applied state, unless there was no state
> > >> applied before. In that case it returns what .get_state returned during
> > >> request time, unless there is no .get_state callback ... not sure if the
> > >> device tree stuff somehow goes into that, didn't find it on a quick
> > >> glance)
> > >> 
> > >> Also there is a (small) danger, that pwm_state contains something that
> > >> isn't intended by the driver, e.g. a wrong polarity. So I like the
> > >> consumer to fully specify what they intend and not use pwm_get_state().
> > > 
> > > Ah, I see. I have no hard feelings for this patch. I just wondered why the
> > > PWM state is duplicated. and wanted to get rid of it. If there is a
> > > specific reason for this, I'm ok with that.
> > 
> > I don't see the value of continuous runtime overhead to save a few bytes of
> > data, so I don't see a reason to _not_ cache the state locally. This is
> > similar to caching a clock frequency locally instead of calling the clock
> > subsystem again and again to read it. Sure, nowadays CPUs are more powerful
> > than they used to be, but I don't see that as reason or argument for
> > wasting their power.
> 
> Ok, seems reasonable. I'm fully fine with patch 6 being dropped. What about 
> the other patches?

+1 for dropping patch #6. Otherwise (with my PWM expert hat on) I have
no further criticism. But I didn't look deep enough into the patches for
an Ack, I guess I'm also missing some hwmon foo to objectively review
further.

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:[~2022-06-21  7:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 11:05 [PATCH v4 0/6] hwmon: pwm-fan: switch regulator dynamically Alexander Stein
2022-05-23 11:05 ` [PATCH v4 1/6] hwmon: pwm-fan: Refactor fan power on/off Alexander Stein
2022-08-30 13:45   ` Guenter Roeck
2022-05-23 11:05 ` [PATCH v4 2/6] hwmon: pwm-fan: Simplify enable/disable check Alexander Stein
2022-08-30 13:43   ` Guenter Roeck
2022-09-14 15:06     ` Alexander Stein
2022-05-23 11:05 ` [PATCH v4 3/6] hwmon: pwm-fan: Add dedicated power switch function Alexander Stein
2022-08-30 13:50   ` Guenter Roeck
2022-09-14 15:10     ` Alexander Stein
2022-05-23 11:05 ` [PATCH v4 4/6] hwmon: pwm-fan: split __set_pwm into locked/unlocked functions Alexander Stein
2022-08-30 13:52   ` Guenter Roeck
2022-05-23 11:05 ` [PATCH v4 5/6] hwmon: pwm-fan: Switch regulator dynamically Alexander Stein
2022-08-30 14:01   ` Guenter Roeck
2022-05-23 11:05 ` [PATCH v4 6/6] hwmon: pwm-fan: Remove internal duplicated pwm_state Alexander Stein
2022-05-23 12:46   ` Uwe Kleine-König
2022-05-23 13:55     ` Alexander Stein
2022-05-23 14:18       ` Guenter Roeck
2022-06-21  6:41         ` Alexander Stein
2022-06-21  7:22           ` Uwe Kleine-König [this message]

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=20220621072244.72j6n2inwut36wsx@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=Markus.Niebel@ew.tq-group.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=corbet@lwn.net \
    --cc=jdelvare@suse.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=thierry.reding@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.