linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ludovic BARRE <ludovic.barre@st.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH 6/9] mmc: mmci: sdmmc: add execute tuning with delay block
Date: Mon, 27 Jan 2020 14:19:00 +0100	[thread overview]
Message-ID: <48b15042-88cc-29d1-63bb-6bfa277980b2@st.com> (raw)
In-Reply-To: <CAPDyKFq25C6W3df5LRsYAcV71rM0YYx9xd=isURKVkbCiN+fBw@mail.gmail.com>

hi Ulf

Le 1/24/20 à 2:10 PM, Ulf Hansson a écrit :
> On Fri, 10 Jan 2020 at 14:49, Ludovic Barre <ludovic.barre@st.com> wrote:
>>
>> The hardware delay block is used to align the sampling clock on
>> the data received by SDMMC. It is mandatory for SDMMC to
>> support the SDR104 mode. The delay block is used to generate
>> an output clock which is dephased from the input clock.
>> The phase of the output clock must be programmed by the execute
>> tuning interface.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>> ---
>>   drivers/mmc/host/mmci_stm32_sdmmc.c | 147 ++++++++++++++++++++++++++++
>>   1 file changed, 147 insertions(+)
>>
>> diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
>> index df08f6662431..10059fa19f4a 100644
>> --- a/drivers/mmc/host/mmci_stm32_sdmmc.c
>> +++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
>> @@ -3,10 +3,13 @@
>>    * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
>>    * Author: Ludovic.barre@st.com for STMicroelectronics.
>>    */
>> +#include <linux/bitfield.h>
>>   #include <linux/delay.h>
>>   #include <linux/dma-mapping.h>
>> +#include <linux/iopoll.h>
>>   #include <linux/mmc/host.h>
>>   #include <linux/mmc/card.h>
>> +#include <linux/of_address.h>
>>   #include <linux/reset.h>
>>   #include <linux/scatterlist.h>
>>   #include "mmci.h"
>> @@ -14,6 +17,20 @@
>>   #define SDMMC_LLI_BUF_LEN      PAGE_SIZE
>>   #define SDMMC_IDMA_BURST       BIT(MMCI_STM32_IDMABNDT_SHIFT)
>>
>> +#define DLYB_CR                        0x0
>> +#define DLYB_CR_DEN            BIT(0)
>> +#define DLYB_CR_SEN            BIT(1)
>> +
>> +#define DLYB_CFGR              0x4
>> +#define DLYB_CFGR_SEL_MASK     GENMASK(3, 0)
>> +#define DLYB_CFGR_UNIT_MASK    GENMASK(14, 8)
>> +#define DLYB_CFGR_LNG_MASK     GENMASK(27, 16)
>> +#define DLYB_CFGR_LNGF         BIT(31)
>> +
>> +#define DLYB_NB_DELAY          11
>> +#define DLYB_CFGR_SEL_MAX      (DLYB_NB_DELAY + 1)
>> +#define DLYB_CFGR_UNIT_MAX     127
> 
> [...]
> 
>> +static int sdmmc_dlyb_lng_tuning(struct mmci_host *host)
>> +{
>> +       struct sdmmc_dlyb *dlyb = host->variant_priv;
>> +       u32 cfgr;
>> +       int i, lng, ret;
>> +
>> +       for (i = 0; i <= DLYB_CFGR_UNIT_MAX; i++) {
>> +               sdmmc_dlyb_set_cfgr(dlyb, i, DLYB_CFGR_SEL_MAX, true);
>> +
>> +               ret = readl_relaxed_poll_timeout(dlyb->base + DLYB_CFGR, cfgr,
>> +                                                (cfgr & DLYB_CFGR_LNGF),
>> +                                                1, 1000);
> 
> I suggest you introduce a define for this timeout, in the top of the file.

OK

> 
>> +               if (ret) {
>> +                       dev_warn(mmc_dev(host->mmc),
>> +                                "delay line cfg timeout unit:%d cfgr:%d\n",
>> +                                i, cfgr);
>> +                       continue;
>> +               }
>> +
>> +               lng = FIELD_GET(DLYB_CFGR_LNG_MASK, cfgr);
>> +               if (lng < BIT(DLYB_NB_DELAY) && lng > 0)
>> +                       break;
>> +       }
>> +
>> +       if (i > DLYB_CFGR_UNIT_MAX)
>> +               return -EINVAL;
>> +
>> +       dlyb->unit = i;
>> +       dlyb->max = __fls(lng);
>> +
>> +       return 0;
>> +}
>> +
>> +static int sdmmc_dlyb_phase_tuning(struct mmci_host *host, u32 opcode)
>> +{
>> +       struct sdmmc_dlyb *dlyb = host->variant_priv;
>> +       int cur_len = 0, max_len = 0, end_of_len = 0;
>> +       int phase;
>> +
>> +       for (phase = 0; phase <= dlyb->max; phase++) {
>> +               sdmmc_dlyb_set_cfgr(dlyb, dlyb->unit, phase, false);
>> +
>> +               if (mmc_send_tuning(host->mmc, opcode, NULL)) {
>> +                       cur_len = 0;
>> +               } else {
>> +                       cur_len++;
>> +                       if (cur_len > max_len) {
>> +                               max_len = cur_len;
>> +                               end_of_len = phase;
>> +                       }
>> +               }
>> +       }
>> +
>> +       if (!max_len) {
>> +               dev_err(mmc_dev(host->mmc), "no tuning point found\n");
>> +               return -EINVAL;
>> +       }
>> +
>> +       phase = end_of_len - max_len / 2;
>> +       sdmmc_dlyb_set_cfgr(dlyb, dlyb->unit, phase, false);
>> +
>> +       dev_dbg(mmc_dev(host->mmc), "unit:%d max_dly:%d phase:%d\n",
>> +               dlyb->unit, dlyb->max, phase);
>> +
>> +       return 0;
>> +}
>> +
>> +static int sdmmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> +{
>> +       struct mmci_host *host = mmc_priv(mmc);
>> +       struct sdmmc_dlyb *dlyb = host->variant_priv;
>> +
>> +       if (!dlyb || !dlyb->base)
>> +               return -EINVAL;
>> +
>> +       if (sdmmc_dlyb_lng_tuning(host))
>> +               return -EINVAL;
>> +
>> +       return sdmmc_dlyb_phase_tuning(host, opcode);
> 
> What happens to the tuning registers when the controller device
> becomes runtime suspended? Would it possible that the values gets lost
> and then they need to be restored in runtime resume?

when the device goes to runtime suspend:
-The sdmmc clock is disabled => sdmmc & dlyb registers are not accessible.
-The power domain of this blocks is not off, the register values are not 
lost.

On runtime resume the clock is re-enabled and the registers
are accessible and with right values

Regards
Ludo

> 
>> +}
>> +
>>   static struct mmci_host_ops sdmmc_variant_ops = {
>>          .validate_data = sdmmc_idma_validate_data,
>>          .prep_data = sdmmc_idma_prep_data,
>> @@ -338,5 +469,21 @@ static struct mmci_host_ops sdmmc_variant_ops = {
>>
>>   void sdmmc_variant_init(struct mmci_host *host)
>>   {
>> +       struct device_node *np = host->mmc->parent->of_node;
>> +       void __iomem *base_dlyb;
>> +       struct sdmmc_dlyb *dlyb;
>> +
>>          host->ops = &sdmmc_variant_ops;
>> +
>> +       base_dlyb = devm_of_iomap(mmc_dev(host->mmc), np, 1, NULL);
>> +       if (IS_ERR(base_dlyb))
>> +               return;
>> +
>> +       dlyb = devm_kzalloc(mmc_dev(host->mmc), sizeof(*dlyb), GFP_KERNEL);
>> +       if (!dlyb)
>> +               return;
>> +
>> +       dlyb->base = base_dlyb;
>> +       host->variant_priv = dlyb;
>> +       host->mmc_ops->execute_tuning = sdmmc_execute_tuning;
>>   }
>> --
>> 2.17.1
>>
> 
> Kind regards
> Uffe
> 

  reply	other threads:[~2020-01-27 13:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 13:48 [PATCH 0/9] mmc: mmci: sdmmc: add sdr104 support Ludovic Barre
2020-01-10 13:48 ` [PATCH 1/9] mmc: mmci: sdmmc: replace sg_dma_xxx macros Ludovic Barre
2020-01-10 13:48 ` [PATCH 2/9] mmc: mmci: sdmmc: rename sdmmc_priv struct to sdmmc_idma Ludovic Barre
2020-01-10 13:48 ` [PATCH 3/9] mmc: mmci: add a reference at mmc_host_ops in mmci struct Ludovic Barre
2020-01-24 13:09   ` Ulf Hansson
2020-01-27 10:57     ` Ludovic BARRE
2020-01-10 13:48 ` [PATCH 4/9] mmc: mmci: add private pointer for variant Ludovic Barre
2020-01-10 13:48 ` [PATCH 5/9] dt-bindings: mmc: mmci: add delay block base register for sdmmc Ludovic Barre
2020-01-15 14:56   ` Rob Herring
2020-01-16  9:20     ` Ludovic BARRE
2020-01-16 14:33       ` Rob Herring
2020-01-16 14:52         ` Ludovic BARRE
2020-01-10 13:48 ` [PATCH 6/9] mmc: mmci: sdmmc: add execute tuning with delay block Ludovic Barre
2020-01-24 13:10   ` Ulf Hansson
2020-01-27 13:19     ` Ludovic BARRE [this message]
2020-01-10 13:48 ` [PATCH 7/9] mmc: mmci: add volt_switch callbacks Ludovic Barre
2020-01-24 13:12   ` Ulf Hansson
2020-01-27 13:21     ` Ludovic BARRE
2020-01-10 13:48 ` [PATCH 8/9] mmc: mmci: sdmmc: add voltage switch functions Ludovic Barre
2020-01-24 13:16   ` Ulf Hansson
2020-01-27 13:50     ` Ludovic BARRE
2020-01-10 13:48 ` [PATCH 9/9] mmc: mmci: add sdmmc variant revision 2.0 Ludovic Barre
2020-01-24 12:55 ` [PATCH 0/9] mmc: mmci: sdmmc: add sdr104 support Ludovic BARRE
2020-01-24 13:19   ` Ulf Hansson
2020-01-27 13:52     ` Ludovic BARRE

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=48b15042-88cc-29d1-63bb-6bfa277980b2@st.com \
    --to=ludovic.barre@st.com \
    --cc=alexandre.torgue@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.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).