On 1 February 2016 at 23:05, Carlo Caione <carlo@xxxxxxxxxx> wrote: > On Tue, Dec 8, 2015 at 9:35 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > Hi Ulf, > (old thread, I know) > >>> I have actually a problem and a question related to this value. On the >>> boards I'm currently using to test this driver I have no CD GPIO. In >>> this case do I have to specify the MMC as "non-removable"? Also if I >> >> "non-removable" is intended to be used for eMMC or other cards >> (SD/SDIO) that is not possible to remove/insert at runtime. >> >>> try to change an SD card at runtime I have to wait 3 times the timeout >>> before being able to do it successfully. >> >> I guess you are using the "broken-cd" binding, which will enable >> MMC_CAP_NEEDS_POLL and thus the mmc core will poll to detect cards >> being inserted or removed. > > I still fail to see what the correct behaviour should be. > Using the v4 of this driver with a "broken-cd" binding and a timeout > of 10s my SD card takes 30s to be identified as removed after I take > it out from the SD slot. > Also, if I take it out and insert it again, I still have to wait 30s > to be able to access it again. Is this a limitation / bug of my driver > or is this the expected behaviour when we do not have a dedicated GPIO > for card detection? It's *not* an expected a behaviour. Using MMC_CAP_NEEDS_POLL, means that the mmc core will send CMD13 commands in a polling manner to find out whether a card has been removed. It seems like when the card is removed, the host driver doesn't get an IRQ which indicates a command timeout. Instead it waits for the 10 s timeout to expire. My question is then; why don't the driver get an IRQ for the command timeout? Is that because of non-correct setup of the IRQ masks or because the controller HW doesn't support this? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
