Hi, On 1/17/20 3:10 PM, Artur Świgoń wrote: > Hi Chanwoo, > > On Fri, 2020-01-17 at 14:31 +0900, Chanwoo Choi wrote: >> Hi Artur, >> >> I'm concerned about that make it the separate series >> without use-case like exynos-bus, exynos-drm. >> If this series is applied to v5.6, it doesn't make >> the problem and the patches for exynos-bus/exynos-drm >> will be reviewed and then merged on later kernel version. >> >> But, if not, the interconnect, exynos-bus and exynos-drm >> patches should be merged into the same kernel version, >> it must require the immutable branch among interconnect, >> devfreq and exynos-drm. I think that you need to consider >> it between different subsystems. > > Thanks for the feedback. Due to the fact that the RFC depends > on the proposed changes to the interconnect framework, I need > to ensure that these three patches come first. > > If there is any disagreement over any of these three patches, > the rest of the RFC might need to be modified. In such case, > I will update the RFC and send the rest of v4 patches (for > exynos-bus, exynos-mixer, and probably also exynos5-dmc). OK. Thanks. > >> On 1/16/20 11:41 PM, Artur Świgoń wrote: >>> Previously posted as a part of a larger RFC: [1]. >>> >>> The Exynos SoC family relies on the devfreq driver for frequency >>> scaling. However, a way to programmatically enforce QoS contraints >>> (i.e., minimum frequency) is desired. A solution which uses the >>> interconnect framework to ensure QoS is currently being developed[1]. >>> >>> The exynos-bus hierarchy is composed of multiple buses which are probed >>> separately. Sometimes the DMC is even handled by a different driver. >>> Since the exynos-bus driver is generic and supports multiple differing >>> bus hierarchies, IDs for nodes (i.e. buses) are assigned dynamically. Due >>> to the unspecified relative probing order, every bus registers its own >>> interconnect provider. >>> >>> Rationale for each patch in this series: >>> * Patch 01 (exporting of_icc_get_from_provider()) makes it easy to >>> retrieve the parent node from the DT (cf. patch 05 in [1]). >>> * Patch 02 (allowing #interconnect-cells = <0>) allows to remove dummy >>> node IDs from the DT. >>> * Patch 03 (allowing inter-provider node pairs) is necessary to make >>> such multi-provider hierarchy work. A new approach implemented in v3 >>> ensures not to break any existing drivers. >>> >>> --- >>> Changes since v3 (to patches in this series): >>> * Improve commit messages. >>> >>> --- >>> Artur Świgoń >>> Samsung R&D Institute Poland >>> Samsung Electronics >>> >>> --- >>> References: >>> [1] https://protect2.fireeye.com/url?k=c69d0cf5-9b4f1bfc-c69c87ba-0cc47a31cdf8-2143c550c0e479bd&u=https://patchwork.kernel.org/patch/11305287/ >>> >>> Artur Świgoń (3): >>> interconnect: Export of_icc_get_from_provider() >>> interconnect: Relax requirement in of_icc_get_from_provider() >>> interconnect: Allow inter-provider pairs to be configured >>> >>> drivers/interconnect/core.c | 16 ++++++++-------- >>> include/linux/interconnect-provider.h | 8 ++++++++ >>> 2 files changed, 16 insertions(+), 8 deletions(-) >>> >> >> -- Best Regards, Chanwoo Choi Samsung Electronics
