lkml.org 
[lkml]   [2020]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: [v2 3/4] regulator: qcom: Add labibb driver
Hello Mark,

On Thu, 14 May 2020 at 16:57, Sumit Semwal <sumit.semwal@linaro.org> wrote:
>
> Hello Mark,
>
> Thank you for your review comments!
> On Mon, 11 May 2020 at 16:09, Mark Brown <broonie@kernel.org> wrote:
> >
> > On Sat, May 09, 2020 at 02:11:59AM +0530, Sumit Semwal wrote:
> >
> > > + ret = regmap_bulk_read(reg->regmap, reg->base +
> > > + REG_LABIBB_STATUS1, &val, 1);
> > > + if (ret < 0) {
> > > + dev_err(reg->dev, "Read register failed ret = %d\n", ret);
> > > + return ret;
> > > + }
> >
> > Why a bulk read of a single register?
> Right, will change.
> >
> > > +static int _check_enabled_with_retries(struct regulator_dev *rdev,
> > > + int retries, int enabled)
> > > +{
> >
> > This is not retrying, this is polling to see if the regulator actually
> > enabled.
> Yes, will update accordingly.
>
> >
> > > +static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
> > > +{
> >
> > > + ret = _check_enabled_with_retries(rdev, retries, 1);
> > > + if (ret < 0) {
> > > + dev_err(reg->dev, "retries exhausted: enable %s regulator\n",
> > > + reg->desc.name);
> > > + return ret;
> > > + }
> >
> > If this is useful factor it out into a helper or the core, other devices
> > also have status bits saying if the regulator is enabled. It looks like
> > this may be mainly trying to open code something like enable_time, with
> > possibly some issues where the time taken to enable varies a lot.
> >
> Makes sense; I am not terribly familiar with the regulator core and
> helpers, so let me look and refactor accordingly.
Does something like this make sense, or did I misunderstand your
suggestion completely? I'll send the updated patches accordingly.

--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2353,6 +2353,7 @@ static int _regulator_do_enable(struct
regulator_dev *rdev)
+ /* If max_time_poll_enabled is set for the regulator,
+ * Poll upto max_time_poll_enabled time to see if the regulator
+ * actually got enabled.
+ * For each iteration, wait for the enable_time delay calculated
+ * above already.
+ * If the regulator isn't enabled after max_time_poll_enabled has
+ * expired, return -REG_ENABLED_CHECK_FAILED.
+ */
+ if (rdev->desc->max_time_poll_enabled) {
+ unsigned int remaining_time_to_poll =
rdev->desc->max_time_poll_enabled;
+
+ while (remaining_time_to_poll > 0) {
+ /* We've already waited for enable_time above;
+ * so we can start with immediate check of the
+ * status of the regulator.
+ */
+ if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ _regulator_enable_delay(delay);
+ remaining_time_to_poll -= delay;
+ }
+
+ if (remaining_time_to_poll <= 0) {
+ rdev_err(rdev, "Enabled check failed.\n");
+ return -REG_ENABLED_CHECK_FAILED;
+ }
+ }
+

Since atleast in my use case, the delay is really enable_time (time
before we could check the status register), we could reuse the
already-calculated 'delay' based on enable_time?
>
<snip>

Best,
Sumit.

\
 
 \ /
  Last update: 2020-05-27 18:32    [W:0.067 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site