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>