Tool/software: Linux
Hello,
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 should not reply to CMD0, hence there mmc_clk is switched off 8 clock cycles after issuing CMD0's CRC7. 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 these.
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.
Is there a way to either avoid sending CMD0 during the detection phase (I doubt this, looking at the code), or keep the clock ON (at least during the detection phase), ideally controllable via the device tree settings?
Best regards,
Marc Dorval
