Dear Seungwon

On 01/13/2014 01:32 PM, Seungwon Jeon wrote:

quoted

quoted

quoted

quoted

quoted

+static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+	struct dw_mci_k3_priv_data *priv = host->priv;
+	u32 rate = priv->clk_table[ios->timing];

quoted

The function mmc_clk_determine_rate() will need the info which
controller it is, what's the init clock rate, what's the max clock rate,
and what's the limitation, which may be different as different soc, and
can not be hardcoded.
The limitation may in HS200 and SDR104 mode.

The plan is only input init rate and max rate instead of the table,
while others directly use ios->clock, only if the the limitation resolved.

Handling mmc clock for hi3620 is in drivers/clk/hisilicon/clk-hi3620.c, right?
Currently only hi3620 has been introduced.
If hi3620's host has a limitation, clk-hi3620.c can handle clock range(init, max) for source clock enough.
I feel like clock table is redundant.
Ok. It's just my suggestion.  But I still point dependency of mode index number.
K3's clock table refers and depends mode definition value from include/linux/mmc/host.h
If new mode is added or modified, it should be considered and also may make complicated.

Looks like you dislike the clk_table very much :)

Double checked with the silicon guy, currently it is said the limitation
in HS200 and SDR104 can be replaced by the max_rate, so clk_table can be
replaced with ios->clock directly, though they have concern it is not so
convinent when removing clk_table in case limitation rate is not equal
to max_rate again in future.

Will update accordingly, thanks for the suggestion.

Thanks