Quoting Jeffrey Hugo (2019-11-07 14:35:21) > On 11/7/2019 2:55 PM, Stephen Boyd wrote: > > Quoting Jeffrey Hugo (2019-10-01 12:57:22) > >> diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt > >> index 8b0f7841af8d..a92f3cbc9736 100644 > >> --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt > >> +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt > > > >> > >> - reg : shall contain base register location and length > >> - #clock-cells : shall contain 1 > >> - #reset-cells : shall contain 1 > >> > >> +For MSM8998 only: > >> + - clocks: a list of phandles and clock-specifier pairs, > >> + one for each entry in clock-names. > >> + - clock-names: "xo" for the xo clock. > >> + "gpll0" for the global pll 0 clock. > >> + "dsi0dsi" for the dsi0 pll dsi clock (required if dsi is > >> + enabled, optional otherwise). > >> + "dsi0byte" for the dsi0 pll byte clock (required if dsi > >> + is enabled, optional otherwise). > >> + "dsi1dsi" for the dsi1 pll dsi clock (required if dsi is > >> + enabled, optional otherwise). > >> + "dsi1byte" for the dsi1 pll byte clock (required if dsi > >> + is enabled, optional otherwise). > >> + "hdmipll" for the hdmi pll clock (required if hdmi is > >> + enabled, optional otherwise). > >> + "dpvco" for the displayport pll vco clock (required if > >> + dp is enabled, optional otherwise). > >> + "dplink" for the displayport pll link clock (required if > >> + dp is enabled, optional otherwise). > > > > I'm not sure why it's optional. The hardware is "fixed" in the sense > > that the dp phy is always there and connected to this hardware block. > > From a driver perspective I agree it's optional to be used, but from a > > DT perspective it's always there so it should be required. > > > > Sure, the DP phy is technically always there, but does a particular > platform have an actual DP output connected to the phy? If not, why > bother describing something that isn't even used? If the DP phy isn't connected then having it be marked as status = "disabled" is the typical approach to the problem. I agree it may not be used on some particular board using the SoC, but this is an SoC that is made once so we should be able to describe it regardless of how it's used by some board. > > From a more practical sense its undefined how to actually get the DP > clocks - the DP binding is implicitly a clock provider since it has > #clock-cells, but it doesn't specify how to actually get the clocks. > The DSI binding tells you which index is the dsi clock, and which is the > byte clock. > > The HDMI binding is not a clock provider at all. Needs to be revised, > which didn't appear trivial when I took a quick look while working on mmcc. > > I want to do the right thing here by specifying all the external clocks > up front, and not have to worry about backwards compatibility with > pre-existing DTs later on, but I also would like to focus on one problem > at a time, and not go dig into all the problems with DP/HDMI before > landing this, particularly as those components also rely on the mmcc. > > Is that justification enough for you? If not, how would you like to > proceed? Make them required in the binding, and just have an invalid > (per the binding) DT until all the problems get sorted out? > If we can make the clks 'required' and not cause the DTS checker system to blow up then I'll be happy. I hope we can have a property like: clocks = <&gcc KNOWN_CLK>, <0>, <0>, <&dp_phy 1>; where <0> means "I don't know right now", and that will be enough to please the checker and can be filled in later on when we sort out the HDMI and DP bindings. If this doesn't work then I guess I'll just have to get over it and complain to Rob Herring.
