On Fri, Dec 04, 2020 at 12:08:39PM -0600, Scott Cheloha wrote:
> On Fri, Dec 04, 2020 at 10:07:07AM +0100, Claudio Jeker wrote:
> > On Thu, Dec 03, 2020 at 10:42:50PM -0600, Scott Cheloha wrote:
> > > Hi,
> > >
> > > mbg(4) is among the few remaining drivers using tsleep(9).
> > >
> > > In a few
On Fri, Dec 04, 2020 at 10:07:07AM +0100, Claudio Jeker wrote:
> On Thu, Dec 03, 2020 at 10:42:50PM -0600, Scott Cheloha wrote:
> > Hi,
> >
> > mbg(4) is among the few remaining drivers using tsleep(9).
> >
> > In a few spots, when the kernel is not cold, the driver will spin for
> > up to 1/10
On Thu, Dec 03, 2020 at 10:42:50PM -0600, Scott Cheloha wrote:
> Hi,
>
> mbg(4) is among the few remaining drivers using tsleep(9).
>
> In a few spots, when the kernel is not cold, the driver will spin for
> up to 1/10 seconds waiting for the MBG_BUSY flag to go low.
>
> We can approximate this
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
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
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,
On Mon, Apr 06, 2020 at 02:03:36PM -0500, Scott Cheloha wrote:
> Ticks to seconds. Trivial.
>
> ok?
ok stsp@
> Index: if_wi.c
> ===
> RCS file: /cvs/src/sys/dev/ic/if_wi.c,v
> retrieving revision 1.171
> diff -u -p -r1.171 if_wi.c
On Fri, Jan 10, 2020 at 06:54:26PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> ok?
Bump and rebase.
1/2 seconds, so, 500 milliseconds.
ok?
Index: dwiic.c
===
RCS file: /cvs/src/sys/dev/ic/dwiic.c,v
retrieving
On Mon, Feb 17, 2020 at 07:40:40PM -0500, Kenneth R Westerback wrote:
> On Mon, Feb 17, 2020 at 06:23:01PM -0600, Scott Cheloha wrote:
> > On Sat, Jan 11, 2020 at 02:57:14AM -0600, Scott Cheloha wrote:
> > > The sleep duration is in milliseconds. We can rip out the timeval and
> > > tvtohz(9) and
On Sat, Jan 11, 2020 at 02:57:14AM -0600, Scott Cheloha wrote:
> The sleep duration is in milliseconds. We can rip out the timeval and
> tvtohz(9) and use MSEC_TO_NSEC() directly instead. I've added a local
> "msecs" variable because "timo" (a) feels a bit ambiguous and (b) is
> used with
On Fri, Jan 10, 2020 at 05:55:14PM -0600, Scott Cheloha wrote:
> Here the timeout constants are all in terms of seconds. We can change
> the input unit of the wait functions from hz to seconds and then
> convert as needed.
>
> sdhc_wait_intr_cold() uses delay(9), so convert to microseconds.
>
>
Scott Cheloha writes:
> Given the SCSI_NOSLEEP split here I think the simplest thing we can do
> is ask to sleep as much as we delay(9).
>
> The question is: if you *could* poll in 10us intervals here with
> tsleep_nsec(9), would you want to? If so, then this works. If
> not, what is a more
On Mon, Jan 13, 2020 at 06:32:00PM -0600, Scott Cheloha wrote:
> These sleeps don't have units, though in practice they are 1 second.
> Just prior in the code I see a delay(9) of 100 microseconds. Is the
> 100 ticks here a typo? What is a reasonable sleep duration for this
> hardware?
Both of
On Tue, Jan 07, 2020 at 08:03:27AM -, Miod Vallat wrote:
>
> > Convert ticks to milliseconds.
> >
> > The 33 milliseconds in the timeout_add_msec(9) call will be truncated
> > to 3 ticks, but that was already the case with the current (hz / 30)
> > code so this is no worse.
>
> [...]
>
> >
> Convert ticks to milliseconds.
>
> The 33 milliseconds in the timeout_add_msec(9) call will be truncated
> to 3 ticks, but that was already the case with the current (hz / 30)
> code so this is no worse.
[...]
> /* allow 1/30 second for heads to settle */
> -
On Sun, Dec 15, 2019 at 10:28:32PM -0600, Scott Cheloha wrote:
> I don't have any of these cards, but these are straightforward conversions.
>
> ok?
>
ok
16 matches
Mail list logo
