On 09/01/2023 11:51, Dmitry Baryshkov wrote: > On 09/01/2023 12:35, Krzysztof Kozlowski wrote: >> On 09/01/2023 01:52, Dmitry Baryshkov wrote: >>> Add (optional) core clock to the mdss bindings to let the MDSS driver >>> access harware registers before MDP driver probes. >>> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> >>> --- >>> .../bindings/display/msm/qcom,mdss.yaml | 34 ++++++++++++++----- >>> 1 file changed, 26 insertions(+), 8 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml >>> index ba0460268731..0647fc5a7d94 100644 >>> --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml >>> +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml >>> @@ -45,17 +45,11 @@ properties: >>> >>> clocks: >>> minItems: 1 >>> - items: >>> - - description: Display abh clock >>> - - description: Display axi clock >> >> Not related to this patch, but it is a bit surprising to see AXI clock >> optional. > > Hmm, There is one defined downstream. Probably we should fix that (but > yes, it's a separate issue). > >>> - - description: Display vsync clock >>> + maxItems: 4 >>> >>> clock-names: >>> minItems: 1 >>> - items: >>> - - const: iface >>> - - const: bus >>> - - const: vsync >>> + maxItems: 4 >>> >>> "#address-cells": >>> const: 1 >>> @@ -69,6 +63,30 @@ properties: >>> items: >>> - description: MDSS_CORE reset >>> >>> +oneOf: >>> + - properties: >>> + clocks: >>> + minItems: 3 >>> + maxItems: 4 >>> + >>> + clock-names: >>> + minItems: 3 >>> + items: >>> + - const: iface >>> + - const: bus >> >> BTW, sc7180-mdss uses here ahb name and calls it "AHB clock from dispcc". >> >> SM8250 won't match here either. Maybe this should be reworked to specify >> limits here but not the names and actual clocks? IOW, drop entire oneOf? > > SC7180 and SM8250 use platform-specific bindings (qcom,sc7180-mdss.yaml > and qcom,sm8250-mdss.yaml). This file is used only for older platforms > (msm8916, msm8996, etc). Ah, right. It's a bit confusing to have bindings split into files: 1. mdss-common 2. mdss 3. device specific but I guess fixing this would be another chunk of work. > >> >> There were a lot, a lot of changes to MDSS/DPU bindings recently, so I >> am really loosing track what is done where and when. >> >> There are also few separate patchsets from you on the lists. Could they >> be combined into one cleanup? > > Ack, I'll merge them into a single patchset. > >> I understand that sometimes new cleanup is needed after old cleanup >> finished (I had the same with pinctrl), so it is not a complain. >> >> Another problem (and this time I complain) is that several of your >> patchsets were sent, discussed and then without any notice applied. No >> message that a patchset was applied to some tree. Look: >> >> https://lore.kernel.org/all/20221124001708.25720-2-a39.skl@xxxxxxxxx/ >> https://lore.kernel.org/all/09ed16e1-4af2-8fce-dab4-f6c0f09e688c@xxxxxxxxxx/ >> >> Nothing. Silent application. If you are the maintainer which picks up >> the patch, please always, always send message that they are applied. >> Patchwork does it automatically, b4 can do it easily as well. If you use >> other tools - use other tools for sending it. Otherwise things are >> discussed on mailing lists, receive several comments and there is never >> a resubmit but instead they show in the tree. > > Unfortunately freedreno uses patchwork-fdo, which doesn't send > notifications. And the fdo fork is not supported by b4. I checked what > would be necessary to enable support in b4. Unfortunately several API > changes would be necessary. So this is a long process. But we are open > to any suggestions on how to improve the process. Currently all three > maintainers (Rob, Abhinav and me) keep the patch status in the > patchwork, but that's all. And how other freedesktop.org patchwork users notify? Manually or is there some hook? I notice only Exynos DRM where maintainer sends manual "Applied" messages. Best regards, Krzysztof
