Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson:

On 30 September 2015 at 16:55, Heiko St?bner [off-list ref] wrote:

quoted

Am Mittwoch, 30. September 2015, 16:42:05 schrieb Ulf Hansson:

quoted

On 30 September 2015 at 16:07, Heiko Stuebner [off-list ref] wrote:

quoted

From: Douglas Anderson <dianders@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@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

This looks good to me!

very cool :-)

quoted

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?

The API stays of course the same, only the degree to settings translation gets 
optimized, so I guess in the worst case you would get no good phase and thus 
fall back to non-highspeed modes - but the system would stay running.

But of course, if the clock maintainers could Ack the two clock patches and 
everything would stay together that would work even better :-)


Heiko

quoted

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