HI Kevin On 07/23/2018 10:12 PM, Kevin Hilman wrote: > Yixun Lan <yixun.lan@xxxxxxxxxxx> writes: > > [...] > >>> >>>> Second, we might like to convert eMMC driver to also use mmc-clkc model. >>> >>> IMO, this should be done as part of merging this series. Otherwise, we >>> have duplicated code for the same thing. >> >> IMO, I'd leave this out of this series, since this patch series is quite >> complete as itself. Although, the downside is code duplication. >> >> Still, I need to hear Jerome, or Kevin's option, to see if or how we >> should proceed the eMMC's clock conversion. >> >> I could think of three option myself >> 1) don't do the conversion, downside is code duplication, upside is NO >> DT change, no compatibility issue >> 2) add a syscon node into eMMC DT node, then only convert clock part >> into this mmc-clkc model, while still leave other eMMC register access >> as the usual iomap way (still no race condition) >> 3) convert all eMMC register access by using regmap interface. >> >> both 2) and 3) need to update the DT. >> >> and probably 2) is a compromise way, and 1) is also OK, 3) is probably >> the worst way due to dramatically change (I think this was already >> rejected in the previous discussion) > > Because the devices (NAND and eMMC_C) are mutually exclusive, taking the > step-by-step approach is fine (and preferred) by me. > > Phase 1: > - add new mmc-clk provider > - add NAND driver using new mmc-clk provider > - boards using NAND should ensure emmc_c is disabled in DT > > This allows us to not touch the MMC driver or existing upstream > bindings. Yes, this means there is duplicate code in the MMC driver and > the new mmc-clk provider, but that can be removed in the next phase. > Great, the approach to address this issue is reasonable. We'd like to focus on phase 1 first, thanks > Phase 2: > - convert MMC driver to use new mmc-clk provider > - update MMC users in DT and bindings > Ok. Yixun -- 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
