Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <1650964532-9379-1-git-send-email-quic_spathi@quicinc.com>
In-Reply-To: <1650964532-9379-1-git-send-email-quic_spathi@quicinc.com>
From:   Brian Norris <briannorris@chromium.org>
Date:   Tue, 26 Apr 2022 11:02:52 -0700
Message-ID: <CA+ASDXMkzrqkDdb=y4DpK5Ot=XFtj6aAv7-mSBoGP5rDJZanpA@mail.gmail.com>
Subject: Re: [PATCH V1] mmc: core: Select HS mode in device first and then in
 the host
To:     Srinivasarao Pathipati <quic_spathi@quicinc.com>
Cc:     Ulf Hansson <ulf.hansson@linaro.org>, avri.altman@wdc.com,
        Linus Walleij <linus.walleij@linaro.org>,
        vbadigan@codeaurora.org, Shawn Lin <shawn.lin@rock-chips.com>,
        s.shtylyov@omp.ru, merez@codeaurora.org,
        wsa+renesas@sang-engineering.com, sayalil@codeaurora.org,
        linux-mmc@vger.kernel.org,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Kishor Krishna Bhat <quic_kishkris@quicinc.com>,
        kamasali <quic_kamasali@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Tue, Apr 26, 2022 at 2:16 AM Srinivasarao Pathipati
<quic_spathi@quicinc.com> wrote:
>
> From: Sayali Lokhande <sayalil@codeaurora.org>
>
> While switching from hs400 to hs200 mode, high speed mode
> timing should be selected in the device before changing the
> clock frequency in the host. But current implementation,
> (mmc_hs400_to_hs200) first updates the frequency in the host
> and then updates mode in the device. This is a spec violation.
> Hence update the sequence to comply with the spec.

I'm a bit new to interpreting eMMC specs, but are you sure this is a
violation? In JESD84-B51, I see:

"The bus frequency can be changed at any time (under the restrictions
of maximum data transfer frequency, defined by the Device, and the
identification frequency defined by the standard document)."

I think that suggests we can lower the host clock first, and then
lower the device timing. And (according to my limited knowledge) that
makes sense too: the device timing is a "maximum" (to some extent) and
we're free to run the host bus somewhat slower.

And on the flip side: it sounds like you may be _introducing_ a spec
violation (that we'll be running the host faster than the device
timing, briefly)?

Apologies if I'm off base. But you did CC me ;)

Regards,
Brian