diff for duplicates of <3312969.jJ2hfB2JkV@diego> diff --git a/a/1.txt b/N1/1.txt index 0453fbf..0eb7cde 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,50 +1,40 @@ Am Freitag, 2. Oktober 2015, 11:52:00 schrieb Jaehoon Chung: > On 10/02/2015 06:05 AM, Ulf Hansson wrote: -> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wro= -te: -> >> On 10/01, Heiko St=FCbner wrote: +> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wrote: +> >> On 10/01, Heiko Stübner wrote: > >>> Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson: -> >>>> On 30 September 2015 at 16:55, Heiko St=FCbner <heiko@sntech.de>= - wrote: +> >>>> 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= ->=20 +> >>>>>> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wrote: -> >>>>> The clock changes of course only touch internals of the phase-c= -locks, +> >>>>> 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 c= -lock +> >>>> +> >>>> What happens if I take mmc and dt changes, wouldn't I need the clock > >>>> patches as well? -> >>>=20 +> >>> > >>> The API stays of course the same, only the degree to settings -> >>> translation gets optimized, so I guess in the worst case you woul= -d get -> >>> no good phase and thus fall back to non-highspeed modes - but the= - +> >>> 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. -> >>>=20 -> >>> But of course, if the clock maintainers could Ack the two clock p= -atches +> >>> +> >>> But of course, if the clock maintainers could Ack the two clock patches > >>> and > >>> everything would stay together that would work even better :-) -> >>=20 +> >> > >> If Ulf doesn't want to take them we can apply them to clk tree. > >> Otherwise, you can have my acked-by on the clk patches. -> >=20 -> > I don't mind picking up the clock patches. So I consider this as an= - +> > +> > I don't mind picking up the clock patches. So I consider this as an > > ack for both patch 1 and patch2, thanks. -> >=20 +> > > > Now, let's give Jaehoon some time to review the dw_mmc parts. ->=20 +> > I will check other patches on today, if it's ok, i will apply at my > repository. Thanks for giving time! :) -I think Ulf wanted to apply the whole series via the mmc tree directly,= - but I=20 +I think Ulf wanted to apply the whole series via the mmc tree directly, but I guess that is between you two to decide ;-) diff --git a/a/content_digest b/N1/content_digest index 0ab60f4..6d05b88 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -18,54 +18,44 @@ "b\0" "Am Freitag, 2. Oktober 2015, 11:52:00 schrieb Jaehoon Chung:\n" "> On 10/02/2015 06:05 AM, Ulf Hansson wrote:\n" - "> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wro=\n" - "te:\n" - "> >> On 10/01, Heiko St=FCbner wrote:\n" + "> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wrote:\n" + "> >> On 10/01, Heiko St\303\274bner wrote:\n" "> >>> 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>=\n" - " wrote:\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=\n" - ">=20\n" + "> >>>>>> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> \n" "wrote:\n" - "> >>>>> The clock changes of course only touch internals of the phase-c=\n" - "locks,\n" + "> >>>>> The clock changes of course only touch internals of the phase-clocks,\n" "> >>>>> so\n" "> >>>>> should have no problem going through another tree.\n" - "> >>>>=20\n" - "> >>>> What happens if I take mmc and dt changes, wouldn't I need the c=\n" - "lock\n" + "> >>>> \n" + "> >>>> What happens if I take mmc and dt changes, wouldn't I need the clock\n" "> >>>> patches as well?\n" - "> >>>=20\n" + "> >>> \n" "> >>> The API stays of course the same, only the degree to settings\n" - "> >>> translation gets optimized, so I guess in the worst case you woul=\n" - "d get\n" - "> >>> no good phase and thus fall back to non-highspeed modes - but the=\n" - "\n" + "> >>> translation gets optimized, so I guess in the worst case you would get\n" + "> >>> no good phase and thus fall back to non-highspeed modes - but the\n" "> >>> system would stay running.\n" - "> >>>=20\n" - "> >>> But of course, if the clock maintainers could Ack the two clock p=\n" - "atches\n" + "> >>> \n" + "> >>> But of course, if the clock maintainers could Ack the two clock patches\n" "> >>> and\n" "> >>> everything would stay together that would work even better :-)\n" - "> >>=20\n" + "> >> \n" "> >> If Ulf doesn't want to take them we can apply them to clk tree.\n" "> >> Otherwise, you can have my acked-by on the clk patches.\n" - "> >=20\n" - "> > I don't mind picking up the clock patches. So I consider this as an=\n" - "\n" + "> > \n" + "> > I don't mind picking up the clock patches. So I consider this as an\n" "> > ack for both patch 1 and patch2, thanks.\n" - "> >=20\n" + "> > \n" "> > Now, let's give Jaehoon some time to review the dw_mmc parts.\n" - ">=20\n" + "> \n" "> I will check other patches on today, if it's ok, i will apply at my\n" "> repository. Thanks for giving time! :)\n" "\n" - "I think Ulf wanted to apply the whole series via the mmc tree directly,=\n" - " but I=20\n" + "I think Ulf wanted to apply the whole series via the mmc tree directly, but I \n" "guess that is between you two to decide ;-)\n" "\n" "\n" Heiko -00ebf8b76872d74091cb26e85002eed3c5ddd16c5b6d2c574b83ec8492200f02 +54e68a7864c7b37e84c5705bffcb2712bf9d6234ee67b622cf19f203f812bcc0
diff --git a/a/1.txt b/N2/1.txt index 0453fbf..fec08ca 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,50 +1,40 @@ Am Freitag, 2. Oktober 2015, 11:52:00 schrieb Jaehoon Chung: > On 10/02/2015 06:05 AM, Ulf Hansson wrote: -> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wro= -te: -> >> On 10/01, Heiko St=FCbner wrote: +> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wrote: +> >> On 10/01, Heiko St?bner wrote: > >>> Am Donnerstag, 1. Oktober 2015, 11:54:24 schrieb Ulf Hansson: -> >>>> On 30 September 2015 at 16:55, Heiko St=FCbner <heiko@sntech.de>= - wrote: +> >>>> 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= ->=20 +> >>>>>> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> wrote: -> >>>>> The clock changes of course only touch internals of the phase-c= -locks, +> >>>>> 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 c= -lock +> >>>> +> >>>> What happens if I take mmc and dt changes, wouldn't I need the clock > >>>> patches as well? -> >>>=20 +> >>> > >>> The API stays of course the same, only the degree to settings -> >>> translation gets optimized, so I guess in the worst case you woul= -d get -> >>> no good phase and thus fall back to non-highspeed modes - but the= - +> >>> 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. -> >>>=20 -> >>> But of course, if the clock maintainers could Ack the two clock p= -atches +> >>> +> >>> But of course, if the clock maintainers could Ack the two clock patches > >>> and > >>> everything would stay together that would work even better :-) -> >>=20 +> >> > >> If Ulf doesn't want to take them we can apply them to clk tree. > >> Otherwise, you can have my acked-by on the clk patches. -> >=20 -> > I don't mind picking up the clock patches. So I consider this as an= - +> > +> > I don't mind picking up the clock patches. So I consider this as an > > ack for both patch 1 and patch2, thanks. -> >=20 +> > > > Now, let's give Jaehoon some time to review the dw_mmc parts. ->=20 +> > I will check other patches on today, if it's ok, i will apply at my > repository. Thanks for giving time! :) -I think Ulf wanted to apply the whole series via the mmc tree directly,= - but I=20 +I think Ulf wanted to apply the whole series via the mmc tree directly, but I guess that is between you two to decide ;-) diff --git a/a/content_digest b/N2/content_digest index 0ab60f4..42f42ce 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,71 +1,52 @@ "ref\01443622064-14362-1-git-send-email-heiko@sntech.de\0" "ref\0CAPDyKFqrkYXsbBJ61yYo0G8za1szARvA=as-5nLTiwGH5pCrEQ@mail.gmail.com\0" "ref\0560DF150.3000906@samsung.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\0Fri, 02 Oct 2015 09:06:48 +0200\0" - "To\0Jaehoon Chung <jh80.chung@samsung.com>\0" - "Cc\0Ulf Hansson <ulf.hansson@linaro.org>" - Stephen Boyd <sboyd@codeaurora.org> - Michael Turquette <mturquette@baylibre.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 Freitag, 2. Oktober 2015, 11:52:00 schrieb Jaehoon Chung:\n" "> On 10/02/2015 06:05 AM, Ulf Hansson wrote:\n" - "> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wro=\n" - "te:\n" - "> >> On 10/01, Heiko St=FCbner wrote:\n" + "> > On 1 October 2015 at 19:35, Stephen Boyd <sboyd@codeaurora.org> wrote:\n" + "> >> On 10/01, Heiko St?bner wrote:\n" "> >>> 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>=\n" - " wrote:\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=\n" - ">=20\n" + "> >>>>>> On 30 September 2015 at 16:07, Heiko Stuebner <heiko@sntech.de> \n" "wrote:\n" - "> >>>>> The clock changes of course only touch internals of the phase-c=\n" - "locks,\n" + "> >>>>> The clock changes of course only touch internals of the phase-clocks,\n" "> >>>>> so\n" "> >>>>> should have no problem going through another tree.\n" - "> >>>>=20\n" - "> >>>> What happens if I take mmc and dt changes, wouldn't I need the c=\n" - "lock\n" + "> >>>> \n" + "> >>>> What happens if I take mmc and dt changes, wouldn't I need the clock\n" "> >>>> patches as well?\n" - "> >>>=20\n" + "> >>> \n" "> >>> The API stays of course the same, only the degree to settings\n" - "> >>> translation gets optimized, so I guess in the worst case you woul=\n" - "d get\n" - "> >>> no good phase and thus fall back to non-highspeed modes - but the=\n" - "\n" + "> >>> translation gets optimized, so I guess in the worst case you would get\n" + "> >>> no good phase and thus fall back to non-highspeed modes - but the\n" "> >>> system would stay running.\n" - "> >>>=20\n" - "> >>> But of course, if the clock maintainers could Ack the two clock p=\n" - "atches\n" + "> >>> \n" + "> >>> But of course, if the clock maintainers could Ack the two clock patches\n" "> >>> and\n" "> >>> everything would stay together that would work even better :-)\n" - "> >>=20\n" + "> >> \n" "> >> If Ulf doesn't want to take them we can apply them to clk tree.\n" "> >> Otherwise, you can have my acked-by on the clk patches.\n" - "> >=20\n" - "> > I don't mind picking up the clock patches. So I consider this as an=\n" - "\n" + "> > \n" + "> > I don't mind picking up the clock patches. So I consider this as an\n" "> > ack for both patch 1 and patch2, thanks.\n" - "> >=20\n" + "> > \n" "> > Now, let's give Jaehoon some time to review the dw_mmc parts.\n" - ">=20\n" + "> \n" "> I will check other patches on today, if it's ok, i will apply at my\n" "> repository. Thanks for giving time! :)\n" "\n" - "I think Ulf wanted to apply the whole series via the mmc tree directly,=\n" - " but I=20\n" + "I think Ulf wanted to apply the whole series via the mmc tree directly, but I \n" "guess that is between you two to decide ;-)\n" "\n" "\n" Heiko -00ebf8b76872d74091cb26e85002eed3c5ddd16c5b6d2c574b83ec8492200f02 +e2ad52fb360059cb6c07bdb5f2efe81d4e2c3f36da20bd33cd02aaf0d7725445
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.