The R/W performance of GL9763E is low with some platforms, which
support ASPM mechanism, due to entering L1 state very frequently
in R/W process. Enlarge its ASPM L1 entry delay to improve the
R/W performance of GL9763E.
Signed-off-by: Renius Chen <[email protected]>
---
drivers/mmc/host/sdhci-pci-gli.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index c6a107d7c742..2d13bfcbcacf 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -88,6 +88,10 @@
#define PCIE_GLI_9763E_SCR 0x8E0
#define GLI_9763E_SCR_AXI_REQ BIT(9)
+#define PCIE_GLI_9763E_CFG2 0x8A4
+#define GLI_9763E_CFG2_L1DLY GENMASK(28, 19)
+#define GLI_9763E_CFG2_L1DLY_MAX 0x3FF
+
#define PCIE_GLI_9763E_MMC_CTRL 0x960
#define GLI_9763E_HS400_SLOW BIT(3)
@@ -792,6 +796,11 @@ static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
value &= ~GLI_9763E_HS400_SLOW;
pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value);
+ pci_read_config_dword(pdev, PCIE_GLI_9763E_CFG2, &value);
+ value &= ~GLI_9763E_CFG2_L1DLY;
+ value |= FIELD_PREP(GLI_9763E_CFG2_L1DLY, GLI_9763E_CFG2_L1DLY_MAX);
+ pci_write_config_dword(pdev, PCIE_GLI_9763E_CFG2, value);
+
pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, &value);
value &= ~GLI_9763E_VHS_REV;
value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R);
--
2.27.0
On Wed, 6 Jan 2021 at 10:27, Renius Chen <[email protected]> wrote:
>
> The R/W performance of GL9763E is low with some platforms, which
> support ASPM mechanism, due to entering L1 state very frequently
> in R/W process. Enlarge its ASPM L1 entry delay to improve the
> R/W performance of GL9763E.
What do you mean by frequently? In between a burst of request or
during a burst of request?
I am thinking that this could have an effect on energy instead, but I
guess it's not always straightforward to decide what's most important.
Anyway, what does it mean when you change to use 0x3FF? Are you
increasing the idle period? Then for how long?
Kind regards
Uffe
>
> Signed-off-by: Renius Chen <[email protected]>
> ---
> drivers/mmc/host/sdhci-pci-gli.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
> index c6a107d7c742..2d13bfcbcacf 100644
> --- a/drivers/mmc/host/sdhci-pci-gli.c
> +++ b/drivers/mmc/host/sdhci-pci-gli.c
> @@ -88,6 +88,10 @@
> #define PCIE_GLI_9763E_SCR 0x8E0
> #define GLI_9763E_SCR_AXI_REQ BIT(9)
>
> +#define PCIE_GLI_9763E_CFG2 0x8A4
> +#define GLI_9763E_CFG2_L1DLY GENMASK(28, 19)
> +#define GLI_9763E_CFG2_L1DLY_MAX 0x3FF
> +
> #define PCIE_GLI_9763E_MMC_CTRL 0x960
> #define GLI_9763E_HS400_SLOW BIT(3)
>
> @@ -792,6 +796,11 @@ static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
> value &= ~GLI_9763E_HS400_SLOW;
> pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value);
>
> + pci_read_config_dword(pdev, PCIE_GLI_9763E_CFG2, &value);
> + value &= ~GLI_9763E_CFG2_L1DLY;
> + value |= FIELD_PREP(GLI_9763E_CFG2_L1DLY, GLI_9763E_CFG2_L1DLY_MAX);
> + pci_write_config_dword(pdev, PCIE_GLI_9763E_CFG2, value);
> +
> pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, &value);
> value &= ~GLI_9763E_VHS_REV;
> value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R);
> --
> 2.27.0
>
> Ulf Hansson <[email protected]> 於 2021年1月13日 週三 下午6:53寫道：
>
> On Wed, 6 Jan 2021 at 10:27, Renius Chen <[email protected]> wrote:
> >
> > The R/W performance of GL9763E is low with some platforms, which
> > support ASPM mechanism, due to entering L1 state very frequently
> > in R/W process. Enlarge its ASPM L1 entry delay to improve the
> > R/W performance of GL9763E.
>
> What do you mean by frequently? In between a burst of request or
> during a burst of request?
GL9763E enters ASPM L1 state after a very short idle in default, even
during a burst of request.
> I am thinking that this could have an effect on energy instead, but I
> guess it's not always straightforward to decide what's most important.
>
> Anyway, what does it mean when you change to use 0x3FF? Are you
> increasing the idle period? Then for how long?
Yes, we considered that having high performance is more important than
saving power during a burst of request.
So we increased the idle period for 260us, by setting 0x3FF to the
ASPM L1 entry delay bits of our vendor-specific register.
Anyway, GL9763E can still enter ASPM L1 state by a longer idle.
Thanks for reviewing.
Best regards,
Renius
> Kind regards
> Uffe
>
> >
> > Signed-off-by: Renius Chen <[email protected]>
> > ---
> > drivers/mmc/host/sdhci-pci-gli.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
> > index c6a107d7c742..2d13bfcbcacf 100644
> > --- a/drivers/mmc/host/sdhci-pci-gli.c
> > +++ b/drivers/mmc/host/sdhci-pci-gli.c
> > @@ -88,6 +88,10 @@
> > #define PCIE_GLI_9763E_SCR 0x8E0
> > #define GLI_9763E_SCR_AXI_REQ BIT(9)
> >
> > +#define PCIE_GLI_9763E_CFG2 0x8A4
> > +#define GLI_9763E_CFG2_L1DLY GENMASK(28, 19)
> > +#define GLI_9763E_CFG2_L1DLY_MAX 0x3FF
> > +
> > #define PCIE_GLI_9763E_MMC_CTRL 0x960
> > #define GLI_9763E_HS400_SLOW BIT(3)
> >
> > @@ -792,6 +796,11 @@ static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
> > value &= ~GLI_9763E_HS400_SLOW;
> > pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value);
> >
> > + pci_read_config_dword(pdev, PCIE_GLI_9763E_CFG2, &value);
> > + value &= ~GLI_9763E_CFG2_L1DLY;
> > + value |= FIELD_PREP(GLI_9763E_CFG2_L1DLY, GLI_9763E_CFG2_L1DLY_MAX);
> > + pci_write_config_dword(pdev, PCIE_GLI_9763E_CFG2, value);
> > +
> > pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, &value);
> > value &= ~GLI_9763E_VHS_REV;
> > value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R);
> > --
> > 2.27.0
> >
On Thu, 14 Jan 2021 at 07:25, 陳建宏 <[email protected]> wrote:
>
> > Ulf Hansson <[email protected]> 於 2021年1月13日 週三 下午6:53寫道：
> >
> > On Wed, 6 Jan 2021 at 10:27, Renius Chen <[email protected]> wrote:
> > >
> > > The R/W performance of GL9763E is low with some platforms, which
> > > support ASPM mechanism, due to entering L1 state very frequently
> > > in R/W process. Enlarge its ASPM L1 entry delay to improve the
> > > R/W performance of GL9763E.
> >
> > What do you mean by frequently? In between a burst of request or
> > during a burst of request?
>
> GL9763E enters ASPM L1 state after a very short idle in default, even
> during a burst of request.
Okay, then it certainly makes sense to extend the idle period.
Would you mind extending the commit message with some of this
information, as I think it's useful.
>
> > I am thinking that this could have an effect on energy instead, but I
> > guess it's not always straightforward to decide what's most important.
> >
> > Anyway, what does it mean when you change to use 0x3FF? Are you
> > increasing the idle period? Then for how long?
>
> Yes, we considered that having high performance is more important than
> saving power during a burst of request.
> So we increased the idle period for 260us, by setting 0x3FF to the
> ASPM L1 entry delay bits of our vendor-specific register.
> Anyway, GL9763E can still enter ASPM L1 state by a longer idle.
Most mmc controllers that uses runtime PM autosuspend for the same
reasons, uses and idle period time of ~50us. 260us is in the same
ballpark, so I am fine with that, if that works for you.
However, can you please add a comment in the code (and preferably also
to the commit message) that 0x3FF means using a 260us idle period?
[...]
Kind regards
Uffe
> Ulf Hansson <[email protected]> 於 2021年1月14日 週四 下午8:04寫道：
>
> On Thu, 14 Jan 2021 at 07:25, 陳建宏 <[email protected]> wrote:
> >
> > > Ulf Hansson <[email protected]> 於 2021年1月13日 週三 下午6:53寫道：
> > >
> > > On Wed, 6 Jan 2021 at 10:27, Renius Chen <[email protected]> wrote:
> > > >
> > > > The R/W performance of GL9763E is low with some platforms, which
> > > > support ASPM mechanism, due to entering L1 state very frequently
> > > > in R/W process. Enlarge its ASPM L1 entry delay to improve the
> > > > R/W performance of GL9763E.
> > >
> > > What do you mean by frequently? In between a burst of request or
> > > during a burst of request?
> >
> > GL9763E enters ASPM L1 state after a very short idle in default, even
> > during a burst of request.
>
> Okay, then it certainly makes sense to extend the idle period.
>
> Would you mind extending the commit message with some of this
> information, as I think it's useful.
>
> >
> > > I am thinking that this could have an effect on energy instead, but I
> > > guess it's not always straightforward to decide what's most important.
> > >
> > > Anyway, what does it mean when you change to use 0x3FF? Are you
> > > increasing the idle period? Then for how long?
> >
> > Yes, we considered that having high performance is more important than
> > saving power during a burst of request.
> > So we increased the idle period for 260us, by setting 0x3FF to the
> > ASPM L1 entry delay bits of our vendor-specific register.
> > Anyway, GL9763E can still enter ASPM L1 state by a longer idle.
>
> Most mmc controllers that uses runtime PM autosuspend for the same
> reasons, uses and idle period time of ~50us. 260us is in the same
> ballpark, so I am fine with that, if that works for you.
>
> However, can you please add a comment in the code (and preferably also
> to the commit message) that 0x3FF means using a 260us idle period?
OK, I'll extend the commit message with some of these information and
add a comment in the code to describe that the idle period is set to
260us.
Then I'll submit a newer version: mmc: sdhci-pci-gli: Enlarge ASPM L1
entry delay of GL9763E (v2).
Thank you.
>
> [...]
>
> Kind regards
> Uffe