[U-Boot] [RESEND PATCH v3 1/2] mmc: rockchip_sdhci: add clock init for mmc

[Jaehoon Chung]

Hi

On 12/29/2016 09:53 AM, Kever Yang wrote:
> Hi Stefan,
> 
>     Thanks for your review comment.
> On 12/29/2016 02:35 AM, Stefan Herbrechtsmeier wrote:
>> Hi,
>>
>> Am 28.12.2016 um 12:01 schrieb Jaehoon Chung:
>>> On 12/28/2016 12:32 PM, Kever Yang wrote:
>>>> Init the clock rate to max-frequency from dts with clock driver api.
>>>>
>>>> Signed-off-by: Kever Yang <kever.yang at rock-chips.com>
>>> Reviewed-by: Jaehoon Chung <jh80.chung at samsung.com>
>> This is an incorrect use of the max-frequency property.
>>
>> The max-frequency value limit the output clock of the mmc interface and depends on the controller, circuit (level shifter), board and so on. It doesn't represents the clock frequency of the controller.
>>
>> The clock setup inside the clock framework should use the assigned-clock-rates property. The mmc driver should only enable the clock and pass the clock rate together with the max-frequency to the mmc framework.
> 
> I'm not good at mmc controller and driver framework, but seems that the sdhci core treats the max-frequency as the clock input from clock module, right?
> What if the mmc controller max-frequency is not equal to the clock module output which is possible? Does kernel deal with this, and how.

If my understanding is right, some controller should be broken the CLOCK_BASE capability. (Refer to Linux kernel)
And then they needs to get value from CMU.

host->max_clk should be used the card's maximum value.

In Linux Kernel's case
if max_frequency property is defined, assigned to mmc->f_max
and host->f_max is assigned to clk_get_rate() value. (If Broken clock_base capability)
And check "mmc->f_max > host->f_max" or "mmc->f_max == 0"
	if true
	then mmc->_f_max = f_max;
	else
	then mmc->f_max is used to "max_frequency" value.

In Conclusion,
	host's maximum value is used. ("max_frequency" property is used to QUIRK_BROKEN_CAP_CLOCK_BASE in Linux kernel.)

Kever's patch is not problem.

Best Regards,
Jaehoon Chung

> 
> Thanks,
> - Kever
>>
>> Regards,
>>   Stefan
>>
>>
>>
>>
> 
> 
> 
> 
>