devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Caleb Connolly <caleb.connolly@linaro.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Lux Aliaga <they@mint.lgbt>,
	agross@kernel.org, andersson@kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, vkoul@kernel.org,
	kishon@kernel.org, alim.akhtar@samsung.com, avri.altman@wdc.com,
	bvanassche@acm.org, keescook@chromium.org, tony.luck@intel.com,
	gpiccoli@igalia.com
Cc: ~postmarketos/upstreaming@lists.sr.ht,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-scsi@vger.kernel.org, linux-hardening@vger.kernel.org,
	phone-devel@vger.kernel.org, martin.botka@somainline.org,
	marijn.suijten@somainline.org
Subject: Re: [PATCH v6 4/6] arm64: dts: qcom: sm6125: Add UFS nodes
Date: Tue, 17 Jan 2023 20:01:32 +0000	[thread overview]
Message-ID: <b127bf23-8752-47be-d98e-4a61794a3c48@linaro.org> (raw)
In-Reply-To: <51a8bb85-8fda-2d79-f753-9461316bae9e@linaro.org>



On 11/01/2023 12:04, Konrad Dybcio wrote:
> 
> 
> On 11.01.2023 03:53, Lux Aliaga wrote:
>>
>> On 09/01/2023 09:18, Konrad Dybcio wrote:
>>>
>>> On 8.01.2023 20:53, Lux Aliaga wrote:
>>>> Adds a UFS host controller node and its corresponding PHY to
>>>> the sm6125 platform.
>>>>
>>>> Signed-off-by: Lux Aliaga <they@mint.lgbt>
>>>> ---
>>>>   arch/arm64/boot/dts/qcom/sm6125.dtsi | 57 ++++++++++++++++++++++++++++
>>>>   1 file changed, 57 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
>>>> index df5453fcf2b9..cec7071d5279 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
>>>> @@ -511,6 +511,63 @@ sdhc_2: mmc@4784000 {
>>>>               status = "disabled";
>>>>           };
>>>>   +        ufs_mem_hc: ufs@4804000 {
>>>> +            compatible = "qcom,sm6125-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
>>>> +            reg = <0x04804000 0x3000>, <0x04810000 0x8000>;
>>> You need reg-names for ICE to probe, otherwise the second reg sits unused.
>>>
>>>> +            interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>>>> +            phys = <&ufs_mem_phy>;
>>>> +            phy-names = "ufsphy";
>>>> +            lanes-per-direction = <1>;
>>>> +            #reset-cells = <1>;
>>>> +            resets = <&gcc GCC_UFS_PHY_BCR>;
>>>> +            reset-names = "rst";
>>>> +            iommus = <&apps_smmu 0x200 0x0>;
>>>> +
>>>> +            clock-names = "core_clk",
>>>> +                      "bus_aggr_clk",
>>>> +                      "iface_clk",
>>>> +                      "core_clk_unipro",
>>>> +                      "ref_clk",
>>>> +                      "tx_lane0_sync_clk",
>>>> +                      "rx_lane0_sync_clk",
>>>> +                      "ice_core_clk";
>>>> +            clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
>>>> +                 <&gcc GCC_SYS_NOC_UFS_PHY_AXI_CLK>,
>>>> +                 <&gcc GCC_UFS_PHY_AHB_CLK>,
>>>> +                 <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
>>>> +                 <&rpmcc RPM_SMD_XO_CLK_SRC>,
>>>> +                 <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>>>> +                 <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
>>>> +                 <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
>>>> +            freq-table-hz = <50000000 240000000>,
>>>> +                    <0 0>,
>>>> +                    <0 0>,
>>>> +                    <37500000 150000000>,
>>>> +                    <0 0>,
>>>> +                    <0 0>,
>>>> +                    <0 0>,
>>>> +                    <75000000 300000000>;
>>>> +
>>>> +            status = "disabled";
>>>> +        };
>>>> +
>>>> +        ufs_mem_phy: phy@4807000 {
>>>> +            compatible = "qcom,sm6125-qmp-ufs-phy";
>>>> +            reg = <0x04807000 0x1c4>;
>>> Isn't this too small? Downstream says 0xdb8, but it's probably even bigger..
>> What do you think could help me find the new length of the registers? I tried 0x1000 and it probed just fine, but I'm not really sure until what extent I could push it.
> The "true" values are probably only in documentation, which
> I don't have.

This patch series uses the "new" DT layout, where there isn't a subnode
to define the address ranges of the different components.

The reg size would be correct if it used the "legacy" DT layout.

Confirming in downstream, 0xdb8 is the correct value (it's what DT uses
there and the phy-qcom-ufs-qmp-v3-660 driver confirms the biggest
register offset is PHY_BASE (0xc00) + PHY_SIZE (0x1b4) = 0xdb4 inclusive)

I'd suggest going for that in your next revision Lux.
> 
> Konrad
>>

-- 
Kind Regards,
Caleb (they/them)

  reply	other threads:[~2023-01-17 21:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-08 19:53 [PATCH v6 0/6] arm64: dts: qcom: sm6125: UFS and xiaomi-laurel-sprout support Lux Aliaga
2023-01-08 19:53 ` [PATCH v6 1/6] dt-bindings: ufs: qcom: Add SM6125 compatible string Lux Aliaga
2023-01-08 19:53 ` [PATCH v6 2/6] dt-bindings: phy: Add QMP UFS PHY compatible for SM6125 Lux Aliaga
2023-01-09 12:19   ` Krzysztof Kozlowski
2023-01-13 18:21   ` Vinod Koul
2023-01-08 19:53 ` [PATCH v6 3/6] phy: qcom-qmp: Add SM6125 UFS PHY support Lux Aliaga
2023-01-13 18:21   ` Vinod Koul
2023-01-13 19:31   ` Dmitry Baryshkov
2023-02-09 14:34     ` Lux Aliaga
2023-01-08 19:53 ` [PATCH v6 4/6] arm64: dts: qcom: sm6125: Add UFS nodes Lux Aliaga
2023-01-09 12:18   ` Konrad Dybcio
2023-01-11  2:53     ` Lux Aliaga
2023-01-11 12:04       ` Konrad Dybcio
2023-01-17 20:01         ` Caleb Connolly [this message]
2023-01-08 19:53 ` [PATCH v6 5/6] dt-bindings: arm: qcom: Document xiaomi,laurel-sprout board Lux Aliaga
2023-01-08 19:53 ` [PATCH v6 6/6] arm64: dts: qcom: sm6125: Initial support for xiaomi-laurel-sprout Lux Aliaga
2023-01-09 12:21   ` Konrad Dybcio
2023-01-10 11:56   ` Marijn Suijten
2023-01-10 12:03 ` [PATCH v6 0/6] arm64: dts: qcom: sm6125: UFS and xiaomi-laurel-sprout support Marijn Suijten

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=b127bf23-8752-47be-d98e-4a61794a3c48@linaro.org \
    --to=caleb.connolly@linaro.org \
    --cc=agross@kernel.org \
    --cc=alim.akhtar@samsung.com \
    --cc=andersson@kernel.org \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gpiccoli@igalia.com \
    --cc=keescook@chromium.org \
    --cc=kishon@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=martin.botka@somainline.org \
    --cc=phone-devel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=they@mint.lgbt \
    --cc=tony.luck@intel.com \
    --cc=vkoul@kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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).