[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7hbmay3ut6.fsf@baylibre.com>
Date: Mon, 23 Jul 2018 09:12:21 -0500
From: Kevin Hilman <khilman@...libre.com>
To: Yixun Lan <yixun.lan@...ogic.com>
Cc: Rob Herring <robh@...nel.org>,
Jerome Brunet <jbrunet@...libre.com>,
Neil Armstrong <narmstrong@...libre.com>,
Carlo Caione <carlo@...one.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Miquèl Raynal <miquel.raynal@...tlin.com>,
Boris Brezillon <boris.brezillon@...tlin.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Liang Yang <liang.yang@...ogic.com>,
Qiufang Dai <qiufang.dai@...ogic.com>,
Jian Hu <jian.hu@...ogic.com>,
linux-clk <linux-clk@...r.kernel.org>,
<linux-amlogic@...ts.infradead.org>,
"moderated list\:ARM\/FREESCALE IMX \/ MXC ARM ARCHITECTURE"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
<devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] clk: meson: add DT documentation for emmc clock controller
Yixun Lan <yixun.lan@...ogic.com> 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
Powered by blists - more mailing lists