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

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

 



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

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