| Message ID | 1453213055-35563-1-git-send-email-lakshmis@xilinx.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Tue, Jan 19, 2016 at 10:17 PM, P L Sai Krishna <lakshmi.sai.krishna.potthuri@xilinx.com> wrote: > During the auto tuning mode of SDR104, a couple of transactions > on rx_tap_value which are not incremental or decremental by 1. > Since the DLL supports only increment/decrement by 1 during > dynamic change, observed unexpected delays during both these > transactions. > The first transaction occurs when the tap value > reached 0x1F, it will reset to 0x0 and go till 0x7. This > transaction can be avoided by changing the corecfg_dis1p5xtuningcnt > to 1'b1 which is currently tied to 1'b0 in the RTL. > The second transaction occurs after the tuning is completed. > Once the tuning is done, the tuning fsm in the host controller > calculates the average pattern match and will write the value > on the rx tap value. Therefore observed a transaction from 0x7 to > the final value which need not be a increment/decrement value. > Because of this issue DLL tuning will not be accurate and SDR50, > SDR104 & HS200 modes may not work. > > This patch adds workaround to change the SD clock after > tuning done to provide accurate DLL tuning for SDR50, > SD104 & HS200 modes. > > After receiving the tuning done, program "SDCLK Frequency Select" > of clock control register with a value different from the desired > value. Wait for the "Internal Clock Stable" bit of the clock > control register and program the desired frequency. Does this series apply to any non-Arasan or non-sdhci mmc hosts? The subject does not indicate a specific platform. Thanks ChenYu > Signed-off-by: P L Sai Krishna <lakshmis@xilinx.com> > --- > drivers/mmc/host/sdhci-of-arasan.c | 18 ++++++++++++++++++ > drivers/mmc/host/sdhci-pltfm.c | 3 +++ > drivers/mmc/host/sdhci.c | 5 +++++ > drivers/mmc/host/sdhci.h | 4 ++++ > 4 files changed, 30 insertions(+)
On Tue, Jan 19, 2016 at 07:47:31PM +0530, P L Sai Krishna wrote: > +void arasan_tune_sdclk(struct sdhci_host *host) static? > +{ > + unsigned int clock; > + > + clock = host->clock; Maybe combine the above two lines: unsigned int clock = host->clock; ? > + > + /* > + * As per controller erratum, program the SDCLK Frequency > + * Select of clock control register with a value, say > + * clock/2. Wait for the Internal clock stable and program > + * the desired frequency. > + */ > + host->ops->set_clock(host, clock/2); The comment above says "wait for the internal clock stable" - I see no wait in here. Does the code actually conform with the comment? Please also use "clock / 2" as per coding style, thanks > + > + host->ops->set_clock(host, host->clock); Maybe replace host->clock with clock? > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index d622435..8b064cd 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -2043,6 +2043,11 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode) > err = -EIO; > } > > + if ((host->quirks2 & SDHCI_QUIRK2_BROKEN_TUNING) && > + (tuning_loop_counter >= 0) && (ctrl & SDHCI_CTRL_TUNED_CLK)) { > + host->ops->tune_clk(host); > + } Do we need this "SDHCI_QUIRK2_BROKEN_TUNING" quirk at all? What's wrong with: if (host->ops->tune_clk && tuning_loop_counter >= 0 && ctrl & SDHCI_CTRL_TUNED_CLK) host->ops->tune_clk(host); here?
Hi, > -----Original Message----- > From: Chen-Yu Tsai [mailto:wens@csie.org] > Sent: Tuesday, January 19, 2016 8:32 PM > To: Lakshmi Sai Krishna Potthuri > Cc: Michal Simek; Soren Brinkmann; Ulf Hansson; Kevin Hao; Emil P. Lenchak; > Tobias Klauser; Sudeep Holla; Adrian Hunter; Jisheng Zhang; Ivan T. Ivanov; > Scott Branden; Vincent Yang; Haibo Chen; Marek Vasut; > ludovic.desroches@atmel.com; Rob Herring; Pawel Moll; Mark Rutland; Ian > Campbell; Kumar Gala; Suman Tripathi; Shawn Lin; devicetree; Harini > Katakam; linux-mmc@vger.kernel.org; linux-kernel; Lakshmi Sai Krishna > Potthuri; Anirudha Sarangi; Punnaiah Choudary Kalluri; linux-arm-kernel > Subject: Re: [LINUX PATCH 1/5] mmc: Workaround for the issue in auto > tuning mode. > > Hi, > > On Tue, Jan 19, 2016 at 10:17 PM, P L Sai Krishna > <lakshmi.sai.krishna.potthuri@xilinx.com> wrote: > > During the auto tuning mode of SDR104, a couple of transactions on > > rx_tap_value which are not incremental or decremental by 1. > > Since the DLL supports only increment/decrement by 1 during dynamic > > change, observed unexpected delays during both these transactions. > > The first transaction occurs when the tap value reached 0x1F, it will > > reset to 0x0 and go till 0x7. This transaction can be avoided by > > changing the corecfg_dis1p5xtuningcnt to 1'b1 which is currently tied > > to 1'b0 in the RTL. > > The second transaction occurs after the tuning is completed. > > Once the tuning is done, the tuning fsm in the host controller > > calculates the average pattern match and will write the value on the > > rx tap value. Therefore observed a transaction from 0x7 to the final > > value which need not be a increment/decrement value. > > Because of this issue DLL tuning will not be accurate and SDR50, > > SDR104 & HS200 modes may not work. > > > > This patch adds workaround to change the SD clock after tuning done to > > provide accurate DLL tuning for SDR50, > > SD104 & HS200 modes. > > > > After receiving the tuning done, program "SDCLK Frequency Select" > > of clock control register with a value different from the desired > > value. Wait for the "Internal Clock Stable" bit of the clock control > > register and program the desired frequency. > > Does this series apply to any non-Arasan or non-sdhci mmc hosts? > The subject does not indicate a specific platform. This series is applicable only for Zynq Ultrascal+ MPSoC which uses Arasan SDHCI. Sorry, I will change the description to indicate the same. The DT property used is made generic but the tuning used is Specific to this SoC. Regards Sai Krishna This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Hi, > -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk] > Sent: Tuesday, January 19, 2016 11:28 PM > To: Lakshmi Sai Krishna Potthuri > Cc: Michal Simek; Soren Brinkmann; Ulf Hansson; Kevin Hao; Emil P. Lenchak; > Tobias Klauser; Sudeep Holla; Adrian Hunter; Jisheng Zhang; Ivan T. Ivanov; > Scott Branden; Vincent Yang; Haibo Chen; Marek Vasut; > ludovic.desroches@atmel.com; Rob Herring; Pawel Moll; Mark Rutland; Ian > Campbell; Kumar Gala; Suman Tripathi; Shawn Lin; > devicetree@vger.kernel.org; Harini Katakam; linux-mmc@vger.kernel.org; > linux-kernel@vger.kernel.org; Lakshmi Sai Krishna Potthuri; Anirudha > Sarangi; Punnaiah Choudary Kalluri; linux-arm-kernel@lists.infradead.org > Subject: Re: [LINUX PATCH 1/5] mmc: Workaround for the issue in auto > tuning mode. > <snip> > > + > > + /* > > + * As per controller erratum, program the SDCLK Frequency > > + * Select of clock control register with a value, say > > + * clock/2. Wait for the Internal clock stable and program > > + * the desired frequency. > > + */ > > + host->ops->set_clock(host, clock/2); > > The comment above says "wait for the internal clock stable" - I see no wait in > here. Does the code actually conform with the comment? Wait for internal clock stable is taken care of inside set_clock() <snip> > > + if ((host->quirks2 & SDHCI_QUIRK2_BROKEN_TUNING) && > > + (tuning_loop_counter >= 0) && (ctrl & > SDHCI_CTRL_TUNED_CLK)) { > > + host->ops->tune_clk(host); > > + } > > Do we need this "SDHCI_QUIRK2_BROKEN_TUNING" quirk at all? What's > wrong > with: > > if (host->ops->tune_clk && tuning_loop_counter >= 0 && > ctrl & SDHCI_CTRL_TUNED_CLK) > host->ops->tune_clk(host); > > here? > tune_clock is provided as part of ops and will always be present. Other users of arasan and this driver might not have tuning broken And won't use this manual tuning. Regards Sai Krishna This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c index 75379cb..7f30577 100644 --- a/drivers/mmc/host/sdhci-of-arasan.c +++ b/drivers/mmc/host/sdhci-of-arasan.c @@ -52,6 +52,23 @@ static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host) return freq; } +void arasan_tune_sdclk(struct sdhci_host *host) +{ + unsigned int clock; + + clock = host->clock; + + /* + * As per controller erratum, program the SDCLK Frequency + * Select of clock control register with a value, say + * clock/2. Wait for the Internal clock stable and program + * the desired frequency. + */ + host->ops->set_clock(host, clock/2); + + host->ops->set_clock(host, host->clock); +} + static struct sdhci_ops sdhci_arasan_ops = { .set_clock = sdhci_set_clock, .get_max_clock = sdhci_pltfm_clk_get_max_clock, @@ -59,6 +76,7 @@ static struct sdhci_ops sdhci_arasan_ops = { .set_bus_width = sdhci_set_bus_width, .reset = sdhci_reset, .set_uhs_signaling = sdhci_set_uhs_signaling, + .tune_clk = arasan_tune_sdclk, }; static struct sdhci_pltfm_data sdhci_arasan_pdata = { diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 072bb27..223c5eb 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -90,6 +90,9 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_get_property(np, "no-1-8-v", NULL)) host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; + if (of_get_property(np, "broken-tuning", NULL)) + host->quirks2 |= SDHCI_QUIRK2_BROKEN_TUNING; + if (of_device_is_compatible(np, "fsl,p2020-rev1-esdhc")) host->quirks |= SDHCI_QUIRK_BROKEN_DMA; diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index d622435..8b064cd 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2043,6 +2043,11 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode) err = -EIO; } + if ((host->quirks2 & SDHCI_QUIRK2_BROKEN_TUNING) && + (tuning_loop_counter >= 0) && (ctrl & SDHCI_CTRL_TUNED_CLK)) { + host->ops->tune_clk(host); + } + out: if (tuning_count) { /* diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index 7654ae5..16419f0 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -417,6 +417,9 @@ struct sdhci_host { #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14) /* Broken Clock divider zero in controller */ #define SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN (1<<15) +/* Tuning Broken for HS200, SDR50 and SDR104 */ +#define SDHCI_QUIRK2_BROKEN_TUNING (1<<16) + /* * When internal clock is disabled, a delay is needed before modifying the * SD clock frequency or enabling back the internal clock. @@ -548,6 +551,7 @@ struct sdhci_ops { void (*platform_init)(struct sdhci_host *host); void (*card_event)(struct sdhci_host *host); void (*voltage_switch)(struct sdhci_host *host); + void (*tune_clk)(struct sdhci_host *host); int (*select_drive_strength)(struct sdhci_host *host, struct mmc_card *card, unsigned int max_dtr, int host_drv,
During the auto tuning mode of SDR104, a couple of transactions on rx_tap_value which are not incremental or decremental by 1. Since the DLL supports only increment/decrement by 1 during dynamic change, observed unexpected delays during both these transactions. The first transaction occurs when the tap value reached 0x1F, it will reset to 0x0 and go till 0x7. This transaction can be avoided by changing the corecfg_dis1p5xtuningcnt to 1'b1 which is currently tied to 1'b0 in the RTL. The second transaction occurs after the tuning is completed. Once the tuning is done, the tuning fsm in the host controller calculates the average pattern match and will write the value on the rx tap value. Therefore observed a transaction from 0x7 to the final value which need not be a increment/decrement value. Because of this issue DLL tuning will not be accurate and SDR50, SDR104 & HS200 modes may not work. This patch adds workaround to change the SD clock after tuning done to provide accurate DLL tuning for SDR50, SD104 & HS200 modes. After receiving the tuning done, program "SDCLK Frequency Select" of clock control register with a value different from the desired value. Wait for the "Internal Clock Stable" bit of the clock control register and program the desired frequency. Signed-off-by: P L Sai Krishna <lakshmis@xilinx.com> --- drivers/mmc/host/sdhci-of-arasan.c | 18 ++++++++++++++++++ drivers/mmc/host/sdhci-pltfm.c | 3 +++ drivers/mmc/host/sdhci.c | 5 +++++ drivers/mmc/host/sdhci.h | 4 ++++ 4 files changed, 30 insertions(+)