Message ID | 20200130211231.224656-1-dianders@chromium.org |
---|---|
Headers | show |
Series | clk: qcom: Fix parenting for dispcc/gpucc/videocc | expand |
On Thu, Jan 30, 2020 at 3:12 PM Douglas Anderson <dianders@chromium.org> wrote: > > The qcom,dispcc bindings had a few problems with them: > > 1. They didn't specify all the clocks that dispcc is a client of. > Specifically on sc7180 there are two clocks from the DSI PHY and > two from the DP PHY. On sdm845 there are actually two DSI PHYs > (each of which has two clocks) and an extra clock from the gcc. > These all need to be specified. > > 2. The sdm845.dtsi has existed for quite some time without specifying > the clocks. The Linux driver was relying on global names to match > things up. While we should transition things, it should be noted > in the bindings. > > 3. The names used the bindings for "xo" and "gpll0" didn't match the > names that QC used for these clocks internally and this was causing > confusion / difficulty with their code generation tools. Switched > to the internal names to simplify everyone's lives. It's not quite > as clean in a purist sense but it should avoid headaches. This > officially changes the binding, but that seems OK in this case. > > Also note that I updated the example. > > Fixes: 5d28e44ba630 ("dt-bindings: clock: Add YAML schemas for the QCOM DISPCC clock bindings") > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > Changes in v3: > - Added include file to description. > - Discovered / added new gcc input clock on sdm845. > - Split sc7180 and sdm845 into two files. > - Switched names to internal QC names rather than logical ones. > - Updated commit description. > > Changes in v2: > - Patch ("dt-bindings: clock: Fix qcom,dispcc...") new for v2. > > .../bindings/clock/qcom,dispcc.yaml | 67 ------------- > .../bindings/clock/qcom,sc7180-dispcc.yaml | 84 ++++++++++++++++ > .../bindings/clock/qcom,sdm845-dispcc.yaml | 99 +++++++++++++++++++ > 3 files changed, 183 insertions(+), 67 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/qcom,dispcc.yaml > create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml > create mode 100644 Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml Other than the same $id problem, Reviewed-by: Rob Herring <robh@kernel.org>
Hi, On Fri, Jan 31, 2020 at 8:43 AM Rob Herring <robh@kernel.org> wrote: > > On Thu, Jan 30, 2020 at 3:12 PM Douglas Anderson <dianders@chromium.org> wrote: > > > > The qcom,gpucc bindings had a few problems with them: > > > > 1. When things were converted to yaml the name of the "gpll0 main" > > clock got changed from "gpll0" to "gpll0_main". Change it back for > > msm8998. > > > > 2. Apparently there is a push not to use purist aliases for clocks but > > instead to just use the internal Qualcomm names. For sdm845 and > > sc7180 (where the drivers haven't already been changed) move in > > this direction. > > > > Things were also getting complicated harder to deal with by jamming > > several SoCs into one file. Splitting simplifies things. > > > > Fixes: 5c6f3a36b913 ("dt-bindings: clock: Add YAML schemas for the QCOM GPUCC clock bindings") > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > > > Changes in v3: > > - Added pointer to inlude file in description. > > - Everyone but msm8998 now uses internal QC names. > > - Fixed typo grpahics => graphics > > - Split bindings into 3 files. > > > > Changes in v2: > > - Patch ("dt-bindings: clock: Fix qcom,gpucc...") new for v2. > > > > .../devicetree/bindings/clock/qcom,gpucc.yaml | 72 ------------------- > > .../bindings/clock/qcom,msm8998-gpucc.yaml | 66 +++++++++++++++++ > > .../bindings/clock/qcom,sc7180-gpucc.yaml | 72 +++++++++++++++++++ > > .../bindings/clock/qcom,sdm845-gpucc.yaml | 72 +++++++++++++++++++ > > 4 files changed, 210 insertions(+), 72 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc.yaml > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml > > I'm not seeing any differences in sdm845 and sc7180. Do those really > need to be separate? It doesn't have to be all combined or all > separate. They are the same, other than pointing to a different #include file. I debated whether to put them in one file (arbitrarily named after one SoC or the other) or to put them in individual files. I got the impression from Stephen that he'd prefer them to be separate files even in the case that they were 99% identical, but I certainly could have misunderstood. I'll do whatever you guys agree to. If you want them in one file I'll probably name it "qcom,sdm845-gpucc.yaml" just because that SoC is earlier, unless someone tells me otherwise. -Doug
Hi, On Mon, Feb 3, 2020 at 8:29 AM Stephen Boyd <sboyd@kernel.org> wrote: > > Quoting Doug Anderson (2020-01-31 08:48:37) > > Hi, > > > > On Fri, Jan 31, 2020 at 8:43 AM Rob Herring <robh@kernel.org> wrote: > > > > > > On Thu, Jan 30, 2020 at 3:12 PM Douglas Anderson <dianders@chromium.org> wrote: > > > > > > > > The qcom,gpucc bindings had a few problems with them: > > > > > > > > 1. When things were converted to yaml the name of the "gpll0 main" > > > > clock got changed from "gpll0" to "gpll0_main". Change it back for > > > > msm8998. > > > > > > > > 2. Apparently there is a push not to use purist aliases for clocks but > > > > instead to just use the internal Qualcomm names. For sdm845 and > > > > sc7180 (where the drivers haven't already been changed) move in > > > > this direction. > > > > > > > > Things were also getting complicated harder to deal with by jamming > > > > several SoCs into one file. Splitting simplifies things. > > > > > > > > Fixes: 5c6f3a36b913 ("dt-bindings: clock: Add YAML schemas for the QCOM GPUCC clock bindings") > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > > --- > > > > > > > > Changes in v3: > > > > - Added pointer to inlude file in description. > > > > - Everyone but msm8998 now uses internal QC names. > > > > - Fixed typo grpahics => graphics > > > > - Split bindings into 3 files. > > > > > > > > Changes in v2: > > > > - Patch ("dt-bindings: clock: Fix qcom,gpucc...") new for v2. > > > > > > > > .../devicetree/bindings/clock/qcom,gpucc.yaml | 72 ------------------- > > > > .../bindings/clock/qcom,msm8998-gpucc.yaml | 66 +++++++++++++++++ > > > > .../bindings/clock/qcom,sc7180-gpucc.yaml | 72 +++++++++++++++++++ > > > > .../bindings/clock/qcom,sdm845-gpucc.yaml | 72 +++++++++++++++++++ > > > > 4 files changed, 210 insertions(+), 72 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc.yaml > > > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml > > > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml > > > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml > > > > > > I'm not seeing any differences in sdm845 and sc7180. Do those really > > > need to be separate? It doesn't have to be all combined or all > > > separate. > > > > They are the same, other than pointing to a different #include file. > > I debated whether to put them in one file (arbitrarily named after one > > SoC or the other) or to put them in individual files. I got the > > impression from Stephen that he'd prefer them to be separate files > > even in the case that they were 99% identical, but I certainly could > > have misunderstood. > > > > I'll do whatever you guys agree to. If you want them in one file I'll > > probably name it "qcom,sdm845-gpucc.yaml" just because that SoC is > > earlier, unless someone tells me otherwise. > > > > I'd prefer them to be split out and point at the include file so we know > what numbers are valid. It provides clarity and helps avoid the back and > forth of combining and splitting the files. We suffer the same problem > on the driver side, and we've long given up trying to combine SoCs when > they're otherwise fairly similar. Thanks for clarifying! Rob: I hope it's OK that I've gone ahead and sent out v4 leaving this alone. I knew you were interested in getting the other bindings patch out sooner rather than later and I was hoping to get both series out together so I could context switch to a few other things early this week. Apologies if this was moving too fast... -Doug