From: Ulf Hansson <ulf.hansson@linaro.org> To: Ludovic Barre <ludovic.barre@st.com> 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: Fri, 24 Jan 2020 14:10:03 +0100 [thread overview] Message-ID: <CAPDyKFq25C6W3df5LRsYAcV71rM0YYx9xd=isURKVkbCiN+fBw@mail.gmail.com> (raw) In-Reply-To: <20200110134823.14882-7-ludovic.barre@st.com> 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. > + 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? > +} > + > 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
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org> To: Ludovic Barre <ludovic.barre@st.com> Cc: DTML <devicetree@vger.kernel.org>, Alexandre Torgue <alexandre.torgue@st.com>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, linux-stm32@st-md-mailman.stormreply.com, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 6/9] mmc: mmci: sdmmc: add execute tuning with delay block Date: Fri, 24 Jan 2020 14:10:03 +0100 [thread overview] Message-ID: <CAPDyKFq25C6W3df5LRsYAcV71rM0YYx9xd=isURKVkbCiN+fBw@mail.gmail.com> (raw) In-Reply-To: <20200110134823.14882-7-ludovic.barre@st.com> 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. > + 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? > +} > + > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-24 13:10 UTC|newest] Thread overview: 50+ 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 ` 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 ` 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 ` 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-10 13:48 ` Ludovic Barre 2020-01-24 13:09 ` Ulf Hansson 2020-01-24 13:09 ` Ulf Hansson 2020-01-27 10:57 ` Ludovic BARRE 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 ` 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-10 13:48 ` Ludovic Barre 2020-01-15 14:56 ` Rob Herring 2020-01-15 14:56 ` Rob Herring 2020-01-16 9:20 ` Ludovic BARRE 2020-01-16 9:20 ` Ludovic BARRE 2020-01-16 14:33 ` Rob Herring 2020-01-16 14:33 ` Rob Herring 2020-01-16 14:52 ` Ludovic BARRE 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-10 13:48 ` Ludovic Barre 2020-01-24 13:10 ` Ulf Hansson [this message] 2020-01-24 13:10 ` Ulf Hansson 2020-01-27 13:19 ` Ludovic BARRE 2020-01-27 13:19 ` Ludovic BARRE 2020-01-10 13:48 ` [PATCH 7/9] mmc: mmci: add volt_switch callbacks Ludovic Barre 2020-01-10 13:48 ` Ludovic Barre 2020-01-24 13:12 ` Ulf Hansson 2020-01-24 13:12 ` Ulf Hansson 2020-01-27 13:21 ` Ludovic BARRE 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-10 13:48 ` Ludovic Barre 2020-01-24 13:16 ` Ulf Hansson 2020-01-24 13:16 ` Ulf Hansson 2020-01-27 13:50 ` Ludovic BARRE 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-10 13:48 ` Ludovic Barre 2020-01-24 12:55 ` [PATCH 0/9] mmc: mmci: sdmmc: add sdr104 support Ludovic BARRE 2020-01-24 12:55 ` Ludovic BARRE 2020-01-24 13:19 ` Ulf Hansson 2020-01-24 13:19 ` Ulf Hansson 2020-01-27 13:52 ` Ludovic BARRE 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='CAPDyKFq25C6W3df5LRsYAcV71rM0YYx9xd=isURKVkbCiN+fBw@mail.gmail.com' \ --to=ulf.hansson@linaro.org \ --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=ludovic.barre@st.com \ --cc=mcoquelin.stm32@gmail.com \ --cc=robh+dt@kernel.org \ --cc=srinivas.kandagatla@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.