Re: [PATCH v5 1/1] arm64: dts: qcom: ipq6018: add sdhci node

From: Konrad Dybcio
Date: Thu Mar 07 2024 - 06:53:06 EST




On 3/7/24 08:50, Dmitry Baryshkov wrote:
On Thu, 7 Mar 2024 at 09:38, Robert Marko <robimarko@xxxxxxxxx> wrote:

On Thu, 7 Mar 2024 at 08:28, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:

On Wed, 6 Mar 2024 at 22:35, Robert Marko <robimarko@xxxxxxxxx> wrote:


On 06. 03. 2024. 20:43, Dmitry Baryshkov wrote:
On Wed, 6 Mar 2024 at 14:31, Chukun Pan <amadeus@xxxxxxxxxx> wrote:
Add node to support mmc controller inside of IPQ6018.
This controller supports both eMMC and SD cards.

Tested with:
eMMC (HS200)
SD Card (SDR50/SDR104)

Signed-off-by: Chukun Pan <amadeus@xxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 322eced0b876..420c192bccd9 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -441,6 +441,25 @@ dwc_1: usb@7000000 {
};
};

+ sdhc: mmc@7804000 {
+ compatible = "qcom,ipq6018-sdhci", "qcom,sdhci-msm-v5";
+ reg = <0x0 0x07804000 0x0 0x1000>,
+ <0x0 0x07805000 0x0 0x1000>;
+ reg-names = "hc", "cqhci";
+
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hc_irq", "pwr_irq";
+
+ clocks = <&gcc GCC_SDCC1_AHB_CLK>,
+ <&gcc GCC_SDCC1_APPS_CLK>,
+ <&xo>;
+ clock-names = "iface", "core", "xo";
+ resets = <&gcc GCC_SDCC1_BCR>;
+ max-frequency = <192000000>;
If I understand correctly, GCC_SDCC1_APPS_CLK support frequencies up
to 384 MHz, but here you are limiting it to 192 MHz. Why is it so?

I am not sure that 384MHz is actually supported as IPQ6018 datasheet
clearly indicates that HS400 mode is not supported.

I didn't check the datasheet, I opened the gcc-ipq6018.c

I understand that, I just pointed it out, it wouldn't surprise me if
the frequency table
was just copy/pasted from IPQ8074.

Then it might be fixed instead, making the max-frequency property unnecessary.

The clock driver contains clock settings that were either autogenerated
or manually included, or copypasted. These settings, and particularly
downstream, only describe the known-working clock rates and the minimum
required voltage setting just to keep them ticking nicely (think running
a car with the clutch pressed, no real load), a subset (which may be an
improper subset) of which gets translated into the device OPPs (or frequency
levels downstream). We should have an OPP table here.

Konrad