SDIO Clock stopped in 'idle' mode

[MarcDorval]

Hi Robert,

I'm facing an issue while trying to connect a WiFi chip to a Beaglebone black, using the mmc2 interface.

The issue occurs during the detection phase, right at the end of CMD0.

A typical SDIO part may not reply to CMD0 (as per the SDIO Physical Layer Simplified Specification), hence there mmc_clk is switched off 8 clock cycles after issuing CMD0's CRC7, when using the am335x on the BBB.
NB: Other SOCs (such as the Broadcom SoC used on Raspberry PI 2) keep the clock always on, and I don't have any issue using the latter, when using a Raspberry Pi.

The point is that my Wifi part is designed to reply to CMD0, so it starts replying but can only send the very first 3 bits (it takes 5 clock cycles to start the response), then the clock is turned off. The clock is turned on again later, while issuing CMD8, but there is a conflict there between the SoC trying to issue CMD8 and my part trying to complete its reply to CMD0.

My current workaround consists in hacking the kernel code (drivers/mmc/core/core.c:mmc_rescan_try_freq) to avoid calling mmc_go_idle for mmc2. This method works, but is not clean, since it requires rebuilding the kernel with very specific code.

I also experimented forcing bit CLKEXTFREE in the SD_CON register to 1. This works as well, but is still a kernel hack which I'd rather avoid.

I've been looking for the past days for a way to get a continuous clock in 'idle' mode, with no success so far.
It seems that there is something related to enabling IRQs using a GPIO (MMC2_DAT1 in my case) which could keep the clock active in idle, but I didn't find any detailed info about how to activate this in the device tree.

I believe I'm quite close to the solution, but still lacking some bits of information to get there.
Looks like I'm losing my way in the (device) tree...

Any help would be appreciated.

Best regards,
Marc Dorval