That was about m/sRAW on unsupported models (Rebel cameras). This option was made available in a fork of ML, and it resulted in corrupted images (i.e. data lost). Users were also unable to switch back to plain RAW without clearing Canon settings.
This is why I'm reluctant to play with certain settings - because I had trouble with them (and in some case I had to find out how to restore a soft-bricked camera). These things didn't result in permanent camera damage, but still, it wasn't funny to clean up the mess done by others.
However, the question was about maximum frame rate; in this case, the sensor readout speed is going to be the first bottleneck. If you can't capture the frames fast enough, it doesn't make sense to worry about compression, card writing speed and other stuff like that. So, let's find out the frame rate for full resolution capture.
From 0xFE32B0F6 VSizeSetting, I can tell it's reading out 3720 lines in 83 ms, so the theoretical limit would be about 12 fps at full resolution. Raw resolution registers seem to be:
0xD0006800: 0x0001000f ; (x0, y0)
0xD0006804: 0x0e8802d1 ; (x1, y1)
Lower half is X divided by number of channels, higher half is Y (on most models it's not divided by anything). Effective resolution (from wikipedia) is 5472 × 3648. From the above values, readout size must be 5648 x 3719, using 8 channels (i.e. 8 columns read out in parallel). TODO: cross-check with a full CR2 size (dcraw -i -v).
FPS timer A (from register 0xD0006008) appears to be 0x305, i.e. 774 units (as the hardware register is programmed with N-1). One line is read out in 22.3 microseconds. That means, main FPS clock must be... 774 / 22.3 = 34.7 MHz ?!
Timer B is close to 3720, likely 0xE8B = 3724 units (from VSizeSetting). Cross-checking: 34.7 MHz / 3724 / 774 = 12.04 FPS.
That means, in theory, maximum resolution at 24p might be about 5472x1700 (or something close). Or, maybe 4096x2200 with 1.33x crop. That doesn't guarantee we can actually figure out how to achieve these; they are just theoretical figures.
Still, the clock value is quite unusual, so... let's check the actual timer values used by the camera. For the above numbers, I've only grepped the ROM for known registers and looked for values that seemed to make sense.
To confirm my theory, try to capture a diagnostic log while capturing a still image. It should contain 0xD0006008, 0xD0006014, 0xD0006800 and 0xD0006804 (among others). Something along these lines:
msleep(5000); // wait for camera to start
log_start();
call("Release"); // take a picture (happens in background)
msleep(2000); // wait for the picture to be captured
log_finish();
Also try to capture the values of the above registers while *entering* LiveView, at known frame rates (24, 25, 30 and so on). That is, start logging just before entering LiveView, and stop it 2-3 seconds after entering.
