On 2 April 2015 at 14:18, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 02/04/15 15:10, Ulf Hansson wrote: >> On 2 April 2015 at 12:30, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >>> On 04/02/15 10:43, Ulf Hansson wrote: >>>> >>>> [...] >>>>>>>> >>>>>>>> - ability to hold off re-tuning if the card is busy >>>>>>> >>>>>>> >>>>>>> >>>>>>> What do you mean by "card is busy"? >>>>>> >>>>>> >>>>>> >>>>>> I guess, more accurately, any time the card is in a state that is >>>>>> incapable >>>>>> of supporting re-tuning. For example: >>>>>> - DAT0 busy >>>>> >>>>> >>>>> >>>>> This state is not specific to re-tuning. An SDIO device can keep DAT0 >>>>> busy >>>>> at which the host controller can not start another request. >>>> >>>> >>>> Not entirely true. Some commands are allowed during this period, for >>>> example CMD13 (which doesn't exist for SDIO) >>> >>> >>> Yeah. I was wondering whether to mention that. >>> >>>> Anyway, I get the point. Thanks! >>>> >>>>> >>>>>> - between dependent commands like erase start, end, etc >>>>>> - card is asleep >>>>>> Also SDIO cards can have a custom sleep state where tuning won't work. >>>>> >>>>> >>>>> >>>>> Our SDIO wifi device has such a state and it can only come out of it upon >>>>> CMD52 write or CMD14 (ExitSleep). >>>> >>>> >>>> So how will the mmc core know about these states? I guess we will >>>> require SDIO func drivers to deal with enable/disable or hold/release >>>> of re-tuning then? >>> >>> >>> This is actually why in the past we tried to only kick off retuning before a >>> request that requires use of data line(s) so mmc core (or sdhci) would not >>> do re-tuning when SDIO func used CMD52 to wakeup the device. I never tried >>> CMD14 approach and not even sure from which spec it comes (maybe eMMC). >> >> That's an interesting idea. It would eliminate the need for SDIO func >> drivers to care about holding/releasing re-tuning. >> >> Would be nice to hear about Adrian's thoughts around this as well. > > I don't see how it would work because re-tuning is needed after the host > controller runtime resumes. i.e. once the SDIO wifi card stops being active > the host controller will runtime suspend. Why do we always need to re-tune from this phase? What Arend points out is that we could "delay" the re-tune until we know there is a DATA request. Wouldn't that work for SDHCI as well? > > Also I would expect doing re-tuning before every data request would likely > be unacceptable from a performance point of view. > >> >>> >>>> I don't like this, but if there is no other way... Also, we must be >>>> very careful on which API we exports for SDIO func drivers to use. The >>>> can easily be misinterpreted. >>>> >>>> [...] >> >> 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
