Messages in this thread | | | Subject | Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus | From | Georgi Djakov <> | Date | Fri, 26 Jul 2019 11:05:18 +0300 |
| |
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
| |