Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Pratyush Brahma <quic_pbrahma@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>, <andersson@kernel.org>
Cc: <konradybcio@kernel.org>, <robh@kernel.org>, <krzk+dt@kernel.org>,
	<conor+dt@kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Prakash Gupta <quic_guptap@quicinc.com>
Subject: Re: [PATCH v3 2/2] arm64: dts: qcom: qcs8300: Add device node for gfx_smmu
Date: Mon, 3 Feb 2025 10:41:35 +0530	[thread overview]
Message-ID: <0d4e9563-4a1c-4b7d-b075-eb5a6595ebe4@quicinc.com> (raw)
In-Reply-To: <5defdbcb-f134-4332-8b63-50794da6e2cd@oss.qualcomm.com>


On 2/1/2025 9:21 PM, Konrad Dybcio wrote:
> On 30.01.2025 6:40 AM, Pratyush Brahma wrote:
>> On 1/29/2025 7:56 PM, Konrad Dybcio wrote:
>>> On 28.01.2025 11:02 AM, Pratyush Brahma wrote:
>>>> On 1/9/2025 8:56 PM, Konrad Dybcio wrote:
>>>>> On 8.01.2025 1:10 PM, Pratyush Brahma wrote:
>>>>>> On 12/30/2024 6:49 PM, Konrad Dybcio wrote:
>>>>>>> On 27.12.2024 12:00 PM, Pratyush Brahma wrote:
>>>>>>>> Add the device node for gfx smmu that is required for gpu
>>>>>>>> specific address translations.
>>>>>>>>
>>>>>>>> This patch depends on the patch series [1] posted by Imran Shaik
>>>>>>>> adding the clock support for gpu.
>>>>>>>>
>>>>>>>> [1] https://lore.kernel.org/all/802d32f1-ff7e-4d61-83f1-f804ee1750ed@oss.qualcomm.com/
>>>>>>>>
>>>>>>>> Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
>>>>>>>> ---
>>>>>>>>      arch/arm64/boot/dts/qcom/qcs8300.dtsi | 37 +++++++++++++++++++++++++++
>>>>>>>>      1 file changed, 37 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
>>>>>>>> index 80226992a65d..8eb688e2df0a 100644
>>>>>>>> --- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
>>>>>>>> @@ -816,6 +816,43 @@
>>>>>>>>                  #power-domain-cells = <1>;
>>>>>>>>              };
>>>>>>>>      +        adreno_smmu: iommu@3da0000 {
>>>>>>>> +            compatible = "qcom,qcs8300-smmu-500", "qcom,adreno-smmu",
>>>>>>>> +                   "qcom,smmu-500", "arm,mmu-500";
>>>>>>>> +            reg = <0x0 0x3da0000 0x0 0x20000>;
>>>>>>>> +            #iommu-cells = <2>;
>>>>>>>> +            #global-interrupts = <2>;
>>>>>>>> +            dma-coherent;
>>>>>>>> +
>>>>>>>> +            power-domains = <&gpucc GPU_CC_CX_GDSC>;
>>>>>>>> +            clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
>>>>>>>> +                 <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>,
>>>>>>>> +                 <&gpucc GPU_CC_AHB_CLK>,
>>>>>>>> +                 <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
>>>>>>>> +                 <&gpucc GPU_CC_CX_GMU_CLK>,
>>>>>>>> +                 <&gpucc GPU_CC_HUB_CX_INT_CLK>,
>>>>>>>> +                 <&gpucc GPU_CC_HUB_AON_CLK>;
>>>>>>>> +            clock-names = "gcc_gpu_memnoc_gfx_clk",
>>>>>>>> +                      "gcc_gpu_snoc_dvm_gfx_clk",
>>>>>>>> +                      "gpu_cc_ahb_clk",
>>>>>>>> +                      "gpu_cc_hlos1_vote_gpu_smmu_clk",
>>>>>>>> +                      "gpu_cc_cx_gmu_clk",
>>>>>>>> +                      "gpu_cc_hub_cx_int_clk",
>>>>>>>> +                      "gpu_cc_hub_aon_clk";
>>>>>>> Most of these entries look totally bogus, please make sure you only
>>>>>>> reference the ones actually required
>>>>>> These entries are exactly similar to the ones we use in sa8775p as well [1] and the usecases
>>>>>> haven't changed between qcs8300 and sa8775p.
>>>>>>
>>>>>> Can you please let me know which entries you find irrelevant here?
>>>>> Well, I'm particularly unsure about CX_GMU and the HUB clocks.
>>>>> I >>don't think<< they don't have much to do with the SMMU, but please
>>>>> check internally with someone who knows for sure
>>>> I checked internally and found that these clocks are required for gpu smmu operations
>>>> as we don't use interconnect voting mechanism here as we do downstream. Hence the
>>>> list of clocks is same across all targets using gpu smmu as described in [1] previously.
>>> I managed to dig up some documents too.. It seems you're right, however the order
>>> is supposed to be slightly different:
>>>
>>> GPU_CC_CX_GMU_CLK
>>> GPU_CC_HUB_CX_INT_CLK
>>> GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK
>>> GCC_GPU_MEMNOC_GFX_CLK
>>>
>>> Unsure if it *actually* matters given we've added them in a random order on a
>>> multitude of platforms and there haven't been any visible adverse effects.
>> Thanks for checking this. We haven't really adhered to this order in
>> most of our platforms and things have been running fine. So I guess it doesn't matter.
>> However, I'll still send out the next patchset in the order you've mentioned. Just so that we
>> are in consonance, the final order would look like the following. Please correct me if you'd
>> prefer otherwise.
>>
>>                  clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
>>                                 <&gpucc GPU_CC_HUB_CX_INT_CLK>,
>>                                 <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
>>                                 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
>>                                 <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>,
>>                                 <&gpucc GPU_CC_AHB_CLK>,
>>                                 <&gpucc GPU_CC_HUB_AON_CLK>;
> Looks good, please double-check if it works without clk_ignore_unused
Thanks. Yes, these have been tested without clk_ignore_unused. I will 
send out the next set of patches
with this order.
>
> Konrad

-- 
Thanks and Regards
Pratyush Brahma


      reply	other threads:[~2025-02-03  5:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-27 11:00 [PATCH v3 2/2] arm64: dts: qcom: qcs8300: Add device node for gfx_smmu Pratyush Brahma
2024-12-28  3:35 ` Bjorn Andersson
2025-01-08 12:13   ` Pratyush Brahma
2024-12-30 13:19 ` Konrad Dybcio
2025-01-08 12:10   ` Pratyush Brahma
2025-01-09 15:26     ` Konrad Dybcio
2025-01-28 10:02       ` Pratyush Brahma
2025-01-29 14:26         ` Konrad Dybcio
2025-01-30  5:40           ` Pratyush Brahma
2025-02-01 15:51             ` Konrad Dybcio
2025-02-03  5:11               ` Pratyush Brahma [this message]

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=0d4e9563-4a1c-4b7d-b075-eb5a6595ebe4@quicinc.com \
    --to=quic_pbrahma@quicinc.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_guptap@quicinc.com \
    --cc=robh@kernel.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