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

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

On 5/18/26 20:27, Florian Fainelli wrote:
> 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.

Ulf, did you want me to re-submit with that kind of detail added to the 
commit message? Also since this is a bit specific to our devices, did 
you need me to scope the fixup to the ARCH_BRCMSTB platforms somehow?

Thanks!
-- 
Florian