On 12/16/2013 05:18 PM, Seungwon Jeon wrote:

On Mon, December 16, 2013, Zhangfei Gao wrote:

quoted

On 12/16/2013 03:29 PM, Seungwon Jeon wrote:

quoted

On Mon, December 16, 2013, Zhangfei Gao wrote:

quoted

Dear Seungwon

On 12/16/2013 11:50 AM, Seungwon Jeon wrote:

quoted

On Sat, December 14, 2013, Zhangfei Gao wrote:

quoted

quoted

+	/* SoC portion */
+	dwmmc_0: dwmmc0 at fcd03000 {
+		compatible = "hisilicon,hi4511-dw-mshc";
+		reg = <0xfcd03000 0x1000>;
+		interrupts = <0 16 4>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>;
+		clock-names = "ciu", "biu";
+		clock-freq-table =
+		<25000000 0 50000000 25000000 50000000 100000000 0 50000000>;

I think it could be solved with mmc->f_min and mmc->f_max(from clock-freq-min-max property)
if there is no limitation per each speed mode. As seeing described table, it looks that.

Have tried them before, but unfortunately, they are different.

The controller can not generate clock itself, while depending on the
outside clock generator, which may require to change clock source in
differnt mode.

The value we want is set the capacibility of the clock input and the max
clock freq where mmc works stable in that mode, which may be different
in different mode.

clock-freq-min-max will set the value for set_ios.
For example, we use 25M as clock capability when init, which can not be
set as freq-min, and used as set_ios, where 400K should be used,
otherwise init definitely fail.

Can you check 'f_init' within 'drivers/mmc/core/core.c' file?
If you set 'f_min = 25000000' for init-sequence, mmc_set_ios() will pass that rate through

'ios.clock'

quoted

Then, dw_mmc-k3 can do clk_set_rate() with 25MHz at dw_mci_k3_set_ios().

This means controller directly use 25M init emmc and sd card, it will fail.
We still need 400K init freq, while the input clock source is 25M,
divided by the controller.

quoted

And other required speeds for each mode seem not specific compared with standard spec.
Also clk_set_rate() would be possible with 'ios.clock' instead of specific table.
I just referred your example's clock-freq-table above.

There also some controller limitation currently.
In some mode, the controller only works well in the limited freq.
For example UHS_SDR104_MAX_DTR 208000000 can not be used, only half may
be reached, at least currently

Ok. I see your condition. I misunderstood a little bit.
I wonder whether limitation is only max frequency(SDR104 or HS200) except for init-freq.
How about other mode? Working is fine with normal clock rate(from clock-freq-table)?

The root cause is the controller can not generate stable clock itself,
but depends on outside clock source, which is varying, and driver need
to decide input clock rate / choose clock source according to the
working mode.

Three cases here:
1. Input rate for init are diferent for different controller, not the
init 400K, some are 13M, others are 25M, since different clock source.
This can be easily solved by clock-freq-init = <25000000>

2. There is maxmum limit, also can be easily solved by define CLK_MAX.
For example, CLK_MAX = 180M.

3. However some mode can not use the max speed from ios->clock
for example UHS_SDR104_MAX_DTR 208000000 can not be used, only half may
be reached, at least currently.

The third case is current limitation, after this limitation is solved,
we can switch to ios->clock directly.

Considering all these cases, we think using table is more suitable now.

Thanks