Received-SPF: pass (google.com: domain of linux-kernel+bounces-95490-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <48fd9457-d092-4226-9a6c-13dea81694f5@linaro.org>
Date: Thu, 7 Mar 2024 12:50:05 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/1] arm64: dts: qcom: ipq6018: add sdhci node
Content-Language: en-US
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
 Robert Marko <robimarko@gmail.com>
Cc: Chukun Pan <amadeus@jmu.edu.cn>, Bjorn Andersson <andersson@kernel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
 Conor Dooley <conor+dt@kernel.org>, Rob Herring <robh@kernel.org>,
 linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
 devicetree@vger.kernel.org
References: <20240306123006.724934-1-amadeus@jmu.edu.cn>
 <20240306123006.724934-2-amadeus@jmu.edu.cn>
 <CAA8EJpqYjutM1Kh6QxysB6XNAmXywtOtRJ7KP0LbY5E36kCPvA@mail.gmail.com>
 <78b1a1a2-a9fa-4b28-9d96-d65bb5517199@gmail.com>
 <CAA8EJppJBOQh19r4A-igsh5znDE_R6mDNy+ao5ximx7vtsZZvA@mail.gmail.com>
 <CAOX2RU4W-zV3A8eW0A+1V838Fm=tUkXY=Bs3j4VJ8Jo9mxrOAw@mail.gmail.com>
 <CAA8EJpq=-r4XhnFJset0=X=YO5QNUpuw+e1r6DTsPvzNAZCyNw@mail.gmail.com>
From: Konrad Dybcio <konrad.dybcio@linaro.org>
In-Reply-To: <CAA8EJpq=-r4XhnFJset0=X=YO5QNUpuw+e1r6DTsPvzNAZCyNw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 3/7/24 08:50, Dmitry Baryshkov wrote:
> On Thu, 7 Mar 2024 at 09:38, Robert Marko <robimarko@gmail.com> wrote:
>>
>> On Thu, 7 Mar 2024 at 08:28, Dmitry Baryshkov
>> <dmitry.baryshkov@linaro.org> wrote:
>>>
>>> On Wed, 6 Mar 2024 at 22:35, Robert Marko <robimarko@gmail.com> wrote:
>>>>
>>>>
>>>> On 06. 03. 2024. 20:43, Dmitry Baryshkov wrote:
>>>>> On Wed, 6 Mar 2024 at 14:31, Chukun Pan <amadeus@jmu.edu.cn> 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@jmu.edu.cn>
>>>>>> ---
>>>>>>    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