On Thu, Nov 26, 2020 at 08:25:48PM +1100, Jonathan Gray wrote:
> On Tue, Nov 24, 2020 at 07:20:46PM -0600, Scott Cheloha wrote:
> > Hi,
> >
> > Both kettenis@ and mpi@ have mentioned in private that my proposed
> > changes to tsleep_nsec(9) etc. would be nicer if we could just get rid
> > of tsleep(9) etc. entirely.
> >
> > This is difficult, but I'll try.
> >
> > Worst case, we thin out the remaining callers. There are not many
> > left.
> >
> > --
> >
> > So, an(4) is one such caller.
> >
> > In an_wait() we spin for (3 * hz) ticks waiting for CSR_WRITE_2 to
> > return the AN_EV_CMD flag. There is no code handling a case where
> > this fails to happen.
> >
> > What we do in practice is very nearly equivalent to spinning for 3
> > seconds waiting for CSR_WRITE_2 to return the AN_EV_CMD flag, so I
> > have converted it to use tsleep_nsec(9).
> >
> > This compiles on amd64 but I can't test it.
> >
> > Thoughts? ok?
>
> I don't see why the upper bound would have to be so precise.
>
> Why not just
>
> for (i = 0; i < 3000; i += 100) {
> if (CSR_READ_2(sc, AN_EVENT_STAT) & AN_EV_CMD)
> break;
> tsleep_nsec(sc, PWAIT, "anatch", MSEC_TO_NSEC(100));
> }
I was just trying to imitate the current behavior as closely as
possible.
If you're fine fudging it like that then I'm fine with it. Just
beware that that tsleep_nsec(9) can and will oversleep by up to 1/hz
seconds.
Did you intend to increase the poll interval from 10ms to 100ms or is
that a typo?
