linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
To: Doug Anderson <dianders@google.com>,
	Shaik Sajida Bhanu <sbhanu@codeaurora.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Asutosh Das <asutoshd@codeaurora.org>,
	Sahitya Tummala <stummala@codeaurora.org>,
	Ram Prakash Gupta <rampraka@codeaurora.org>,
	Sayali Lokhande <sayalil@codeaurora.org>,
	sartgarg@codeaurora.org, Rajendra Nayak <rnayak@codeaurora.org>,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	Sibi Sankar <sibis@codeaurora.org>,
	cang@codeaurora.org, pragalla@codeaurora.org,
	nitirawa@codeaurora.org,
	Linux MMC List <linux-mmc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH V2] arm64: dts: qcom: sc7280: Add nodes for eMMC and SD card
Date: Thu, 25 Mar 2021 09:28:44 +0530	[thread overview]
Message-ID: <b77f207b-2d90-3c8b-857f-625bd3867ed1@codeaurora.org> (raw)
In-Reply-To: <CAD=FV=WLZCSd6D5VFyD+1KBp5n1qyszER2EVaEMwYjQfPSSDnA@mail.gmail.com>


On 3/23/2021 9:41 PM, Doug Anderson wrote:
> Hi,
>
> On Sat, Mar 20, 2021 at 11:18 AM Shaik Sajida Bhanu
> <sbhanu@codeaurora.org> wrote:
>> Add nodes for eMMC and SD card on sc7280.
>>
>> Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
>>
>> ---
>> This change is depends on the below patch series:
>> https://lore.kernel.org/patchwork/project/lkml/list/?series=488871
>> https://lore.kernel.org/patchwork/project/lkml/list/?series=489530
>> https://lore.kernel.org/patchwork/project/lkml/list/?series=488429
>>
>> Changes since V1:
>>          - Moved SDHC nodes as suggested by Bjorn Andersson.
>>          - Dropped "pinconf-" prefix as suggested by Bjorn Andersson.
>>          - Removed extra newlines as suggested by Konrad Dybcio.
>>          - Changed sd-cd pin to bias-pull-up in sdc2_off as suggested by
>>            Veerabhadrarao Badiganti.
>>          - Added bandwidth votes for eMMC and SD card.
>> ---
>>   arch/arm64/boot/dts/qcom/sc7280-idp.dts |  25 ++++
>>   arch/arm64/boot/dts/qcom/sc7280.dtsi    | 213 ++++++++++++++++++++++++++++++++
>>   2 files changed, 238 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dts b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
>> index 54d2cb3..4105263 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
>> +++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
>> @@ -8,6 +8,7 @@
>>   /dts-v1/;
>>
>>   #include "sc7280.dtsi"
>> +#include <dt-bindings/gpio/gpio.h>
>>
>>   / {
>>          model = "Qualcomm Technologies, Inc. sc7280 IDP platform";
>> @@ -242,6 +243,30 @@
>>          status = "okay";
>>   };
>>
>> +&sdhc_1 {
>> +       status = "okay";
> When I apply your patch I find that your sort order is wrong. "s"
> comes before "u" and after "q" in the alphabet so "sdhc_1" and
> "sdhc_2" should sort _after "qupv3_id_0" and before "uart5"
>
>
>> +       pinctrl-names = "default", "sleep";
>> +       pinctrl-0 = <&sdc1_on>;
>> +       pinctrl-1 = <&sdc1_off>;
>> +
>> +       vmmc-supply = <&vreg_l7b_2p9>;
>> +       vqmmc-supply = <&vreg_l19b_1p8>;
>> +};
>> +
>> +&sdhc_2 {
>> +       status = "okay";
>> +
>> +       pinctrl-names = "default","sleep";
>> +       pinctrl-0 = <&sdc2_on>;
>> +       pinctrl-1 = <&sdc2_off>;
>> +
>> +       vmmc-supply = <&vreg_l9c_2p9>;
>> +       vqmmc-supply = <&vreg_l6c_2p9>;
>> +
>> +       cd-gpios = <&tlmm 91 GPIO_ACTIVE_LOW>;
> Where is the pinctrl for the card detect?  Oh, I see it's in
> "sdc2_on". Probably would be good to break it out since this is
> board-specific. See below.
>
>
>> +};
>> +
>>   /* PINCTRL - additions to nodes defined in sc7280.dtsi */
>>
>>   &qup_uart5_default {
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 8f6b569..69eb064 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -20,6 +20,11 @@
>>
>>          chosen { };
>>
>> +       aliases {
>> +               mmc1 = &sdhc_1;
>> +               mmc2 = &sdhc_2;
>> +       };
>> +
>>          clocks {
>>                  xo_board: xo-board {
>>                          compatible = "fixed-clock";
>> @@ -305,6 +310,64 @@
>>                          #power-domain-cells = <1>;
>>                  };
>>
>> +               sdhc_1: sdhci@7c4000 {
>> +                       compatible = "qcom,sdhci-msm-v5";
> Please make the compatible:
>    compatible = "qcom,sc7280-sdhci", "qcom,sdhci-msm-v5";
>
> ...and add to the bindings. It should be a trivial bindings patch so
> not too much trouble.
>
> NOTE: even though the "qcom,sc7280-sdhci" should be in the bindings
> and here you _shouldn't_ be adding any code for it. Just let the
> fallback compatible string ("qcom,sdhci-msm-v5") do its magic. Adding
> the sc7280 specific version is more of a "just in case we need it
> later" type thing.
>
>
>> +                       reg = <0 0x7c4000 0 0x1000>,
>> +                                       <0 0x7c5000 0 0x1000>;
>> +                       reg-names = "hc", "cqhci";
>> +
>> +                       iommus = <&apps_smmu 0xC0 0x0>;
>> +                       interrupts = <GIC_SPI 652 IRQ_TYPE_LEVEL_HIGH>,
>> +                                       <GIC_SPI 656 IRQ_TYPE_LEVEL_HIGH>;
>> +                       interrupt-names = "hc_irq", "pwr_irq";
>> +
>> +                       clocks = <&gcc GCC_SDCC1_APPS_CLK>,
>> +                                       <&gcc GCC_SDCC1_AHB_CLK>,
>> +                                       <&rpmhcc RPMH_CXO_CLK>;
>> +                       clock-names = "core", "iface", "xo";
> I'm curious: why is the "xo" clock needed here but not for sc7180?
Actually its needed even for sc7180. We are making use of this clock in 
msm_init_cm_dll()
The default PoR value is also same as calculated value for 
HS200/HS400/SDR104 modes.
But just not to rely on default register values we need this entry.

>
>> +                       interconnects = <&aggre1_noc MASTER_SDCC_1 0 &mc_virt SLAVE_EBI1 0>,
>> +                                       <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_SDCC_1 0>;
>> +                       interconnect-names = "sdhc-ddr","cpu-sdhc";
>> +                       power-domains = <&rpmhpd SC7280_CX>;
>> +                       operating-points-v2 = <&sdhc1_opp_table>;
>> +
>> +                       bus-width = <8>;
>> +                       non-removable;
> This was actually a problem on sc7180 too, but you probably don't want
> "non-removable" in the SoC file. Board files really should be adding
> this. Though the SoC might be designed with the idea that this would
> be used for a non-removable eMMC card I don't know why it wouldn't be
> possible for someone to hook this up to an external slot and use a
> GPIO somewhere as a card detect.
>
>
>> +                       supports-cqe;
>> +                       no-sd;
>> +                       no-sdio;
> Does the port really not support SD / SDIO, or are you adding these
> two properties just because on your reference board it's not hooked up
> to SD/SDIO? What exactly makes it impossible to use SD/SDIO on this
> port?
>
By having this, we can optimize emmc device scan time.
Driver wont issue SDIO & SDcards specific commands while
scanning the device.Its little optimization.
I think board specific dt is right place.


>> +                       max-frequency = <192000000>;
> Why do you need to specify this?
>
>
>> +                       qcom,dll-config = <0x0007642c>;
>> +                       qcom,ddr-config = <0x80040868>;
> These magic hex values really have no place being in dts which should
> have things expressed at a higher level. ...but I guess that ship has
> sailed and this is in the bindings so I guess we're stuck with them,
> so I guess they're fine.
>
>
>> +                       mmc-ddr-1_8v;
>> +                       mmc-hs200-1_8v;
>> +                       mmc-hs400-1_8v;
>> +                       mmc-hs400-enhanced-strobe;
>> +
>> +                       status = "disabled";
>> +
>> +                       sdhc1_opp_table: sdhc1-opp-table {
>> +                               compatible = "operating-points-v2";
>> +
>> +                               opp-100000000 {
>> +                                       opp-hz = /bits/ 64 <100000000>;
>> +                                       required-opps = <&rpmhpd_opp_low_svs>;
>> +                                       opp-peak-kBps = <1200000 76000>;
>> +                                       opp-avg-kBps = <1200000 50000>;
> Why are the kBps numbers so vastly different than the ones on sc7180
> for the same OPP point. That implies:
>
> a) sc7180 is wrong.
>
> b) This patch is wrong.
>
> c) The numbers are essentially random and don't really matter.
>
> Can you identify which of a), b), or c) is correct, or propose an
> alternate explanation of the difference?
>
>
>> +                               };
>> +
>> +                               opp-384000000 {
>> +                                       opp-hz = /bits/ 64 <384000000>;
>> +                                       required-opps = <&rpmhpd_opp_nom>;
>> +                                       opp-peak-kBps = <5400000 1600000>;
>> +                                       opp-avg-kBps = <6000000 300000>;
> These opp numbers are also quite different than sc7180
>
>
>> +                               };
>> +                       };
>> +               };
>> +
>>                  qupv3_id_0: geniqup@9c0000 {
>>                          compatible = "qcom,geni-se-qup";
>>                          reg = <0 0x009c0000 0 0x2000>;
>> @@ -328,6 +391,54 @@
>>                          };
>>                  };
>>
>> +               sdhc_2: sdhci@8804000 {
>> +                       compatible = "qcom,sdhci-msm-v5";
>> +                       reg = <0 0x08804000 0 0x1000>;
>> +
>> +                       iommus = <&apps_smmu 0x100 0x0>;
>> +                       interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
>> +                                       <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
>> +                       interrupt-names = "hc_irq", "pwr_irq";
>> +
>> +                       clocks = <&gcc GCC_SDCC2_APPS_CLK>,
>> +                                       <&gcc GCC_SDCC2_AHB_CLK>,
>> +                                       <&rpmhcc RPMH_CXO_CLK>;
>> +                       clock-names = "core", "iface", "xo";
>> +                       interconnects = <&aggre1_noc MASTER_SDCC_2 0 &mc_virt SLAVE_EBI1 0>,
>> +                                       <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_SDCC_2 0>;
>> +                       interconnect-names = "sdhc-ddr","cpu-sdhc";
>> +                       power-domains = <&rpmhpd SC7280_CX>;
>> +                       operating-points-v2 = <&sdhc2_opp_table>;
>> +
>> +                       bus-width = <4>;
>> +
>> +                       no-mmc;
>> +                       no-sdio;
> Similar question to above: why exactly would mmc not work? Are you
> saying that if someone hooked this up to a full sized SD card slot and
> placed an MMC card into the slot that it wouldn't work? Similar
> question about SDIO. If someone placed an external SDIO card into your
> slot, would it not work?
>
As mentioned above, its just to optimize SDcard scan time a little.
>> +                       max-frequency = <202000000>;
> Not needed?
>
>> +
>> +                       qcom,dll-config = <0x0007642c>;
>> +
>> +                       status = "disabled";
>> +
>> +                       sdhc2_opp_table: sdhc2-opp-table {
>> +                                       compatible = "operating-points-v2";
>> +
>> +                                       opp-100000000 {
>> +                                               opp-hz =/bits/ 64 <100000000>;
>> +                                               required-opps = <&rpmhpd_opp_low_svs>;
>> +                                               opp-peak-kBps = <1200000 76000>;
>> +                                               opp-avg-kBps = <1200000 50000>;
>> +                                       };
>> +                                       opp-202000000 {
> Blank line between the OPPs?
>
>> +                                               opp-hz = /bits/ 64 <202000000>;
>> +                                               required-opps = <&rpmhpd_opp_nom>;
>> +                                               opp-peak-kBps = <3500000 1200000>;
>> +                                               opp-avg-kBps = <5000000 100000>;
>> +                                       };
> Similar questions about why the OPPs are so vastly different from sc7180.
>
>> +                               };
>> +               };
>> +
>>                  pdc: interrupt-controller@b220000 {
>>                          compatible = "qcom,sc7280-pdc", "qcom,pdc";
>>                          reg = <0 0x0b220000 0 0x30000>;
>> @@ -374,6 +485,108 @@
>>                                  pins = "gpio46", "gpio47";
>>                                  function = "qup13";
>>                          };
>> +
>> +                       sdc1_on: sdc1-on {
>> +                               clk {
>> +                                       pins = "sdc1_clk";
>> +                                       bias-disable;
>> +                                       drive-strength = <16>;
>> +                               };
>> +
>> +                               cmd {
>> +                                       pins = "sdc1_cmd";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <10>;
>> +                               };
>> +
>> +                               data {
>> +                                       pins = "sdc1_data";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <10>;
>> +                               };
>> +
>> +                               rclk {
>> +                                       pins = "sdc1_rclk";
>> +                                       bias-pull-down;
>> +                               };
> * generally "bias" doesn't belong in the SoC file but instead should
> be in the board file. Some boards might have external pulls (even if
> the internal ones would work fine, hardware designers do weird things)
> and thus might need to disable the internal ones (double pulls are not
> great).
>
> * generally drive-strength doesn't belong in the SoC file but should
> be in the board file. Different boards with different layouts might
> need different drive strengths, right?
>
> If you remove those two things, I guess there's not actually much left
> in the SoC dtsi file so I guess move these all to the board file? That
> seems to be what we ended up with in "qrb5165-rb5.dts" / "sm8250.dtsi"
> which is an example of a board using the new style of pinctrl for
> devicetree.
>
>
>> +                       };
>> +
>> +                       sdc1_off: sdc1-off {
>> +                               clk {
>> +                                       pins = "sdc1_clk";
>> +                                       bias-disable;
>> +                                       drive-strength = <2>;
>> +                               };
>> +
>> +                               cmd {
>> +                                       pins = "sdc1_cmd";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <2>;
>> +                               };
>> +
>> +                               data {
>> +                                       pins = "sdc1_data";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <2>;
>> +                               };
>> +
>> +                               rclk {
>> +                                       pins = "sdc1_rclk";
>> +                                       bias-pull-down;
>> +                               };
>> +                       };
> No need for a sleep state for the rclk since it's the same as the
> active state, right? NOTE: one way to handle this would be to define
> one node per pingroup and thus do something like:
>
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&sdc1_clk>, <&sdc1_cmd>, <&sdc1_data>, <&sdc1_rclk>;
> pinctrl-1 = <&sdc1_clk_sleep>, <&sdc1_cmd_sleep>, <&sdc1_data_sleep>,
> <&sdc1_rclk>;
>
> I do wish we could avoid having to duplicate the "bias" in every board
> file. Hrm, I wonder if this could be made simpler by actually putting
> the "sleep" states in the sc7180.dtsi file (not the board file) and
> using "bias-bus-hold" to avoid it being board specific?
>
> Thus (assuming it works), the total summary would be:
>
> 1. Board dts file fully defines "sdc1_clk", "sdc1_cmd", "sdc1_data",
> "sdc1_rclk", specifying whatever bias and drive strength needed for
> the board.
>
> 2. SoC dtsi fully defines "sdc1_clk_sleep", "sdc1_cmd_sleep",
> "sdc1_data_sleep", "sdc1_rclk_sleep", specifying drive-strength of 2
> (for outputs) and "bias-bus-hold" which is OK for all board.
>
>
>> +
>> +                       sdc2_on: sdc2-on {
>> +                               clk {
>> +                                       pins = "sdc2_clk";
>> +                                       bias-disable;
>> +                                       drive-strength = <16>;
>> +                               };
>> +
>> +                               cmd {
>> +                                       pins = "sdc2_cmd";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <10>;
>> +                               };
>> +
>> +                               data {
>> +                                       pins = "sdc2_data";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <10>;
>> +                               };
>> +
>> +                               sd-cd {
>> +                                       pins = "gpio91";
> NOTE: even if we find some reason to keep some of the pinctrl in the
> SoC dtsi file, the card detect almost certainly needs to move _fully_
> to the board dts file. Different boards could use a different card
> detect pin.
>
>> +                                       bias-pull-up;
>> +                                       drive-strength = <2>;
> Drive strength isn't needed for input pins. Please remove.
>
>> +                               };
>> +                       };
>> +
>> +                       sdc2_off: sdc2-off {
>> +                               clk {
>> +                                       pins = "sdc2_clk";
>> +                                       bias-disable;
>> +                                       drive-strength = <2>;
>> +                               };
>> +
>> +                               cmd {
>> +                                       pins = "sdc2_cmd";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <2>;
>> +                               };
>> +
>> +                               data {
>> +                                       pins = "sdc2_data";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <2>;
>> +                               };
>> +
>> +                               sd-cd {
>> +                                       pins = "gpio91";
>> +                                       bias-pull-up;
>> +                                       drive-strength = <2>;
>> +                               };
> There's definitely no need for a separate sleep state for the CD line.
>
>
> -Doug

  reply	other threads:[~2021-03-25  4:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 18:17 [PATCH V2] arm64: dts: qcom: sc7280: Add nodes for eMMC and SD card Shaik Sajida Bhanu
2021-03-23  7:01 ` Stephen Boyd
2021-03-24 15:23   ` sbhanu
2021-03-24 15:57     ` Stephen Boyd
2021-03-24 16:28       ` Stephen Boyd
2021-03-25  3:36         ` Veerabhadrarao Badiganti
2021-03-25 16:20           ` Doug Anderson
2021-03-23 16:11 ` Doug Anderson
2021-03-25  3:58   ` Veerabhadrarao Badiganti [this message]
2021-03-25 16:17     ` Doug Anderson
2021-04-01  9:58       ` sbhanu
2021-03-26  6:56     ` sbhanu
2021-03-29 14:56       ` Doug Anderson
2021-04-13 10:59         ` sbhanu
2021-04-14 20:25           ` Doug Anderson
2021-04-16  9:52             ` Georgi Djakov
2021-04-20 17:20             ` sbhanu
2021-04-20 20:14               ` Doug Anderson
2021-04-28 10:47                 ` sbhanu
2021-04-28 15:13                   ` Doug Anderson
2021-04-29 20:44                     ` Georgi Djakov
2021-06-01  9:58                       ` sbhanu

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=b77f207b-2d90-3c8b-857f-625bd3867ed1@codeaurora.org \
    --to=vbadigan@codeaurora.org \
    --cc=adrian.hunter@intel.com \
    --cc=agross@kernel.org \
    --cc=asutoshd@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=cang@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@google.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=nitirawa@codeaurora.org \
    --cc=pragalla@codeaurora.org \
    --cc=rampraka@codeaurora.org \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=sartgarg@codeaurora.org \
    --cc=sayalil@codeaurora.org \
    --cc=sbhanu@codeaurora.org \
    --cc=sibis@codeaurora.org \
    --cc=stummala@codeaurora.org \
    --cc=ulf.hansson@linaro.org \
    /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).