Message-ID: <d2fd100c-0da0-a8cf-0324-539e3345cc89@samsung.com>
Date:   Fri, 17 Jan 2020 16:14:47 +0900
From:   Chanwoo Choi <cw00.choi@...sung.com>
To:     Artur Świgoń <a.swigon@...sung.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org
Cc:     georgi.djakov@...aro.org, b.zolnierkie@...sung.com,
        m.szyprowski@...sung.com, krzk@...nel.org
Subject: Re: [PATCH v4 0/3] interconnect: Support Samsung Exynos use-case

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

Powered by blists - more mailing lists