Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14986181rwb; Mon, 28 Nov 2022 06:57:25 -0800 (PST) X-Google-Smtp-Source: AA0mqf5wIrrq1WLc4d1GbLalmDMVVw6ziP/KbfdfzeV6/4Ho6bvs8UvrnjuKX/DYi0T0okKIh9JI X-Received: by 2002:a17:906:b04c:b0:78d:9b0a:7b0b with SMTP id bj12-20020a170906b04c00b0078d9b0a7b0bmr43630503ejb.197.1669647444958; Mon, 28 Nov 2022 06:57:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669647444; cv=none; d=google.com; s=arc-20160816; b=kQsjGShOrfU0MAXEU1TSK6DyQJt7hg8/20sXGXllf3dA1Fq0G2QQfPz4ciMV+953bY GvOhS7TpJQW+ByS559gDGgQM4Y2M6ZJ8iipdwCDLVm+6udJZmz9NejNT4wS5t95a2eMO lWcxMc4D73S5Ztchpxnws+uuPX6uayTYg2DLHqYpFWQHQbRyAo5RtzoBv1HDY28m6Xu+ ES0cvKxk53QP58vJki92zeFUmaWxAXp9r85ObGRQvXRJyZG9itgpN67dHz+pqt5CYuxp irK1ytYsmcyB0H3QmvweYw+olUU6SUrmE2+GP04boivhFSeJLUOTtMGjLy/eHc0jYNR+ iduw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=qSvMj8PUNBAvsb6moF/MSstY3kL26RyBVoPokCmHLD4=; b=enk8+sz2AE+hHGF6CsYTCMAgSl9cd243cvKWHCvAO15b5kVElb29wGuH+3oy19eyoH JIVrIQpy9ZPkQBcqnKNHByvLKQ13U+NFXVLNvfpy29W7QYiNpLNC1ltCH/dEU+gGlpTp 74+7b5nPwsj6JAqcQc9epc82ZAInwEwiCMRL4vi4tz4y+e/qEaptm7bj6HSSICQ4a/BY iXT14nQdJwBjvURiiR9Jr7lVG8/4DgYq/pXPB6SRI2a6X2b/IGFZcWdyJqfyWy3w7Bcf D/q0aTV2kXPT/3qMtsAockkNeq25xn/kUwS1At8x2mevsU5jen5NsxqKUiOiQ/4KaoNa UFWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ga15-20020a1709070c0f00b0078232bfe3a0si10737192ejc.331.2022.11.28.06.57.05; Mon, 28 Nov 2022 06:57:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231969AbiK1NcO (ORCPT + 84 others); Mon, 28 Nov 2022 08:32:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231723AbiK1NcC (ORCPT ); Mon, 28 Nov 2022 08:32:02 -0500 Received: from mail-sh.amlogic.com (mail-sh.amlogic.com [58.32.228.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E70031CFF0; Mon, 28 Nov 2022 05:31:02 -0800 (PST) Received: from [10.18.29.47] (10.18.29.47) by mail-sh.amlogic.com (10.18.11.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.13; Mon, 28 Nov 2022 21:30:59 +0800 Message-ID: <29f06ea8-3795-46a4-fcd2-3f0d4c313ae7@amlogic.com> Date: Mon, 28 Nov 2022 21:30:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH V5 1/4] clk: meson: S4: add support for Amlogic S4 SoC PLL clock driver and bindings Content-Language: en-US To: Jerome Brunet , Krzysztof Kozlowski , , , , , , , Rob Herring , Kevin Hilman , Michael Turquette , Stephen Boyd , Krzysztof Kozlowski , Martin Blumenstingl CC: References: <20221123021346.18136-1-yu.tu@amlogic.com> <20221123021346.18136-2-yu.tu@amlogic.com> <92b570ea-3ddc-8e91-5a7a-ed601bb7c02c@amlogic.com> <5b7176b4-d7a2-c67f-31c6-e842e0870836@linaro.org> <1jfse72wqk.fsf@starbuckisacylon.baylibre.com> <1jedtnp7db.fsf@starbuckisacylon.baylibre.com> From: Yu Tu In-Reply-To: <1jedtnp7db.fsf@starbuckisacylon.baylibre.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.18.29.47] X-ClientProxiedBy: mail-sh.amlogic.com (10.18.11.5) To mail-sh.amlogic.com (10.18.11.5) X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jerome , On 2022/11/28 20:33, Jerome Brunet wrote: > [ EXTERNAL EMAIL ] > > > On Mon 28 Nov 2022 at 15:39, Yu Tu wrote: > >> Hi Jerome, >> Thank you for your reply. >> >> On 2022/11/25 17:23, Jerome Brunet wrote: >>> [ EXTERNAL EMAIL ] >>> On Wed 23 Nov 2022 at 14:53, Krzysztof Kozlowski >>> wrote: >>> >>>> On 23/11/2022 14:23, Neil Armstrong wrote: >>>>> Hi, >>>>> >>>>> On 23/11/2022 12:16, Yu Tu wrote: >>>>>> Hi Krzysztof, >>>>>>     Thank you for your reply. >>>>>> >>>>>> On 2022/11/23 18:08, Krzysztof Kozlowski wrote: >>>>>>> [ EXTERNAL EMAIL ] >>>>>>> >>>>>>> On 23/11/2022 03:13, Yu Tu wrote: >>>>>>>> Add the S4 PLL clock controller found and bindings in the s4 SoC family. >>>>>>>> >>>>>>>> Signed-off-by: Yu Tu >>>>>>>> --- >>>>>>>>   .../bindings/clock/amlogic,s4-pll-clkc.yaml   |  51 + >>>>>>> >>>>>>> This is v5 and still bindings are here? Bindings are always separate >>>>>>> patches. Use subject prefixes matching the subsystem (git log --oneline >>>>>>> -- ...). >>>>>>> >>>>>>> And this was split, wasn't it? What happened here?!? >>>>>> >>>>>> Put bindings and clock driver patch together from Jerome. Maybe you can read this chat history. >>>>>> https://lore.kernel.or/all/1jy1v6z14n.fsf@starbuckisacylon.baylibre.com/ >>>>> >>>>> Jerome was asking you to send 2 patchsets, one with : >>>>> - bindings in separate patches >>>>> - drivers in separate patches >>>>> and a second with DT changes. >>> Indeed, this is what was asked. It is aligned with Krzysztof's request. >> >> According to your discussion, I still should send patches in the previous >> way in series. But I'm going to change it like you suggested. >> I don't know, am I getting it right? > > 3 people tried to explain this already and we all told you the same thing. > > * 1 patchset per maintainer: clk and dt > * bindings must be dedicated patches - never mixed with driver code. > > I strongly suggest that you take some time to (re)read: > * https://docs.kernel.org/process/submitting-patches.html > * https://docs.kernel.org/devicetree/bindings/submitting-patches.html > > If still unclear, please take some time to look at the kernel mailing > list archive and see how others have done the same things. > > Thx. I'll change it as you suggest.But I still don't understand what you suggested in V3. I remember discussing it with you at V3. https://lore.kernel.or/all/1jy1v6z14n.fsf@starbuckisacylon.baylibre.com/ ">>>> Also it would be nice to split this in two series. >>>> Bindings and drivers in one, arm64 dt in the other. These changes goes >>>> in through different trees. >>> At present, Bindings, DTS and drivers are three series. Do you mean to put >>> Bindings and drivers together? If so, checkpatch.pl will report a warning. >> Yes because patches are not in yet so there is a good reason to ignore >> the warning. Warning will never show up on the actual tree if the >> patches are correctly ordered. > > I think Binding, DTS and drivers use three series and you said two series > is not a big problem. Three series are recommended for checkpatch.pl, I > think it should be easy for that to separate and merge。 No - There is only 2 series. 1 for the bindings and clock drivers and one for the DT once things are in" > >> >>> >>>>> >>>>> Then when the bindings + clocks patches are merged, a pull request of the bindings >>>>> can be done to me so I can merge it with DT. >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>>   MAINTAINERS                                   |   1 + >>>>>>>>   drivers/clk/meson/Kconfig                     |  13 + >>>>>>>>   drivers/clk/meson/Makefile                    |   1 + >>>>>>>>   drivers/clk/meson/s4-pll.c                    | 875 ++++++++++++++++++ >>>>>>>>   drivers/clk/meson/s4-pll.h                    |  88 ++ >>>>>>>>   .../dt-bindings/clock/amlogic,s4-pll-clkc.h   |  30 + >>>>>>>>   7 files changed, 1059 insertions(+) >>>>>>>>   create mode 100644 Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml >>>>>>>>   create mode 100644 drivers/clk/meson/s4-pll.c >>>>>>>>   create mode 100644 drivers/clk/meson/s4-pll.h >>>>>>>>   create mode 100644 include/dt-bindings/clock/amlogic,s4-pll-clkc.h >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..fd517e8ef14f >>>>>>>> --- /dev/null >>>>>>>> +++ b/Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml >>>>>>>> @@ -0,0 +1,51 @@ >>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>>>>> +%YAML 1.2 >>>>>>>> +--- >>>>>>>> +$id: http://devicetree.org/schemas/clock/amlogic,s4-pll-clkc.yaml# >>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>>>>> + >>>>>>>> +title: Amlogic Meson S serials PLL Clock Controller >>>>>>>> + >>>>>>>> +maintainers: >>>>>>>> +  - Neil Armstrong >>>>>>>> +  - Jerome Brunet >>>>>>>> +  - Yu Tu >>>>>>>> + >>>>>>> One blank line. >>>>>> >>>>>>  I will delete this, on next version patch. >>>>>> >>>>>>> >>>>>>>> + >>>>>>>> +properties: >>>>>>>> +  compatible: >>>>>>>> +    const: amlogic,s4-pll-clkc >>>>>>>> + >>>>>>>> +  reg: >>>>>>>> +    maxItems: 1 >>>>>>>> + >>>>>>>> +  clocks: >>>>>>>> +    maxItems: 1 >>>>>>>> + >>>>>>>> +  clock-names: >>>>>>>> +    items: >>>>>>>> +      - const: xtal >>>>>>>> + >>>>>>>> +  "#clock-cells": >>>>>>>> +    const: 1 >>>>>>>> + >>>>>>>> +required: >>>>>>>> +  - compatible >>>>>>>> +  - reg >>>>>>>> +  - clocks >>>>>>>> +  - clock-names >>>>>>>> +  - "#clock-cells" >>>>>>>> + >>>>>>>> +additionalProperties: false >>>>>>>> + >>>>>>>> +examples: >>>>>>>> +  - | >>>>>>>> +    clkc_pll: clock-controller@fe008000 { >>>>>>>> +      compatible = "amlogic,s4-pll-clkc"; >>>>>>>> +      reg = <0xfe008000 0x1e8>; >>>>>>>> +      clocks = <&xtal>; >>>>>>>> +      clock-names = "xtal"; >>>>>>>> +      #clock-cells = <1>; >>>>>>>> +    }; >>>>>>> >>>>>>> >>>>>>>> +#endif /* __MESON_S4_PLL_H__ */ >>>>>>>> diff --git a/include/dt-bindings/clock/amlogic,s4-pll-clkc.h b/include/dt-bindings/clock/amlogic,s4-pll-clkc.h >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..345f87023886 >>>>>>>> --- /dev/null >>>>>>>> +++ b/include/dt-bindings/clock/amlogic,s4-pll-clkc.h >>>>>>> >>>>>>> This belongs to bindings patch, not driver. >>>>>>> >>>>>>>> @@ -0,0 +1,30 @@ >>>>>>>> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ >>>>>>>> +/* >>>>>>>> + * Copyright (c) 2021 Amlogic, Inc. All rights reserved. >>>>>>>> + * Author: Yu Tu >>>>>>>> + */ >>>>>>>> + >>>>>>>> +#ifndef _DT_BINDINGS_CLOCK_AMLOGIC_S4_PLL_CLKC_H >>>>>>>> +#define _DT_BINDINGS_CLOCK_AMLOGIC_S4_PLL_CLKC_H >>>>>>>> + >>>>>>>> +/* >>>>>>>> + * CLKID index values >>>>>>>> + */ >>>>>>>> + >>>>>>>> +#define CLKID_FIXED_PLL            1 >>>>>>>> +#define CLKID_FCLK_DIV2            3 >>>>>>> >>>>>>> Indexes start from 0 and are incremented by 1. Not by 2. >>>>>>> >>>>>>> NAK. >>>>>> >>>>>> I remember Jerome discussing this with you.You can look at this submission history. >>>>>> https://lore.kernel.org/all/c088e01c-0714-82be-8347-6140daf56640@linaro.org/ >>>>> >>>>> Historically we did that by only exposing part of the numbers, controlling which >>>>> clocks were part of the bindings. >>>>> >>>>> But it seems this doesn't make sens anymore, maybe it would be time to put all the >>>>> clock ids in the bindings for this new SoC and break with the previous strategy. >>> Krzysztof and I agreed there is nothing wrong with the current >>> approach, I believe. >>> It does not prevent someone from using an un-exposed clock, sure, or >>> exposing it in the future if necessary. >>> However, I think it clearly shows that an un-exposed element is not >>> expected to be used by an external consumers. It should be enough to >>> trigger a discussion if this expectation is wrong. >>> >>>> >>>> So the outcome of the previous discussion was somewhere later in that >>>> thread: >>>> >>>>> It is just a choice to not expose some IDs. >>>>> It is not tied to the implementation at all. >>>>> I think we actually follow the rules and the idea behind it. >>>> >>>> >>>> Best regards, >>>> Krzysztof >>> . > > .