[GIT PULL] interconnect changes for 5.5

[GIT PULL] interconnect changes for 5.5

[Georgi Djakov]

Hi Greg,

This is a pull request with interconnect patches for the 5.5 merge window.
All patches have been for a while in linux-next without reported issues. The
details are in the signed tag. Please consider pulling into char-misc-next.

Thanks,
Georgi

The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675:

  Linux 5.4-rc3 (2019-10-13 16:37:36 -0700)

are available in the Git repository at:

  https://git.linaro.org/people/georgi.djakov/linux.git tags/icc-5.5-rc1

for you to fetch changes up to 0bf9146d94a00c7759a30241eeabd3e2b28c5f15:

  docs: driver-api: make interconnect title quieter (2019-11-02 04:04:35 +0200)

----------------------------------------------------------------
interconnect patches for 5.5

Here are the interconnect updates for the 5.5-rc1 merge window.

- Disallow the interconnect core to be built as a module, as this will
bring more complexity when this API is called from other frameworks that
are built-in only.
- New interconnect driver for msm8974 platforms.
- Change the initcall level of a driver, so it is available earlier to
other dependent drivers.
- Minor clean-up and a tiny documentation fix.

Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>

----------------------------------------------------------------
Brian Masney (2):
      dt-bindings: interconnect: qcom: add msm8974 bindings
      interconnect: qcom: add msm8974 driver

Georgi Djakov (1):
      interconnect: Add locking in icc_set_tag()

Jordan Crouse (2):
      interconnect: Move interconnect drivers to core_initcall
      interconnect: Remove unused module exit code from core

Leonard Crestez (1):
      interconnect: qcom: Fix icc_onecell_data allocation

Louis Taylor (1):
      docs: driver-api: make interconnect title quieter

Viresh Kumar (1):
      interconnect: Disallow interconnect core to be built as a module

 Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml |  62 +
 Documentation/driver-api/interconnect.rst                        |   2 +-
 drivers/interconnect/Kconfig                                     |   2 +-
 drivers/interconnect/core.c                                      |  11 +-
 drivers/interconnect/qcom/Kconfig                                |   9 +
 drivers/interconnect/qcom/Makefile                               |   2 +
 drivers/interconnect/qcom/msm8974.c                              | 796 ++++++++
 drivers/interconnect/qcom/qcs404.c                               |  17 +-
 drivers/interconnect/qcom/sdm845.c                               |  16 +-
 include/dt-bindings/interconnect/qcom,msm8974.h                  | 146 ++
 10 files changed, 1051 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
 create mode 100644 drivers/interconnect/qcom/msm8974.c
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8974.h

Re: [GIT PULL] interconnect changes for 5.5

[Greg Kroah-Hartman]

On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> Hi Greg,
> 
> This is a pull request with interconnect patches for the 5.5 merge window.
> All patches have been for a while in linux-next without reported issues. The
> details are in the signed tag. Please consider pulling into char-misc-next.

I don't know about
0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
Shouldn't you just fix up the dependancies of subsystems that rely on
this?  We are moving more and more to kernels that "just work" with
everything as modules, even on arm64 systems.  So forbiding the
interconnect code from being able to be built as a module does not feel
good to me at all.

Same for
0007-interconnect-Remove-unused-module-exit-code-from-cor.patch, we are
adding module_init/exit() calls to modules, do not remove them!


Can you drop those two patches and resend?  Or I can just take these out
of the pull request and apply the rest as patches for now, if that's
easier for you to handle.

thanks,

greg k-h

Re: [GIT PULL] interconnect changes for 5.5

[Georgi Djakov]

Hi Greg,

On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
>> Hi Greg,
>>
>> This is a pull request with interconnect patches for the 5.5 merge window.
>> All patches have been for a while in linux-next without reported issues. The
>> details are in the signed tag. Please consider pulling into char-misc-next.
> 
> I don't know about
> 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> Shouldn't you just fix up the dependancies of subsystems that rely on
> this?  We are moving more and more to kernels that "just work" with
> everything as modules, even on arm64 systems.  So forbiding the
> interconnect code from being able to be built as a module does not feel
> good to me at all.

Thank you for commenting on this! The initial idea was to keep everything as
modular as possible. The reasons behind this change is that other core
frameworks like cpufreq (and possibly others) want to call the interconnect
APIs. Some of these frameworks are built-in only and it would be easier to
handle dependencies if interconnect core built-in too. Now each user that
can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
!INTERCONNECT.

> 
> Same for
> 0007-interconnect-Remove-unused-module-exit-code-from-cor.patch, we are
> adding module_init/exit() calls to modules, do not remove them!
> 
> 
> Can you drop those two patches and resend?  Or I can just take these out
> of the pull request and apply the rest as patches for now, if that's
> easier for you to handle.

Ok, will drop them for now and re-send!

Thanks,
Georgi

Re: [GIT PULL] interconnect changes for 5.5

[Greg Kroah-Hartman]

On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
> Hi Greg,
> 
> On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> >> Hi Greg,
> >>
> >> This is a pull request with interconnect patches for the 5.5 merge window.
> >> All patches have been for a while in linux-next without reported issues. The
> >> details are in the signed tag. Please consider pulling into char-misc-next.
> > 
> > I don't know about
> > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> > Shouldn't you just fix up the dependancies of subsystems that rely on
> > this?  We are moving more and more to kernels that "just work" with
> > everything as modules, even on arm64 systems.  So forbiding the
> > interconnect code from being able to be built as a module does not feel
> > good to me at all.
> 
> Thank you for commenting on this! The initial idea was to keep everything as
> modular as possible. The reasons behind this change is that other core
> frameworks like cpufreq (and possibly others) want to call the interconnect
> APIs. Some of these frameworks are built-in only and it would be easier to
> handle dependencies if interconnect core built-in too. Now each user that
> can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
> !INTERCONNECT.

That's fine, when those subsystems start to use those apis, that
dependency needs to be added.  Nothing new here, and you forcing it to
either be "on or off" isn't going to change that.  Let's do it correctly
please.

thanks,

greg k-h

Re: [GIT PULL] interconnect changes for 5.5

[Georgi Djakov]

On 8.11.19 г. 12:39 ч., Greg Kroah-Hartman wrote:
> On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
>> Hi Greg,
>>
>> On 11/7/19 16:21, Greg Kroah-Hartman wrote:
>>> On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
>>>> Hi Greg,
>>>>
>>>> This is a pull request with interconnect patches for the 5.5 merge window.
>>>> All patches have been for a while in linux-next without reported issues. The
>>>> details are in the signed tag. Please consider pulling into char-misc-next.
>>>
>>> I don't know about
>>> 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
>>> Shouldn't you just fix up the dependancies of subsystems that rely on
>>> this?  We are moving more and more to kernels that "just work" with
>>> everything as modules, even on arm64 systems.  So forbiding the
>>> interconnect code from being able to be built as a module does not feel
>>> good to me at all.
>>
>> Thank you for commenting on this! The initial idea was to keep everything as
>> modular as possible. The reasons behind this change is that other core
>> frameworks like cpufreq (and possibly others) want to call the interconnect
>> APIs. Some of these frameworks are built-in only and it would be easier to
>> handle dependencies if interconnect core built-in too. Now each user that
>> can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
>> !INTERCONNECT.
> 
> That's fine, when those subsystems start to use those apis, that
> dependency needs to be added.  Nothing new here, and you forcing it to
> either be "on or off" isn't going to change that.  Let's do it correctly
> please.

Alright! That matches with what we do today. Thanks for the guidance!

BR,
Georgi

Re: [GIT PULL] interconnect changes for 5.5

[Bjorn Andersson]

On Fri, Nov 8, 2019 at 2:39 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
> > Hi Greg,
> >
> > On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> > >> Hi Greg,
> > >>
> > >> This is a pull request with interconnect patches for the 5.5 merge window.
> > >> All patches have been for a while in linux-next without reported issues. The
> > >> details are in the signed tag. Please consider pulling into char-misc-next.
> > >
> > > I don't know about
> > > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> > > Shouldn't you just fix up the dependancies of subsystems that rely on
> > > this?  We are moving more and more to kernels that "just work" with
> > > everything as modules, even on arm64 systems.  So forbiding the
> > > interconnect code from being able to be built as a module does not feel
> > > good to me at all.
> >
> > Thank you for commenting on this! The initial idea was to keep everything as
> > modular as possible. The reasons behind this change is that other core
> > frameworks like cpufreq (and possibly others) want to call the interconnect
> > APIs. Some of these frameworks are built-in only and it would be easier to
> > handle dependencies if interconnect core built-in too. Now each user that
> > can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
> > !INTERCONNECT.
>
> That's fine, when those subsystems start to use those apis, that
> dependency needs to be added.  Nothing new here, and you forcing it to
> either be "on or off" isn't going to change that.  Let's do it correctly
> please.
>

Please no!

Making our frameworks tristate means that we can no longer rely on
include file stubs (as framework=m, client=y will fail), so every
single client must add the "depends on framework || framework=n" - in
contrast to nothing the framework itself is bool.

An example of this is that there's almost 500 files referencing the
regulator api and all Kconfig entries referencing these files must be
updated with a "depends on REGULATOR || REGULATOR=n" if we're going to
start tristating frameworks.

For individual drivers behind these frameworks, definitely tristate.
But the only thing you're going to get out of making the frameworks
tristate is more build failures.

Regards,
Bjorn

Re: [GIT PULL] interconnect changes for 5.5

[Greg Kroah-Hartman]

On Fri, Nov 08, 2019 at 05:36:46PM -0800, Bjorn Andersson wrote:
> On Fri, Nov 8, 2019 at 2:39 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
> > > Hi Greg,
> > >
> > > On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> > > > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> > > >> Hi Greg,
> > > >>
> > > >> This is a pull request with interconnect patches for the 5.5 merge window.
> > > >> All patches have been for a while in linux-next without reported issues. The
> > > >> details are in the signed tag. Please consider pulling into char-misc-next.
> > > >
> > > > I don't know about
> > > > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> > > > Shouldn't you just fix up the dependancies of subsystems that rely on
> > > > this?  We are moving more and more to kernels that "just work" with
> > > > everything as modules, even on arm64 systems.  So forbiding the
> > > > interconnect code from being able to be built as a module does not feel
> > > > good to me at all.
> > >
> > > Thank you for commenting on this! The initial idea was to keep everything as
> > > modular as possible. The reasons behind this change is that other core
> > > frameworks like cpufreq (and possibly others) want to call the interconnect
> > > APIs. Some of these frameworks are built-in only and it would be easier to
> > > handle dependencies if interconnect core built-in too. Now each user that
> > > can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
> > > !INTERCONNECT.
> >
> > That's fine, when those subsystems start to use those apis, that
> > dependency needs to be added.  Nothing new here, and you forcing it to
> > either be "on or off" isn't going to change that.  Let's do it correctly
> > please.
> >
> 
> Please no!
> 
> Making our frameworks tristate means that we can no longer rely on
> include file stubs (as framework=m, client=y will fail), so every
> single client must add the "depends on framework || framework=n" - in
> contrast to nothing the framework itself is bool.

What's wrong with a single "depends on framework"?  If your code relies
on this framework, you should depend on it, right?  Include file stubs
feels odd for a core functionality, if you can live without that
functionality, then sure, don't depend on it and all should be just
fine.

thanks,

greg k-h

Re: [GIT PULL] interconnect changes for 5.5

[Bjorn Andersson]

On Sat, Nov 9, 2019 at 12:48 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Nov 08, 2019 at 05:36:46PM -0800, Bjorn Andersson wrote:
> > On Fri, Nov 8, 2019 at 2:39 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
> > > > Hi Greg,
> > > >
> > > > On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> > > > > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> > > > >> Hi Greg,
> > > > >>
> > > > >> This is a pull request with interconnect patches for the 5.5 merge window.
> > > > >> All patches have been for a while in linux-next without reported issues. The
> > > > >> details are in the signed tag. Please consider pulling into char-misc-next.
> > > > >
> > > > > I don't know about
> > > > > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> > > > > Shouldn't you just fix up the dependancies of subsystems that rely on
> > > > > this?  We are moving more and more to kernels that "just work" with
> > > > > everything as modules, even on arm64 systems.  So forbiding the
> > > > > interconnect code from being able to be built as a module does not feel
> > > > > good to me at all.
> > > >
> > > > Thank you for commenting on this! The initial idea was to keep everything as
> > > > modular as possible. The reasons behind this change is that other core
> > > > frameworks like cpufreq (and possibly others) want to call the interconnect
> > > > APIs. Some of these frameworks are built-in only and it would be easier to
> > > > handle dependencies if interconnect core built-in too. Now each user that
> > > > can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
> > > > !INTERCONNECT.
> > >
> > > That's fine, when those subsystems start to use those apis, that
> > > dependency needs to be added.  Nothing new here, and you forcing it to
> > > either be "on or off" isn't going to change that.  Let's do it correctly
> > > please.
> > >
> >
> > Please no!
> >
> > Making our frameworks tristate means that we can no longer rely on
> > include file stubs (as framework=m, client=y will fail), so every
> > single client must add the "depends on framework || framework=n" - in
> > contrast to nothing the framework itself is bool.
>
> What's wrong with a single "depends on framework"?  If your code relies
> on this framework, you should depend on it, right?

As your question shows, everyone gets this wrong and the build breaks
all the time (it's not "depends on framework", it's "depends on
framework || framework=n" - and everyone you'll talk to will be
puzzled as to why this is).

But consistently introducing this for clocks, regulators, pinctrl,
resets, etc should be a task so large that people will come out
educated from it - or whatever it is that one feels after fixing
thousands of Kconfig entries.

> Include file stubs
> feels odd for a core functionality, if you can live without that
> functionality, then sure, don't depend on it and all should be just
> fine.
>

Odd or not, it's what we have in all these frameworks.

Regards,
Bjorn

> thanks,
>
> greg k-h

Re: [GIT PULL] interconnect changes for 5.5

[Greg Kroah-Hartman]

On Sat, Nov 09, 2019 at 12:27:29PM -0800, Bjorn Andersson wrote:
> On Sat, Nov 9, 2019 at 12:48 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Nov 08, 2019 at 05:36:46PM -0800, Bjorn Andersson wrote:
> > > On Fri, Nov 8, 2019 at 2:39 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
> > > > > Hi Greg,
> > > > >
> > > > > On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> > > > > > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> > > > > >> Hi Greg,
> > > > > >>
> > > > > >> This is a pull request with interconnect patches for the 5.5 merge window.
> > > > > >> All patches have been for a while in linux-next without reported issues. The
> > > > > >> details are in the signed tag. Please consider pulling into char-misc-next.
> > > > > >
> > > > > > I don't know about
> > > > > > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> > > > > > Shouldn't you just fix up the dependancies of subsystems that rely on
> > > > > > this?  We are moving more and more to kernels that "just work" with
> > > > > > everything as modules, even on arm64 systems.  So forbiding the
> > > > > > interconnect code from being able to be built as a module does not feel
> > > > > > good to me at all.
> > > > >
> > > > > Thank you for commenting on this! The initial idea was to keep everything as
> > > > > modular as possible. The reasons behind this change is that other core
> > > > > frameworks like cpufreq (and possibly others) want to call the interconnect
> > > > > APIs. Some of these frameworks are built-in only and it would be easier to
> > > > > handle dependencies if interconnect core built-in too. Now each user that
> > > > > can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||
> > > > > !INTERCONNECT.
> > > >
> > > > That's fine, when those subsystems start to use those apis, that
> > > > dependency needs to be added.  Nothing new here, and you forcing it to
> > > > either be "on or off" isn't going to change that.  Let's do it correctly
> > > > please.
> > > >
> > >
> > > Please no!
> > >
> > > Making our frameworks tristate means that we can no longer rely on
> > > include file stubs (as framework=m, client=y will fail), so every
> > > single client must add the "depends on framework || framework=n" - in
> > > contrast to nothing the framework itself is bool.
> >
> > What's wrong with a single "depends on framework"?  If your code relies
> > on this framework, you should depend on it, right?
> 
> As your question shows, everyone gets this wrong and the build breaks
> all the time (it's not "depends on framework", it's "depends on
> framework || framework=n" - and everyone you'll talk to will be
> puzzled as to why this is).

Ah, now I get it.  Yeah, that sucks.  We need a "shortcut" in Kconfig to
express that type of dependancy.

thanks,

greg k-h

Re: [GIT PULL] interconnect changes for 5.5

[Viresh Kumar]

On 10-11-19, 11:16, Greg Kroah-Hartman wrote:
> Ah, now I get it.  Yeah, that sucks.  We need a "shortcut" in Kconfig to
> express that type of dependancy.

So we are going to merge this patch for now ?

@Bjorn, thanks for replying while I was away :)

-- 
viresh

Re: [GIT PULL] interconnect changes for 5.5

[Greg Kroah-Hartman]

On Mon, Nov 11, 2019 at 10:24:23AM +0530, Viresh Kumar wrote:
> On 10-11-19, 11:16, Greg Kroah-Hartman wrote:
> > Ah, now I get it.  Yeah, that sucks.  We need a "shortcut" in Kconfig to
> > express that type of dependancy.
> 
> So we are going to merge this patch for now ?

I did not, sorry.

greg k-h

Re: [GIT PULL] interconnect changes for 5.5

[Viresh Kumar]

On 10-11-19, 11:16, Greg Kroah-Hartman wrote:
> On Sat, Nov 09, 2019 at 12:27:29PM -0800, Bjorn Andersson wrote:
> > As your question shows, everyone gets this wrong and the build breaks
> > all the time (it's not "depends on framework", it's "depends on
> > framework || framework=n" - and everyone you'll talk to will be
> > puzzled as to why this is).
> 
> Ah, now I get it.  Yeah, that sucks.  We need a "shortcut" in Kconfig to
> express that type of dependancy.

Maybe we can use

depends on framework != m

-- 
viresh

Re: [GIT PULL] interconnect changes for 5.5

[Georgi Djakov]

On 11/14/19 10:41, Viresh Kumar wrote:
> On 10-11-19, 11:16, Greg Kroah-Hartman wrote:
>> On Sat, Nov 09, 2019 at 12:27:29PM -0800, Bjorn Andersson wrote:
>>> As your question shows, everyone gets this wrong and the build breaks
>>> all the time (it's not "depends on framework", it's "depends on
>>> framework || framework=n" - and everyone you'll talk to will be
>>> puzzled as to why this is).
>>
>> Ah, now I get it.  Yeah, that sucks.  We need a "shortcut" in Kconfig to
>> express that type of dependancy.
> 
> Maybe we can use
> 
> depends on framework != m

That won't work in the case where framework=m, provider=m and consumer=m.
Today this is supported by having each consumer to:
	depends on framework || !framework

So again, the problem is that we need to add something to Kconfig, even a
"shortcut", in order to express this dependency. If we convert the framework
from tristate to bool, there will be no need to touch Kconfig, as we have the
include stubs. Keeping the modular support comes at the cost of adding a
dependency to Kconfig for each user.

Thanks,
Georgi