[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <405ff057-a14e-f9eb-19e0-8d467dda35a1@amlogic.com>
Date: Mon, 23 Jul 2018 22:28:36 +0800
From: Yixun Lan <yixun.lan@...ogic.com>
To: Kevin Hilman <khilman@...libre.com>
CC: <yixun.lan@...ogic.com>, 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@...r.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
HI Kevin
On 07/23/2018 10:12 PM, Kevin Hilman wrote:
> 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.
>
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
Powered by blists - more mailing lists