On Tue, 2010-12-21 at 13:20 +0100, RafaÅ MiÅecki wrote:
> W dniu 21 grudnia 2010 12:34 uÅytkownik Michael BÃsch <mb@xxxxxxxxx> napisaÅ:
> > On Tue, 2010-12-21 at 11:50 +0100, RafaÅ MiÅecki wrote:
> >> +static void b43_radio_init2056_post(struct b43_wldev *dev)
> >> +{
> >> + b43_radio_set(dev, B2056_SYN_COM_CTRL, 0xB);
> >> + b43_radio_set(dev, B2056_SYN_COM_PU, 0x2);
> >> + b43_radio_set(dev, B2056_SYN_COM_RESET, 0x2);
> >> + mdelay(1);
> >
> > Please don't use mdelay() ever. The driver is fully preemptible.
> > Use msleep() instead.
>
> So, using "msleep" allows kernel to switch context, while using
> "mdelay" does not?
Yeah well. msleep() does switch context (at least to the idle task,
if there's nothing else to do). Whereas mdelay() busy-waits in a tight
loop. So on a non-preemptible kernel you will lock up the CPU (and if
there's only one CPU, the whole system) for a millisecond by using
mdelay(). On a preemptible kernel it's somewhat mitigated, but I think
explicit sleep is still better there. Also for advanced speedstep and
powersaving considerations.
In the past we did significant efforts to make the whole driver (Except
the very tiny hardirq handler) preemptible. This improved things a
lot. In the old days, bringing the interface up came along with
about one-second system lockup (on UP, nonpreempt) and the periodic work
frequently caused things like audio to break. Today that's not an issue
anymore due to removal of huge mdelay() calls and preemptible locking.
Always remember that a millisecond really is a _huge_ amount of time
on a modern CPU.
> If so, should be convert our longer udelay calls (like 300us) to usleep?
Well, in my opinion, yes. I'm pretty sure opinions on that will diverge
from developer to developer, but I think at least in stuff like
periodically happening tasks we should avoid those delays and
use msleep(1) instead.
--
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
