From: Rajendra Nayak <rnayak@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Sibi Sankar <sibis@codeaurora.org>,
sboyd@kernel.org, georgi.djakov@linaro.org, saravanak@google.com,
nm@ti.com, bjorn.andersson@linaro.org, agross@kernel.org,
david.brown@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com,
rjw@rjwysocki.net, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, dianders@chromium.org,
mka@chromium.org, vincent.guittot@linaro.org,
amit.kucheria@linaro.org, ulf.hansson@linaro.org,
linux-kernel-owner@vger.kernel.org
Subject: Re: [RFC v3 00/10] DDR/L3 Scaling support on SDM845 and SC7180 SoCs
Date: Thu, 19 Mar 2020 17:03:18 +0530 [thread overview]
Message-ID: <53065b03-22d5-fb78-aa6f-e4711b8ffd3b@codeaurora.org> (raw)
In-Reply-To: <20200319110805.glmuc2qvgcei3mon@vireshk-i7>
On 3/19/2020 4:38 PM, Viresh Kumar wrote:
> On 19-03-20, 16:23, Rajendra Nayak wrote:
>>
>>
>> On 3/19/2020 3:54 PM, Viresh Kumar wrote:
>> I thought this series indeed is proposing to add that support in OPP core?
>> a.k.a "[RFC v3 06/10] opp: Allow multiple opp_tables to be mapped to a single device"
>>
>> These discussions are stalled for over 2 months now waiting on a response from Saravana.
>> Viresh, whats the way forward here and how long do we plan on waiting for Saravanas response?
>
> I agree and I am equally worried about it. So lets clear the air a bit
> first. Can someone answer following :
>
> - This series depends on the series from Saravana ? Right, so that
> needs to get merged/accepted first ?
>
> - If yes, then what is the way forward as Saravana isn't responding
> right now ..
sure, I understand there is a dependency, however refusing to review the approach
(to add multiple OPPS tables per device) that this series is taking because of an outstanding
question which, if I read it right is "We can not add multiple OPP tables for a single device right now"
seems odd.
Its fine if you are not happy with the approach taken here and you can propose something else,
but it looks inevitable that we would need something like this to be supported (multiple OPP tables per device)
and hence the request to review the patches.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2020-03-19 11:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-27 20:03 [RFC v3 00/10] DDR/L3 Scaling support on SDM845 and SC7180 SoCs Sibi Sankar
2020-01-27 20:03 ` [RFC v3 01/10] arm64: dts: qcom: sdm845: Add SoC compatible to MTP Sibi Sankar
2020-01-28 20:40 ` Matthias Kaehlcke
2020-01-29 13:45 ` Sibi Sankar
2020-01-27 20:03 ` [RFC v3 02/10] cpufreq: blacklist SDM845 in cpufreq-dt-platdev Sibi Sankar
2020-01-28 20:44 ` Matthias Kaehlcke
2020-01-29 13:46 ` Sibi Sankar
2020-01-30 11:40 ` Sudeep Holla
2020-02-01 12:21 ` Sibi Sankar
2020-01-27 20:03 ` [RFC v3 03/10] cpufreq: blacklist SC7180 " Sibi Sankar
2020-01-28 20:45 ` Matthias Kaehlcke
2020-01-27 20:03 ` [RFC v3 04/10] OPP: Add and export helper to update voltage Sibi Sankar
2020-01-28 21:33 ` Matthias Kaehlcke
2020-01-29 13:49 ` Sibi Sankar
2020-01-27 20:03 ` [RFC v3 05/10] opp: of: export _opp_of_get_opp_desc_node Sibi Sankar
2020-01-27 20:03 ` [RFC v3 06/10] opp: Allow multiple opp_tables to be mapped to a single device Sibi Sankar
2020-01-27 20:03 ` [RFC v3 07/10] opp: Remove multiple attached opp tables from a device Sibi Sankar
2020-01-27 20:03 ` [RFC v3 08/10] cpufreq: qcom: Update the bandwidth levels on frequency change Sibi Sankar
2020-01-29 9:35 ` Lukasz Luba
2020-01-29 14:27 ` Sibi Sankar
2020-01-27 20:03 ` [RFC v3 09/10] arm64: dts: qcom: sdm845: Add cpu OPP tables Sibi Sankar
2020-01-29 1:24 ` Matthias Kaehlcke
2020-01-29 14:05 ` Sibi Sankar
2020-01-29 18:18 ` Matthias Kaehlcke
2020-01-27 20:03 ` [RFC v3 10/10] arm64: dts: qcom: sc7180: " Sibi Sankar
2020-01-29 2:54 ` [RFC v3 00/10] DDR/L3 Scaling support on SDM845 and SC7180 SoCs Rob Clark
2020-01-29 14:21 ` Sibi Sankar
2020-01-29 9:46 ` Lukasz Luba
2020-01-29 14:37 ` Sibi Sankar
2020-01-29 15:47 ` Lukasz Luba
2020-03-17 20:43 ` Sibi Sankar
2020-03-18 3:42 ` Viresh Kumar
2020-03-19 9:42 ` Rajendra Nayak
2020-03-19 10:11 ` Sibi Sankar
2020-03-19 10:24 ` Viresh Kumar
2020-03-19 10:53 ` Rajendra Nayak
2020-03-19 11:08 ` Viresh Kumar
2020-03-19 11:33 ` Rajendra Nayak [this message]
2020-03-20 8:01 ` Viresh Kumar
2020-03-19 10:57 ` Sibi Sankar
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=53065b03-22d5-fb78-aa6f-e4711b8ffd3b@codeaurora.org \
--to=rnayak@codeaurora.org \
--cc=agross@kernel.org \
--cc=amit.kucheria@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=georgi.djakov@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel-owner@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=sibis@codeaurora.org \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.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).