Messages in this thread Patch in this message | | | Date | Wed, 8 Feb 2017 11:18:38 +0000 | From | Charles Keepax <> | Subject | Re: [PATCH RESEND 3/4] mfd: arizona: Update arizona_poll_reg to take a timeout in milliseconds |
| |
On Wed, Feb 08, 2017 at 10:04:58AM +0000, Lee Jones wrote: > On Tue, 31 Jan 2017, Charles Keepax wrote: > > > Currently, we specify the timeout in terms of the number of polls but it > > is more clear from a user of the functions perspective to specify the > > timeout directly in milliseconds, as such update the function to these new > > semantics. > > > > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> > > --- > > drivers/mfd/arizona-core.c | 17 +++++++++++------ > > 1 file changed, 11 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c > > index 4cb34c3..ae4cdc4 100644 > > --- a/drivers/mfd/arizona-core.c > > +++ b/drivers/mfd/arizona-core.c > > @@ -235,14 +235,18 @@ static irqreturn_t arizona_overclocked(int irq, void *data) > > return IRQ_HANDLED; > > } > > > > +#define ARIZONA_REG_POLL_DELAY_MS 5 > > + > > static int arizona_poll_reg(struct arizona *arizona, > > - int timeout, unsigned int reg, > > + int timeout_ms, unsigned int reg, > > unsigned int mask, unsigned int target) > > { > > + unsigned int npolls = (timeout_ms + ARIZONA_REG_POLL_DELAY_MS - 1) / > > + ARIZONA_REG_POLL_DELAY_MS; > > Why the over-complication? > > Shouldn't this just be "timeout_ms / ARIZONA_REG_POLL_DELAY_MS"?
This will often give you less than the requested timeout if the requested timeout is not an exact multiple of ARIZONA_REG_POLL_DELAY_MS. We should never give less timeout than requested although more is always going to be fine.
> > > unsigned int val = 0; > > int ret, i; > > > > - for (i = 0; i < timeout; i++) { > > + for (i = 0; i < npolls; i++) { > > ret = regmap_read(arizona->regmap, reg, &val); > > if (ret != 0) { > > dev_err(arizona->dev, "Failed to read reg 0x%x: %d\n", > > @@ -253,7 +257,8 @@ static int arizona_poll_reg(struct arizona *arizona, > > if ((val & mask) == target) > > return 0; > > > > - usleep_range(1000, 5000); > > + usleep_range((ARIZONA_REG_POLL_DELAY_MS * 1000) / 2, > > + ARIZONA_REG_POLL_DELAY_MS * 1000); > > I'm sure there is a macro for conversion from ms to us. >
I will have a look see if I can find it.
> By using such a wide range, you are now not honouring the timeout set > by the caller by as much as 50%. >
Yes apologies my fault here, we really should be applying the adjustment to the maximum not the minimum here. I don't see a problem with the wide range, getting more timeout than we asked for is never going to be a problem but less is. I will respin.
Thanks, Charles
| |