| Message ID | 1594644106-22449-1-git-send-email-akhilpo@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for GPU DDR BW scaling | expand |
On Mon, Jul 13, 2020 at 5:41 AM Akhil P Oommen <akhilpo@codeaurora.org> wrote: > > This series adds support for GPU DDR bandwidth scaling and is based on the > bindings from Georgi [1]. This is mostly a rebase of Sharat's patches [2] on the > tip of msm-next branch. > > Changes from v4: > - Squashed a patch to another one to fix Jonathan's comment > - Add back the pm_runtime_get_if_in_use() check > > Changes from v3: > - Rebased on top of Jonathan's patch which adds support for changing gpu freq > through hfi on newer targets > - As suggested by Rob, left the icc_path intact for pre-a6xx GPUs > > [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/vireshk/pm/+log/opp/linux-next/ > [2] https://patchwork.freedesktop.org/series/75291/ > > Sharat Masetty (6): > dt-bindings: drm/msm/gpu: Document gpu opp table > drm: msm: a6xx: send opp instead of a frequency > drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR > arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling > arm64: dts: qcom: sc7180: Add interconnects property for GPU > arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp I can take the first two into msm-next, the 3rd will need to wait until dev_pm_opp_set_bw() lands Bjorn, I assume you take the last three? BR, -R > > .../devicetree/bindings/display/msm/gpu.txt | 28 ++++++ > arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++ > arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 ++ > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 108 ++++++++++++--------- > drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +- > drivers/gpu/drm/msm/msm_gpu.c | 3 +- > drivers/gpu/drm/msm/msm_gpu.h | 3 +- > 7 files changed, 112 insertions(+), 50 deletions(-) > > -- > 2.7.4 >
On 15-07-20, 08:36, Rob Clark wrote: > I can take the first two into msm-next, the 3rd will need to wait > until dev_pm_opp_set_bw() lands You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase it anymore.
On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 15-07-20, 08:36, Rob Clark wrote: > > I can take the first two into msm-next, the 3rd will need to wait > > until dev_pm_opp_set_bw() lands > > You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase > it anymore. > I can't really base on something newer than drm-next BR, -R
On 20-07-20, 08:03, Rob Clark wrote: > On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > > On 15-07-20, 08:36, Rob Clark wrote: > > > I can take the first two into msm-next, the 3rd will need to wait > > > until dev_pm_opp_set_bw() lands > > > > You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase > > it anymore. This was 5.8-rc1 + 2 patches for OPP. That's all. > > > > I can't really base on something newer than drm-next But you need the OPP dependency, isn't it ?
On Mon, Jul 20, 2020 at 8:24 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 20-07-20, 08:03, Rob Clark wrote: > > On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > > > > On 15-07-20, 08:36, Rob Clark wrote: > > > > I can take the first two into msm-next, the 3rd will need to wait > > > > until dev_pm_opp_set_bw() lands > > > > > > You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase > > > it anymore. > > This was 5.8-rc1 + 2 patches for OPP. That's all. > > > > > > > > I can't really base on something newer than drm-next > > But you need the OPP dependency, isn't it ? With your ack, I can add the patch the dev_pm_opp_set_bw patch to my tree and merge it via msm-next -> drm-next -> linus Otherwise I can send a second later pull req that adds the final patch after has rebased to 5.9-rc1 (by which point the opp next tree will have presumably been merged BR, -R > > -- > viresh
On 21-07-20, 07:28, Rob Clark wrote: > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my > tree and merge it via msm-next -> drm-next -> linus I wanted to send it via my tree, but its okay. Pick this patch from linux-next and add my Ack, I will drop it after that. a8351c12c6c7 OPP: Add and export helper to set bandwidth > Otherwise I can send a second later pull req that adds the final patch > after has rebased to 5.9-rc1 (by which point the opp next tree will > have presumably been merged The PM stuff gets pushed fairly early and so I was asking you to rebase just on my tree, so you could have sent the pull request right after the PM tree landed there instead of waiting for rc1. But its fine now.
On Tue, Jul 21, 2020 at 10:30 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 21-07-20, 07:28, Rob Clark wrote: > > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my > > tree and merge it via msm-next -> drm-next -> linus > > I wanted to send it via my tree, but its okay. Pick this patch from > linux-next and add my Ack, I will drop it after that. > > a8351c12c6c7 OPP: Add and export helper to set bandwidth Thanks, I'll do that > > > Otherwise I can send a second later pull req that adds the final patch > > after has rebased to 5.9-rc1 (by which point the opp next tree will > > have presumably been merged > > The PM stuff gets pushed fairly early and so I was asking you to > rebase just on my tree, so you could have sent the pull request right > after the PM tree landed there instead of waiting for rc1. I guess I should have explained that my tree gets pulled first into drm-next, which then gets pulled by Linus. BR, -R > But its fine now. > > -- > viresh
On Wed, Jul 22, 2020 at 5:47 PM Rob Clark <robdclark@gmail.com> wrote: > > On Tue, Jul 21, 2020 at 10:30 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > > On 21-07-20, 07:28, Rob Clark wrote: > > > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my > > > tree and merge it via msm-next -> drm-next -> linus > > > > I wanted to send it via my tree, but its okay. Pick this patch from > > linux-next and add my Ack, I will drop it after that. > > > > a8351c12c6c7 OPP: Add and export helper to set bandwidth > > Thanks, I'll do that > > > > > > Otherwise I can send a second later pull req that adds the final patch > > > after has rebased to 5.9-rc1 (by which point the opp next tree will > > > have presumably been merged > > > > The PM stuff gets pushed fairly early and so I was asking you to > > rebase just on my tree, so you could have sent the pull request right > > after the PM tree landed there instead of waiting for rc1. > > I guess I should have explained that my tree gets pulled first into > drm-next, which then gets pulled by Linus. Yeah either topic tree or acks for merging in the other branch. No rebasing in the middle of the merge window, that's rather uncool. -Daniel > > BR, > -R > > > But its fine now. > > > > -- > > viresh > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 22-07-20, 11:00, Viresh Kumar wrote: > On 21-07-20, 07:28, Rob Clark wrote: > > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my > > tree and merge it via msm-next -> drm-next -> linus > > I wanted to send it via my tree, but its okay. Pick this patch from > linux-next and add my Ack, I will drop it after that. > > a8351c12c6c7 OPP: Add and export helper to set bandwidth Oops, sorry for the trouble but this needs to go via my tree only :( I maintain two different branches, one for OPP and another one for cpufreq. There was no dependency within the OPP branch and so I dropped it that day and asked you to take it. But when I tried to send a pull request today I realised that one of the qcom patches in the cpufreq branch is dependent on it and I need to keep this patch in my tree.
On Wed, Jul 29, 2020 at 10:10 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 22-07-20, 11:00, Viresh Kumar wrote: > > On 21-07-20, 07:28, Rob Clark wrote: > > > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my > > > tree and merge it via msm-next -> drm-next -> linus > > > > I wanted to send it via my tree, but its okay. Pick this patch from > > linux-next and add my Ack, I will drop it after that. > > > > a8351c12c6c7 OPP: Add and export helper to set bandwidth > > Oops, sorry for the trouble but this needs to go via my tree only :( > > I maintain two different branches, one for OPP and another one for > cpufreq. There was no dependency within the OPP branch and so I > dropped it that day and asked you to take it. > > But when I tried to send a pull request today I realised that one of > the qcom patches in the cpufreq branch is dependent on it and I need > to keep this patch in my tree. Hmm, I've already sent my pull request to Dave, dropping the patch would require force-push and sending a new PR. Which I can do if Dave prefers. OTOH I guess it isn't the end of the world if the patch is merged via two different trees. BR, -R
On 30-07-20, 08:27, Rob Clark wrote: > Hmm, I've already sent my pull request to Dave, dropping the patch > would require force-push and sending a new PR. Which I can do if Dave > prefers. OTOH I guess it isn't the end of the world if the patch is > merged via two different trees. I don't think a patch can go via two trees, as that would have two sha keys for the same code. Though it is fine for a patch to go via two different trees if we make sure the same sha key is used for both. Will it be possible for you to provide a branch/tag of your branch that I can base stuff of ?
On Thu, Jul 30, 2020 at 8:37 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 30-07-20, 08:27, Rob Clark wrote: > > Hmm, I've already sent my pull request to Dave, dropping the patch > > would require force-push and sending a new PR. Which I can do if Dave > > prefers. OTOH I guess it isn't the end of the world if the patch is > > merged via two different trees. > > I don't think a patch can go via two trees, as that would have two sha > keys for the same code. it looks weird in the history, but other than that I think it is fine.. at least I see it happen somewhat regularly with fixes in drm > Though it is fine for a patch to go via two different trees if we make > sure the same sha key is used for both. > > Will it be possible for you to provide a branch/tag of your branch > that I can base stuff of ? You could use https://gitlab.freedesktop.org/drm/msm/-/commits/msm-next/ (or the tag drm-msm-next-2020-07-29), which already has the OPP patch. I've been trying to avoid force-pushing that because downstream trees are already pulling from that. BR, -R
On Thu, Jul 30, 2020 at 8:37 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 30-07-20, 08:27, Rob Clark wrote: > > Hmm, I've already sent my pull request to Dave, dropping the patch > > would require force-push and sending a new PR. Which I can do if Dave > > prefers. OTOH I guess it isn't the end of the world if the patch is > > merged via two different trees. > > I don't think a patch can go via two trees, as that would have two sha > keys for the same code. > > Though it is fine for a patch to go via two different trees if we make > sure the same sha key is used for both. > > Will it be possible for you to provide a branch/tag of your branch > that I can base stuff of ? > Ok, I sent a v2 pull req that dropped the OPP patch. Both are tagged so Dave can use either version, so I guess you two can coordinate this BR, -R