Re: eMMC tuning issue on Odroid C2 and a possible solution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2017-10-12 at 22:29 +0200, Heiner Kallweit wrote:
> Am 12.10.2017 um 22:05 schrieb Jerome Brunet:
> > On Thu, 2017-10-12 at 21:49 +0200, Heiner Kallweit wrote:
> > > > The result of the tuning does not depends on starting point, so I don't
> > > > really
> > > > understand how it would significantly change things.
> > > > 
> > > 
> > > I think it depends on the tx phase starting point.
> > > 
> > 
> > If the result of the tuning is not independent of the starting, instead of
> > just
> > telling me, it is fairly easy for you to give actual result, like I asked
> > you:
> > 
> 
> With hs200@200 and tx phase starting point 0 I get the following with no
> further CRC errors.
> 
> [    0.726572] meson-gx-mmc d0074000.mmc: d0074000.mmc#rx phase/delay
> tunning...
> [    0.728664] hctosys: unable to open rtc device (rtc0)
> [    0.728827] USB_OTG_PWR: disabling
> [    0.728831] TFLASH_VDD: disabling
> [    0.728833] TF_IO: disabling
> [    0.753183] Waiting for root device /dev/mmcblk0p1...
> [    0.754352] meson-gx-mmc d0074000.mmc: success with phase: 270
> [    0.758386] meson-gx-mmc d0074000.mmc: d0074000.mmc#tx phase/delay
> tunning...
> [    0.768050] meson-gx-mmc d0074000.mmc: success with phase: 120
> [    0.771235] meson-gx-mmc d0074000.mmc: d0074000.mmc#rx phase/delay
> tunning...
> [    0.780902] meson-gx-mmc d0074000.mmc: success with phase: 0
> [    0.784036] mmc0: new HS200 MMC card at address 0001
> [    0.789090] mmcblk0: mmc0:0001 DJNB4R 116 GiB
> [    0.793328] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB
> [    0.799198] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB
> [    0.805048] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB, chardev
> (249:0)
> [    0.812799] mmcblk0: response CRC error sending r/w cmd command, card
> status 0x900
> [    0.819727] meson-gx-mmc d0074000.mmc: d0074000.mmc#tx phase/delay
> tunning...
> [    0.827007] meson-gx-mmc d0074000.mmc: success with phase: 210
> [    0.832559] meson-gx-mmc d0074000.mmc: d0074000.mmc#rx phase/delay
> tunning...
> [    0.839848] meson-gx-mmc d0074000.mmc: success with phase: 0
> 
> 
> > > > Ok, starting from Rx:0 Tx:270 then tuning gives you Tx:300 Rx:90
> > > > And what different did it gives you starting Rx:0/Tx:0 ?
> > 
> > And if the result are indeed vastly different, let's debug and get a real
> > explanation.
> > 
> > > Tuning does:
> > > rx phase tuning
> > > tx phase tuning
> > > rx phase tuning
> > > 
> > > Result of each step depends on result of previous step.
> > 
> > Again, we don't agree. 
> > 
> > > So also the initial
> > > rx phase tuning result depends on the starting point of tx phase.
> > 
> > The first Rx tuning is there only to get a sane starting point for the tx
> > tuning
> > ,as explained in the code. This is the reason why is not done when re-
> > tuning.
> > 

Heiner, This is the same story again and again !
Getting clear status is just really painful. It's like half the message is
ignored each time. 

I can clearly see that, this result comes from your hack, and this hack makes no
sense. I don't care about this result. This is not what I asked.

What I asked is:
1) From linux-next what is tuning result in hs200@200Mhz with the starting :
* Rx:0/Tx:270/Core:180 (current setting)
* Rx:0/Tx:0/Core:180 (the setting you keep on mentioning)

Please don't send your logs: the phase set are displayed in
debugfs/clk?clk_summary

2) Try to come up with a real explanation: "It just happens ..." is not an
explanation. 

> > 
> > 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux