[OpenWrt-Devel,4/4] ipq40xx: add support for secondarycores bringup

Ipq40xx requires separate procedure.
Cherry-pick from QSDK.

Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
---
 ...x-add-support-for-secondary-cores-bringup.patch | 174 +++++++++++++++++++++
 ...x-Add-support-for-secondary-cores-bringup.patch | 174 +++++++++++++++++++++
 2 files changed, 348 insertions(+)
 create mode 100644 target/linux/ipq40xx/patches-4.14/091-ipq40xx-add-support-for-secondary-cores-bringup.patch
 create mode 100644 target/linux/ipq40xx/patches-4.19/087-ipq40xx-Add-support-for-secondary-cores-bringup.patch

Pavel Kubelun <be.dissent@gmail.com> [2019-05-14 16:42:20]:

> --- /dev/null
> +++ b/target/linux/ipq40xx/patches-4.14/091-ipq40xx-add-support-for-secondary-cores-bringup.patch
> @@ -0,0 +1,174 @@
> +From 6126701397fa6c884fd78453d995e49df91a566a Mon Sep 17 00:00:00 2001
> +From: Pavel Kubelun <be.dissent@gmail.com>
> +Date: Mon, 13 May 2019 11:25:05 +0300
> +Subject: [PATCH] ipq40xx: Add support for secondary cores bringup
> +
> +Cherry-pick QSDK patches to enable proper ipq40xx
> +secondary cores bringup.
> +
> +https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=eggplant&id=f810b63c356bd72d9b89fb9c0b7e27c250c3540f

Please preserve the authorship of the work and try to upstream this changes
first, then backport it to OpenWrt.

-- ynezz

ср, 15 мая 2019 г., 19:02 Petr Štetiar <ynezz@true.cz>:

> Pavel Kubelun <be.dissent@gmail.com> [2019-05-14 16:42:20]:
>
> > --- /dev/null
> > +++
> b/target/linux/ipq40xx/patches-4.14/091-ipq40xx-add-support-for-secondary-cores-bringup.patch
> > @@ -0,0 +1,174 @@
> > +From 6126701397fa6c884fd78453d995e49df91a566a Mon Sep 17 00:00:00 2001
> > +From: Pavel Kubelun <be.dissent@gmail.com>
> > +Date: Mon, 13 May 2019 11:25:05 +0300
> > +Subject: [PATCH] ipq40xx: Add support for secondary cores bringup
> > +
> > +Cherry-pick QSDK patches to enable proper ipq40xx
> > +secondary cores bringup.
> > +
> > +
> https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=eggplant&id=f810b63c356bd72d9b89fb9c0b7e27c250c3540f
>
> Please preserve the authorship of the work and try to upstream this changes
> first, then backport it to OpenWrt.
>

This patchset consists of 2 patches with different authors that I have
squashed into 1. How should I preserve authorship in this case?
I'm not the author of this code to upstream it.


> -- ynezz
>

Павел <be.dissent@gmail.com> [2019-05-15 20:35:38]:

> This patchset consists of 2 patches with different authors that I have
> squashed into 1. How should I preserve authorship in this case?

Just add them as separate patches, exactly as produced by `git format-patch`
command, don't squash them.

> I'm not the author of this code to upstream it.

You don't need to be author in order to upstream it. It's quite common to post
patches for review on behalf of other developers, you just need to keep proper
authorship. My recent (rejected) attempt for example[1].

1. https://patchwork.ozlabs.org/patch/1086628/

-- ynezz

ср, 15 мая 2019 г., 21:55 Petr Štetiar <ynezz@true.cz>:

> Павел <be.dissent@gmail.com> [2019-05-15 20:35:38]:
>
> > This patchset consists of 2 patches with different authors that I have
> > squashed into 1. How should I preserve authorship in this case?
>
> Just add them as separate patches, exactly as produced by `git
> format-patch`
> command, don't squash them.
>

Not a problem, actually, but I've been suggested to squash them :)
https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897


> > I'm not the author of this code to upstream it.
>
> You don't need to be author in order to upstream it. It's quite common to
> post
> patches for review on behalf of other developers, you just need to keep
> proper
> authorship. My recent (rejected) attempt for example[1].
>
> 1. https://patchwork.ozlabs.org/patch/1086628/


Shouldn't the dev send the patch directly to me in order to be able to post
it on his behalf, like openwrt submitting patches guideline describes?


>
> -- ynezz
>

Павел <be.dissent@gmail.com> [2019-05-15 22:14:41]:

> Not a problem, actually, but I've been suggested to squash them :)
> https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897

ok, thanks for the background, but still, squashing doesn't mean changing
authorship and Christian has probably also warned you beforehand :-)

"(Note: In some of the patches the "Author" in the commits is dissent1! So
  watch out before sending them off)"

> Shouldn't the dev send the patch directly to me in order to be able to post
> it on his behalf, like openwrt submitting patches guideline describes?

From the kernel docs[1]:

"The contribution is based upon previous work that, to the best of my
 knowledge, is covered under an appropriate open source license and I have the
 right under that license to submit that work with modifications, whether
 created in whole or in part by me, under the same open source license (unless
 I am permitted to submit under a different license), as indicated in the file;"

so in short, kernel is covered by GPLv2 which allows you to do this if you
retain the authorship.

1. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

-- ynezz

ср, 15 мая 2019 г., 22:35 Petr Štetiar <ynezz@true.cz>:

> Павел <be.dissent@gmail.com> [2019-05-15 22:14:41]:
>
> > Not a problem, actually, but I've been suggested to squash them :)
> > https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897
>
> ok, thanks for the background, but still, squashing doesn't mean changing
> authorship and Christian has probably also warned you beforehand :-)
>
> "(Note: In some of the patches the "Author" in the commits is dissent1! So
>   watch out before sending them off)"
>

That was about different - I didn't switch from nickname to real name by
mistake when exported patches from my staging tree.

Thanks anyway, I'll add 2 commit messages into patchnotes within the
squashed patch. Is that okay?


> > Shouldn't the dev send the patch directly to me in order to be able to
> post
> > it on his behalf, like openwrt submitting patches guideline describes?
>
> From the kernel docs[1]:
>
> "The contribution is based upon previous work that, to the best of my
>  knowledge, is covered under an appropriate open source license and I have
> the
>  right under that license to submit that work with modifications, whether
>  created in whole or in part by me, under the same open source license
> (unless
>  I am permitted to submit under a different license), as indicated in the
> file;"
>
> so in short, kernel is covered by GPLv2 which allows you to do this if you
> retain the authorship.
>
> 1.
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin


Okay, thanks for pointing out.


>
> -- ynezz
>

On Wednesday, May 15, 2019 9:35:28 PM CEST Petr Štetiar wrote:
> Павел <be.dissent@gmail.com> [2019-05-15 22:14:41]:
> 
> > Not a problem, actually, but I've been suggested to squash them :)
> > https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897
> 
> ok, thanks for the background, but still, squashing doesn't mean changing
> authorship and Christian has probably also warned you beforehand :-)

Did it occure to anybody to look at these two patches for a second
before writing long essays about that's right and not? Because Patch
"one" is incomplete and the second patch is clearly doing a "FIXUP"
for the first. That's why they should be squashed. I do think, you'll
be just ignored if you try to post these as-is with your signed-off
on the linux-msm-arm. But then, why not give it a shot, this would
make for some good laughs if it went through as-is.

But from what I noticed, nobody did any of the requested perf
testing. These are absolutely necessary because the switch
from kpss-v1 to kpss-v2 clearly did have an big impact on the
performance. So let's not break anything because of a possible
incomplete patch (that might or might not require "ROM" support
that might or might not be present on all devices).

> "(Note: In some of the patches the "Author" in the commits is dissent1! So
>   watch out before sending them off)"
> 
> > Shouldn't the dev send the patch directly to me in order to be able to post
> > it on his behalf, like openwrt submitting patches guideline describes?
> 
> From the kernel docs[1]:
> 
> "The contribution is based upon previous work that, to the best of my
>  knowledge, is covered under an appropriate open source license and I have the
>  right under that license to submit that work with modifications, whether
>  created in whole or in part by me, under the same open source license (unless
>  I am permitted to submit under a different license), as indicated in the file;"
> 
> so in short, kernel is covered by GPLv2 which allows you to do this if you
> retain the authorship.
The other aspect of this is that you can also "offload" some of the blame
with retaining the original authorship if the patch goes sour. Because as
you have seen even the benight 32KHz (32000Hz vs 32768Hz) non-issue
(since it gets "rounded down" by the qcom-clk to 32000 see kernel debug)
can be a hot topic with conflicting "facts". Simply because we don't know
how the clock count is attained. If it's an external osc then it's probably
the "round" 32768 Hz, but if this sleep clock is generated from the 48 MHz
Osc reference (which we know is there, because these osc are big enough to
be spotted by looking at the PCB) then a "odd" 32000Hz is possible.

(That said, the highres timer fix seems to be definitely a winner. 
I'm glad that you spotted it).

Regrads,
Christian

пт, 17 мая 2019 г., 23:18 Christian Lamparter <chunkeey@gmail.com>:

> On Wednesday, May 15, 2019 9:35:28 PM CEST Petr Štetiar wrote:
> > Павел <be.dissent@gmail.com> [2019-05-15 22:14:41]:
> >
> > > Not a problem, actually, but I've been suggested to squash them :)
> > > https://github.com/openwrt/openwrt/pull/2043#issuecomment-491581897
> >
> > ok, thanks for the background, but still, squashing doesn't mean changing
> > authorship and Christian has probably also warned you beforehand :-)
>
> Did it occure to anybody to look at these two patches for a second
> before writing long essays about that's right and not? Because Patch
> "one" is incomplete and the second patch is clearly doing a "FIXUP"
> for the first. That's why they should be squashed. I do think, you'll
> be just ignored if you try to post these as-is with your signed-off
> on the linux-msm-arm. But then, why not give it a shot, this would
> make for some good laughs if it went through as-is.
>
> But from what I noticed, nobody did any of the requested perf
> testing. These are absolutely necessary because the switch
> from kpss-v1 to kpss-v2 clearly did have an big impact on the
>

Actually I've compared openssl benchmark (difference that you've mentioned)
between kpss-acc-v2 and this one - there's completely no difference that I
could notice. For example sha256 produces the same result. Here's
cortex-a7acc edition:
root@OpenWrt:~# openssl speed sha256
Doing sha256 for 3s on 16 size blocks: 859807 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 493458 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 219786 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 68287 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 9187 sha256's in 3.00s
Doing sha256 for 3s on 16384 size blocks: 4619 sha256's in 3.00s
OpenSSL 1.1.1b  26 Feb 2019
built on: Thu May 16 12:57:06 2019 UTC
options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr)
compiler: arm-openwrt-linux-muslgnueabi-gcc -fPIC -pthread
-Wa,--noexecstack -Wall -O3 -pipe -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result
-mfloat-abi=hard -Wformat -Werror=format-security -fstack-protector
-D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -O3 -fpic -ffunction-sections
-fdata-sections -znow -zrelro -DOPENSSL_USE_NODELETE -DOPENSSL_PIC
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG
-DOPENSSL_PREFER_CHACHA_OVER_GCM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes  16384 bytes
sha256            4585.64k    10527.10k    18755.07k    23308.63k
25086.63k    25225.90k

I'm not pasting the kpss-acc-v2 result because it doesn't differ.

But I indeed noticed 2x difference between oem firmware that is probably
still on kpss-acc-v1.

performance. So let's not break anything because of a possible
> incomplete patch (that might or might not require "ROM" support
> that might or might not be present on all devices).
>
> > "(Note: In some of the patches the "Author" in the commits is dissent1!
> So
> >   watch out before sending them off)"
> >
> > > Shouldn't the dev send the patch directly to me in order to be able to
> post
> > > it on his behalf, like openwrt submitting patches guideline describes?
> >
> > From the kernel docs[1]:
> >
> > "The contribution is based upon previous work that, to the best of my
> >  knowledge, is covered under an appropriate open source license and I
> have the
> >  right under that license to submit that work with modifications, whether
> >  created in whole or in part by me, under the same open source license
> (unless
> >  I am permitted to submit under a different license), as indicated in
> the file;"
> >
> > so in short, kernel is covered by GPLv2 which allows you to do this if
> you
> > retain the authorship.
> The other aspect of this is that you can also "offload" some of the blame
> with retaining the original authorship if the patch goes sour. Because as
> you have seen even the benight 32KHz (32000Hz vs 32768Hz) non-issue
> (since it gets "rounded down" by the qcom-clk to 32000 see kernel debug)
> can be a hot topic with conflicting "facts". Simply because we don't know
> how the clock count is attained. If it's an external osc then it's probably
> the "round" 32768 Hz, but if this sleep clock is generated from the 48 MHz
> Osc reference (which we know is there, because these osc are big enough to
> be spotted by looking at the PCB) then a "odd" 32000Hz is possible.
>
> (That said, the highres timer fix seems to be definitely a winner.
> I'm glad that you spotted it).
>
> Regrads,
> Christian
>
>
>