On Thu, Aug 14, 2025 at 12:50:17PM GMT, Nitin Rawat wrote:
>
>
> On 8/14/2025 6:29 AM, Harrison Vanderbyl wrote:
> > Describe device tree entry for x1e80100 ufs device
> > Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@xxxxxxxxx>
> > ---
> > arch/arm64/boot/dts/qcom/x1e80100.dtsi | 91 ++++++++++++++++++++++++++
> > 1 file changed, 91 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> > index a9a7bb676c6f..effa776e3dd0 100644
> > --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> > @@ -2819,6 +2819,97 @@ tsens3: thermal-sensor@c274000 {
> > #thermal-sensor-cells = <1>;
> > };
> > +
> > + ufs_mem_hc: ufs@1d84000 {
> > + compatible = "qcom,x1e80100-ufshc",
> > + "qcom,ufshc", "jedec,ufs-2.0";
This controller is UFS 3.0 based. Also, JEDEC has two specs for UFS:
1. UFSHCI (Host controllers found in SoCs)
2. UFS (UFS devices)
And this compatible 'jedec,ufs-2.0' is mostly for UFS devices, not Host
controllers. So using we should be using 'jedec,ufshc-3.0' here and in other
bindings.
krzk: Is it OK to change the compatible for all bindings and dts? Atleast linux
is not making use of this compatible, but I'm not sure about other DT users.
> > + reg = <0 0x01d84000 0 0x3000>;
> > +
> > +
> > + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + phys = <&ufs_mem_phy>;
> > + phy-names = "ufsphy";
> > +
> > + lanes-per-direction = <2>;
> > +
> > + #reset-cells = <1>;
> > + resets = <&gcc GCC_UFS_PHY_BCR>;
> > +
> > + reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
> > + reset-names = "rst";
> > +
> > + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> > +
> > + iommus = <&apps_smmu 0x1a0 0x0>;
> > +
> > + clock-names = "core_clk",
> > + "bus_aggr_clk",
> > + "iface_clk",
> > + "core_clk_unipro",
> > + "ref_clk",
> > + "tx_lane0_sync_clk",
> > + "rx_lane0_sync_clk",
> > + "rx_lane1_sync_clk";
> > +
> > + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> > + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> > + <&gcc GCC_UFS_PHY_AHB_CLK>,
> > + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> > + <&rpmhcc RPMH_CXO_CLK>,
> > + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> > + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> > + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> > +
> > + freq-table-hz = <100000000 403000000>,
> > + <0 0>,
> > + <0 0>,
> > + <100000000 403000000>,
> > + <100000000 403000000>,
> > + <0 0>,
> > + <0 0>,
> > + <0 0>;
> > +
> Please use OPP table instead of freq-table-hz.
>
>
> > + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
> > + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> > + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
> > + &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ALWAYS>;
>
> For Config Path, use QCOM_ICC_TAG_ACTIVE_ONLY.
>
> YOu can refer to ICC discussion link for SM8750 - https://lore.kernel.org/linux-devicetree/354f8710-a5ec-47b5-bcfa-bff75ac3ca71@xxxxxxxxxxxxxxxx/
>
Nitin, question for you: Is this controller cache coherent as like its ancerstor
sm8550?
- Mani
--
மணிவண்ணன் சதாசிவம்
