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
