Re: CVS commit: src/sys/dev/i2c

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

> Date: Wed, 23 Nov 2022 01:42:13 -0500
> From: Brad Spencer <brad%anduin.eldar.org@localhost>
> 
> Simon Burge <simonb%NetBSD.org@localhost> 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?