linux-kernel.vger.kernel.org archive mirror
 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 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).