[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1357253791.2685.48.camel@bwh-desktop.uk.solarflarecom.com>
Date: Thu, 3 Jan 2013 22:56:31 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Barry Grussling <barry@...ssling.com>
CC: <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/4] DSA: Convert msleep calls to usleep_range calls
On Thu, 2013-01-03 at 14:33 -0800, Barry Grussling wrote:
> On Thu, Jan 3, 2013 at 12:14 PM, Ben Hutchings
> <bhutchings@...arflare.com> wrote:
> > I seriously doubt that it is worth the trouble to save wake-ups during
> > the occasional hardware reset. And using usleep_range() 1000 times is
> > weird. If the sleep duration can vary then the right thing to do is
> > probably to calculate a deadline first (jiffies + HZ) and then sleep
> > repeatedly until the deadline is in the past. This also accounts for
> > the fact that HZ may be < 1000...
>
> I don't think the idea here is variable sleep time. Its more just
> giving hardware a little
> bit of time to catch up with firmware. I don't really care about
> variable sleep times,
> but checkpatch.pl says msleep of less than 20 ms is bad and may result in sleep
> times of up to 20 ms for requests of shorter durations.
Still true for usleep_range() on hardware that doesn't have an hrtimer.
> Should I use udelay instead? What is the recommended method for sleeping 1 ms?
This driver doesn't want to wait 1 ms, it wants to wait for up to 1
second and poll periodically. Think about the whole loop, not just that
one function call.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists