Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp824763imd; Sat, 3 Nov 2018 11:02:20 -0700 (PDT) X-Google-Smtp-Source: AJdET5fuwVTbk5vPn+vAgdTJv8jXBubNPVVP84DuUiWDnPVLTgBy/wKzJcu67PocMEEt/FDsICrn X-Received: by 2002:a65:62d5:: with SMTP id m21-v6mr15020316pgv.243.1541268140059; Sat, 03 Nov 2018 11:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541268140; cv=none; d=google.com; s=arc-20160816; b=dgXh8CD0iwwl7fVPeKnVxbjk0rkfb+xJbN5w+eubLm8/hf5pUN2XSkWdSoYSpxqAbS vQPYbZRB3QR7QOh/8LZK0mrT0dz3vJejmLrPNJI5Csd/A8Q5g+xYQB+260WSDjILzy9T DQYXmCXFgzWpfj1229/VnBlBLiPNUMT/AvncOzEUeZhiZsTQdMrortIFQ0qtAefmxo1A a1yz/22S2UyAjAuUrw7qas8cTuULJ5JumT4rR41urUTPx5etQ+viekDBZ6v8yt0TLvdQ 5XaNEX+MBVpXBnuoGLFpuMBCytRhQjDEt+BHeXryDRZvj25Rn8Cve3sMsYhxWeSAQOHC fuSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Tjz2zX2HlnpEQfX+4doPPyJxL1YGNEWaJjKU5mkop/Y=; b=y5TMSfJsDWHMJqLObCF43MJviPL4F3MYGHWsk1sWsX6Z1X0UI7Wia7DdfvQHi57iuM fJJNN+56eAmt9zVPz+KwAzDXCVAJhtQNp0PPHToE9vYJE30gF1wF6WXfcUOJsHCWA3Xs Zz1Paae4/jdr7o6prWKPRRBFdeVYVPUvt3aqvo4MHw1rnQlI0FkMYKKtiebLGbZjUqeu FWEv+UHaQPblsC3KsLB9qTlBbRPVtstG4Bp/bQWV6hLgRKQN63wiqKpXrDnBjiMYl743 h8meCNNXsDfPtvdm2Vhi0GivIUuuffnVAJIFbcGsODIT5Isg0RzpMlhc4nAoJLfAPj9n FkDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z67-v6si39860917pfz.5.2018.11.03.11.02.02; Sat, 03 Nov 2018 11:02:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728568AbeKDDNi (ORCPT + 99 others); Sat, 3 Nov 2018 23:13:38 -0400 Received: from mail-sh2.amlogic.com ([58.32.228.45]:44231 "EHLO mail-sh2.amlogic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727497AbeKDDNi (ORCPT ); Sat, 3 Nov 2018 23:13:38 -0400 Received: from [192.168.0.111] (223.167.21.242) by mail-sh2.amlogic.com (10.18.11.6) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 4 Nov 2018 02:01:39 +0800 Subject: Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver To: Jerome Brunet , Martin Blumenstingl CC: Neil Armstrong , , , , , , , , , , , , , , , , , References: <1539839245-13793-1-git-send-email-jianxin.pan@amlogic.com> <1539839245-13793-4-git-send-email-jianxin.pan@amlogic.com> <3723695d951e0d30e8a0117d336d8f268269a030.camel@baylibre.com> From: Jianxin Pan Message-ID: <66c2915a-4ecd-8a6e-6493-4318ae7bb620@amlogic.com> Date: Sun, 4 Nov 2018 02:01:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3723695d951e0d30e8a0117d336d8f268269a030.camel@baylibre.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [223.167.21.242] X-ClientProxiedBy: mail-sh2.amlogic.com (10.18.11.6) To mail-sh2.amlogic.com (10.18.11.6) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > > > . >