On 05.11.2019 00:49, Rob Herring wrote: > On Fri, Nov 01, 2019 at 12:52:00AM +0200, Leonard Crestez wrote: >> Add initial dt bindings for the interconnects inside i.MX chips. >> Multiple external IPs are involved but SOC integration means the >> software controllable interfaces are very similar. >> >> Single node also acts as interconnect provider if #interconnect-cells is >> present. >> >> Signed-off-by: Leonard Crestez <leonard.crestez@xxxxxxx> >> Acked-by: MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> >> --- >> .../devicetree/bindings/devfreq/imx.yaml | 83 +++++++++++++++++++ > > bindings/interconnect/ Make sense. The only other two files in devicetree/bindings/devfreq are: * rk3399_dmc: a memory controller * exynos-bus: arguably an interconnect >> 1 file changed, 83 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/devfreq/imx.yaml >> >> diff --git a/Documentation/devicetree/bindings/devfreq/imx.yaml b/Documentation/devicetree/bindings/devfreq/imx.yaml >> new file mode 100644 >> index 000000000000..bfc825407764 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/devfreq/imx.yaml >> @@ -0,0 +1,83 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +%YAML 1.2 >> +--- >> +$id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdevfreq%2Fimx.yaml%23&data=02%7C01%7Cleonard.crestez%40nxp.com%7C95911400e0834b06269c08d761794cd2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637085045930647253&sdata=88iAXoKObu%2FXBqZu6hNwnOUIffB8GxVLdGeBWiCjClI%3D&reserved=0 >> +$schema: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cleonard.crestez%40nxp.com%7C95911400e0834b06269c08d761794cd2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637085045930647253&sdata=0phpsG05ZsYc5SnI3FXZODJpJSEB2tzA5v02r7N%2BY2I%3D&reserved=0 >> + >> +title: Generic i.MX bus frequency device > > i.MX8 specific? Not really, but it's initially targeted at imx8m. >> +maintainers: >> + - Leonard Crestez <leonard.crestez@xxxxxxx> >> + >> +description: | >> + The i.MX SoC family has multiple buses for which clock frequency (and >> + sometimes voltage) can be adjusted. >> + >> + Some of those buses expose register areas mentioned in the memory maps as GPV >> + ("Global Programmers View") but not all. Access to this area might be denied >> + for normal (non-secure) world. >> + >> + The buses are based on externally licensed IPs such as ARM NIC-301 and >> + Arteris FlexNOC but DT bindings are specific to the integration of these bus >> + interconnect IPs into imx SOCs. >> + >> +properties: >> + compatible: >> + oneOf: >> + - items: >> + - enum: >> + - fsl,imx8mn-nic >> + - fsl,imx8mm-nic >> + - fsl,imx8mq-nic >> + - const: fsl,imx8m-nic >> + - items: >> + - enum: >> + - fsl,imx8mn-noc >> + - fsl,imx8mm-noc >> + - fsl,imx8mq-noc >> + - const: fsl,imx8m-noc >> + >> + reg: >> + maxItems: 1 >> + >> + clocks: >> + maxItems: 1 >> + >> + operating-points-v2: true >> + >> + devfreq: >> + description: | >> + Phandle to another devfreq device to match OPPs with by using the >> + passive governor. >> + $ref: "/schemas/types.yaml#/definitions/phandle" >> + >> + '#interconnect-cells': >> + description: | >> + If specified then also act as an interconnect provider. Should only be >> + set once per soc on main noc. >> + const: 1 >> + >> + interconnect-node-id: > > Looks like common property, but it's not... > > Generally, we don't do indexes or instance ids. So it needs a better > explanation or drop this. The driver side looks like an odd marriage > between interconnect and devfreq drivers that needs better integration, > but I'm not all that familar with either. Current interconnect drivers all operate by sending messages via a mailbox to a system controller which handles bandwidth requests. They only perform request aggregation. On imx8m frequency scaling is also implemented in the kernel so the NOC becomes almost like a MFD. The interconnect-node-id is used to find other scalable nodes for the same interconnect provider. I can replace this with a "scalable-nodes" array like this: noc: interconnect@32700000 { compatible = "fsl,imx8mq-noc", "fsl,imx8m-noc"; reg = <0x32700000 0x100000>; clocks = <&clk IMX8MQ_CLK_NOC>; #interconnect-cells = <1>; fsl,scalable-node-ids = <IMX8MQ_ICN_NOC>, <IMX8MQ_ICS_DRAM>; fsl,scalable-nodes = <&noc>, <&ddrc>; operating-points-v2 = <&noc_opp_table>; noc_opp_table: opp-table { compatible = "operating-points-v2"; opp-133M { opp-hz = /bits/ 64 <133333333>; }; opp-400M { opp-hz = /bits/ 64 <400000000>; }; opp-800M { opp-hz = /bits/ 64 <800000000>; }; }; }; ddrc: dram-controller@3d400000 { compatible = "fsl,imx8mq-ddrc", "fsl,imx8m-ddrc"; reg = <0x3d400000 0x400000>; clock-names = "core", "pll", "alt", "apb"; clocks = <&clk IMX8MQ_CLK_DRAM_CORE>, <&clk IMX8MQ_DRAM_PLL_OUT>, <&clk IMX8MQ_CLK_DRAM_ALT>, <&clk IMX8MQ_CLK_DRAM_APB>; devfreq-events = <&ddr_pmu>; }; It's a bit strange that the noc references itself but in advanced multiple NOC can be be present and there needs to be a way to map from the interconnect graph (node ids) to devicetree nodes. >> + description: | >> + i.MX chips have multiple scalable buses based on the same IP, this is >> + used to distinguish between. Uses same identifier namespace as consumer > > It's not names, so number space? Just guessing because there's no type > nor example. Maybe "numeric namespace"? >> + "interconnects" property, for example one of the values in >> + "include/dt-bindings/interconnect/imx8mm.h" >> + >> + const: 1 >> + >> +required: >> + - compatible >> + - clocks >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/clock/imx8mm-clock.h> >> + noc: noc@32700000 { >> + compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc"; >> + reg = <0x32700000 0x100000>; >> + clocks = <&clk IMX8MM_CLK_NOC>; >> + operating-points-v2 = <&noc_opp_table>; >> + }; >> -- >> 2.17.1
