[v4,01/13] dt-bindings: clk: g12a-clkc: export VCLK2_SEL and add CTS_ENCL clock ids
Message ID | 20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-1-2592c29ea263@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp5094639vqo; Fri, 12 May 2023 06:13:19 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6DvHNDxdKNpIEnSl/8eYpRHpGm0r9SJWnn4xkPhvQxoRx7JuS3MRPOyKmfrh+O0sr3bcZd X-Received: by 2002:a17:902:7482:b0:1aa:f43f:e60 with SMTP id h2-20020a170902748200b001aaf43f0e60mr26363416pll.36.1683897198986; Fri, 12 May 2023 06:13:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683897198; cv=none; d=google.com; s=arc-20160816; b=cAn+7lCQYZxAfeiXQ5iAr5LPyHEZOVlVRzj8QdQUE6AMbt8oGnlTOXEziMpHHj8anj cdOC90fvy8Q2qLHsVWPzju0tY5LiEPZZh7FWGYGm+xDwvGT2sonVEf94vE9wny+Xx3Ro 0t6O1+fV2CcVGgmumRC/k4MpSahWRyI4GoUsVd3pNIVKN946JZbQM5wQFA+WRVNc16Ds m3bJdnkRTU8jNmWKNzi0ywc5JFjwqQBgUL4SGxA09wbqdFyfvcTH8WVMUiRx6m2vLnQ8 M8sZ07TQ3x8wLvL33NwAFeeYrN7D1kiQ2AWlMZQtp0mTu8ENlXZZkZMuEIBvGWyx3w4U PCHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=TCif7crIj/Q+cQYJxHIAitbk8dIOcZs5cJxa+/QObN0=; b=Xcb2sN3C1wIBFfFu/aVaxyeYPa8sC1dUobYqXByyTUyYCim8KD4awok2MvIIJUKIOk uGyzKKYKmLfm4h0AvP23aT2ZMh+tR0ofDZAghcY++Z/IoHDLfqCwrrHa4goGDUTQQlPa 9643KdqSM+AoMM9yKBCfl3wHXijHQcsyHvqpB9h3KqN86VbztuCaGvy/sHqlh1Jp0y09 9dUBNDYkS02R5S0jrf6HocTi342ij+XqCKaR/YX9K4F142Wa9riYcWoB5pFVzrBH+QrJ LM2d5G/bm+tu9ovJt4Cp5lP+d58ZGSIBqdnHk52ZKQ9QHM1WeqhN5zzkQyeVgoZrcRUi yu2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=d8ReaVAZ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v71-20020a63894a000000b00524f08d75f5si9022690pgd.567.2023.05.12.06.13.03; Fri, 12 May 2023 06:13:18 -0700 (PDT) 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; dkim=pass header.i=@linaro.org header.s=google header.b=d8ReaVAZ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241074AbjELNMC (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Fri, 12 May 2023 09:12:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241004AbjELNL5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 12 May 2023 09:11:57 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66DB611579 for <linux-kernel@vger.kernel.org>; Fri, 12 May 2023 06:11:55 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-3f4ec041fc3so12923635e9.1 for <linux-kernel@vger.kernel.org>; Fri, 12 May 2023 06:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683897114; x=1686489114; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=TCif7crIj/Q+cQYJxHIAitbk8dIOcZs5cJxa+/QObN0=; b=d8ReaVAZ8FGgRG41sHZjy5aJxvI3k2Wxp4ywR4UuUr6DVd2z5pq9ae5LRlfNCDj1+p 7fCHM6i6ltr+pof+tk+/99AhTvsaEROv0fDEUbnyqZ3GkOOcMGSFiVJZf83V58DI6SKF d3cVUKbXyCUEN2qE1ckHhgmX7K0Q634+q/QgMoI8DzozrrSaDV0OnDnHyDa5ITpUY6Lb 1+I0C8qZ+RDN5waxpoQSRXmhDt50GuLNA17VlhKV4STibWDY1vJmE1bCPSfHe9qsHm0m xyl+25xAA/ZflITwDnuw3j0QLRIaeLpdQRZNUXmjOUQ7XVTr8bs6vjUW1fz8zVwJt9Qu mnKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683897114; x=1686489114; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TCif7crIj/Q+cQYJxHIAitbk8dIOcZs5cJxa+/QObN0=; b=PZBkQP2+aNNbkYFxrWJ/ltLjvMIDchYs5o5gD5nhRZCfRb/uc218+BQ7T2dK5IJieu GbheUb93a4AC3dKmTWHCivaJCswJ6mP2Z8TbTLPw78O4i9WW96f55thE0n3hy0MpqghB RsfI1tMKujRbXgtpcsug0hvzhSW3bgS1hH8uZnjmpSb4qyDdMhBZrrm4LQ55vvm0soCX U6w+qUA5E1LGtEEYiPFEx3+8ZeM+Xt+8Ury123wvawouUddZM8z64GqAwg8qMWxlYaeZ Yn+LBvi3k9oLARhuEEq/JKT9g5uJRhVA0rRhPRQ7H5svJxIMBQilS26FAPzjm2AAeyGd DOwQ== X-Gm-Message-State: AC+VfDx3hX3l0o2QJHnFRjdwLMHjI+TzvEYK9XHiuxxYe1m5/sjdjjLM QczphwPHMMjWxRJ7w5Fioj+iqA== X-Received: by 2002:a1c:c908:0:b0:3f1:662a:93d0 with SMTP id f8-20020a1cc908000000b003f1662a93d0mr18456984wmb.15.1683897113972; Fri, 12 May 2023 06:11:53 -0700 (PDT) Received: from arrakeen.starnux.net ([2a01:e0a:982:cbb0:8261:5fff:fe11:bdda]) by smtp.gmail.com with ESMTPSA id v10-20020a5d610a000000b0030647449730sm23461965wrt.74.2023.05.12.06.11.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 May 2023 06:11:53 -0700 (PDT) From: Neil Armstrong <neil.armstrong@linaro.org> Date: Fri, 12 May 2023 15:11:32 +0200 Subject: [PATCH v4 01/13] dt-bindings: clk: g12a-clkc: export VCLK2_SEL and add CTS_ENCL clock ids MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-1-2592c29ea263@linaro.org> References: <20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea263@linaro.org> In-Reply-To: <20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea263@linaro.org> To: Jerome Brunet <jbrunet@baylibre.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Kevin Hilman <khilman@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Philipp Zabel <p.zabel@pengutronix.de>, Vinod Koul <vkoul@kernel.org>, Kishon Vijay Abraham I <kishon@kernel.org>, Sam Ravnborg <sam@ravnborg.org> Cc: Nicolas Belin <nbelin@baylibre.com>, linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-phy@lists.infradead.org, Neil Armstrong <neil.armstrong@linaro.org> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1451; i=neil.armstrong@linaro.org; h=from:subject:message-id; bh=Amfvy8AIRpoaKCjLWius5WoZ7OLXQo8QlfjTgDRK50c=; b=owEBbQKS/ZANAwAKAXfc29rIyEnRAcsmYgBkXjsS/xb78nbVwpTmjP+QuEB7+O3NBa/QB86INXFY Y60FIeGJAjMEAAEKAB0WIQQ9U8YmyFYF/h30LIt33NvayMhJ0QUCZF47EgAKCRB33NvayMhJ0X5HEA Cv0kyCcpaM9ud6vdmE+8t+V2OnX+Mm51tFsvYR9LjCMrDENGe0d+m2dWigi7JMMIeeuq/6n5RPjxHH RvrZm2Za0/sedwLuQ4DCdU+GT31rwcEEb/bE1Qp8lxgke+/bOTdNEiEhRNy2HlmjDgJ/AbdJ62Gfjk wlJVjS03B3cCwn5+/LxSlkhS9PBZIUXb0DKUkagnejQemxgKwBzAHCbjRCIYe1zQqE8x8Tbs0hHdUM xTRkhuRQfna7zLvtOHJezV8ZhjrOFjri6gFf12S/7KQtmDLIUkd8U4AzuHnRCPsj7iKHM+l9jQi36J FwZjxKeKUN+Jl2tAdqe2eO4odBHCCVWri4iDCwteEusAI/HwBQp7A0seEAxMvHMXei/sK5uFclitUk WdQlZAmmF5uSUi4Yk8krjGgRhsOGNA6euakrseK4XeCZ2dVRJGDH4qR52yWQsT3Jrw2qmrc7QyQ1kP vO/+xWZbE+kCjpmCxsXoxo9i4A1SCCjeo1Uw/EAOLfoNagbC+3eFG01Q2ERk7O0seC3PshCSNCyhee WpRXRRmnh5L5RXeKBAzbkh3d9/YoJGNY77075Pdm2Flgu4BS58cjeOvLP9b5cN6X82ehnyPfaxKuS1 66zRZSxKi92sCRDxQUDmdLQ1MtYZNR4in/ZxcB/sXPzen1Y+6sbOwNSl0BUg== X-Developer-Key: i=neil.armstrong@linaro.org; a=openpgp; fpr=89EC3D058446217450F22848169AB7B1A4CFF8AE X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765694189407079543?= X-GMAIL-MSGID: =?utf-8?q?1765694189407079543?= |
Series |
drm/meson: add support for MIPI DSI Display
|
|
Commit Message
Neil Armstrong
May 12, 2023, 1:11 p.m. UTC
Expose VCLK2_SEL clock id and add new ids for the CTS_ENCL and CTS_ENCL_SEL
clocks on G12A compatible SoCs.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/clk/meson/g12a.h | 1 -
include/dt-bindings/clock/g12a-clkc.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
Comments
On 12/05/2023 15:11, Neil Armstrong wrote: > Expose VCLK2_SEL clock id and add new ids for the CTS_ENCL and CTS_ENCL_SEL > clocks on G12A compatible SoCs. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- > drivers/clk/meson/g12a.h | 1 - > include/dt-bindings/clock/g12a-clkc.h | 3 +++ > 2 files changed, 3 insertions(+), 1 deletion(-) Bindings must be a separate patch from the driver changes. If this causes bisectability issues, this means entire solution breaks ABI and is not appropriate anyway... Best regards, Krzysztof
On 13/05/2023 20:28, Krzysztof Kozlowski wrote: > On 12/05/2023 15:11, Neil Armstrong wrote: >> Expose VCLK2_SEL clock id and add new ids for the CTS_ENCL and CTS_ENCL_SEL >> clocks on G12A compatible SoCs. >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> --- >> drivers/clk/meson/g12a.h | 1 - >> include/dt-bindings/clock/g12a-clkc.h | 3 +++ >> 2 files changed, 3 insertions(+), 1 deletion(-) > > Bindings must be a separate patch from the driver changes. If this > causes bisectability issues, this means entire solution breaks ABI and > is not appropriate anyway... This is basically how we handled CLK IDs on Amlogic clk bindings for the last years, the amount of changes is very low and rather exceptional compared to early development stage. Neil > > Best regards, > Krzysztof >
On 15/05/2023 18:06, Neil Armstrong wrote: > On 13/05/2023 20:28, Krzysztof Kozlowski wrote: >> On 12/05/2023 15:11, Neil Armstrong wrote: >>> Expose VCLK2_SEL clock id and add new ids for the CTS_ENCL and CTS_ENCL_SEL >>> clocks on G12A compatible SoCs. >>> >>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >>> --- >>> drivers/clk/meson/g12a.h | 1 - >>> include/dt-bindings/clock/g12a-clkc.h | 3 +++ >>> 2 files changed, 3 insertions(+), 1 deletion(-) >> >> Bindings must be a separate patch from the driver changes. If this >> causes bisectability issues, this means entire solution breaks ABI and >> is not appropriate anyway... > > This is basically how we handled CLK IDs on Amlogic clk bindings for the > last years, the amount of changes is very low and rather exceptional > compared to early development stage. The commits with bindings are used in devicetree-rebasing repo, so we want them to be separate. Meson is the only or almost the only platform making such changes. I don't get why, because the conflict could be easily avoided with using different names for defines in bindings and local clock. Approach of having bindings strictly tied with driver commit is never desired. Best regards, Krzysztof
On 15/05/2023 18:13, Krzysztof Kozlowski wrote: > On 15/05/2023 18:06, Neil Armstrong wrote: >> On 13/05/2023 20:28, Krzysztof Kozlowski wrote: >>> On 12/05/2023 15:11, Neil Armstrong wrote: >>>> Expose VCLK2_SEL clock id and add new ids for the CTS_ENCL and CTS_ENCL_SEL >>>> clocks on G12A compatible SoCs. >>>> >>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >>>> --- >>>> drivers/clk/meson/g12a.h | 1 - >>>> include/dt-bindings/clock/g12a-clkc.h | 3 +++ >>>> 2 files changed, 3 insertions(+), 1 deletion(-) >>> >>> Bindings must be a separate patch from the driver changes. If this >>> causes bisectability issues, this means entire solution breaks ABI and >>> is not appropriate anyway... >> >> This is basically how we handled CLK IDs on Amlogic clk bindings for the >> last years, the amount of changes is very low and rather exceptional >> compared to early development stage. > > The commits with bindings are used in devicetree-rebasing repo, so we > want them to be separate. > > Meson is the only or almost the only platform making such changes. I > don't get why, because the conflict could be easily avoided with using > different names for defines in bindings and local clock. Approach of > having bindings strictly tied with driver commit is never desired. Also one more argument maybe not relevant here but for other cases - this makes literally impossible to include the clock ID in DTS in the same kernel revision, because you must not merge driver branch to DTS branch. SoC folks were complaining about this many times. Best regards, Krzysztof
On 15/05/2023 18:15, Krzysztof Kozlowski wrote: > On 15/05/2023 18:13, Krzysztof Kozlowski wrote: >> On 15/05/2023 18:06, Neil Armstrong wrote: >>> On 13/05/2023 20:28, Krzysztof Kozlowski wrote: >>>> On 12/05/2023 15:11, Neil Armstrong wrote: >>>>> Expose VCLK2_SEL clock id and add new ids for the CTS_ENCL and CTS_ENCL_SEL >>>>> clocks on G12A compatible SoCs. >>>>> >>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >>>>> --- >>>>> drivers/clk/meson/g12a.h | 1 - >>>>> include/dt-bindings/clock/g12a-clkc.h | 3 +++ >>>>> 2 files changed, 3 insertions(+), 1 deletion(-) >>>> >>>> Bindings must be a separate patch from the driver changes. If this >>>> causes bisectability issues, this means entire solution breaks ABI and >>>> is not appropriate anyway... >>> >>> This is basically how we handled CLK IDs on Amlogic clk bindings for the >>> last years, the amount of changes is very low and rather exceptional >>> compared to early development stage. >> >> The commits with bindings are used in devicetree-rebasing repo, so we >> want them to be separate. A lot of commits changes the bindings and other part of the kernel source, it was solved with git filter-repo a long time ago. While I understand in an ideal world those commits should only touch Documentation/bindings, it's sometime not possible. >> >> Meson is the only or almost the only platform making such changes. I >> don't get why, because the conflict could be easily avoided with using >> different names for defines in bindings and local clock. Approach of >> having bindings strictly tied with driver commit is never desired. If we did it now, we would have make it differently and expose all the clock IDs on the bindings like on Qcom, be sure of that. > > Also one more argument maybe not relevant here but for other cases - > this makes literally impossible to include the clock ID in DTS in the > same kernel revision, because you must not merge driver branch to DTS > branch. SoC folks were complaining about this many times. Actually we handle this very simply by having such patches merged in a immutable branch merged in the clock and DT pull-requests, it worked perfectly so far and neither Stephen or Arnd complained about that. > > Best regards, > Krzysztof >
On 15/05/2023 18:22, neil.armstrong@linaro.org wrote: >>> Meson is the only or almost the only platform making such changes. I >>> don't get why, because the conflict could be easily avoided with using >>> different names for defines in bindings and local clock. Approach of >>> having bindings strictly tied with driver commit is never desired. > > If we did it now, we would have make it differently and expose all the clock > IDs on the bindings like on Qcom, be sure of that. No, you just keep different names. The only problem here is that your clock name is the same thus you cannot split bindings into separate patch. > >> >> Also one more argument maybe not relevant here but for other cases - >> this makes literally impossible to include the clock ID in DTS in the >> same kernel revision, because you must not merge driver branch to DTS >> branch. SoC folks were complaining about this many times. > > Actually we handle this very simply by having such patches merged in a immutable > branch merged in the clock and DT pull-requests, it worked perfectly so far > and neither Stephen or Arnd complained about that. Arnd, Olof, Any changes in the policies? Do you allow now driver branches (with driver code) to be merged into DT branch? Best regards, Krzysztof
On Mon, May 15, 2023, at 18:22, neil.armstrong@linaro.org wrote: > On 15/05/2023 18:15, Krzysztof Kozlowski wrote: >> On 15/05/2023 18:13, Krzysztof Kozlowski wrote: >> >> Also one more argument maybe not relevant here but for other cases - >> this makes literally impossible to include the clock ID in DTS in the >> same kernel revision, because you must not merge driver branch to DTS >> branch. SoC folks were complaining about this many times. > > Actually we handle this very simply by having such patches merged in a immutable > branch merged in the clock and DT pull-requests, it worked perfectly so far > and neither Stephen or Arnd complained about that. It's usually benign if you just add a new clk at the end of the binding header, as that doesn't touch the internal header file in the same commit. I'm certainly happier about drivers that just use numbers from a datasheet instead of having to come up with numbers to stick in a binding because the hardware is entirely irregular, but there is usually no point trying to complain about bad hardware to the driver authors -- I unsterstand you are just trying to make things work. I agree with Krzysztof that using the same identifiers in the local header and in the binding is just making your life harder for no reason, and if you are the only ones doing it this way, it would help to change it. Maybe just add a namespace prefix to all the internal macros so the next time you move one into the documented bindings you can do it with the same immutable branch hack but not include the driver changes in the dt branch. Arnd
On 16/05/2023 10:44, Arnd Bergmann wrote: > On Mon, May 15, 2023, at 18:22, neil.armstrong@linaro.org wrote: >> On 15/05/2023 18:15, Krzysztof Kozlowski wrote: >>> On 15/05/2023 18:13, Krzysztof Kozlowski wrote: >>> >>> Also one more argument maybe not relevant here but for other cases - >>> this makes literally impossible to include the clock ID in DTS in the >>> same kernel revision, because you must not merge driver branch to DTS >>> branch. SoC folks were complaining about this many times. >> >> Actually we handle this very simply by having such patches merged in a immutable >> branch merged in the clock and DT pull-requests, it worked perfectly so far >> and neither Stephen or Arnd complained about that. > > It's usually benign if you just add a new clk at the end of the binding > header, as that doesn't touch the internal header file in the same > commit. I'm certainly happier about drivers that just use numbers from > a datasheet instead of having to come up with numbers to stick in a binding > because the hardware is entirely irregular, but there is usually no point > trying to complain about bad hardware to the driver authors -- I unsterstand > you are just trying to make things work. > > I agree with Krzysztof that using the same identifiers in the local > header and in the binding is just making your life harder for no > reason, and if you are the only ones doing it this way, it would > help to change it. Maybe just add a namespace prefix to all the internal > macros so the next time you move one into the documented bindings you > can do it with the same immutable branch hack but not include the > driver changes in the dt branch. Ack, I'll try to find a simple intermediate solution to avoid this situation. Thanks, Neil > > Arnd
On Tue 16 May 2023 at 11:00, Neil Armstrong <neil.armstrong@linaro.org> wrote: > On 16/05/2023 10:44, Arnd Bergmann wrote: >> On Mon, May 15, 2023, at 18:22, neil.armstrong@linaro.org wrote: >>> On 15/05/2023 18:15, Krzysztof Kozlowski wrote: >>>> On 15/05/2023 18:13, Krzysztof Kozlowski wrote: >>>> >>>> Also one more argument maybe not relevant here but for other cases - >>>> this makes literally impossible to include the clock ID in DTS in the >>>> same kernel revision, because you must not merge driver branch to DTS >>>> branch. SoC folks were complaining about this many times. >>> >>> Actually we handle this very simply by having such patches merged in a immutable >>> branch merged in the clock and DT pull-requests, it worked perfectly so far >>> and neither Stephen or Arnd complained about that. >> It's usually benign if you just add a new clk at the end of the binding >> header, as that doesn't touch the internal header file in the same >> commit. I'm certainly happier about drivers that just use numbers from >> a datasheet instead of having to come up with numbers to stick in a binding >> because the hardware is entirely irregular, but there is usually no point >> trying to complain about bad hardware to the driver authors -- I unsterstand >> you are just trying to make things work. >> I agree with Krzysztof that using the same identifiers in the local >> header and in the binding is just making your life harder for no >> reason, and if you are the only ones doing it this way, it would >> help to change it. Maybe just add a namespace prefix to all the internal >> macros so the next time you move one into the documented bindings you >> can do it with the same immutable branch hack but not include the >> driver changes in the dt branch. > > Ack, I'll try to find a simple intermediate solution to avoid this situation. I'd in favor of keeping things simple and just put all the IDs in the bindings. We have been doodling with the idea for while, I think now is the time > > Thanks, > Neil > >> Arnd
diff --git a/drivers/clk/meson/g12a.h b/drivers/clk/meson/g12a.h index a97613df38b3..1a4a626c2c63 100644 --- a/drivers/clk/meson/g12a.h +++ b/drivers/clk/meson/g12a.h @@ -168,7 +168,6 @@ #define CLKID_VID_PLL_SEL 130 #define CLKID_VID_PLL_DIV 131 #define CLKID_VCLK_SEL 132 -#define CLKID_VCLK2_SEL 133 #define CLKID_VCLK_INPUT 134 #define CLKID_VCLK2_INPUT 135 #define CLKID_VCLK_DIV 136 diff --git a/include/dt-bindings/clock/g12a-clkc.h b/include/dt-bindings/clock/g12a-clkc.h index a93b58c5e18e..80421d7982dd 100644 --- a/include/dt-bindings/clock/g12a-clkc.h +++ b/include/dt-bindings/clock/g12a-clkc.h @@ -108,6 +108,7 @@ #define CLKID_VAPB 124 #define CLKID_HDMI_PLL 128 #define CLKID_VID_PLL 129 +#define CLKID_VCLK2_SEL 133 #define CLKID_VCLK 138 #define CLKID_VCLK2 139 #define CLKID_VCLK_DIV1 148 @@ -149,5 +150,7 @@ #define CLKID_NNA_CORE_CLK 267 #define CLKID_MIPI_DSI_PXCLK_SEL 269 #define CLKID_MIPI_DSI_PXCLK 270 +#define CLKID_CTS_ENCL 271 +#define CLKID_CTS_ENCL_SEL 272 #endif /* __G12A_CLKC_H */