On 30 September 2015 at 16:55, Heiko St?bner <heiko at sntech.de> wrote: > Am Mittwoch, 30. September 2015, 16:42:05 schrieb Ulf Hansson: >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko at sntech.de> wrote: >> > From: Douglas Anderson <dianders at chromium.org> >> > >> > This adds logic to the MMC core to set VQMMC. This is expected to be >> > called by MMC drivers like dw_mmc as part of (or instead of) their >> > start_signal_voltage_switch() callback. >> > >> > A few notes: >> > >> > * When setting the signal voltage to 3.3V we do our best to make VQMMC >> > >> > and VMMC match. It's been reported that this makes some old cards >> > happy since they were tested back in the day before UHS when VQMMC >> > and VMMC were provided by the same regulator. A nice side effect of >> > this is that we don't end up on the hairy edge of VQMMC (2.7V), >> > which some EEs claim is a little too close to the minimum for >> > comfort. >> > This is done in two steps. At first we try to find a VQMMC within >> > a 0.3V tolerance of VMMC and if this is not supported by the >> > supplying regulator we try to find a suitable voltage within the >> > whole 2.7V-3.6V area of the spec. >> > >> > * The two step approach is currently necessary, as the used >> > >> > regulator_set_voltage_triplet(min, target, max) uses a simple >> > >> > implementation that just tries two basic steps: >> > regulator_set_voltage(target, max); >> > regulator_set_voltage(min, target); >> > >> > So with only one step with 2.7-3.6V borders, if a suitable voltage >> > is a bit below VMMC, we would directly get the lowest 2.7V >> > which some boards (like Rockchips) don't like at all. >> > >> > * When setting the signal voltage to 1.8V or 1.2V we aim for that >> > >> > specific voltage instead of picking the lowest one in the range. >> > >> > * We very purposely don't print errors in mmc_regulator_set_vqmmc(). >> > >> > There are cases where the MMC core will try several different >> > voltages and we don't want to pollute the logs. >> > >> > Signed-off-by: Douglas Anderson <dianders at chromium.org> >> > Signed-off-by: Heiko Stuebner <heiko at sntech.de> >> >> This looks good to me! > > very cool :-) > > >> Once all are happy with the patches, can we take the mmc patches via >> my mmc tree or does it all have to go together? > > The clock changes of course only touch internals of the phase-clocks, so > should have no problem going through another tree. What happens if I take mmc and dt changes, wouldn't I need the clock patches as well? > > For the devicetree part I'm unsure. If the boards enable the tuning-related > settings without the new voltage handling, 2.7V gets set on all Rockchip > boards which doesn't work on those at all. > > So either the dts patches would need to go into your tree, I would need a > stable branch or we could simply postpone dts changes for the next cycle. > Kind regards Uffe
