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

[Florian Fainelli]

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?

Thanks!
--
Florian