Hi Santosh, I submitted the following patch a while back. https://patchwork.kernel.org/patch/1886421/ As already said, the patch is straight forward, but without it, we probably will not see decent SDIO performance on am335x chips. [why it is needed] The omap_hsmmc module is suspended whenever it is idle, its functional clock being turned off. In this mode it is not able to forwared IRQs to the system. For that to happen, it needs to tell the PRCM to restore it's fclk. ------ | PRCM | ------ | ^ fclk | | swakeup v | ------- ------ <-- IRQ -- | hsmmc | <-- CIRQ -- | card | ------- ------ This is done through the swakeup line, which can be configured to trigger for various events, among others; CIRQ. The problem is that on the AM335x family the swakeup line is missing, it has not been routed from the module to the PRCM. [solution] the simplest solution was to keep the fclk enabled all the time. But that was not accepted, instead this was suggested > > The alternative was to configure dat1 line as a GPIO, while > > waiting for an IRQ. Then configuring it back as dat1 to serve > > the SDIO card after it signalled an IRQ. Or when the host > > wants to start a transfer. > > The way to implement this is set named states in the .dts file > for the pins using pinctrl-single.c, then have the MMC driver > request states "default" "active" and "idle" during the probe, > then toggle between active and idle during the runtime. Surprisingly the induced overhead is quite small, the performance is similar to keeping the fclk enabled at all times. See here for full thread: http://www.spinics.net/lists/linux-omap/msg83363.html https://patchwork.kernel.org/patch/1901471/ ... or just the patch There are still open questions to gpio patch itself, see here http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg87217.html So could we pls reopen that thread? It might be on the other side of your mailbox rgds, Andi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
