On 09-03-18, 09:03, Jordan Crouse wrote: > 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. Okay, I get it. You can't (shouldn't) use genpd stuff here. I would still like you guys (You/Rajendra/Stephen) to conclude if qcom-corner and qcom,arc-level are eventually same values and we should use same property for them. -- viresh -- 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
