All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-pm@vger.kernel.org, Dmitry Osipenko <digetx@gmail.com>
Subject: Re: opp: How to use multiple opp-supported-hw versions properly?
Date: Tue, 25 Aug 2020 10:57:40 +0200	[thread overview]
Message-ID: <20200825085740.GA855@gerhold.net> (raw)
In-Reply-To: <20200825081637.opfmtccwczn6jtlo@vireshk-i7>

On Tue, Aug 25, 2020 at 01:46:37PM +0530, Viresh Kumar wrote:
> On 25-08-20, 09:44, Stephan Gerhold wrote:
> > Hi Viresh,
> > 
> > (an unrelated questions while I investigate the device links ;) )
> > 
> > I'm a bit confused about how to use "opp-supported-hw" properly
> > when you have multiple versions defined.
> 
> Documentation/devicetree/bindings/opp/opp.txt gives some explanation which I
> thought should be enough, maybe it isn't :(
> 
> Or maybe I am oversimplifying your problem and I myself have forgotten this
> property and its usage :)
> 
> > In my case I have two version numbers from 0-7, so theoretically up to
> > 64 versions. This does not fit into a single version mask
> 
> I don't think this is correct. The opp-supported-hw property must be thought of
> as a bitfield where each bit represents a version.
> 
> In your case a single 32 bit value should be enough IMO.
> 

I took this from Documentation/devicetree/bindings/opp/opp.txt:

"Each level of hierarchy is represented by a 32 bit value, and so there
 can be only 32 different supported version per hierarchy. i.e. 1 bit
 per version. A value of 0xFFFFFFFF will enable the OPP for all versions
 for that hierarchy level. And a value of 0x00000000 will disable the
 OPP completely, and so we never want that to happen."

Also:

"If 32 values aren't sufficient for a version hierarchy, than that
 version hierarchy can be contained in multiple 32 bit values. i.e.
 <X Y Z1 Z2> in the above example, Z1 & Z2 refer to the version
 hierarchy Z."

but it doesn't mention anything about the problem I described
("conflicting" ranges for one of the "sub-versions").

> <0x00FF00FF>, here each FF can support upto 8 versions, which is exactly what
> you need. Now if you want to support version 3-3 (where version are numbered
> from 0-7) for an OPP, you set this value to: <0x00080008>
> 
> Does that make sense ?
> 

I have to admit that I keep getting confused with these bit masks...
I think this is also one option I considered but actually it doesn't
work:

Essentially you suggest to encode a version using:

static int ver(int version1, int version2) {
	return BIT(version1) << 16 | BIT(version2);
}

Now let's take a look at my example again:

> > Now let's say I want to limit an OPP to v0.1, v1.0 and v1.1, but not
> > v0.0. With a single "opp-supported-hw" I think I can only say:
> > 
> > 	opp-supported-hw = <0x3 0x3>;
> > 
> > but that does also include v0.0...
> > I think to exclude that I would need multiple version ranges, e.g.
> > 
> > 	opp-supported-hw = <0x1 0x2>, <0x2 0x3>;
> > 
> > This does not seem to be supported, though.
> > 

So for the versions I mentioned we get:
  - ver(0, 1) = 0x10002
  - ver(1, 0) = 0x20001
  - ver(1, 1) = 0x20002
  - ver(0, 0) = 0x10001 (this one should be excluded)

So to mark v0.1, v1.0 and v1.1 as supported I'd set:
     opp-supported-hw = <(ver(0, 1) | ver(1, 0) | ver(1, 1))>;
i.e. opp-supported-hw = <0x30003>;

Now let's say I'm running v0.0 = 0x10001. This version should not
support the OPP. But actually 0x30003 & 0x10001 = 0x10001 != 0,
so the OPP would consider it as supported.

I tried many different approaches, but you end up being unable to
control subversions independently for most of them.

But as I mentioned I keep getting really confused with these bitmasks,
so maybe I'm wrong :)

Thanks!
Stephan

  reply	other threads:[~2020-08-25  8:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25  7:44 opp: How to use multiple opp-supported-hw versions properly? Stephan Gerhold
2020-08-25  8:16 ` Viresh Kumar
2020-08-25  8:57   ` Stephan Gerhold [this message]
2020-08-25  9:56     ` Viresh Kumar
2020-08-25 10:35       ` Stephan Gerhold
2020-08-26 11:51         ` Viresh Kumar
2020-08-25 10:59   ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200825085740.GA855@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=digetx@gmail.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=sboyd@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vireshk@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.