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(-)
--
2.17.1
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
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).
> 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(-)
> >
>
>
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
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