[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=XptsmgTm-CA1tOd6Dhk7eYbU1qyewkKbBCYP02uGoovg@mail.gmail.com>
Date: Thu, 29 Sep 2016 12:47:37 -0700
From: Doug Anderson <dianders@...gle.com>
To: Shawn Lin <shawn.lin@...k-chips.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Jaehoon Chung <jh80.chung@...sung.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>
Subject: Re: [RESEND PATCH v2 2/4] mmc: core: changes frequency to hs_max_dtr
when selecting hs400es
Hi,
On Thu, Sep 22, 2016 at 5:12 PM, Shawn Lin <shawn.lin@...k-chips.com> wrote:
> Per JESD84-B51 P69, Host need to change frequency to <=52MHz
Technically Page 49. In the PDF you go to page 69, but the heading on
the top of the page says 49.
> after setting HS_TIMING to 0x1, and host may changes frequency
> to <= 200MHz after setting HS_TIMING to 0x3. That means the card
> expects the clock rate to increase from the current used f_init
> (which is less than 400KHz, but still being less than 52MHz) to
> 52MHz, otherwise we find some eMMC devices significantly report
> failure when sending status.
Technically it seems like things ought to be OK at the slow speed
since technically we're allowed to talk "high speed" at 400 kHZ (or at
any rate <= 52MHz). ...but I guess I could also see some cards not
liking that. Though I'm no expert, feel free to add my reviewed-by if
it is useful:
Reviewed-by: Douglas Anderson <dianders@...omium.org>
Powered by blists - more mailing lists