Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Simon Horman]

On Tue, Jan 10, 2017 at 10:08:48PM +0100, Niklas Söderlund wrote:
> Hi Simon,
> 
> I started to se errors when I was testing DMAC+IPMMU patches on top of 
> v4.10-rc1 on Koelsch.

There has been some discussion in this thread already. I would like to
provide some more information in case it is useful.

The 3.5.0 BSP appears to contain several that may be relevant to this
discussion:

383c4437846d mmc: sh_mobile_sdhi: Add detecting a change point of data to SCC 
tuning
1823812e0937 mmc: tmio: Add detecting a change point of data to SCC tunin
03935e9182d9 mmc: tmio: Fix tuning flow
c711db03349c mmc: sh_mobile_sdhi: Fix sampling clock position selecting
2838a2ff8ca7 mmc: tmio: fix soft lockup on CMD12 for R-Car SDHI


Of these, so far I have looked into "mmc: tmio: Fix tuning flow".
It seems to do several things:

- Ensure tuning initialisation is called for each tuning procedure:
  this seems a correct fix for a bug added by me
- Do not terminate tuning on error:
  this is not my reading of the documentation but may well be correct
- Reset more:
  I am least sure about this as it does not seem to have any explanation
  in the changelog

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Niklas Söderlund]

On 2017-01-12 14:03:24 +0100, Wolfram Sang wrote:
> 
> > I'll bring my Koelsch.
> 
> Great. I *think* one Koelsch will do, but if it is not too much of a
> problem, double-checking with a second board won't hurt. So, since Geert
> will probably bring all necessary cables and supplies, maybe you can
> pack the board nonetheless? But having one Koelsch already is really
> good!

If it fits in my luggage I will bring it then (I think it will), but I 
won't throw out my laptop to make room for it then since Geert will 
bring his :-)

> 
> > AFAIK, Wolfram is interested in "as many SD cards", not "as many Koelsch
> > boards".
> 
> 1st: as many Gen2 boards as possible (one per Gen2 SoC version would be
> awesome!) Gose, Alt anyone?
> 
> For those, I'll bring my SanDisk card which causes issues when ejecting
> on all my boards. This is my main target.
> 
> 2nd: as many SD cards as possible
> 
> This is a secondary target, but trying to find other issues/other type
> of cards with same issues will be helpful, too.
> 
> Thanks,
> 
>Wolfram
> 



-- 
Regards,
Niklas Söderlund

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Wolfram Sang]

> I'll bring my Koelsch.

Great. I *think* one Koelsch will do, but if it is not too much of a
problem, double-checking with a second board won't hurt. So, since Geert
will probably bring all necessary cables and supplies, maybe you can
pack the board nonetheless? But having one Koelsch already is really
good!

> AFAIK, Wolfram is interested in "as many SD cards", not "as many Koelsch
> boards".

1st: as many Gen2 boards as possible (one per Gen2 SoC version would be
awesome!) Gose, Alt anyone?

For those, I'll bring my SanDisk card which causes issues when ejecting
on all my boards. This is my main target.

2nd: as many SD cards as possible

This is a secondary target, but trying to find other issues/other type
of cards with same issues will be helpful, too.

Thanks,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Geert Uytterhoeven]

On Thu, Jan 12, 2017 at 12:17 PM, Niklas Söderlund
 wrote:
> On 2017-01-11 18:34:32 +0100, Wolfram Sang wrote:
>> > I also have a koelsch, so no need to take one on a plane ;-)
>>
>> I thought yours was so heavily hooked up that it was a bit cumbersome to
>> bring it somewhere. Happy to be wrong here :)
>
> To be super clear, Geert you can bring your Koelsch and Wolfram you only
> want to do testing on one Koelsch board and not as many as you can get
> your hands on?
>
> If so I be happy to leave my board at home and not have to take it on
> the plane, please confirm so there are no misunderstandings :-)

I'll bring my Koelsch.

AFAIK, Wolfram is interested in "as many SD cards", not "as many Koelsch
boards".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Niklas Söderlund]

On 2017-01-11 18:34:32 +0100, Wolfram Sang wrote:
> 
> > I also have a koelsch, so no need to take one on a plane ;-)
> 
> I thought yours was so heavily hooked up that it was a bit cumbersome to
> bring it somewhere. Happy to be wrong here :)
> 

To be super clear, Geert you can bring your Koelsch and Wolfram you only 
want to do testing on one Koelsch board and not as many as you can get 
your hands on?

If so I be happy to leave my board at home and not have to take it on 
the plane, please confirm so there are no misunderstandings :-)

-- 
Regards,
Niklas Söderlund

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Wolfram Sang]

> I also have a koelsch, so no need to take one on a plane ;-)

I thought yours was so heavily hooked up that it was a bit cumbersome to
bring it somewhere. Happy to be wrong here :)



signature.asc
Description: PGP signature

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Geert Uytterhoeven]

On Wed, Jan 11, 2017 at 4:57 PM, Niklas Söderlund
 wrote:
> On 2017-01-11 16:05:21 +0100, Wolfram Sang wrote:
>> I wanted to do some TDSEL testing on other Gen2 boards in Brussels,
>> provided that people could bring some. So, if you could bring that
>> Koelsch board, that would be really helpful.
>
> Sure, can you or someone else bring a power source? I plan to not check
> luggage so everything to conserve space helps :-)

I also have a koelsch, so no need to take one on a plane ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Niklas Söderlund]

Hi Wolfram,

On 2017-01-11 16:05:21 +0100, Wolfram Sang wrote:
> Hi Niklas,
> 
> > I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in 
> > pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch 
> > for Koelsch but found the documentation lacking and where unable to do 
> > so. That is I found a TDSEL register but no documentation of its 
> > content.
> 
> Sorry, that slipped through. Actually, I sent a patch for H2:
> 
> https://patchwork.kernel.org/patch/9434323/
> 
> I wanted to do some TDSEL testing on other Gen2 boards in Brussels,
> provided that people could bring some. So, if you could bring that
> Koelsch board, that would be really helpful.

Sure, can you or someone else bring a power source? I plan to not check 
luggage so everything to conserve space helps :-)

> 
> I assume that you created a similar patch to the above for Koelsch and
> the issue still remained? :(

Yes I did with the help from Geert, I have now also tried your patch.  
Unfortunately the result is the same and the warning is printed. I hope 
to be able to spend more time later this week with the tuning patch to 
try and figure this out.

> 
> Regards,
> 
>Wolfram
> 



-- 
Regards,
Niklas Söderlund

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Wolfram Sang]

Hi Niklas,

> I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in 
> pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch 
> for Koelsch but found the documentation lacking and where unable to do 
> so. That is I found a TDSEL register but no documentation of its 
> content.

Sorry, that slipped through. Actually, I sent a patch for H2:

https://patchwork.kernel.org/patch/9434323/

I wanted to do some TDSEL testing on other Gen2 boards in Brussels,
provided that people could bring some. So, if you could bring that
Koelsch board, that would be really helpful.

I assume that you created a similar patch to the above for Koelsch and
the issue still remained? :(

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Niklas Söderlund]

Hi Geert,

Thanks for your feedback.

On 2017-01-11 09:42:09 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Wed, Jan 11, 2017 at 9:35 AM, Niklas Söderlund
>  wrote:
> > On 2017-01-10 23:30:43 +0100, Wolfram Sang wrote:
> >> > Oddly enough the error are only printed when I insert the SD card in the
> >> > mmc0 slot. I can insert/eject the card multiple times in mmc1 and no
> >> > error but the first insertion in mmc0 and boom. Only difference I can
> >> > see are the clock speed between mmc0 and mmc1.
> >>
> >> Can you try this patch?
> >>
> >> From: Wolfram Sang 
> >> Date: Sun, 13 Nov 2016 11:10:09 +0100
> >> Subject: [PATCH] pinctrl: pfc: r8a7795: WIP: hardcode TDSEL value
> >>
> >> Otherwise, AC-180M won't get probed with SDR50 and EMMY-W1 has more
> >> tuning errors with SDR104.
> >>
> >> Signed-off-by: Wolfram Sang 
> >> ---
> >>  drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
> >> b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> >
> > I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in
> > pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch
> > for Koelsch but found the documentation lacking and where unable to do
> > so. That is I found a TDSEL register but no documentation of its
> > content.
> 
> The datasheet does mention which bits are for SD[023]_CLK.
> Actual bit patterns should be the same as on r8a7795.

Thanks for the information about the bit patterns. I tried using the 
same bit pattern on SD[023]_CLK but the error persisted :-( 

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@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

-- 
Regards,
Niklas Söderlund

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Geert Uytterhoeven]

Hi Niklas,

On Wed, Jan 11, 2017 at 9:35 AM, Niklas Söderlund
 wrote:
> On 2017-01-10 23:30:43 +0100, Wolfram Sang wrote:
>> > Oddly enough the error are only printed when I insert the SD card in the
>> > mmc0 slot. I can insert/eject the card multiple times in mmc1 and no
>> > error but the first insertion in mmc0 and boom. Only difference I can
>> > see are the clock speed between mmc0 and mmc1.
>>
>> Can you try this patch?
>>
>> From: Wolfram Sang 
>> Date: Sun, 13 Nov 2016 11:10:09 +0100
>> Subject: [PATCH] pinctrl: pfc: r8a7795: WIP: hardcode TDSEL value
>>
>> Otherwise, AC-180M won't get probed with SDR50 and EMMY-W1 has more
>> tuning errors with SDR104.
>>
>> Signed-off-by: Wolfram Sang 
>> ---
>>  drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
>> b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
>
> I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in
> pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch
> for Koelsch but found the documentation lacking and where unable to do
> so. That is I found a TDSEL register but no documentation of its
> content.

The datasheet does mention which bits are for SD[023]_CLK.
Actual bit patterns should be the same as on r8a7795.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Niklas Söderlund]

Hi Wolfram,

Thanks for your feedback.

On 2017-01-10 23:30:43 +0100, Wolfram Sang wrote:
> 
> > Oddly enough the error are only printed when I insert the SD card in the 
> > mmc0 slot. I can insert/eject the card multiple times in mmc1 and no 
> > error but the first insertion in mmc0 and boom. Only difference I can 
> > see are the clock speed between mmc0 and mmc1.
> 
> Can you try this patch?
> 
> From: Wolfram Sang 
> Date: Sun, 13 Nov 2016 11:10:09 +0100
> Subject: [PATCH] pinctrl: pfc: r8a7795: WIP: hardcode TDSEL value
> 
> Otherwise, AC-180M won't get probed with SDR50 and EMMY-W1 has more
> tuning errors with SDR104.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
> b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c

I'm doing my tests on Koelsch so I'm afraid setting the TDSEL in 
pfc-r8a7795.c won't do much ;-) Nevertheless I tried to mimic the patch 
for Koelsch but found the documentation lacking and where unable to do 
so. That is I found a TDSEL register but no documentation of its 
content.

I could try to run the test on r8a7795 but my understanding is that the 
IPMMU is not 100% OK on ES1.0. That is at least why I stopped testing on 
it a while back. Have this been addressed in a recent firmware I could 
upgrade to?

> index 3f58bfd676ce94..3e3f7585efe8b3 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> @@ -5416,6 +5416,9 @@ static int r8a7795_pinmux_init(struct sh_pfc *pfc)
>   pr_info("%s: R-Car H3 >= ES2.0\n", __func__);
>   // FIXME Fixup r8a7795_pinmux_info for ES2.0
>   }
> +
> +#define TDSEL 0xe60603c0
> + sh_pfc_write_reg(pfc, TDSEL, 32, 0xc3);
>   return 0;
>  }
>  
> -- 
> 2.10.2
> 
> 



-- 
Regards,
Niklas Söderlund

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Wolfram Sang]

> Oddly enough the error are only printed when I insert the SD card in the 
> mmc0 slot. I can insert/eject the card multiple times in mmc1 and no 
> error but the first insertion in mmc0 and boom. Only difference I can 
> see are the clock speed between mmc0 and mmc1.

Can you try this patch?

From: Wolfram Sang 
Date: Sun, 13 Nov 2016 11:10:09 +0100
Subject: [PATCH] pinctrl: pfc: r8a7795: WIP: hardcode TDSEL value

Otherwise, AC-180M won't get probed with SDR50 and EMMY-W1 has more
tuning errors with SDR104.

Signed-off-by: Wolfram Sang 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 3f58bfd676ce94..3e3f7585efe8b3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -5416,6 +5416,9 @@ static int r8a7795_pinmux_init(struct sh_pfc *pfc)
pr_info("%s: R-Car H3 >= ES2.0\n", __func__);
// FIXME Fixup r8a7795_pinmux_info for ES2.0
}
+
+#define TDSEL 0xe60603c0
+   sh_pfc_write_reg(pfc, TDSEL, 32, 0xc3);
return 0;
 }
 
-- 
2.10.2




signature.asc
Description: PGP signature

Re: [PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Niklas Söderlund]

Hi Simon,

I started to se errors when I was testing DMAC+IPMMU patches on top of 
v4.10-rc1 on Koelsch.

[2.247490] [drm] Device feb0.display probed
[2.254407] sh_mobile_sdhi ee10.sd: Got CD GPIO
[2.259535] sh_mobile_sdhi ee10.sd: Got WP GPIO
[2.473871] sh_mobile_sdhi ee10.sd: mmc0 base at 0xee10 max clock 
rate 195 MHz
[2.484048] sh_mobile_sdhi ee14.sd: Got CD GPIO
[2.489175] sh_mobile_sdhi ee14.sd: Got WP GPIO
[2.703850] sh_mobile_sdhi ee14.sd: mmc1 base at 0xee14 max clock 
rate 97 MHz
[2.714083] sh_mobile_sdhi ee16.sd: Got CD GPIO
[2.911847] ipmmu-vmsa e674.mmu: Unhandled fault: status 0x2101 iova 
0x40002000
[2.925838] sh_mobile_sdhi ee16.sd: mmc2 base at 0xee16 max clock 
rate 97 MHz
[2.938057] ipmmu-vmsa e674.mmu: Unhandled fault: status 0x2101 iova 
0x40002000
[2.938342] asoc-simple-card sound: ak4642-hifi <-> ec50.sound mapping ok
[2.954859] mmc0: new ultra high speed SDR50 SDHC card at address 
[2.962604] mmcblk0: mmc0: SU04G 3.69 GiB 
[2.971149] input: keyboard as /devices/platform/keyboard/input/input0
[2.980044] da9063-rtc da9063-rtc: setting system clock to 2017-01-10 
20:15:43 UTC (1484079343)
[2.989814]  mmcblk0: p1
[3.106206] Micrel KSZ8041RNLI ee70.etherne:01: attached PHY driver 
[Micrel KSZ8041RNLI] (mii_bus:phy_addr=ee70.etherne:01, irq=405)

If I boot the system without a SD card inserted the warnings are not 
printed, however when I insert the SD card they are immediately printed.  
Multiple removal/insertion of a card do not trigger additional warnings, 
only at the first insertion.

Oddly enough the error are only printed when I insert the SD card in the 
mmc0 slot. I can insert/eject the card multiple times in mmc1 and no 
error but the first insertion in mmc0 and boom. Only difference I can 
see are the clock speed between mmc0 and mmc1.

[  125.681585] ipmmu-vmsa e674.mmu: Unhandled fault: status 0x2101 iova 
0x40002000
[  125.698839] ipmmu-vmsa e674.mmu: Unhandled fault: status 0x2101 iova 
0x40002000
[  125.708228] mmc0: new ultra high speed SDR50 SDHC card at address 
[  125.716394] mmcblk0: mmc0: SU04G 3.69 GiB 
[  125.737443]  mmcblk0: p1
[  305.365862] mmc0: card  removed
[  307.933518] mmc0: new ultra high speed SDR50 SDHC card at address 
[  307.941948] mmcblk0: mmc0: SU04G 3.69 GiB 
[  307.964353]  mmcblk0: p1
[  310.965794] mmc0: card  removed
[  317.335789] mmc1: new ultra high speed SDR50 SDHC card at address 
[  317.343172] mmcblk1: mmc1: SU04G 3.69 GiB 
[  317.364223]  mmcblk1: p1

Sometimes the error is reported 3 times but in most cases only 2.

I can interact fine with the card (I tried checksumming a large file and 
compared with a known good) so it's not broken. I can also interact with 
other devices using the DMAC+IPMMU without similar warnings being 
printed at all, I tested with i2c6.

If i revert this patch 06f438dd389a699d ("mmc: sh_mobile_sdhi: Add 
tuning support") the warnings go away. I have not been able to figure 
out what in the patch triggers the warnings, and I'm not sure the 
problem are with sh_mobile_sdhi. I know to little about the DMAC and 
IPMMU to rule them out as the true source. Do you have any idea what 
might cause this? I'm happy to run more tests or help out in other ways 
if I can.

To reproduce start on v4.10-rc1 and use shmobile_defconfig with a few 
additions:

CONFIG_ARM_LPAE=y
CONFIG_IPMMU_VMSA=y

And I enable IPMMU for DMAC in DT:

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87214668d70f..d4500d79db1d 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -325,6 +325,21 @@
power-domains = < R8A7791_PD_ALWAYS_ON>;
#dma-cells = <1>;
dma-channels = <15>;
+   iommus = <_ds 0>,
+<_ds 1>,
+<_ds 2>,
+<_ds 3>,
+<_ds 4>,
+<_ds 5>,
+<_ds 6>,
+<_ds 7>,
+<_ds 8>,
+<_ds 9>,
+<_ds 10>,
+<_ds 11>,
+<_ds 12>,
+<_ds 13>,
+<_ds 14>;
};
 
dmac1: dma-controller@e672 {
@@ -356,6 +371,21 @@
power-domains = < R8A7791_PD_ALWAYS_ON>;
#dma-cells = <1>;
dma-channels = <15>;
+   iommus = <_ds 15>,
+<_ds 16>,
+<_ds 17>,
+<_ds 18>,
+<_ds 19>,
+<_ds 20>,
+<_ds 21>,
+<_ds 22>,
+<_ds 23>,
+<_ds 24>,
+   

[PATCH v8 6/6] mmc: sh_mobile_sdhi: Add tuning support

[Simon Horman]

Add tuning support for use with SDR104 mode
This includes adding support for the sampling clock controller (SCC).

Based on work by Ai Kyuse.

Cc: Ai Kyuse 
Signed-off-by: Simon Horman 
---
v8 [Simon Horman]
* Correct inverted logic in sh_mobile_sdhi_hw_reset
* Correct value of SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN

v7 [Simon Horman]
* No change

v6 [Simon Horman]
* Rebase to use host->taps

v5 [Simon Horman]
* As suggested by Ulf Hansson
  - Use more descriptive name for callback to check for SSC error
* Reinstate Gen3 tuning support

v4 [Simon Horman]
As suggested by Geert Uytterhoeven:
* guard SDR104 specific portion of probe with host->mmc->caps &
  MMC_CAP_UHS_SDR104
* As suggested by Wolfram Sang:
  - Pass priv to sd_scc_{read,write}32 to save host_to_priv access
for each call
  - Use 0x0 instead of other representations of 0 in hex
  - Use CLK_CTL_SCLKEN
  - Do not add unused SH_MOBILE_SDHI_MAX_TAP
  - Use ternary operator in sh_mobile_sdhi_select_tuning
  - Do include as yet unsupported HS200 in error string
* Reintroduce retuning support: This was removed in v3.
* Revert to algorithm in v1 patchset, on further reading of the documentation
  it appears to be correct.

v3 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Do not add unused retuning callback to struct tmio_mmc_host
  - Change return type of prepare_tuning callback to void
  - Add tap_size parameter to select_tuning callback

v2 [Simon Horman]
* As suggested by Kuninori Morimoto
  - Use host->mmc->caps & MMC_CAP_UHS_SDR104 instead of
pdata->flags & TMIO_MMC_HAS_UHS_SCC to avoid needing the
MMC_CAP_UHS_SDR104 flag at all.
N.B: Morimoto-san suggested using but this flag is not actually
set there in by current probe come.
  - Simplify logic in sh_mobile_sdhi_inquiry_tuning
* As suggested by Wolfram Sang
  - Use clk_rate instead of clk for field in struct sh_mobile_sdhi_scc
  - Remove inquiry_tuning callback which is now unnecessary as calling
of tuning is handled by the core
  - Removed unused sh_mobile_sdhi_set_clk_div callback
  - Save sci_base address rather than calculating it on each read and write
* Update selection logic in sh_mobile_sdhi_select_tuning to match spec
* Use bool instead of long for taps parameter of
  sh_mobile_sdhi_select_tuning()
* Return 0 from sh_mobile_sdhi_init_tuning() if the
  SDR104 capability is not set and thus tuning should not
  be performed because it is not supported by the hardware

v1 [Simon Horman]
* Rebase
* Always use value of 0x8 for TAPNUM field of DTCNTL register
  rather than reading value from DT property. There does not
  seem to be a need to expose this in DT at this point.
* Do not include tmio_mmc_start_signal_voltage_switch changes which
  are already in mainline in a different form
* Do not add renesas,clk-rate property as the max-frequency property, which
  is now present in mainline, seems to provide the needed rate
* Omit Gen3 specific changes
* Do not provide renesas,mmc-scc-tappos DT property.
  Instead, always use taps provided in driver.
* Do not parse sd-uhs-sdr50 and sd-uhs-sdr104 properties.
  This is handled by the core.

v0 [Ai Kyuse]

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/sh_mobile_sdhi.c | 265 +-
 1 file changed, 264 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c 
b/drivers/mmc/host/sh_mobile_sdhi.c
index 49edff7fee49..15c77bc6e4ee 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -47,6 +47,11 @@
 
 #define host_to_priv(host) container_of((host)->pdata, struct sh_mobile_sdhi, 
mmc_data)
 
+struct sh_mobile_sdhi_scc {
+   unsigned long clk_rate; /* clock rate for SDR104 */
+   u32 tap;/* sampling clock position for SDR104 */
+};
+
 struct sh_mobile_sdhi_of_data {
unsigned long tmio_flags;
unsigned long capabilities;
@@ -54,6 +59,9 @@ struct sh_mobile_sdhi_of_data {
enum dma_slave_buswidth dma_buswidth;
dma_addr_t dma_rx_offset;
unsigned bus_shift;
+   int scc_offset;
+   struct sh_mobile_sdhi_scc *taps;
+   int taps_num;
 };
 
 static const struct sh_mobile_sdhi_of_data of_default_cfg = {
@@ -66,12 +74,35 @@ static const struct sh_mobile_sdhi_of_data 
of_rcar_gen1_compatible = {
.capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
 };
 
+/* Definitions for sampling clocks */
+static struct sh_mobile_sdhi_scc rcar_gen2_scc_taps[] = {
+   {
+   .clk_rate = 15600,
+   .tap = 0x0703,
+   },
+   {
+   .clk_rate = 0,
+   .tap = 0x0300,
+   },
+};
+
 static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_MIN_RCAR2,
.capabilities   =