On Wed, Mar 07, 2018 at 10:36:24AM +0530, Viresh Kumar wrote: > On 06-03-18, 08:37, Jordan Crouse wrote: > > I'll try to explain but I might need Stephen or some of the other folks to jump > > in and save me. > > Maybe you should start using his kernel.org address then ? :) > > > On sdm845 there are shared power resources controlled by the RPMh which is > > programed by a series of commands from the regulator driver; but in the case > > of the GPU the votes are passed to the GMU (graphics management unit) which > > communicates with the RPMh on behalf of the GPU. > > > > In order to construct the RPMh vote we need first need a voltage level that we > > can look up in a database. qcom,arc-level is the voltage level associated with > > a specific OPP. > > > > I had previously been abusing this with opp-microvolt but that was wrong for > > obvious reasons and then Stephen pointed out that this would be a better way. > > Glad that you shared that :) > > A solution is already in progress for that and is partially merged as > well. > > Look for "performance_state" in genpd and OPP cores (already merged), > followed by this series here: > > https://lkml.kernel.org/r/cover.1513926033.git.viresh.kumar@xxxxxxxxxx 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 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. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
