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.

Freedreno mailing list

Reply via email to