diff for duplicates of <2695161.Z1IhqPE0bd@diego> diff --git a/a/1.txt b/N1/1.txt index 7719430..8f30f7e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,106 +1,83 @@ Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson: -> On 30 September 2015 at 16:55, Heiko St=FCbner <heiko@sntech.de> wrot= -e: +> On 30 September 2015 at 16:55, Heiko Stübner <heiko@sntech.de> wrote: > > Am Mittwoch, 30. September 2015, 16:42:05 schrieb Ulf Hansson: -> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wr= -ote: +> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wrote: > >> > From: Douglas Anderson <dianders@chromium.org> -> >> >=20 -> >> > 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) the= -ir +> >> > +> >> > 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. -> >> >=20 +> >> > > >> > A few notes: -> >> >=20 -> >> > * When setting the signal voltage to 3.3V we do our best to make= - VQMMC -> >> >=20 -> >> > and VMMC match. It's been reported that this makes some old c= -ards -> >> > happy since they were tested back in the day before UHS when V= -QMMC -> >> > and VMMC were provided by the same regulator. A nice side eff= -ect of -> >> > this is that we don't end up on the hairy edge of VQMMC (2.7V)= -, +> >> > +> >> > * 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 wit= -hin +> >> > 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 t= -he +> >> > supplying regulator we try to find a suitable voltage within the > >> > whole 2.7V-3.6V area of the spec. -> >> >=20 +> >> > > >> > * The two step approach is currently necessary, as the used -> >> >=20 +> >> > > >> > regulator_set_voltage_triplet(min, target, max) uses a simple -> >> > =20 +> >> > > >> > implementation that just tries two basic steps: > >> > regulator_set_voltage(target, max); > >> > regulator_set_voltage(min, target); -> >> > =20 -> >> > So with only one step with 2.7-3.6V borders, if a suitable vol= -tage +> >> > +> >> > 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. -> >> >=20 -> >> > * When setting the signal voltage to 1.8V or 1.2V we aim for tha= -t -> >> >=20 -> >> > specific voltage instead of picking the lowest one in the rang= -e. -> >> >=20 -> >> > * We very purposely don't print errors in mmc_regulator_set_vqmm= -c(). -> >> >=20 +> >> > +> >> > * 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. -> >> >=20 +> >> > > >> > Signed-off-by: Douglas Anderson <dianders@chromium.org> > >> > Signed-off-by: Heiko Stuebner <heiko@sntech.de> -> >>=20 +> >> > >> This looks good to me! -> >=20 +> > > > very cool :-) -> >=20 -> >> Once all are happy with the patches, can we take the mmc patches v= -ia +> > +> >> 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? -> >=20 -> > The clock changes of course only touch internals of the phase-clock= -s, so +> > +> > The clock changes of course only touch internals of the phase-clocks, so > > should have no problem going through another tree. ->=20 +> > 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 translati= -on gets=20 -optimized, so I guess in the worst case you would get no good phase and= - thus=20 +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=20 +But of course, if the clock maintainers could Ack the two clock patches and everything would stay together that would work even better :-) Heiko ->=20 +> > > 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 Roc= -kchip +> > settings without the new voltage handling, 2.7V gets set on all Rockchip > > boards which doesn't work on those at all. -> >=20 -> > 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. ->=20 +> > +> > 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 diff --git a/a/content_digest b/N1/content_digest index 4662367..982c53b 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -18,110 +18,87 @@ "\00:1\0" "b\0" "Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson:\n" - "> On 30 September 2015 at 16:55, Heiko St=FCbner <heiko@sntech.de> wrot=\n" - "e:\n" + "> On 30 September 2015 at 16:55, Heiko St\303\274bner <heiko@sntech.de> wrote:\n" "> > Am Mittwoch, 30. September 2015, 16:42:05 schrieb Ulf Hansson:\n" - "> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wr=\n" - "ote:\n" + "> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wrote:\n" "> >> > From: Douglas Anderson <dianders@chromium.org>\n" - "> >> >=20\n" - "> >> > This adds logic to the MMC core to set VQMMC. This is expected =\n" - "to be\n" - "> >> > called by MMC drivers like dw_mmc as part of (or instead of) the=\n" - "ir\n" + "> >> > \n" + "> >> > This adds logic to the MMC core to set VQMMC. This is expected to be\n" + "> >> > called by MMC drivers like dw_mmc as part of (or instead of) their\n" "> >> > start_signal_voltage_switch() callback.\n" - "> >> >=20\n" + "> >> > \n" "> >> > A few notes:\n" - "> >> >=20\n" - "> >> > * When setting the signal voltage to 3.3V we do our best to make=\n" - " VQMMC\n" - "> >> >=20\n" - "> >> > and VMMC match. It's been reported that this makes some old c=\n" - "ards\n" - "> >> > happy since they were tested back in the day before UHS when V=\n" - "QMMC\n" - "> >> > and VMMC were provided by the same regulator. A nice side eff=\n" - "ect of\n" - "> >> > this is that we don't end up on the hairy edge of VQMMC (2.7V)=\n" - ",\n" + "> >> > \n" + "> >> > * When setting the signal voltage to 3.3V we do our best to make VQMMC\n" + "> >> > \n" + "> >> > and VMMC match. It's been reported that this makes some old cards\n" + "> >> > happy since they were tested back in the day before UHS when VQMMC\n" + "> >> > and VMMC were provided by the same regulator. A nice side effect of\n" + "> >> > this is that we don't end up on the hairy edge of VQMMC (2.7V),\n" "> >> > which some EEs claim is a little too close to the minimum for\n" "> >> > comfort.\n" - "> >> > This is done in two steps. At first we try to find a VQMMC wit=\n" - "hin\n" + "> >> > This is done in two steps. At first we try to find a VQMMC within\n" "> >> > a 0.3V tolerance of VMMC and if this is not supported by the\n" - "> >> > supplying regulator we try to find a suitable voltage within t=\n" - "he\n" + "> >> > supplying regulator we try to find a suitable voltage within the\n" "> >> > whole 2.7V-3.6V area of the spec.\n" - "> >> >=20\n" + "> >> > \n" "> >> > * The two step approach is currently necessary, as the used\n" - "> >> >=20\n" + "> >> > \n" "> >> > regulator_set_voltage_triplet(min, target, max) uses a simple\n" - "> >> > =20\n" + "> >> > \n" "> >> > implementation that just tries two basic steps:\n" "> >> > regulator_set_voltage(target, max);\n" "> >> > regulator_set_voltage(min, target);\n" - "> >> > =20\n" - "> >> > So with only one step with 2.7-3.6V borders, if a suitable vol=\n" - "tage\n" + "> >> > \n" + "> >> > So with only one step with 2.7-3.6V borders, if a suitable voltage\n" "> >> > is a bit below VMMC, we would directly get the lowest 2.7V\n" "> >> > which some boards (like Rockchips) don't like at all.\n" - "> >> >=20\n" - "> >> > * When setting the signal voltage to 1.8V or 1.2V we aim for tha=\n" - "t\n" - "> >> >=20\n" - "> >> > specific voltage instead of picking the lowest one in the rang=\n" - "e.\n" - "> >> >=20\n" - "> >> > * We very purposely don't print errors in mmc_regulator_set_vqmm=\n" - "c().\n" - "> >> >=20\n" + "> >> > \n" + "> >> > * When setting the signal voltage to 1.8V or 1.2V we aim for that\n" + "> >> > \n" + "> >> > specific voltage instead of picking the lowest one in the range.\n" + "> >> > \n" + "> >> > * We very purposely don't print errors in mmc_regulator_set_vqmmc().\n" + "> >> > \n" "> >> > There are cases where the MMC core will try several different\n" "> >> > voltages and we don't want to pollute the logs.\n" - "> >> >=20\n" + "> >> > \n" "> >> > Signed-off-by: Douglas Anderson <dianders@chromium.org>\n" "> >> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>\n" - "> >>=20\n" + "> >> \n" "> >> This looks good to me!\n" - "> >=20\n" + "> > \n" "> > very cool :-)\n" - "> >=20\n" - "> >> Once all are happy with the patches, can we take the mmc patches v=\n" - "ia\n" + "> > \n" + "> >> Once all are happy with the patches, can we take the mmc patches via\n" "> >> my mmc tree or does it all have to go together?\n" - "> >=20\n" - "> > The clock changes of course only touch internals of the phase-clock=\n" - "s, so\n" + "> > \n" + "> > The clock changes of course only touch internals of the phase-clocks, so\n" "> > should have no problem going through another tree.\n" - ">=20\n" + "> \n" "> What happens if I take mmc and dt changes, wouldn't I need the clock\n" "> patches as well?\n" "\n" - "The API stays of course the same, only the degree to settings translati=\n" - "on gets=20\n" - "optimized, so I guess in the worst case you would get no good phase and=\n" - " thus=20\n" + "The API stays of course the same, only the degree to settings translation gets \n" + "optimized, so I guess in the worst case you would get no good phase and thus \n" "fall back to non-highspeed modes - but the system would stay running.\n" "\n" - "But of course, if the clock maintainers could Ack the two clock patches=\n" - " and=20\n" + "But of course, if the clock maintainers could Ack the two clock patches and \n" "everything would stay together that would work even better :-)\n" "\n" "\n" "Heiko\n" "\n" - ">=20\n" + "> \n" "> > For the devicetree part I'm unsure. If the boards enable the\n" "> > tuning-related\n" - "> > settings without the new voltage handling, 2.7V gets set on all Roc=\n" - "kchip\n" + "> > settings without the new voltage handling, 2.7V gets set on all Rockchip\n" "> > boards which doesn't work on those at all.\n" - "> >=20\n" - "> > So either the dts patches would need to go into your tree, I would =\n" - "need a\n" - "> > stable branch or we could simply postpone dts changes for the next =\n" - "cycle.\n" - ">=20\n" + "> > \n" + "> > So either the dts patches would need to go into your tree, I would need a\n" + "> > stable branch or we could simply postpone dts changes for the next cycle.\n" + "> \n" "> Kind regards\n" > Uffe -6794cfd98e28933e624296acfca1818dd5b6b217bbec1eb296eb206fd2fb28c6 +b5769d67d9d6e1124d025fe55500dc5713f5a383f66e3be2b3968ab5ce9e51fa
diff --git a/a/1.txt b/N2/1.txt index 7719430..e70fe34 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,106 +1,83 @@ Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson: -> On 30 September 2015 at 16:55, Heiko St=FCbner <heiko@sntech.de> wrot= -e: +> On 30 September 2015 at 16:55, Heiko St?bner <heiko@sntech.de> wrote: > > Am Mittwoch, 30. September 2015, 16:42:05 schrieb Ulf Hansson: -> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wr= -ote: +> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wrote: > >> > From: Douglas Anderson <dianders@chromium.org> -> >> >=20 -> >> > 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) the= -ir +> >> > +> >> > 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. -> >> >=20 +> >> > > >> > A few notes: -> >> >=20 -> >> > * When setting the signal voltage to 3.3V we do our best to make= - VQMMC -> >> >=20 -> >> > and VMMC match. It's been reported that this makes some old c= -ards -> >> > happy since they were tested back in the day before UHS when V= -QMMC -> >> > and VMMC were provided by the same regulator. A nice side eff= -ect of -> >> > this is that we don't end up on the hairy edge of VQMMC (2.7V)= -, +> >> > +> >> > * 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 wit= -hin +> >> > 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 t= -he +> >> > supplying regulator we try to find a suitable voltage within the > >> > whole 2.7V-3.6V area of the spec. -> >> >=20 +> >> > > >> > * The two step approach is currently necessary, as the used -> >> >=20 +> >> > > >> > regulator_set_voltage_triplet(min, target, max) uses a simple -> >> > =20 +> >> > > >> > implementation that just tries two basic steps: > >> > regulator_set_voltage(target, max); > >> > regulator_set_voltage(min, target); -> >> > =20 -> >> > So with only one step with 2.7-3.6V borders, if a suitable vol= -tage +> >> > +> >> > 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. -> >> >=20 -> >> > * When setting the signal voltage to 1.8V or 1.2V we aim for tha= -t -> >> >=20 -> >> > specific voltage instead of picking the lowest one in the rang= -e. -> >> >=20 -> >> > * We very purposely don't print errors in mmc_regulator_set_vqmm= -c(). -> >> >=20 +> >> > +> >> > * 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. -> >> >=20 +> >> > > >> > Signed-off-by: Douglas Anderson <dianders@chromium.org> > >> > Signed-off-by: Heiko Stuebner <heiko@sntech.de> -> >>=20 +> >> > >> This looks good to me! -> >=20 +> > > > very cool :-) -> >=20 -> >> Once all are happy with the patches, can we take the mmc patches v= -ia +> > +> >> 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? -> >=20 -> > The clock changes of course only touch internals of the phase-clock= -s, so +> > +> > The clock changes of course only touch internals of the phase-clocks, so > > should have no problem going through another tree. ->=20 +> > 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 translati= -on gets=20 -optimized, so I guess in the worst case you would get no good phase and= - thus=20 +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=20 +But of course, if the clock maintainers could Ack the two clock patches and everything would stay together that would work even better :-) Heiko ->=20 +> > > 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 Roc= -kchip +> > settings without the new voltage handling, 2.7V gets set on all Rockchip > > boards which doesn't work on those at all. -> >=20 -> > 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. ->=20 +> > +> > 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 diff --git a/a/content_digest b/N2/content_digest index 4662367..9db7c0d 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,127 +1,94 @@ "ref\01443622064-14362-1-git-send-email-heiko@sntech.de\0" "ref\017200614.QxCe8zAb7I@diego\0" "ref\0CAPDyKFpis8XnvrppHq7q_7DQeN2UiEpykNTJ=1iJJ9AGOHTW6Q@mail.gmail.com\0" - "From\0Heiko St\303\274bner <heiko@sntech.de>\0" - "Subject\0Re: [PATCH v2 3/8] mmc: core: Add mmc_regulator_set_vqmmc()\0" + "From\0heiko@sntech.de (Heiko St\303\274bner)\0" + "Subject\0[PATCH v2 3/8] mmc: core: Add mmc_regulator_set_vqmmc()\0" "Date\0Thu, 01 Oct 2015 12:21:19 +0200\0" - "To\0Ulf Hansson <ulf.hansson@linaro.org>\0" - "Cc\0Michael Turquette <mturquette@baylibre.com>" - Stephen Boyd <sboyd@codeaurora.org> - tgih.jun@samsung.com <tgih.jun@samsung.com> - Jaehoon Chung <jh80.chung@samsung.com> - linux-mmc <linux-mmc@vger.kernel.org> - linux-clk@vger.kernel.org - linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> - open list:ARM/Rockchip SoC... <linux-rockchip@lists.infradead.org> - Doug Anderson <dianders@chromium.org> - " Alexandru Stan <amstan@chromium.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson:\n" - "> On 30 September 2015 at 16:55, Heiko St=FCbner <heiko@sntech.de> wrot=\n" - "e:\n" + "> On 30 September 2015 at 16:55, Heiko St?bner <heiko@sntech.de> wrote:\n" "> > Am Mittwoch, 30. September 2015, 16:42:05 schrieb Ulf Hansson:\n" - "> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wr=\n" - "ote:\n" + "> >> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wrote:\n" "> >> > From: Douglas Anderson <dianders@chromium.org>\n" - "> >> >=20\n" - "> >> > This adds logic to the MMC core to set VQMMC. This is expected =\n" - "to be\n" - "> >> > called by MMC drivers like dw_mmc as part of (or instead of) the=\n" - "ir\n" + "> >> > \n" + "> >> > This adds logic to the MMC core to set VQMMC. This is expected to be\n" + "> >> > called by MMC drivers like dw_mmc as part of (or instead of) their\n" "> >> > start_signal_voltage_switch() callback.\n" - "> >> >=20\n" + "> >> > \n" "> >> > A few notes:\n" - "> >> >=20\n" - "> >> > * When setting the signal voltage to 3.3V we do our best to make=\n" - " VQMMC\n" - "> >> >=20\n" - "> >> > and VMMC match. It's been reported that this makes some old c=\n" - "ards\n" - "> >> > happy since they were tested back in the day before UHS when V=\n" - "QMMC\n" - "> >> > and VMMC were provided by the same regulator. A nice side eff=\n" - "ect of\n" - "> >> > this is that we don't end up on the hairy edge of VQMMC (2.7V)=\n" - ",\n" + "> >> > \n" + "> >> > * When setting the signal voltage to 3.3V we do our best to make VQMMC\n" + "> >> > \n" + "> >> > and VMMC match. It's been reported that this makes some old cards\n" + "> >> > happy since they were tested back in the day before UHS when VQMMC\n" + "> >> > and VMMC were provided by the same regulator. A nice side effect of\n" + "> >> > this is that we don't end up on the hairy edge of VQMMC (2.7V),\n" "> >> > which some EEs claim is a little too close to the minimum for\n" "> >> > comfort.\n" - "> >> > This is done in two steps. At first we try to find a VQMMC wit=\n" - "hin\n" + "> >> > This is done in two steps. At first we try to find a VQMMC within\n" "> >> > a 0.3V tolerance of VMMC and if this is not supported by the\n" - "> >> > supplying regulator we try to find a suitable voltage within t=\n" - "he\n" + "> >> > supplying regulator we try to find a suitable voltage within the\n" "> >> > whole 2.7V-3.6V area of the spec.\n" - "> >> >=20\n" + "> >> > \n" "> >> > * The two step approach is currently necessary, as the used\n" - "> >> >=20\n" + "> >> > \n" "> >> > regulator_set_voltage_triplet(min, target, max) uses a simple\n" - "> >> > =20\n" + "> >> > \n" "> >> > implementation that just tries two basic steps:\n" "> >> > regulator_set_voltage(target, max);\n" "> >> > regulator_set_voltage(min, target);\n" - "> >> > =20\n" - "> >> > So with only one step with 2.7-3.6V borders, if a suitable vol=\n" - "tage\n" + "> >> > \n" + "> >> > So with only one step with 2.7-3.6V borders, if a suitable voltage\n" "> >> > is a bit below VMMC, we would directly get the lowest 2.7V\n" "> >> > which some boards (like Rockchips) don't like at all.\n" - "> >> >=20\n" - "> >> > * When setting the signal voltage to 1.8V or 1.2V we aim for tha=\n" - "t\n" - "> >> >=20\n" - "> >> > specific voltage instead of picking the lowest one in the rang=\n" - "e.\n" - "> >> >=20\n" - "> >> > * We very purposely don't print errors in mmc_regulator_set_vqmm=\n" - "c().\n" - "> >> >=20\n" + "> >> > \n" + "> >> > * When setting the signal voltage to 1.8V or 1.2V we aim for that\n" + "> >> > \n" + "> >> > specific voltage instead of picking the lowest one in the range.\n" + "> >> > \n" + "> >> > * We very purposely don't print errors in mmc_regulator_set_vqmmc().\n" + "> >> > \n" "> >> > There are cases where the MMC core will try several different\n" "> >> > voltages and we don't want to pollute the logs.\n" - "> >> >=20\n" + "> >> > \n" "> >> > Signed-off-by: Douglas Anderson <dianders@chromium.org>\n" "> >> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>\n" - "> >>=20\n" + "> >> \n" "> >> This looks good to me!\n" - "> >=20\n" + "> > \n" "> > very cool :-)\n" - "> >=20\n" - "> >> Once all are happy with the patches, can we take the mmc patches v=\n" - "ia\n" + "> > \n" + "> >> Once all are happy with the patches, can we take the mmc patches via\n" "> >> my mmc tree or does it all have to go together?\n" - "> >=20\n" - "> > The clock changes of course only touch internals of the phase-clock=\n" - "s, so\n" + "> > \n" + "> > The clock changes of course only touch internals of the phase-clocks, so\n" "> > should have no problem going through another tree.\n" - ">=20\n" + "> \n" "> What happens if I take mmc and dt changes, wouldn't I need the clock\n" "> patches as well?\n" "\n" - "The API stays of course the same, only the degree to settings translati=\n" - "on gets=20\n" - "optimized, so I guess in the worst case you would get no good phase and=\n" - " thus=20\n" + "The API stays of course the same, only the degree to settings translation gets \n" + "optimized, so I guess in the worst case you would get no good phase and thus \n" "fall back to non-highspeed modes - but the system would stay running.\n" "\n" - "But of course, if the clock maintainers could Ack the two clock patches=\n" - " and=20\n" + "But of course, if the clock maintainers could Ack the two clock patches and \n" "everything would stay together that would work even better :-)\n" "\n" "\n" "Heiko\n" "\n" - ">=20\n" + "> \n" "> > For the devicetree part I'm unsure. If the boards enable the\n" "> > tuning-related\n" - "> > settings without the new voltage handling, 2.7V gets set on all Roc=\n" - "kchip\n" + "> > settings without the new voltage handling, 2.7V gets set on all Rockchip\n" "> > boards which doesn't work on those at all.\n" - "> >=20\n" - "> > So either the dts patches would need to go into your tree, I would =\n" - "need a\n" - "> > stable branch or we could simply postpone dts changes for the next =\n" - "cycle.\n" - ">=20\n" + "> > \n" + "> > So either the dts patches would need to go into your tree, I would need a\n" + "> > stable branch or we could simply postpone dts changes for the next cycle.\n" + "> \n" "> Kind regards\n" > Uffe -6794cfd98e28933e624296acfca1818dd5b6b217bbec1eb296eb206fd2fb28c6 +c7c72c14007a1b3bfa49c5393908e246da65516fab698b0dcc523edadcddaf17
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.