linux-kernel - Re: [PATCH] mmc: sdhci-esdhc-imx: improve imx8mq emmc/sd read performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3e79d92a-6ec9-4c7a-a836-1306678c2bef@arm.com>
Date: Mon, 17 Feb 2025 12:02:04 +0000
From: Christian Loehle <christian.loehle@....com>
To: Lucas Stach <l.stach@...gutronix.de>, ziniu.wang_1@....com,
 adrian.hunter@...el.com, ulf.hansson@...aro.org
Cc: imx@...ts.linux.dev, s32@....com, shawnguo@...nel.org,
 s.hauer@...gutronix.de, linux-mmc@...r.kernel.org,
 linux-kernel@...r.kernel.org, haibo.chen@....com, kernel@...gutronix.de,
 festevam@...il.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] mmc: sdhci-esdhc-imx: improve imx8mq emmc/sd read
 performance

On 2/17/25 11:58, Lucas Stach wrote:
> Hi Luke,
> 
> Am Montag, dem 17.02.2025 um 19:06 +0800 schrieb ziniu.wang_1@....com:
>> From: Luke Wang <ziniu.wang_1@....com>
>>
>> Compared with kernel 6.1, imx8mq eMMC/SD read performance drops by about
>> 30% with kernel 6.6.
>>
>> The eMMC/SD read thread will be put to sleep until the hardware completes
>> data transfer. Normally, the read thread will be woken up immediately
>> when the data transfer is completed. However, due to a known ic bug, if
>> imx8mq is in cpuidle, it will take a long time (about 500us) to exit
>> cpuidle. As a result, the read thread cannot immediately read the next
>> data block, affecting the read performance.
>>
> Is this really a problem with the upstream kernel? i.MX8MQ upstream
> does not use the deeper PSCI idle states, but only uses WFI, so I doubt
> that upstream is affected by this issue.
> 
> Regards,
> Lucas

Furthermore if that were to be the case the correct solution would probably
to have that reflected in the dts, too?