Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Oct 2018 00:07:03 +0200
From:      Marius Strobl <marius@freebsd.org>
To:        "Amartya, Shreyank" <Shreyank.Amartya@amd.com>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "mav@FreeBSD.org" <mav@FreeBSD.org>
Subject:   Re: FW: eMMC AMD platform
Message-ID:  <20181023220703.GF21523@alchemy.franken.de>
In-Reply-To: <SN6PR12MB28133E1584C865EA66EBC38291F50@SN6PR12MB2813.namprd12.prod.outlook.com>
References:  <SN6PR12MB2813785A929D9DD89C0E6E3391F50@SN6PR12MB2813.namprd12.prod.outlook.com> <SN6PR12MB28133E1584C865EA66EBC38291F50@SN6PR12MB2813.namprd12.prod.outlook.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 23, 2018 at 11:46:33AM +0000, Amartya, Shreyank wrote:
> Hi,
> 
> I have an AMD eMMC 5.0 controller connected to an eMMC device.
> I recently got around to enabling HS400 mode but the performance is still same what I was getting in HS200 mode.
> Is there a way to verify the HS400 mode is active?

Hi,

apart from examining the signals between SDHCI controller and eMMC
chip with a scope, I don't see a way to verify that HS400 actually
is active. However, if controller and device have been successfully
switched (i. e. including tuning and none of the operations in the
associated sequence has failed on either end) to operate at HS400
and data can be transferred between them without errors, there's no
reason to believe that HS400 shouldn't be active. If both sides don't
actually use the same transfer mode, transactions simply would fail.

> 
> Patch for enabling HS400: https://reviews.freebsd.org/D17644
> 
> In order to enable the HS400 mode I had to clear the Sampling clock select bit (Host control 2 register) and then set it later (as part of the patch).
> Now, I suspect that this led to reset of the tuning circuit and that even though HS400 mode is enabled, since it is not tuned, I do not see increase in performance. Could that be a possibility?

Well, with a controller that has known bugs in that area speculating
about what's really going on doesn't make much sense but generally what
you describe isn't plausible; if an SDHCI controller isn't tuned to the
device in a UHS-I mode requiring tuning, the result is - depending on
controller implementation and operations attempted - an interrupt with
the CRC and/or tuning error bit set in the SDHCI interrupt status.

While I haven't seen a case so far where HS400 doesn't yield more
throughput than HS200 (assuming that the eMMC chip actually can
outperform HS200 in HS400 mode, which isn't necessarily the case
depending on model and manufacturer and whether e. g. pSLC is
used), one thing to keep in mind is that sdhci(4) supports SDMA
at most so far, i. e. none of the ADMA modes. In turn, that AMD
controller might perform badly with SDMA. Off-hand I'm not sure
whether the alignment restrictions of that controller for both
ADMA and SDMA might impact one of the modes more than others.
In any case, you'd need to disable the use of the ADMA modes in
Linux in order to get to throughputs that make sense to compare
(there are other cases despite DMA modes where either FreeBSD or
Linux takes better advantage of MMC and SDHCI features, though).

Marius




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181023220703.GF21523>