devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	devicetree@vger.kernel.org, sudeep.holla@arm.com,
	rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org,
	sboyd@kernel.org, nm@ti.com, daniel.lezcano@linaro.org,
	morten.rasmussen@arm.com, chris.redpath@arm.com
Subject: Re: [PATCH v3 2/3] opp/of: Allow empty opp-table with opp-shared
Date: Thu, 5 Nov 2020 10:11:18 +0530	[thread overview]
Message-ID: <20201105044118.k75um7gcz3ffkphc@vireshk-i7> (raw)
In-Reply-To: <9f442724-df13-d582-717d-535cc9c9c9f1@arm.com>

On 04-11-20, 17:54, Nicola Mazzucato wrote:
> Initially I thought to place a comment right there but I ended up with an
> explanation of this case at the top of this function (the corner-case). It
> probably also needs more details..

I read it earlier as well but yeah, that wasn't good enough for me to
understand what you are doing.

> Basically, on this case - empty opp table & opp-shared - we limit the scope of
> opp-shared to *only* tell us about hw description, and not marking the opp
> points as shared, since they are not present in DT.

It doesn't matter where the OPP table entries are coming from. The OPP
table should be marked shared if it is found to be shared.

> It would be the equivalent
> of describing that devices share clock/voltage lines, but we can't tell anything
> about opp points cause they are not there (in DT).

Its okay, even then we should set the right flags here. It is really
confusing that we blindly set it as exclusive, even though it may be
shared.

> OTOH If we don't set shared_opp to OPP_TABLE_ACCESS_EXCLUSIVE for that specific
> case, we won't be able to add opps for the remaining cpus as the opp core
> will find the opps as duplicated. This is a corner case, really.

Hmm, I am not sure where you fail and how but this should be set to
OPP_TABLE_ACCESS_EXCLUSIVE only if the OPP table isn't shared. else it
should be OPP_TABLE_ACCESS_SHARED.

-- 
viresh

  reply	other threads:[~2020-11-05  4:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 12:01 [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies Nicola Mazzucato
2020-11-02 12:01 ` [PATCH v3 1/3] dt-bindings/opp: Update documentation for opp-shared Nicola Mazzucato
2020-11-02 12:01 ` [PATCH v3 2/3] opp/of: Allow empty opp-table with opp-shared Nicola Mazzucato
2020-11-03  5:01   ` Viresh Kumar
2020-11-04 17:54     ` Nicola Mazzucato
2020-11-05  4:41       ` Viresh Kumar [this message]
2020-11-16 11:45         ` Nicola Mazzucato
2020-11-02 12:01 ` [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies Nicola Mazzucato
2020-11-06  9:20   ` Viresh Kumar
2020-11-06 10:37     ` Lukasz Luba
2020-11-06 10:55       ` Viresh Kumar
2020-11-06 11:14         ` Lukasz Luba
2020-11-09  6:57           ` Viresh Kumar
2020-11-16 11:33             ` Lukasz Luba
2020-11-17 10:11               ` Viresh Kumar
2020-11-17 10:47                 ` Nicola Mazzucato
2020-11-17 10:53                   ` Viresh Kumar
2020-11-17 13:06                     ` Rafael J. Wysocki
2020-11-18  4:42                       ` Viresh Kumar
2020-11-18 12:00                         ` Rafael J. Wysocki
2020-11-19  6:40                           ` Viresh Kumar
2020-11-17 10:47                 ` Lukasz Luba
2020-11-17 10:55                   ` Viresh Kumar
2020-11-06  9:24   ` Viresh Kumar
2020-11-19  6:43   ` Viresh Kumar
2020-11-03 10:18 ` [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies Viresh Kumar
2020-11-04 18:04   ` Nicola Mazzucato
2020-11-05 14:25     ` Vincent Guittot
2020-11-05 15:46       ` Ionela Voinescu

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=20201105044118.k75um7gcz3ffkphc@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=chris.redpath@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=nicola.mazzucato@arm.com \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sudeep.holla@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).