On Mon, Oct 8, 2018 at 5:46 PM Arnd Bergmann <a...@arndb.de> wrote:
>
> On Sun, Oct 7, 2018 at 5:00 PM <sunil.kovv...@gmail.com> wrote:
> >
> > From: Sunil Goutham <sgout...@marvell.com>
> >
> > Go through all BLKADDRs and check which ones are implemented
> > on this silicon and do a HW reset of each implemented block.
> > Also added all RVU AF and PF register offsets.
> >
>
> >
> > +/* Poll a RVU block's register 'offset', for a 'zero'
> > + * or 'nonzero' at bits specified by 'mask'
> > + */
> > +int rvu_poll_reg(struct rvu *rvu, u64 block, u64 offset, u64 mask, bool
> > zero)
> > +{
> > + void __iomem *reg;
> > + int timeout = 100;
> > + u64 reg_val;
> > +
> > + reg = rvu->afreg_base + ((block << 28) | offset);
> > + while (timeout) {
> > + reg_val = readq(reg);
> > + if (zero && !(reg_val & mask))
> > + return 0;
> > + if (!zero && (reg_val & mask))
> > + return 0;
> > + udelay(1);
> > + cpu_relax();
> > + timeout--;
> > + }
> > + return -EBUSY;
> > +}
>
> This can be a fairly long wait of multiple milliseconds, given that
> you call it nine times in a row, that each udelay() can take
> multiple microseconds (plus the time for the readq()), and
> you look 100 times.
>
> It seems this is only called from probe(), which is not in atomic
> context, and you don't hold any locks, so why not change the
> udelay() to an msleep() or usleep_range() to let some other
> process run?
>
> Arnd
Sure, usleep_range seems to be a better option, will change.
Thanks,
Sunil.
