On 1/24/2024 9:33 AM, Nikunj Kela wrote:
On 1/24/2024 9:24 AM, Sudeep Holla wrote:
On Wed, Jan 24, 2024 at 06:28:33AM -0800, Nikunj Kela wrote:
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.
One option is to make dev_pm_opp_set_opp() work for both. IIUC, opp
layer
can deal with clocks and regulators. A quick look at
dev_pm_opp_set_opp()
seem to suggest that.
I did explore that and there are some complications due to the
abstraction we are trying to achieve.
Another option is to try both one after another. Here I am assuming that
clk_get() will fail and return error. One could check if it has
pm_domain
with "perf" support and use opp APIs.
This sounds promising so I would like to explore this further. IIUC,
you are suggesting that we check if genpd->set_performance_state() is
implemented when the clock APIs fail?
I don't think we need DT changes to achieve what you have explained
so far.
At least not at a level of per device node compatible or extra property.
Hi Sudeep,
I would like to conclude on this thread. I was discussing this with Ulf.
He thinks that using the domain names to identify if platform is
abstracting clocks etc. are not scalable and sufficient. Instead he
thinks that the change in the interface to OS(and FW) is a good
candidate for a new compatible(even though HW is same). Even for SCMI,
we do change phandle in DT to SCMI protocol phandle so that is like a
different platform altogether. Could you please let me know if you still
think that using a different compatible in this case is not warranted.
Thanks
--
Regards,
Sudeep
