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 <[email protected]>
> > ---
> > 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
