> Date: Wed, 23 Nov 2022 01:42:13 -0500
> From: Brad Spencer <b...@anduin.eldar.org>
>
> Simon Burge <sim...@netbsd.org> writes:
>
> > + delay(35000);
> >
> > This will spin for 35 milliseconds (per sensor read if I read this
> > correctly). Can you please look at using kpause(9) for this delay?
> > See some other i2c drivers for examples of this.
>
> Probably possible, may be a couple of days before I can get to
> it.... (or not, depends on how holiday prep goes)...
>
> I have used some of the cv_timedwait stuff in the past and didn't know
> about kpause which seems to be suited to what I need to do. Almost all
> sensor chips require some sort of wait after a command is sent, but this
> one was particularly frustrating about it.
The issue here isn't the duration of the delay -- just the mechanism.
Sleeping for 35ms with kpause(9) is fine, but busy-waiting on the CPU
for 35ms with delay(9) is not (unless HZ is set to something absurdly
low like 10 instead of the usual 100, but I doubt that's an important
use-case to consider here).
In this case, you should use:
kpause("bmx280", /*intr*/false, MAX(1, mstohz(35)), NULL);
> This
> was, as one might say, a "surprising development" as the documentation
> really does not hint that this sort of thing goes on (or was even
> possible to do).
Can you put a link to the documentation in the source code, and cite
the sections where you get the complicated formulas like in
bmx280_compensate_P_int64?
