[permalink] [raw]

Subject: [PATCH v6 4/4] mmc: sdhci-tegra: Use actual clock rate for SW tuning correction

Ensure tegra_host member "curr_clk_rate" holds the actual clock rate
instead of requested clock rate for proper use during tuning correction
algorithm. Actual clk rate may not be the same as the requested clk
frequency depending on the parent clock source set. Tuning correction
algorithm depends on certain parameters which are sensitive to current
clk rate. If the host clk is selected instead of the actual clock rate,
tuning correction algorithm may end up applying invalid correction,
which could result in errors

Fixes: ea8fc5953e8b ("mmc: tegra: update hw tuning process")

Signed-off-by: Aniruddha TVS Rao <[email protected]>
Signed-off-by: Prathamesh Shete <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
---
drivers/mmc/host/sdhci-tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 283f702b4993..8739cd6a702c 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -783,7 +783,7 @@ static void tegra_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
dev_err(dev, "failed to set clk rate to %luHz: %d\n",
host_clk, err);

- tegra_host->curr_clk_rate = host_clk;
+ tegra_host->curr_clk_rate = clk_get_rate(pltfm_host->clk);
if (tegra_host->ddr_signaling)
host->max_clk = host_clk;
else
--
2.17.1

2022-09-28 13:21:29

by Prathamesh Shete

[permalink] [raw]

Subject: [PATCH v6 3/4] mmc: sdhci-tegra: Issue CMD and DAT resets together

In case of error condition to avoid system crash
Tegra SDMMC controller requires CMD and DAT resets
issued together. SDHCI controller FSM goes into
bad state due to rapid SD card hot-plug event.
Issuing reset on the CMD FSM before DATA FSM results
in kernel panic, hence add support to issue CMD and
DAT resets together.
This is applicable to Tegra186 and later chips.

Signed-off-by: Aniruddha TVS Rao <[email protected]>
Signed-off-by: Prathamesh Shete <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
---
drivers/mmc/host/sdhci-tegra.c | 3 ++-
drivers/mmc/host/sdhci.c | 5 +++++
drivers/mmc/host/sdhci.h | 2 ++
3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 60ce3e80f248..283f702b4993 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1535,7 +1535,8 @@ static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
SDHCI_QUIRK_NO_HISPD_BIT |
SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
- .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+ .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
+ SDHCI_QUIRK2_ISSUE_CMD_DAT_RESET_TOGETHER,
.ops = &tegra186_sdhci_ops,
};

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2b5dda521b0e..8512a69f1aae 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -270,6 +270,11 @@ enum sdhci_reset_reason {

static void sdhci_reset_for_reason(struct sdhci_host *host, enum sdhci_reset_reason reason)
{
+ if (host->quirks2 &
+ SDHCI_QUIRK2_ISSUE_CMD_DAT_RESET_TOGETHER) {
+ sdhci_do_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
+ return;
+ }
switch (reason) {
case SDHCI_RESET_FOR_INIT:
sdhci_do_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index d750c464bd1e..6a5766774b05 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -478,6 +478,8 @@ struct sdhci_host {
* block count.
*/
#define SDHCI_QUIRK2_USE_32BIT_BLK_CNT (1<<18)
+/* Issue CMD and DATA reset together */
+#define SDHCI_QUIRK2_ISSUE_CMD_DAT_RESET_TOGETHER (1<<19)

int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
2.17.1

2022-09-28 13:22:19

by Prathamesh Shete

[permalink] [raw]

Subject: [PATCH v6 2/4] mmc: sdhci-tegra: Add support to program MC stream ID

SMMU clients are supposed to program stream ID from
their respective address spaces instead of MC override.
Define NVQUIRK_PROGRAM_STREAMID and use it to program
SMMU stream ID from the SDMMC client address space.

Signed-off-by: Aniruddha TVS Rao <[email protected]>
Signed-off-by: Prathamesh Shete <[email protected]>
---
drivers/mmc/host/sdhci-tegra.c | 44 ++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index a6c5bbae77b4..60ce3e80f248 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -25,6 +25,10 @@
#include <linux/mmc/slot-gpio.h>
#include <linux/gpio/consumer.h>
#include <linux/ktime.h>
+#ifdef CONFIG_IOMMU_API
+#include <linux/iommu.h>
+#include <linux/bitops.h>
+#endif

#include <soc/tegra/common.h>

@@ -94,6 +98,8 @@
#define SDHCI_TEGRA_AUTO_CAL_STATUS 0x1ec
#define SDHCI_TEGRA_AUTO_CAL_ACTIVE BIT(31)

+#define SDHCI_TEGRA_CIF2AXI_CTRL_0 0x1fc
+
#define NVQUIRK_FORCE_SDHCI_SPEC_200 BIT(0)
#define NVQUIRK_ENABLE_BLOCK_GAP_DET BIT(1)
#define NVQUIRK_ENABLE_SDHCI_SPEC_300 BIT(2)
@@ -121,6 +127,7 @@
#define NVQUIRK_HAS_TMCLK BIT(10)

#define NVQUIRK_HAS_ANDROID_GPT_SECTOR BIT(11)
+#define NVQUIRK_PROGRAM_STREAMID BIT(12)

/* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
#define SDHCI_TEGRA_CQE_BASE_ADDR 0xF000
@@ -177,6 +184,9 @@ struct sdhci_tegra {
bool enable_hwcq;
unsigned long curr_clk_rate;
u8 tuned_tap_delay;
+#ifdef CONFIG_IOMMU_API
+ u32 streamid;
+#endif
};

static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
@@ -1564,6 +1574,7 @@ static const struct sdhci_tegra_soc_data soc_data_tegra234 = {
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
NVQUIRK_ENABLE_SDR104 |
+ NVQUIRK_PROGRAM_STREAMID |
NVQUIRK_HAS_TMCLK,
.min_tap_delay = 95,
.max_tap_delay = 111,
@@ -1775,6 +1786,25 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
if (rc)
goto err_add_host;

+ /* Program MC streamID for DMA transfers */
+#ifdef CONFIG_IOMMU_API
+ if (soc_data->nvquirks & NVQUIRK_PROGRAM_STREAMID) {
+ struct iommu_fwspec *fwspec;
+
+ fwspec = dev_iommu_fwspec_get(&pdev->dev);
+ if (fwspec == NULL) {
+ dev_warn(mmc_dev(host->mmc),
+ "iommu fwspec is NULL, continue without stream ID\n");
+ } else {
+ tegra_host->streamid = fwspec->ids[0] & 0xff;
+ tegra_sdhci_writel(host, tegra_host->streamid |
+ FIELD_PREP(GENMASK(15, 8),
+ tegra_host->streamid),
+ SDHCI_TEGRA_CIF2AXI_CTRL_0);
+ }
+ }
+#endif
+
return 0;

err_add_host:
@@ -1861,6 +1891,10 @@ static int sdhci_tegra_suspend(struct device *dev)
static int sdhci_tegra_resume(struct device *dev)
{
struct sdhci_host *host = dev_get_drvdata(dev);
+#ifdef CONFIG_IOMMU_API
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
+#endif
int ret;

ret = mmc_gpio_set_cd_wake(host->mmc, false);
@@ -1871,6 +1905,16 @@ static int sdhci_tegra_resume(struct device *dev)
if (ret)
return ret;

+ /* Re-program MC streamID for DMA transfers */
+#ifdef CONFIG_IOMMU_API
+ if (tegra_host->soc_data->nvquirks & NVQUIRK_PROGRAM_STREAMID) {
+ tegra_sdhci_writel(host, tegra_host->streamid |
+ FIELD_PREP(GENMASK(15, 8),
+ tegra_host->streamid),
+ SDHCI_TEGRA_CIF2AXI_CTRL_0);
+ }
+#endif
+
ret = sdhci_resume_host(host);
if (ret)
goto disable_clk;
--
2.17.1

2022-09-28 14:50:42

by Adrian Hunter

[permalink] [raw]

Subject: Re: [PATCH v6 2/4] mmc: sdhci-tegra: Add support to program MC stream ID

On 28/09/22 15:56, Prathamesh Shete wrote:
> SMMU clients are supposed to program stream ID from
> their respective address spaces instead of MC override.
> Define NVQUIRK_PROGRAM_STREAMID and use it to program
> SMMU stream ID from the SDMMC client address space.
>
> Signed-off-by: Aniruddha TVS Rao <[email protected]>
> Signed-off-by: Prathamesh Shete <[email protected]>

One observation below.

Nevertheless:

Acked-by: Adrian Hunter <[email protected]>

> ---
> drivers/mmc/host/sdhci-tegra.c | 44 ++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index a6c5bbae77b4..60ce3e80f248 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -25,6 +25,10 @@
> #include <linux/mmc/slot-gpio.h>
> #include <linux/gpio/consumer.h>
> #include <linux/ktime.h>
> +#ifdef CONFIG_IOMMU_API
> +#include <linux/iommu.h>
> +#include <linux/bitops.h>
> +#endif
>
> #include <soc/tegra/common.h>
>
> @@ -94,6 +98,8 @@
> #define SDHCI_TEGRA_AUTO_CAL_STATUS 0x1ec
> #define SDHCI_TEGRA_AUTO_CAL_ACTIVE BIT(31)
>
> +#define SDHCI_TEGRA_CIF2AXI_CTRL_0 0x1fc
> +
> #define NVQUIRK_FORCE_SDHCI_SPEC_200 BIT(0)
> #define NVQUIRK_ENABLE_BLOCK_GAP_DET BIT(1)
> #define NVQUIRK_ENABLE_SDHCI_SPEC_300 BIT(2)
> @@ -121,6 +127,7 @@
> #define NVQUIRK_HAS_TMCLK BIT(10)
>
> #define NVQUIRK_HAS_ANDROID_GPT_SECTOR BIT(11)
> +#define NVQUIRK_PROGRAM_STREAMID BIT(12)
>
> /* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
> #define SDHCI_TEGRA_CQE_BASE_ADDR 0xF000
> @@ -177,6 +184,9 @@ struct sdhci_tegra {
> bool enable_hwcq;
> unsigned long curr_clk_rate;
> u8 tuned_tap_delay;
> +#ifdef CONFIG_IOMMU_API
> + u32 streamid;
> +#endif
> };
>
> static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
> @@ -1564,6 +1574,7 @@ static const struct sdhci_tegra_soc_data soc_data_tegra234 = {
> NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
> NVQUIRK_ENABLE_SDR50 |
> NVQUIRK_ENABLE_SDR104 |
> + NVQUIRK_PROGRAM_STREAMID |
> NVQUIRK_HAS_TMCLK,
> .min_tap_delay = 95,
> .max_tap_delay = 111,
> @@ -1775,6 +1786,25 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
> if (rc)
> goto err_add_host;
>
> + /* Program MC streamID for DMA transfers */
> +#ifdef CONFIG_IOMMU_API
> + if (soc_data->nvquirks & NVQUIRK_PROGRAM_STREAMID) {
> + struct iommu_fwspec *fwspec;
> +
> + fwspec = dev_iommu_fwspec_get(&pdev->dev);
> + if (fwspec == NULL) {
> + dev_warn(mmc_dev(host->mmc),
> + "iommu fwspec is NULL, continue without stream ID\n");

It will still program a zero streamid upon resume.

> + } else {
> + tegra_host->streamid = fwspec->ids[0] & 0xff;
> + tegra_sdhci_writel(host, tegra_host->streamid |
> + FIELD_PREP(GENMASK(15, 8),
> + tegra_host->streamid),
> + SDHCI_TEGRA_CIF2AXI_CTRL_0);
> + }
> + }
> +#endif
> +
> return 0;
>
> err_add_host:
> @@ -1861,6 +1891,10 @@ static int sdhci_tegra_suspend(struct device *dev)
> static int sdhci_tegra_resume(struct device *dev)
> {
> struct sdhci_host *host = dev_get_drvdata(dev);
> +#ifdef CONFIG_IOMMU_API
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
> +#endif
> int ret;
>
> ret = mmc_gpio_set_cd_wake(host->mmc, false);
> @@ -1871,6 +1905,16 @@ static int sdhci_tegra_resume(struct device *dev)
> if (ret)
> return ret;
>
> + /* Re-program MC streamID for DMA transfers */
> +#ifdef CONFIG_IOMMU_API
> + if (tegra_host->soc_data->nvquirks & NVQUIRK_PROGRAM_STREAMID) {
> + tegra_sdhci_writel(host, tegra_host->streamid |
> + FIELD_PREP(GENMASK(15, 8),
> + tegra_host->streamid),
> + SDHCI_TEGRA_CIF2AXI_CTRL_0);
> + }
> +#endif
> +
> ret = sdhci_resume_host(host);
> if (ret)
> goto disable_clk;

2022-10-06 10:59:55

On Thu, 13 Oct 2022 at 08:33, Prathamesh Shete <[email protected]> wrote:
>
> Hi Ulf,
>
> >> In that case, perhaps we can add a "depends on IOMMU_API" in the Kconfig
> >> instead? Or is the tegra driver used on platforms where IOMMU_API could be
> >> unset?
> Yes it can/will work with IOMMU disabled so its not recommended to add a "depends on" condition in Kconfig.

Alright, in that case it looks to me that there are two other options
to move forward.

1) Add proper definitions of the struct iommu_fwspec in
include/linux/iommu.h even when CONFIG_IOMMU_API is unset. In a way it
seems a bit silly to me, to have the iommu stubs around, unless those
can be used for cases like this, right!?

2) Move the code within the "ifdef CONFIG_IOMMU_API" sections into
separate functions - and add stubs for these functions too. In this
way the functions can be called, independently of whether
CONFIG_IOMMU_API is set/unse, which would make the code in
drivers/mmc/host/sdhci-tegra.c cleaner and thus easier to maintain.

>
> Thanks
> Prathamesh
>
> > -----Original Message-----
> > From: Ulf Hansson <[email protected]>
> > Sent: Tuesday, October 11, 2022 6:04 PM
> > To: Prathamesh Shete <[email protected]>
> > Cc: [email protected]; [email protected]; Jonathan Hunter
> > <[email protected]>; [email protected]; linux-
> > [email protected]; [email protected]; linux-
> > [email protected]; Aniruddha Tvs Rao <[email protected]>; Suresh
> > Mangipudi <[email protected]>; Krishna Yarlagadda
> > <[email protected]>
> > Subject: Re: [PATCH v7 2/4] mmc: sdhci-tegra: Add support to program MC
> > stream ID
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, 11 Oct 2022 at 13:44, Prathamesh Shete <[email protected]> wrote:
> > >
> > > Hi Ulf
> > >
> > > The initial patches were without the #ifdef. #ifdef is being added as per review
> > comments and kernel robot errors.
> > > Following error was detected by kernel robot
> > > >>
> > > All errors (new ones prefixed by >>):
> > >
> > > drivers/mmc/host/sdhci-tegra.c: In function 'sdhci_tegra_probe':
> > > >> drivers/mmc/host/sdhci-tegra.c:1794:54: error: 'struct iommu_fwspec' has
> > no member named 'ids'
> > > 1794 | tegra_host->streamid = fwspec->ids[0] & 0xffff;
> > > | ^~
> > >
> > >
> > > vim +1794 drivers/mmc/host/sdhci-tegra.c
> > > >>
> > > Adrian also pointed out this issue so to address these issues #ifdef
> > > was added
> >
> > I see!
> >
> > In that case, perhaps we can add a "depends on IOMMU_API" in the Kconfig
> > instead? Or is the tegra driver used on platforms where IOMMU_API could be
> > unset?
> >
> > [...]

Kind regards
Uffe

2022-10-14 07:52:49

by Prathamesh Shete

[permalink] [raw]

On Thu, Oct 13, 2022 at 03:43:18PM +0200, Ulf Hansson wrote:
> On Thu, 13 Oct 2022 at 08:33, Prathamesh Shete <[email protected]> wrote:
> >
> > Hi Ulf,
> >
> > >> In that case, perhaps we can add a "depends on IOMMU_API" in the Kconfig
> > >> instead? Or is the tegra driver used on platforms where IOMMU_API could be
> > >> unset?
> > Yes it can/will work with IOMMU disabled so its not recommended to add a "depends on" condition in Kconfig.
>
> Alright, in that case it looks to me that there are two other options
> to move forward.
>
> 1) Add proper definitions of the struct iommu_fwspec in
> include/linux/iommu.h even when CONFIG_IOMMU_API is unset. In a way it
> seems a bit silly to me, to have the iommu stubs around, unless those
> can be used for cases like this, right!?

I recall that I had proposed a patch for this a long time ago:

https://lore.kernel.org/all/[email protected]/

Given that Joerg had acked it at the time, I think the only reason why
it never ended up getting merged is because the rest of the series did
not get enough traction. I wonder if I should peel it out of the series
and propose it separately.

I agree it doesn't make any sense to have the stubs to allow compilation
and then break compilation because users of the stubs will end up
wanting to dereference the structure.

Thierry

Attachments:

(No filename) (1.36 kB)
signature.asc (849.00 B)
Download all attachments

2022-10-18 10:22:37

by Ulf Hansson

[permalink] [raw]

Subject: Re: [PATCH v7 2/4] mmc: sdhci-tegra: Add support to program MC stream ID

On Mon, 17 Oct 2022 at 16:11, Thierry Reding <[email protected]> wrote:
>
> On Thu, Oct 13, 2022 at 03:43:18PM +0200, Ulf Hansson wrote:
> > On Thu, 13 Oct 2022 at 08:33, Prathamesh Shete <[email protected]> wrote:
> > >
> > > Hi Ulf,
> > >
> > > >> In that case, perhaps we can add a "depends on IOMMU_API" in the Kconfig
> > > >> instead? Or is the tegra driver used on platforms where IOMMU_API could be
> > > >> unset?
> > > Yes it can/will work with IOMMU disabled so its not recommended to add a "depends on" condition in Kconfig.
> >
> > Alright, in that case it looks to me that there are two other options
> > to move forward.
> >
> > 1) Add proper definitions of the struct iommu_fwspec in
> > include/linux/iommu.h even when CONFIG_IOMMU_API is unset. In a way it
> > seems a bit silly to me, to have the iommu stubs around, unless those
> > can be used for cases like this, right!?
>
> I recall that I had proposed a patch for this a long time ago:
>
> https://lore.kernel.org/all/[email protected]/

That looks exactly what we would need!

>
> Given that Joerg had acked it at the time, I think the only reason why
> it never ended up getting merged is because the rest of the series did
> not get enough traction. I wonder if I should peel it out of the series
> and propose it separately.

Yes, please.

>
> I agree it doesn't make any sense to have the stubs to allow compilation
> and then break compilation because users of the stubs will end up
> wanting to dereference the structure.

Thanks for sharing your thoughts around this!

If you submit a new version of the old patch, I would certainly give
it my blessing.

Kind regards
Uffe