devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Luca Weiss <luca.weiss@fairphone.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Andy Gross <agross@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@somainline.org>
Cc: Marijn Suijten <marijn.suijten@somainline.org>,
	Rob Herring <robh@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Konrad Dybcio <konrad.dybcio@somainline.org>
Subject: Re: [PATCH 4/5] arm64: dts: qcom: sm6350: Add GPU nodes
Date: Mon, 3 Apr 2023 21:50:10 +0300	[thread overview]
Message-ID: <d279d2fa-e255-1e43-780c-6bdac437469d@linaro.org> (raw)
In-Reply-To: <22cfb674-eb2b-ff77-da87-cf6b520e592d@linaro.org>

On 18/03/2023 15:45, Konrad Dybcio wrote:
> 
> 
> On 17.03.2023 09:56, Luca Weiss wrote:
>> On Thu Mar 16, 2023 at 12:16 PM CET, Konrad Dybcio wrote:
>>> From: Konrad Dybcio <konrad.dybcio@somainline.org>
>>>
>>> Add Adreno, GPU SMMU and GMU nodes to hook up everything that
>>> the A619 needs to function properly.
>>>
>>> Co-developed-by: Luca Weiss <luca.weiss@fairphone.com>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>> ---
> [...]
> 
>> What about adding interconnect already? I also have opp-peak-kBps
>> additions in the opp table for that. I'll attach the diff I have at the
>> end of the email.
> I believe the GMU takes care of it internally (or at least should)
> with the bandwidth tables we send in a6xx_hfi.c : a6xx_hfi_send_bw_table()

We should still declare the interconnects. If at some point we attempt 
to fill these tables in a proper way, the interconnects will be required 
to get addresses of the nodes.

> 
> 
> [...]
> 
>>>   
>>> +		adreno_smmu: iommu@3d40000 {
>>
>> This and gmu should be above gpucc @3d90000?
> Absolutely.
> 
> Konrad
>>
>>> +			compatible = "qcom,sm6350-smmu-v2", "qcom,adreno-smmu", "qcom,smmu-v2";
>>> +			reg = <0 0x03d40000 0 0x10000>;
>>> +			#iommu-cells = <1>;
>>> +			#global-interrupts = <2>;
>>> +			interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 364 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 366 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 367 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 368 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 369 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
>>> +
>>> +			clocks = <&gpucc GPU_CC_AHB_CLK>,
>>> +				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
>>> +				 <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>;
>>> +			clock-names = "ahb",
>>> +				      "bus",
>>> +				      "iface";
>>> +
>>> +			power-domains = <&gpucc GPU_CX_GDSC>;
>>> +		};
>>> +
>>> +		gmu: gmu@3d6a000 {
>>> +			compatible = "qcom,adreno-gmu-619.0", "qcom,adreno-gmu";
>>> +			reg = <0 0x03d6a000 0 0x31000>,
>>> +			      <0 0x0b290000 0 0x10000>,
>>> +			      <0 0x0b490000 0 0x10000>;
>>> +			reg-names = "gmu",
>>> +				    "gmu_pdc",
>>> +				    "gmu_pdc_seq";
>>> +
>>> +			interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
>>> +				     <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
>>> +			interrupt-names = "hfi",
>>> +					  "gmu";
>>> +
>>> +			clocks = <&gpucc GPU_CC_AHB_CLK>,
>>> +				 <&gpucc GPU_CC_CX_GMU_CLK>,
>>> +				 <&gpucc GPU_CC_CXO_CLK>,
>>> +				 <&gcc GCC_DDRSS_GPU_AXI_CLK>,
>>> +				 <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
>>> +			clock-names = "ahb",
>>> +				      "gmu",
>>> +				      "cxo",
>>> +				      "axi",
>>> +				      "memnoc";
>>> +
>>> +			power-domains = <&gpucc GPU_CX_GDSC>,
>>> +					<&gpucc GPU_GX_GDSC>;
>>> +			power-domain-names = "cx",
>>> +					     "gx";
>>> +
>>> +			iommus = <&adreno_smmu 5>;
>>> +
>>> +			operating-points-v2 = <&gmu_opp_table>;
>>> +
>>> +			status = "disabled";
>>> +
>>> +			gmu_opp_table: opp-table {
>>> +				compatible = "operating-points-v2";
>>> +
>>> +				opp-200000000 {
>>> +					opp-hz = /bits/ 64 <200000000>;
>>> +					opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
>>> +				};
>>> +			};
>>> +		};
>>> +
>>>   		mpss: remoteproc@4080000 {
>>>   			compatible = "qcom,sm6350-mpss-pas";
>>>   			reg = <0x0 0x04080000 0x0 0x4040>;
>>>
>>> -- 
>>> 2.39.2
>>
>> Here's the diff I have for interconnect on top of this:
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
>> index 4954cbc2c0fc..51c5ac679a32 100644
>> --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
>> @@ -1142,6 +1142,8 @@ gpu: gpu@3d00000 {
>>   			iommus = <&adreno_smmu 0>;
>>   			operating-points-v2 = <&gpu_opp_table>;
>>   			qcom,gmu = <&gmu>;
>> +			interconnects = <&gem_noc MASTER_GRAPHICS_3D 0 &clk_virt SLAVE_EBI_CH0 0>;
>> +			interconnect-names = "gfx-mem";
>>   			nvmem-cells = <&gpu_speed_bin>;
>>   			nvmem-cell-names = "speed_bin";
>>   
>> @@ -1157,42 +1159,49 @@ gpu_opp_table: opp-table {
>>   				opp-850000000 {
>>   					opp-hz = /bits/ 64 <850000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
>> +					opp-peak-kBps = <8371200>;
>>   					opp-supported-hw = <0x02>;
>>   				};
>>   
>>   				opp-800000000 {
>>   					opp-hz = /bits/ 64 <800000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
>> +					opp-peak-kBps = <8371200>;
>>   					opp-supported-hw = <0x04>;
>>   				};
>>   
>>   				opp-650000000 {
>>   					opp-hz = /bits/ 64 <650000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
>> +					opp-peak-kBps = <6220000>;
>>   					opp-supported-hw = <0x08>;
>>   				};
>>   
>>   				opp-565000000 {
>>   					opp-hz = /bits/ 64 <565000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
>> +					opp-peak-kBps = <5412000>;
>>   					opp-supported-hw = <0x10>;
>>   				};
>>   
>>   				opp-430000000 {
>>   					opp-hz = /bits/ 64 <430000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
>> +					opp-peak-kBps = <4068000>;
>>   					opp-supported-hw = <0xff>;
>>   				};
>>   
>>   				opp-355000000 {
>>   					opp-hz = /bits/ 64 <355000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
>> +					opp-peak-kBps = <3072000>;
>>   					opp-supported-hw = <0xff>;
>>   				};
>>   
>>   				opp-253000000 {
>>   					opp-hz = /bits/ 64 <253000000>;
>>   					opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
>> +					opp-peak-kBps = <2188000>;
>>   					opp-supported-hw = <0xff>;
>>   				};
>>   			};
>>

-- 
With best wishes
Dmitry


  reply	other threads:[~2023-04-03 18:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 11:16 [PATCH 0/5] SM6350 GPU Konrad Dybcio
2023-03-16 11:16 ` [PATCH 1/5] dt-bindings: clock: qcom,gpucc: Fix SM6350 clock names Konrad Dybcio
2023-03-17  8:37   ` Krzysztof Kozlowski
2023-03-17 12:11     ` Konrad Dybcio
2023-04-03 18:05       ` Konrad Dybcio
2023-03-16 11:16 ` [PATCH 2/5] arm64: dts: qcom: sm6350: Add GPUCC node Konrad Dybcio
2023-03-17  8:47   ` Luca Weiss
2023-03-16 11:16 ` [PATCH 3/5] arm64: dts: qcom: sm6350: Add QFPROM node Konrad Dybcio
2023-03-17  8:50   ` Luca Weiss
2023-03-17 12:12     ` Konrad Dybcio
2023-03-16 11:16 ` [PATCH 4/5] arm64: dts: qcom: sm6350: Add GPU nodes Konrad Dybcio
2023-03-16 11:30   ` Luca Weiss
2023-03-17  8:56   ` Luca Weiss
2023-03-18 13:45     ` Konrad Dybcio
2023-04-03 18:50       ` Dmitry Baryshkov [this message]
2023-04-03 18:52         ` Konrad Dybcio
2023-03-16 11:17 ` [PATCH 5/5] arm64: dts: qcom: sm6350: Fix ZAP region Konrad Dybcio
2023-03-17  8:56   ` Luca Weiss

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=d279d2fa-e255-1e43-780c-6bdac437469d@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=angelogioacchino.delregno@somainline.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.weiss@fairphone.com \
    --cc=marijn.suijten@somainline.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sboyd@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;
as well as URLs for NNTP newsgroup(s).