Re: huge emmc speed regression

From: Andriy Gapon <avg_at_FreeBSD.org>
Date: Sun, 07 Nov 2021 08:29:33 UTC
On 06/11/2021 13:05, Andriy Gapon wrote:
> On 06/11/2021 12:58, Andriy Gapon wrote:
>>
>> Upfront, I haven't tested the latest main / current yet.
>> I should really test it but that's porbably for the next weekend.

And yeah, this was already fixed in commit 4a331971d2f10 (Sep 29) by Jessica Clarke.

>> I see a huge emmc speed difference between the current from April 2021 and 
>> September 2021 (commit 5e79bba562bc303eed669dbd0d391b6c6a9c289b) on Orange Pi 
>> PC Plus using on-board eMMC card.  I use MMCCAM in both cases.
>>
>> In the old environment I see expected read speeds (with sequential dd) of 
>> around 40 MB/s.
>> In the new environment the speeds are around 300 KB/s (like a very good floppy 
>> disk of old).
>>
>> Some info from the old environment:
>> # camcontrol mmcsdcmd 2:0:0 -I
>> Host controller information
>> Host OCR: 0x300000
>> Min frequency: 400 KHz
>> Max frequency: 52 MHz
> [snip]
> 
>> Same command in the new environment looks a bit strange:
>> # camcontrol mmcsdcmd 2:0:0 -I
>> Host controller information
>> Host OCR: 0x300000
>> Min frequency: 400 KHz
>> Max frequency: 0 MHz
> [snip]
> 
> It seems that this is because the FDT does not have max-frequency property.
> The old mmc_fdt_parse() code would leave f_max alone in that case and it was set 
> to 52 MHz by the driver.
> However, the new code in mmc_fdt_parse(), or rather mmc_parse(), would reset 
> f_max to zero (despite the comment that was carried over):
> 
>          /*
>           * max-frequency is optional, drivers should tweak this value
>           * if it's not present based on the clock that the mmc controller
>           * operates on
>           */
>          max_freq = 0;
>          device_get_property(dev, "max-frequency", &max_freq, sizeof(uint64_t));
>          host->f_max = max_freq;
> 
> 


-- 
Andriy Gapon