Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1629132650-26277-1-git-send-email-sbhanu@codeaurora.org>
In-Reply-To: <1629132650-26277-1-git-send-email-sbhanu@codeaurora.org>
From:   Doug Anderson <dianders@google.com>
Date:   Tue, 17 Aug 2021 06:58:18 -0700
Message-ID: <CAD=FV=UqFczZ6tLzVuXhgKG9teSNTGt_RdqAxP4eXBN_eDDAtQ@mail.gmail.com>
Subject: Re: [PATCH V1] arm64: dts: qcom: sc7180: Use maximum drive strength
 values for eMMC
To:     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>,
        pragalla@codeaurora.org, nitirawa@codeaurora.org,
        Ram Prakash Gupta <rampraka@codeaurora.org>,
        Sayali Lokhande <sayalil@codeaurora.org>,
        sartgarg@codeaurora.org, cang@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>,
        Stephen Boyd <swboyd@chromium.org>,
        Matthias Kaehlcke <mka@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Mon, Aug 16, 2021 at 9:51 AM Shaik Sajida Bhanu
<sbhanu@codeaurora.org> wrote:
>
> The current drive strength values are not sufficient on non discrete
> boards and this leads to CRC errors during switching to HS400 enhanced
> strobe mode.
>
> Hardware simulation results on non discrete boards shows up that use the
> maximum drive strength values for data and command lines could helps
> in avoiding these CRC errors.
>
> So, update data and command line drive strength values to maximum.
>
> Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
> ---
>  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

I found this CL because you created a bug for it (thanks!), but it
would have also been nice if you had CCed some folks from Google that
work on the trogdor project on your patch.


> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> index 0f2b3c0..79d7aa6 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> @@ -1524,13 +1524,13 @@ ap_spi_fp: &spi10 {
>                 pinconf-cmd {
>                         pins = "sdc1_cmd";
>                         bias-pull-up;
> -                       drive-strength = <10>;
> +                       drive-strength = <16>;
>                 };
>
>                 pinconf-data {
>                         pins = "sdc1_data";
>                         bias-pull-up;
> -                       drive-strength = <10>;
> +                       drive-strength = <16>;

I could be convinced that this is the right thing to do, but I want to
really make sure that it has had sufficient testing. Specifically as
this patch is written we'll be updating the drive strength for all
boards. Increasing the drive strength can sometimes introduce new
problems (reflections, noise, ...) so we have to be confident that
we're not breaking someone that used to work by increasing the drive
strength here. How much has this been tested?

From the discussions in the bugs, it seemed like the increased drive
strength was only needed for one eMMC part and that eMMC part still
had problems even after the increased drive strength, it just had
fewer problems. It would be good to confirm that I got my data
straight, but if it's right I'd be inclined _not_ to increase the
drive strength and simply to make sure we don't use that eMMC part (or
solve the problems with it in a different way). I seem to remember
that there were other eMMC-related values that could be set. Any
chance the problems are really there? Like `fixed-emmc-driver-type`?

-Doug