diff for duplicates of <1491562312.9365.41.camel@nxp.com> diff --git a/a/1.txt b/N1/1.txt index 21be825..6b6e60e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,7 +4,7 @@ On Thu, 2017-04-06 at 19:52 +0100, Mark Brown wrote: > > > To repeat what I said previously the whole point of bypassing is to not > > > do regulation and generally the constraints in the unregulated idle case -> > > are substantially more relaxed. This would break use cases relying on +> > > are substantially more relaxed.??This would break use cases relying on > > > the existing behaviour which wouldn't expect to affect the parent > > > voltage at all, either stopping things working or making them less > > > efficient by needlessly regulating the voltage down which defeats the @@ -16,7 +16,7 @@ On Thu, 2017-04-06 at 19:52 +0100, Mark Brown wrote: > So your end goal here is to bypass a regulator which is forced into your > system design by being integrated into the SoC which isn't able to -> regulate down to a low enough voltage for your use case? I guess one +> regulate down to a low enough voltage for your use case???I guess one > question is if you need to use the regulator at all? Both the PMIC and the LDOs can provide the required voltage range. LDO @@ -39,7 +39,7 @@ not clear if it's entirely intentional. > > regulator need not be respected by the core. I expected the opposite, > > this is something that should be documented. -> SubmittingPatches... Bear in mind that most regulators are fixed +> SubmittingPatches...??Bear in mind that most regulators are fixed > voltage in a given system so bypass would be very difficult to use if it > tried to pass the constraints upstream. @@ -82,15 +82,10 @@ Ok, I will try that approach instead. > Another option would be to add a regulator configuration which allowed > the regulator to transparently go into bypass mode if the parent could > do things directly, only enabling regulation if the parent couldn't -> support. That would mean you'd loose the supply cleanup function which +> support.??That would mean you'd loose the supply cleanup function which > is typically part of why there are LDOs in the system but it sounds like > you're OK with that in at least your use case. Dynamic enabling of bypass mode in the core seems very complex and not terribly useful for my case. I pretty much want them always in bypass or always enabled. - --- -To unsubscribe from this list: send the line "unsubscribe devicetree" in -the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index d6d2919..032fe93 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,27 +5,10 @@ "ref\020170328164754.z2c2ttovs3sxbcos@sirena.org.uk\0" "ref\01490730595.15830.1.camel@nxp.com\0" "ref\020170406185202.uixxcv3dgucrddgc@sirena.org.uk\0" - "ref\020170406185202.uixxcv3dgucrddgc-GFdadSzt00ze9xe1eoZjHA@public.gmane.org\0" - "From\0Leonard Crestez <leonard.crestez-3arQi8VN3Tc@public.gmane.org>\0" - "Subject\0Re: [RFC 4/8] regulator: core: Check enabling bypass respects constraints\0" + "From\0leonard.crestez@nxp.com (Leonard Crestez)\0" + "Subject\0[RFC 4/8] regulator: core: Check enabling bypass respects constraints\0" "Date\0Fri, 7 Apr 2017 13:51:52 +0300\0" - "To\0Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\0" - "Cc\0Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>" - Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> - Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> - Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - Robin Gong <yibin.gong-3arQi8VN3Tc@public.gmane.org> - Anson Huang <Anson.Huang-3arQi8VN3Tc@public.gmane.org> - Irina Tirdea <irina.tirdea-3arQi8VN3Tc@public.gmane.org> - Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> - Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org> - Octavian Purdila <octavian.purdila-3arQi8VN3Tc@public.gmane.org> - linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - " linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Thu, 2017-04-06 at 19:52 +0100, Mark Brown wrote:\n" @@ -34,7 +17,7 @@ "\n" "> > > To repeat what I said previously the whole point of bypassing is to not\n" "> > > do regulation and generally the constraints in the unregulated idle case\n" - "> > > are substantially more relaxed.\302\240\302\240This would break use cases relying on\n" + "> > > are substantially more relaxed.??This would break use cases relying on\n" "> > > the existing behaviour which wouldn't expect to affect the parent\n" "> > > voltage at all, either stopping things working or making them less\n" "> > > efficient by needlessly regulating the voltage down which defeats the\n" @@ -46,7 +29,7 @@ "\n" "> So your end goal here is to bypass a regulator which is forced into your\n" "> system design by being integrated into the SoC which isn't able to\n" - "> regulate down to a low enough voltage for your use case?\302\240\302\240I guess one\n" + "> regulate down to a low enough voltage for your use case???I guess one\n" "> question is if you need to use the regulator at all?\n" "\n" "Both the PMIC and the LDOs can provide the required voltage range. LDO\n" @@ -69,7 +52,7 @@ "> > regulator need not be respected by the core. I expected the opposite,\n" "> > this is something that should be documented.\n" "\n" - "> SubmittingPatches...\302\240\302\240Bear in mind that most regulators are fixed\n" + "> SubmittingPatches...??Bear in mind that most regulators are fixed\n" "> voltage in a given system so bypass would be very difficult to use if it\n" "> tried to pass the constraints upstream.\n" "\n" @@ -112,17 +95,12 @@ "> Another option would be to add a regulator configuration which allowed\n" "> the regulator to transparently go into bypass mode if the parent could\n" "> do things directly, only enabling regulation if the parent couldn't\n" - "> support.\302\240\302\240That would mean you'd loose the supply cleanup function which\n" + "> support.??That would mean you'd loose the supply cleanup function which\n" "> is typically part of why there are LDOs in the system but it sounds like\n" "> you're OK with that in at least your use case.\n" "\n" "Dynamic enabling of bypass mode in the core seems very complex and not\n" "terribly useful for my case. I pretty much want them always in bypass\n" - "or always enabled.\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe devicetree\" in\n" - "the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + or always enabled. -de1ce48a6355e79ffadfb488c8d3c3989dc6c7ef12f348c57c9da92523e99c55 +dbf9d58ee032cda84444ef94b57434f4e4cf18f8a08c93e24711c4bae2392a56
diff --git a/a/1.txt b/N2/1.txt index 21be825..0d1923b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -89,8 +89,3 @@ Ok, I will try that approach instead. Dynamic enabling of bypass mode in the core seems very complex and not terribly useful for my case. I pretty much want them always in bypass or always enabled. - --- -To unsubscribe from this list: send the line "unsubscribe devicetree" in -the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index d6d2919..d17241c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -5,27 +5,26 @@ "ref\020170328164754.z2c2ttovs3sxbcos@sirena.org.uk\0" "ref\01490730595.15830.1.camel@nxp.com\0" "ref\020170406185202.uixxcv3dgucrddgc@sirena.org.uk\0" - "ref\020170406185202.uixxcv3dgucrddgc-GFdadSzt00ze9xe1eoZjHA@public.gmane.org\0" - "From\0Leonard Crestez <leonard.crestez-3arQi8VN3Tc@public.gmane.org>\0" + "From\0Leonard Crestez <leonard.crestez@nxp.com>\0" "Subject\0Re: [RFC 4/8] regulator: core: Check enabling bypass respects constraints\0" "Date\0Fri, 7 Apr 2017 13:51:52 +0300\0" - "To\0Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\0" - "Cc\0Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>" - Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> - Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> - Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - Robin Gong <yibin.gong-3arQi8VN3Tc@public.gmane.org> - Anson Huang <Anson.Huang-3arQi8VN3Tc@public.gmane.org> - Irina Tirdea <irina.tirdea-3arQi8VN3Tc@public.gmane.org> - Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> - Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org> - Octavian Purdila <octavian.purdila-3arQi8VN3Tc@public.gmane.org> - linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - " linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\0" + "To\0Mark Brown <broonie@kernel.org>\0" + "Cc\0Sascha Hauer <kernel@pengutronix.de>" + Liam Girdwood <lgirdwood@gmail.com> + Viresh Kumar <viresh.kumar@linaro.org> + Rafael J. Wysocki <rjw@rjwysocki.net> + Shawn Guo <shawnguo@kernel.org> + Robin Gong <yibin.gong@nxp.com> + Anson Huang <Anson.Huang@nxp.com> + Irina Tirdea <irina.tirdea@nxp.com> + Rob Herring <robh+dt@kernel.org> + Mark Rutland <mark.rutland@arm.com> + Fabio Estevam <fabio.estevam@nxp.com> + Octavian Purdila <octavian.purdila@nxp.com> + <linux-pm@vger.kernel.org> + <linux-arm-kernel@lists.infradead.org> + <devicetree@vger.kernel.org> + " <linux-kernel@vger.kernel.org>\0" "\00:1\0" "b\0" "On Thu, 2017-04-06 at 19:52 +0100, Mark Brown wrote:\n" @@ -118,11 +117,6 @@ "\n" "Dynamic enabling of bypass mode in the core seems very complex and not\n" "terribly useful for my case. I pretty much want them always in bypass\n" - "or always enabled.\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe devicetree\" in\n" - "the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + or always enabled. -de1ce48a6355e79ffadfb488c8d3c3989dc6c7ef12f348c57c9da92523e99c55 +d341365abbcf5b05f9fa772fa144c2108dc56dc68982cfc268344c127c959e2a
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.