[...] > > I have no locking issues, so I am not sure what you mean here. Okay, I should have stated race conditions. > >> >>> >>>> I think we need an generic approach to deal with the runtime PM >>>> synchronization issue described above. More precisely in those >>>> scenarios when mmc hosts needs to notify the mmc core to take some >>>> specific actions, from a mmc host's runtime PM callback. >>> >>> For the re-tune case I did not want to assume what the host driver >>> needed to do, so I added ->hold_tuning() and ->release_tuning() >>> host operations. >> >> I have thought a bit more on how I would like this to be implemented. >> It's a bit closer to what Neil's suggests in his approach [1]. > > I am not sure it is valuable to mix up the two issues. > > For Neil's problem I would do something quiet different: > > 1. The host driver already knows the bus width so can easily "get/put" > runtime pm to prevent suspend when the bus width does not permit it. To me the problem is the other way around. The host driver don't want prevent runtime PM suspend. Instead it want to notify the core that it's ready to be runtime PM suspended. Due to restrictions by the SDIO spec, the mmc core first need to switch to 1-bit data, before the host can do clock gating in runtime PM suspend. > > 2. The need to do things when the card is idle comes up a lot (e.g. bkops, > sleep notification, cache flush etc etc). In Neil's case he wants to switch > to 1-bit mode, but that just seems another of these "idle" operations. So I > would investigate the requirements of supporting idle operations in general. That won't work for the SDIO case, since runtime PM is being deployed differently for SDIO than for MMC/SD. In the SDIO case it's the SDIO func drivers that handles the get/put. For the MMC/SD case it's handled by the block device layer. Still, yes I agree that it would be of great interest to look into "idle" operations of eMMC/SD, especially for those other things you mention, but I don't see it as the solution for Neil's SDIO issue. 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
