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

[Ulf Hansson]

On Thu, May 28, 2026 at 1:41 AM Florian Fainelli
<florian.fainelli@xxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxx> wrote:
> >>>
> >>> On 5/11/26 07:18, Ulf Hansson wrote:
> >>>> On Mon, 13 Apr 2026 at 20:06, Florian Fainelli
> >>>> <florian.fainelli@xxxxxxxxxxxx> 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?

Apologize for the delay, I have been a bit busy with administrative
kind of work when changing employment.

I will respond as soon as I can to your previous email to help figure
out the way forward.

Kind regards
Uffe