AFAIK the issue is that sometimes OMAP doesn't come up from the deepest sleep
state into state kernel expects, so kernel spins waiting (until HW watchdog
reboots the device). If I understood correctly (couldn't verify as people are
still on Xmas vacation), the most effective workaround in kernel so far seems
to be toggling this state again (whatever that means) as that seems to get the
HW to the expected state. The exact reason why the issue happens, what exactly
triggers it, how to reliably trigger it and why toggling the state again fixes
it is not known yet. It's being investigated (not by me, I'm happy I don't
need to do debugging with an oscilloscope).

How often it happens seems to vary greatly between people, according to
comments here some get it sometimes even several times per hour (it seems to
happen more easily just after reset/reboot), but most people never get it.
However, there's not enough data to say whether it's more of a binary
difference (some devices or environments have/cause it, some not) or a sliding
scale (triggering just being rarer on others). This is partly because there
may also be other, much rarer 32wd_to reboot reasons.

The workaround we're internally testing will help if disabling the off mode
helps. If one is still getting 32wd_to reboots with off mode disabled, and
they're not due to an oops, then it's possible that this workaround isn't
enough to get completely rid of the reboots. (I've been last week testing
device that previously rebooted within hour which has now uptime of one week,
so the the workaround seems effective and it doesn't decreasing the use-time at
all.)