From: Bjorn Helgaas <helgaas@kernel.org>
To: ricky_wu@realtek.com
Cc: arnd@arndb.de, gregkh@linuxfoundation.org, bhelgaas@google.com,
ulf.hansson@linaro.org, rui_feng@realsil.com.cn,
linux-kernel@vger.kernel.org, puranjay12@gmail.com,
linux-pci@vger.kernel.org, vailbhavgupta40@gamail.com
Subject: Re: [PATCH v5 2/2] misc: rtsx: Add power saving functions and fix driving parameter
Date: Tue, 8 Sep 2020 17:28:34 -0500 [thread overview]
Message-ID: <20200908222834.GA646416@bjorn-Precision-5520> (raw)
In-Reply-To: <20200907100731.7722-1-ricky_wu@realtek.com>
On Mon, Sep 07, 2020 at 06:07:31PM +0800, ricky_wu@realtek.com wrote:
> From: Ricky Wu <ricky_wu@realtek.com>
>
> v4:
> split power down flow and power saving function to two patch
>
> v5:
> fix up modified change under the --- line
Hehe, this came out *above* the "---" line :)
> Add rts522a L1 sub-state support
> Save more power on rts5227 rts5249 rts525a rts5260
> Fix rts5260 driving parameter
>
> Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
> ---
> drivers/misc/cardreader/rts5227.c | 112 +++++++++++++++++++++-
> drivers/misc/cardreader/rts5249.c | 145 ++++++++++++++++++++++++++++-
> drivers/misc/cardreader/rts5260.c | 28 +++---
> drivers/misc/cardreader/rtsx_pcr.h | 17 ++++
> 4 files changed, 283 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/misc/cardreader/rts5227.c b/drivers/misc/cardreader/rts5227.c
> index 747391e3fb5d..8859011672cb 100644
> --- a/drivers/misc/cardreader/rts5227.c
> +++ b/drivers/misc/cardreader/rts5227.c
> @@ -72,15 +72,80 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr *pcr)
>
> pci_read_config_dword(pdev, PCR_SETTING_REG2, ®);
> pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
> + if (rtsx_check_mmc_support(reg))
> + pcr->extra_caps |= EXTRA_CAPS_NO_MMC;
> pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
> if (rtsx_reg_check_reverse_socket(reg))
> pcr->flags |= PCR_REVERSE_SOCKET;
> }
>
> +static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
> +{
> + struct pci_dev *pdev = pcr->pci;
> + int l1ss;
> + u32 lval;
> + struct rtsx_cr_option *option = &pcr->option;
> +
> + l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
> + if (!l1ss)
> + return;
> +
> + pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, &lval);
This looks a little problematic. PCI_L1SS_CTL1 is an architected
register in the ASPM L1 PM Substates capability, and its value may
change at runtime because drivers/pci/pcie/aspm.c manages it.
It looks like the code below does device-specific configuration based
on the current PCI_L1SS_CTL1 value. But what happens if aspm.c
changes PCI_L1SS_CTL1 later?
> + if (CHK_PCI_PID(pcr, 0x522A)) {
> + if (0 == (lval & 0x0F))
> + rtsx_pci_enable_oobs_polling(pcr);
> + else
> + rtsx_pci_disable_oobs_polling(pcr);
> + }
> +
> + if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
> + rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
> + else
> + rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
> +
> + if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
> + rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
> + else
> + rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
> +
> + if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
> + rtsx_set_dev_flag(pcr, PM_L1_1_EN);
> + else
> + rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
> +
> + if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
> + rtsx_set_dev_flag(pcr, PM_L1_2_EN);
> + else
> + rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
> +
> + if (option->ltr_en) {
> + u16 val;
> +
> + pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, &val);
Same thing here. I don't think the PCI core currently changes
PCI_EXP_DEVCTL2 after boot, but it's not a good idea to assume it's
going to be constant.
> + if (val & PCI_EXP_DEVCTL2_LTR_EN) {
> + option->ltr_enabled = true;
> + option->ltr_active = true;
> + rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
> + } else {
> + option->ltr_enabled = false;
> + }
> + }
> +
> + if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
> + | PM_L1_1_EN | PM_L1_2_EN))
> + option->force_clkreq_0 = false;
> + else
> + option->force_clkreq_0 = true;
> +
> +}
next prev parent reply other threads:[~2020-09-08 22:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 10:07 [PATCH v5 2/2] misc: rtsx: Add power saving functions and fix driving parameter ricky_wu
2020-09-08 22:28 ` Bjorn Helgaas [this message]
2020-09-09 7:10 ` 吳昊澄 Ricky
2020-09-09 17:44 ` Bjorn Helgaas
2020-09-11 8:18 ` 吳昊澄 Ricky
2020-09-11 14:56 ` Bjorn Helgaas
2020-09-15 8:24 ` 吳昊澄 Ricky
2020-09-15 15:28 ` Bjorn Helgaas
2020-09-16 12:30 ` gregkh
2020-09-16 13:32 ` Bjorn Helgaas
2020-09-16 14:28 ` gregkh
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=20200908222834.GA646416@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=puranjay12@gmail.com \
--cc=ricky_wu@realtek.com \
--cc=rui_feng@realsil.com.cn \
--cc=ulf.hansson@linaro.org \
--cc=vailbhavgupta40@gamail.com \
/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).