linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jianxin Pan <jianxin.pan@amlogic.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>, <yixun.lan@amlogic.com>,
	<khilman@baylibre.com>, <carlo@caione.org>,
	<mturquette@baylibre.com>, <sboyd@kernel.org>, <robh@kernel.org>,
	<miquel.raynal@bootlin.com>, <boris.brezillon@bootlin.com>,
	<liang.yang@amlogic.com>, <jian.hu@amlogic.com>,
	<qiufang.dai@amlogic.com>, <hanjie.lin@amlogic.com>,
	<victor.wan@amlogic.com>, <linux-clk@vger.kernel.org>,
	<linux-amlogic@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
Date: Sun, 4 Nov 2018 02:01:32 +0800	[thread overview]
Message-ID: <66c2915a-4ecd-8a6e-6493-4318ae7bb620@amlogic.com> (raw)
In-Reply-To: <3723695d951e0d30e8a0117d336d8f268269a030.camel@baylibre.com>

Hi Jerome,

Thanks for the review, we really appreciate your time.

I'm very sorry maybe I don't catch all your meaning very well. 

Please see my comments below.

On 2018/10/29 3:16, Jerome Brunet wrote:
> On Thu, 2018-10-25 at 22:58 +0200, Martin Blumenstingl wrote:
>> Hi Jerome,
>>
>> On Thu, Oct 25, 2018 at 2:54 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>> [snip]
>>>>>> +static void clk_regmap_div_init(struct clk_hw *hw)
>>>>>> +{
>>>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>>>> + struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
>>>>>> + unsigned int val;
>>>>>> + int ret;
>>>>>> +
>>>>>> + ret = regmap_read(clk->map, div->offset, &val);
>>>>>> + if (ret)
>>>>>> +         return;
>>>>>>
>>>>>> + val &= (clk_div_mask(div->width) << div->shift);
>>>>>> + if (!val)
>>>>>> +         regmap_update_bits(clk->map, div->offset,
>>>>>> +                            clk_div_mask(div->width) << div->shift,
>>>>>> +                            clk_div_mask(div->width));
>>>>>
>>>>> This is wrong for several reasons:
>>>>> * You should hard code the initial value in the driver.
>>>>> * If shift is not 0, I doubt this will give the expected result.
>>>>
>>>> The value 0x00 of divider means nand clock off then read/write nand register is forbidden.
>>>
>>> That is not entirely true, you can access the clock register or you'd be in a
>>> chicken and egg situation.
>>>
>>>> Should we set the initial value in nand driver, or in sub emmc clk driver?
>>>
>>> In the nand driver, which is the consumer of the clock. see my previous comments
>>> about it.
>>
>> an old version of this series had the code still in the NAND driver
>> (by writing to the registers directly instead of using the clk API).
>> this looks pretty much like a "sclk-div" to me (as I commented in v3
>> of this series: [0]):
>> - value 0 means disabled
>> - positive divider values
>> - (probably no duty control, but that's optional as far as I
>> understand sclk-div)
>> - uses max divider value when enabling the clock
>>
>> if switching to sclk-div works then we can get rid of some duplicate code
> 
> It is possible:
> There is a couple of things to note though:
> 
> * sclk does not 'uses max divider value when enabling the clock': Since this
> divider can gate, it needs to save the divider value when disabling, since the
> divider value is no longer stored in the register,
> On init, this cached value is  saved as it is. If the divider is initially
> disabled, we have to set the cached value to something that makes sense, in case
> the clock is enabled without a prior call to clk_set_rate().
>> So in sclk, the clock setting is not changed nor hard coded in init, and this is
> a very important difference.
>
I think It's ok for the latest sub mmc clock and nand driver now:
1. in mmc_clkc_register_clk_with_parent("div", ...) from mmc_clkc_probe():
   cached_div is set to div_max durning clk register,but is not set to div hw register.

2. In meson nand driver v6: 	https://lore.kernel.org/lkml/1541090542-19618-3-git-send-email-jianxin.pan@amlogic.com
1) In meson_nfc_clk_init() from probe:   get clock handle, then prepare_enable and set default rate.
   nfc->device_clk = devm_clk_get(nfc->dev, "device");
   ret = clk_prepare_enable(nfc->device_clk);			//Here div hw register changed from 0 -> cached_div.
   default_clk_rate = clk_round_rate(nfc->device_clk, 24000000);
   ret = clk_set_rate(nfc->device_clk, default_clk_rate);	//Then register and cached_div are both updated to the default 24M.
2) In meson_nfc_select_chip(), set the actual frequency
  ret = clk_set_rate(nfc->device_clk, meson_chip->clk_rate);	//Here register and cached_div are changed again.
3) if clk_disable() is called, set div hw register to zero, and cached_div  keep unchagned.
   if clk_disable() is called again,  cached_div is restored to div hw register.

When enabling the clock, divider register does not need to be div_max.  
Any value is OK except ZERO, the cached_div from init or set_rate is ok
>  
> * Even if sclk zero value means gated, it is still a zero based divider, while
> eMMC/Nand divider is one based. It this controller was to sclk, then something
> needs to be done for this.
Could I add another patch to this patchset for sclk to support CLK_DIVIDER_ONE_BASED ?
> 
> * Since sclk caches a value in its data, and there can multiple instance of eMMC
> /NAND clock controller, some care must be taken when registering the data.
OK, I will fix it and alloc mmc_clkc_div_data danymicly durning probe.
Thank you. 
> 
> Both the generic divider and sclk could work here ... it's up to you Jianxin.
> 
== Why use meson_sclk_div_ops instead of clk_regmap_divider_ops?
The default divider hw register vaule is 0 when system power on.
Then there is a WARNING in divider_recalc_rate() durning clk_hw_register():
[    0.918238] ffe05000.clock-controller#div: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
[    0.925581] WARNING: CPU: 3 PID: 1 at drivers/clk/clk-divider.c:127 divider_recalc_rate+0x88/0x90
Then I still need to hard code the initual value to nand driver without CLK_DIVIDER_ALLOW_ZERO flags.
>>
>>
>> Regards
>> Martin
>>
>>
>> [0] https://patchwork.kernel.org/patch/10607157/#22238243
> 
> 
> .
> 



  parent reply	other threads:[~2018-11-03 18:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18  5:07 [PATCH v5 0/3] clk: meson: add a sub EMMC clock controller support Jianxin Pan
2018-10-18  5:07 ` [PATCH v5 1/3] clk: meson: add emmc sub clock phase delay driver Jianxin Pan
2018-10-18 17:14   ` Stephen Boyd
2018-10-24  8:58   ` Jerome Brunet
2018-10-24 10:57     ` Jianxin Pan
2018-10-18  5:07 ` [PATCH v5 2/3] clk: meson: add DT documentation for emmc clock controller Jianxin Pan
2018-10-18 17:08   ` Stephen Boyd
2018-10-19 15:50     ` Jianxin Pan
2018-10-19 18:04       ` Stephen Boyd
2018-10-22  6:05         ` Jianxin Pan
2018-10-24  8:58   ` Jerome Brunet
2018-10-25  7:29     ` Yixun Lan
2018-10-25 11:50       ` Jianxin Pan
2018-11-04  3:04       ` Stephen Boyd
2018-11-04 15:39         ` Jianxin Pan
2018-10-18  5:07 ` [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver Jianxin Pan
2018-10-18 17:13   ` Stephen Boyd
2018-10-19 16:12     ` Jianxin Pan
2018-10-19 18:03       ` Stephen Boyd
2018-10-22  5:59         ` Jianxin Pan
2018-10-24  9:00         ` Jerome Brunet
2018-10-24  6:29     ` Jianxin Pan
2018-10-24  8:47       ` Stephen Boyd
2018-10-24  8:51         ` Jianxin Pan
2018-10-24  9:01   ` Jerome Brunet
2018-10-25 11:48     ` Jianxin Pan
2018-10-25 12:54       ` Jerome Brunet
2018-10-25 20:58         ` Martin Blumenstingl
2018-10-28 19:16           ` Jerome Brunet
2018-10-29 19:45             ` Martin Blumenstingl
2018-10-30 13:41             ` Jianxin Pan
2018-11-03 18:01             ` Jianxin Pan [this message]
2018-11-05  9:46               ` jbrunet
2018-11-05 11:29                 ` Jianxin Pan
2018-10-28 15:12         ` Jianxin Pan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66c2915a-4ecd-8a6e-6493-4318ae7bb620@amlogic.com \
    --to=jianxin.pan@amlogic.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=carlo@caione.org \
    --cc=hanjie.lin@amlogic.com \
    --cc=jbrunet@baylibre.com \
    --cc=jian.hu@amlogic.com \
    --cc=khilman@baylibre.com \
    --cc=liang.yang@amlogic.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=narmstrong@baylibre.com \
    --cc=qiufang.dai@amlogic.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=victor.wan@amlogic.com \
    --cc=yixun.lan@amlogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).