[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <DM6PR04MB657515154B27EB6B9E57A3D7FCFA9@DM6PR04MB6575.namprd04.prod.outlook.com>
Date: Wed, 27 Apr 2022 08:04:20 +0000
From: Avri Altman <Avri.Altman@....com>
To: Brian Norris <briannorris@...omium.org>,
Srinivasarao Pathipati <quic_spathi@...cinc.com>
CC: Ulf Hansson <ulf.hansson@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
"vbadigan@...eaurora.org" <vbadigan@...eaurora.org>,
Shawn Lin <shawn.lin@...k-chips.com>,
"s.shtylyov@....ru" <s.shtylyov@....ru>,
"merez@...eaurora.org" <merez@...eaurora.org>,
"wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
"sayalil@...eaurora.org" <sayalil@...eaurora.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Kishor Krishna Bhat <quic_kishkris@...cinc.com>,
kamasali <quic_kamasali@...cinc.com>
Subject: RE: [PATCH V1] mmc: core: Select HS mode in device first and then in
the host
> Hi,
>
> On Tue, Apr 26, 2022 at 2:16 AM Srinivasarao Pathipati
> <quic_spathi@...cinc.com> wrote:
> >
> > From: Sayali Lokhande <sayalil@...eaurora.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)?
Ack on that.
Also, specifically, please refer to Figure 28 — HS200 Selection flow diagram.
You can see that the flow goes though:
BUS_WIDTH [183] -> from 0x06 (DDR 8bit) to 0x02 (SDR 8bit)
HS_TIMING [185] -> from 0x03(HS400) to 0x02 (HS200)
Host may changes the frequency , but it’s no needed as HS400 and HS200 use same CLK
Thanks,
Avri
>
> Apologies if I'm off base. But you did CC me ;)
>
> Regards,
> Brian
Powered by blists - more mailing lists