public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
Date: Mon, 12 Mar 2018 11:22:54 +0530	[thread overview]
Message-ID: <20180312055254.GY6842@vireshk-i7> (raw)
In-Reply-To: <20180309160355.GC10589@jcrouse-lnx.qualcomm.com>

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

  parent reply	other threads:[~2018-03-12  5:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02 21:56 [PATCH 0/2] arm64: dts: Add sdm845 GPU/GMU and SMMU Jordan Crouse
2018-03-02 21:56 ` [PATCH 1/2] dt-bindings: Document qcom,adreno-gmu Jordan Crouse
2018-03-05 19:38   ` Rob Herring
2018-03-16 18:27     ` Jordan Crouse
2018-03-02 21:56 ` [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU Jordan Crouse
2018-03-05  4:42   ` Viresh Kumar
2018-03-05 15:28     ` Jordan Crouse
2018-03-06  4:26       ` Viresh Kumar
2018-03-06 15:37         ` [Freedreno] " Jordan Crouse
2018-03-07  5:06           ` Viresh Kumar
2018-03-08 20:14             ` Jordan Crouse
2018-03-09  3:43               ` Viresh Kumar
2018-03-09 10:19                 ` Rajendra Nayak
2018-03-09 15:47                   ` Jordan Crouse
2018-03-09 16:03                 ` Jordan Crouse
2018-03-09 17:18                   ` Stephen Boyd
2018-03-09 17:42                     ` Jordan Crouse
2018-03-12  5:54                       ` Viresh Kumar
2018-03-12  5:52                   ` Viresh Kumar [this message]
2018-03-13 18:23                     ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180312055254.GY6842@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox