Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

[Florian Fainelli <florian.fainelli@broadcom.com>]

On 5/12/26 06:33, Ulf Hansson wrote:
> On Mon, 11 May 2026 at 18:01, Florian Fainelli
> <florian.fainelli@broadcom.com> wrote:
>>
>> On 5/11/26 07:18, Ulf Hansson wrote:
>>> On Mon, 13 Apr 2026 at 20:06, Florian Fainelli
>>> <florian.fainelli@broadcom.com> wrote:
>>>>
>>>> The Kioxia 016G01 eMMC device does not exit SLEEP mode when sending CMD0
>>>> which prevents the system from properly resuming from S3 warm boot where
>>>> the eMMC is necessary to pull in the boot components.
>>>
>>> Is the bug confirmed by Kioxia?
>>
>> We've been going back and forth with them without much progress as far
>> as a resolution goes. Since there was no progress and I would like to
>> get this included in downstream kernels at some point, this was submitted.
>>
>>>
>>> If not, can you explain a bit more what is actually happening during
>>> system resume?
>>
>> Upon entering Suspend-to-DRAM, the eMMC will be put into sleep mode.
>> When our systems resume, one of our hardware cores driving the eMMC (HIF
>> block) in command mode will send a CMD0 command for the eMMC device to
> 
> Is the CMD0 sent solely by HW/FW before the mmc core executes
> _mmc_resume() during system resume?

That is correct. The sequence basically goes like this: HW sends CMD0, 
then FW pulls in boot code, identifies this is a Suspend to DRAM, does 
its steps, and eventually Linux resumes and calls _mmc_resume().

> 
>> exit SLEEP mode. The Kioxia 016G01 device takes 10ms rather than the
>> tSLEEP_EXIT value of 1ms which is advertised and so our HIF block does
> 
> Can you please clarify what tSLEEP_EXIT refers to? Are you referring
> to the S_A_TIMEOUT in the EXT_CSD register for the eMMC card?

Yes, sorry I am referring to S_A_TIMEOUT in the EXT_CSD register.

> 
> Anyway, waking up an eMMC from sleep state in just 1ms sounds a bit
> optimistic to me.

Fair enough, but AFAIR we wait up to 30ms before declaring a timeout, 
every other vendor we have seen exits and acknowledges boot within 
1-10ms at most. Similarly if the device is not in SLEEP, then it 
acknowledges boot within 1ms.

> 
>> not see the Boot ACK pattern in time and does not service the read
>> request from the processor that wanted to read from eMMC, we get a reset
>> of the system, rather than continue booting.
>>
>> When SLEEP is not enabled, the eMMC device responds within tSLEEP_EXIT
>> as advertised and we don't have that problem.
> 
> Okay, I see.
> 
> In this regard, it's important to understand for me how the mmc host
> driver (and the HW/FW) manages VCC and VCCQ when the mmc core calls
> mmc_power_off() from _mmc_suspend()?
> 
> Does this turn off any of these regulators or what happens to them
> during system suspend?

We don't have software controlled regulators for VCC and VCCQ and our 
reference boards using that specific eMMC device keep it powered on 
through suspend-to-DRAM. This is the very reason why if it stays in 
sleep mode, powered on, and then we attempt to boot from eMMC we have 
this issue.

> 
>>
>> So I suppose I could reformulate the commit message and give some more
>> details here if you would like?
> 
> Yes, but let's discuss a bit more first.
> 
> Kind regards
> Uffe


-- 
Florian