On Mon, January 13, 2014, Zhangfei Gao wrote:
> 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 :)
Oh, I just want to remove dependency as I mentioned.
>
> 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.
I guess specific clock handling(clk-hi3620.c) can adjust required source clock rate.
>
> Will update accordingly, thanks for the suggestion.
Thank you for consideration.
Thanks,
Seungwon Jeon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
