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? * are these communicated just once for every OPP at init/boot, or for every OPP switch? * whats the communication mechanism we use between CPU and GMU? regards Rajendra > > 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. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
