From: Sudeep Holla <email@example.com> To: Sibi Sankar <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, Sudeep Holla <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables Date: Wed, 5 May 2021 12:41:18 +0100 [thread overview] Message-ID: <20210505114118.idblntcldomzgmab@bogus> (raw) In-Reply-To: <firstname.lastname@example.org> On Wed, May 05, 2021 at 03:39:17PM +0530, Sibi Sankar wrote: > On 2021-05-05 14:19, Sudeep Holla wrote: [...] > > But I am not sure how this is related to the above commit anyways. > > > > > > > > I guess your main concern for breakage is ^^ commit? The original > > > design is > > > to list a super set of frequencies supported by all variants of the > > > SoC > > > along with the required DDR/L3 bandwidth values. When we run into > > > non-documented frequency we just wouldn't put in bw votes for it which > > > should be fine since the entire opp_table is optional. If this is > > > the reason > > > for the NACK I can try get it reverted with Matthias's ack. > > > > No my main concern is this platform uses "qcom-cpufreq-hw" driver and > > the > > fact that the OPPs are retrieved from the hardware lookup table > > invalidates > > whatever we have in DT. In short it will be junk and becomes obsolete. > > The table provides mapping to bandwidths which aren't available in the > firmware though. In short we do have to store the mapping somewhere i.e. a > mapping that lists all possible frequencies to its bandwidth requirements > needs to be present and using a opp table with the interconnect bw bindings > was the consensus reached. I understand and that's exactly what I had pointed out earlier when I mentioned that I had raised this concern previously. > Given that a duplicate mapping that lists all possible frequencies to bw is > inevitable I disagree, it was made inevitable by not listening to all feedback, sorry. > and Qualcomm has a way of listing all the supported frequencies for the SoC, > I feel that dt breakage in the future should be a non-concern. I don't completely understand this TBH. Also my main worry is as we move more towards abstract scale and/or index based, any addition or deletion of OPPs results in change in the index or scale. It may be dealt on absolute scale today everywhere and not a problem *today*, but it will break IMO. > Not sure why you call it junk since it solves the perf/power requirements on > SDM845/SC7180 SoCs. When it becomes obsolete it would mean that they are > better devfreq governors available upstream and that's a good reason for the > opp tables to go away. > Nope, I meant the firmware updates the OPP table underneath for whatever valid reasons it may have. > > So what I suggested before is still valid. You simply can't have static > > OPP tables in the DT for this platform. Do get some boot code to fetch > > the same from the h/w LUT and patch to the DT or figure out any other way > > to manage dynamically. > > moving the logic to boot loader doesn't magically fix your concerns though > (since it would also need a superset of available frequencies). OK that's interesting. I wanted to fetch the exact list from the hardware every time. > It will suffer from the same problems with an additional dependency on > firmware propagation in case of breakages which is something you can avoid > for the simple cpu based scaling solution. IMO the cross dependency is one part of problem and fetching the exact list of OPPs available for the CPU is another. I meant to fix the latter in boot code. The former is something I assume DT bindings deals with. > > > > So NACK still stands for static addition of OPPs to the DT as in this > > patch. > > I'll let Viresh take the call since this solution is already used on older SoCs. Sure, definitely I am just expressing my concern with NACK and I don't have the final say 😁. -- Regards, Sudeep
next prev parent reply other threads:[~2021-05-05 11:41 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-30 14:28 [PATCH 0/2] DDR/L3 Scaling support on SC7280 SoCs Sibi Sankar 2021-04-30 14:28 ` [PATCH 1/2] cpufreq: blacklist SC7280 in cpufreq-dt-platdev Sibi Sankar 2021-05-03 16:20 ` Matthias Kaehlcke 2021-04-30 14:28 ` [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables Sibi Sankar 2021-05-03 16:36 ` Matthias Kaehlcke 2021-05-04 7:05 ` Sibi Sankar 2021-05-04 14:42 ` Sudeep Holla 2021-05-04 18:25 ` Sibi Sankar 2021-05-04 19:16 ` Matthias Kaehlcke 2021-05-05 8:49 ` Sudeep Holla 2021-05-05 10:09 ` Sibi Sankar 2021-05-05 11:41 ` Sudeep Holla [this message] 2021-05-05 11:37 ` Viresh Kumar 2021-05-05 11:44 ` Sudeep Holla
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=20210505114118.idblntcldomzgmab@bogus \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables' \ /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
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.