* [PATCH 0/5] Add R8A77980/Condor LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:53 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Reposting with the correct subject... Sorry! :-]
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180604-v4.17-rc7' tag. We're adding the R8A77980 FCPVD/VSPD/
DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
connected to the LVDS output. These patches depend on the Thine THC63LVD1024
driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
DT patches in order to apply/compile...
[1/5] arm64: dts: renesas: r8a77980: add FCPVD support
[2/5] arm64: dts: renesas: r8a77980: add VSPD support
[3/5] arm64: dts: renesas: r8a77980: add DU support
[4/5] arm64: dts: renesas: r8a77980: add LVDS support
[5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
From: Sergei Shtylyov @ 2018-06-06 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,14 @@
resets = <&cpg 408>;
};
+ fcpvd0: fcp at fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH 2/5] arm64: dts: renesas: r8a77980: add VSPD support
From: Sergei Shtylyov @ 2018-06-06 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,16 @@
resets = <&cpg 408>;
};
+ vspd0: vsp at fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x4000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp at fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
^ permalink raw reply
* [PATCH 3/5] arm64: dts: renesas: r8a77980: add DU support
From: Sergei Shtylyov @ 2018-06-06 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the generic R8A77980 part of the DU device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -671,6 +671,36 @@
resets = <&cpg 603>;
};
+ du: display at feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH 4/5] arm64: dts: renesas: r8a77980: add LVDS support
From: Sergei Shtylyov @ 2018-06-06 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the generic R8A77980 part of the LVDS device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -696,6 +696,35 @@
port at 1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder at feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
^ permalink raw reply
* [PATCH 5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the Condor board dependent part of the DU and LVDS device nodes.
Also add the device nodes for Thine THC63LVD1024 LVDS decoder and Analog
Devices ADV7511W HDMI transmitter...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 ++++++++++++++++++++++++
1 file changed, 106 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi at 39{
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Clément Péron @ 2018-06-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
Hi Scott, Florian,
On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 06/06/201 8 09:03 AM, Scott Branden wrote:
> > Hi Clement,
> >
> >
> > On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
> >> From: Cl?ment Peron <clement.peron@devialet.com>
> >>
> >> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
> >>
> >> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > Thanks for upstreaming some missing Cygnus components.
> >
> > But, the problem is the tarball release from Broadcom you are extracting
> > these changes from does not contain git history; so, you are missing the
> > original authors and signed-off's.
> > I checked our internal git repository and for this commit the author is:
> > Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> >
> > Please adjust author and signed-off appropriately. If there are other
> > changes you are extracting from the source tarballs you have please
> > contact me so we can construct patch appropriately.
>
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
> --
> Florian
Totally not my goal to steal the author and agree to keep track of the
original author
as soon as it's possible. I didn't though it was important for this
patch as the same
code is available in the dt-bindings documentation.
Actually there are still some buggy components like DSA (Arun proposed
a patch this morning)
the PWM (config and delay aren't correct) and I2C. These are mainlined
but can't be used
and need a minimal effort to correctly work on Cygnus.
Also there are some important components like USB Phy or Mailbox that
were proposed and
almost made it, but just need a small modification to be accepted.
My idea was just to submit small patches that are trivial to review.
In order to avoid keeping
lots of patches in our kernel and also have something functional when
building a mainline kernel.
Regards,
Clement
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
On 18-06-06 09:47 AM, Florian Fainelli wrote:
> On 06/06/2018 09:03 AM, Scott Branden wrote:
>> Hi Clement,
>>
>>
>> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>
>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>
>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>> Thanks for upstreaming some missing Cygnus components.
>>
>> But, the problem is the tarball release from Broadcom you are extracting
>> these changes from does not contain git history; so, you are missing the
>> original authors and signed-off's.
>> I checked our internal git repository and for this commit the author is:
>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>
>> Please adjust author and signed-off appropriately.? If there are other
>> changes you are extracting from the source tarballs you have please
>> contact me so we can construct patch appropriately.
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
Sure, I can submit the original patch to keep things simple and avoid
finding a lawyer right now.
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
But, It would be great to get some guidance and clarification on this
for sure.
I'm reading:
https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html
The change was created entirely by Broadcom, so seems difficult for
somebody else to upstream change without appropriate authorship and
signed off from copyright holder.? Point a) and b) are not met in
Developer's Certificate of Origin while point c) is being attempted
(without a or b being certified).
^ permalink raw reply
* [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Catalin Marinas @ 2018-06-06 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606163846.495725-1-jeremy.linton@arm.com>
On Wed, Jun 06, 2018 at 11:38:46AM -0500, Jeremy Linton wrote:
> The numa mask subset check can often lead to system hang or crash during
> CPU hotplug and system suspend operation if NUMA is disabled. This is
> mostly observed on HMP systems where the CPU compute capacities are
> different and ends up in different scheduler domains. Since
> cpumask_of_node is returned instead core_sibling, the scheduler is
> confused with incorrect cpumasks(e.g. one CPU in two different sched
> domains at the same time) on CPU hotplug.
>
> Lets disable the NUMA siblings checks for the time being, as NUMA in
> socket machines have LLC's that will assure that the scheduler topology
> isn't "borken".
>
> The NUMA check exists to assure that if a LLC within a socket crosses
> NUMA nodes/chiplets the scheduler domains remain consistent. This code will
> likely have to be re-enabled in the near future once the NUMA mask story
> is sorted. At the moment its not necessary because the NUMA in socket
> machines LLC's are contained within the NUMA domains.
>
> Further, as a defensive mechanism during hot-plug, lets assure that the
> LLC siblings are also masked.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Thanks for this. I queued it for this merging window.
--
Catalin
^ permalink raw reply
* [GIT PULL] Mailbox changes for v4.18
From: Jassi Brar @ 2018-06-06 17:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 7fbb6157630f2ba6ee355689061f9596b84373ef:
Merge tag 'armsoc-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-05-26
14:05:16 -0700)
are available in the Git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
tags/mailbox-v4.18
for you to fetch changes up to f83d1cfc8bcddf93bb6f55940fd59f5b047863e5:
mailbox/drivers/hisi: Consolidate the Kconfig for the MAILBOX
(2018-06-06 22:21:59 +0530)
----------------------------------------------------------------
- Remove HAS_DMA config dependencies
- New STMicroelectronics STM32 IPCC driver
- Enable QCom driver to run more controllers
- Fixed return code from null to ptr-err for Brcm driver
- Fix kconfig dependencies for the HiSilicon driver
----------------------------------------------------------------
Bjorn Andersson (1):
mailbox: qcom: Add msm8998 hmss compatible
Daniel Lezcano (1):
mailbox/drivers/hisi: Consolidate the Kconfig for the MAILBOX
Fabien Dessenne (2):
dt-bindings: mailbox: add STMicroelectronics STM32 IPCC binding
mailbox: add STMicroelectronics STM32 IPCC driver
Geert Uytterhoeven (1):
mailbox: Remove depends on HAS_DMA in case of platform dependency
Sibi Sankar (2):
dt-bindings: mailbox: Add APSS shared binding for SDM845 SoCs
mailbox: Add support for Qualcomm SDM845 SoCs
Stefan Wahren (1):
mailbox: bcm2835: Fix of_xlate return value
.../bindings/mailbox/qcom,apcs-kpss-global.txt | 2 +
.../devicetree/bindings/mailbox/stm32-ipcc.txt | 47 +++
drivers/mailbox/Kconfig | 22 +-
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm2835-mailbox.c | 2 +-
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +
drivers/mailbox/stm32-ipcc.c | 402 +++++++++++++++++++++
7 files changed, 472 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/stm32-ipcc.txt
create mode 100644 drivers/mailbox/stm32-ipcc.c
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJiuCcdfmrdHf10JkVOGQXD77JN=_FUv2ysEGTzyvwON31HX_A@mail.gmail.com>
On 18-06-06 10:06 AM, Cl?ment P?ron wrote:
> Hi Scott, Florian,
>
> On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 06/06/201 8 09:03 AM, Scott Branden wrote:
>>> Hi Clement,
>>>
>>>
>>> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>>
>>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>>
>>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>>> Thanks for upstreaming some missing Cygnus components.
>>>
>>> But, the problem is the tarball release from Broadcom you are extracting
>>> these changes from does not contain git history; so, you are missing the
>>> original authors and signed-off's.
>>> I checked our internal git repository and for this commit the author is:
>>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>>
>>> Please adjust author and signed-off appropriately. If there are other
>>> changes you are extracting from the source tarballs you have please
>>> contact me so we can construct patch appropriately.
>> If you want the original author's Signed-off-by to be preserved, why
>> don't you extract it from your internal git tree and submit the patch on
>> Mohamed's behalf?
>>
>> AFAICT what Clement is doing here is permissible given the Linux
>> developer certificate of origin though I am not a lawyer of course.
>> --
>> Florian
> Totally not my goal to steal the author and agree to keep track of the
> original author
> as soon as it's possible. I didn't though it was important for this
> patch as the same
> code is available in the dt-bindings documentation.
>
> Actually there are still some buggy components like DSA (Arun proposed
> a patch this morning)
> the PWM (config and delay aren't correct) and I2C. These are mainlined
> but can't be used
> and need a minimal effort to correctly work on Cygnus.
We have internal versions of most everything.? It's a matter of getting
people to push the appropriate patches out for upstream version to work.
Please contact the bcm-kernel-feedback list with issues and we can work
through common solution (or, likely already have a solution just not
upstreamed).
>
> Also there are some important components like USB Phy or Mailbox that
> were proposed and
> almost made it, but just need a small modification to be accepted.
Again - we may have internal solution already.? Yes, mailbox was
submitted upstream a long time ago and I think got stalled being
accepted upstream.? We can work through upstream solution by starting
with sending to bcm-kernel-feedback-list to discuss details.
>
> My idea was just to submit small patches that are trivial to review.
> In order to avoid keeping
> lots of patches in our kernel and also have something functional when
> building a mainline kernel.
I understand the difficulty you would have if you're trying to work with
a different kernel version in our release.? If you send me a list
directly of the drivers you use in Cygnus that will help me get those
changes prioritized to be pushed upstream.? And/or we can work together
on that.
>
> Regards,
> Clement
Thanks,
?Scott
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Florian Fainelli @ 2018-06-06 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <676106a4-d763-725c-2342-f8d215fbd169@broadcom.com>
On 06/06/2018 10:14 AM, Scott Branden wrote:
>
>
> On 18-06-06 09:47 AM, Florian Fainelli wrote:
>> On 06/06/2018 09:03 AM, Scott Branden wrote:
>>> Hi Clement,
>>>
>>>
>>> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>>
>>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>>
>>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>>> Thanks for upstreaming some missing Cygnus components.
>>>
>>> But, the problem is the tarball release from Broadcom you are extracting
>>> these changes from does not contain git history; so, you are missing the
>>> original authors and signed-off's.
>>> I checked our internal git repository and for this commit the author is:
>>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>>
>>> Please adjust author and signed-off appropriately.? If there are other
>>> changes you are extracting from the source tarballs you have please
>>> contact me so we can construct patch appropriately.
>> If you want the original author's Signed-off-by to be preserved, why
>> don't you extract it from your internal git tree and submit the patch on
>> Mohamed's behalf?
> Sure, I can submit the original patch to keep things simple and avoid
> finding a lawyer right now.
>>
>> AFAICT what Clement is doing here is permissible given the Linux
>> developer certificate of origin though I am not a lawyer of course.
> But, It would be great to get some guidance and clarification on this
> for sure.
> I'm reading:
> https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html
>
> The change was created entirely by Broadcom, so seems difficult for
> somebody else to upstream change without appropriate authorship and
> signed off from copyright holder.
Indeed, but it is effectively Broadcom's fault for not providing a git
tree for the customer to pull from in order to preserve the original
authorship, if what was distributed is a tarball of changes against a
vanilla kernel (which is likely to be the case), then all author
attributions are lost.
Not suggesting you change how you deliver code to customers, we have the
same issue in the STB/CM group, except maybe customers care less about
upstreaming so we can do it ourselves at our own pace and using our own
attributions.
> Point a) and b) are not met in
> Developer's Certificate of Origin while point c) is being attempted
> (without a or b being certified).
I would think that point a) and b) are met by the very fact that the
Cygnus kernel port is GPLv2 code, being a derivative work of the Linux
kernel, and that should be enough.
This is kind of well established things, this has happened for many
Broadcom product lines unfortunately because not everyone is active like
you in getting things upstreamed. Those contributions were still
entirely valid and acceptable for the kernel community.
Maybe we do need a lawyer, Saul Goodman, are you here?
--
Florian
^ permalink raw reply
* [PATCH v2 5/5] arm64: perf: Add support for chaining event counters
From: Mark Rutland @ 2018-06-06 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527591356-10934-6-git-send-email-suzuki.poulose@arm.com>
On Tue, May 29, 2018 at 11:55:56AM +0100, Suzuki K Poulose wrote:
> Add support for 64bit event by using chained event counters
> and 64bit cycle counters.
>
> Arm v8 PMUv3 allows chaining a pair of adjacent PMU counters
> (with the lower counter number being always "even"). The low
> counter is programmed to count the event of interest and the
> high counter(odd numbered) is programmed with a special event
> code (0x1e - Chain).
I found this a little difficult to read. How about:
PMUv3 allows chaining a pair of adjacent 32-bit counters, effectively
forming a 64-bit counter. The low/even counter is programmed to count
the event of interest, and the high/odd counter is programmed to count
the CHAIN event, taken when the low/even counter overflows.
> Thus we need special allocation schemes
> to make the full use of available counters. So, we allocate the
> counters from either ends. i.e, chained counters are allocated
> from the lower end in pairs of two and the normal counters are
> allocated from the higher number. Also makes necessary changes to
> handle the chained events as a single event with 2 counters.
Why do we need to allocate in this way?
I can see this might make allocating a pair of counters more likely in
some cases, but there are still others where it wouldn't be possible
(and we'd rely on the rotation logic to repack the counters for us).
[...]
> +static inline u32 armv8pmu_read_evcntr(int idx)
> +{
> + return (armv8pmu_select_counter(idx) == idx) ?
> + read_sysreg(pmxevcntr_el0) : 0;
> +}
Given armv8pmu_select_counter() always returns the idx passed to it, I
don't think we need to check anything here. We can clean that up to be
void, and remove the existing checks.
[...]
> +static inline u64 armv8pmu_read_chain_counter(int idx)
> +{
> + u64 prev_hi, hi, lo;
> +
> + hi = armv8pmu_read_evcntr(idx);
> + do {
> + prev_hi = hi;
> + isb();
> + lo = armv8pmu_read_evcntr(idx - 1);
> + isb();
> + hi = armv8pmu_read_evcntr(idx);
> + } while (prev_hi != hi);
> +
> + return (hi << 32) | lo;
> +}
> +static inline void armv8pmu_write_chain_counter(int idx, u64 value)
> +{
> + armv8pmu_write_evcntr(idx, value >> 32);
> + isb();
> + armv8pmu_write_evcntr(idx - 1, value);
> +}
Can we use upper_32_bits() and lower_32_bits() here?
As a more general thing, I think we need to clean up the way we
read/write counters, because I don't think that it's right that we poke
them while they're running -- that means you get some arbitrary skew on
counter groups.
It looks like the only case we do that is the IRQ handler, so we should
be able to stop/start the PMU there.
With that, we can get rid of the ISB here, and likewise in
read_chain_counter, which wouldn't need to be a loop.
> +
> +static inline void armv8pmu_write_hw_counter(struct perf_event *event,
> + u64 value)
> +{
> + int idx = event->hw.idx;
> +
> + if (armv8pmu_event_is_chained(event))
> + armv8pmu_write_chain_counter(idx, value);
> + else
> + armv8pmu_write_evcntr(idx, value);
> +}
> +
> static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
> {
> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> @@ -541,14 +612,14 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
> smp_processor_id(), idx);
> else if (idx == ARMV8_IDX_CYCLE_COUNTER) {
> /*
> - * Set the upper 32bits as this is a 64bit counter but we only
> - * count using the lower 32bits and we want an interrupt when
> - * it overflows.
> + * Set the upper 32bits if we are counting this in
> + * 32bit mode, as this is a 64bit counter.
> */
It would be good to keep the explaination as to why.
> - value |= 0xffffffff00000000ULL;
> + if (!armv8pmu_event_is_64bit(event))
> + value |= 0xffffffff00000000ULL;
> write_sysreg(value, pmccntr_el0);
> - } else if (armv8pmu_select_counter(idx) == idx)
> - write_sysreg(value, pmxevcntr_el0);
> + } else
> + armv8pmu_write_hw_counter(event, value);
> }
> +static inline void armv8pmu_write_event_type(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + int idx = hwc->idx;
> +
> + /*
> + * For chained events, write the the low counter event type
> + * followed by the high counter. The high counter is programmed
> + * with CHAIN event code with filters set to count at all ELs.
> + */
> + if (armv8pmu_event_is_chained(event)) {
> + u32 chain_evt = ARMV8_PMUV3_PERFCTR_CHAIN |
> + ARMV8_PMU_INCLUDE_EL2;
> +
> + armv8pmu_write_evtype(idx - 1, hwc->config_base);
> + isb();
> + armv8pmu_write_evtype(idx, chain_evt);
The ISB isn't necessary here, AFAICT. We only do this while the PMU is
disabled; no?
> + } else
> + armv8pmu_write_evtype(idx, hwc->config_base);
> +}
[...]
> +static inline void armv8pmu_enable_event_counter(struct perf_event *event)
> +{
> + int idx = event->hw.idx;
> +
> + /*
> + * For chained events, we enable the high counter followed by
> + * the low counter.
> + */
> + armv8pmu_enable_counter(idx);
> + if (armv8pmu_event_is_chained(event)) {
> + isb();
> + armv8pmu_enable_counter(idx - 1);
> + }
> +}
If we fix up the IRQ handler, this would only happen with the PMU as a
whole disabled, and we wouldn't care about ordering of enable/disable of
each event.
[...]
> +static inline void armv8pmu_disable_event_counter(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + int idx = hwc->idx;
> +
> + /*
> + * Disable the low counter followed by the high counter
> + * for chained events.
> + */
> + if (armv8pmu_event_is_chained(event)) {
> + armv8pmu_disable_counter(idx - 1);
> + isb();
> + }
> +
> + armv8pmu_disable_counter(idx);
> +}
... likewise.
> @@ -679,6 +679,12 @@ static void cpu_pm_pmu_setup(struct arm_pmu *armpmu, unsigned long cmd)
> continue;
>
> event = hw_events->events[idx];
> + /*
> + * If there is no event at this idx (e.g, an idx used
> + * by a chained event in Arm v8 PMUv3), skip it.
> + */
> + if (!event)
> + continue;
We may as well lose the used_mask test if we're looking at the event
regardless.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 1/7] interconnect: Add generic on-chip interconnect API
From: Georgi Djakov @ 2018-06-06 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43fedb5b-f4a5-8362-d0a2-534b85473bc1@linaro.org>
Hi Evan,
On 06/06/2018 05:59 PM, Georgi Djakov wrote:
>>> +
>>> +/**
>>> + * icc_node_create() - create a node
>>> + * @id: node id
>>> + *
>>> + * Return: icc_node pointer on success, or ERR_PTR() on error
>>> + */
>>> +struct icc_node *icc_node_create(int id)
>>> +{
>>> + struct icc_node *node;
>>> +
>>> + /* check if node already exists */
>>> + node = node_find(id);
>>> + if (node)
>>> + return node;
>>
>> This is probably going to do more harm than good once icc_node_delete comes
>> in, since it almost certainly indicates a programmer error or ID collision,
>> and will likely result in a double free. We should probably fail with
>> EEXIST instead.
>
> In the current approach we create the nodes one by one, and the linked
> nodes are created when they are referenced. The other way around would
> be to create first all the nodes and then populate the links to avoid
> the "chicken and egg" problem.
>
Just to elaborate a bit more on that: We can't actually register all the
nodes in advance, as we might have multiple interconnect providers
probing in different order. Each provider may have nodes linking to
nodes belonging to other providers (not probed yet). That's why we
create the nodes on the first reference and then, when the actual
provider driver is probed, the rest of the node data is filled.
Thanks,
Georgi
^ permalink raw reply
* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Scott Branden @ 2018-06-06 18:21 UTC (permalink / raw)
To: linux-arm-kernel
From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 9fe4f5a..b0e38fa 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -417,6 +417,11 @@
status = "disabled";
};
+ rng: rng at 18032000 {
+ compatible = "brcm,iproc-rng200";
+ reg = <0x18032000 0x28>;
+ };
+
sdhci0: sdhci at 18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;
--
2.5.0
^ permalink raw reply related
* [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
From: Steven Rostedt @ 2018-06-06 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606142600.GN13775@localhost>
On Wed, 6 Jun 2018 16:26:00 +0200
Johan Hovold <johan@kernel.org> wrote:
> Looks like the greybus code above is working as intended by checking for
> unterminated string after the strncpy, even if this does now triggers
> the truncation warning.
Ah, yes I now see that. Thanks for pointing it out. But perhaps it
should also add the "- 1" to the strncpy() so that gcc doesn't think
it's a mistake.
-- Steve
^ permalink raw reply
* [PATCH] coresight: Fix check in coresight_tmc_etr_buf_insert_barrier_packet
From: Mathieu Poirier @ 2018-06-06 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527851302-5843-1-git-send-email-suzuki.poulose@arm.com>
On 1 June 2018 at 05:08, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> We request for "CORESIGHT_BARRIER_PKT_SIZE" length and we should
> be happy when we get that size.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>
> Mathieu,
>
> Please could you pull this patch, if you are happy with it ?
> This fixes a problem in the ETR buf series, which I just
> noticed while testing the part2 of the series.
I will pick up the change - you will see it being queued when the
first rc comes out.
>
> Suzuki
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index e2bcef3..c736250 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -862,7 +862,7 @@ tmc_etr_buf_insert_barrier_packet(struct etr_buf *etr_buf, u64 offset)
>
> len = tmc_etr_buf_get_data(etr_buf, offset,
> CORESIGHT_BARRIER_PKT_SIZE, &bufp);
> - if (WARN_ON(len <= CORESIGHT_BARRIER_PKT_SIZE))
> + if (WARN_ON(len < CORESIGHT_BARRIER_PKT_SIZE))
> return -EINVAL;
> coresight_insert_barrier_packet(bufp);
> return offset + CORESIGHT_BARRIER_PKT_SIZE;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 0/6] Enhance support for the SP805 WDT
From: Florian Fainelli @ 2018-06-06 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
On 05/28/2018 11:01 AM, Ray Jui wrote:
> This patch series enhances the support for the SP805 watchdog timer.
> First of all, 'timeout-sec' devicetree property is added. In addition,
> support is also added to allow the driver to reset the watchdog if it
> has been detected that watchdot has been started in the bootloader. In
> this case, the driver will initiate the ping service from the kernel
> watchdog subsystem, before a user mode daemon takes over. This series
> also enables SP805 in the default ARM64 defconfig
>
> This patch series is based off v4.17-rc5 and is available on GIHUB:
> repo: https://github.com/Broadcom/arm64-linux.git
> branch: sp805-wdt-v4
>
> Changes since v3:
> - Improve description of 'timeout-sec' in the binding document, per
> recommendation from Guenter Roeck
>
> Changes since v2:
> - Fix indent and format to make them consistent within arm,sp805.txt
>
> Changes since v1:
> - Consolidate two duplicated SP805 binding documents into one
> - Slight change of the wdt_is_running implementation per discussion
>
> Ray Jui (6):
> Documentation: DT: Consolidate SP805 binding docs
> Documentation: DT: Add optional 'timeout-sec' property for sp805
> watchdog: sp805: add 'timeout-sec' DT property support
> watchdog: sp805: set WDOG_HW_RUNNING when appropriate
> arm64: dt: set initial SR watchdog timeout to 60 seconds
> arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
I can take the last two patches and Guenter would take the first 4 or
would you want to proceed differently?
--
Florian
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-06 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <OSBPR01MB2054E3A1E383495F3534B551D2650@OSBPR01MB2054.jpnprd01.prod.outlook.com>
Hi Michel,
On 06/05/18 23:36, Michel Pollet wrote:
> Hi Frank,
>
> On 05 June 2018 18:34, Frank wrote:
>> On 06/05/18 04:28, Michel Pollet wrote:
>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>> it requires a special enable method to get it started.
>>>
>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>> ---
>>> arch/arm/mach-shmobile/Makefile | 1 +
>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>> ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 80 insertions(+)
>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>
>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>> --- a/arch/arm/mach-shmobile/Makefile
>>> +++ b/arch/arm/mach-shmobile/Makefile
>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>> headsmp-scu.o platsmp-scu.o
>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>> platsmp-scu.o
>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>> platsmp-scu.o
>>>
>>> # PM objects
>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> new file mode 100644
>>> index 0000000..cd40e6e
>>> --- /dev/null
>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> @@ -0,0 +1,79 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * R9A06G032 Second CA7 enabler.
>>> + *
>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>> + *
>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>> <buserror@gmail.com>
>>> + * Derived from action,s500-smp
>>> + */
>>> +
>>> +#include <linux/io.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/smp.h>
>>> +
>>> +/*
>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>> +it after
>>> + * writing an address into the BOOTADDR register of sysctrl.
>>> + *
>>> + * So the default value of the "cpu-release-addr" corresponds to
>> BOOTADDR...
>>> + *
>>> + * *However* the BOOTADDR register is not available when the kernel
>>> + * starts in NONSEC mode.
>>> + *
>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>> +pen
>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>> +SRAM address,
>>> + * which is not restricted.
>>
>> The binding document for cpu-release-addr does not have a definition for 32
>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>> for 32 bit arm to patch 1.
>
> Hmmm I do find a definition in
> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
> added my 'enable-method' -- And it is already used as 32 bits in at least
> arch/arm/boot/dts/stih407-family.dtsi.
>From cpus.txt:
- cpu-release-addr
Usage: required for systems that have an "enable-method"
property value of "spin-table".
Value type: <prop-encoded-array>
Definition:
# On ARM v8 64-bit systems must be a two cell
property identifying a 64-bit zero-initialised
memory location.
The definition specifies a two cell property for 64-bit systems.
Please add to the definition that cpu-release-addr is a one cell property
for 32-bit systems.
-Frank
>
> What do you want me to add to this exactly? Do you want me to just
> change "required for systems that have an "enable-method" property
> value of "spin-table" to also specify renesas,r9a06g032 ?
>
> Thanks!
> Michel
>
>>
>> -Frank
>>
>>
>>> + */
>>> +
>>> +static void __iomem *cpu_bootaddr;
>>> +
>>> +static DEFINE_SPINLOCK(cpu_lock);
>>> +
>>> +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct
>>> +task_struct *idle) {
>>> +if (!cpu_bootaddr)
>>> +return -ENODEV;
>>> +
>>> +spin_lock(&cpu_lock);
>>> +
>>> +writel(__pa_symbol(secondary_startup), cpu_bootaddr);
>>> +arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>>> +
>>> +spin_unlock(&cpu_lock);
>>> +
>>> +return 0;
>>> +}
>>> +
>>> +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
>>> +{
>>> +struct device_node *dn;
>>> +int ret;
>>> +u32 bootaddr;
>>> +
>>> +dn = of_get_cpu_node(1, NULL);
>>> +if (!dn) {
>>> +pr_err("CPU#1: missing device tree node\n");
>>> +return;
>>> +}
>>> +/*
>>> + * Determine the address from which the CPU is polling.
>>> + * The bootloader *does* change this property
>>> + */
>>> +ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
>>> +of_node_put(dn);
>>> +if (ret) {
>>> +pr_err("CPU#1: invalid cpu-release-addr property\n");
>>> +return;
>>> +}
>>> +pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
>>> +
>>> +cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr)); }
>>> +
>>> +static const struct smp_operations r9a06g032_smp_ops __initconst = {
>>> +.smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
>>> +.smp_boot_secondary = r9a06g032_smp_boot_secondary, };
>>> +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp",
>>> +&r9a06g032_smp_ops);
>>>
>
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
>
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: allwinner: a64: add R_I2C controller
From: Maxime Ripard @ 2018-06-06 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606051702.6478-2-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:00PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
> two groups of pinmuxes on PL bank, so it's called R_I2C.
>
> Add support for this I2C controller and the pinmux which doesn't conflict
> with RSB.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..dcf957b2e7c8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -46,6 +46,7 @@
> #include <dt-bindings/clock/sun8i-r-ccu.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/reset/sun50i-a64-ccu.h>
> +#include <dt-bindings/reset/sun8i-r-ccu.h>
>
> / {
> interrupt-parent = <&gic>;
> @@ -655,6 +656,18 @@
> #reset-cells = <1>;
> };
>
> + r_i2c: i2c at 1f02400 {
> + compatible = "allwinner,sun50i-a64-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x01f02400 0x400>;
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_APB0_I2C>;
> + resets = <&r_ccu RST_APB0_I2C>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> r_pio: pinctrl at 1f02c00 {
> compatible = "allwinner,sun50i-a64-r-pinctrl";
> reg = <0x01f02c00 0x400>;
> @@ -666,6 +679,17 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> +
> + r_i2c_pins: i2c {
> + pins = "PL0", "PL1";
> + function = "s_i2c";
> + };
> +
We usually don't have pin groups that are not used by any boards. I've
removed it and applied.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 2/3] arm64: dts: allwinner: a64: Add PWM controllers
From: Maxime Ripard @ 2018-06-06 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606051702.6478-3-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:01PM -0700, Vasily Khoruzhick wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC features two PWM controllers, which are fully
> compatible to the one used in the A13 and H3 chips.
>
> Add the nodes for the devices (one for the "normal" PWM, the other for
> the one in the CPUS domain) and the pins their outputs are connected to.
>
> On the A64 the "normal" PWM is muxed together with one of the MDIO pins
> used to communicate with the Ethernet PHY, so it won't be usable on many
> boards. But the Pinebook laptop uses this pin for controlling the LCD
> backlight.
>
> On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
> at the same location as the PWM pin on the RaspberryPi.
>
> Tested on Pinebook and Teres-I
>
> [vasily: fixed comment message as requested by Stefan Bruens, added default
> muxing options to pwm and r_pwm nodes]
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Tested-by: Harald Geyer <harald@ccbib.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Rob Herring @ 2018-06-06 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbbd287c-437e-d7bd-d40f-6bb914d96860@gmail.com>
On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Michel,
>
> On 06/05/18 23:36, Michel Pollet wrote:
>> Hi Frank,
>>
>> On 05 June 2018 18:34, Frank wrote:
>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>> it requires a special enable method to get it started.
>>>>
>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>> ---
>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>> ++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>
>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>> headsmp-scu.o platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>> platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>> platsmp-scu.o
>>>>
>>>> # PM objects
>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> new file mode 100644
>>>> index 0000000..cd40e6e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * R9A06G032 Second CA7 enabler.
>>>> + *
>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>> + *
>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>> <buserror@gmail.com>
>>>> + * Derived from action,s500-smp
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/smp.h>
>>>> +
>>>> +/*
>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>> +it after
>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>> + *
>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>> BOOTADDR...
>>>> + *
>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>> + * starts in NONSEC mode.
>>>> + *
>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>> +pen
>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>> +SRAM address,
>>>> + * which is not restricted.
>>>
>>> The binding document for cpu-release-addr does not have a definition for 32
>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>> for 32 bit arm to patch 1.
>>
>> Hmmm I do find a definition in
>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> added my 'enable-method' -- And it is already used as 32 bits in at least
>> arch/arm/boot/dts/stih407-family.dtsi.
>
> From cpus.txt:
>
> - cpu-release-addr
> Usage: required for systems that have an "enable-method"
> property value of "spin-table".
> Value type: <prop-encoded-array>
> Definition:
> # On ARM v8 64-bit systems must be a two cell
> property identifying a 64-bit zero-initialised
> memory location.
>
> The definition specifies a two cell property for 64-bit systems.
>
> Please add to the definition that cpu-release-addr is a one cell property
> for 32-bit systems.
Actually, this is all already documented in the DT spec and it is
always 2 cells[1]. We should perhaps just remove whatever is
duplicated from the spec.
Rob
[1]
``cpu-release-addr`` | SD | ``<u64>`` The
cpu-release-addr property is required for
cpu nodes that have
an enable-method property
value of
``"spin-table"``. The value specifies the
physical address of
a spin table entry that
releases a
secondary CPU from its spin loop.
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Maxime Ripard @ 2018-06-06 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606051702.6478-4-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:02PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.xyz>
>
> Pinebook is a A64-based laptop produced by Pine64, with the following
> peripherals:
>
> USB:
> - Two external USB ports (one is directly connected to A64's OTG
> controller, the other is under a internal hub connected to the host-only
> controller.)
> - USB HID keyboard and touchpad connected to the internal hub.
> - USB UVC camera connected to the internal hub.
>
> Power-related:
> - A DC IN jack connected to AXP803's DCIN pin.
> - A Li-Polymer battery connected to AXP803's battery pins.
>
> Storage:
> - An eMMC by Foresee on the main board (in the product revision of the
> main board it's designed to be switchable).
> - An external MicroSD card slot.
>
> Display:
> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
> - A mini HDMI port.
>
> Misc:
> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
> - A headphone jack connected to the SoC's internal codec.
> - A debug UART port muxed with headphone jack.
>
> This commit adds basical support for it.
>
> [vasily: squashed several commits into one, added simplefb node, added usbphy
> to ehci0 and ohci0 nodes and other cosmetic changes to dts]
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
I've updated Icenowy's domain and applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Florian Fainelli @ 2018-06-06 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbbd287c-437e-d7bd-d40f-6bb914d96860@gmail.com>
On 06/06/2018 12:30 PM, Frank Rowand wrote:
> Hi Michel,
>
> On 06/05/18 23:36, Michel Pollet wrote:
>> Hi Frank,
>>
>> On 05 June 2018 18:34, Frank wrote:
>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>> it requires a special enable method to get it started.
>>>>
>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>> ---
>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>> ++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>
>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>> headsmp-scu.o platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>> platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>> platsmp-scu.o
>>>>
>>>> # PM objects
>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> new file mode 100644
>>>> index 0000000..cd40e6e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * R9A06G032 Second CA7 enabler.
>>>> + *
>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>> + *
>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>> <buserror@gmail.com>
>>>> + * Derived from action,s500-smp
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/smp.h>
>>>> +
>>>> +/*
>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>> +it after
>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>> + *
>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>> BOOTADDR...
>>>> + *
>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>> + * starts in NONSEC mode.
>>>> + *
>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>> +pen
>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>> +SRAM address,
>>>> + * which is not restricted.
>>>
>>> The binding document for cpu-release-addr does not have a definition for 32
>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>> for 32 bit arm to patch 1.
>>
>> Hmmm I do find a definition in
>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> added my 'enable-method' -- And it is already used as 32 bits in at least
>> arch/arm/boot/dts/stih407-family.dtsi.
>
> From cpus.txt:
>
> - cpu-release-addr
> Usage: required for systems that have an "enable-method"
> property value of "spin-table".
> Value type: <prop-encoded-array>
> Definition:
> # On ARM v8 64-bit systems must be a two cell
> property identifying a 64-bit zero-initialised
> memory location.
>
> The definition specifies a two cell property for 64-bit systems.
>
> Please add to the definition that cpu-release-addr is a one cell property
> for 32-bit systems.
Or maybe phrase it such that the number of cells encoded in
cpu-release-addr must exactly match the CPU node's #address-cells size?
--
Florian
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-06 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJCkP_c_wKGRc7Qzkiw8sZLRf6MGz-WgVsLjnQfqK8r6Q@mail.gmail.com>
Hi Rob,
On Wed, Jun 6, 2018 at 9:35 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Actually, this is all already documented in the DT spec and it is
> always 2 cells[1]. We should perhaps just remove whatever is
> duplicated from the spec.
>
> Rob
>
> [1]
> ``cpu-release-addr`` | SD | ``<u64>`` The
> cpu-release-addr property is required for
> cpu nodes that have
> an enable-method property
> value of
> ``"spin-table"``. The value specifies the
> physical address of
> a spin table entry that
> releases a
> secondary CPU from its spin loop.
Interesting. But why is this <u64>, and not just following #address-cells?
Due to the ePAPR-spec being 64-bit Power System-centric?
There's also "initial-mapped-area", which must use 64-bit values for effective
and physical addresses, according to ePAPR.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox