On Mon, December 16, 2013, Zhangfei Gao wrote: > On 12/16/2013 03:29 PM, Seungwon Jeon wrote: > > On Mon, December 16, 2013, Zhangfei Gao wrote: > >> Dear Seungwon > >> > >> On 12/16/2013 11:50 AM, Seungwon Jeon wrote: > >>> On Sat, December 14, 2013, Zhangfei Gao wrote: > >> > >>>> + /* SoC portion */ > >>>> + dwmmc_0: dwmmc0@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' > > 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. > > > 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)? Thanks, Seungwon Jeon > > > > >> > >>>> +static int dw_mci_k3_suspend(struct device *dev) > >>>> +{ > >>>> + struct dw_mci *host = dev_get_drvdata(dev); > >>>> + > >>>> + if (!IS_ERR(host->ciu_clk)) > >>>> + clk_disable_unprepare(host->ciu_clk); > >>>> + > >>>> + return dw_mci_suspend(host); > >>> If k3 needs clk_disable here, dw_mci_suspend()is expected to be called prior to > >> clk_disable_unprepare()? > >>> Of course, it's ok at present though. > >>> > >> > >> Sure, it can be switched, though dw_mci_suspend does nothing related > >> with clock now. > > Yes, but if some works with ciu_clk is added in dw_mci_suspend(), it will affect. > > > Sorry for the misunderstood, I mean it make sense and will change. > Thanks the advice. > > > -- > 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 -- 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