All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Brad Larson <brad@pensando.io>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	adrian.hunter@intel.com, alcooperx@gmail.com,
	andy.shevchenko@gmail.com, arnd@arndb.de, blarson@amd.com,
	brijeshkumar.singh@amd.com, catalin.marinas@arm.com,
	gsomlo@gmail.com, gerg@linux-m68k.org, krzk@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, lee.jones@linaro.org,
	broonie@kernel.org, yamada.masahiro@socionext.com,
	p.zabel@pengutronix.de, piotrs@cadence.com, p.yadav@ti.com,
	rdunlap@infradead.org, robh+dt@kernel.org, samuel@sholland.org,
	fancer.lancer@gmail.com, suravee.suthikulpanit@amd.com,
	thomas.lendacky@amd.com, will@kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
Date: Mon, 22 Aug 2022 12:53:22 +0200	[thread overview]
Message-ID: <CAPDyKFoYdQirftoEQAMBwXKXqSo-tu9EUvL6B6vHCj6cDd14ug@mail.gmail.com> (raw)
In-Reply-To: <20220820195750.70861-18-brad@pensando.io>

On Sat, 20 Aug 2022 at 21:58, Brad Larson <brad@pensando.io> wrote:
>
> From: Brad Larson <blarson@amd.com>
>
> Add support for mmc hardware reset with a reset-controller
> which would need to be enabled in the device tree with
> a supporting driver.  The default is disabled for all
> existing designs.
>
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  drivers/mmc/host/sdhci-cadence.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
> index c662c63d49fa..35d37b9aba63 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -12,6 +12,7 @@
>  #include <linux/mmc/mmc.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/reset.h>
>
>  #include "sdhci-pltfm.h"
>
> @@ -70,6 +71,7 @@ struct sdhci_cdns_priv {
>         spinlock_t wrlock;      /* write lock */
>         bool enhanced_strobe;
>         void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
> +       struct reset_control *rst_hw;
>         unsigned int nr_phy_params;
>         struct sdhci_cdns_phy_param phy_params[];
>  };
> @@ -458,6 +460,22 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
>                                          SDHCI_CDNS_HRS06_MODE_MMC_HS400);
>  }
>
> +static void sdhci_mmc_hw_reset(struct mmc_host *mmc)

Nitpick: Probably better to be consistent with the prefixes for
function names. So, I suggest changing this to
"sdhci_cdns_mmc_hw_reset".

> +{
> +       struct sdhci_host *host = mmc_priv(mmc);
> +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> +
> +       dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");

Maybe it's sufficient with dev_dbg?

> +
> +       reset_control_assert(priv->rst_hw);
> +       /* For eMMC, minimum is 1us but give it 9us for good measure */
> +       udelay(9);
> +
> +       reset_control_deassert(priv->rst_hw);
> +       /* For eMMC, minimum is 200us but give it 300us for good measure */
> +       usleep_range(300, 1000);
> +}
> +
>  static int sdhci_cdns_probe(struct platform_device *pdev)
>  {
>         struct sdhci_host *host;
> @@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>         if (ret)
>                 goto free;
>
> +       if (host->mmc->caps & MMC_CAP_HW_RESET) {
> +               priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");
> +               if (IS_ERR(priv->rst_hw)) {
> +                       ret = PTR_ERR(priv->rst_hw);
> +                       if (ret == -ENOENT)
> +                               priv->rst_hw = NULL;
> +               } else {
> +                       host->mmc_host_ops.card_hw_reset = sdhci_mmc_hw_reset;
> +               }
> +       }
> +
>         ret = sdhci_add_host(host);
>         if (ret)
>                 goto free;
> --

Other than the comments above, I wonder about what merging strategy we
should use for the series. I believe it looks fine for me to pick up
the mmc related patches, thus we can apply patches on a per subsystem
basis, right?

Kind regards
Uffe

WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Brad Larson <brad@pensando.io>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,  linux-mmc@vger.kernel.org,
	adrian.hunter@intel.com, alcooperx@gmail.com,
	 andy.shevchenko@gmail.com, arnd@arndb.de, blarson@amd.com,
	 brijeshkumar.singh@amd.com, catalin.marinas@arm.com,
	gsomlo@gmail.com,  gerg@linux-m68k.org, krzk@kernel.org,
	krzysztof.kozlowski+dt@linaro.org,  lee.jones@linaro.org,
	broonie@kernel.org, yamada.masahiro@socionext.com,
	 p.zabel@pengutronix.de, piotrs@cadence.com, p.yadav@ti.com,
	 rdunlap@infradead.org, robh+dt@kernel.org, samuel@sholland.org,
	 fancer.lancer@gmail.com, suravee.suthikulpanit@amd.com,
	 thomas.lendacky@amd.com, will@kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset
Date: Mon, 22 Aug 2022 12:53:22 +0200	[thread overview]
Message-ID: <CAPDyKFoYdQirftoEQAMBwXKXqSo-tu9EUvL6B6vHCj6cDd14ug@mail.gmail.com> (raw)
In-Reply-To: <20220820195750.70861-18-brad@pensando.io>

On Sat, 20 Aug 2022 at 21:58, Brad Larson <brad@pensando.io> wrote:
>
> From: Brad Larson <blarson@amd.com>
>
> Add support for mmc hardware reset with a reset-controller
> which would need to be enabled in the device tree with
> a supporting driver.  The default is disabled for all
> existing designs.
>
> Signed-off-by: Brad Larson <blarson@amd.com>
> ---
>  drivers/mmc/host/sdhci-cadence.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
> index c662c63d49fa..35d37b9aba63 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -12,6 +12,7 @@
>  #include <linux/mmc/mmc.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> +#include <linux/reset.h>
>
>  #include "sdhci-pltfm.h"
>
> @@ -70,6 +71,7 @@ struct sdhci_cdns_priv {
>         spinlock_t wrlock;      /* write lock */
>         bool enhanced_strobe;
>         void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
> +       struct reset_control *rst_hw;
>         unsigned int nr_phy_params;
>         struct sdhci_cdns_phy_param phy_params[];
>  };
> @@ -458,6 +460,22 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
>                                          SDHCI_CDNS_HRS06_MODE_MMC_HS400);
>  }
>
> +static void sdhci_mmc_hw_reset(struct mmc_host *mmc)

Nitpick: Probably better to be consistent with the prefixes for
function names. So, I suggest changing this to
"sdhci_cdns_mmc_hw_reset".

> +{
> +       struct sdhci_host *host = mmc_priv(mmc);
> +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> +
> +       dev_info(mmc_dev(host->mmc), "emmc hardware reset\n");

Maybe it's sufficient with dev_dbg?

> +
> +       reset_control_assert(priv->rst_hw);
> +       /* For eMMC, minimum is 1us but give it 9us for good measure */
> +       udelay(9);
> +
> +       reset_control_deassert(priv->rst_hw);
> +       /* For eMMC, minimum is 200us but give it 300us for good measure */
> +       usleep_range(300, 1000);
> +}
> +
>  static int sdhci_cdns_probe(struct platform_device *pdev)
>  {
>         struct sdhci_host *host;
> @@ -520,6 +538,17 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>         if (ret)
>                 goto free;
>
> +       if (host->mmc->caps & MMC_CAP_HW_RESET) {
> +               priv->rst_hw = devm_reset_control_get_optional_exclusive(dev, "hw");
> +               if (IS_ERR(priv->rst_hw)) {
> +                       ret = PTR_ERR(priv->rst_hw);
> +                       if (ret == -ENOENT)
> +                               priv->rst_hw = NULL;
> +               } else {
> +                       host->mmc_host_ops.card_hw_reset = sdhci_mmc_hw_reset;
> +               }
> +       }
> +
>         ret = sdhci_add_host(host);
>         if (ret)
>                 goto free;
> --

Other than the comments above, I wonder about what merging strategy we
should use for the series. I believe it looks fine for me to pick up
the mmc related patches, thus we can apply patches on a per subsystem
basis, right?

Kind regards
Uffe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-08-22 10:54 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-20 19:57 [PATCH v6 00/17] Support AMD Pensando Elba SoC Brad Larson
2022-08-20 19:57 ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 01/17] dt-bindings: arm: add AMD Pensando boards Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-22 18:15   ` Krzysztof Kozlowski
2022-08-22 18:15     ` Krzysztof Kozlowski
2022-08-31 22:40     ` Larson, Bradley
2022-08-31 22:40       ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 02/17] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-22 21:29   ` Rob Herring
2022-08-22 21:29     ` Rob Herring
2022-08-31 22:36     ` Larson, Bradley
2022-08-31 22:36       ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 03/17] dt-bindings: spi: cdns: Add compatible for " Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-22 18:22   ` Krzysztof Kozlowski
2022-08-22 18:22     ` Krzysztof Kozlowski
2022-08-31 18:37     ` Larson, Bradley
2022-08-31 18:37       ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 04/17] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller bindings Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-21 17:49   ` Serge Semin
2022-08-21 17:49     ` Serge Semin
2022-08-31 18:28     ` Larson, Bradley
2022-08-31 18:28       ` Larson, Bradley
2022-09-11 18:34       ` Serge Semin
2022-09-11 18:34         ` Serge Semin
2022-09-14 18:47         ` Larson, Bradley
2022-09-14 18:47           ` Larson, Bradley
2022-08-22 18:19   ` Krzysztof Kozlowski
2022-08-22 18:19     ` Krzysztof Kozlowski
2022-08-31 18:45     ` Larson, Bradley
2022-08-31 18:45       ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 05/17] dt-bindings: mfd: syscon: Add amd,pensando-elba-syscon compatible Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-22 18:23   ` Krzysztof Kozlowski
2022-08-22 18:23     ` Krzysztof Kozlowski
2022-08-31 18:35     ` Larson, Bradley
2022-08-31 18:35       ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-21 20:21   ` Rob Herring
2022-08-21 20:21     ` Rob Herring
2022-08-22 14:25   ` Rob Herring
2022-08-22 14:25     ` Rob Herring
2022-08-31 23:01     ` Larson, Bradley
2022-08-31 23:01       ` Larson, Bradley
2022-09-01  7:20       ` Krzysztof Kozlowski
2022-09-01  7:20         ` Krzysztof Kozlowski
2022-09-01 20:37         ` Larson, Bradley
2022-09-01 20:37           ` Larson, Bradley
2022-09-08 11:27           ` Krzysztof Kozlowski
2022-09-08 11:27             ` Krzysztof Kozlowski
2022-09-13 21:57             ` Larson, Bradley
2022-09-13 21:57               ` Larson, Bradley
2022-09-16  9:56               ` Krzysztof Kozlowski
2022-09-16  9:56                 ` Krzysztof Kozlowski
2022-09-29 22:50                 ` Larson, Bradley
2022-09-29 22:50                   ` Larson, Bradley
2022-10-07 15:53                   ` Krzysztof Kozlowski
2022-10-07 15:53                     ` Krzysztof Kozlowski
2022-08-20 19:57 ` [PATCH v6 07/17] dt-bindings: reset: amd,pensando-elbasr-reset: Add AMD Pensando SR Reset Controller bindings Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-21 20:21   ` Rob Herring
2022-08-21 20:21     ` Rob Herring
2022-08-20 19:57 ` [PATCH v6 08/17] MAINTAINERS: Add entry for AMD PENSANDO Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 09/17] arm64: Add config for AMD Pensando SoC platforms Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 10/17] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-09-30  7:27   ` Krzysztof Kozlowski
2022-09-30  7:27     ` Krzysztof Kozlowski
2022-10-04 19:46     ` Larson, Bradley
2022-10-04 19:46       ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 11/17] spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 12/17] spi: dw: Add support " Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-21 18:18   ` Serge Semin
2022-08-21 18:18     ` Serge Semin
2022-08-31 18:04     ` Larson, Bradley
2022-08-31 18:04       ` Larson, Bradley
2022-09-11 18:20       ` Serge Semin
2022-09-11 18:20         ` Serge Semin
2022-09-14 17:03         ` Larson, Bradley
2022-09-14 17:03           ` Larson, Bradley
2022-08-20 19:57 ` [PATCH v6 13/17] mmc: sdhci-cadence: Enable device specific override of writel() Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 14/17] mfd: pensando-elbasr: Add AMD Pensando Elba System Resource chip Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 15/17] reset: elbasr: Add AMD Pensando Elba SR Reset Controller Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-22  7:04   ` Philipp Zabel
2022-08-22  7:04     ` Philipp Zabel
2022-08-20 19:57 ` [PATCH v6 16/17] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-20 19:57 ` [PATCH v6 17/17] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
2022-08-20 19:57   ` Brad Larson
2022-08-22  7:03   ` Philipp Zabel
2022-08-22  7:03     ` Philipp Zabel
2022-08-31 22:49     ` Larson, Bradley
2022-08-31 22:49       ` Larson, Bradley
2022-08-22 10:53   ` Ulf Hansson [this message]
2022-08-22 10:53     ` Ulf Hansson
2022-08-22 12:25     ` Mark Brown
2022-08-22 12:25       ` Mark Brown
2022-08-31 23:29     ` Larson, Bradley
2022-08-31 23:29       ` Larson, Bradley

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=CAPDyKFoYdQirftoEQAMBwXKXqSo-tu9EUvL6B6vHCj6cDd14ug@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=alcooperx@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=blarson@amd.com \
    --cc=brad@pensando.io \
    --cc=brijeshkumar.singh@amd.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=gerg@linux-m68k.org \
    --cc=gsomlo@gmail.com \
    --cc=krzk@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=p.yadav@ti.com \
    --cc=p.zabel@pengutronix.de \
    --cc=piotrs@cadence.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=thomas.lendacky@amd.com \
    --cc=will@kernel.org \
    --cc=yamada.masahiro@socionext.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 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.