On Thu, Apr 11, 2024 at 08:59:53AM -0700, Nikunj Kela wrote: > > On 4/11/2024 2:23 AM, Sudeep Holla wrote: > > On Wed, Apr 10, 2024 at 09:55:24AM -0700, Nikunj Kela wrote: > > > On 3/19/2024 9:13 AM, Sudeep Holla wrote: > > > > On Tue, Mar 19, 2024 at 03:41:40PM +0000, Srinivas Kandagatla wrote: > > > > > On 19/03/2024 15:17, Sudeep Holla wrote: > > > > > > I am not debating on the implementation just to be clear. I accept changes > > > > > > might be needed there. The $subject is all about DT bindings and what need > > > > > > to be changes and for me nothing, just use existing bindings and if there > > > > > > are issues there, let us discuss it with specifics. > > > > > > > > > > > How can changes to dt bindings be nothing? All the resources > > > > > clk/regulators/resets will become optional and a new power or perf domain > > > > > will become required for each device with firmwares that support SCMI Perf. > > > > > > > > > Correct, sorry to miss the point that few properties are now optional from > > > > mandatory before. Very good point. I was so caught up with the addition of > > > > the new "firmware controlled blah blah" property/compatible that I missed > > > > to observe mandatory->optional as a change. Thanks for correcting me. > > > > > > > If there are no more questions on this and everyone is on the same page, I > > > would like to conclude this thread in favor of using a new DT property > > > 'qcom,firmware-managed-resources'. > > > > > This is exactly opposite to what I have advocated so far in this thread. > > Not sure how you drew to this conclusion. Check [1] and [2] for example. > > The point was not to have qcom specific compatibles or properties as it > > doesn't scale well. Please chime into those if you have argument and how > > you came to this conclusion. > > > > -- > > Regards, > > Sudeep > > > > [1] https://lore.kernel.org/all/ZfMZ9ATxuvONcGpz@bogus > > [2] https://lore.kernel.org/all/0411f99d-231a-af4b-d681-7f7748361aa3@xxxxxxxxxxx > Hi Sudeep, we had a discussion with Linaro team on this and people suggested > that this should be a vendor specific property since different vendors might > abstract differently. Unless you point to some public discussion or meeting notes it is hard to understand what was discussed and how this conclusion was drawn, definitely not evident from the thread. Any pointers to the meeting notes ? If it was private, just assume it didn't happen when responding on public ML threads like these. Otherwise it adds more confusion and won't be much of a help IMO. > Moreover, our changes are only in Qualcomm drivers so > it made sense to use vendor specific property. That being said, if you are > suggesting that we remove Qcom from it, I can again discuss this. I will let > Srini and other pitch in here if they want to add more to it. Sorry, there are lots of points made on this thread which you have not read(missed) or not yet responded. So I suggest you to go through the thread and then either respond or better start a new thread summarising what is addressed so far what is not addressed, if you have responses to those questions. Since this has become a huge thread now, it may make it hard for people to follow, annoy few others 😉. So I suggest to start a new thread capturing highlights of the discussion so far. For me, you seem to have missed how you address this on a generic USB or some other non-Qcom IP is the main question I have repeatedly asked and haven't received any comments on that topic. Trilok suggested that case needs to be considered even on Qcom SoC which makes you argument that I will first address Qcom IPs only just weak. So at this point, I have to conclude you are not interested in addressing that if you continue in that direction and accept that you will go ahead with Qcom specific solution anyways. If so, I may have to skip getting involved in these discussions in the future as I believe it may be just waste of my time. Sorry if that's harsh, nothing personal. -- Regards, Sudeep
