[v2,1/2] dt-bindings: display/msm: dsi-controller-main: Fix deprecated QCM2290 compatible
Message ID | 20230217111316.306241-1-konrad.dybcio@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp832804wrn; Fri, 17 Feb 2023 03:29:30 -0800 (PST) X-Google-Smtp-Source: AK7set+PYyRKSg2g2KQFrcQKOhg7rvlzPOY5G8zmTSTw1J/rlRDn8ELLg1le4XL/tUeygJGegS8W X-Received: by 2002:a17:902:e845:b0:19b:c2d:1222 with SMTP id t5-20020a170902e84500b0019b0c2d1222mr4385437plg.52.1676633369860; Fri, 17 Feb 2023 03:29:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676633369; cv=none; d=google.com; s=arc-20160816; b=EPZXcJgh8p7Zi0VSt0eUxF9QHSIvqlAeL61y3Cx/95sBX/F5GhrY7+9DOkce4Vun0D AwgWfGofY1CLlgqb7bBskuvbB26p3Li0pDeHFTPrfcZHbZkH/TD5zJoe3YH+Z0vI0HdN qr0TPBJteg21HuBUBuqyF6zu0flHXm/lNUiT8iqlxzqAoK3oPYegvPy32xhQNQ7GCdTm bTHIAvocyh2/AXhwZ9lEY0MwyXroq+vZdrUGvECTSQuCFXNehjUW68GiWUTOXil4ZkOS 1YphkdDiDL1RrydeuiRtZ4rGo7gaDZhHLux30Dn8KLVAqOOpfymZR6T2AUyjzyyOOSjG 90zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=20OCfuLzA9fqgo8AT1mDWVtFNDiuNjsVIu2uoLHzxWk=; b=jxRGOQcqWu5Z+V3kjnUQ2iiKrjAq9mOoZ+qwqaNQan8A3NRtHBf+PQUNJPFJ8+ojtY 2R9OCcs0fALvx+5DkeB5X4yLsPeWyKAqBTuDQmBqroRNmHh/lAEWgHyTC8xaGSwZLlld vS25JfflYbW/FnMoGG/s9pvzp93p80EptnIuIYhSKcUOwYTyYKzqU1U3PTYVDEe9wvae fBaV9oM6ahH24CsRFpaiqW1djkXT6NQKAMTWKSrtyGpT3+bhAXCVJuzDHdKFZhJdbbFz x2uSwooRbDrv4kJ77DSHMWiw2A2j0B3hBeIKMv9iAOcL1X02X/8ngQwWdkDv3zQydMjv GEsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=M7B9dusj; 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 r136-20020a632b8e000000b004fbd2e67637si4216004pgr.624.2023.02.17.03.29.16; Fri, 17 Feb 2023 03:29:29 -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; dkim=pass header.i=@linaro.org header.s=google header.b=M7B9dusj; 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 S229893AbjBQLN6 (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Fri, 17 Feb 2023 06:13:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229756AbjBQLNx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 17 Feb 2023 06:13:53 -0500 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7538065368 for <linux-kernel@vger.kernel.org>; Fri, 17 Feb 2023 03:13:38 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id bi36so1039644lfb.6 for <linux-kernel@vger.kernel.org>; Fri, 17 Feb 2023 03:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=20OCfuLzA9fqgo8AT1mDWVtFNDiuNjsVIu2uoLHzxWk=; b=M7B9dusj6MIYmuDnw4a2+gkHtOEil5pVYeLlsyq0LtpccdoRJkVfAhfKtNG1wbNmgT Yx671npsFn+FMm+XEgqGdrr0U3yCjYo8GltBUXigdpmsl+gfVQMTefQrjVUqDP0m8akd mkqBdIFYbEmBbNObAt2vFzbJKot1qX5m3/NXq7YRTypAyFv7Pwp2JxIrudmJvK0QoZV8 OVm3wCu1WOdeW1ja5/iLUHMZnRnDAOPp/BYu60DfwqiXnTqN8w0WC0aWvRNnUE5PaIhf Dxm3z5FY4/x9+CySIcYZ8tNc0etWFFWxscTPmj3Y/WGCBEz33RRn8sQVXgUM6zEE8KfX fn9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=20OCfuLzA9fqgo8AT1mDWVtFNDiuNjsVIu2uoLHzxWk=; b=newctMS0VG+p3BBMoKzar6qtYvV1Li3ihFkvREGjo8FG8gf1JGpTMaVxMEGpl4LiqN HkvH6osShfv+3MkOumHhqi1gs60tYq7xaMhrBLkxIE+uDHPtlidjt87HiF82vzG/B1Q5 U6FDicB3z1Vpw1Auyr5dNaAvJvb796ZqiycL8/srDv6Zafo0MM0k/MkAlxNWJhTwy+Zb 6UsDp+4xWHUI0w4m4pUFMVc+xKGxSoraeqvWYnAPKL2DySh5DUpvy7ofmQlZ11TRJXws VDPPsfBUt+OWUsPRcEIMUO+kH0hZ0LDfTENevt6jf+E0V3TH1PuXi0qsaDNKTLq4Bspm G7HA== X-Gm-Message-State: AO0yUKXC/uW1wtyLHJZ3npr9+rzOakpsKDnzXAtlbCANjw0pkmld5sI5 Qi/dSxaaX4sgw/MxI+pygklcPA== X-Received: by 2002:ac2:598b:0:b0:4dc:8510:bfed with SMTP id w11-20020ac2598b000000b004dc8510bfedmr327637lfn.65.1676632399844; Fri, 17 Feb 2023 03:13:19 -0800 (PST) Received: from localhost.localdomain (abxh117.neoplus.adsl.tpnet.pl. [83.9.1.117]) by smtp.gmail.com with ESMTPSA id h11-20020ac250cb000000b004b564e1a4e0sm642683lfm.76.2023.02.17.03.13.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Feb 2023 03:13:19 -0800 (PST) From: Konrad Dybcio <konrad.dybcio@linaro.org> To: linux-arm-msm@vger.kernel.org, andersson@kernel.org, agross@kernel.org Cc: marijn.suijten@somainline.org, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Clark <robdclark@gmail.com>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Sean Paul <sean@poorly.run>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Krishna Manikandan <quic_mkrishn@quicinc.com>, "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/2] dt-bindings: display/msm: dsi-controller-main: Fix deprecated QCM2290 compatible Date: Fri, 17 Feb 2023 12:13:15 +0100 Message-Id: <20230217111316.306241-1-konrad.dybcio@linaro.org> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 autolearn=unavailable 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?1758077512184573954?= X-GMAIL-MSGID: =?utf-8?q?1758077512184573954?= |
Series |
[v2,1/2] dt-bindings: display/msm: dsi-controller-main: Fix deprecated QCM2290 compatible
|
|
Commit Message
Konrad Dybcio
Feb. 17, 2023, 11:13 a.m. UTC
SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290",
without the generic fallback. Fix the deprecated binding to reflect
that.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Depends on (and should have been a part of):
https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dybcio@linaro.org/
v1 -> v2:
New patch
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 -
1 file changed, 1 deletion(-)
Comments
On 17/02/2023 12:13, Konrad Dybcio wrote: > SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290", > without the generic fallback. Fix the deprecated binding to reflect > that. > > Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > Depends on (and should have been a part of): > > https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dybcio@linaro.org/ > > v1 -> v2: > New patch > > .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > index 41cdb631d305..ee19d780dea8 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml > @@ -37,7 +37,6 @@ properties: > - items: If this way stays, drop the items as it is just an enum. > - enum: > - qcom,dsi-ctrl-6g-qcm2290 > - - const: qcom,mdss-dsi-ctrl Wasn't then intention to deprecate both - qcm2290 and mdss - when used alone? Best regards, Krzysztof
On 17.02.2023 12:30, Krzysztof Kozlowski wrote: > On 17/02/2023 12:13, Konrad Dybcio wrote: >> SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290", >> without the generic fallback. Fix the deprecated binding to reflect >> that. >> >> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> --- >> Depends on (and should have been a part of): >> >> https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dybcio@linaro.org/ >> >> v1 -> v2: >> New patch >> >> .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >> index 41cdb631d305..ee19d780dea8 100644 >> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >> @@ -37,7 +37,6 @@ properties: >> - items: > > If this way stays, drop the items as it is just an enum. > >> - enum: >> - qcom,dsi-ctrl-6g-qcm2290 >> - - const: qcom,mdss-dsi-ctrl > > Wasn't then intention to deprecate both - qcm2290 and mdss - when used > alone? "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" was never used. The only upstream usage of the 2290 compat is in sm6115.dtsi: compatible = "qcom,dsi-ctrl-6g-qcm2290"; https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221 Konrad > > > Best regards, > Krzysztof >
On 17/02/2023 12:32, Konrad Dybcio wrote: > > > On 17.02.2023 12:30, Krzysztof Kozlowski wrote: >> On 17/02/2023 12:13, Konrad Dybcio wrote: >>> SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290", >>> without the generic fallback. Fix the deprecated binding to reflect >>> that. >>> >>> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>> --- >>> Depends on (and should have been a part of): >>> >>> https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dybcio@linaro.org/ >>> >>> v1 -> v2: >>> New patch >>> >>> .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >>> index 41cdb631d305..ee19d780dea8 100644 >>> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >>> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >>> @@ -37,7 +37,6 @@ properties: >>> - items: >> >> If this way stays, drop the items as it is just an enum. >> >>> - enum: >>> - qcom,dsi-ctrl-6g-qcm2290 >>> - - const: qcom,mdss-dsi-ctrl >> >> Wasn't then intention to deprecate both - qcm2290 and mdss - when used >> alone? > "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" > > was never used. The only upstream usage of the 2290 compat > is in sm6115.dtsi: > > compatible = "qcom,dsi-ctrl-6g-qcm2290"; > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221 I meant, that original commit wanted to deprecate: compatible="qcom,dsi-ctrl-6g-qcm2290"; compatible="qcom,mdss-dsi-ctrl"; Best regards, Krzysztof
On 17.02.2023 12:35, Krzysztof Kozlowski wrote: > On 17/02/2023 12:32, Konrad Dybcio wrote: >> >> >> On 17.02.2023 12:30, Krzysztof Kozlowski wrote: >>> On 17/02/2023 12:13, Konrad Dybcio wrote: >>>> SM6115 previously erroneously added just "qcom,dsi-ctrl-6g-qcm2290", >>>> without the generic fallback. Fix the deprecated binding to reflect >>>> that. >>>> >>>> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>> --- >>>> Depends on (and should have been a part of): >>>> >>>> https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dybcio@linaro.org/ >>>> >>>> v1 -> v2: >>>> New patch >>>> >>>> .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >>>> index 41cdb631d305..ee19d780dea8 100644 >>>> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >>>> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml >>>> @@ -37,7 +37,6 @@ properties: >>>> - items: >>> >>> If this way stays, drop the items as it is just an enum. >>> >>>> - enum: >>>> - qcom,dsi-ctrl-6g-qcm2290 >>>> - - const: qcom,mdss-dsi-ctrl >>> >>> Wasn't then intention to deprecate both - qcm2290 and mdss - when used >>> alone? >> "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" >> >> was never used. The only upstream usage of the 2290 compat >> is in sm6115.dtsi: >> >> compatible = "qcom,dsi-ctrl-6g-qcm2290"; >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221 > > I meant, that original commit wanted to deprecate: > compatible="qcom,dsi-ctrl-6g-qcm2290"; > compatible="qcom,mdss-dsi-ctrl"; > Okay, so what would be the correct resolution? Drop this patch and keep 2/2? Konrad > Best regards, > Krzysztof >
On 17/02/2023 12:36, Konrad Dybcio wrote: >>> >>> compatible = "qcom,dsi-ctrl-6g-qcm2290"; >>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221 >> >> I meant, that original commit wanted to deprecate: >> compatible="qcom,dsi-ctrl-6g-qcm2290"; >> compatible="qcom,mdss-dsi-ctrl"; >> > Okay, so what would be the correct resolution? > Drop this patch and keep 2/2? First, it would be nice to know what was the intention of Bryan's commit? Second, if the intention was to deprecate both of these, then this commit could stay with changes - make it enum for both compatibles (not list). Best regards, Krzysztof
On 17.02.2023 13:24, Krzysztof Kozlowski wrote: > On 17/02/2023 12:36, Konrad Dybcio wrote: >>>> >>>> compatible = "qcom,dsi-ctrl-6g-qcm2290"; >>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sm6115.dtsi?h=next-20230217#n1221 >>> >>> I meant, that original commit wanted to deprecate: >>> compatible="qcom,dsi-ctrl-6g-qcm2290"; >>> compatible="qcom,mdss-dsi-ctrl"; >>> >> Okay, so what would be the correct resolution? >> Drop this patch and keep 2/2? > > First, it would be nice to know what was the intention of Bryan's commit? AFAICT, it was necessary to add per-SoC compatibles to all DSI hosts to make documenting clocks possible (they differ per-platform). The qcm2290 deprecation came from the oddity of the compatible name (it did not match qcom,socname-hw), but he seems to have overlooked that (at least before my recent patchset [1]), it was necessary as it needed to circumvent part of the driver's logic. So it was first made up-to-speed with the rest by adding the fallback common compatible and then (wrongly) deprecated. Then, SM6115 DSI DTS part was added parallel to that, so he did not update it. With [1] its deprecation is correct and this series tries to complete it. Konrad [1] https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dybcio@linaro.org/ > > Second, if the intention was to deprecate both of these, then this > commit could stay with changes - make it enum for both compatibles (not > list). > > Best regards, > Krzysztof >
On 17/02/2023 12:24, Krzysztof Kozlowski wrote:
> First, it would be nice to know what was the intention of Bryan's commit?
Sorry I've been grazing this thread but, not responding.
- qcom,dsi-ctrl-6g-qcm2290
is non-compliant with qcom,socid-dsi-ctrl which is our desired naming
convention, so that's what the deprecation is about i.e. moving this
compat to "qcom,qcm2290-dsi-ctrl"
Actually I have the question why we are deciding to go with "sm6115"
instead of "qcm2290" ?
The stamp on the package you receive from Thundercomm says "qcm2290" not
"sm6115"
?
---
bod
On 17.02.2023 22:13, Bryan O'Donoghue wrote: > On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >> First, it would be nice to know what was the intention of Bryan's commit? > > Sorry I've been grazing this thread but, not responding. > > - qcom,dsi-ctrl-6g-qcm2290 > > is non-compliant with qcom,socid-dsi-ctrl which is our desired naming convention, so that's what the deprecation is about i.e. moving this compat to "qcom,qcm2290-dsi-ctrl" > > Actually I have the question why we are deciding to go with "sm6115" instead of "qcm2290" ? > > The stamp on the package you receive from Thundercomm says "qcm2290" not "sm6115" Correct, but QCM2290 is not supported upstream yet. SM6115 (a different SoC) however is, but it used the qcm2290 compatible as it was a convenient hack to get the DSI host ID recognized based on the (identical-to-qcm2290) base register without additional driver changes. We're now trying to untangle that mess.. Konrad > > ? > > --- > bod > >
On 17/02/2023 21:16, Konrad Dybcio wrote: > Correct, but QCM2290 is not supported upstream yet. > > SM6115 (a different SoC) however is, but it used the qcm2290 compatible > as it was a convenient hack to get the DSI host ID recognized based on > the (identical-to-qcm2290) base register without additional driver changes. > We're now trying to untangle that mess.. Gand so what we want documented is: compatible = "qcom,qcs2290-dsi-ctrl", qcom,mdss-dsi-ctrl"; compatible = "qcom,sm6115-dsi-ctrl", qcom,mdss-dsi-ctrl"; with the old compatible = "qcom,dsi-ctrl-6g-qcm2290"; clanger continuing to be deprecated. --- bod
On 17.02.2023 22:20, Bryan O'Donoghue wrote: > On 17/02/2023 21:16, Konrad Dybcio wrote: >> Correct, but QCM2290 is not supported upstream yet. >> >> SM6115 (a different SoC) however is, but it used the qcm2290 compatible >> as it was a convenient hack to get the DSI host ID recognized based on >> the (identical-to-qcm2290) base register without additional driver changes. >> We're now trying to untangle that mess.. > > Gand so what we want documented is: > > compatible = "qcom,qcs2290-dsi-ctrl", qcom,mdss-dsi-ctrl"; qcm* yes, this became documented with your original cleanup > compatible = "qcom,sm6115-dsi-ctrl", qcom,mdss-dsi-ctrl"; and yes this became documented (well, in the DSI binding) in my other patch series and is finished being documented in this one > > with the old compatible = "qcom,dsi-ctrl-6g-qcm2290"; clanger continuing to be deprecated. correct, we still have to note it but keep it deprecated Konrad > > --- > bod
On 17/02/2023 21:23, Konrad Dybcio wrote: > > > On 17.02.2023 22:20, Bryan O'Donoghue wrote: >> On 17/02/2023 21:16, Konrad Dybcio wrote: >>> Correct, but QCM2290 is not supported upstream yet. >>> >>> SM6115 (a different SoC) however is, but it used the qcm2290 compatible >>> as it was a convenient hack to get the DSI host ID recognized based on >>> the (identical-to-qcm2290) base register without additional driver changes. >>> We're now trying to untangle that mess.. >> >> Gand so what we want documented is: >> >> compatible = "qcom,qcs2290-dsi-ctrl", qcom,mdss-dsi-ctrl"; > qcm* yes, this became documented with your original cleanup > >> compatible = "qcom,sm6115-dsi-ctrl", qcom,mdss-dsi-ctrl"; > and yes this became documented (well, in the DSI binding) in > my other patch series and is finished being documented in this one > >> >> with the old compatible = "qcom,dsi-ctrl-6g-qcm2290"; clanger continuing to be deprecated. > correct, we still have to note it but keep it deprecated > > Konrad >> >> --- >> bod Cool. That maps to my understanding & the intention of the deprecation. --- bod
On 17/02/2023 22:13, Bryan O'Donoghue wrote: > On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >> First, it would be nice to know what was the intention of Bryan's commit? > > Sorry I've been grazing this thread but, not responding. > > - qcom,dsi-ctrl-6g-qcm2290 > > is non-compliant with qcom,socid-dsi-ctrl which is our desired naming > convention, so that's what the deprecation is about i.e. moving this > compat to "qcom,qcm2290-dsi-ctrl" OK, then there was no intention to deprecate qcom,mdss-dsi-ctrl and it should be left as allowed compatible. Best regards, Krzysztof
On 18.02.2023 11:14, Krzysztof Kozlowski wrote: > On 17/02/2023 22:13, Bryan O'Donoghue wrote: >> On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >>> First, it would be nice to know what was the intention of Bryan's commit? >> >> Sorry I've been grazing this thread but, not responding. >> >> - qcom,dsi-ctrl-6g-qcm2290 >> >> is non-compliant with qcom,socid-dsi-ctrl which is our desired naming >> convention, so that's what the deprecation is about i.e. moving this >> compat to "qcom,qcm2290-dsi-ctrl" > > OK, then there was no intention to deprecate qcom,mdss-dsi-ctrl and it > should be left as allowed compatible. Not sure if we're on the same page. It wasn't intended to deprecate [1] "qcom,qcm2290-dsi-ctrl", "qcom-mdss-dsi-ctrl"; (newly-introduced in Bryan's cleanup patchset) but it was intended to deprecate [2] "qcom,dsi-ctrl-6g-qcm2290"; which was introduced long before that *and* used in the 6115 dt (and it still is in linux-next today, as my cleanup hasn't landed yet). [3] "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" was never used (and should never be, considering there's a proper compatible [1] now) so adding it to bindings didn't solve the undocumented-ness issue. Plus the fallback would have never worked back then, as the DSI hw revision check would spit out 2.4.1 or 2.4. which is SC7180 or SDM845 and then it would never match the base register, as they're waay different. Konrad > > Best regards, > Krzysztof >
On 18/02/2023 12:23, Konrad Dybcio wrote: > > > On 18.02.2023 11:14, Krzysztof Kozlowski wrote: >> On 17/02/2023 22:13, Bryan O'Donoghue wrote: >>> On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >>>> First, it would be nice to know what was the intention of Bryan's commit? >>> >>> Sorry I've been grazing this thread but, not responding. >>> >>> - qcom,dsi-ctrl-6g-qcm2290 >>> >>> is non-compliant with qcom,socid-dsi-ctrl which is our desired naming >>> convention, so that's what the deprecation is about i.e. moving this >>> compat to "qcom,qcm2290-dsi-ctrl" >> >> OK, then there was no intention to deprecate qcom,mdss-dsi-ctrl and it >> should be left as allowed compatible. > Not sure if we're on the same page. We are. > > It wasn't intended to deprecate [1] "qcom,qcm2290-dsi-ctrl", "qcom-mdss-dsi-ctrl"; > (newly-introduced in Bryan's cleanup patchset) but it was intended to deprecate > [2] "qcom,dsi-ctrl-6g-qcm2290"; which was introduced long before that *and* used in > the 6115 dt (and it still is in linux-next today, as my cleanup hasn't landed yet). > > [3] "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" was never used (and should never > be, considering there's a proper compatible [1] now) so adding it to bindings > didn't solve the undocumented-ness issue. Plus the fallback would have never > worked back then, as the DSI hw revision check would spit out 2.4.1 or 2.4. > which is SC7180 or SDM845 and then it would never match the base register, as > they're waay different. All these were known. I was asking about "qcom,mdss-dsi-ctrl", because the original intention also affects the way we want to keep it now (unless there are other reasons). Best regards, Krzysztof
On 18.02.2023 15:49, Krzysztof Kozlowski wrote: > On 18/02/2023 12:23, Konrad Dybcio wrote: >> >> >> On 18.02.2023 11:14, Krzysztof Kozlowski wrote: >>> On 17/02/2023 22:13, Bryan O'Donoghue wrote: >>>> On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >>>>> First, it would be nice to know what was the intention of Bryan's commit? >>>> >>>> Sorry I've been grazing this thread but, not responding. >>>> >>>> - qcom,dsi-ctrl-6g-qcm2290 >>>> >>>> is non-compliant with qcom,socid-dsi-ctrl which is our desired naming >>>> convention, so that's what the deprecation is about i.e. moving this >>>> compat to "qcom,qcm2290-dsi-ctrl" >>> >>> OK, then there was no intention to deprecate qcom,mdss-dsi-ctrl and it >>> should be left as allowed compatible. >> Not sure if we're on the same page. > > We are. > >> >> It wasn't intended to deprecate [1] "qcom,qcm2290-dsi-ctrl", "qcom-mdss-dsi-ctrl"; >> (newly-introduced in Bryan's cleanup patchset) but it was intended to deprecate >> [2] "qcom,dsi-ctrl-6g-qcm2290"; which was introduced long before that *and* used in >> the 6115 dt (and it still is in linux-next today, as my cleanup hasn't landed yet). >> >> [3] "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" was never used (and should never >> be, considering there's a proper compatible [1] now) so adding it to bindings >> didn't solve the undocumented-ness issue. Plus the fallback would have never >> worked back then, as the DSI hw revision check would spit out 2.4.1 or 2.4. >> which is SC7180 or SDM845 and then it would never match the base register, as >> they're waay different. > > All these were known. I was asking about "qcom,mdss-dsi-ctrl", because > the original intention also affects the way we want to keep it now > (unless there are other reasons). Okay, so we want to deprecate: "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" because it is: 1) non-compliant with the qcom,socname-hwblock formula 2) replaceable since we rely on the fallback compatible 3) "qcom,dsi-ctrl-6g-qcm2290" alone would have been expected to be fixed in the DTSI similar to other SoCs Is that correct? Because 2) doesn't hold, as - at the time of the introduction of Bryan's patchset - the fallback compatible would not have been sufficient from the Linux POV [1], though it would have been sufficient from the hardware description POV, as the hardware on the SoC *is* essentially what qcom,mdss-dsi-ctrl refers to. [1] The driver would simply not probe. It *would be* Linux-correct after my code-fixing series was applied, but I think I'm just failing to comprehend what sort of ABI we're trying to preserve here :/ Konrad > > Best regards, > Krzysztof >
On 20/02/2023 11:24, Konrad Dybcio wrote: > > > On 18.02.2023 15:49, Krzysztof Kozlowski wrote: >> On 18/02/2023 12:23, Konrad Dybcio wrote: >>> >>> >>> On 18.02.2023 11:14, Krzysztof Kozlowski wrote: >>>> On 17/02/2023 22:13, Bryan O'Donoghue wrote: >>>>> On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >>>>>> First, it would be nice to know what was the intention of Bryan's commit? >>>>> >>>>> Sorry I've been grazing this thread but, not responding. >>>>> >>>>> - qcom,dsi-ctrl-6g-qcm2290 >>>>> >>>>> is non-compliant with qcom,socid-dsi-ctrl which is our desired naming >>>>> convention, so that's what the deprecation is about i.e. moving this >>>>> compat to "qcom,qcm2290-dsi-ctrl" >>>> >>>> OK, then there was no intention to deprecate qcom,mdss-dsi-ctrl and it >>>> should be left as allowed compatible. >>> Not sure if we're on the same page. >> >> We are. >> >>> >>> It wasn't intended to deprecate [1] "qcom,qcm2290-dsi-ctrl", "qcom-mdss-dsi-ctrl"; >>> (newly-introduced in Bryan's cleanup patchset) but it was intended to deprecate >>> [2] "qcom,dsi-ctrl-6g-qcm2290"; which was introduced long before that *and* used in >>> the 6115 dt (and it still is in linux-next today, as my cleanup hasn't landed yet). >>> >>> [3] "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" was never used (and should never >>> be, considering there's a proper compatible [1] now) so adding it to bindings >>> didn't solve the undocumented-ness issue. Plus the fallback would have never >>> worked back then, as the DSI hw revision check would spit out 2.4.1 or 2.4. >>> which is SC7180 or SDM845 and then it would never match the base register, as >>> they're waay different. >> >> All these were known. I was asking about "qcom,mdss-dsi-ctrl", because >> the original intention also affects the way we want to keep it now >> (unless there are other reasons). > Okay, so we want to deprecate: > > "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" No, we don't want to deprecate it. Such compatible was never existing originally and was only introduced by mistake. We want to correct the mistake, but we don't want to deprecate such list. > > because it is: > > 1) non-compliant with the qcom,socname-hwblock formula > 2) replaceable since we rely on the fallback compatible > 3) "qcom,dsi-ctrl-6g-qcm2290" alone would have been expected to > be fixed in the DTSI similar to other SoCs > > Is that correct? No. So again, I am talking only about qcom,mdss-dsi-ctrl. Since beginning of this thread: "Wasn't then intention to deprecate both - qcm2290 and mdss - when used alone?" Why do you bring the list to the topic? The list was created by mistake and Bryan confirmed that it was never his intention. > > Because 2) doesn't hold, as - at the time of the introduction > of Bryan's patchset - the fallback compatible would not have > been sufficient from the Linux POV [1] There was no fallback compatible at that time. > , though it would have been > sufficient from the hardware description POV, as the hardware > on the SoC *is* essentially what qcom,mdss-dsi-ctrl refers to. > > [1] The driver would simply not probe. It *would be* Linux-correct > after my code-fixing series was applied, but I think I'm just failing > to comprehend what sort of ABI we're trying to preserve here :/ Best regards, Krzysztof
On 20.02.2023 11:31, Krzysztof Kozlowski wrote: > On 20/02/2023 11:24, Konrad Dybcio wrote: >> >> >> On 18.02.2023 15:49, Krzysztof Kozlowski wrote: >>> On 18/02/2023 12:23, Konrad Dybcio wrote: >>>> >>>> >>>> On 18.02.2023 11:14, Krzysztof Kozlowski wrote: >>>>> On 17/02/2023 22:13, Bryan O'Donoghue wrote: >>>>>> On 17/02/2023 12:24, Krzysztof Kozlowski wrote: >>>>>>> First, it would be nice to know what was the intention of Bryan's commit? >>>>>> >>>>>> Sorry I've been grazing this thread but, not responding. >>>>>> >>>>>> - qcom,dsi-ctrl-6g-qcm2290 >>>>>> >>>>>> is non-compliant with qcom,socid-dsi-ctrl which is our desired naming >>>>>> convention, so that's what the deprecation is about i.e. moving this >>>>>> compat to "qcom,qcm2290-dsi-ctrl" >>>>> >>>>> OK, then there was no intention to deprecate qcom,mdss-dsi-ctrl and it >>>>> should be left as allowed compatible. >>>> Not sure if we're on the same page. >>> >>> We are. >>> >>>> >>>> It wasn't intended to deprecate [1] "qcom,qcm2290-dsi-ctrl", "qcom-mdss-dsi-ctrl"; >>>> (newly-introduced in Bryan's cleanup patchset) but it was intended to deprecate >>>> [2] "qcom,dsi-ctrl-6g-qcm2290"; which was introduced long before that *and* used in >>>> the 6115 dt (and it still is in linux-next today, as my cleanup hasn't landed yet). >>>> >>>> [3] "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" was never used (and should never >>>> be, considering there's a proper compatible [1] now) so adding it to bindings >>>> didn't solve the undocumented-ness issue. Plus the fallback would have never >>>> worked back then, as the DSI hw revision check would spit out 2.4.1 or 2.4. >>>> which is SC7180 or SDM845 and then it would never match the base register, as >>>> they're waay different. >>> >>> All these were known. I was asking about "qcom,mdss-dsi-ctrl", because >>> the original intention also affects the way we want to keep it now >>> (unless there are other reasons). >> Okay, so we want to deprecate: >> >> "qcom,dsi-ctrl-6g-qcm2290", "qcom,mdss-dsi-ctrl" > > No, we don't want to deprecate it. Such compatible was never existing > originally and was only introduced by mistake. We want to correct the > mistake, but we don't want to deprecate such list. > >> >> because it is: >> >> 1) non-compliant with the qcom,socname-hwblock formula >> 2) replaceable since we rely on the fallback compatible >> 3) "qcom,dsi-ctrl-6g-qcm2290" alone would have been expected to >> be fixed in the DTSI similar to other SoCs >> >> Is that correct? > > No. So again, I am talking only about qcom,mdss-dsi-ctrl. Since > beginning of this thread: > > "Wasn't then intention to deprecate both - qcm2290 and mdss - when used > alone?" > > Why do you bring the list to the topic? The list was created by mistake > and Bryan confirmed that it was never his intention. Ugh.. I think I just misread your message in your second reply counting from the beginning of the thread.. Things are much clearer now that I re-read it.. So, just to confirm.. This patch, with the items: level dropped, is fine? Konrad > >> >> Because 2) doesn't hold, as - at the time of the introduction >> of Bryan's patchset - the fallback compatible would not have >> been sufficient from the Linux POV [1] > > There was no fallback compatible at that time. > >> , though it would have been >> sufficient from the hardware description POV, as the hardware >> on the SoC *is* essentially what qcom,mdss-dsi-ctrl refers to. >> >> [1] The driver would simply not probe. It *would be* Linux-correct >> after my code-fixing series was applied, but I think I'm just failing >> to comprehend what sort of ABI we're trying to preserve here :/ > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 41cdb631d305..ee19d780dea8 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -37,7 +37,6 @@ properties: - items: - enum: - qcom,dsi-ctrl-6g-qcm2290 - - const: qcom,mdss-dsi-ctrl deprecated: true reg: