gpmc_calc_wa...ring_divider(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… gpmc_calc_waitmonitoring_divider(9) β€” yes bestie, that's the Kernel API Manual πŸŽ€

okay so first thing: the header up top lowkey truncates the name (gpmc_calc_wa...ring_divider(9)) but the full name is gpmc_calc_waitmonitoring_divider, and this whole page lives in the Kernel API Manual. she's a kernel function, she's from ./drivers/memory, and she's about to explain dividers to you. strap in πŸ¦‹


✨ NAME ✨

gpmc_calc_waitmonitoring_divider β€” calculate the proper GPMCFCLKDIVIDER based on WAITMONITORINGTIME πŸ’–

and the vibe check on WAITMONITORINGTIME? it will be _at least_ as long as desired, i.e.:

  • read β†’ don't sample the bus too early πŸ™ˆ
  • write β†’ the data is longer on the bus ✍️

that's it, that's the whole energy. no cap.


🌸 SYNOPSIS 🌸

int gpmc_calc_waitmonitoring_divider (unsigned int wait_monitoring );

literally one argument, one int back. she's lowkey low maintenance πŸ’…


πŸŽ€ ARGUMENTS πŸŽ€

  • wait_monitoring β€” the WAITMONITORINGTIME, measured in ns ⏱️ (nanoseconds, bestie, not vibes)

🧚 DESCRIPTION 🧚

okay so here's the formula, and yes it's nested ceils, don't panic, we got this:

gpmc_clk_div + 1 = ceil(ceil(waitmonitoringtime_ns / gpmc_fclk_ns) / waitmonitoring_ticks)

that's the whole calculation, character for character, no notes πŸ‘‘

and the edge case? if WAITMONITORINGTIME ends up resulting in 0 or 1 tick with div = 1, those get caught by the div <= 0 check. so nobody's out here dividing by zero on my watch, periodt πŸ’€


πŸ”₯ RETURN πŸ”₯

  • -1 on failure to scale 😭 (it tried, it really did)
  • else the proper divider, > 0 ✨ slay

πŸ¦‹ SEE ALSO πŸ¦‹

kernel file ./drivers/memory/omap-gpmc.c β€” the whole friend group lives here:

go read them, iykyk 🌈


okay that's the page!! this lil diva ships from ./drivers/memory, dated October 2026, in the Kernel API Manual (the (9) girlies 🫢). mwah, go calculate some dividers responsibly πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from