wrpll_calc_max_lock_us(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… NAME πŸ’…

okay so this is a Kernel API Manual page (yes, the kernel has lore too, and yes it's iconic) all about wrpll_calc_max_lock_us β€” it literally returns the time for the PLL to lock. that's the whole vibe. πŸŽ€


✨ SYNOPSIS ✨

unsigned int wrpll_calc_max_lock_us (const struct wrpll_cfg *c );

that's it bestie, one little function, one little pointer, no drama 🌸


🫢 ARGUMENTS 🫢

  • c β€” ptr to a struct wrpll_cfg record to read from. it's just reading, she's not gonna touch anything, promise πŸ™ˆ

πŸ¦‹ DESCRIPTION πŸ¦‹

so here's the tea: this returns the minimum amount of time (in microseconds) that the caller must wait after reprogramming the PLL to make sure it's actually locked to the input frequency and stable. like, you gotta give her a sec to settle, y'know? 😭

and this wait time is likely to depend on the DIVR value β€” but that part is still under discussion with the manufacturer, so ngl it's giving "we'll circle back on that one". lowkey unfinished business πŸ”₯

main character energy: don't just slam the PLL and immediately trust her, that's not how any of this works πŸ’€

⭐ RETURN ⭐

the minimum amount of time the caller must wait for the PLL to lock (in microseconds). periodt. πŸ’…


🧚 SEE ALSO 🧚

all the siblings, one big happy clock family πŸŒˆπŸ‘‘


and that's the page fr fr β€” brought to you by <pink>./drivers/clk/analogbits</pink>, dated October 2026, and filed under wrpll_calc_max_lock_us(9). go lock some PLLs, bestie, and drink water πŸ’–πŸ“

πŸ“¦ where this page comes from