Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
MIME-Version: 1.0
References: <20230830092314.624212-1-mathieu.moneyron@gmail.com>
 <096e9122-23b8-5a36-7779-28994187c620@intel.com> <9a311ce3-0d29-af39-5533-c1cad6de1300@microchip.com>
In-Reply-To: <9a311ce3-0d29-af39-5533-c1cad6de1300@microchip.com>
From:   Mathieu Moneyron <mathieu.moneyron@gmail.com>
Date:   Sat, 23 Sep 2023 16:23:16 +0200
Message-ID: <CAKmtTBYquiYQ-=MVWCqH8=iiFONvt6B_==EZhWsQkSA8WNuYUQ@mail.gmail.com>
Subject: Re: [PATCH] mmc: Fix force card detect in sdhci
To:     Aubin Constans <aubin.constans@microchip.com>
Cc:     Adrian Hunter <adrian.hunter@intel.com>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Eugen Hristev <eugen.hristev@collabora.com>,
        Ludovic Desroches <ludovic.desroches@microchip.com>,
        Nicolas Ferre <nicolas.ferre@microchip.com>,
        linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Aubin,

Thanks for your feedback.
I'll try my best to give clear explanations.

On Sat, Sep 23, 2023 at 2:44=E2=80=AFPM Aubin Constans
<aubin.constans@microchip.com> wrote:
>
> On 04/09/2023 09:38, Adrian Hunter wrote:
> > + Eugen Hristev  > > On 30/08/23 12:23, mathieu wrote: >> On the ATMEL =
at91 when using
> the non-removable flag in device tree >> and not using the card-detect
> pin inside the device-tree pinctrl, >> the card detect pin is physically
> still used which can cause >> unknown behaviour when this pin is used
> for other purposes.
> Hi Mathieu,
>
> On which SoC(s) exactly, has this behaviour been observed?

This has been observed on SAMA5D27.
>
>
> Also, has this issue been discussed in any separate support request, in s=
uch
> case we could retrieve some background from it?
>
> By "unknown behaviour", do you mean "the card insertion status would
> follow whatever electrical level is seen on the card-detect pin"?

For instance our board design has the PA13 (card detect) pin wired to drive=
 a
3v3 power supply.
The fixed regulator driver configure this pin as output (described in the d=
evice
tree).
But what I observed is that the sdmmc driver still want to use PA13 as the =
card
detect signal which is then configured as an input. This cause the 3v3 powe=
r to
drop.

By "unknown behavior" I mean the configuration of this pin as card detect s=
ets
unwanted electrical levels to what's connected to this pin.
>
>
> >>  >> From my interpretation this seems to be caused by a hardware desig=
n
>  >> flaw and the real hardware is not working as intended by the >>
> documentation. >>
> >>
> >> Signed-off-by: Mathieu Moneyron <mathieu.moneyron@gmail.com>
> >>
> >> ---
> >>  drivers/mmc/host/sdhci-of-at91.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/sdhci-of-at91.c
> >> b/drivers/mmc/host/sdhci-of-at91.c
> >> index 69fef88e7..4fd6bfbf6 100644
> >> --- a/drivers/mmc/host/sdhci-of-at91.c
> >> +++ b/drivers/mmc/host/sdhci-of-at91.c
> >> @@ -51,10 +51,15 @@ struct sdhci_at91_priv {
> >>  static void sdhci_at91_set_force_card_detect(struct sdhci_host *host)
> >>  {
> >>      u8 mc1r;
> >> +    u8 ctrl;
> >>
> >>      mc1r =3D readb(host->ioaddr + SDMMC_MC1R);
> >>      mc1r |=3D SDMMC_MC1R_FCD;
> >>      writeb(mc1r, host->ioaddr + SDMMC_MC1R);
> >> +
> >> +    ctrl =3D readb(host->ioaddr + SDHCI_HOST_CONTROL);
> >> +    ctrl |=3D SDHCI_CTRL_CDTEST_INS | SDHCI_CTRL_CDTEST_EN;
> >> +    writeb(ctrl, host->ioaddr + SDHCI_HOST_CONTROL);
> >>  }
> >>
> >>  static void sdhci_at91_set_clock(struct sdhci_host *host, unsigned
> >> int clock)
>
> Kind regards,
> Aubin
>
Kind regards,
Mathieu