mbox series

[v2,0/3] mmc: tmio: Fix reset operation

Message ID 20181016013832.2385-1-niklas.soderlund@ragnatech.se (mailing list archive)
Headers show
Series mmc: tmio: Fix reset operation | expand

Message

Niklas Söderlund Oct. 16, 2018, 1:38 a.m. UTC
From: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

Hi,

While looking at the Renesas BSP kernel I found patches which improves
the state of the hardware at probe and after runtime resume.

Patch 1/3 make sure the module clock is enabled after resuming before 
register are accessed. Patch 2/3 is the real change in this series and 
brings in reset of the vendor specific callback when resetting (SCC in 
the Renesas case). While 3/3 simply make sure that the IRQ mask for 
Renesas boards (Gen2 and later) are in a good shape after probe (and 
reset).

In addition to addressing the state after resuming it helped unbreak a 
SD card I have which are very problematic on Koelsch. Without this 
series inserting the card results in:

sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee100000.sd: Tuning procedure failed
mmc0: tuning execution failed: -5
mmc0: error -5 whilst initialising SD card
sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)

While with this series applied (patch 2/3):

sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
mmc0: new ultra high speed SDR50 SDHC card at address aaaa
mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
 mmcblk0: p1 p2

Patch 1/3 was previously part of 2/3 but as it deals with a unrelated 
issue it's here broken out to a separate patch. Patch 3/3 have once been 
posted outside this series bit after comments from Wolfram it's brought 
back as it now deepens on 2/3.

Most changes in this series are based on similar work from Masaharu 
Hayakawa but for this version all changes now differ quiet a lot from 
his work.  All mails sent to him bounce with a "Undelivered Mail 
Returned to Sender" error. I therefor felt the need to claim authorship 
as I don't want to post blame of my (potential) mistakes on some else.

Niklas Söderlund (3):
  mmc: tmio: enable module clock before resetting when resuming
  mmc: tmio: fix reset operation
  mmc: renesas_sdhi: add initial setting of interrupt mask register

 drivers/mmc/host/renesas_sdhi_core.c |  4 ++++
 drivers/mmc/host/tmio_mmc.h          |  1 +
 drivers/mmc/host/tmio_mmc_core.c     | 22 ++++++++++------------
 3 files changed, 15 insertions(+), 12 deletions(-)

Comments

Geert Uytterhoeven Oct. 16, 2018, 7:05 a.m. UTC | #1
Hi Niklas,

On Tue, Oct 16, 2018 at 3:39 AM Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> From: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> While looking at the Renesas BSP kernel I found patches which improves
> the state of the hardware at probe and after runtime resume.
>
> Patch 1/3 make sure the module clock is enabled after resuming before
> register are accessed. Patch 2/3 is the real change in this series and
> brings in reset of the vendor specific callback when resetting (SCC in
> the Renesas case). While 3/3 simply make sure that the IRQ mask for
> Renesas boards (Gen2 and later) are in a good shape after probe (and
> reset).
>
> In addition to addressing the state after resuming it helped unbreak a
> SD card I have which are very problematic on Koelsch. Without this
> series inserting the card results in:
>
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> sh_mobile_sdhi ee100000.sd: Tuning procedure failed
> mmc0: tuning execution failed: -5
> mmc0: error -5 whilst initialising SD card
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
>
> While with this series applied (patch 2/3):
>
> sh_mobile_sdhi ee100000.sd: timeout waiting for hardware interrupt (CMD19)
> mmc0: new ultra high speed SDR50 SDHC card at address aaaa
> mmcblk0: mmc0:aaaa SU04G 3.69 GiB
>  mmcblk0: p1 p2

Nice!

Can you please check if this fixes the similar issue on Magnus' ALT?
My (old, latest is v4.15) logs show the same timeout, but with errors
84 (EILSEQ)
or 110 (ETIMEDOUT) instead of 5 (EIO).

Thanks!

Gr{oetje,eeting}s,

                        Geert
Wolfram Sang Oct. 19, 2018, 9:38 p.m. UTC | #2
> Can you please check if this fixes the similar issue on Magnus' ALT?

We will have an Alt in Edinburgh which also showed such messages.