On Sun, Mar 11, 2018 at 10:52 PM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> 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.
>
It sounds like it's qcom,{corner,level} from Jordan's description. In
my mind 'level' and 'corner' are the same but they got a name change
with the new RPM interface. Then another number space was introduced
with the new RPM interface, 'arc-level', which represents the numbers
that the hardware deals with. It may be that DT doesn't ever care to
express the 'arc-level', because cmd db hides the numberspace by
requiring software to translate the software 'level' to the hardware
'arc-level'. So the whole thing may be a moot point and we can decide
to use qcom,level everywhere because it's the future.
--
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
