All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Benjamin Bara <bbara93@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>
Cc: support.opensource@diasemi.com,
	DLG-Adam.Ward.opensource@dm.renesas.com,
	Martin Fuzzey <martin.fuzzey@flowbird.group>,
	linux-kernel@vger.kernel.org,
	Benjamin Bara <benjamin.bara@skidata.com>
Subject: Re: [PATCH RFC v4 13/13] regulator: bd718x7: let the core handle the monitors
Date: Mon, 3 Jul 2023 14:02:35 +0300	[thread overview]
Message-ID: <4467bc6d-d4e7-aaa2-daab-875eb0e4159b@gmail.com> (raw)
In-Reply-To: <20230419-dynamic-vmon-v4-13-4d3734e62ada@skidata.com>

On 6/20/23 23:03, Benjamin Bara wrote:
> From: Benjamin Bara <benjamin.bara@skidata.com>
> 
> The monitors of the bd718x7 must be disabled while the respective
> regulator is switching to a higher voltage. Use the new property
> '.mon_disable_reg_set_higher' to activate the handling in the core.
> 
> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>

This looks great to me. Eg,
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>

Just a thing crossed my mind if you want to go an extra mile... (Yeah, 
we usually do like to do a bit more work, right?)

I guess that enabling / disabling a monitor is in many cases a matter of 
setting/clearing a single bit in a monitoring register - or maybe in 
some cases setting a limit value to zero.

Do you think it might be worth to add a 'monitor_reg_enable_uv, 
monitor_reg_enable_ov, monitor_reg_enable_oc, monitor_reg_enable_temp' 
and 'monitor_mask_enable_uv, monitor_mask_enable_ov, 
monitor_mask_enable_oc, monitor_mask_enable_temp' in the regulator_desc 
+ provide helpers for the drivers which do not need any more complex stuff?

Just a thought. Again, thanks for working on this!

> ---
>   drivers/regulator/bd718x7-regulator.c | 136 +++-------------------------------
>   1 file changed, 10 insertions(+), 126 deletions(-)
> 
> diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/regulator/bd718x7-regulator.c
> index fbf609d219fc..251d098d088c 100644
> --- a/drivers/regulator/bd718x7-regulator.c
> +++ b/drivers/regulator/bd718x7-regulator.c
> @@ -128,128 +128,6 @@ static int bd71837_get_buck34_enable_hwctrl(struct regulator_dev *rdev)
>   	return !!(BD718XX_BUCK_RUN_ON & val);
>   }
>   
> -static void voltage_change_done(struct regulator_dev *rdev, unsigned int sel,
> -				unsigned int *mask)
> -{
> -	int ret;
> -
> -	if (*mask) {
> -		/*
> -		 * Let's allow scheduling as we use I2C anyways. We just need to
> -		 * guarantee minimum of 1ms sleep - it shouldn't matter if we
> -		 * exceed it due to the scheduling.
> -		 */
> -		msleep(1);
> -
> -		ret = regmap_clear_bits(rdev->regmap, BD718XX_REG_MVRFLTMASK2,
> -					 *mask);
> -		if (ret)
> -			dev_err(&rdev->dev,
> -				"Failed to re-enable voltage monitoring (%d)\n",
> -				ret);
> -	}
> -}
> -
> -static int voltage_change_prepare(struct regulator_dev *rdev, unsigned int sel,
> -				  unsigned int *mask)
> -{
> -	int ret;
> -
> -	*mask = 0;
> -	if (rdev->desc->ops->is_enabled(rdev)) {
> -		int now, new;
> -
> -		now = rdev->desc->ops->get_voltage_sel(rdev);
> -		if (now < 0)
> -			return now;
> -
> -		now = rdev->desc->ops->list_voltage(rdev, now);
> -		if (now < 0)
> -			return now;
> -
> -		new = rdev->desc->ops->list_voltage(rdev, sel);
> -		if (new < 0)
> -			return new;
> -
> -		/*
> -		 * If we increase LDO voltage when LDO is enabled we need to
> -		 * disable the power-good detection until voltage has reached
> -		 * the new level. According to HW colleagues the maximum time
> -		 * it takes is 1000us. I assume that on systems with light load
> -		 * this might be less - and we could probably use DT to give
> -		 * system specific delay value if performance matters.
> -		 *
> -		 * Well, knowing we use I2C here and can add scheduling delays
> -		 * I don't think it is worth the hassle and I just add fixed
> -		 * 1ms sleep here (and allow scheduling). If this turns out to
> -		 * be a problem we can change it to delay and make the delay
> -		 * time configurable.
> -		 */
> -		if (new > now) {
> -			int tmp;
> -			int prot_bit;
> -			int ldo_offset = rdev->desc->id - BD718XX_LDO1;
> -
> -			prot_bit = BD718XX_LDO1_VRMON80 << ldo_offset;
> -			ret = regmap_read(rdev->regmap, BD718XX_REG_MVRFLTMASK2,
> -					  &tmp);
> -			if (ret) {
> -				dev_err(&rdev->dev,
> -					"Failed to read voltage monitoring state\n");
> -				return ret;
> -			}
> -
> -			if (!(tmp & prot_bit)) {
> -				/* We disable protection if it was enabled... */
> -				ret = regmap_set_bits(rdev->regmap,
> -						      BD718XX_REG_MVRFLTMASK2,
> -						      prot_bit);
> -				/* ...and we also want to re-enable it */
> -				*mask = prot_bit;
> -			}
> -			if (ret) {
> -				dev_err(&rdev->dev,
> -					"Failed to stop voltage monitoring\n");
> -				return ret;
> -			}
> -		}
> -	}
> -
> -	return 0;
> -}
> -
> -static int bd718xx_set_voltage_sel_restricted(struct regulator_dev *rdev,
> -						    unsigned int sel)
> -{
> -	int ret;
> -	int mask;
> -
> -	ret = voltage_change_prepare(rdev, sel, &mask);
> -	if (ret)
> -		return ret;
> -
> -	ret = regulator_set_voltage_sel_regmap(rdev, sel);
> -	voltage_change_done(rdev, sel, &mask);
> -
> -	return ret;
> -}
> -
> -static int bd718xx_set_voltage_sel_pickable_restricted(
> -		struct regulator_dev *rdev, unsigned int sel)
> -{
> -	int ret;
> -	int mask;
> -
> -	ret = voltage_change_prepare(rdev, sel, &mask);
> -	if (ret)
> -		return ret;
> -
> -	ret = regulator_set_voltage_sel_pickable_regmap(rdev, sel);
> -	voltage_change_done(rdev, sel, &mask);
> -
> -	return ret;
> -}
> -
>   static int bd71837_set_voltage_sel_pickable_restricted(
>   		struct regulator_dev *rdev, unsigned int sel)
>   {
> @@ -610,7 +488,7 @@ static int bd718x7_set_buck_ovp(struct regulator_dev *rdev, int lim_uV,
>    */
>   BD718XX_OPS(bd718xx_pickable_range_ldo_ops,
>   	    regulator_list_voltage_pickable_linear_range, NULL,
> -	    bd718xx_set_voltage_sel_pickable_restricted,
> +	    regulator_set_voltage_sel_pickable_regmap,
>   	    regulator_get_voltage_sel_pickable_regmap, NULL, NULL,
>   	    bd718x7_set_ldo_uvp, NULL, bd717x7_get_ldo_prot);
>   
> @@ -618,7 +496,7 @@ BD718XX_OPS(bd718xx_pickable_range_ldo_ops,
>   static const struct regulator_ops bd718xx_ldo5_ops_hwstate = {
>   	.is_enabled = never_enabled_by_hwstate,
>   	.list_voltage = regulator_list_voltage_pickable_linear_range,
> -	.set_voltage_sel = bd718xx_set_voltage_sel_pickable_restricted,
> +	.set_voltage_sel = regulator_set_voltage_sel_pickable_regmap,
>   	.get_voltage_sel = regulator_get_voltage_sel_pickable_regmap,
>   	.set_under_voltage_protection = bd718x7_set_ldo_uvp,
>   };
> @@ -631,12 +509,12 @@ BD718XX_OPS(bd718xx_pickable_range_buck_ops,
>   	    bd718x7_set_buck_ovp, bd717x7_get_buck_prot);
>   
>   BD718XX_OPS(bd718xx_ldo_regulator_ops, regulator_list_voltage_linear_range,
> -	    NULL, bd718xx_set_voltage_sel_restricted,
> +	    NULL, regulator_set_voltage_sel_regmap,
>   	    regulator_get_voltage_sel_regmap, NULL, NULL, bd718x7_set_ldo_uvp,
>   	    NULL, bd717x7_get_ldo_prot);
>   
>   BD718XX_OPS(bd718xx_ldo_regulator_nolinear_ops, regulator_list_voltage_table,
> -	    NULL, bd718xx_set_voltage_sel_restricted,
> +	    NULL, regulator_set_voltage_sel_regmap,
>   	    regulator_get_voltage_sel_regmap, NULL, NULL, bd718x7_set_ldo_uvp,
>   	    NULL, bd717x7_get_ldo_prot);
>   
> @@ -1818,6 +1696,12 @@ static int bd718xx_probe(struct platform_device *pdev)
>   		else
>   			desc->ops = swops[i];
>   
> +		/*
> +		 * bd718x7 requires to disable a regulator's over voltage
> +		 * protection while it changes to a higher value.
> +		 */
> +		desc->mon_disable_reg_set_higher = REGULATOR_MONITOR_OVER_VOLTAGE;
> +
>   		rdev = devm_regulator_register(&pdev->dev, desc, &config);
>   		if (IS_ERR(rdev))
>   			return dev_err_probe(&pdev->dev, PTR_ERR(rdev),
> 

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~


      reply	other threads:[~2023-07-03 11:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 20:02 [PATCH RFC v4 00/13] regulator: dynamic voltage monitoring support Benjamin Bara
2023-06-20 20:02 ` [PATCH RFC v4 01/13] regulator: da9063: fix null pointer deref with partial DT config Benjamin Bara
2023-06-20 20:02 ` [PATCH RFC v4 02/13] regulator: add getter for active monitors Benjamin Bara
2023-06-26 13:43   ` Matti Vaittinen
2023-06-26 16:37     ` Mark Brown
2023-06-20 20:02 ` [PATCH RFC v4 03/13] regulator: da9063: implement get_active_protections() Benjamin Bara
2023-06-20 20:02 ` [PATCH RFC v4 04/13] regulator: bd718x7: " Benjamin Bara
2023-06-26 13:45   ` Matti Vaittinen
2023-06-20 20:02 ` [PATCH RFC v4 05/13] regulator: introduce properties for monitoring workarounds Benjamin Bara
2023-06-26 13:47   ` Matti Vaittinen
2023-06-20 20:02 ` [PATCH RFC v4 06/13] regulator: set required ops " Benjamin Bara
2023-06-26 13:49   ` Matti Vaittinen
2023-06-20 20:03 ` [PATCH RFC v4 07/13] regulator: find active protections during initialization Benjamin Bara
2023-06-26 13:56   ` Matti Vaittinen
2023-06-26 16:49     ` Mark Brown
2023-07-03 18:43       ` Benjamin Bara
2023-07-04 13:49         ` Mark Brown
2023-06-20 20:03 ` [PATCH RFC v4 08/13] regulator: move monitor handling into own function Benjamin Bara
2023-06-26 14:04   ` Matti Vaittinen
2023-06-20 20:03 ` [PATCH RFC v4 09/13] regulator: implement mon_disable_reg_disabled Benjamin Bara
2023-07-03 10:31   ` Matti Vaittinen
2023-07-03 18:50     ` Benjamin Bara
2023-06-20 20:03 ` [PATCH RFC v4 10/13] regulator: implement mon_disable_reg_set_{higher,lower} Benjamin Bara
2023-07-03 10:45   ` Matti Vaittinen
2023-06-20 20:03 ` [PATCH RFC v4 11/13] regulator: implement mon_unsupported_reg_modes Benjamin Bara
2023-07-03 10:49   ` Matti Vaittinen
2023-06-20 20:03 ` [PATCH RFC v4 12/13] regulator: da9063: let the core handle the monitors Benjamin Bara
2023-06-20 20:03 ` [PATCH RFC v4 13/13] regulator: bd718x7: " Benjamin Bara
2023-07-03 11:02   ` Matti Vaittinen [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=4467bc6d-d4e7-aaa2-daab-875eb0e4159b@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=DLG-Adam.Ward.opensource@dm.renesas.com \
    --cc=bbara93@gmail.com \
    --cc=benjamin.bara@skidata.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.fuzzey@flowbird.group \
    --cc=support.opensource@diasemi.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.