I'd recommend centralizing the function epilogue. Otherwise, if a future refactor changes which registers need to be saved and one of the return sites is missed that could lead to nasty errors.
If you are worried about register pressure, rather than having 2 bool arguments like this you could have a single u32 argument holding a bitwise OR of flags.
Since this function lives in graphics_32, I'd expect that to imply 32 bits per pixel. If the same function is intended to be used for both modes, it should live in a generic graphics file.
Should we document these as returns instead? If any caller is writing to the buffer directly, they could then rely on this return and skip the extra load.
There is a bit trick for this: !(v & (v - 1)). Though that does not yield the log2.
If we do not declare these addresses in order, I fear we will accidentally introduce double use of an address at some point.
I'd personally rather see reserved addresses put in hex, but I don't have a good reasoning for that.