On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote: > (I wrote an email that seems to have been lost) > > Quoting Jordan Crouse (2018-03-09 08:03:55) > > On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote: > > > On 08-03-18, 13:14, Jordan Crouse wrote: > > > > It seems to me that performance_state has a direct relationship with genpd > > > > which is good for CPU votes but in this case, we're just passing along raw data > > > > to an independent microcontroller. The 'qcom,arc-level' is used to construct > > > > the actual values that the GMU will program into the RPMh. Since these are > > > > > > The "genpd" here is created specially for this RPM. The performance-state thing > > > is designed to solve this very specific problem of qualcomm SoCs and there is no > > > way we are going to add another property for this now. > > > > > > > informational (from the CPU perspective) rather than functional I feel like > > > > that using performance_state for this would be as hacky as using opp-microvolt > > > > or something else. > > > > > > There is some WIP stuff here Rajendra is testing currently. > > > > > > ssh://git@xxxxxxxxxxxxxx/people/viresh.kumar/mylinux.git opp/genpd/qcom > > > > > > Please have a talk with Rajendra who can help you understand on how this can be > > > used for GPUs. > > > > I don't think we are understanding each other. The GMU is a separate > > microcontroller. It is given a magic number (actually a combination of magic > > numbers) that it then uses to directly interact with the other hardware to make > > the vote. The only responsibility that the CPU has is to construct that magic > > number (once, at init) and send it across when asked. > > > > Looking at the sdhc code from the testing tree it makes perfect sense > > that you have a device that needs to eventually do a RPMh vote from the CPU and > > so the 'required-opp' and performance state come together to do the right thing. > > This is good code. > > > > None of this is true for the GPU. The CPU never votes for the GPU so there > > isn't any need to connect it to the power domain drivers. Even if you did > > there isn't any current mechanism for the rpmpd driver to pass the right magic > > number to the GPU driver which is what it really needs. > > > > I suppose that instead of using 'qcom,arc-level' we could use 'qcom-corner' but > > then thats just a naming dispute. We still need a way for the GPU to query the > > magic values. > > > > Agreed. Forcing genpd and set_performance_state APIs on GMU doesn't make > any sense if the GMU is doing it all itself. > > The binding should be the same between sdhc and GMU if they're actually > talking about the same thing though. I think they are, because I suspect > GMU needs to translate the human reasonable value of qcom,corner into > the hardware qcom,arc-level value to write into it's hardware so the GMU > can auto-transition performance states. If I'm wrong, then > qcom,arc-level needs to be created alongside of qcom,corner because > they're different number spaces. I think the value that we're discussing here is the RPMh voltage level which we translate into the qcom,arc-level(s). I'm not sure how that matches up with qcom,corner. > BTW, it's qcom,corner and not qcom-corner right? http://git.linaro.org/people/viresh.kumar/mylinux.git/commit/?h=opp/genpd/qcom&id=7586600b3bf3f8e79ce9198922fad7d4aa5b3f8d + qcom-corner = <1>; shrug? Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
