On 10/28, Mark Brown wrote:
> On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote:
> > On 23-10-15, 01:39, Mark Brown wrote:
>
> > > I'm not sure that's
> > > a place we want to end up just yet, I think it's safer to just have a
> > > little bit of code in the kernel that glues things
On 10/28, Mark Brown wrote:
> On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote:
> > On 23-10-15, 01:39, Mark Brown wrote:
>
> > > I'm not sure that's
> > > a place we want to end up just yet, I think it's safer to just have a
> > > little bit of code in the kernel that glues things
On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote:
> On 23-10-15, 01:39, Mark Brown wrote:
> > I'm not sure that's
> > a place we want to end up just yet, I think it's safer to just have a
> > little bit of code in the kernel that glues things together in the cases
> > where this is
On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote:
> On 23-10-15, 01:39, Mark Brown wrote:
> > I'm not sure that's
> > a place we want to end up just yet, I think it's safer to just have a
> > little bit of code in the kernel that glues things together in the cases
> > where this is
On 23-10-15, 01:39, Mark Brown wrote:
> When we start doing this we also start having to worry about things like
> the sequencing of the updates between the various supplies and end up in
> full on power sequencing (or at least baking some sequencing into the DT
> which will doubtless need
On 23-10-15, 01:39, Mark Brown wrote:
> When we start doing this we also start having to worry about things like
> the sequencing of the updates between the various supplies and end up in
> full on power sequencing (or at least baking some sequencing into the DT
> which will doubtless need
On Sat, Oct 17, 2015 at 09:40:55AM +0530, Viresh Kumar wrote:
> Okay here is the problem statement:
> We have two supplies for a device and the device node will have
> something like:
> name1-supply = <>;
> name2-supply = <>;
> And the OPP node needs to have voltages for both of them:
>
On Fri, Sep 11, 2015 at 05:31:57PM +0530, Viresh Kumar wrote:
> +- supply-names: This is a required property, only if multiple supplies are
> + available for the device. Otherwise it is optional.
> +
> + This list is used to pass names of all the device supplies. The order of
> names
> +
On Fri, Sep 11, 2015 at 05:31:57PM +0530, Viresh Kumar wrote:
> +- supply-names: This is a required property, only if multiple supplies are
> + available for the device. Otherwise it is optional.
> +
> + This list is used to pass names of all the device supplies. The order of
> names
> +
On Sat, Oct 17, 2015 at 09:40:55AM +0530, Viresh Kumar wrote:
> Okay here is the problem statement:
> We have two supplies for a device and the device node will have
> something like:
> name1-supply = <>;
> name2-supply = <>;
> And the OPP node needs to have voltages for both of them:
>
On 17-10-15, 09:40, Viresh Kumar wrote:
> Hehe, no.
>
> Okay here is the problem statement:
>
> We have two supplies for a device and the device node will have
> something like:
>
> name1-supply = <>;
> name2-supply = <>;
>
> And the OPP node needs to have voltages for both of them:
>
>
On 17-10-15, 09:40, Viresh Kumar wrote:
> Hehe, no.
>
> Okay here is the problem statement:
>
> We have two supplies for a device and the device node will have
> something like:
>
> name1-supply = <>;
> name2-supply = <>;
>
> And the OPP node needs to have voltages for both of them:
>
>
On 16-10-15, 12:16, Stephen Boyd wrote:
> On 10/16, Viresh Kumar wrote:
> > On 15-10-15, 17:22, Stephen Boyd wrote:
> > > I'm lost why we need this property at all. What happened to using
> > >
> > > opp-microvolt-0 = <1 2 3>;
> > > opp-microvolt-1 = <1>;
> > > opp-microvolt-2 = <3 4 5>;
> > >
On 10/16, Viresh Kumar wrote:
> On 15-10-15, 17:22, Stephen Boyd wrote:
> > I'm lost why we need this property at all. What happened to using
> >
> > opp-microvolt-0 = <1 2 3>;
> > opp-microvolt-1 = <1>;
> > opp-microvolt-2 = <3 4 5>;
> > etc.
>
> Perhaps you are confusing this with the
On 15-10-15, 17:22, Stephen Boyd wrote:
> I'm lost why we need this property at all. What happened to using
>
> opp-microvolt-0 = <1 2 3>;
> opp-microvolt-1 = <1>;
> opp-microvolt-2 = <3 4 5>;
> etc.
Perhaps you are confusing this with the bindings we came up for
picking right voltage levels
On 10/16, Viresh Kumar wrote:
> On 15-10-15, 17:22, Stephen Boyd wrote:
> > I'm lost why we need this property at all. What happened to using
> >
> > opp-microvolt-0 = <1 2 3>;
> > opp-microvolt-1 = <1>;
> > opp-microvolt-2 = <3 4 5>;
> > etc.
>
> Perhaps you are confusing this with the
On 15-10-15, 17:22, Stephen Boyd wrote:
> I'm lost why we need this property at all. What happened to using
>
> opp-microvolt-0 = <1 2 3>;
> opp-microvolt-1 = <1>;
> opp-microvolt-2 = <3 4 5>;
> etc.
Perhaps you are confusing this with the bindings we came up for
picking right voltage levels
On 16-10-15, 12:16, Stephen Boyd wrote:
> On 10/16, Viresh Kumar wrote:
> > On 15-10-15, 17:22, Stephen Boyd wrote:
> > > I'm lost why we need this property at all. What happened to using
> > >
> > > opp-microvolt-0 = <1 2 3>;
> > > opp-microvolt-1 = <1>;
> > > opp-microvolt-2 = <3 4 5>;
> > >
On 09/14, Rob Herring wrote:
> On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> > Regulators already have stable DT bindings, wherein the consumer (of
> > supplies) will have following for each regulator/supply.
> >
> > -supply: ;
> >
> > Current OPP bindings extend above, by transforming it into a
On 09/14, Rob Herring wrote:
> On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> > Regulators already have stable DT bindings, wherein the consumer (of
> > supplies) will have following for each regulator/supply.
> >
> > -supply: ;
> >
> > Current OPP bindings extend above, by transforming it into a
Rob,
On 15-09-15, 08:17, Viresh Kumar wrote:
> On 14-09-15, 15:22, Rob Herring wrote:
> > What if we have a 2nd device and supply rail? For example, what if the
> > L2$ has a separate rail from the cores but is linked to the OPPs.
>
> Right, so that is the case with the Mediatek SoC as well,
Rob,
On 15-09-15, 08:17, Viresh Kumar wrote:
> On 14-09-15, 15:22, Rob Herring wrote:
> > What if we have a 2nd device and supply rail? For example, what if the
> > L2$ has a separate rail from the cores but is linked to the OPPs.
>
> Right, so that is the case with the Mediatek SoC as well,
On 14-09-15, 15:22, Rob Herring wrote:
> What if we have a 2nd device and supply rail? For example, what if the
> L2$ has a separate rail from the cores but is linked to the OPPs.
Right, so that is the case with the Mediatek SoC as well, AFAIR. How
do we plan to treat L2 devices? For example, in
On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> Regulators already have stable DT bindings, wherein the consumer (of
> supplies) will have following for each regulator/supply.
>
> -supply: ;
>
> Current OPP bindings extend above, by transforming it into a list of
> phandles. But we missed the
On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> Regulators already have stable DT bindings, wherein the consumer (of
> supplies) will have following for each regulator/supply.
>
> -supply: ;
>
> Current OPP bindings extend above, by transforming it into a list of
> phandles. But we missed the
On 14-09-15, 15:22, Rob Herring wrote:
> What if we have a 2nd device and supply rail? For example, what if the
> L2$ has a separate rail from the cores but is linked to the OPPs.
Right, so that is the case with the Mediatek SoC as well, AFAIR. How
do we plan to treat L2 devices? For example, in
Regulators already have stable DT bindings, wherein the consumer (of
supplies) will have following for each regulator/supply.
-supply: ;
Current OPP bindings extend above, by transforming it into a list of
phandles. But we missed the string, which is used to identify the
regulator.
And looking
Regulators already have stable DT bindings, wherein the consumer (of
supplies) will have following for each regulator/supply.
-supply: ;
Current OPP bindings extend above, by transforming it into a list of
phandles. But we missed the string, which is used to identify the
regulator.
And looking
28 matches
Mail list logo
