| Message ID | 1551252192-535-7-git-send-email-stanley.chu@mediatek.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v3,1/7] scsi: ufs: Introduce ufshcd_get_pwr_dev_param | expand |
On Wed, Feb 27, 2019 at 03:23:10PM +0800, Stanley Chu wrote: > Add UFS and UFS PHY node document for Mediatek SoC chips. > > Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> > --- > .../devicetree/bindings/ufs/ufs-mediatek.txt | 47 +++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > new file mode 100644 > index 000000000000..5fc985928b3e > --- /dev/null > +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > @@ -0,0 +1,47 @@ > +* Mediatek Universal Flash Storage (UFS) Host Controller > + > +UFS nodes are defined to describe on-chip UFS hardware macro. > +Each UFS Host Controller should have its own node. > + > +To bind UFS PHY with UFS host controller, the controller node should > +contain a phandle reference to UFS M-PHY node. > + > +Required properties for UFS nodes: > +- compatible : Compatible list, contains the following controller: > + "mediatek,ufshci" Needs an SoC specific compatible string. > +- reg : Address and length of the UFS register set. > +- interrupt-parent : Interrupt device. Drop this. It is implied or may be in a parent node. > +- phys : phandle to m-phy. > +- clocks : List of phandle and clock specifier pairs. > +- clock-names : List of clock input name strings sorted in the same > + order as the clocks property. "ufs-clk" is mandatory. > +- freq-table-hz : Array of <min max> operating frequencies stored in the same > + order as the clocks property. If this property is not > + defined or a value in the array is "0" then it is assumed > + that the frequency is set by the parent clock or a > + fixed rate clock source. > +- vcc-supply : Power to the UFS device. > +- vcc-fixed-regulator: Specify that vcc-supply is a fixed regulator. Why is this needed? The driver could query the voltage range of the regulator or you could check the regulator node. > +- lanes-per-direction: Number of lanes available per direction. Shall be 1. If this can only be one value, then it can be implied by the compatible string. > + > +Example: > + > + ufs_mphy: ufs_mphy@11fa0000 { > + ... > + }; > + > + ufshci:ufshci@11270000 { > + compatible = "mediatek,ufshci"; > + reg = <0 0x11270000 0 0x2300>; > + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>; > + phys = <&ufs_mphy>; > + > + clocks = <&infracfg_ao INFRACFG_AO_UFS_CG>; > + clock-names = "ufs-clk"; > + freq-table-hz = <0 0>; > + > + vcc-supply = <&mt_pmic_vemc_ldo_reg>; > + vcc-fixed-regulator; > + > + lanes-per-direction = <1>; > + }; > -- > 2.18.0 >
Hi Rob, On Tue, 2019-03-12 at 21:31 +0800, Rob Herring wrote: > On Wed, Feb 27, 2019 at 03:23:10PM +0800, Stanley Chu wrote: > > Add UFS and UFS PHY node document for Mediatek SoC chips. > > > > Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> > > --- > > .../devicetree/bindings/ufs/ufs-mediatek.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > > diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > new file mode 100644 > > index 000000000000..5fc985928b3e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > @@ -0,0 +1,47 @@ > > +* Mediatek Universal Flash Storage (UFS) Host Controller > > + > > +UFS nodes are defined to describe on-chip UFS hardware macro. > > +Each UFS Host Controller should have its own node. > > + > > +To bind UFS PHY with UFS host controller, the controller node should > > +contain a phandle reference to UFS M-PHY node. > > + > > +Required properties for UFS nodes: > > +- compatible : Compatible list, contains the following controller: > > + "mediatek,ufshci" > > Needs an SoC specific compatible string. Will add. > > > +- reg : Address and length of the UFS register set. > > +- interrupt-parent : Interrupt device. > > Drop this. It is implied or may be in a parent node. Will remove it. > > > +- phys : phandle to m-phy. > > +- clocks : List of phandle and clock specifier pairs. > > +- clock-names : List of clock input name strings sorted in the same > > + order as the clocks property. "ufs-clk" is mandatory. > > +- freq-table-hz : Array of <min max> operating frequencies stored in the same > > + order as the clocks property. If this property is not > > + defined or a value in the array is "0" then it is assumed > > + that the frequency is set by the parent clock or a > > + fixed rate clock source. > > +- vcc-supply : Power to the UFS device. > > +- vcc-fixed-regulator: Specify that vcc-supply is a fixed regulator. > > Why is this needed? The driver could query the voltage range of the > regulator or you could check the regulator node. Both ufshcd-pltfrm.txt and ufshcd-pltfrm.c driver allow - <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator. Our vcc does not require further initializatio, so is it OK here or shall we also modify both ufshcd-pltfrm dt-bindings document and ufs driver to avoid using it ? > > > +- lanes-per-direction: Number of lanes available per direction. Shall be 1. > > If this can only be one value, then it can be implied by the compatible > string. Will remove it. > > > + > > +Example: > > + > > + ufs_mphy: ufs_mphy@11fa0000 { > > + ... > > + }; > > + > > + ufshci:ufshci@11270000 { > > + compatible = "mediatek,ufshci"; > > + reg = <0 0x11270000 0 0x2300>; > > + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>; > > + phys = <&ufs_mphy>; > > + > > + clocks = <&infracfg_ao INFRACFG_AO_UFS_CG>; > > + clock-names = "ufs-clk"; > > + freq-table-hz = <0 0>; > > + > > + vcc-supply = <&mt_pmic_vemc_ldo_reg>; > > + vcc-fixed-regulator; > > + > > + lanes-per-direction = <1>; > > + }; > > -- > > 2.18.0 > >
On Tue, Mar 12, 2019 at 9:41 PM Stanley Chu <stanley.chu@mediatek.com> wrote: > > Hi Rob, > > On Tue, 2019-03-12 at 21:31 +0800, Rob Herring wrote: > > On Wed, Feb 27, 2019 at 03:23:10PM +0800, Stanley Chu wrote: > > > Add UFS and UFS PHY node document for Mediatek SoC chips. > > > > > > Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> > > > --- > > > .../devicetree/bindings/ufs/ufs-mediatek.txt | 47 +++++++++++++++++++ > > > 1 file changed, 47 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > > > > diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > new file mode 100644 > > > index 000000000000..5fc985928b3e > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > @@ -0,0 +1,47 @@ > > > +* Mediatek Universal Flash Storage (UFS) Host Controller > > > + > > > +UFS nodes are defined to describe on-chip UFS hardware macro. > > > +Each UFS Host Controller should have its own node. > > > + > > > +To bind UFS PHY with UFS host controller, the controller node should > > > +contain a phandle reference to UFS M-PHY node. > > > + > > > +Required properties for UFS nodes: > > > +- compatible : Compatible list, contains the following controller: > > > + "mediatek,ufshci" > > > > Needs an SoC specific compatible string. > > Will add. > > > > > > +- reg : Address and length of the UFS register set. > > > +- interrupt-parent : Interrupt device. > > > > Drop this. It is implied or may be in a parent node. > > Will remove it. > > > > > > +- phys : phandle to m-phy. > > > +- clocks : List of phandle and clock specifier pairs. > > > +- clock-names : List of clock input name strings sorted in the same > > > + order as the clocks property. "ufs-clk" is mandatory. > > > +- freq-table-hz : Array of <min max> operating frequencies stored in the same > > > + order as the clocks property. If this property is not > > > + defined or a value in the array is "0" then it is assumed > > > + that the frequency is set by the parent clock or a > > > + fixed rate clock source. > > > +- vcc-supply : Power to the UFS device. > > > +- vcc-fixed-regulator: Specify that vcc-supply is a fixed regulator. > > > > Why is this needed? The driver could query the voltage range of the > > regulator or you could check the regulator node. > > Both ufshcd-pltfrm.txt and ufshcd-pltfrm.c driver allow > > - <name>-fixed-regulator : boolean property specifying that > <name>-supply is a fixed regulator. > > Our vcc does not require further initializatio, so is it OK here or > shall we also modify both ufshcd-pltfrm dt-bindings document and ufs > driver to avoid using it ? There are no users of that property in tree and doesn't look like adding it was ever reviewed. We have standard ways to handle this and don't need a custom property. Rob
Hi Rob, On Thu, 2019-03-14 at 03:48 +0800, Rob Herring wrote: > On Tue, Mar 12, 2019 at 9:41 PM Stanley Chu <stanley.chu@mediatek.com> wrote: > > > > Hi Rob, > > > > On Tue, 2019-03-12 at 21:31 +0800, Rob Herring wrote: > > > On Wed, Feb 27, 2019 at 03:23:10PM +0800, Stanley Chu wrote: > > > > Add UFS and UFS PHY node document for Mediatek SoC chips. > > > > > > > > Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> > > > > --- > > > > .../devicetree/bindings/ufs/ufs-mediatek.txt | 47 +++++++++++++++++++ > > > > 1 file changed, 47 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > > new file mode 100644 > > > > index 000000000000..5fc985928b3e > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt > > > > @@ -0,0 +1,47 @@ > > > > +* Mediatek Universal Flash Storage (UFS) Host Controller > > > > + > > > > +UFS nodes are defined to describe on-chip UFS hardware macro. > > > > +Each UFS Host Controller should have its own node. > > > > + > > > > +To bind UFS PHY with UFS host controller, the controller node should > > > > +contain a phandle reference to UFS M-PHY node. > > > > + > > > > +Required properties for UFS nodes: > > > > +- compatible : Compatible list, contains the following controller: > > > > + "mediatek,ufshci" > > > > > > Needs an SoC specific compatible string. > > > > Will add. > > > > > > > > > +- reg : Address and length of the UFS register set. > > > > +- interrupt-parent : Interrupt device. > > > > > > Drop this. It is implied or may be in a parent node. > > > > Will remove it. > > > > > > > > > +- phys : phandle to m-phy. > > > > +- clocks : List of phandle and clock specifier pairs. > > > > +- clock-names : List of clock input name strings sorted in the same > > > > + order as the clocks property. "ufs-clk" is mandatory. > > > > +- freq-table-hz : Array of <min max> operating frequencies stored in the same > > > > + order as the clocks property. If this property is not > > > > + defined or a value in the array is "0" then it is assumed > > > > + that the frequency is set by the parent clock or a > > > > + fixed rate clock source. > > > > +- vcc-supply : Power to the UFS device. > > > > +- vcc-fixed-regulator: Specify that vcc-supply is a fixed regulator. > > > > > > Why is this needed? The driver could query the voltage range of the > > > regulator or you could check the regulator node. > > > > Both ufshcd-pltfrm.txt and ufshcd-pltfrm.c driver allow > > > > - <name>-fixed-regulator : boolean property specifying that > > <name>-supply is a fixed regulator. > > > > Our vcc does not require further initializatio, so is it OK here or > > shall we also modify both ufshcd-pltfrm dt-bindings document and ufs > > driver to avoid using it ? > > There are no users of that property in tree and doesn't look like > adding it was ever reviewed. We have standard ways to handle this and > don't need a custom property. Got it and thanks. I am planning to drop VCC related first in this series and add it back by another patch accompanied with VCC/ICC logic fix in UFS common driver which beyond the scope of this series. > > Rob Thanks, Stanley.
On 13/03/2019 20:48, Rob Herring wrote: Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: - <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator. > There are no users of that property in tree and doesn't look like > adding it was ever reviewed. We have standard ways to handle this and > don't need a custom property. FWIW, it seems to come from downstream: https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/?h=LE.UM.1.3.r3.25 $ git grep fixed-regulator vendor -- arch/arm/boot/dts/qcom/ vendor:arch/arm/boot/dts/qcom/msm8996.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-skuk.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-vr1.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-rumi.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-sim.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-svr20.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-v2.1-interposer-sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-sim.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-sim.dts: vdd-hba-fixed-regulator;
On 13/03/2019 20:48, Rob Herring wrote: Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: - <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator. > There are no users of that property in tree and doesn't look like > adding it was ever reviewed. We have standard ways to handle this and > don't need a custom property. FWIW, it seems to come from downstream: https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/?h=LE.UM.1.3.r3.25 $ git grep fixed-regulator vendor -- arch/arm/boot/dts/qcom/ vendor:arch/arm/boot/dts/qcom/msm8996.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-interposer-sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-skuk.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd-vr1.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-rumi.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-sim.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-svr20.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/msm8998-v2.1-interposer-sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm630-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-cdp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-mtp.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-pm660a-sim.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-qrd.dtsi: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-rumi.dts: vdd-hba-fixed-regulator; vendor:arch/arm/boot/dts/qcom/sdm660-sim.dts: vdd-hba-fixed-regulator;
On Thu, Mar 14, 2019 at 3:46 AM Marc Gonzalez <marc.w.gonzalez@free.fr> wrote: > > On 13/03/2019 20:48, Rob Herring wrote: > > Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: > - <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator. > > > There are no users of that property in tree and doesn't look like > > adding it was ever reviewed. We have standard ways to handle this and > > don't need a custom property. > > FWIW, it seems to come from downstream: The question would be is downstream compliant with the upstream binding. If so, then we shouldn't really break things as that's just out of tree which is fine. Or we just need a better explanation of why it is needed. MMC has some properties related to card voltages for example. Maybe the need is similar. Rob
Hi Rob and all, On Fri, 2019-03-15 at 00:44 +0800, Rob Herring wrote: > On Thu, Mar 14, 2019 at 3:46 AM Marc Gonzalez <marc.w.gonzalez@free.fr> wrote: > > > > On 13/03/2019 20:48, Rob Herring wrote: > > > > Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt mentions: > > - <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator. > > > > > There are no users of that property in tree and doesn't look like > > > adding it was ever reviewed. We have standard ways to handle this and > > > don't need a custom property. > > > > FWIW, it seems to come from downstream: > > The question would be is downstream compliant with the upstream > binding. If so, then we shouldn't really break things as that's just > out of tree which is fine. > > Or we just need a better explanation of why it is needed. MMC has some > properties related to card voltages for example. Maybe the need is > similar. > For short-term, could this patch series be merged without "vcc" related property defined in dt-bindings (like PATCH V5 does)? Or using "vcc-supply" along with "vcc-fixed-regulator" with a detailed explanation can be accepted? ufs-mediatek can work fine without "vcc" related property but with a limitation that driver cannot control "vcc" power which is enabled by-default on MediaTek chipsets. For long-term, it seems to me that "<name>-fixed-regulator" can be removed from both dt-bindings and UFS driver without impact, even for downstream usage found by Marc. If "<name>-fixed-regulator" property is defined in device tree, such regulator will skip "current limit" assignment from "<name>-max-microamp" property, and voltage range assignment from "vcc-supply-lp8" property (for vcc, vccq, and vccq2 only). If driver can handle above both cases correctly, "<name>-fixed-regulator" can be removed. In MediaTek chipsets, "vcc-supply" can ignore above two properties. However if "vcc-fixed-regulator" is not added, driver will get fail during device tree probing due to undefined "vcc-max-microamp". If our target is removing "<name>-fixed-regulator", we could try to fix and resolve above all. And if we do not merge "vcc" related property this time, after that we can add "vcc-supply" back to dt-bindings to provide vcc control capability in ufs-mediatek driver. Would you please provide any suggestions? > Rob
diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt new file mode 100644 index 000000000000..5fc985928b3e --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt @@ -0,0 +1,47 @@ +* Mediatek Universal Flash Storage (UFS) Host Controller + +UFS nodes are defined to describe on-chip UFS hardware macro. +Each UFS Host Controller should have its own node. + +To bind UFS PHY with UFS host controller, the controller node should +contain a phandle reference to UFS M-PHY node. + +Required properties for UFS nodes: +- compatible : Compatible list, contains the following controller: + "mediatek,ufshci" +- reg : Address and length of the UFS register set. +- interrupt-parent : Interrupt device. +- phys : phandle to m-phy. +- clocks : List of phandle and clock specifier pairs. +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. "ufs-clk" is mandatory. +- freq-table-hz : Array of <min max> operating frequencies stored in the same + order as the clocks property. If this property is not + defined or a value in the array is "0" then it is assumed + that the frequency is set by the parent clock or a + fixed rate clock source. +- vcc-supply : Power to the UFS device. +- vcc-fixed-regulator: Specify that vcc-supply is a fixed regulator. +- lanes-per-direction: Number of lanes available per direction. Shall be 1. + +Example: + + ufs_mphy: ufs_mphy@11fa0000 { + ... + }; + + ufshci:ufshci@11270000 { + compatible = "mediatek,ufshci"; + reg = <0 0x11270000 0 0x2300>; + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>; + phys = <&ufs_mphy>; + + clocks = <&infracfg_ao INFRACFG_AO_UFS_CG>; + clock-names = "ufs-clk"; + freq-table-hz = <0 0>; + + vcc-supply = <&mt_pmic_vemc_ldo_reg>; + vcc-fixed-regulator; + + lanes-per-direction = <1>; + };
Add UFS and UFS PHY node document for Mediatek SoC chips. Signed-off-by: Stanley Chu <stanley.chu@mediatek.com> --- .../devicetree/bindings/ufs/ufs-mediatek.txt | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-mediatek.txt