All of lore.kernel.org
 help / color / mirror / Atom feed
From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: eMMC tuning issue on Odroid C2 and a possible solution
Date: Thu, 12 Oct 2017 22:59:12 +0200	[thread overview]
Message-ID: <1507841952.16356.285.camel@baylibre.com> (raw)
In-Reply-To: <08c2642a-06b2-f36b-80b1-3be82c346887@gmail.com>

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

> > 
> > 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	Kevin Hilman <khilman@baylibre.com>
Subject: Re: eMMC tuning issue on Odroid C2 and a possible solution
Date: Thu, 12 Oct 2017 22:59:12 +0200	[thread overview]
Message-ID: <1507841952.16356.285.camel@baylibre.com> (raw)
In-Reply-To: <08c2642a-06b2-f36b-80b1-3be82c346887@gmail.com>

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. 

> > 
> > 
> 
> 


  reply	other threads:[~2017-10-12 20:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11 20:46 eMMC tuning issue on Odroid C2 and a possible solution Heiner Kallweit
2017-10-11 20:46 ` Heiner Kallweit
2017-10-12 15:22 ` Jerome Brunet
2017-10-12 15:22   ` Jerome Brunet
2017-10-12 18:17   ` Heiner Kallweit
2017-10-12 18:17     ` Heiner Kallweit
2017-10-12 19:34     ` Jerome Brunet
2017-10-12 19:34       ` Jerome Brunet
2017-10-12 19:49       ` Heiner Kallweit
2017-10-12 19:49         ` Heiner Kallweit
2017-10-12 20:05         ` Jerome Brunet
2017-10-12 20:05           ` Jerome Brunet
2017-10-12 20:29           ` Heiner Kallweit
2017-10-12 20:29             ` Heiner Kallweit
2017-10-12 20:59             ` Jerome Brunet [this message]
2017-10-12 20:59               ` Jerome Brunet
2017-10-12 21:04               ` Heiner Kallweit
2017-10-12 21:04                 ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1507841952.16356.285.camel@baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=linus-amlogic@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.