On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@xxxxxxxxxxx> wrote: > > 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. My apologies for joining this discussion at this late state. Yet, I just wanted to confirm what Nikunj said above. In the end we are indeed talking about adding a new platform, as changing the FW interface from a QCOM proprietary one into SCMI, simply requires updates to a DTS file(s) that is platform specific. That said, it also seems reasonable to me to use a compatible string, to allow us to describe the update of HW for various affected devices. Probably the best next step is to post a patch series showing how this would really look like, as it would help us to understand more, I think. Kind regards Uffe
