<commit_before>delays - Information on the various kernel delay / sleep mechanisms
-------------------------------------------------------------------

This document seeks to answer the common question: "What is the
RightWay (TM) to insert a delay?"

This question is most often faced by driver writers who have to
deal with hardware delays and who may not be the most intimately
familiar with the inner workings of the Linux Kernel.


Inserting Delays
----------------

The first, and most important, question you need to ask is "Is my
code in an atomic context?"  This should be followed closely by "Does
it really need to delay in atomic context?" If so...

ATOMIC CONTEXT:
	You must use the *delay family of functions. These
	functions use the jiffie estimation of clock speed
	and will busy wait for enough loop cycles to achieve
	the desired delay:

	ndelay(unsigned long nsecs)
	udelay(unsigned long usecs)
	mdelay(unsgined long msecs)

	udelay is the generally preferred API; ndelay-level
	precision may not actually exist on many non-PC devices.

	mdelay is macro wrapper around udelay, to account for
	possible overflow when passing large arguments to udelay.
	In general, use of mdelay is discouraged and code should
	be refactored to allow for the use of msleep.

NON-ATOMIC CONTEXT:
	You should use the *sleep[_range] family of functions.
	There are a few more options here, while any of them may
	work correctly, using the "right" sleep function will
	help the scheduler, power management, and just make your
	driver better :)<commit_msg>doc: timers-howto: fix a typo ("unsgined")<commit_after>delays - Information on the various kernel delay / sleep mechanisms
-------------------------------------------------------------------

This document seeks to answer the common question: "What is the
RightWay (TM) to insert a delay?"

This question is most often faced by driver writers who have to
deal with hardware delays and who may not be the most intimately
familiar with the inner workings of the Linux Kernel.


Inserting Delays
----------------

The first, and most important, question you need to ask is "Is my
code in an atomic context?"  This should be followed closely by "Does
it really need to delay in atomic context?" If so...

ATOMIC CONTEXT:
	You must use the *delay family of functions. These
	functions use the jiffie estimation of clock speed
	and will busy wait for enough loop cycles to achieve
	the desired delay:

	ndelay(unsigned long nsecs)
	udelay(unsigned long usecs)
	mdelay(unsigned long msecs)

	udelay is the generally preferred API; ndelay-level
	precision may not actually exist on many non-PC devices.

	mdelay is macro wrapper around udelay, to account for
	possible overflow when passing large arguments to udelay.
	In general, use of mdelay is discouraged and code should
	be refactored to allow for the use of msleep.

NON-ATOMIC CONTEXT:
	You should use the *sleep[_range] family of functions.
	There are a few more options here, while any of them may
	work correctly, using the "right" sleep function will
	help the scheduler, power management, and just make your
	driver better :)
{'fraction_non_alphanumeric': 0.09032875837855091, 'fraction_numerical': 0.0, 'mean_word_length': 3.3108665749656123, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7572530', 'n_tokens_mistral': 815, 'n_tokens_neox': 798, 'n_words': 465}