From: Chanwoo Choi <cw00.choi@samsung.com>
To: "Artur Świgoń" <a.swigon@samsung.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-samsung-soc@vger.kernel.org
Cc: georgi.djakov@linaro.org, b.zolnierkie@samsung.com,
m.szyprowski@samsung.com, krzk@kernel.org
Subject: Re: [PATCH v4 0/3] interconnect: Support Samsung Exynos use-case
Date: Fri, 17 Jan 2020 14:31:49 +0900 [thread overview]
Message-ID: <95ac808c-aacf-8ca8-94a7-98bbdb37b39d@samsung.com> (raw)
In-Reply-To: <20200116144202.12116-1-a.swigon@samsung.com>
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.
Regards,
Chanwoo Choi
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://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
next prev parent reply other threads:[~2020-01-17 5:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200116144241eucas1p226c1d7fc2fad5bd1b9fb6d0fb1b22bff@eucas1p2.samsung.com>
2020-01-16 14:41 ` Artur Świgoń
[not found] ` <CGME20200116144241eucas1p18dcf099873015e955d71d90712bbe9e0@eucas1p1.samsung.com>
2020-01-16 14:42 ` [PATCH v4 1/3] interconnect: Export of_icc_get_from_provider() Artur Świgoń
2020-01-23 9:21 ` Georgi Djakov
2020-01-24 11:22 ` Artur Świgoń
[not found] ` <CGME20200116144242eucas1p2bf8b4df91355974c8c96778f4ec117f7@eucas1p2.samsung.com>
2020-01-16 14:42 ` [PATCH v4 2/3] interconnect: Relax requirement in of_icc_get_from_provider() Artur Świgoń
2020-01-17 5:24 ` Chanwoo Choi
[not found] ` <CGME20200116144242eucas1p1b66d8ca0d111f140c48b80c5064ca4ff@eucas1p1.samsung.com>
2020-01-16 14:42 ` [PATCH v4 3/3] interconnect: Allow inter-provider pairs to be configured Artur Świgoń
2020-01-17 5:31 ` Chanwoo Choi [this message]
2020-01-17 6:10 ` [PATCH v4 0/3] interconnect: Support Samsung Exynos use-case Artur Świgoń
2020-01-17 7:14 ` Chanwoo Choi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95ac808c-aacf-8ca8-94a7-98bbdb37b39d@samsung.com \
--to=cw00.choi@samsung.com \
--cc=a.swigon@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=georgi.djakov@linaro.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®