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.