Problems after recent changes to meson-gx-mmc driver

Problems after recent changes to meson-gx-mmc driver

[Heiner Kallweit]

Hi Jerome,

the recent changes, most likely one of the changes affecting the clock phase setting
or tuning, break mmc on my system (Odroid C2 + Hardkernel 128GB eMMC card).
"Next" kernel from Aug 25th works fine here. Hadn't time yet to bisect the issue.

As additional info, that's what the eMMC DT config looks like here.
The issue remains when switching to HS200.

/* eMMC */
&sd_emmc_c {
        status = "okay";
        pinctrl-0 = <&emmc_pins>;
        pinctrl-names = "default";

        bus-width = <8>;
        cap-sd-highspeed;
        max-frequency = <200000000>;
        non-removable;
        disable-wp;
        cap-mmc-highspeed;
        mmc-ddr-1_8v;
        mmc-hs400-1_8v;

        mmc-pwrseq = <&emmc_pwrseq>;
        vmmc-supply = <&vcc3v3>;
        vqmmc-supply = <&vcc1v8>;
};

Kind regards,
Heiner


[    0.784729] mmcblk0: mmc0:0001 DJNB4R 116 GiB
[    0.790226] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB
[    0.794860] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB
[    0.800723] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB
[    0.807012]  mmcblk0: p1
[    0.815910] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    0.818973] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    0.826699] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    0.836784] mmcblk0: error -110 sending stop command
[    0.916784] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    0.920069] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    0.930234] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    0.933718] print_req_error: I/O error, dev mmcblk0, sector 2048
[    0.939669] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write
[    0.949190] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[    0.955397] VFS: Mounted root (ext4 filesystem) on device 179:1.
[    0.963359] devtmpfs: mounted
[    0.964411] Freeing unused kernel memory: 320K
[    0.983379] mmcblk0: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
[    0.989571] mmcblk0: response CRC error sending r/w cmd command, card status 0x900
[    1.093957] systemd[1]: System time before build time, advancing clock.
[    1.159148] mmcblk0: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
[    1.193201] NET: Registered protocol family 10
[    1.193750] Segment Routing with IPv6
[    1.205032] systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYP                                                                                                                                            TSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid)
[    1.220390] systemd[1]: Detected architecture arm64.
[    1.244200] systemd[1]: Set hostname to <odroidc2>.
[    1.370901] mmcblk0: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
[    1.378114] mmcblk0: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
[    1.397501] systemd[1]: Created slice User and Session Slice.
[    1.415651] systemd[1]: Reached target Remote File Systems.
[    1.432905] systemd[1]: Created slice System Slice.
[    1.451645] systemd[1]: Reached target Slices.
[    1.468022] systemd[1]: Created slice system-serial\x2dgetty.slice.
[    1.483793] systemd[1]: Listening on udev Control Socket.
[    1.502607] systemd[1]: Mounting Kernel Debug File System...
[    1.830855] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered,discard
[    2.077375] systemd-journald[644]: Received request to flush runtime journal from PID 1
[    2.085030] systemd-journald[644]: File /var/log/journal/5d03187c26854bbe9eab8ea99e9291cb/system.journal corrupted or uncleanly                                                                                                                                             shut down, renaming and replacing.
[    2.096502] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.102475] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.110107] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.117608] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.125121] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.132627] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.140032] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.147511] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.155040] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.161860] print_req_error: I/O error, dev mmcblk0, sector 76224512
[    2.168147] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:322: I/O error 10 writing to inode 2359327 (offset 0 size 4096 star                                                                                                                                            ting block 9528065)
[    2.181256] Buffer I/O error on device mmcblk0p1, logical block 9527808
[    2.190050] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.196320] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.203573] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.211149] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.218616] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.226114] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.233593] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.241013] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.248513] mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
[    2.255350] print_req_error: I/O error, dev mmcblk0, sector 121899008

Re: Problems after recent changes to meson-gx-mmc driver

[Jerome Brunet]

On Sat, 2017-09-09 at 15:14 +0200, Heiner Kallweit wrote:
> Hi Jerome,
> 
> the recent changes, most likely one of the changes affecting the clock phase
> setting
> or tuning, break mmc on my system (Odroid C2 + Hardkernel 128GB eMMC card).
> "Next" kernel from Aug 25th works fine here. Hadn't time yet to bisect the
> issue.
> 
> As additional info, that's what the eMMC DT config looks like here.
> The issue remains when switching to HS200.
> 
> /* eMMC */
> &sd_emmc_c {
>         status = "okay";
>         pinctrl-0 = <&emmc_pins>;
>         pinctrl-names = "default";
> 
>         bus-width = <8>;
>         cap-sd-highspeed;
>         max-frequency = <200000000>;
>         non-removable;
>         disable-wp;
>         cap-mmc-highspeed;
>         mmc-ddr-1_8v;
>         mmc-hs400-1_8v;

This is not the setup in the upstream dts.

>From what I see here, this emmc is using dual data rate modes.
So the most impacting change would be :

mmc: meson-gx: fix dual data rate mode frequencies

Before this patch the output frequency was actually half what was reported, so
in this case, I suspect you were only running at 100MHz before. At this
frequency, tuning on the emmc is a lot easier to achieve, if even necessary.

I have tested a fair amount of mmc configuration but I don't have setup with
HS400, but I think the following issue may rise:

* Generating 200MHz DDR output out of fdiv2 is not possible: this would require
400Mhz input which cannot be done from 1GHz and a simple divider. You can either
get 500Mhz (250Mhz out) or 250MHz (125MHz out)

* In HS400, If I remember correctly, tuning is done in HS200, then switch to
HS400 (bumping the input clock) May it require different phase setting ?

* Running 200MHz on the PCB is very demanding. I have seen that when trying
SDR104. Amplitude and signal quality drops significantly between 100MHz and
200Mhz. Are you sure the lines (including PCB, connectors, etc) are able to cope
with this and provide a good enough signal to the eMMC chip ?

Bottom line is that this eMMC never really run HS400, at least not at the speed
you thought it did. To get the rate you had previously, simply change this:

        max-frequency = <100000000>;



> 
>         mmc-pwrseq = <&emmc_pwrseq>;
>         vmmc-supply = <&vcc3v3>;
>         vqmmc-supply = <&vcc1v8>;
> };
> 
> Kind regards,
> Heiner
> 
> 
> [    0.784729] mmcblk0: mmc0:0001 DJNB4R 116 GiB
> [    0.790226] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB
> [    0.794860] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB
> [    0.800723] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB
> [    0.807012]  mmcblk0: p1
> [    0.815910] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    0.818973] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    0.826699] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    0.836784] mmcblk0: error -110 sending stop command
> [    0.916784] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    0.920069] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    0.930234] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    0.933718] print_req_error: I/O error, dev mmcblk0, sector 2048
> [    0.939669] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync
> page write
> [    0.949190] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode.
> Opts: (null)
> [    0.955397] VFS: Mounted root (ext4 filesystem) on device 179:1.
> [    0.963359] devtmpfs: mounted
> [    0.964411] Freeing unused kernel memory: 320K
> [    0.983379] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
> card status 0x900
> [    0.989571] mmcblk0: response CRC error sending r/w cmd command, card
> status 0x900
> [    1.093957] systemd[1]: System time before build time, advancing clock.
> [    1.159148] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
> card status 0x900
> [    1.193201] NET: Registered protocol family 10
> [    1.193750] Segment Routing with IPv6
> [    1.205032] systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT
> -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
> +LIBCRYP                                                                      
>                                                                       TSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN
> default-hierarchy=hybrid)
> [    1.220390] systemd[1]: Detected architecture arm64.
> [    1.244200] systemd[1]: Set hostname to <odroidc2>.
> [    1.370901] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
> card status 0x900
> [    1.378114] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
> card status 0x900
> [    1.397501] systemd[1]: Created slice User and Session Slice.
> [    1.415651] systemd[1]: Reached target Remote File Systems.
> [    1.432905] systemd[1]: Created slice System Slice.
> [    1.451645] systemd[1]: Reached target Slices.
> [    1.468022] systemd[1]: Created slice system-serial\x2dgetty.slice.
> [    1.483793] systemd[1]: Listening on udev Control Socket.
> [    1.502607] systemd[1]: Mounting Kernel Debug File System...
> [    1.830855] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered,discard
> [    2.077375] systemd-journald[644]: Received request to flush runtime
> journal from PID 1
> [    2.085030] systemd-journald[644]: File
> /var/log/journal/5d03187c26854bbe9eab8ea99e9291cb/system.journal corrupted or
> uncleanly                                                                     
>                                                                         shut
> down, renaming and replacing.
> [    2.096502] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.102475] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.110107] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.117608] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.125121] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.132627] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.140032] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.147511] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.155040] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.161860] print_req_error: I/O error, dev mmcblk0, sector 76224512
> [    2.168147] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:322: I/O error
> 10 writing to inode 2359327 (offset 0 size 4096
> star                                                                          
>                                                                   ting block
> 9528065)
> [    2.181256] Buffer I/O error on device mmcblk0p1, logical block 9527808
> [    2.190050] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.196320] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.203573] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.211149] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.218616] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.226114] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.233593] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.241013] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.248513] mmcblk0: response CRC error sending r/w cmd command, card
> status 0xd00
> [    2.255350] print_req_error: I/O error, dev mmcblk0, sector 121899008
> 

Re: Problems after recent changes to meson-gx-mmc driver

[Heiner Kallweit]

Am 09.09.2017 um 16:05 schrieb Jerome Brunet:
> On Sat, 2017-09-09 at 15:14 +0200, Heiner Kallweit wrote:
>> Hi Jerome,
>>
>> the recent changes, most likely one of the changes affecting the clock phase
>> setting
>> or tuning, break mmc on my system (Odroid C2 + Hardkernel 128GB eMMC card).
>> "Next" kernel from Aug 25th works fine here. Hadn't time yet to bisect the
>> issue.
>>
>> As additional info, that's what the eMMC DT config looks like here.
>> The issue remains when switching to HS200.
>>
>> /* eMMC */
>> &sd_emmc_c {
>>         status = "okay";
>>         pinctrl-0 = <&emmc_pins>;
>>         pinctrl-names = "default";
>>
>>         bus-width = <8>;
>>         cap-sd-highspeed;
>>         max-frequency = <200000000>;
>>         non-removable;
>>         disable-wp;
>>         cap-mmc-highspeed;
>>         mmc-ddr-1_8v;
>>         mmc-hs400-1_8v;
> 
> This is not the setup in the upstream dts.
> 
>>From what I see here, this emmc is using dual data rate modes.
> So the most impacting change would be :
> 
> mmc: meson-gx: fix dual data rate mode frequencies
> 
> Before this patch the output frequency was actually half what was reported, so
> in this case, I suspect you were only running at 100MHz before. At this
> frequency, tuning on the emmc is a lot easier to achieve, if even necessary.
> 
> I have tested a fair amount of mmc configuration but I don't have setup with
> HS400, but I think the following issue may rise:
> 
> * Generating 200MHz DDR output out of fdiv2 is not possible: this would require
> 400Mhz input which cannot be done from 1GHz and a simple divider. You can either
> get 500Mhz (250Mhz out) or 250MHz (125MHz out)
> 
> * In HS400, If I remember correctly, tuning is done in HS200, then switch to
> HS400 (bumping the input clock) May it require different phase setting ?
> 
> * Running 200MHz on the PCB is very demanding. I have seen that when trying
> SDR104. Amplitude and signal quality drops significantly between 100MHz and
> 200Mhz. Are you sure the lines (including PCB, connectors, etc) are able to cope
> with this and provide a good enough signal to the eMMC chip ?
> 
> Bottom line is that this eMMC never really run HS400, at least not at the speed
> you thought it did. To get the rate you had previously, simply change this:
> 
>         max-frequency = <100000000>;
> 
> 
> 
Thanks a lot for the comprehensive explanation.
However switching to HS400/100MHz or HS200/200MHz doesn't fix it for me.
I have to go back to HS200/100MHz to get a stable system again.
So most likely it's not only about patch "fix dual data rate mode frequencies".

My combination of Odroid C2 and the 128GB eMMC card may be a little exotic
as the card was twice the price of the board. I merely bought it to experiment
with the (I think) most performant combination.

>>
>>         mmc-pwrseq = <&emmc_pwrseq>;
>>         vmmc-supply = <&vcc3v3>;
>>         vqmmc-supply = <&vcc1v8>;
>> };
>>
>> Kind regards,
>> Heiner
>>
>>
>> [    0.784729] mmcblk0: mmc0:0001 DJNB4R 116 GiB
>> [    0.790226] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB
>> [    0.794860] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB
>> [    0.800723] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB
>> [    0.807012]  mmcblk0: p1
>> [    0.815910] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    0.818973] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    0.826699] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    0.836784] mmcblk0: error -110 sending stop command
>> [    0.916784] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    0.920069] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    0.930234] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    0.933718] print_req_error: I/O error, dev mmcblk0, sector 2048
>> [    0.939669] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync
>> page write
>> [    0.949190] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode.
>> Opts: (null)
>> [    0.955397] VFS: Mounted root (ext4 filesystem) on device 179:1.
>> [    0.963359] devtmpfs: mounted
>> [    0.964411] Freeing unused kernel memory: 320K
>> [    0.983379] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>> card status 0x900
>> [    0.989571] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0x900
>> [    1.093957] systemd[1]: System time before build time, advancing clock.
>> [    1.159148] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>> card status 0x900
>> [    1.193201] NET: Registered protocol family 10
>> [    1.193750] Segment Routing with IPv6
>> [    1.205032] systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT
>> -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
>> +LIBCRYP                                                                      
>>                                                                       TSETUP
>> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN
>> default-hierarchy=hybrid)
>> [    1.220390] systemd[1]: Detected architecture arm64.
>> [    1.244200] systemd[1]: Set hostname to <odroidc2>.
>> [    1.370901] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>> card status 0x900
>> [    1.378114] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>> card status 0x900
>> [    1.397501] systemd[1]: Created slice User and Session Slice.
>> [    1.415651] systemd[1]: Reached target Remote File Systems.
>> [    1.432905] systemd[1]: Created slice System Slice.
>> [    1.451645] systemd[1]: Reached target Slices.
>> [    1.468022] systemd[1]: Created slice system-serial\x2dgetty.slice.
>> [    1.483793] systemd[1]: Listening on udev Control Socket.
>> [    1.502607] systemd[1]: Mounting Kernel Debug File System...
>> [    1.830855] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered,discard
>> [    2.077375] systemd-journald[644]: Received request to flush runtime
>> journal from PID 1
>> [    2.085030] systemd-journald[644]: File
>> /var/log/journal/5d03187c26854bbe9eab8ea99e9291cb/system.journal corrupted or
>> uncleanly                                                                     
>>                                                                         shut
>> down, renaming and replacing.
>> [    2.096502] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.102475] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.110107] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.117608] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.125121] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.132627] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.140032] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.147511] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.155040] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.161860] print_req_error: I/O error, dev mmcblk0, sector 76224512
>> [    2.168147] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:322: I/O error
>> 10 writing to inode 2359327 (offset 0 size 4096
>> star                                                                          
>>                                                                   ting block
>> 9528065)
>> [    2.181256] Buffer I/O error on device mmcblk0p1, logical block 9527808
>> [    2.190050] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.196320] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.203573] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.211149] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.218616] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.226114] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.233593] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.241013] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.248513] mmcblk0: response CRC error sending r/w cmd command, card
>> status 0xd00
>> [    2.255350] print_req_error: I/O error, dev mmcblk0, sector 121899008
>>
> 
> 

Re: Problems after recent changes to meson-gx-mmc driver

[Heiner Kallweit]

Am 09.09.2017 um 21:53 schrieb Heiner Kallweit:
> Am 09.09.2017 um 16:05 schrieb Jerome Brunet:
>> On Sat, 2017-09-09 at 15:14 +0200, Heiner Kallweit wrote:
>>> Hi Jerome,
>>>
>>> the recent changes, most likely one of the changes affecting the clock phase
>>> setting
>>> or tuning, break mmc on my system (Odroid C2 + Hardkernel 128GB eMMC card).
>>> "Next" kernel from Aug 25th works fine here. Hadn't time yet to bisect the
>>> issue.
>>>
>>> As additional info, that's what the eMMC DT config looks like here.
>>> The issue remains when switching to HS200.
>>>
>>> /* eMMC */
>>> &sd_emmc_c {
>>>         status = "okay";
>>>         pinctrl-0 = <&emmc_pins>;
>>>         pinctrl-names = "default";
>>>
>>>         bus-width = <8>;
>>>         cap-sd-highspeed;
>>>         max-frequency = <200000000>;
>>>         non-removable;
>>>         disable-wp;
>>>         cap-mmc-highspeed;
>>>         mmc-ddr-1_8v;
>>>         mmc-hs400-1_8v;
>>
>> This is not the setup in the upstream dts.
>>
>> >From what I see here, this emmc is using dual data rate modes.
>> So the most impacting change would be :
>>
>> mmc: meson-gx: fix dual data rate mode frequencies
>>
>> Before this patch the output frequency was actually half what was reported, so
>> in this case, I suspect you were only running at 100MHz before. At this
>> frequency, tuning on the emmc is a lot easier to achieve, if even necessary.
>>
>> I have tested a fair amount of mmc configuration but I don't have setup with
>> HS400, but I think the following issue may rise:
>>
>> * Generating 200MHz DDR output out of fdiv2 is not possible: this would require
>> 400Mhz input which cannot be done from 1GHz and a simple divider. You can either
>> get 500Mhz (250Mhz out) or 250MHz (125MHz out)
>>
>> * In HS400, If I remember correctly, tuning is done in HS200, then switch to
>> HS400 (bumping the input clock) May it require different phase setting ?
>>
>> * Running 200MHz on the PCB is very demanding. I have seen that when trying
>> SDR104. Amplitude and signal quality drops significantly between 100MHz and
>> 200Mhz. Are you sure the lines (including PCB, connectors, etc) are able to cope
>> with this and provide a good enough signal to the eMMC chip ?
>>
>> Bottom line is that this eMMC never really run HS400, at least not at the speed
>> you thought it did. To get the rate you had previously, simply change this:
>>
>>         max-frequency = <100000000>;
>>
>>
>>
> Thanks a lot for the comprehensive explanation.
> However switching to HS400/100MHz or HS200/200MHz doesn't fix it for me.
> I have to go back to HS200/100MHz to get a stable system again.
> So most likely it's not only about patch "fix dual data rate mode frequencies".
> 
I checked further and setting the tx clock phase back to 0 fixes the issue for me.
("mmc: meson-gx: change default tx phase" changes it from 0 to 270.)
But as you write 0 seems to break certain other systems.

> My combination of Odroid C2 and the 128GB eMMC card may be a little exotic
> as the card was twice the price of the board. I merely bought it to experiment
> with the (I think) most performant combination.
> 
>>>
>>>         mmc-pwrseq = <&emmc_pwrseq>;
>>>         vmmc-supply = <&vcc3v3>;
>>>         vqmmc-supply = <&vcc1v8>;
>>> };
>>>
>>> Kind regards,
>>> Heiner
>>>
>>>
>>> [    0.784729] mmcblk0: mmc0:0001 DJNB4R 116 GiB
>>> [    0.790226] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB
>>> [    0.794860] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB
>>> [    0.800723] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB
>>> [    0.807012]  mmcblk0: p1
>>> [    0.815910] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    0.818973] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    0.826699] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    0.836784] mmcblk0: error -110 sending stop command
>>> [    0.916784] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    0.920069] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    0.930234] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    0.933718] print_req_error: I/O error, dev mmcblk0, sector 2048
>>> [    0.939669] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync
>>> page write
>>> [    0.949190] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode.
>>> Opts: (null)
>>> [    0.955397] VFS: Mounted root (ext4 filesystem) on device 179:1.
>>> [    0.963359] devtmpfs: mounted
>>> [    0.964411] Freeing unused kernel memory: 320K
>>> [    0.983379] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>>> card status 0x900
>>> [    0.989571] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0x900
>>> [    1.093957] systemd[1]: System time before build time, advancing clock.
>>> [    1.159148] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>>> card status 0x900
>>> [    1.193201] NET: Registered protocol family 10
>>> [    1.193750] Segment Routing with IPv6
>>> [    1.205032] systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT
>>> -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
>>> +LIBCRYP                                                                      
>>>                                                                       TSETUP
>>> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN
>>> default-hierarchy=hybrid)
>>> [    1.220390] systemd[1]: Detected architecture arm64.
>>> [    1.244200] systemd[1]: Set hostname to <odroidc2>.
>>> [    1.370901] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>>> card status 0x900
>>> [    1.378114] mmcblk0: response CRC error sending SET_BLOCK_COUNT command,
>>> card status 0x900
>>> [    1.397501] systemd[1]: Created slice User and Session Slice.
>>> [    1.415651] systemd[1]: Reached target Remote File Systems.
>>> [    1.432905] systemd[1]: Created slice System Slice.
>>> [    1.451645] systemd[1]: Reached target Slices.
>>> [    1.468022] systemd[1]: Created slice system-serial\x2dgetty.slice.
>>> [    1.483793] systemd[1]: Listening on udev Control Socket.
>>> [    1.502607] systemd[1]: Mounting Kernel Debug File System...
>>> [    1.830855] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=ordered,discard
>>> [    2.077375] systemd-journald[644]: Received request to flush runtime
>>> journal from PID 1
>>> [    2.085030] systemd-journald[644]: File
>>> /var/log/journal/5d03187c26854bbe9eab8ea99e9291cb/system.journal corrupted or
>>> uncleanly                                                                     
>>>                                                                         shut
>>> down, renaming and replacing.
>>> [    2.096502] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.102475] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.110107] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.117608] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.125121] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.132627] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.140032] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.147511] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.155040] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.161860] print_req_error: I/O error, dev mmcblk0, sector 76224512
>>> [    2.168147] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:322: I/O error
>>> 10 writing to inode 2359327 (offset 0 size 4096
>>> star                                                                          
>>>                                                                   ting block
>>> 9528065)
>>> [    2.181256] Buffer I/O error on device mmcblk0p1, logical block 9527808
>>> [    2.190050] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.196320] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.203573] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.211149] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.218616] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.226114] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.233593] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.241013] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.248513] mmcblk0: response CRC error sending r/w cmd command, card
>>> status 0xd00
>>> [    2.255350] print_req_error: I/O error, dev mmcblk0, sector 121899008
>>>
>>
>>
> 

Re: Problems after recent changes to meson-gx-mmc driver

[Jerome Brunet]

On Sat, 2017-09-09 at 22:20 +0200, Heiner Kallweit wrote:
> I checked further and setting the tx clock phase back to 0 fixes the issue for
> me.
> ("mmc: meson-gx: change default tx phase" changes it from 0 to 270.)
> But as you write 0 seems to break certain other systems.

That was my second guess ...

As I mentioned in the commit message, 270 is working fine for the setups I have
tested but I always wondered if that would be the case for every possible
setups/boards/modes.

Would you mind testing 90 and 180 as well with your setup ? I'll make another
pass on the different setups I have access to. Please stick to hs200 and drop
hs400 for this test. I'm still unsure if doubling the clock after doing the
tuning may affect the phase tuning ... lets keep that out of the way for now.

Re: Problems after recent changes to meson-gx-mmc driver

[Heiner Kallweit]

Am 10.09.2017 um 17:08 schrieb Jerome Brunet:
> On Sat, 2017-09-09 at 22:20 +0200, Heiner Kallweit wrote:
>> I checked further and setting the tx clock phase back to 0 fixes the issue for
>> me.
>> ("mmc: meson-gx: change default tx phase" changes it from 0 to 270.)
>> But as you write 0 seems to break certain other systems.
> 
> That was my second guess ...
> 
> As I mentioned in the commit message, 270 is working fine for the setups I have
> tested but I always wondered if that would be the case for every possible
> setups/boards/modes.
> 
> Would you mind testing 90 and 180 as well with your setup ? I'll make another
> pass on the different setups I have access to. Please stick to hs200 and drop
> hs400 for this test. I'm still unsure if doubling the clock after doing the
> tuning may affect the phase tuning ... lets keep that out of the way for now.
> 
I tested the other tx clock settings with HS200/200MHz.

0: No errors
90: 6 CRC errors, otherwise system works normal.
180: Lots of CRC errors, but system still works.
270: So many errors that root file system gets corrupted and is mounted r/o.

Seems like we won't find a tx clock phase working on all systems.
So maybe the tuning needs to be extended to check all tx / rx clock
phase combinations.

IIRC I went with a fixed tx clock phase because other combinations of
tx / rx clock phase selected by an experimental tuning algorithm
worked fine when tuning but produced errors later.

Re: Problems after recent changes to meson-gx-mmc driver

[Jerome Brunet]

On Sun, 2017-09-10 at 18:20 +0200, Heiner Kallweit wrote:
> Am 10.09.2017 um 17:08 schrieb Jerome Brunet:
> > On Sat, 2017-09-09 at 22:20 +0200, Heiner Kallweit wrote:
> > > I checked further and setting the tx clock phase back to 0 fixes the issue
> > > for
> > > me.
> > > ("mmc: meson-gx: change default tx phase" changes it from 0 to 270.)
> > > But as you write 0 seems to break certain other systems.
> > 
> > That was my second guess ...
> > 
> > As I mentioned in the commit message, 270 is working fine for the setups I
> > have
> > tested but I always wondered if that would be the case for every possible
> > setups/boards/modes.
> > 
> > Would you mind testing 90 and 180 as well with your setup ? I'll make
> > another
> > pass on the different setups I have access to. Please stick to hs200 and
> > drop
> > hs400 for this test. I'm still unsure if doubling the clock after doing the
> > tuning may affect the phase tuning ... lets keep that out of the way for
> > now.
> > 
> 
> I tested the other tx clock settings with HS200/200MHz.
> 
> 0: No errors
> 90: 6 CRC errors, otherwise system works normal.
> 180: Lots of CRC errors, but system still works.
> 270: So many errors that root file system gets corrupted and is mounted r/o.
> 
> Seems like we won't find a tx clock phase working on all systems.
> So maybe the tuning needs to be extended to check all tx / rx clock
> phase combinations.

Well, I kind of had this in mind when writing the new tuning function. Tuning
the Tx phase should be fairly simple, a call like:

meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk);

added in meson_mmc_execute_tuning() should do the trick.

That being said If you are getting file system errors then tuning must have
succeed first, even if the tx phase is not good for you.
Not sure if cycling on the Tx phase in the tuning function will help then.
It will select the center of the working window, so maybe ... It's worth trying

Another approach, if this difference is due to the PCB layout, line routing,
etc, maybe the Tx phase could be provided as a DT param ... maybe

> 
> IIRC I went with a fixed tx clock phase because other combinations of
> tx / rx clock phase selected by an experimental tuning algorithm
> worked fine when tuning but produced errors later.

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

[Jerome Brunet]

It has been reported that some platforms (odroid-c2) may require
a different tx phase setting to operate at high speed.

To improve the situation, this patch includes tx phase in the tuning
process.

Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---

Hi Heiner,

Would you mind trying this change with your setup and letting us know
if it helps ?

It seems like a good idea to add an initial Rx tuning before doing the
actual tuning but, honestly, I don't know if it is really necessary.

Regards

Jerome


 drivers/mmc/host/meson-gx-mmc.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index c885c2d4b904..0254d8bfd536 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -717,6 +717,22 @@ static int meson_mmc_clk_phase_tuning(struct mmc_host *mmc, u32 opcode,
 static int meson_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
 {
 	struct meson_host *host = mmc_priv(mmc);
+	int ret;
+
+	/*
+	 * If this is the initial tuning, try to get a sane Rx starting
+	 * phase before doing the actual tuning.
+	 */
+	if (!mmc->doing_retune) {
+		ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
+
+		if (ret)
+			return ret;
+	}
+
+	ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk);
+	if (ret)
+		return ret;
 
 	return meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
 }
-- 
2.13.5

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

[Heiner Kallweit]

Am 18.09.2017 um 15:44 schrieb Jerome Brunet:
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index c885c2d4b904..0254d8bfd536 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -717,6 +717,22 @@ static int meson_mmc_clk_phase_tuning(struct mmc_host *mmc, u32 opcode,
>  static int meson_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
>  {
>  	struct meson_host *host = mmc_priv(mmc);
> +	int ret;
> +
> +	/*
> +	 * If this is the initial tuning, try to get a sane Rx starting
> +	 * phase before doing the actual tuning.
> +	 */
> +	if (!mmc->doing_retune) {
> +		ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
> +
> +		if (ret)
> +			return ret;
> +	}
> +
> +	ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk);
> +	if (ret)
> +		return ret;
>  
>  	return meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
>  }
> -- 2.13.5
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.

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

[Jerome Brunet]

On Mon, 2017-09-18 at 21:11 +0200, Heiner Kallweit wrote:
> Am 18.09.2017 um 15:44 schrieb Jerome Brunet:
> > diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-
> > mmc.c
> > index c885c2d4b904..0254d8bfd536 100644
> > --- a/drivers/mmc/host/meson-gx-mmc.c
> > +++ b/drivers/mmc/host/meson-gx-mmc.c
> > @@ -717,6 +717,22 @@ static int meson_mmc_clk_phase_tuning(struct mmc_host
> > *mmc, u32 opcode,
> >  static int meson_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
> >  {
> >  	struct meson_host *host = mmc_priv(mmc);
> > +	int ret;
> > +
> > +	/*
> > +	 * If this is the initial tuning, try to get a sane Rx starting
> > +	 * phase before doing the actual tuning.
> > +	 */
> > +	if (!mmc->doing_retune) {
> > +		ret = meson_mmc_clk_phase_tuning(mmc, opcode, host-
> > >rx_clk);
> > +
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk);
> > +	if (ret)
> > +		return ret;
> >  
> >  	return meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
> >  }
> > -- 2.13.5
> 
> 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

What makes you think that tx and rx phase depends on one another ?
I have done a lot of tests on all the phase different settings while working on
this series and could see that:

1) For a fixed Tx and Core phase, Rx phase tuning tends to give a constant
result
2) For a fixed Tx, Rx phase tuning tends to rotate with the core phase
3) For a fixed Core phase, Rx phase tuning tends to remain constant for any
values of Tx phase

>From what I understand of the HW, this would make sense:
* Tx phase would be the phase at which the data are sent compared to the core
clock
* Rx phase would be the phase at which the data are sampled compared to the core
clock

This would make me conclude that both Tx and Rx phases depends on the core phase
but are independent of one another. Of course, if you have evidence showing
otherwise, I'm happy to reconsider.
ATM, I don't see the added value of testing all the combination.

Another thing to consider is that, with the current driver, we set the Tx and Rx
with a precision of 30 degrees -> 12 possible phase settings.

* 2 sequential tuning => 24 test
* all combination of 2 phases => 144 test

Also, remember that this tuning is as much based on the working tuning point as
it is on the failing ones. I looks for the center of the tuning window, so
failing tests are very valuable. Looking for all the combination, you would have
you look for this "center" in 2D ... not impossible, but complex and annoying. 
  

> 

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

[Heiner Kallweit]

Am 19.09.2017 um 13:08 schrieb Jerome Brunet:
> On Mon, 2017-09-18 at 21:11 +0200, Heiner Kallweit wrote:
>> Am 18.09.2017 um 15:44 schrieb Jerome Brunet:
>>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-
>>> mmc.c
>>> index c885c2d4b904..0254d8bfd536 100644
>>> --- a/drivers/mmc/host/meson-gx-mmc.c
>>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>>> @@ -717,6 +717,22 @@ static int meson_mmc_clk_phase_tuning(struct mmc_host
>>> *mmc, u32 opcode,
>>>  static int meson_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
>>>  {
>>>  	struct meson_host *host = mmc_priv(mmc);
>>> +	int ret;
>>> +
>>> +	/*
>>> +	 * If this is the initial tuning, try to get a sane Rx starting
>>> +	 * phase before doing the actual tuning.
>>> +	 */
>>> +	if (!mmc->doing_retune) {
>>> +		ret = meson_mmc_clk_phase_tuning(mmc, opcode, host-
>>>> rx_clk);
>>> +
>>> +		if (ret)
>>> +			return ret;
>>> +	}
>>> +
>>> +	ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk);
>>> +	if (ret)
>>> +		return ret;
>>>  
>>>  	return meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
>>>  }
>>> -- 2.13.5
>>
>> 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.

> What makes you think that tx and rx phase depends on one another ?
> I have done a lot of tests on all the phase different settings while working on
> this series and could see that:
> 
> 1) For a fixed Tx and Core phase, Rx phase tuning tends to give a constant
> result
> 2) For a fixed Tx, Rx phase tuning tends to rotate with the core phase
> 3) For a fixed Core phase, Rx phase tuning tends to remain constant for any
> values of Tx phase
> 
>>From what I understand of the HW, this would make sense:
> * Tx phase would be the phase at which the data are sent compared to the core
> clock
> * Rx phase would be the phase at which the data are sampled compared to the core
> clock
> 
> This would make me conclude that both Tx and Rx phases depends on the core phase
> but are independent of one another. Of course, if you have evidence showing
> otherwise, I'm happy to reconsider.
> ATM, I don't see the added value of testing all the combination.
> 
> Another thing to consider is that, with the current driver, we set the Tx and Rx
> with a precision of 30 degrees -> 12 possible phase settings.
> 
> * 2 sequential tuning => 24 test
> * all combination of 2 phases => 144 test
> 
> Also, remember that this tuning is as much based on the working tuning point as
> it is on the failing ones. I looks for the center of the tuning window, so
> failing tests are very valuable. Looking for all the combination, you would have
> you look for this "center" in 2D ... not impossible, but complex and annoying. 
>   
> 
>>
> 
> 

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

[Jerome Brunet]

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 ...

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

[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@baylibre.com

Jerome.