Hi Artur, On 7/23/19 15:20, Artur Świgoń wrote: > This patch adds interconnect functionality to the exynos-bus devfreq > driver. > > The SoC topology is a graph (or, more specifically, a tree) and most of its > edges are taken from the devfreq parent-child hierarchy (cf. > Documentation/devicetree/bindings/devfreq/exynos-bus.txt). The previous > patch adds missing edges to the DT (under the name 'parent'). Due to > unspecified relative probing order, -EPROBE_DEFER may be propagated to > guarantee that a child is probed before its parent. > > Each bus is now an interconnect provider and an interconnect node as well > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers > itself as a node. Node IDs are not hardcoded but rather assigned at > runtime, in probing order (subject to the above-mentioned exception > regarding relative order). This approach allows for using this driver with > various Exynos SoCs.
I am not familiar with the Exynos bus topology, but it seems to me that it's not represented correctly. An interconnect provider with just a single node (port) is odd. I would expect that each provider consists of multiple master and slave nodes. This data would be used by a framework to understand what are the links and how the traffic flows between the IP blocks and through which buses. > The devfreq target() callback provided by exynos-bus now selects either the > frequency calculated by the devfreq governor or the frequency requested via > the interconnect API for the given node, whichever is higher. This completely makes sense. We just need to be sure that the interconnect framework is used correctly. Thanks, Georgi
