Until we know even how to get the m4s to start running it's probably a little premature to start allocating work for them. Although the code written for a driver to periodically run can probably run as well on an M4 if we can figure them out, so there's unlikely to be work lost even if we do switch to using the M4s somewhere down the line.
Personally I'm dubious that the M4s even have access to the GPIOs directly though, so it won't be able to read the VSync signal from the rotation chip. They're probably sat behind a very simple MMU.
My thoughts using one of the M4s were around having this relatively simple process help enable command mode while allowing the primary cores to 'sleep' even when there is something static on the screen. I'm likely oversimplifying the effort required.
It's hard to believe that there would be advertised cores within the SoC that have no documentation regarding their capabilities or how to address them.
What I have not found is a description of the ROM contents. But it appears that TI provides a patched kernel and tools so that something called "SYS/BIOS" is loaded into the M4 and started. And the A15 can use remote procedure calls to trigger code in the M4.
Therefore, I think it is possible to run the VSYNC gpio/interrupt handler on one of the M4 cores, but that a second phase optimization after the Pyra becomes available to the masses. As a first step it is easier to add it as an irg handler to the A15.