On 3/12/2024 9:58 AM, Trilok Soni wrote:
On 3/12/2024 9:52 AM, Nikunj Kela wrote:
One is with old firmware interface and -scmi is with SCMI. No new top
level compatible change is needed. I understand it was switch from one
interface to the another and not like Qcom platforms which is moving
from in-kernel solution to firmware solution. But the general rule applies
here as well unless there are specific reasons for needing that exception.
I am not against it or ruling that out, just curious to understand them.
--
Regards,
Sudeep
Hi All,
Thank you all for all your inputs on this. I discussed this with Srini and he suggested that we could use a new optional DT property like "qcom, fw-managed" to ascertain if we are running on firmware managed variant. Thus each device node in the dts can add this. I did ask him if, instead of putting it to each device node, we can use it at the board level however he thinks that it would not be easy to update yaml documentation on DT nodes with board level property. So if everyone here agrees with this approach, I would like to close this thread.
Thank you!
Is "fw-managed" name restricted to SCMI based approaches? Why it needs to be per
driver device-tree node? What happens when I attach the same SOC-IP
along w/ the RISC-V Application core and use the RPMI?
In theory, fw-managed is not restricted to SCMI based approach however
currently, we are using it with SCMI based approach only.
Should not have fw-managed defined at the devicetree spec? This is not a
ARM specific problem since the drivers which are going to use this flag/property
are generic shouldn't care about SCMI/RPMI.
This requires more discussion I guess, I am not opposed to it.
Basically, I would prefer better than "qcom, fw-managed" since this is not
a qcom specific problem.
Sure, we can remove qcom if you think that's a better name.
