linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: 冯锐 <rui_feng@realsil.com.cn>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: 答复: [PATCH 3/3] mmc: rtsx: Add SD Express mode support for RTS5261
Date: Thu, 22 Oct 2020 06:04:05 +0000	[thread overview]
Message-ID: <dd210290eef6467cbffca8cbaddb8b84@realsil.com.cn> (raw)
In-Reply-To: <CAPDyKFrnkF3mU5PJsy0VtEjPSToktSsRRtyMvQF97vymc+rY5A@mail.gmail.com>

> 
> On Fri, 25 Sep 2020 at 03:57, <rui_feng@realsil.com.cn> wrote:
> >
> > From: Rui Feng <rui_feng@realsil.com.cn>
> >
> > RTS5261 support legacy SD mode and SD Express mode.
> > In SD7.x, SD association introduce SD Express as a new mode.
> > This patch makes RTS5261 support SD Express mode.
> 
> As per patch 2, can you please add some more information about what changes
> are needed to support SD Express? This just states that the support is
> implemented, but please elaborate how.
> 
> >
> > Signed-off-by: Rui Feng <rui_feng@realsil.com.cn>
> > ---
> >  drivers/mmc/host/rtsx_pci_sdmmc.c | 59
> > +++++++++++++++++++++++++++++++
> >  1 file changed, 59 insertions(+)
> >
> > diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
> > b/drivers/mmc/host/rtsx_pci_sdmmc.c
> > index 2763a376b054..efde374a4a5e 100644
> > --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> > +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> > @@ -895,7 +895,9 @@ static int sd_set_bus_width(struct
> > realtek_pci_sdmmc *host,  static int sd_power_on(struct
> > realtek_pci_sdmmc *host)  {
> >         struct rtsx_pcr *pcr = host->pcr;
> > +       struct mmc_host *mmc = host->mmc;
> >         int err;
> > +       u32 val;
> >
> >         if (host->power_state == SDMMC_POWER_ON)
> >                 return 0;
> > @@ -922,6 +924,14 @@ static int sd_power_on(struct realtek_pci_sdmmc
> *host)
> >         if (err < 0)
> >                 return err;
> >
> > +       if (PCI_PID(pcr) == PID_5261) {
> > +               val = rtsx_pci_readl(pcr, RTSX_BIPR);
> > +               if (val & SD_WRITE_PROTECT) {
> > +                       pcr->extra_caps &=
> ~EXTRA_CAPS_SD_EXPRESS;
> > +                       mmc->caps2 &= ~(MMC_CAP2_SD_EXP |
> > + MMC_CAP2_SD_EXP_1_2V);
> 
> This looks a bit weird to me. For a write protected card you want to disable the
> SD_EXPRESS support, right?
> 
Right. If end user insert a write protected SD express card, I will disable SD_EXPRESS support.
If host switch to SD EXPRESS mode, the card will be recognized as a writable PCIe/NVMe device,
I think this is not end user's purpose.

> Is there no mechanism to support read-only PCIe/NVMe based storage devices?
> If that is the case, maybe it's simply better to not support the readonly option
> at all for SD express cards?
> 
I think there's no mechanism to support read-only PCIe/NVMe based storage devices.
But different venders may have different opinions. This is only Realtek's opinion.

> > +               }
> > +       }
> > +
> >         host->power_state = SDMMC_POWER_ON;
> >         return 0;
> >  }
> > @@ -1127,6 +1137,8 @@ static int sdmmc_get_cd(struct mmc_host *mmc)
> >         if (val & SD_EXIST)
> >                 cd = 1;
> >
> > +       if (pcr->extra_caps & EXTRA_CAPS_SD_EXPRESS)
> > +               mmc->caps2 |= MMC_CAP2_SD_EXP |
> MMC_CAP2_SD_EXP_1_2V;
> 
> This looks wrong. You shouldn't be using the ->get_cd() callback to re-enable
> mmc caps.
> 
> Normally set the mmc caps while host probes (from the ->probe() callback), but
> I guess this is kind of a special case, as the read-only switch state isn't known
> until we have powered on the card, right?
> 
Right.

> If that is the case, I suggest to re-enable the mmc caps from the
> ->set_ios() callback instead, when ios->power_mode == MMC_POWER_OFF.
> 
I will move it to sd_power_on().

> >         mutex_unlock(&pcr->pcr_mutex);
> >
> >         return cd;
> > @@ -1308,6 +1320,50 @@ static int sdmmc_execute_tuning(struct
> mmc_host *mmc, u32 opcode)
> >         return err;
> >  }
> >
> > +static int sdmmc_init_sd_express(struct mmc_host *mmc, struct mmc_ios
> > +*ios) {
> > +       u32 relink_time, val;
> > +       struct realtek_pci_sdmmc *host = mmc_priv(mmc);
> > +       struct rtsx_pcr *pcr = host->pcr;
> > +
> > +       /*
> > +        * If card has PCIe availability and WP if off,
> > +        * reader switch to PCIe mode.
> > +        */
> > +       val = rtsx_pci_readl(pcr, RTSX_BIPR);
> > +       if (!(val & SD_WRITE_PROTECT)) {
> 
> This should not be needed, as you have already checked the write protect bit
> before enabling the mmc caps for SD EXPRESS, right?
> 
Right.

> > +               /* Set relink_time for changing to PCIe card */
> > +               relink_time = 0x8FFF;
> > +
> > +               rtsx_pci_write_register(pcr, 0xFF01, 0xFF, relink_time);
> > +               rtsx_pci_write_register(pcr, 0xFF02, 0xFF, relink_time >>
> 8);
> > +               rtsx_pci_write_register(pcr, 0xFF03, 0x01, relink_time
> > + >> 16);
> > +
> > +               rtsx_pci_write_register(pcr, PETXCFG, 0x80, 0x80);
> > +               rtsx_pci_write_register(pcr, LDO_VCC_CFG0,
> > +                       RTS5261_LDO1_OCP_THD_MASK,
> > +                       pcr->option.sd_800mA_ocp_thd);
> > +
> > +               if (pcr->ops->disable_auto_blink)
> > +                       pcr->ops->disable_auto_blink(pcr);
> > +
> > +               /* For PCIe/NVMe mode can't enter delink issue */
> > +               pcr->hw_param.interrupt_en &= ~(SD_INT_EN);
> > +               rtsx_pci_writel(pcr, RTSX_BIER,
> > + pcr->hw_param.interrupt_en);
> > +
> > +               rtsx_pci_write_register(pcr, RTS5260_AUTOLOAD_CFG4,
> > +                       RTS5261_AUX_CLK_16M_EN,
> RTS5261_AUX_CLK_16M_EN);
> > +               rtsx_pci_write_register(pcr, RTS5261_FW_CFG0,
> > +                       RTS5261_FW_ENTER_EXPRESS,
> RTS5261_FW_ENTER_EXPRESS);
> > +               rtsx_pci_write_register(pcr, RTS5261_FW_CFG1,
> > +                       RTS5261_MCU_BUS_SEL_MASK |
> RTS5261_MCU_CLOCK_SEL_MASK
> > +                       | RTS5261_MCU_CLOCK_GATING |
> RTS5261_DRIVER_ENABLE_FW,
> > +                       RTS5261_MCU_CLOCK_SEL_16M |
> RTS5261_MCU_CLOCK_GATING
> > +                       | RTS5261_DRIVER_ENABLE_FW);
> > +       }
> > +       return 0;
> > +}
> > +
> >  static const struct mmc_host_ops realtek_pci_sdmmc_ops = {
> >         .pre_req = sdmmc_pre_req,
> >         .post_req = sdmmc_post_req,
> > @@ -1317,6 +1373,7 @@ static const struct mmc_host_ops
> realtek_pci_sdmmc_ops = {
> >         .get_cd = sdmmc_get_cd,
> >         .start_signal_voltage_switch = sdmmc_switch_voltage,
> >         .execute_tuning = sdmmc_execute_tuning,
> > +       .init_sd_express = sdmmc_init_sd_express,
> >  };
> >
> >  static void init_extra_caps(struct realtek_pci_sdmmc *host) @@
> > -1338,6 +1395,8 @@ static void init_extra_caps(struct realtek_pci_sdmmc
> *host)
> >                 mmc->caps |= MMC_CAP_8_BIT_DATA;
> >         if (pcr->extra_caps & EXTRA_CAPS_NO_MMC)
> >                 mmc->caps2 |= MMC_CAP2_NO_MMC;
> > +       if (pcr->extra_caps & EXTRA_CAPS_SD_EXPRESS)
> > +               mmc->caps2 |= MMC_CAP2_SD_EXP |
> MMC_CAP2_SD_EXP_1_2V;
> >  }
> >
> >  static void realtek_init_host(struct realtek_pci_sdmmc *host)
> > --
> > 2.17.1
> >
> 
> A follow up question:
> 
> Based upon your feedback from our earlier discussions, I believe you stated
> that the card reader driver (rtsx_pci_driver) will unregister the corresponding
> mfd/platform device that corresponds to the rtsx_pci_sdmmc_driver - when it
> gets configured to manage a PCIe/NVMe based storage device. Correct?
> 
> Perhaps I didn't get that part correctly, but if this is the case, it means that the
> ->remove() callback (rtsx_pci_sdmmc_drv_remove()) will be invoked.
> Furthermore, this will cause the ->set_ios() callback to be invoked when the
> core calls mmc_power_off() in that path. Isn't that a problem that you need to
> address?
> 
After init_sd_express() is called, mmc_power_off() will not work, so it's not a problem I need to
address.

> Kind regards
> Uffe
> 
> ------Please consider the environment before printing this e-mail.

  reply	other threads:[~2020-10-22  6:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25  1:57 [PATCH 3/3] mmc: rtsx: Add SD Express mode support for RTS5261 rui_feng
2020-10-20  6:52 ` 答复: " 冯锐
2020-10-20  8:14   ` Ulf Hansson
2020-10-21 13:59 ` Ulf Hansson
2020-10-22  6:04   ` 冯锐 [this message]
2020-10-23  8:02     ` Ulf Hansson
2020-10-23  9:14       ` Christoph Hellwig
2020-10-23 12:12         ` Ulf Hansson
2020-10-23 12:18           ` Christoph Hellwig
2020-11-12 16:42           ` Christoph Hellwig
2020-11-17  2:09             ` 冯锐
2020-10-26  8:22       ` 答复: " 冯锐
2020-10-27 12:54         ` Ulf Hansson
2020-10-27 19:37           ` Christoph Hellwig
2020-10-28  2:08           ` 答复: " 冯锐
2020-10-28 10:05           ` 冯锐
2020-10-28 10:18             ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd210290eef6467cbffca8cbaddb8b84@realsil.com.cn \
    --to=rui_feng@realsil.com.cn \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).