On 14/01/15 11:47, Ulf Hansson wrote: > On 13 January 2015 at 17:02, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >> On 01/13/15 16:41, Ulf Hansson wrote: >>> >>> On 13 January 2015 at 16:11, Arend van Spriel<arend@xxxxxxxxxxxx> wrote: >>>> >>>> On 01/13/15 15:56, Ulf Hansson wrote: >>>>> >>>>> >>>>> [...] >>>>> >>>>>>>> Thank you for looking at the patches. >>>>>>>> >>>>>>>> I am not sure I know what you mean. sdhci already has a re-tuning >>>>>>>> timer, so >>>>>>>> this is just moving it into core, where it won't be used by other >>>>>>>> drivers >>>>>>>> unless they enable it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am kind of questioning the re-tuning timer in sdhci. What is it good >>>>>>> for? >>>>>> >>>>>> >>>>>> >>>>>> It is part of the SD Host Controller Standard Specification. The timer >>>>>> ensures that re-tuning is done before temperature changes could affect >>>>>> the >>>>>> "sampling point". It is needed for re-tuning mode 1 for UHS-I modes >>>>>> like >>>>>> SDR104. >>>>> >>>>> >>>>> >>>>> Does the spec say what value the timer should have? >>>> >>>> >>>> >>>> It is read from the Capabilities register in the SD host controller, ie. >>>> in >>>> field "Timer Count for Re-Tuning" (see below). >>>> >>>> Regards, >>>> Arend >>>> >>>> Timer Count for Re-Tuning >>>> This field indicates an initial value of the Re-Tuning Timer for >>>> Re-Tuning >>>> Mode 1 to 3. Setting to 0 disables Re-Tuning Timer. >>>> 0h Re-Tuning Timer disabled >>>> 1h 1 seconds >>>> 2h 2 seconds >>>> 3h 4 seconds >>>> 4h 8 seconds >>>> ..... ...................... >>>> n 2(n-1) seconds >>>> ..... ...................... >>>> Bh 1024 seconds >>>> Eh - Ch Reserved >>>> Fh Get information from other source >>> >>> >>> Thanks for sharing this information, but unfortunate I don't >>> understand much from it. >>> >>> Is the host driver intended to read/poll this register to find a good >>> value? >> >> >> You can download the spec (and others) here [1]. sdhci currently implements >> retuning mode 1, which is decribed in the spec: >> >> Re-Tuning Timer Control Example for Re-Tuning Mode 1 >> The initial value of re-tuning timer is provided by Timer Count for >> Re-Tuning field in this register. The timer starts counting by loading the >> initial value. When the timer expires, the Host Driver marks an expiration >> flag. On receiving a command request, the Host driver checks the expiration >> flag. If the expiration flag is set, then the Host Driver should perform the >> re-tuning procedure before issuing a command. If the expiration flag is not >> set, then the Host Driver issues a command without performing the re-tuning >> procedure. Every time the re-tuning procedure is performed, the timer loads >> the new initial value and the expiration flag is cleared. >> >> So the host controller could indeed update this register for subsequent >> retuning. > > Arend, thanks for the link and information. So, I decided to go for a > look in there. > >>From the same section you quoted above: > ------ > (1) Re-Tuning Mode 1 > The host controller does not have any internal logic to detect when > the re-tuning needs to be performed. In this case, the Host Driver > should maintain all re-tuning timings by using a Re-Tuning Timer. To > enable inserting the re-tuning procedure during data transfers, the > data length per read/write command shall be limited up to 4MB. > ------ > > That means, we can't get _any_ help from the controller HW (in mode 1) > to find a good value for the timer. In fact the timer value *is* defined in the Capabilities Register (Offset 040h) bits 43-40 Timer Count for Re-Tuning It has been supported since 2011, see: commit cf2b5eea1ea0ff9b3184bc6771bcb93a9fdcd1d9 "mmc: sdhci: add support for retuning mode 1" -- 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
