[PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process

[jbrunet@baylibre.com (Jerome Brunet)]

On Wed, 2017-09-27 at 18:24 +0200, Jerome Brunet wrote:
> On Tue, 2017-09-19 at 20:54 +0200, Heiner Kallweit wrote:
> > > > Unfortunately this still doesn't fix the issue here.
> > > > Tuning rx and tx clk sequentially assumes both are independent, what
> > > > they
> > > > IMHO are not. So meybe we have to check all combinations of rx/tx clk
> > > > phase.
> > > 
> > > Interesting, I would be curious to know what tuning value you ended with,
> > > compared to the "hard-coded' working value you have set.
> > > 
> > > You can get that fairly easily now, using CCF in debugfs, in
> > > <debugfs>/clk/clk_summary, the different phase are reported
> > > 
> > 
> > This gives me:
> > 
> > core phase: 180
> > rx phase: 0
> > tx phase: 270
> > 
> > And I end up with a corrupted root file system.
> 
> You should have had tuning on both the Rx and Tx phase and yet, you end up
> with
> the default values ... that's strange
> 
> I should be able to get my hands on 16GB emmc module for this platform soon.
> Let's see ...


So, I did some tests on the odroidc2 with the 16GB emmc module.

1) With Mainline + DTS patches (Waiting in Olof late branch) + the patch
proposed here:

mmc0: new HS200 MMC card at address 0001
mmcblk0: mmc0:0001 SDW16G 14.7 GiB
mmcblk0boot0: mmc0:0001 SDW16G partition 1 4.00 MiB
mmcblk0boot1: mmc0:0001 SDW16G partition 2 4.00 MiB
mmcblk0rpmb: mmc0:0001 SDW16G partition 3 4.00 MiB
mmcblk0: p1 p2 p3 p4

and clk_summary

d0074000.mmc#mux     1            1  1000000000          0 0
 d0074000.mmc#div    1            1   200000000          0 0
  d0074000.mmc#core  1            1   200000000          0 180
  d0074000.mmc#rx    0            0   200000000          0 120
  d0074000.mmc#tx    0            0   200000000          0 0

Note the tx phase tuning ended-up with the value you expected. I've done read
tests with this and there was no issue.

This made no sense with the value you reported but I thought maybe you did your
test in hs400 ... so I tested and it seems to be the case. In this mode, the
tuning value got reset.

This is because I mistakenly place the phase reset in POWER_ON instead of
POWER_UP.
The phase get reset every time the set_ios() is called, which is not what we
want.

With a few fix applied here, this is what I get:

# cat /sys/kernel/debug/mmc0/ios       
clock:          200000000 Hz           
actual clock:   166666667 Hz           
vdd:            21 (3.3 ~ 3.4 V)       
bus mode:       2 (push-pull)          
chip select:    0 (don't care)         
power mode:     2 (on)                 
bus width:      3 (8 bits)             
timing spec:    10 (mmc HS400)         
signal voltage: 1 (1.80 V)             
driver type:    0 (driver type B)      

clk_summary:
d0074000.mmc#mux            1            1  1000000000          0 0
 d0074000.mmc#div           1            1   333333334          0 0
  d0074000.mmc#core         1            1   333333334          0 180
  d0074000.mmc#rx           0            0   333333334          0 120
  d0074000.mmc#tx           0            0   333333334          0 0

No errors reported while doing read test using dd. Read throughput appears to be
around 220MB/s with this module.

I have posted a series with the fixes here:
https://lkml.kernel.org/r/20171002122743.32334-1-jbrunet at baylibre.com

Jerome.