Re: DT Query on "New Compatible vs New Property"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

[1]: https://lore.kernel.org/all/20230919121605.7304-1-ulf.hansson@xxxxxxxxxx/

[2]:https://lore.kernel.org/all/20230925131715.138411-1-ulf.hansson@xxxxxxxxxx/






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux