[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <92b6aa73-caef-85bb-6656-5e159ef7d237@linaro.org>
Date: Mon, 20 Feb 2023 11:39:50 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
linux-arm-msm@...r.kernel.org, andersson@...nel.org,
agross@...nel.org
Cc: marijn.suijten@...ainline.org, Rob Clark <robdclark@...il.com>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Krishna Manikandan <quic_mkrishn@...cinc.com>,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: display/msm: dsi-controller-main: Fix
deprecated QCM2290 compatible
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
>
Powered by blists - more mailing lists