| Message ID | 20210826082107.47299-1-wsa+renesas@sang-engineering.com |
|---|---|
| State | New |
| Headers | show |
| Series | mmc: renesas_sdhi: fix regression with hard reset on old SDHIs | expand |
Hi Wolfram, On Thu, Aug 26, 2021 at 10:21 AM Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > Old SDHI instances have a default value for the reset register which > keeps it in reset state by default. So, when applying a hard reset we > need to manually leave the soft reset state as well. Later SDHI > instances have a different default value, the one we write manually now. > > Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible") > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > Geez, typical SDHI nastiness here... > > Geert: I think this fixes the issue you saw on Koelsch. It works fine on > my Lager now at least. Can you please test and tag if all goes well? > It would be great to have this in 5.14 but it definately needs Geert's > confirmation first. Thanks, fixes the SD Card issue is was seeing on Koelsch, and still works on Salvator-XS. Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Also:
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
On Thu, 26 Aug 2021 at 16:31, Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > > > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> > > Thanks a ton for testing, Geert! > > Ulf, any chance to get this into 5.14? Apologize for the delay! I have applied it for fixes (v5.15) and added a stable tag, hope that's okay. Thanks and kind regards Uffe
Hi Wolfram, On Thu, Aug 26, 2021 at 4:25 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Aug 26, 2021 at 10:21 AM Wolfram Sang > <wsa+renesas@sang-engineering.com> wrote: > > Old SDHI instances have a default value for the reset register which > > keeps it in reset state by default. So, when applying a hard reset we > > need to manually leave the soft reset state as well. Later SDHI > > instances have a different default value, the one we write manually now. > > > > Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible") > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > --- > > > > Geez, typical SDHI nastiness here... > > > > Geert: I think this fixes the issue you saw on Koelsch. It works fine on > > my Lager now at least. Can you please test and tag if all goes well? > > It would be great to have this in 5.14 but it definately needs Geert's > > confirmation first. > > Thanks, fixes the SD Card issue is was seeing on Koelsch, and still > works on Salvator-XS. > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Note that this does not fix the issues on gose and alt in Magnus' farm, but they may have failed before b4d86f37eacb too. gose: sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD51) mmc0: error -110 whilst initialising SD card DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) ------------[ cut here ]------------ WARNING: CPU: 1 PID: 35 at kernel/dma/debug.c:498 add_dma_entry+0x134/0x178 DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000001099f61 alt: sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) DMA-API: cacheline tracking EEXIST, overlapping mappings aren't supported sh_mobile_sdhi ee100000.mmc: timeout waiting for hardware interrupt (CMD19) ------------[ cut here ]------------ WARNING: CPU: 1 PID: 49 at kernel/dma/debug.c:498 add_dma_entry+0x134/0x178 DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000001082b42 Other MMC instances on gose and alt seem to work. From my limited collection of logs of booting on these boards, ee100000.mmc on - gose worked in v4.15, and is broken since at least v4.17, - alt worked in v5.1-rc6, and is broken now. SD cards might have been changed in the meantime, though. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, > From my limited collection of logs of booting on these boards, ee100000.mmc on > - gose worked in v4.15, and is broken since at least v4.17, Okay, so this is clearly not related to b4d86f37eacb. I don't have a Gose but there might be one in a remote lab. I will test when time permits. > - alt worked in v5.1-rc6, and is broken now. So, this is also not related to b4d86f37eacb. I have an Alt board here and will double check. IIRC it worked for me(tm). > SD cards might have been changed in the meantime, though. Hmm, that might make a difference. Thanks for the report. Still, the patch Ulf applied is good to have. Happy hacking, Wolfram
Hi Ulf, > Apologize for the delay! I seriously hope you have been on vacation :) > I have applied it for fixes (v5.15) and added a stable tag, hope that's okay. Sure, thanks a lot! All the best, Wolfram
> I have applied it for fixes (v5.15) and added a stable tag, hope that's okay.
Your 'fixes' branch is still in -next only. Could you send it to Linus,
please?
On Mon, 27 Sept 2021 at 09:57, Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > > > > I have applied it for fixes (v5.15) and added a stable tag, hope that's okay. > > Your 'fixes' branch is still in -next only. Could you send it to Linus, > please? Yes, it was busy last week. I will send a pull request later today/evening. Kind regards Uffe
> > Your 'fixes' branch is still in -next only. Could you send it to Linus, > > please? > > Yes, it was busy last week. I will send a pull request later today/evening. Thanks, Ulf! Much appreciated.
Hi Wolfram,
On my RZ/G2L board, if I configure card detection irq from SDHI, instead of card detection using gpio interrupt, then it is missing card detection interrupt after reset.
Just wondering, does it work on R-Car with CD irq from SDHI instead of card detection using gpio interrupt?
With the below changes, I am getting cd interrupts from SDHI after reset.
diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
index a4407f391f66..32f34de1a2a6 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct tmio_mmc_host *host)
/* Unknown why but without polling reset status, it will hang */
read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100,
false, priv->rstc);
+
+ tmio_mmc_enable_mmc_irqs(host, TMIO_MASK_CMD);
/* At least SDHI_VER_GEN2_SDR50 needs manual release of reset */
Regards,
Biju
> -----Original Message-----
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Sent: 26 August 2021 09:21
> To: linux-mmc@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org; Geert Uytterhoeven
> <geert+renesas@glider.be>; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Wolfram Sang <wsa+renesas@sang-
> engineering.com>
> Subject: [PATCH] mmc: renesas_sdhi: fix regression with hard reset on old
> SDHIs
>
> Old SDHI instances have a default value for the reset register which keeps
> it in reset state by default. So, when applying a hard reset we need to
> manually leave the soft reset state as well. Later SDHI instances have a
> different default value, the one we write manually now.
>
> Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible")
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Geez, typical SDHI nastiness here...
>
> Geert: I think this fixes the issue you saw on Koelsch. It works fine on
> my Lager now at least. Can you please test and tag if all goes well?
> It would be great to have this in 5.14 but it definately needs Geert's
> confirmation first.
>
> drivers/mmc/host/renesas_sdhi_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> b/drivers/mmc/host/renesas_sdhi_core.c
> index 6fc4cf3c9dce..a4407f391f66 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct tmio_mmc_host
> *host)
> /* Unknown why but without polling reset status, it will hang
> */
> read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100,
> false, priv->rstc);
> + /* At least SDHI_VER_GEN2_SDR50 needs manual release of reset
> */
> + sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
> priv->needs_adjust_hs400 = false;
> renesas_sdhi_set_clock(host, host->clk_cache);
> } else if (priv->scc_ctl) {
> --
> 2.30.2
Hi All,
I have reproduced this issue on RZ/G2M pin by configuring cd using SDHI instead of gpio irq.
After applying the patch card detection/removal works as expected.
Looks like the issue is present on R-Car Gen3 boards with cd as pin(ie, card detection/removal using SDHI IRQ).
I will post a patch to fixing this issue.
Please find the logs
With IRQ fix on reset function
-----------------------------------
3.090956] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz
[ 4.855266] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
[ 4.865396] mmcblk1: mmc1:aaaa SP32G 29.7 GiB
[ 4.885474] mmcblk1: p1
root@hihope-rzg2m:~# [ 60.220648] mmc1: card aaaa removed
[ 61.613520] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
[ 61.626103] mmcblk1: mmc1:aaaa SP32G 29.7 GiB
[ 61.647925] mmcblk1: p1
root@hihope-rzg2m:~# cat /proc/interrupts | grep ee100000.mmc
162: 2158 0 0 0 0 0 GIC-0 197 Level ee100000.mmc
without IRQ fix.
-----------------
renesas_sdhi_internal_dmac ee140000.mmc: mmc2 base at 0x00000000ee140000, max clock rate 200 MHz
But there is no card detection during boot.
it is not detecting card removal/removal at all
root@hihope-rzg2m:~# cat /proc/interrupts | grep ee100000.mmc
162: 0 0 0 0 0 0 GIC-0 197 Level ee100000.mmc
root@hihope-rzg2m:~#
regards,
Biju
> -----Original Message-----
> From: Biju Das
> Sent: 05 October 2021 18:03
> To: 'Wolfram Sang' <wsa+renesas@sang-engineering.com>; linux-
> mmc@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org; Geert Uytterhoeven
> <geert+renesas@glider.be>; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>
> Subject: RE: [PATCH] mmc: renesas_sdhi: fix regression with hard reset on
> old SDHIs
>
> Hi Wolfram,
>
> On my RZ/G2L board, if I configure card detection irq from SDHI, instead
> of card detection using gpio interrupt, then it is missing card detection
> interrupt after reset.
>
> Just wondering, does it work on R-Car with CD irq from SDHI instead of
> card detection using gpio interrupt?
>
> With the below changes, I am getting cd interrupts from SDHI after reset.
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> b/drivers/mmc/host/renesas_sdhi_core.c
> index a4407f391f66..32f34de1a2a6 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct tmio_mmc_host
> *host)
> /* Unknown why but without polling reset status, it will
> hang */
> read_poll_timeout(reset_control_status, ret, ret == 0, 1,
> 100,
> false, priv->rstc);
> +
> + tmio_mmc_enable_mmc_irqs(host, TMIO_MASK_CMD);
> /* At least SDHI_VER_GEN2_SDR50 needs manual release of
> reset */
>
>
> Regards,
> Biju
>
>
> > -----Original Message-----
> > From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Sent: 26 August 2021 09:21
> > To: linux-mmc@vger.kernel.org
> > Cc: linux-renesas-soc@vger.kernel.org; Geert Uytterhoeven
> > <geert+renesas@glider.be>; Yoshihiro Shimoda
> > <yoshihiro.shimoda.uh@renesas.com>; Wolfram Sang <wsa+renesas@sang-
> > engineering.com>
> > Subject: [PATCH] mmc: renesas_sdhi: fix regression with hard reset on
> > old SDHIs
> >
> > Old SDHI instances have a default value for the reset register which
> > keeps it in reset state by default. So, when applying a hard reset we
> > need to manually leave the soft reset state as well. Later SDHI
> > instances have a different default value, the one we write manually now.
> >
> > Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible")
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > ---
> >
> > Geez, typical SDHI nastiness here...
> >
> > Geert: I think this fixes the issue you saw on Koelsch. It works fine
> > on my Lager now at least. Can you please test and tag if all goes well?
> > It would be great to have this in 5.14 but it definately needs Geert's
> > confirmation first.
> >
> > drivers/mmc/host/renesas_sdhi_core.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> > b/drivers/mmc/host/renesas_sdhi_core.c
> > index 6fc4cf3c9dce..a4407f391f66 100644
> > --- a/drivers/mmc/host/renesas_sdhi_core.c
> > +++ b/drivers/mmc/host/renesas_sdhi_core.c
> > @@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct
> > tmio_mmc_host
> > *host)
> > /* Unknown why but without polling reset status, it will hang
> */
> > read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100,
> > false, priv->rstc);
> > + /* At least SDHI_VER_GEN2_SDR50 needs manual release of reset
> > */
> > + sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
> > priv->needs_adjust_hs400 = false;
> > renesas_sdhi_set_clock(host, host->clk_cache);
> > } else if (priv->scc_ctl) {
> > --
> > 2.30.2
Hi All,
Just to add, I made the below changes to test cd using SDHI IRQ rather than gpio interrupt on RZ/G2M board.
diff --git a/arch/arm64/boot/dts/renesas/hihope-common.dtsi b/arch/arm64/boot/dts/renesas/hihope-common.dtsi
index 0c7e6f790590..334225c39003 100644
--- a/arch/arm64/boot/dts/renesas/hihope-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/hihope-common.dtsi
@@ -225,15 +225,29 @@
};
sdhi0_pins: sd0 {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <3300>;
+ sd0_data {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sd0_mux {
+ groups = "sdhi0_cd";
+ function = "sdhi0";
+ };
};
sdhi0_pins_uhs: sd0_uhs {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <1800>;
+ sd0_data_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sd0_mux_uhs {
+ groups = "sdhi0_cd";
+ function = "sdhi0";
+ };
};
sdhi2_pins: sd2 {
@@ -294,7 +308,6 @@
vmmc-supply = <®_3p3v>;
vqmmc-supply = <&vccq_sdhi0>;
- cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
Regards,
Biju
> -----Original Message-----
> From: Biju Das <biju.das.jz@bp.renesas.com>
> Sent: 06 October 2021 13:46
> To: Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-
> mmc@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org; Geert Uytterhoeven
> <geert+renesas@glider.be>; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>
> Subject: RE: [PATCH] mmc: renesas_sdhi: fix regression with hard reset on
> old SDHIs
>
> Hi All,
>
> I have reproduced this issue on RZ/G2M pin by configuring cd using SDHI
> instead of gpio irq.
> After applying the patch card detection/removal works as expected.
>
> Looks like the issue is present on R-Car Gen3 boards with cd as pin(ie,
> card detection/removal using SDHI IRQ).
> I will post a patch to fixing this issue.
>
> Please find the logs
>
> With IRQ fix on reset function
> -----------------------------------
> 3.090956] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at
> 0x00000000ee100000, max clock rate 200 MHz
> [ 4.855266] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
> [ 4.865396] mmcblk1: mmc1:aaaa SP32G 29.7 GiB
> [ 4.885474] mmcblk1: p1
>
>
> root@hihope-rzg2m:~# [ 60.220648] mmc1: card aaaa removed
> [ 61.613520] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
> [ 61.626103] mmcblk1: mmc1:aaaa SP32G 29.7 GiB
> [ 61.647925] mmcblk1: p1
>
> root@hihope-rzg2m:~# cat /proc/interrupts | grep ee100000.mmc
> 162: 2158 0 0 0 0 0
> GIC-0 197 Level ee100000.mmc
>
>
> without IRQ fix.
> -----------------
>
> renesas_sdhi_internal_dmac ee140000.mmc: mmc2 base at 0x00000000ee140000,
> max clock rate 200 MHz
>
> But there is no card detection during boot.
> it is not detecting card removal/removal at all
>
> root@hihope-rzg2m:~# cat /proc/interrupts | grep ee100000.mmc
> 162: 0 0 0 0 0 0
> GIC-0 197 Level ee100000.mmc
> root@hihope-rzg2m:~#
>
>
> regards,
> Biju
>
>
>
> > -----Original Message-----
> > From: Biju Das
> > Sent: 05 October 2021 18:03
> > To: 'Wolfram Sang' <wsa+renesas@sang-engineering.com>; linux-
> > mmc@vger.kernel.org
> > Cc: linux-renesas-soc@vger.kernel.org; Geert Uytterhoeven
> > <geert+renesas@glider.be>; Yoshihiro Shimoda
> > <yoshihiro.shimoda.uh@renesas.com>; Geert Uytterhoeven
> > <geert+renesas@glider.be>
> > Subject: RE: [PATCH] mmc: renesas_sdhi: fix regression with hard reset
> > on old SDHIs
> >
> > Hi Wolfram,
> >
> > On my RZ/G2L board, if I configure card detection irq from SDHI,
> > instead of card detection using gpio interrupt, then it is missing
> > card detection interrupt after reset.
> >
> > Just wondering, does it work on R-Car with CD irq from SDHI instead of
> > card detection using gpio interrupt?
> >
> > With the below changes, I am getting cd interrupts from SDHI after
> reset.
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> > b/drivers/mmc/host/renesas_sdhi_core.c
> > index a4407f391f66..32f34de1a2a6 100644
> > --- a/drivers/mmc/host/renesas_sdhi_core.c
> > +++ b/drivers/mmc/host/renesas_sdhi_core.c
> > @@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct
> > tmio_mmc_host
> > *host)
> > /* Unknown why but without polling reset status, it
> > will hang */
> > read_poll_timeout(reset_control_status, ret, ret == 0,
> > 1, 100,
> > false, priv->rstc);
> > +
> > + tmio_mmc_enable_mmc_irqs(host, TMIO_MASK_CMD);
> > /* At least SDHI_VER_GEN2_SDR50 needs manual release
> > of reset */
> >
> >
> > Regards,
> > Biju
> >
> >
> > > -----Original Message-----
> > > From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > > Sent: 26 August 2021 09:21
> > > To: linux-mmc@vger.kernel.org
> > > Cc: linux-renesas-soc@vger.kernel.org; Geert Uytterhoeven
> > > <geert+renesas@glider.be>; Yoshihiro Shimoda
> > > <yoshihiro.shimoda.uh@renesas.com>; Wolfram Sang <wsa+renesas@sang-
> > > engineering.com>
> > > Subject: [PATCH] mmc: renesas_sdhi: fix regression with hard reset
> > > on old SDHIs
> > >
> > > Old SDHI instances have a default value for the reset register which
> > > keeps it in reset state by default. So, when applying a hard reset
> > > we need to manually leave the soft reset state as well. Later SDHI
> > > instances have a different default value, the one we write manually
> now.
> > >
> > > Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible")
> > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > > ---
> > >
> > > Geez, typical SDHI nastiness here...
> > >
> > > Geert: I think this fixes the issue you saw on Koelsch. It works
> > > fine on my Lager now at least. Can you please test and tag if all goes
> well?
> > > It would be great to have this in 5.14 but it definately needs
> > > Geert's confirmation first.
> > >
> > > drivers/mmc/host/renesas_sdhi_core.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c
> > > b/drivers/mmc/host/renesas_sdhi_core.c
> > > index 6fc4cf3c9dce..a4407f391f66 100644
> > > --- a/drivers/mmc/host/renesas_sdhi_core.c
> > > +++ b/drivers/mmc/host/renesas_sdhi_core.c
> > > @@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct
> > > tmio_mmc_host
> > > *host)
> > > /* Unknown why but without polling reset status, it will hang
> > */
> > > read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100,
> > > false, priv->rstc);
> > > + /* At least SDHI_VER_GEN2_SDR50 needs manual release of reset
> > > */
> > > + sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
> > > priv->needs_adjust_hs400 = false;
> > > renesas_sdhi_set_clock(host, host->clk_cache);
> > > } else if (priv->scc_ctl) {
> > > --
> > > 2.30.2
diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c index 6fc4cf3c9dce..a4407f391f66 100644 --- a/drivers/mmc/host/renesas_sdhi_core.c +++ b/drivers/mmc/host/renesas_sdhi_core.c @@ -561,6 +561,8 @@ static void renesas_sdhi_reset(struct tmio_mmc_host *host) /* Unknown why but without polling reset status, it will hang */ read_poll_timeout(reset_control_status, ret, ret == 0, 1, 100, false, priv->rstc); + /* At least SDHI_VER_GEN2_SDR50 needs manual release of reset */ + sd_ctrl_write16(host, CTL_RESET_SD, 0x0001); priv->needs_adjust_hs400 = false; renesas_sdhi_set_clock(host, host->clk_cache); } else if (priv->scc_ctl) {
Old SDHI instances have a default value for the reset register which keeps it in reset state by default. So, when applying a hard reset we need to manually leave the soft reset state as well. Later SDHI instances have a different default value, the one we write manually now. Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> --- Geez, typical SDHI nastiness here... Geert: I think this fixes the issue you saw on Koelsch. It works fine on my Lager now at least. Can you please test and tag if all goes well? It would be great to have this in 5.14 but it definately needs Geert's confirmation first. drivers/mmc/host/renesas_sdhi_core.c | 2 ++ 1 file changed, 2 insertions(+)