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. Phase 2: - convert MMC driver to use new mmc-clk provider - update MMC users in DT and bindings Kevin -- 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
