On Fri, Mar 09, 2018 at 03:49:00PM +0530, Rajendra Nayak wrote: > Hey Jordan/Viresh, > > On 03/09/2018 09:13 AM, 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. > > What I am doing is a powerdomain driver to communicate magic values from > CPU to rpmh, looks like we need another one to communicate from CPU to > GMU now :) > > A few things, > * someone will need to map these larger magic values into something that > rpmh would understand (between 0 to 15 on the sdm845), thats done by > reading the command db level maps. Is this done by GMU? It is done by the GPU - we take the magic values, construct them into other magic values and send them to the GMU. As far as I know we are the only other in-kernel client of cmd-db other than the regulator(s). > * are these communicated just once for every OPP at init/boot, or for > every OPP switch? Just once at init. > * whats the communication mechanism we use between CPU and GMU? Shared memory queues inspired by Venus HFI. 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
