Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3812678imd; Mon, 29 Oct 2018 12:46:50 -0700 (PDT) X-Google-Smtp-Source: AJdET5e5sXetzHeDDjG5dNXv1pDSPUdEaSgneLCjVIQLYdbP8uo2+omVwhXR1CmVFFeNSpX4zvX0 X-Received: by 2002:a63:bc12:: with SMTP id q18-v6mr14576089pge.353.1540842410505; Mon, 29 Oct 2018 12:46:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540842410; cv=none; d=google.com; s=arc-20160816; b=EUKmrVDW3Op7iBepJIOOnsnRXjlHdeky1dgz40hLYezQOjp+nJKcCINj+jAIaGn0lv hkAGNQrCXgPOYVbHkEDpOONgEUY4Kh1P73c1qh7nvm7yH/9741iw+gvpW6A7uNiXev+c 2AMWDzBNpP1cnalRItXiW9i3xCUkeZaSUMMh/sa0g+/n+YKMvCeRBEQY24tmY6j+EKSs CPQibntMMUMo7Cx7lQsbt02LSwU6oFQ5KaDnz3C2qCR8e5r1OgoLDlsmGjapme4sCGBq 7934Sue90J70Tcp37qXNqnvgO/C31oqA/fBwQ7xmy+huXgJguyaUjNRvx1POzJIEJmhx APhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=+P+YyHQN4mbzIEI8gj6PxHxuqBpIjDzGExY1dBY+9d4=; b=JtYKiFsr1/sgIAOBrsAVqmMOJ4kH/cx3bogF42ypu/bYkqQ5F9bVfqh2bK0qsiey2c RJkE0S2wJmFaUJADxVydmKHy0pLcNmZ5wZ9eMJPtpBVXWKAZ56RivywQbM5UAgo4WLgQ vy5nRSS020G8DkiZvXPXB9MEUM1lbmdZv4o+C5NdZPyzHD/aaqR3T6Lq4clSrWaBItKc 0mHAhPW64LsjFvgHFIMDyRERrRsGuF1bY+zEqb346rzXRcO7ESWnwyAY9kZkBB3RCn33 almhrwbOPdulDBxXlkeVByq0cUhIl7UwBsBSoO8iB40hSvww9cPHZgaOWgZiCa8TlNMJ oqfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=ZR0WGkzW; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m6-v6si20752774pgg.265.2018.10.29.12.46.35; Mon, 29 Oct 2018 12:46:50 -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; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=ZR0WGkzW; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728936AbeJ3Ef4 (ORCPT + 99 others); Tue, 30 Oct 2018 00:35:56 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:37121 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725911AbeJ3Ef4 (ORCPT ); Tue, 30 Oct 2018 00:35:56 -0400 Received: by mail-oi1-f193.google.com with SMTP id w66-v6so3929914oiw.4; Mon, 29 Oct 2018 12:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+P+YyHQN4mbzIEI8gj6PxHxuqBpIjDzGExY1dBY+9d4=; b=ZR0WGkzWU75PY8YKcHoqeSHCE2QzOKCRQphzI2WtlaVsXOUKtRKMGlJI/OLbzhfTmV 6bulfiIJHwh0zHl3SDZmIiAIQ6V/Ak6Pm6hWWykhdf6NLPY3LH3dLDmcnWwnFDTXrxjb q+n3+O7YTlqLoEKYc+NIZxXl281uTlPMs5eciFPfY+isNqRV1xX60OiqqEZTpirSyv6z cuqEhBqLJr0NQfvekoLk462AbnZI2DuJYo7AYkS66sX06Uo/UuSy5C9SjkxH+bGUqwut pjj4wXp+m5BGrCIGTr7RqTR4cyYPUHBenklsNifS0ho+oKQh2JzShCH929m/YzSJUOce Q6WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+P+YyHQN4mbzIEI8gj6PxHxuqBpIjDzGExY1dBY+9d4=; b=at1r8Zn0SH373L8PwllmBTBTlDr6qozrYXGEYj2Q5h3+s5bGpdiJPr/2mB6chSrKNu td3mktyZsWWr2RDjkhrmtuD9TWFLNmAfTRuhILNzPXPz6KFVsGjaJWE/6NLZbfvfb1KN QfpFmH5UuN1DNSXxASnAzricq4guFnxzx6zG6tUqruEdFhDJDKZUdvctjj8/Ue1B8BbT zKNlPabHSAcE/RPKkCO2vxy76GozgpAPztoD3u8Hm/fmFo1Zjz3nqUPDr4SHuwg4a6Gf n0DPsAgbyS9NzYwe+8uGoh8fZOvYK7ZcsXft3l469nbXZO3zjdQHtmkSoepoM5i8JAbC PBww== X-Gm-Message-State: AGRZ1gL5OibHEN09T8be7JhV3HWQBWGypFadfkWH861ZW4lEitPs9xUa VRZMk0hx2+yZ884sIdw3tCA0nfIGYJlSfLM3Bj8= X-Received: by 2002:aca:e804:: with SMTP id f4-v6mr8705120oih.38.1540842348082; Mon, 29 Oct 2018 12:45:48 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <3723695d951e0d30e8a0117d336d8f268269a030.camel@baylibre.com> From: Martin Blumenstingl Date: Mon, 29 Oct 2018 20:45:36 +0100 Message-ID: Subject: Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver To: jbrunet@baylibre.com Cc: jianxin.pan@amlogic.com, Neil Armstrong , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jerome, many thanks for the whole explanation! On Sun, Oct 28, 2018 at 8:16 PM 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. > > * 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. > > * 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. > > Both the generic divider and sclk could work here ... it's up to you Jianxin. to give even more options: the generic divider will (probably) get a CLK_DIVIDER_ZERO_GATE flag in the next development cycle, see [0] (this may require a small change to clk-regmap on top) Regards Martin [0] https://patchwork.kernel.org/patch/10650797/