On 1/24/2024 6:04 AM, Sudeep Holla wrote:
On Wed, Jan 24, 2024 at 02:38:54PM +0100, Vincent Guittot wrote:
On Wed, 24 Jan 2024 at 14:17, Nikunj Kela <quic_nkela@xxxxxxxxxxx> wrote:
On 1/24/2024 4:48 AM, Sudeep Holla wrote:
On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote:
On 1/24/2024 3:02 AM, Sudeep Holla wrote:
Not really, still puzzled may be more than before as I don't understand
what is going on with the approach as it seem to be deviating from my
initial understanding.
May be take an example of one driver, present the DT binding and driver
changes to make sure there is no misunderstanding from my side. But I am
not convinced with the explanation so far.
Hi Sudeep,
We are not using clock protocol to deal with clocks individually. We are
trying to define different perf domains for peripherals where we are
grouping clocks/regulators/interconnect bandwidth into these perf domains
and use OPP levels via SCMI perf protocol.
That clarifies on what you are trying to achieve.
This is done so as to avoid individual scmi calls for these resources
hence avoiding any race conditions and minimizing the traffic between SCMI
client and server to get better KPIs.
Fair enough, why can't you just use genpd perf APIs to achieve that ?
OPP is built on top of genpd perf only and was recommended by Ulf(PM
maintainer from Linaro) hence we decided to use OPP APIs instead of
directly genpd perf API.
This is being planned for sa8775p platform and any subsequent platforms will
use the same approach. The idea of using perf protocol for peripherals is
new and Qualcomm is first one trying to use that.
Sure.
Therefore existing peripheral drivers will require a way to distinguish between the
two different configurations. Hope this provides little more context and
insight.
While I agree this is new, use custom APIs to control standard resources
is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom
API calls in qcom specific drivers. But what if this is needed in some
generic IP driver. Just not scalable and why should the maintainer of
such driver accept you custom API.
Apologies if it wasn't clear but we are not using custom APIs. We are
using standard OPP APIs to set to opp level of the perf domain.
Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM
framework maintainers recommendation to use OPP.
So I would suggest to work towards using std framework APIs or create one
if you can justify the need for it. Please stop creating custom APIs for
using SCMI. It defeats the whole standardisation it is meant to provide.
Not sure I understand what you refer to as custom APIs here. The OPP
APIs are not custom APIs. They are from OPP framework built on top of
genpd perf. [1] and [2] patch series might provide you more insight into
the work that Ulf did to support SCMI perf with OPP framework.
I think that you are speaking about the same thing. They plan to use
SCMI power domain for idle states and SCMI performance domain for
setting a performance mode. Then, the OPP library is used on top of
perf domain to gather and manipulate the different perf levels.
Indeed, I just realise that after Nikunj's last email. Earlier to that,
it was not so clear and it sounded like some custom way. Anyways I am still
not convinced if this is something drivers need to handle with explicit
DT support for this distinction in particular.
Let me try another shot to convince you :) Currently, driver is dealing
with clocks and regulators using individual framework APIs(e.g.
set_clk_rate, regulator_set_voltage etc.). With defining perf to group
them in OPP APIs, we need to now use set_opp. Therefore the driver needs
to change to use OPP framework APIs instead of clocks/regulator APIs
hence this query on how to distinguish the two configuration even though
the hardware is same.
