diff for duplicates of <20151026105138.20687.13546@quantum> diff --git a/a/1.txt b/N1/1.txt index 0865630..02a4b56 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,8 +2,7 @@ Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > -> >> Well, I'm not quite sure why exactly everyone is so focused on probing= - here. +> >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that @@ -12,13 +11,11 @@ Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). -> = - +> > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). -> = - +> > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the @@ -35,13 +32,11 @@ boots sounds interesting to me. Regards, Mike -> = - +> > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. -> = - +> > Thanks, > Rafael diff --git a/a/content_digest b/N1/content_digest index a34a85f..7c906b0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,7 +6,7 @@ "ref\0CAJZ5v0hPVu7AL8zBdU4Kb7+MVfYv0mTa43RhnCyyPR+RKDbhLA@mail.gmail.com\0" "From\0Michael Turquette <mturquette@baylibre.com>\0" "Subject\0Re: [GIT PULL] On-demand device probing\0" - "Date\0Mon, 26 Oct 2015 03:51:38 -0700\0" + "Date\0Mon, 26 Oct 2015 10:51:38 +0000\0" "To\0Rafael J. Wysocki <rafael@kernel.org>" " Mark Brown <broonie@kernel.org>\0" "Cc\0Rafael J. Wysocki <rjw@rjwysocki.net>" @@ -28,35 +28,14 @@ Wolfram Sang <wsa@the-dreams.de> Grant Likely <grant.likely@linaro.org> Kishon Vijay Abraham I <kishon@ti.com> - Sebastian Reichel <sre@kernel.org> - Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> - David Woodhouse <dwmw2@infradead.org> - Liam Girdwood <lgirdwood@gmail.com> - Felipe Balbi <balbi@ti.com> - Jingoo Han <jingoohan1@gmail.com> - Lee Jones <lee.jones@linaro.org> - Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> - Tomi Valkeinen <tomi.valkeinen@ti.com> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - linux-clk@vger.kernel.org <linux-clk@vger.kernel.org> - dmaengine@vger.kernel.org <dmaengine@vger.kernel.org> - linux-gpio@vger.kernel.org <linux-gpio@vger.kernel.org> - dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org> - linux-tegra@vger.kernel.org <linux-tegra@vger.kernel.org> - linux-i2c@vger.kernel.org <linux-i2c@vger.kernel.org> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> - Linux PWM List <linux-pwm@vger.kernel.org> - linux-usb@vger.kernel.org <linux-usb@vger.kernel.org> - " linux-fbdev@vger.kernel.org <linux-fbdev@vger.kernel.org>\0" + " Sebastian Reichel <sre@kernel.org>\0" "\00:1\0" "b\0" "Quoting Rafael J. Wysocki (2015-10-25 06:54:39)\n" "> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:\n" "> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:\n" "> >\n" - "> >> Well, I'm not quite sure why exactly everyone is so focused on probing=\n" - " here.\n" + "> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.\n" "> >\n" "> > Probe deferral is really noisy even if it's working fine on a given\n" "> > system so it's constantly being highlighted to people in a way that\n" @@ -65,13 +44,11 @@ "> > There's also the understanding people had that the order things get\n" "> > bound changes the ordering for some of the other cases (perhaps it's a\n" "> > good idea to do that, it seems likely to be sensible?).\n" - "> =\n" - "\n" + "> \n" "> But it really doesn't do that. Also making it do so doesn't help much\n" "> in the cases where things can happen asynchronously (system\n" "> suspend/resume, runtime PM).\n" - "> =\n" - "\n" + "> \n" "> If, instead, there was a way to specify a functional dependency at the\n" "> device registration time, it might be used to change the order of\n" "> everything relevant, including probe. That should help to reduce the\n" @@ -88,15 +65,13 @@ "Regards,\n" "Mike\n" "\n" - "> =\n" - "\n" + "> \n" "> If the dependency could only be discovered at the probe time, the\n" "> order of things might be changed in response to letting the driver\n" "> core know about it rather than \"just in case\", which should be more\n" "> efficient.\n" - "> =\n" - "\n" + "> \n" "> Thanks,\n" > Rafael -8a95f51a42c37e96e20907db1a16b5fd361ce3eca0cfd3ea467837fa58679245 +1ee4e8d54d8c6dccaa2a5fb14666f3eaf622c7587dfd7308f7621f9e22370e8a
diff --git a/a/1.txt b/N2/1.txt index 0865630..02a4b56 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -2,8 +2,7 @@ Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > -> >> Well, I'm not quite sure why exactly everyone is so focused on probing= - here. +> >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that @@ -12,13 +11,11 @@ Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). -> = - +> > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). -> = - +> > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the @@ -35,13 +32,11 @@ boots sounds interesting to me. Regards, Mike -> = - +> > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. -> = - +> > Thanks, > Rafael diff --git a/a/content_digest b/N2/content_digest index a34a85f..0aa47f7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -28,35 +28,14 @@ Wolfram Sang <wsa@the-dreams.de> Grant Likely <grant.likely@linaro.org> Kishon Vijay Abraham I <kishon@ti.com> - Sebastian Reichel <sre@kernel.org> - Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> - David Woodhouse <dwmw2@infradead.org> - Liam Girdwood <lgirdwood@gmail.com> - Felipe Balbi <balbi@ti.com> - Jingoo Han <jingoohan1@gmail.com> - Lee Jones <lee.jones@linaro.org> - Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> - Tomi Valkeinen <tomi.valkeinen@ti.com> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - linux-clk@vger.kernel.org <linux-clk@vger.kernel.org> - dmaengine@vger.kernel.org <dmaengine@vger.kernel.org> - linux-gpio@vger.kernel.org <linux-gpio@vger.kernel.org> - dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org> - linux-tegra@vger.kernel.org <linux-tegra@vger.kernel.org> - linux-i2c@vger.kernel.org <linux-i2c@vger.kernel.org> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> - Linux PWM List <linux-pwm@vger.kernel.org> - linux-usb@vger.kernel.org <linux-usb@vger.kernel.org> - " linux-fbdev@vger.kernel.org <linux-fbdev@vger.kernel.org>\0" + " Sebastian Reichel <sre@kernel.org>\0" "\00:1\0" "b\0" "Quoting Rafael J. Wysocki (2015-10-25 06:54:39)\n" "> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:\n" "> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:\n" "> >\n" - "> >> Well, I'm not quite sure why exactly everyone is so focused on probing=\n" - " here.\n" + "> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.\n" "> >\n" "> > Probe deferral is really noisy even if it's working fine on a given\n" "> > system so it's constantly being highlighted to people in a way that\n" @@ -65,13 +44,11 @@ "> > There's also the understanding people had that the order things get\n" "> > bound changes the ordering for some of the other cases (perhaps it's a\n" "> > good idea to do that, it seems likely to be sensible?).\n" - "> =\n" - "\n" + "> \n" "> But it really doesn't do that. Also making it do so doesn't help much\n" "> in the cases where things can happen asynchronously (system\n" "> suspend/resume, runtime PM).\n" - "> =\n" - "\n" + "> \n" "> If, instead, there was a way to specify a functional dependency at the\n" "> device registration time, it might be used to change the order of\n" "> everything relevant, including probe. That should help to reduce the\n" @@ -88,15 +65,13 @@ "Regards,\n" "Mike\n" "\n" - "> =\n" - "\n" + "> \n" "> If the dependency could only be discovered at the probe time, the\n" "> order of things might be changed in response to letting the driver\n" "> core know about it rather than \"just in case\", which should be more\n" "> efficient.\n" - "> =\n" - "\n" + "> \n" "> Thanks,\n" > Rafael -8a95f51a42c37e96e20907db1a16b5fd361ce3eca0cfd3ea467837fa58679245 +968b72796153607a0cd2f00c64054557dde21a37dec67c1ab5b915ebde6aaf08
diff --git a/a/1.txt b/N3/1.txt index 0865630..02a4b56 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -2,8 +2,7 @@ Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > -> >> Well, I'm not quite sure why exactly everyone is so focused on probing= - here. +> >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that @@ -12,13 +11,11 @@ Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). -> = - +> > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). -> = - +> > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the @@ -35,13 +32,11 @@ boots sounds interesting to me. Regards, Mike -> = - +> > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. -> = - +> > Thanks, > Rafael diff --git a/a/content_digest b/N3/content_digest index a34a85f..2ff7632 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -55,8 +55,7 @@ "> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:\n" "> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:\n" "> >\n" - "> >> Well, I'm not quite sure why exactly everyone is so focused on probing=\n" - " here.\n" + "> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.\n" "> >\n" "> > Probe deferral is really noisy even if it's working fine on a given\n" "> > system so it's constantly being highlighted to people in a way that\n" @@ -65,13 +64,11 @@ "> > There's also the understanding people had that the order things get\n" "> > bound changes the ordering for some of the other cases (perhaps it's a\n" "> > good idea to do that, it seems likely to be sensible?).\n" - "> =\n" - "\n" + "> \n" "> But it really doesn't do that. Also making it do so doesn't help much\n" "> in the cases where things can happen asynchronously (system\n" "> suspend/resume, runtime PM).\n" - "> =\n" - "\n" + "> \n" "> If, instead, there was a way to specify a functional dependency at the\n" "> device registration time, it might be used to change the order of\n" "> everything relevant, including probe. That should help to reduce the\n" @@ -88,15 +85,13 @@ "Regards,\n" "Mike\n" "\n" - "> =\n" - "\n" + "> \n" "> If the dependency could only be discovered at the probe time, the\n" "> order of things might be changed in response to letting the driver\n" "> core know about it rather than \"just in case\", which should be more\n" "> efficient.\n" - "> =\n" - "\n" + "> \n" "> Thanks,\n" > Rafael -8a95f51a42c37e96e20907db1a16b5fd361ce3eca0cfd3ea467837fa58679245 +b0defcfabecee5d854951b89d85be09871481b98ec0dfec23948e04cd271fa39
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.