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 >
