On 04/10/2021 12:07, Marek Szyprowski wrote: > Hi Jaehoon, > > On 01.10.2021 02:40, Jaehoon Chung wrote: >> On 9/27/21 8:09 PM, Krzysztof Kozlowski wrote: >>> On Mon, 13 Sept 2021 at 06:32, Christian Hewitt >>> <christianshewitt@xxxxxxxxx> wrote: >>>> https://protect2.fireeye.com/v1/url?k=6f7d4070-30e6793d-6f7ccb3f-0cc47aa8f5ba-2c8976d4b015314f&q=1&e=776d64d2-22f3-400a-a241-42af8b5f60d0&u=https%3A%2F%2Fgithub.com%2Fchewitt%2Flinux%2Fcommit%2F8a4ebfb43a394e5dc5e9fafc92a50d5e81a4f258 >>>> >>>> If I boot any recent kernel without the above patch, the emmc module on the XU4 is not detected, see: >>>> >>>> Without: >>>> >>>> [ 3.227837] mmc0: tuning execution failed: -5 >>>> [ 3.231229] mmc0: error -5 whilst initialising MMC card >>>> [ 3.536450] mmc0: tuning execution failed: -5 >>>> [ 3.539680] mmc0: error -5 whilst initialising MMC card >>>> [ 3.794056] mmc0: tuning execution failed: -5 >>>> [ 3.794212] mmc0: error -5 whilst initialising MMC card >>>> [ 4.111097] mmc0: tuning execution failed: -5 >>>> [ 4.115356] mmc0: error -5 whilst initialising MMC card >>>> [ 4.426164] mmc0: tuning execution failed: -5 >>>> [ 4.429678] mmc0: error -5 whilst initialising MMC card >>>> [ 4.756226] mmc0: tuning execution failed: -5 >>>> [ 4.760641] mmc0: error -5 whilst initialising MMC card >>>> >>>> With: >>>> >>>> [ 3.305461] mmc0: new HS400 MMC card at address 0001 >>>> [ 3.307444] mmcblk0: mmc0:0001 8GME4R 7.28 GiB >>>> [ 3.308132] mmcblk0boot0: mmc0:0001 8GME4R 4.00 MiB >>>> [ 3.309172] mmcblk0boot1: mmc0:0001 8GME4R 4.00 MiB >>>> [ 3.310255] mmcblk0rpmb: mmc0:0001 8GME4R 512 KiB, chardev (246:0) >>>> [ 3.315963] mmcblk0: p1 p2 >>>> >>>> The patch is sourced from a Linux 5.4 patchset used by several retro gaming distros for XU4 images shared in the HardKernel forums. I would be happy to submit it, but the original patch has no description in the commit message. Not being a coding developer myself I cannot explain whether it is correct or what it’s doing to add one. All I can do is confirm that it works, and is needed. SD card boot is not an issue. >>>> >>>> I’ve CC’d the original author (Marian) in case he remembers the patch and can comment. It would be good to get this upstream. >>> The patch might have sense but would require describing conditions - >>> what MMC input and output clock settings work and which do not work. >>> Also someone would need to test other Exynos5422 boards and other >>> Exynos with HS200 and HS400 support (Exynos5433, Exynos7). I think >>> this should not affect SD cards. >> >> Thanks for adding me. >> I didn't see XU4 booting fail with linux-5.15-rc1 kernel. >> >> [ 4.561934] mmc1: new HS400 MMC card at address 0001 >> [ 4.572401] mmcblk1: mmc1:0001 SDW16G 14.7 GiB >> [ 4.602555] mmcblk1: p1 p2 p3 p4 < p5 p6 p7 > >> [ 4.623201] mmcblk1boot0: mmc1:0001 SDW16G 4.00 MiB >> [ 4.640465] mmcblk1boot1: mmc1:0001 SDW16G 4.00 MiB >> >> Which kernel version did you use? > > I came across this patch some time ago, but also didn't manage to > reproduce the issue - in my case eMMC was always detected properly. It > might be related to particular version or series of the eMMC modules. > > I've just checked that patch on XU3, XU4, PeachPi and TM2e boards. All > are working properly with it. > > I've also tried to benchmark the impact of that change and in some case > it causes some performance degradation. > > The main difference is clock configuration. Before this patch (XU4): > > # dmesg | grep mmc0 > mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, > actual 396825HZ div = 63) > mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 200000000Hz, > actual 200000000HZ div = 0) > mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, > actual 50000000HZ div = 0) > mmc_host mmc0: Bus speed (slot 0) = 400000000Hz (slot req 200000000Hz, > actual 200000000HZ div = 1) > mmc0: new HS400 MMC card at address 0001 > mmcblk0: mmc0:0001 SDW16G 14.7 GiB > mmcblk0boot0: mmc0:0001 SDW16G 4.00 MiB > mmcblk0boot1: mmc0:0001 SDW16G 4.00 MiB > mmcblk0rpmb: mmc0:0001 SDW16G 4.00 MiB, chardev (245:0) > > After applying the patch (mmc device number is random depending on the > boot): > > # dmesg | grep mmc1 > [ 3.619177] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req > 400000Hz, actual 396825HZ div = 63) > [ 4.057167] mmc_host mmc1: Bus speed (slot 0) = 200000000Hz (slot req > 200000000Hz, actual 200000000HZ div = 0) > [ 4.070040] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req > 52000000Hz, actual 50000000HZ div = 0) > [ 4.089028] mmc_host mmc1: Bus speed (slot 0) = 266666666Hz (slot req > 200000000Hz, actual 133333333HZ div = 1) > [ 4.102296] mmc1: new HS400 MMC card at address 0001 > [ 4.119072] mmcblk1: mmc1:0001 SDW16G 14.7 GiB > [ 4.173507] mmcblk1boot0: mmc1:0001 SDW16G 4.00 MiB > [ 4.196210] mmcblk1boot1: mmc1:0001 SDW16G 4.00 MiB > [ 4.215163] mmcblk1rpmb: mmc1:0001 SDW16G 4.00 MiB, chardev (245:0) > > The performance has been measured with: > > # dd if=/dev/mmcblk1p6 of=/dev/null bs=128k > 31944+0 records in > 31944+0 records out > 4186963968 bytes (4.2 GB) copied, 36.6981 s, 114 MB/s > > Results (XU4 board): > > exynos_defconfig: 145 MB/s (before) vs 114 MB/s (after) > exynos_defconfig + all devfreqs set to performance: 146 MB/s vs 115 MB/s > exynos_defconfig + cpufreq & all devfreqs set to performance: 154 MB/s > vs 139 MB/s > exynos_defconfig + CONFIG_ARM_EXYNOS_BUS_DEVFREQ disabled: 130 MB/s vs > 108 MB/s > exynos_defconfig + CONFIG_CPUFREQ_DT disabled: 69 MB/s (no impact) > exynos_defconfig + CONFIG_ARM_EXYNOS_BUS_DEVFREQ & CONFIG_CPUFREQ_DT: 66 > MB/s (no impact) > > > Maybe some other clock configuration (I mean the rate of the top-level > clocks or even PLLS) will solve the issue without degrading the > performance, but it is hard to judge that without reproducing the issue. > Thanks for testing and performance measurements. The read speed seems to be a direct effect of lower mmc bus frequency (DIVRATIO changed from 2 to 3). What next? Except what Marek suggested, maybe compare MMC card capabilities and try to find a difference? For example Marek's eMMC (at least one with logs) is from Sandisk SDW16G. Christian's and Marian's (Memeka / mihailescu2m) is apparently Samsung's 8GME4R. Because the patch reduces performance and not all users are affected, I have some doubts. Maybe use by default lower clock (so as in this patch) but if card is in list of known good cards go higher? Another idea is to use always slower bus because it is simply safer and we do not have resources to test 100x of different eMMC modules... Any comments from you? Best regards, Krzysztof
