On Tue, 2018-07-03 at 17:56 +0800, Yixun Lan wrote: > > > Yes, It's true, the mux is parent of the div clock. > > > > > > while testing for the NAND driver, I find it's kind of loose about the > > > parent of the clock, so selecting the div (and let CCF decide freely) is > > > actually works fine > > > > > > but for the EMMC driver, especially when running at high clock, it's > > > kind of picky about the parent of the clock, > > > > It would be nice to get an explanation about this behavior. > > it seems that even of the rate provided by CLKID_SD_EMMC_X_CLK0 (main clock > > controller) is correct, the eMMC cannot reliably tune with it. > > > > Could you elaborate on this ? > > > > It's during my own test in AXG platform, I found clock path > a) fclk_div2 -> sd_emmc_c_clk0_sel -> sd_emmc_c_clk0_div -> > sd_emmc_c_clk0 -> sd_emmc_c_mux -> sd_emmc_c_div > > b) fclk_div2 -> sd_emmc_c_mux -> sd_emmc_c_div > > path a) doesn't work in EMMC driver, even both clock parent of them from > the same fclk_div2 source. > > sd_emmc_c_mux -> sd_emmc_c_div is the clock from the EMMC register base. > I believe it's ASIC design issue yes Yixun, I did the same test. What I meant with this question is: could you confirm there a problem with this clock, and what it is exactly so we can adjust the clock as necessary. If FDIV2 entry to this clock is broken, maybe it should be removed. -- 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
