W dniu 21 grudnia 2010 23:25 uÅytkownik Michael BÃsch <mb@xxxxxxxxx> napisaÅ:
> 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.
Thank you.
--
RafaÅ
--
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
