pwm_set_wave..._might_sleep(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… pwm_set_waveform_might_sleep β€” from the Kernel API Manual (that's the pwm_set_wave..._might_sleep(9) page, bestie) ✨

πŸŽ€ NAME πŸŽ€

pwm_set_waveform_might_sleep β€” apply a new waveform. Cannot be used in atomic context, no cap.

πŸ¦‹ SYNOPSIS πŸ¦‹

int pwm_set_waveform_might_sleep (struct pwm_device *pwm , const struct
     pwm_waveform *wf , bool exact );

🌸 ARGUMENTS 🌸

  • pwm β€” your PWM device, the main character here πŸ’–
  • wf β€” the waveform to apply
  • exact β€” if true, no rounding is allowed. Like, zero. none. periodt.

✨ DESCRIPTION ✨

okay so here's the tea: typically a requested waveform cannot be implemented exactly. why? because hardware is a diva 😭 for example, say you asked for .period_length_ns = 100 ns, but the hardware can only set periods that are a multiple of 8.5 ns. with that hardware, passing exact = true results in pwm_set_waveform_might_sleep failing and returning -EDOM.

if exact = false you get a period of 93.5 ns β€” that's the biggest period not bigger than the requested value, slay 🌈

⚠️ heads up bestie: even with exact = true, some rounding by less than 1 ns is possible/needed. like, it's giving "close enough" energy. in the above example, requesting .period_length_ns = 94 and exact = true, you get the hardware configured with period = 93.5 ns.

Let C be the set of possible hardware configurations for a given PWM device, consisting of tuples (p, d, o) where p is the period length, d is the duty length and o the duty offset.

The following algorithm is implemented to pick the hardware setting (p, d, o) ∈ C for a given request (p', d', o') with exact = false:

p = max( { αΉ— | βˆƒ αΈ‹, Θ― : (αΉ—, αΈ‹, Θ―) ∈ C ∧ αΉ— ≀ p' } βˆͺ { min({ αΉ— | βˆƒ αΈ‹, Θ― : (αΉ—, αΈ‹, Θ―) ∈ C }) })
d = max( { αΈ‹ | βˆƒ Θ― : (p, αΈ‹, Θ―) ∈ C ∧ αΈ‹ ≀ d' } βˆͺ { min({ αΈ‹ | βˆƒ Θ― : (p, αΈ‹, Θ―) ∈ C }) })
o = max( { Θ― | (p, d, Θ―) ∈ C ∧ Θ― ≀ o' } βˆͺ { min({ Θ― | (p, d, Θ―) ∈ C }) })

in words (for the girlies who don't speak math) πŸ’€βž‘οΈπŸ’–

The chosen period length is the maximal possible period length not bigger than the requested period length, and if that doesn't exist, the minimal period length. the chosen duty length is the maximal possible duty length that is compatible with the chosen period length and isn't bigger than the requested duty length. again, if such a value doesn't exist, the minimal duty length compatible with the chosen period is picked. after that the duty offset compatible with the chosen period and duty length is chosen in the same way. iconic, honestly πŸ‘‘

πŸ”₯ RETURN πŸ”₯

  • 0 on success 🫢
  • -EDOM if setting failed due to the exact waveform not being possible (if exact)
  • or a different negative errno on failure 😭

⭐ CONTEXT ⭐

May sleep. literally it's allowed to nap 😴 (so, again: not atomic context, ok?)

πŸ’… SEE ALSO πŸ’…

Kernel file ./drivers/pwm/core.c, plus the whole friend group:

pwm_round_waveform_might_sleep(9), pwm_get_waveform_might_sleep(9), pwm_apply_might_sleep(9), pwm_apply_atomic(9), pwm_get_state_hw(9), pwm_adjust_config(9), pwm_capture(9), pwm_request_from_chip(9), of_pwm_get(9), acpi_pwm_get(9), pwm_get(9), pwm_put(9), devm_pwm_get(9), devm_fwnode_pwm_get(9), __pwmchip_add(9), pwmchip_remove(9), pwm_add_table(9), pwm_remove_table(9)

that's the whole page, bestie 🧚 this one lives in ./drivers/pwm, dated October 2026 β€” mwah, go configure some waveforms responsibly πŸ’œ

πŸ“¦ where this page comes from