Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Sun, Mar 11, 2018 at 10:52 PM, Viresh Kumar 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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On 09-03-18, 10:42, Jordan Crouse wrote: > On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote: > > BTW, it's qcom,corner and not qcom-corner right? > > http://git.linaro.org/people/viresh.kumar/mylinux.git/commit/?h=opp/genpd/qcom&id=7586600b3bf3f8e79ce9198922fad7d4aa5b3f8d > > + qcom-corner = <1>; > > shrug? My branch isn't final and this naming has to come from Qcom (Rajendra). So it can be qcom,corner eventually :) -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote: > (I wrote an email that seems to have been lost) > > Quoting Jordan Crouse (2018-03-09 08:03:55) > > On Fri, Mar 09, 2018 at 09:13:32AM +0530, 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. > > > > > > ssh://g...@git.linaro.org/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. > > > > 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. > > > > Agreed. Forcing genpd and set_performance_state APIs on GMU doesn't make > any sense if the GMU is doing it all itself. > > The binding should be the same between sdhc and GMU if they're actually > talking about the same thing though. I think they are, because I suspect > GMU needs to translate the human reasonable value of qcom,corner into > the hardware qcom,arc-level value to write into it's hardware so the GMU > can auto-transition performance states. If I'm wrong, then > qcom,arc-level needs to be created alongside of qcom,corner because > they're different number spaces. I think the value that we're discussing here is the RPMh voltage level which we translate into the qcom,arc-level(s). I'm not sure how that matches up with qcom,corner. > BTW, it's qcom,corner and not qcom-corner right? http://git.linaro.org/people/viresh.kumar/mylinux.git/commit/?h=opp/genpd/qcom&id=7586600b3bf3f8e79ce9198922fad7d4aa5b3f8d + qcom-corner = <1>; shrug? Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
(I wrote an email that seems to have been lost) Quoting Jordan Crouse (2018-03-09 08:03:55) > On Fri, Mar 09, 2018 at 09:13:32AM +0530, 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. > > > > ssh://g...@git.linaro.org/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. > > 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. > Agreed. Forcing genpd and set_performance_state APIs on GMU doesn't make any sense if the GMU is doing it all itself. The binding should be the same between sdhc and GMU if they're actually talking about the same thing though. I think they are, because I suspect GMU needs to translate the human reasonable value of qcom,corner into the hardware qcom,arc-level value to write into it's hardware so the GMU can auto-transition performance states. If I'm wrong, then qcom,arc-level needs to be created alongside of qcom,corner because they're different number spaces. BTW, it's qcom,corner and not qcom-corner right? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Fri, Mar 09, 2018 at 09:13:32AM +0530, 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. > > ssh://g...@git.linaro.org/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. 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. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Fri, Mar 09, 2018 at 03:49:00PM +0530, Rajendra Nayak wrote: > 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? It is done by the GPU - we take the magic values, construct them into other magic values and send them to the GMU. As far as I know we are the only other in-kernel client of cmd-db other than the regulator(s). > * are these communicated just once for every OPP at init/boot, or for > every OPP switch? Just once at init. > * whats the communication mechanism we use between CPU and GMU? Shared memory queues inspired by Venus HFI. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
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://g...@git.linaro.org/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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
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. ssh://g...@git.linaro.org/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. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Wed, Mar 07, 2018 at 10:36:24AM +0530, Viresh Kumar wrote: > On 06-03-18, 08:37, Jordan Crouse wrote: > > I'll try to explain but I might need Stephen or some of the other folks to > > jump > > in and save me. > > Maybe you should start using his kernel.org address then ? :) > > > On sdm845 there are shared power resources controlled by the RPMh which is > > programed by a series of commands from the regulator driver; but in the case > > of the GPU the votes are passed to the GMU (graphics management unit) which > > communicates with the RPMh on behalf of the GPU. > > > > In order to construct the RPMh vote we need first need a voltage level that > > we > > can look up in a database. qcom,arc-level is the voltage level associated > > with > > a specific OPP. > > > > I had previously been abusing this with opp-microvolt but that was wrong for > > obvious reasons and then Stephen pointed out that this would be a better > > way. > > Glad that you shared that :) > > A solution is already in progress for that and is partially merged as > well. > > Look for "performance_state" in genpd and OPP cores (already merged), > followed by this series here: > > https://lkml.kernel.org/r/cover.1513926033.git.viresh.ku...@linaro.org 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 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. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On 06-03-18, 08:37, Jordan Crouse wrote: > I'll try to explain but I might need Stephen or some of the other folks to > jump > in and save me. Maybe you should start using his kernel.org address then ? :) > On sdm845 there are shared power resources controlled by the RPMh which is > programed by a series of commands from the regulator driver; but in the case > of the GPU the votes are passed to the GMU (graphics management unit) which > communicates with the RPMh on behalf of the GPU. > > In order to construct the RPMh vote we need first need a voltage level that we > can look up in a database. qcom,arc-level is the voltage level associated with > a specific OPP. > > I had previously been abusing this with opp-microvolt but that was wrong for > obvious reasons and then Stephen pointed out that this would be a better way. Glad that you shared that :) A solution is already in progress for that and is partially merged as well. Look for "performance_state" in genpd and OPP cores (already merged), followed by this series here: https://lkml.kernel.org/r/cover.1513926033.git.viresh.ku...@linaro.org -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Tue, Mar 06, 2018 at 09:56:56AM +0530, Viresh Kumar wrote: > On 05-03-18, 08:28, Jordan Crouse wrote: > > I'm glad you brought this up - I was trying to find a place in the > > documentation > > to put it, but since target specific nodes would be a new trick for OPP I > > didn't > > quite know how to go about doing it. Do we just list them as Optional: or > > should we add a target specific section to the documentation and list them > > out > > there instead? > > Something like this and you need to have your own compatible string as > well: > > Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt > > But first, what's the purpose of this field? Just to check if it can > be handled by current bindings. I'll try to explain but I might need Stephen or some of the other folks to jump in and save me. On sdm845 there are shared power resources controlled by the RPMh which is programed by a series of commands from the regulator driver; but in the case of the GPU the votes are passed to the GMU (graphics management unit) which communicates with the RPMh on behalf of the GPU. In order to construct the RPMh vote we need first need a voltage level that we can look up in a database. qcom,arc-level is the voltage level associated with a specific OPP. I had previously been abusing this with opp-microvolt but that was wrong for obvious reasons and then Stephen pointed out that this would be a better way. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
