Message ID | 20231231-hfpll-yaml-v1-2-359d44a4e194@z3ntu.xyz |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-13720-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp3549239dyb; Sun, 31 Dec 2023 06:59:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IG4MoYoscF61oDHt8xhop+ZUSW4qFmKATRNdUoCme1hyDlBH/VhUNg30a0pMgDWh+o/XJ6x X-Received: by 2002:a05:6871:5221:b0:204:3470:cb5f with SMTP id ht33-20020a056871522100b002043470cb5fmr19516603oac.11.1704034797161; Sun, 31 Dec 2023 06:59:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704034797; cv=none; d=google.com; s=arc-20160816; b=ej6O21pTVhWUCSBjrhTAWjYSrkhUf1mX7lkOlw8Td161xIA6g4Uwd4rN14jj5hQv8x WxatyKDHEnO12Z3lZGD8nRFeftzImtcGauzn2WWsDK02Dbjarri23/5TuABjcXXWLMsG zI7lAQDgHQ7Zdvu7HnAu3v+osBZ6+bENrZupelHQpGSUnNvh+EqBRSHkP5wM0OT7uGA6 G6x6W7yBt2tIJQYokfzK/0EkohtON3eOZtuoD3F6tGoiD9BFxc5XSQCmQ2cWzdL4R8PX p9bFfjvqSMa3SI0YZVsnr5NrNBFWL/TVpdewA41zkJ7mJ7MkZQ52K1epTqWEM/H0B0eq qt2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=wSyOdFTdtv/Uhk5OggPpzIbGKuK9kvUqhoZ7MPeeYPU=; fh=435oeUzm8B6dA3Uwhkcw0tvRk6eOGwwHs3WBATxTJL8=; b=QrQeciIu5trbeg3ocoBlLge+35JrPY1BssuihTH0RrgIsZcawfunb9fTwJzqUIbBGR 9mYM6p26Zax1bwtzgpA4JxD3wlbeloQGEIFAGv2KCnr89yhyLhsre4+tKZRi0ikHesEP 8E6NgKC1gJbO9j2eLcguVKz96Xh3LqQoTTIGVIZOs8VzuzS67+OO+BLZ23X0CV881vv9 a59xmY3TuI4wdRumUPUuxWbePBkwsQkdcdofmJ5LKHSViM1W0PP9ngubKgugcqd460eR mbSlWXC4YB9kmbJMGB3KPPeqq/m1tYZfxVIHJ6w+/Y/88giYTlnENxjtFMKs3W0MpB+h W+hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@z3ntu.xyz header.s=s1 header.b=Ou5J4XYS; spf=pass (google.com: domain of linux-kernel+bounces-13720-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13720-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=z3ntu.xyz Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id f8-20020a635548000000b005cd76cdafecsi14427705pgm.356.2023.12.31.06.59.57 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Dec 2023 06:59:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-13720-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@z3ntu.xyz header.s=s1 header.b=Ou5J4XYS; spf=pass (google.com: domain of linux-kernel+bounces-13720-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-13720-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=z3ntu.xyz Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5C5CD2831A5 for <ouuuleilei@gmail.com>; Sun, 31 Dec 2023 14:50:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 52CD2BA43; Sun, 31 Dec 2023 14:49:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=z3ntu.xyz header.i=@z3ntu.xyz header.b="Ou5J4XYS" X-Original-To: linux-kernel@vger.kernel.org Received: from ahti.lucaweiss.eu (ahti.lucaweiss.eu [128.199.32.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 491606111; Sun, 31 Dec 2023 14:49:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=z3ntu.xyz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=z3ntu.xyz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=z3ntu.xyz; s=s1; t=1704034144; bh=iV6I3JyGdTSjJ/OrFak2R6HQgtxg2qe0kijUxUTVvis=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Ou5J4XYSC3TSFaP2sssK4SiYloGxEvfUCt7YhFgumpljStm/Eh5ojEmXigQbfUvkL jLq9ml4FUWE8dOZgoYn6a0Ow/JtbrTXqIaokqhS5IQTWr2QY8Huq9VstDl0crZEo6F WUFN/V2QJm0hjUsLOMPXI2IfelRr0vX8K71FVdQU= From: Luca Weiss <luca@z3ntu.xyz> Date: Sun, 31 Dec 2023 15:48:44 +0100 Subject: [PATCH 2/3] clk: qcom: hfpll: Add QCS404-specific compatible Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231231-hfpll-yaml-v1-2-359d44a4e194@z3ntu.xyz> References: <20231231-hfpll-yaml-v1-0-359d44a4e194@z3ntu.xyz> In-Reply-To: <20231231-hfpll-yaml-v1-0-359d44a4e194@z3ntu.xyz> To: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> Cc: linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Weiss <luca@z3ntu.xyz> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=openpgp-sha256; l=1316; i=luca@z3ntu.xyz; h=from:subject:message-id; bh=iV6I3JyGdTSjJ/OrFak2R6HQgtxg2qe0kijUxUTVvis=; b=owEBbQKS/ZANAwAIAXLYQ7idTddWAcsmYgBlkX9dzudjUyNQvRt2uPyy5l+OT6HTDWBZeHFu1 ZgyaPxPoZyJAjMEAAEIAB0WIQQ5utIvCCzakboVj/py2EO4nU3XVgUCZZF/XQAKCRBy2EO4nU3X VvKMEACX638SAMzvEH1wjIhHAH5bKto2xRxgHfe8+IKZ/PiOSGw9TrUih7SfyLeMm+XRsckalm5 KF+GPBk8p4JgZ15lxafx8Ek7NPVca+7l/3cWGqwrRWI4FMdUbpNUsW5EbLhqI6sTKuLisbPvWfe 0UPk+J79pHo/4tBk0sZJGEQ5wMAX4vp8Yhce/e5h+w+axIr+UsqgZCbOV5G9yahxbKm6vDrLUxh IqNScMYuUvmEgAGFeEh1P0d/DM6sUC+efrCGauP6N7Yqq8Oyby20L8GIwhAZrbkmz3auVlUk1yi Crd3RnnN0ZcIAlcuS52sf5KMliyMQjJTFvb7jyYptassC6TRk6DISOj2FqJzEzms3rdCv6bbcTC aFinjx203/t4p2s0+Qz400TksxOge3bLJO7VlQo1vCqA4tgLslxoF4gi7ZtUjd3I3Xd5X1iqSW8 e0evDpIAtoWUz0PRpD84zVZaj17cUScUI/+vyCEJohOWQU1BASaV9q1eN3STvIc/GWWq+xQCnje UXrBFaGiXkGz45znuzWtNH9Ml+RqoB7T4YjXkLHO/6pZDwi/zg5/8H/NIjC3aw40zbbYhWZ1M78 d22DSQweZiphrJRrxogLgRwmuoZmsJsf+QI2qVkWEeAihaBcIZ+HY2lxZgsyJAWVQI1gg6uANd/ qbESMzYDMS4sexQ== X-Developer-Key: i=luca@z3ntu.xyz; a=openpgp; fpr=BD04DA24C971B8D587B2B8D7FAF69CF6CD2D02CD X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786809991762244696 X-GMAIL-MSGID: 1786809991762244696 |
Series |
Convert qcom,hfpll documentation to yaml + related changes
|
|
Commit Message
Luca Weiss
Dec. 31, 2023, 2:48 p.m. UTC
It doesn't appear that the configuration is for the HFPLL is generic, so
add a qcs404-specific compatible and rename the existing struct to
qcs404.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/clk/qcom/hfpll.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On 31/12/2023 15:48, Luca Weiss wrote: > It doesn't appear that the configuration is for the HFPLL is generic, so That's ok... > add a qcs404-specific compatible and rename the existing struct to but why this is the solution? If the qcom,hfpll compatible was deprecated, but it is not. This commit is contradictory to the bindings. > qcs404. > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz> > --- > drivers/clk/qcom/hfpll.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c > index dac27e31ef60..5b12982519be 100644 > --- a/drivers/clk/qcom/hfpll.c > +++ b/drivers/clk/qcom/hfpll.c > @@ -14,7 +14,7 @@ > #include "clk-regmap.h" > #include "clk-hfpll.h" > > -static const struct hfpll_data hdata = { > +static const struct hfpll_data qcs404 = { > .mode_reg = 0x00, > .l_reg = 0x04, > .m_reg = 0x08, > @@ -84,10 +84,12 @@ static const struct hfpll_data msm8976_cci = { > }; > > static const struct of_device_id qcom_hfpll_match_table[] = { > - { .compatible = "qcom,hfpll", .data = &hdata }, > { .compatible = "qcom,msm8976-hfpll-a53", .data = &msm8976_a53 }, > { .compatible = "qcom,msm8976-hfpll-a72", .data = &msm8976_a72 }, > { .compatible = "qcom,msm8976-hfpll-cci", .data = &msm8976_cci }, > + { .compatible = "qcom,qcs404-hfpll", .data = &qcs404 }, > + /* deprecated, use SoC-specific compatible */ Why? That's not a deprecated compatible. You now expect to create many unnecessary entries, which is not really needed. This is opposite of what we try to achieve with compatibility lists. Best regards, Krzysztof
On Dienstag, 2. Jänner 2024 11:41:26 CET Krzysztof Kozlowski wrote: > On 31/12/2023 15:48, Luca Weiss wrote: > > It doesn't appear that the configuration is for the HFPLL is generic, so > > That's ok... > > > add a qcs404-specific compatible and rename the existing struct to > > but why this is the solution? If the qcom,hfpll compatible was > deprecated, but it is not. This commit is contradictory to the bindings. > > > qcs404. > > > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz> > > --- > > > > drivers/clk/qcom/hfpll.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c > > index dac27e31ef60..5b12982519be 100644 > > --- a/drivers/clk/qcom/hfpll.c > > +++ b/drivers/clk/qcom/hfpll.c > > @@ -14,7 +14,7 @@ > > > > #include "clk-regmap.h" > > #include "clk-hfpll.h" > > > > -static const struct hfpll_data hdata = { > > +static const struct hfpll_data qcs404 = { > > > > .mode_reg = 0x00, > > .l_reg = 0x04, > > .m_reg = 0x08, > > > > @@ -84,10 +84,12 @@ static const struct hfpll_data msm8976_cci = { > > > > }; > > > > static const struct of_device_id qcom_hfpll_match_table[] = { > > > > - { .compatible = "qcom,hfpll", .data = &hdata }, > > > > { .compatible = "qcom,msm8976-hfpll-a53", .data = &msm8976_a53 }, > > { .compatible = "qcom,msm8976-hfpll-a72", .data = &msm8976_a72 }, > > { .compatible = "qcom,msm8976-hfpll-cci", .data = &msm8976_cci }, > > > > + { .compatible = "qcom,qcs404-hfpll", .data = &qcs404 }, > > + /* deprecated, use SoC-specific compatible */ > > Why? That's not a deprecated compatible. You now expect to create many > unnecessary entries, which is not really needed. This is opposite of > what we try to achieve with compatibility lists. Just "qcom,hfpll" is not allowed by the bindings. The problem is that it's actually unclear to me what "qcom,hfpll" was supposed to be currently. It was added originally for MSM8974 and friends (see git log) but then is currently only used by QCS404 while in QCS404 downstream msm-4.4 (I think it was 4.4) I see different driver data than what's here. So I wanted to just move what's used here to be qcs404-specific and then in an upcoming patch add a msm8974-specific compatible with different driver data. Also wouldn't the "don't extend driver lists when not neccessary" mean using something like "qcom,msm1234-hfpll", "qcom,qcs404-hfpll", "qcom,hfpll" then? That was kind of my idea if some other SoC can reuse e.g. qcs404 data? Regards Luca > > Best regards, > Krzysztof
On 06/01/2024 11:19, Luca Weiss wrote: > On Dienstag, 2. Jänner 2024 11:41:26 CET Krzysztof Kozlowski wrote: >> On 31/12/2023 15:48, Luca Weiss wrote: >>> It doesn't appear that the configuration is for the HFPLL is generic, so >> >> That's ok... >> >>> add a qcs404-specific compatible and rename the existing struct to >> >> but why this is the solution? If the qcom,hfpll compatible was >> deprecated, but it is not. This commit is contradictory to the bindings. >> >>> qcs404. >>> >>> Signed-off-by: Luca Weiss <luca@z3ntu.xyz> >>> --- >>> >>> drivers/clk/qcom/hfpll.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c >>> index dac27e31ef60..5b12982519be 100644 >>> --- a/drivers/clk/qcom/hfpll.c >>> +++ b/drivers/clk/qcom/hfpll.c >>> @@ -14,7 +14,7 @@ >>> >>> #include "clk-regmap.h" >>> #include "clk-hfpll.h" >>> >>> -static const struct hfpll_data hdata = { >>> +static const struct hfpll_data qcs404 = { >>> >>> .mode_reg = 0x00, >>> .l_reg = 0x04, >>> .m_reg = 0x08, >>> >>> @@ -84,10 +84,12 @@ static const struct hfpll_data msm8976_cci = { >>> >>> }; >>> >>> static const struct of_device_id qcom_hfpll_match_table[] = { >>> >>> - { .compatible = "qcom,hfpll", .data = &hdata }, >>> >>> { .compatible = "qcom,msm8976-hfpll-a53", .data = &msm8976_a53 }, >>> { .compatible = "qcom,msm8976-hfpll-a72", .data = &msm8976_a72 }, >>> { .compatible = "qcom,msm8976-hfpll-cci", .data = &msm8976_cci }, >>> >>> + { .compatible = "qcom,qcs404-hfpll", .data = &qcs404 }, >>> + /* deprecated, use SoC-specific compatible */ >> >> Why? That's not a deprecated compatible. You now expect to create many >> unnecessary entries, which is not really needed. This is opposite of >> what we try to achieve with compatibility lists. > > Just "qcom,hfpll" is not allowed by the bindings. Okay... sentence is correct but how is it related to the driver? > The problem is that it's actually unclear to me what "qcom,hfpll" was supposed > to be currently. It was added originally for MSM8974 and friends (see git log) > but then is currently only used by QCS404 while in QCS404 downstream msm-4.4 > (I think it was 4.4) I see different driver data than what's here. I discourage from using generic compatibles, because their meaning is too often fluid, but if we already have it then: it is supposed to be whatever driver and bindings defined it when they were added. > > So I wanted to just move what's used here to be qcs404-specific and then in an > upcoming patch add a msm8974-specific compatible with different driver data. > > Also wouldn't the "don't extend driver lists when not neccessary" mean using > something like "qcom,msm1234-hfpll", "qcom,qcs404-hfpll", "qcom,hfpll" then? qcs404 and hfpll are the same aren't they? Then why would third compatible appear? > That was kind of my idea if some other SoC can reuse e.g. qcs404 data? If any other SoC wants to reuse qcs404, why that SoC cannot use hfpll? If hfpll compatible is not correct, it should be deprecated, which is not happening in this patchset. Best regards, Krzysztof
diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c index dac27e31ef60..5b12982519be 100644 --- a/drivers/clk/qcom/hfpll.c +++ b/drivers/clk/qcom/hfpll.c @@ -14,7 +14,7 @@ #include "clk-regmap.h" #include "clk-hfpll.h" -static const struct hfpll_data hdata = { +static const struct hfpll_data qcs404 = { .mode_reg = 0x00, .l_reg = 0x04, .m_reg = 0x08, @@ -84,10 +84,12 @@ static const struct hfpll_data msm8976_cci = { }; static const struct of_device_id qcom_hfpll_match_table[] = { - { .compatible = "qcom,hfpll", .data = &hdata }, { .compatible = "qcom,msm8976-hfpll-a53", .data = &msm8976_a53 }, { .compatible = "qcom,msm8976-hfpll-a72", .data = &msm8976_a72 }, { .compatible = "qcom,msm8976-hfpll-cci", .data = &msm8976_cci }, + { .compatible = "qcom,qcs404-hfpll", .data = &qcs404 }, + /* deprecated, use SoC-specific compatible */ + { .compatible = "qcom,hfpll", .data = &qcs404 }, { } }; MODULE_DEVICE_TABLE(of, qcom_hfpll_match_table);