The data pins aren't used in this stage. All the communication between the driver and the module attached to the MMC bus is done with CMD and CLK pins in the polling process...
A similar thing was happening in the hardware I am working with. Together with these changes in the Kernel's code, we found out that the MMC driver (omap_hsmmc is the one that polls the buses) only recognized the SDIO device in the bus when all lines were configured with the processor's internal pull up enabled, as I showed previously in my pinmux configuration. In fact, all those pins starts at high level and our hardware had to be fixed in order to comply. The device we connect in the MMC2 bus does not require these pull ups and nobody checked the pins reset state...
When I was debugging our board to find out why the driver kept printing error messages like yours, I started using printk() to check which part of the driver was complaining. In the end we had to adapt our board to a previously unknown scenario and the driver in general was fine. Nevertheless, changing the driver code helped to narrow down what was going on and in my case helped even more because we need to inform both 1V8 and 3V3 to ocr_mask. I can only suggest you do the same...
It is also a good idea to check your hardware. I can confirm the bus does work even if you use two different internal muxes. In my case, CLK and CMD are in mux0 and the four data lines are in mux1.
DAVI