Hi Haibo,
Could you please take a look?
Thanks
On Thu, Jan 21, 2021 at 10:26 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
> + Fabio, Haibo
>
> On Thu, 21 Jan 2021 at 10:54, Wang, Xiaolei <Xiaolei.Wang@xxxxxxxxxxxxx> wrote:
> >
> > Hi
> >
> > >Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > >Can you elaborate more what happens?
> >
> > When I use the mkfs.f2fs tool to format the eMMC file system on the imx8qxp board,
> > because mkfs.f2fs will use secdiscard first, when entering mmc_blk_issue_secdiscard_rq erase,
> > once the parameters are passed into MMC_SECURE_TRIM1_ARG, this function will take a long time to return .
> > The program has not ended, has been in TASK_UNINTERRUPTIBLE state.
> >
> > I compared the mkfs.ext4 tool to format the file system. Because it directly uses mmc_blk_issue_discard_rq,
> > this is a normal formatting phenomenon.
> >
> > mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq are just different commands and parameters sent by the host as a bus.
> > I did not see the description of trim in the data sheet. Could the host driver cause this problem?
>
> Yes, it can - and we have had issues like these before. So before
> adding a card quirk, I think we need to make sure this isn't the case.
>
> When using MMC_SECURE_TRIM1_ARG, it's very likely that the request
> takes longer to complete.
>
> The mmc host is responsible for either dealing with busy detection
> with the help of its HW/controller - or if that can't be supported,
> the mmc core falls back to polling the card for busy with a CMD13.
>
> See mmc_do_erase() in /drivers/mmc/core/core.c
>
> >
> > Note:
> > The host driver I use is sdhci-esdhc-imx.c
>
> Alright, I have looped in Fabio and Haibo that knows this driver,
> let's see if they can help.
>
> >
> > Thanks
> > Xiaolei
>
> Kind regards
> Uffe
>
> >
> > -----Original Message-----
> > From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> > Sent: Wednesday, January 20, 2021 9:41 PM
> > To: Wang, Xiaolei <Xiaolei.Wang@xxxxxxxxxxxxx>
> > Cc: Pali Rohár <pali@xxxxxxxxxx>; Lee Jones <lee.jones@xxxxxxxxxx>; linux-mmc@xxxxxxxxxxxxxxx; Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
> > Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> >
> > [Please note this e-mail is from an EXTERNAL e-mail address]
> >
> > On Mon, 18 Jan 2021 at 05:27, Xiaolei Wang <xiaolei.wang@xxxxxxxxxxxxx> wrote:
> > >
> > > R1J57L mmc chip hw capibility indicates that it supports trim
> > > function, but this function does not work properly, the SDIO bus does
> > > not respond, and the IO has been waiting so set quirks to skip trim
> >
> > Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > Can you elaborate more what happens?
> >
> > Kind regards
> > Uffe
> >
> > >
> > > Signed-off-by: Xiaolei Wang <xiaolei.wang@xxxxxxxxxxxxx>
> > > ---
> > > drivers/mmc/core/quirks.h | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > > index d68e6e513a4f..63e02391c133 100644
> > > --- a/drivers/mmc/core/quirks.h
> > > +++ b/drivers/mmc/core/quirks.h
> > > @@ -89,6 +89,8 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = {
> > > MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> > > MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > + MMC_FIXUP("R1J57L", CID_MANFID_MICRON, CID_OEMID_ANY, add_quirk_mmc,
> > > + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > >
> > > /*
> > > * On Some Kingston eMMCs, performing trim can result in @@
> > > -98,6 +100,8 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = {
> > > MMC_QUIRK_TRIM_BROKEN),
> > > MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
> > > MMC_QUIRK_TRIM_BROKEN),
> > > + MMC_FIXUP("R1J57L", CID_MANFID_MICRON, CID_OEMID_ANY, add_quirk_mmc,
> > > + MMC_QUIRK_TRIM_BROKEN),
> > >
> > > END_FIXUP
> > > };
> > > --
> > > 2.25.1
> > >
