On Tue, Dec 22, 2015 at 09:30:00AM +0100, Ulf Hansson wrote: > This quirk seems a bit strange. It looks like a generic problem being > solved by the wrong approach. Although, my knowledge of sdhci HW is > limited so I might be wrong. > > Why doesn't sdhci *always* reset the related registers when the > command or data transfer gets *completed*? Instead as currently, > delaying that until the *next* request is started and via using > SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD? That would be additional overhead. The real problem is that the tuning paths compete with the normal request paths over how to set the registers. This competition needs to be killed, and a saner structure for dealing with requests and tuning commands needs to be created. This is something I'm working on as I get time: I'm restructuring sdhci_send_command() with the aim of getting to the point where the tuning code is _not_ writing to any registers at all, and that's all handled by code common to both paths. > Sdhci's sdhci_execute_tuning() function must be converted to use > mmc_send_tuning(). That will make the request path more complex, because we then need to detect the tuning commands and have special handling for them. With SDHCI, they are not a standard data transfer command, which is what mmc_send_tuning() wants. This means we end up with more complexity in what is supposed to be a fast path, which means more room for bugs to creep in. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- 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
