Dear Seungwon
On 01/13/2014 01:32 PM, Seungwon Jeon wrote:
>>>>>> +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];
>>>>>
>>
>> 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
--
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
