* Problems after recent changes to meson-gx-mmc driver
@ 2017-09-09 13:14 ` Heiner Kallweit
0 siblings, 0 replies; 26+ messages in thread
From: Heiner Kallweit @ 2017-09-09 13:14 UTC (permalink / raw)
To: linus-amlogic
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
^ permalink raw reply [flat|nested] 26+ messages in thread* Problems after recent changes to meson-gx-mmc driver @ 2017-09-09 13:14 ` Heiner Kallweit 0 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-09 13:14 UTC (permalink / raw) To: Jerome Brunet Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Problems after recent changes to meson-gx-mmc driver 2017-09-09 13:14 ` Heiner Kallweit @ 2017-09-09 14:05 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-09 14:05 UTC (permalink / raw) To: linus-amlogic 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Problems after recent changes to meson-gx-mmc driver @ 2017-09-09 14:05 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-09 14:05 UTC (permalink / raw) To: Heiner Kallweit Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Problems after recent changes to meson-gx-mmc driver 2017-09-09 14:05 ` Jerome Brunet @ 2017-09-09 19:53 ` Heiner Kallweit -1 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-09 19:53 UTC (permalink / raw) To: linus-amlogic 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 >> > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Problems after recent changes to meson-gx-mmc driver @ 2017-09-09 19:53 ` Heiner Kallweit 0 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-09 19:53 UTC (permalink / raw) To: Jerome Brunet Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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 >> > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Problems after recent changes to meson-gx-mmc driver 2017-09-09 19:53 ` Heiner Kallweit @ 2017-09-09 20:20 ` Heiner Kallweit -1 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-09 20:20 UTC (permalink / raw) To: linus-amlogic 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 >>> >> >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Problems after recent changes to meson-gx-mmc driver @ 2017-09-09 20:20 ` Heiner Kallweit 0 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-09 20:20 UTC (permalink / raw) To: Jerome Brunet Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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 >>> >> >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Problems after recent changes to meson-gx-mmc driver 2017-09-09 20:20 ` Heiner Kallweit @ 2017-09-10 15:08 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-10 15:08 UTC (permalink / raw) To: linus-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Problems after recent changes to meson-gx-mmc driver @ 2017-09-10 15:08 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-10 15:08 UTC (permalink / raw) To: Heiner Kallweit Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Problems after recent changes to meson-gx-mmc driver 2017-09-10 15:08 ` Jerome Brunet @ 2017-09-10 16:20 ` Heiner Kallweit -1 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-10 16:20 UTC (permalink / raw) To: linus-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Problems after recent changes to meson-gx-mmc driver @ 2017-09-10 16:20 ` Heiner Kallweit 0 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-10 16:20 UTC (permalink / raw) To: Jerome Brunet Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Problems after recent changes to meson-gx-mmc driver 2017-09-10 16:20 ` Heiner Kallweit @ 2017-09-10 16:48 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-10 16:48 UTC (permalink / raw) To: linus-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Problems after recent changes to meson-gx-mmc driver @ 2017-09-10 16:48 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-10 16:48 UTC (permalink / raw) To: Heiner Kallweit Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org, linux-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process 2017-09-10 16:20 ` Heiner Kallweit @ 2017-09-18 13:44 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-18 13:44 UTC (permalink / raw) To: linus-amlogic 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 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process @ 2017-09-18 13:44 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-18 13:44 UTC (permalink / raw) To: Ulf Hansson, Kevin Hilman, Heiner Kallweit Cc: Jerome Brunet, Carlo Caione, linux-mmc, linux-amlogic 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 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process 2017-09-18 13:44 ` Jerome Brunet @ 2017-09-18 19:11 ` Heiner Kallweit -1 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-18 19:11 UTC (permalink / raw) To: linus-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process @ 2017-09-18 19:11 ` Heiner Kallweit 0 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-18 19:11 UTC (permalink / raw) To: Jerome Brunet, Ulf Hansson, Kevin Hilman Cc: Carlo Caione, linux-mmc, linux-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process 2017-09-18 19:11 ` Heiner Kallweit @ 2017-09-19 11:08 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-19 11:08 UTC (permalink / raw) To: linus-amlogic 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. > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process @ 2017-09-19 11:08 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-19 11:08 UTC (permalink / raw) To: Heiner Kallweit, Ulf Hansson, Kevin Hilman Cc: Carlo Caione, linux-mmc, linux-amlogic 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. > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process 2017-09-19 11:08 ` Jerome Brunet @ 2017-09-19 18:54 ` Heiner Kallweit -1 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-19 18:54 UTC (permalink / raw) To: linus-amlogic 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. > > >> > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process @ 2017-09-19 18:54 ` Heiner Kallweit 0 siblings, 0 replies; 26+ messages in thread From: Heiner Kallweit @ 2017-09-19 18:54 UTC (permalink / raw) To: Jerome Brunet, Ulf Hansson, Kevin Hilman Cc: Carlo Caione, linux-mmc, linux-amlogic 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. > > >> > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process 2017-09-19 18:54 ` Heiner Kallweit @ 2017-09-27 16:24 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-27 16:24 UTC (permalink / raw) To: linus-amlogic 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 ... ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process @ 2017-09-27 16:24 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-09-27 16:24 UTC (permalink / raw) To: Heiner Kallweit, Ulf Hansson, Kevin Hilman Cc: Carlo Caione, linux-mmc, linux-amlogic 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 ... ^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process 2017-09-27 16:24 ` Jerome Brunet @ 2017-10-02 12:30 ` Jerome Brunet -1 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-10-02 12:30 UTC (permalink / raw) To: linus-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process @ 2017-10-02 12:30 ` Jerome Brunet 0 siblings, 0 replies; 26+ messages in thread From: Jerome Brunet @ 2017-10-02 12:30 UTC (permalink / raw) To: Heiner Kallweit, Ulf Hansson, Kevin Hilman Cc: Carlo Caione, linux-mmc, linux-amlogic 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2017-10-02 12:30 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-09-09 13:14 Problems after recent changes to meson-gx-mmc driver Heiner Kallweit 2017-09-09 13:14 ` Heiner Kallweit 2017-09-09 14:05 ` Jerome Brunet 2017-09-09 14:05 ` Jerome Brunet 2017-09-09 19:53 ` Heiner Kallweit 2017-09-09 19:53 ` Heiner Kallweit 2017-09-09 20:20 ` Heiner Kallweit 2017-09-09 20:20 ` Heiner Kallweit 2017-09-10 15:08 ` Jerome Brunet 2017-09-10 15:08 ` Jerome Brunet 2017-09-10 16:20 ` Heiner Kallweit 2017-09-10 16:20 ` Heiner Kallweit 2017-09-10 16:48 ` Jerome Brunet 2017-09-10 16:48 ` Jerome Brunet 2017-09-18 13:44 ` [PATCH/RFT] mmc: meson-gx: include tx phase in the tuning process Jerome Brunet 2017-09-18 13:44 ` Jerome Brunet 2017-09-18 19:11 ` Heiner Kallweit 2017-09-18 19:11 ` Heiner Kallweit 2017-09-19 11:08 ` Jerome Brunet 2017-09-19 11:08 ` Jerome Brunet 2017-09-19 18:54 ` Heiner Kallweit 2017-09-19 18:54 ` Heiner Kallweit 2017-09-27 16:24 ` Jerome Brunet 2017-09-27 16:24 ` Jerome Brunet 2017-10-02 12:30 ` Jerome Brunet 2017-10-02 12:30 ` Jerome Brunet
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.