* [PATCH 2/2] arm64: dts: sdm845: Add rpmh-clk node
From: Douglas Anderson @ 2018-06-18 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618205616.102750-1-dianders@chromium.org>
This adds the rpmh-clk node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: to apply this patch cleanly, apply it atop:
arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
https://patchwork.kernel.org/patch/10462691/
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 19b006293d3b..c61ae815a697 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
*/
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
+#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -1001,6 +1002,11 @@
<WAKE_TCS 3>,
<ACTIVE_TCS 2>,
<CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sdm845-rpmh-clk";
+ #clock-cells = <1>;
+ };
};
intc: interrupt-controller at 17a00000 {
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* Dynamic ftrace self test broken on ARM
From: Stefan Agner @ 2018-06-18 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
ftrace self test. I tried v4.18-rc1 first, but it seems that at least
also v4.17 is affected.
Booting Linux on physical CPU 0x0
Linux version 4.17.0 (ags at trochilidae) (gcc version 7.2.1 20171011
(Linaro GCC 7.2-2017.11)) #564 SMP Mon Jun 18 23:00:48 CEST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri
Evaluation Board V3
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
Ignoring RAM at 0xb0000000-0xc0000000
Consider using a HIGHMEM enabled kernel.
cma: Reserved 256 MiB at 0xa0000000
psci: probing for conduit method from DT.
psci: Using PSCI v0.1 Function IDs from DT
percpu: Embedded 17 pages/cpu @(ptrval) s39308 r8192 d22132 u69632
Built 1 zonelists, mobility grouping on. Total pages: 195072
Kernel command line: earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4
rootwait ip=off console=tty1 console=ttymxc0,115200n8 ${extraargs}
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 501152K/786432K available (9216K kernel code, 682K rwdata, 3016K
rodata, 1024K init, 397K bss, 23136K reserved, 262144K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0800000 - 0xff800000 ( 240 MB)
lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (10208 kB)
.init : 0x(ptrval) - 0x(ptrval) (1024 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 683 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 398 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
ftrace: allocating 32657 entries in 96 pages
Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
GIC: Using split EOI/Deactivate mode
arch_timer: cp15 timer(s) running at 8.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles:
0x1d854df40, max_idle_ns: 440795202120 ns
sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every
2199023255500ns
Switching to timer-based delay loop, resolution 125ns
Switching to timer-based delay loop, resolution 41ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
89478484971ns
clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 79635851949 ns
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop (skipped), value calculated using timer
frequency.. 48.00 BogoMIPS (lpj=240000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80100000 - 0x80100060
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
CPU1: update cpu_capacity 1024
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
smp: Brought up 1 node, 2 CPUs
SMP: Total of 2 processors activated (96.00 BogoMIPS).
CPU: All CPU(s) started in HYP mode.
CPU: Virtualization extensions available.
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x84/0x19c with
crng_init=0
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 512 (order: 3, 32768 bytes)
Running postponed tracer tests:
Testing tracer function: PASSED
Testing dynamic ftrace: PASSED
Testing dynamic ftrace ops #1:
(1 0 1 0 0)
(1 1 2 0 0)
(2 1 3 0 93620)
(2 2 4 0 93807) PASSED
Testing dynamic ftrace ops #2:
(1 0 1 96630 0)
(1 1 2 96804 0)
(2 1 3 1 342)
(2 2 4 121 462) PASSED
Testing ftrace recursion: PASSED
Testing ftrace recursion safe: PASSED
Testing ftrace regs: PASSED
Testing tracer nop: PASSED
Testing tracer function_graph: PASSED
pinctrl core: initialized pinctrl subsystem
Unable to handle kernel paging request at virtual address c0ca14e4
pgd = (ptrval)
[c0ca14e4] *pgd=80c1940e(bad)
Internal error: Oops: 80d [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
Hardware name: Freescale i.MX7 Dual (Device Tree)
PC is at skb_init+0x50/0x7c
LR is at kmem_cache_create_usercopy+0x10c/0x320
pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
sp : dc11be98 ip : dc11be58 fp : dc11bebc
r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 8000406a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
Stack: (0xdc11be98 to 0xdc11c000)
be80: 00000018
00000030
bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
c0e63b3c
bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
c0e63a1c
bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
c0bf3c7c
bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
c0fa7140
bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
dc11bf48
bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
c0f09fc0
bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
00000000
bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
c0989c58
bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
00000000
[<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
[<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
[<c0103080>] (do_one_initcall) from [<c0e011d8>]
(kernel_init_freeable+0x270/0x308)
[<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
(kernel_init+0x18/0x124)
[<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xdc11bfb0 to 0xdc11bff8)
bfa0: 00000000 00000000 00000000
00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
---[ end trace fff84001ba23c9c9 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.292924]
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
Hardware name: Freescale i.MX7 Dual (Device Tree)
[<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
[<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
[<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
[<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
[<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
Exception stack(0xdc14df18 to 0xdc14df60)
df00: 00000000
00000324
df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
c0f05d80
df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
ffffffff
[<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
[<c010993c>] (arch_cpu_idle) from [<c098f81c>]
(default_idle_call+0x30/0x3c)
[<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
[<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
[<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
(secondary_start_kernel+0x158/0x164)
[<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
]---
I tested with imx_v6_v7_defconfig and enabled the following options:
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
I guess startup test should leave the kernel unencumbered?
--
Stefan
^ permalink raw reply
* [PATCH 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Lina Iyer @ 2018-06-18 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618205616.102750-1-dianders@chromium.org>
On Mon, Jun 18 2018 at 14:56 -0600, Douglas Anderson wrote:
>This adds the rpmh-rsc node to sdm845 based on the examples in the
>bindings.
>
>Signed-off-by: Douglas Anderson <dianders@chromium.org>
>---
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>index cd308b84bed7..19b006293d3b 100644
>--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>@@ -7,6 +7,7 @@
>
> #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>
> / {
> interrupt-parent = <&intc>;
>@@ -984,6 +985,24 @@
> #mbox-cells = <1>;
> };
>
>+ apps_rsc: rsc at 179c0000 {
>+ label = "apps_rsc";
>+ compatible = "qcom,rpmh-rsc";
>+ reg = <0x179c0000 0x10000>,
>+ <0x179d0000 0x10000>,
>+ <0x179e0000 0x10000>;
>+ reg-names = "drv-0", "drv-1", "drv-2";
>+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>+ qcom,tcs-offset = <0xd00>;
>+ qcom,drv-id = <2>;
>+ qcom,tcs-config = <SLEEP_TCS 3>,
>+ <WAKE_TCS 3>,
>+ <ACTIVE_TCS 2>,
>+ <CONTROL_TCS 1>;
Sorry, my example had this incorrect order and I just noticed this. We
will need to fix the example as well.
The first TCS should be ACTIVE_TCS, then followed by SLEEP_TCS and
WAKE_TCS. This order is important and should match what is set in the
firmware.
qcom,tcs-config = <ACTIVE_TCS 2>,
<SLEEP_TCS 3>,
<WAKE_TCS 3>,
<CONTROL_TCS 1>;
While the above configuration would work for now, it would fail, when we
enable system low power modes, which would use TCSes 2-7 for sleep and
wake set transitions from the firmware.
Thanks,
Lina
>+ };
>+
> intc: interrupt-controller at 17a00000 {
> compatible = "arm,gic-v3";
> #address-cells = <1>;
>--
>2.18.0.rc1.244.gcf134e6275-goog
>
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Douglas Anderson @ 2018-06-18 21:50 UTC (permalink / raw)
To: linux-arm-kernel
This adds the rpmh-rsc node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Fixed ordering of tcs-config as per Lina.
arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cd308b84bed7..43a182fb42c9 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
/ {
interrupt-parent = <&intc>;
@@ -984,6 +985,24 @@
#mbox-cells = <1>;
};
+ apps_rsc: rsc at 179c0000 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x179c0000 0x10000>,
+ <0x179d0000 0x10000>,
+ <0x179e0000 0x10000>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = <ACTIVE_TCS 2>,
+ <SLEEP_TCS 3>,
+ <WAKE_TCS 3>,
+ <CONTROL_TCS 1>;
+ };
+
intc: interrupt-controller at 17a00000 {
compatible = "arm,gic-v3";
#address-cells = <1>;
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: sdm845: Add rpmh-clk node
From: Douglas Anderson @ 2018-06-18 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618215051.156270-1-dianders@chromium.org>
This adds the rpmh-clk node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: to apply this patch cleanly, apply it atop:
arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
https://patchwork.kernel.org/patch/10462691/
Changes in v2: None
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 43a182fb42c9..00722b533a92 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
*/
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
+#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -1001,6 +1002,11 @@
<SLEEP_TCS 3>,
<WAKE_TCS 3>,
<CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sdm845-rpmh-clk";
+ #clock-cells = <1>;
+ };
};
intc: interrupt-controller at 17a00000 {
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Doug Anderson @ 2018-06-18 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618212414.GI21724@codeaurora.org>
Hi,
On Mon, Jun 18, 2018 at 2:24 PM, Lina Iyer <ilina@codeaurora.org> wrote:
> On Mon, Jun 18 2018 at 14:56 -0600, Douglas Anderson wrote:
>>
>> This adds the rpmh-rsc node to sdm845 based on the examples in the
>> bindings.
>>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> ---
>>
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index cd308b84bed7..19b006293d3b 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -7,6 +7,7 @@
>>
>> #include <dt-bindings/clock/qcom,gcc-sdm845.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>>
>> / {
>> interrupt-parent = <&intc>;
>> @@ -984,6 +985,24 @@
>> #mbox-cells = <1>;
>> };
>>
>> + apps_rsc: rsc at 179c0000 {
>> + label = "apps_rsc";
>> + compatible = "qcom,rpmh-rsc";
>> + reg = <0x179c0000 0x10000>,
>> + <0x179d0000 0x10000>,
>> + <0x179e0000 0x10000>;
>> + reg-names = "drv-0", "drv-1", "drv-2";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> + qcom,tcs-offset = <0xd00>;
>> + qcom,drv-id = <2>;
>> + qcom,tcs-config = <SLEEP_TCS 3>,
>> + <WAKE_TCS 3>,
>> + <ACTIVE_TCS 2>,
>> + <CONTROL_TCS 1>;
>
> Sorry, my example had this incorrect order and I just noticed this. We
> will need to fix the example as well.
>
> The first TCS should be ACTIVE_TCS, then followed by SLEEP_TCS and
> WAKE_TCS. This order is important and should match what is set in the
> firmware.
>
> qcom,tcs-config = <ACTIVE_TCS 2>,
> <SLEEP_TCS 3>,
> <WAKE_TCS 3>,
> <CONTROL_TCS 1>;
>
> While the above configuration would work for now, it would fail, when we
> enable system low power modes, which would use TCSes 2-7 for sleep and
> wake set transitions from the firmware.
Since I'm not expecting lots more feedback, I've gone ahead and sent
v2 with this fix.
-Doug
^ permalink raw reply
* Dynamic ftrace self test broken on ARM
From: Steven Rostedt @ 2018-06-18 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65fb14b356bc0a414f1fe5cf5c6eb395@agner.ch>
On Mon, 18 Jun 2018 23:09:04 +0200
Stefan Agner <stefan@agner.ch> wrote:
> Hi,
>
> On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
> ftrace self test. I tried v4.18-rc1 first, but it seems that at least
> also v4.17 is affected.
>
> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 19112604462750000 ns
> futex hash table entries: 512 (order: 3, 32768 bytes)
> Running postponed tracer tests:
> Testing tracer function: PASSED
> Testing dynamic ftrace: PASSED
> Testing dynamic ftrace ops #1:
> (1 0 1 0 0)
> (1 1 2 0 0)
> (2 1 3 0 93620)
> (2 2 4 0 93807) PASSED
> Testing dynamic ftrace ops #2:
> (1 0 1 96630 0)
> (1 1 2 96804 0)
> (2 1 3 1 342)
> (2 2 4 121 462) PASSED
> Testing ftrace recursion: PASSED
> Testing ftrace recursion safe: PASSED
> Testing ftrace regs: PASSED
> Testing tracer nop: PASSED
> Testing tracer function_graph: PASSED
> pinctrl core: initialized pinctrl subsystem
> Unable to handle kernel paging request at virtual address c0ca14e4
> pgd = (ptrval)
> [c0ca14e4] *pgd=80c1940e(bad)
> Internal error: Oops: 80d [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> PC is at skb_init+0x50/0x7c
> LR is at kmem_cache_create_usercopy+0x10c/0x320
> pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
> sp : dc11be98 ip : dc11be58 fp : dc11bebc
> r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
> r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
> r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 8000406a DAC: 00000051
> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xdc11be98 to 0xdc11c000)
> be80: 00000018
> 00000030
> bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
> c0e63b3c
> bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
> c0e63a1c
> bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
> c0bf3c7c
> bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
> c0fa7140
> bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
> dc11bf48
> bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
> c0f09fc0
> bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
> 00000000
> bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
> c0989c58
> bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
> 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
> 00000000
> [<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
> [<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
> [<c0103080>] (do_one_initcall) from [<c0e011d8>]
> (kernel_init_freeable+0x270/0x308)
> [<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
> (kernel_init+0x18/0x124)
> [<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xdc11bfb0 to 0xdc11bff8)
> bfa0: 00000000 00000000 00000000
> 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
> ---[ end trace fff84001ba23c9c9 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 2.292924]
> CPU1: stopping
> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> [<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
> [<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
> [<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
> [<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
> [<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
> Exception stack(0xdc14df18 to 0xdc14df60)
> df00: 00000000
> 00000324
> df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
> c0f05d80
> df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
> ffffffff
> [<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
> [<c010993c>] (arch_cpu_idle) from [<c098f81c>]
> (default_idle_call+0x30/0x3c)
> [<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
> [<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
> [<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
> (secondary_start_kernel+0x158/0x164)
> [<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> ]---
>
> I tested with imx_v6_v7_defconfig and enabled the following options:
>
> CONFIG_DYNAMIC_FTRACE=y
>
> CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
>
> CONFIG_FTRACE_MCOUNT_RECORD=y
>
> CONFIG_FTRACE_SELFTEST=y
>
> CONFIG_FTRACE_STARTUP_TEST=y
>
> I guess startup test should leave the kernel unencumbered?
>
>
I'm guessing that it boots fine with CONFIG_FTRACE_STARTUP_TEST=n? Can
you try disable the tracers to see if it's the function graph or
function tracer that is causing the issue? That is, turn off
CONFIG_FUNCTION_GRAPH_TRACER and test it again, and if that crashes,
turn off CONFIG_FUNCTION_TRACER to make sure the crash goes away there
too.
-- Steve
^ permalink raw reply
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Eric Biggers @ 2018-06-18 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8OnTY7ezbkU5-EzVHp3vvPr_okkOoWfOjkdxhSqSqhBg@mail.gmail.com>
On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote:
> >>>>> +
> >>>>> + // One-time XTS preparation
> >>>>> +
> >>>>> + /*
> >>>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
> >>>>> + * performance, this space is aligned to a 16-byte boundary so that we
> >>>>> + * can use the load/store instructions that declare 16-byte alignment.
> >>>>> + */
> >>>>> + sub sp, #128
> >>>>> + bic sp, #0xf
> >>>>
> >>>>
> >>>> This fails here when building with CONFIG_THUMB2_KERNEL=y
> >>>>
> >>>> AS arch/arm/crypto/speck-neon-core.o
> >>>>
> >>>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
> >>>>
> >>>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
> >>>> `bic sp,#0xf'
> >>>>
> >>>> In a quick hack this change seems to address it:
> >>>>
> >>>>
> >>>> - sub sp, #128
> >>>> - bic sp, #0xf
> >>>> + mov r6, sp
> >>>> + sub r6, #128
> >>>> + bic r6, #0xf
> >>>> + mov sp, r6
> >>>>
> >>>> But there is probably a better solution to address this.
> >>>>
> >>>
> >>> Given that there is no NEON on M class cores, I recommend we put something like
> >>>
> >>> THUMB(bx pc)
> >>> THUMB(nop.w)
> >>> THUMB(.arm)
> >>>
> >>> at the beginning and be done with it.
> >>
> >> I mean nop.n or just nop, of course, and we may need a '.align 2' at
> >> the beginning as well.
> >
> > Wouldn't it be preferable to have it assemble it in Thumb2 too? It seems
> > that bic sp,#0xf is the only issue...
> >
>
> Well, in general, yes. In the case of NEON code, not really, since the
> resulting code will not be smaller anyway, because the Thumb2 NEON
> opcodes are all 4 bytes. Also, Thumb2-only cores don't have NEON
> units, so all cores that this code can run on will be able to run in
> ARM mode.
>
> So from a maintainability pov, having code that only assembles in one
> way is better than having code that must compile both to ARM and to
> Thumb2 opcodes.
>
> Just my 2 cents, anyway.
I don't have too much of a preference, though Stefan's suggested 4 instructions
can be reduced to 3, which also matches what aes-neonbs-core.S does:
sub r12, sp, #128
bic r12, #0xf
mov sp, r12
Ard, is the following what you're suggesting instead?
diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
index 3c1e203e53b9..c989ce3dc057 100644
--- a/arch/arm/crypto/speck-neon-core.S
+++ b/arch/arm/crypto/speck-neon-core.S
@@ -8,6 +8,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
.text
.fpu neon
@@ -233,6 +234,12 @@
* nonzero multiple of 128.
*/
.macro _speck_xts_crypt n, decrypting
+
+ .align 2
+ THUMB(bx pc)
+ THUMB(nop)
+ THUMB(.arm)
+
push {r4-r7}
mov r7, sp
@@ -413,6 +420,8 @@
mov sp, r7
pop {r4-r7}
bx lr
+
+ THUMB(.thumb)
.endm
ENTRY(speck128_xts_encrypt_neon)
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Lina Iyer @ 2018-06-18 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618215051.156270-1-dianders@chromium.org>
Thanks for the quick spin Doug.
On Mon, Jun 18 2018 at 15:51 -0600, Douglas Anderson wrote:
>This adds the rpmh-rsc node to sdm845 based on the examples in the
>bindings.
>
>Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Lina Iyer <ilina@codeaurora.org>
>---
>
>Changes in v2:
>- Fixed ordering of tcs-config as per Lina.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>index cd308b84bed7..43a182fb42c9 100644
>--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>@@ -7,6 +7,7 @@
>
> #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>
> / {
> interrupt-parent = <&intc>;
>@@ -984,6 +985,24 @@
> #mbox-cells = <1>;
> };
>
>+ apps_rsc: rsc at 179c0000 {
>+ label = "apps_rsc";
>+ compatible = "qcom,rpmh-rsc";
>+ reg = <0x179c0000 0x10000>,
>+ <0x179d0000 0x10000>,
>+ <0x179e0000 0x10000>;
>+ reg-names = "drv-0", "drv-1", "drv-2";
>+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>+ qcom,tcs-offset = <0xd00>;
>+ qcom,drv-id = <2>;
>+ qcom,tcs-config = <ACTIVE_TCS 2>,
>+ <SLEEP_TCS 3>,
>+ <WAKE_TCS 3>,
>+ <CONTROL_TCS 1>;
>+ };
>+
> intc: interrupt-controller at 17a00000 {
> compatible = "arm,gic-v3";
> #address-cells = <1>;
>--
>2.18.0.rc1.244.gcf134e6275-goog
>
^ permalink raw reply
* [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS
From: Ard Biesheuvel @ 2018-06-18 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618215657.GB8022@google.com>
On 18 June 2018 at 23:56, Eric Biggers <ebiggers@google.com> wrote:
> On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote:
>> >>>>> +
>> >>>>> + // One-time XTS preparation
>> >>>>> +
>> >>>>> + /*
>> >>>>> + * Allocate stack space to store 128 bytes worth of tweaks. For
>> >>>>> + * performance, this space is aligned to a 16-byte boundary so that we
>> >>>>> + * can use the load/store instructions that declare 16-byte alignment.
>> >>>>> + */
>> >>>>> + sub sp, #128
>> >>>>> + bic sp, #0xf
>> >>>>
>> >>>>
>> >>>> This fails here when building with CONFIG_THUMB2_KERNEL=y
>> >>>>
>> >>>> AS arch/arm/crypto/speck-neon-core.o
>> >>>>
>> >>>> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>> >>>>
>> >>>> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
>> >>>> `bic sp,#0xf'
>> >>>>
>> >>>> In a quick hack this change seems to address it:
>> >>>>
>> >>>>
>> >>>> - sub sp, #128
>> >>>> - bic sp, #0xf
>> >>>> + mov r6, sp
>> >>>> + sub r6, #128
>> >>>> + bic r6, #0xf
>> >>>> + mov sp, r6
>> >>>>
>> >>>> But there is probably a better solution to address this.
>> >>>>
>> >>>
>> >>> Given that there is no NEON on M class cores, I recommend we put something like
>> >>>
>> >>> THUMB(bx pc)
>> >>> THUMB(nop.w)
>> >>> THUMB(.arm)
>> >>>
>> >>> at the beginning and be done with it.
>> >>
>> >> I mean nop.n or just nop, of course, and we may need a '.align 2' at
>> >> the beginning as well.
>> >
>> > Wouldn't it be preferable to have it assemble it in Thumb2 too? It seems
>> > that bic sp,#0xf is the only issue...
>> >
>>
>> Well, in general, yes. In the case of NEON code, not really, since the
>> resulting code will not be smaller anyway, because the Thumb2 NEON
>> opcodes are all 4 bytes. Also, Thumb2-only cores don't have NEON
>> units, so all cores that this code can run on will be able to run in
>> ARM mode.
>>
>> So from a maintainability pov, having code that only assembles in one
>> way is better than having code that must compile both to ARM and to
>> Thumb2 opcodes.
>>
>> Just my 2 cents, anyway.
>
> I don't have too much of a preference, though Stefan's suggested 4 instructions
> can be reduced to 3, which also matches what aes-neonbs-core.S does:
>
> sub r12, sp, #128
> bic r12, #0xf
> mov sp, r12
>
> Ard, is the following what you're suggesting instead?
>
Yes, but after looking at the actual code, I prefer the change above.
The access occurs only once, not in the loop so the additional
instructions should not affect performance.
Apologies for the noise.
> diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
> index 3c1e203e53b9..c989ce3dc057 100644
> --- a/arch/arm/crypto/speck-neon-core.S
> +++ b/arch/arm/crypto/speck-neon-core.S
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/linkage.h>
> +#include <asm/assembler.h>
>
> .text
> .fpu neon
> @@ -233,6 +234,12 @@
> * nonzero multiple of 128.
> */
> .macro _speck_xts_crypt n, decrypting
> +
> + .align 2
> + THUMB(bx pc)
> + THUMB(nop)
> + THUMB(.arm)
> +
> push {r4-r7}
> mov r7, sp
>
> @@ -413,6 +420,8 @@
> mov sp, r7
> pop {r4-r7}
> bx lr
> +
> + THUMB(.thumb)
> .endm
>
> ENTRY(speck128_xts_encrypt_neon)
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add 96boards RK3399 Ficus board
From: Ezequiel Garcia @ 2018-06-18 22:08 UTC (permalink / raw)
To: linux-arm-kernel
The RK3399 Ficus board is an Enterprise Edition board
manufactured by Vamrs Ltd., based on the Rockchip RK3399 SoC.
The board exposes a bunch of nice peripherals, including
SATA, HDMI, MIPI CSI, Ethernet, WiFi, USB 2.0, USB 3.0
and PCIe.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
I am not including USB support because I cannot seem
to make it work.
[ 1.677293] dwc3 fe800000.dwc3: Failed to get clk 'ref': -2
[ 1.677937] dwc3 fe800000.dwc3: Configuration mismatch. dr_mode forced to host
[ 1.678602] dwc3 fe800000.dwc3: failed to initialize core
[ 1.679409] dwc3 fe900000.dwc3: Failed to get clk 'ref': -2
[ 1.679988] dwc3 fe900000.dwc3: failed to initialize core
I am under the impression it is related to:
commit fe8abf332b8f66868013cfcd6bfe727136a2ab5f
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Wed May 16 11:41:07 2018 +0900
usb: dwc3: support clocks and resets for DWC3 core
Any ideas? Would like to sort out the USB issue before
merging.
Also, I should probably split the rk3399.dtsi change.
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3399-ficus.dts | 564 ++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +
3 files changed, 574 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 48a83f882947..2811fb701f12 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-ficus.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
new file mode 100644
index 000000000000..17471b4b7a14
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -0,0 +1,564 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "96boards RK3399 Ficus";
+ compatible = "vamrs,ficus", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ usb_typec_vbus: usb-typec-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "typec-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ vcc1v8_s0: vcc1v8-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_s0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_drv>;
+ regulator-boot-on;
+ regulator-name = "vcc3v3_pcie";
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 0>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ /* for rockchip boot on */
+ rockchip,pwm_id= <2>;
+ rockchip,pwm_voltage = <900000>;
+
+ vin-supply = <&vcc_sys>;
+ };
+
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ clock-frequency = <400000>;
+
+ vdd_cpu_b: syr827 at 40 {
+ status = "okay";
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator at 41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ fusb0: fusb30x at 22 {
+ vbus-supply = <&usb_typec_vbus>;
+ compatible = "fairchild,fusb302";
+ reg = <0x22>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb0_int>;
+ int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+
+ rk808: pmic at 1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc_sys>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_1v8>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ //regulator-ramp-delay = <6001>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8_dvp: LDO_REG1 {
+ regulator-name = "vcc1v8_dvp";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcca1v8_hdmi";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG3 {
+ regulator-name = "vcca_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_sd: LDO_REG4 {
+ regulator-name = "vcc_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc3v0_sd: LDO_REG5 {
+ regulator-name = "vcc3v0_sd";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcca0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcca0v9_hdmi";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc3v3_s3: SWITCH_REG1 {
+ regulator-name = "vcc3v3_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc3v3_s0: SWITCH_REG2 {
+ regulator-name = "vcc3v3_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc1v8_s0>; /* bt656_gpio2ab_ms */
+ audio-supply = <&vcc1v8_s0>; /* audio_gpio3d4a_ms */
+ sdmmc-supply = <&vcc_sd>; /* sdmmc_gpio4b_ms */
+ gpio1830-supply = <&vcc_3v0>; /* gpio1833_gpio4cd_ms */
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreqn_cpm>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&pinctrl {
+ gmac {
+ rgmii_sleep_pins: rgmii-sleep-pins {
+ rockchip,pins =
+ <3 15 RK_FUNC_GPIO &pcfg_output_low>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_bus1: sdmmc-bus1 {
+ rockchip,pins =
+ <4 8 RK_FUNC_1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins =
+ <4 8 RK_FUNC_1 &pcfg_pull_up_8ma>,
+ <4 9 RK_FUNC_1 &pcfg_pull_up_8ma>,
+ <4 10 RK_FUNC_1 &pcfg_pull_up_8ma>,
+ <4 11 RK_FUNC_1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins =
+ <4 12 RK_FUNC_1 &pcfg_pull_none_18ma>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins =
+ <4 13 RK_FUNC_1 &pcfg_pull_up_8ma>;
+ };
+ };
+
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <1 24 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins =
+ <1 21 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins =
+ <1 17 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins =
+ <1 14 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 27 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ fusb30x {
+ fusb0_int: fusb0-int {
+ rockchip,pins =
+ <1 2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ clock-frequency = <100000000>;
+ clock-freq-min-max = <100000 100000000>;
+ disable-wp;
+ sd-uhs-sdr104;
+ vqmmc-supply = <&vcc_sd>;
+ card-detect-delay = <800>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index adb037cd80fe..7169603590f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1923,6 +1923,11 @@
drive-strength = <12>;
};
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
@@ -1948,6 +1953,10 @@
drive-strength = <13>;
};
+ pcfg_output_low: pcfg-output-low {
+ output-low;
+ };
+
clock {
clk_32k: clk-32k {
rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
--
2.17.1
^ permalink raw reply related
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Mark Salter @ 2018-06-18 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cbc68d5-9a8f-1734-4eea-d1f037927137@infradead.org>
On Mon, 2018-06-18 at 11:04 -0700, Geoff Levand wrote:
> Hi James,
>
> Thanks for all the comments, but my lack of access to an m400 platform, and
> my lack of knowledge about the m400 limits what I can comment on and what I
> can do.
I can take another look at this on an m400 here. I don't believe it is a
memory access to physical space with nothing attached to it. I seem to recall
an errata with xgene-1 where such accesses cause the cpu to halt. But I could
be misremembering that. I have no trouble believing the firmware ras code was
untested. It is probably some boilerplate code built in before ras was supported
in kernel. But the problem occurs early enough in boot where there can't be
that many things that would cause a problem on m400 and not mustang so I'll
look again.
>
> My motivation for submitting this fix was to enable CONFIG_ACPI_APEI in the
> Debian 10 kernel (for the new Cavium ThunderX2 based systems). The Debian
> maintainers wanted to either have an upstream kernel fix for this m400 APEI
> problem or to disable CONFIG_ACPI_APEI. The later would be unfortunate. It
> means users would need to have custom kernels to get APEI support or go
> without.
>
> Comments follow.
>
> On 06/18/2018 09:18 AM, James Morse wrote:
> > On 15/06/18 18:17, Geoff Levand wrote:
> >
> > From:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1574718
> >
> > This is tripped by the ghes_probe() call, it finds an error has already occurred
> > before ghes code is initialized.
> >
> > Does this still happen if you compile without CONFIG_PCI? (that is easily half
> > the dmesg that has happened before this point).
> > Disabling CONFIG_EFIVAR_FS would be interesting too, as that is firmware-code we
> > can't fix bugs in.
>
> Sorry, no m400 to test these on, but looking at the code, I would say it doesn't
> occur if CONFIG_PCI=n.
>
> > Your argument here is the that the firmware-vendor only build-tested their code,
> > and never noticed it notifies a fatal exception on startup. I find this hard to
> > believe, especially as these systems don't have EL3.
> >
> > It's much more likely a driver is causing this, possibly because of bad data in
> > the firmware tables. I'd like to quirk the driver, so we can fix the next error
> > like this, as opposed to blindly continuing.
>
> That sounds OK, but which driver?
>
> > If it really is firmware, what is it doing that causes this error, and where
> > does it run? Disabling APEI is just reacting after the error has occurred, when
> > we could prevent it happening.
> >
> > I can't reproduce this on a Mustang. I assume its the different ACPI tables, not
> > the kernel-config.
>
> From what I understand this is only on the m400, not the Mustang.
>
> > > I just put together this patch to unify things and have a
> > > common 'upstream' fix.
> >
> > Wouldn't passing 'hest_disable' on the cmdline do the same for all kernel versions?
>
> Yes, the current patch essentially just sets hest_disable when an m400 is
> detected. The cmdline work-around is what some have been using, but is
> not an acceptable solution for the Debian maintainers. See
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900581
>
> > > On 06/15/2018 04:14 AM, James Morse wrote:
> > > > On 13/06/18 19:22, Geoff Levand wrote:
> > > > > Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
> > > > > a work-around for HPE ProLiant m400 APEI firmware problems.
> > > > >
> > > > > The work-around disables APEI when CONFIG_ACPI_APEI is set and
> > > > > m400 firmware is detected. Without this fixup m400 systems
> > > > > experience errors like these on startup:
> > > > >
> > > > > [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
> > > > > [Hardware Error]: event severity: fatal
> > > > > [Hardware Error]: Error 0, type: fatal
> > > > > [Hardware Error]: section_type: memory error
> > > > > [Hardware Error]: error_status: 0x0000000000001300
> > > >
> > > > "Access to a memory address which is not mapped to any component"
> > > >
> > > >
> > > > > [Hardware Error]: error_type: 10, invalid address
> > > > > Kernel panic - not syncing: Fatal hardware error!
> > > >
> > > > Why is this a problem?
> > > >
> > > > Surely this is a valid description of an error.
> > >
> > > The firmware bug causes this failure, not bad hardware.
> >
> > I'm not talking about bad hardware here. What I think is happening is a software
> > bug is causing the CPU to make a bad access, which the RAS mechanism is
> > reporting like this because software would never be stupid enough to access an
> > address which is not mapped to any component! The RAS stuff believes this must
> > be address corruption.
> >
> > I think this is a linux-driver bug, or a typo in the firmware tables, that cause
> > $non_existent_address to be mapped and probed.
>
> From what I know about it the problem is in the access of the firmware tables,
> and that corrupted data is retrieved. But I am not sure, as there are so many
> reported m400 firmware problems it is hard to tell what exactly is what.
>
> > > > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > > > index 7b09487ff8fb..3c315c2c7476 100644
> > > > > --- a/arch/arm64/kernel/acpi.c
> > > > > +++ b/arch/arm64/kernel/acpi.c
> > > > > +
> > > > > + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
> > > > > + return;
> > > > > +
> > > > > + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
> > > > > +
> > > > > + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
> > > > > + !strncmp(header->oem_table_id, "ProLiant", 8) &&
> > > > You should match the affected range of OEM table revisions too, that way a
> > > > firmware upgrade should start working, instead of being permanently disabled
> > > > because we think its unlikely.
> > >
> > > The m400 has reached end of life. No one really expects to see any firmware
> > > update. I don't know what the effected OEM table revisions are, and I don't
> > > think there is an active platform maintainer who could give that info either.
> > >
> > > If someone can provide the info. I'll update the fix.
> >
> > We can start with the version you have. You mention distro's have their own
> > fixes, hopefully they can supply the missing range of values.
>
> It seems you are living in a dream world...
>
> > > > > + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
> > > >
> > > > How is the CPU implementer relevant?
> > >
> > > That was just a copy of what other fixes had. Should I remove it?
> >
> > The conclusion in the rest of this thread was HPE also produces ProLiant boxes
> > with a (presumably) identical HEST, but a totally different architecture.
> >
> > Matching the DMI platform name as well would work round this. (or somewhere only
> > arm64 builds, with an appropriate comment in case we move it).
> >
> >
> > > > Nothing arch-specific here. You're adding this to arch/arm64 because
> > > > drivers/acpi/apei doesn't have an existing quirks table?
> > >
> > > There was a fix submitted that had it in drivers/acpi/scan.c, but the
> > > ACPI maintainer said he didn't want the fix in the main ACPI code.
> >
> > Specifically about a HID-hack in the core device enumeration code, as opposed to
> > in the driver that claims it.
> >
> >
> > > See:
> > >
> > > https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)
> > > 'some X-Gene based platforms (Mustang and M400) with invalid DSDT.'
> >
> > ... sounds familiar ...
> >
> > And:
> > https://bugzilla.redhat.com/attachment.cgi?id=1144903&action=diff
> >
> > Fixes a typo in firmware description of the GIC.
> >
> > Why do we think this is a new kind of firmware bug, and not a repeat of the last
> > two? The only difference is this is being caught by the RAS code.
>
> It could very well be.
>
> > > The m400 is an arm64 platform, so it seems most appropriate to
> > > have it in arch/arm64/kernel/acpi.c.
> >
> > We don't keep all drivers under arch/arm64, I'd really like to find the driver
> > that is causing this, and quirk it there.
> >
> > If we have to bolt the hest-stable-door, drivers/acpi/apei/hest.c looks better,
> > it at least doesn't have to bodge around hest_disabled not being exposed in a
> > compatible way. If the maintainer objects, (as x86 hasn't had to do this yet),
> > then we can try drivers/acpi/arm64/hest_quirks.c.
>
> We need to call acpi_fixup_m400_quirks early enough to get hest_disable set
> before it is used. To do that from drivers/acpi/ code we would need have
> it as arch_initcall, or still call it from acpi_boot_table_init. I think
> having it as a static routine and the call in arch/arm64/kernel/acpi.c is
> cleaner.
>
> > When only once architecture had to quirk stuff based on the ACPI tables, the
> > arch-code was a suitable dumping ground. Now there is more than one, we should
> > do things in a way they are useful to both architectures.
>
> As I mentioned in the opening, I don't have access to m400 equipment. There is
> little I can do. I could move acpi_fixup_m400_quirks into
> drivers/acpi/apei/hest.c and submit that to the ACPI maintainer, but based on
> https://lkml.org/lkml/2018/4/19/1020, I don't think it would be accepted.
>
> -Geoff
>
^ permalink raw reply
* [PATCH] crypto: arm/speck - fix building in Thumb2 mode
From: Eric Biggers @ 2018-06-18 22:33 UTC (permalink / raw)
To: linux-arm-kernel
Building the kernel with CONFIG_THUMB2_KERNEL=y and
CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
arch/arm/crypto/speck-neon-core.S: Assembler messages:
arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here -- `bic sp,#0xf'
arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here -- `bic sp,#0xf'
The problem is that the 'bic' instruction can't operate on the 'sp'
register in Thumb2 mode. Fix it by using a temporary register. This
isn't in the main loop, so the performance difference is negligible.
This also matches what aes-neonbs-core.S does.
Reported-by: Stefan Agner <stefan@agner.ch>
Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS")
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
arch/arm/crypto/speck-neon-core.S | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
index 3c1e203e53b9..57caa742016e 100644
--- a/arch/arm/crypto/speck-neon-core.S
+++ b/arch/arm/crypto/speck-neon-core.S
@@ -272,9 +272,11 @@
* Allocate stack space to store 128 bytes worth of tweaks. For
* performance, this space is aligned to a 16-byte boundary so that we
* can use the load/store instructions that declare 16-byte alignment.
+ * For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
*/
- sub sp, #128
- bic sp, #0xf
+ sub r12, sp, #128
+ bic r12, #0xf
+ mov sp, r12
.if \n == 64
// Load first tweak
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 1/2] ARM: imx: add standby mode suspend for i.MX6SLL
From: Shawn Guo @ 2018-06-19 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527732369-19740-1-git-send-email-Anson.Huang@nxp.com>
On Thu, May 31, 2018 at 10:06:08AM +0800, Anson Huang wrote:
> Add standby mode suspend for i.MX6SLL, when
> linux kernel suspend, SoC will enter STOP mode
> with ARM core power on.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH V2 1/3] ARM: imx: add L2 page power control for GPC
From: Shawn Guo @ 2018-06-19 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527993226-19587-1-git-send-email-Anson.Huang@nxp.com>
On Sun, Jun 03, 2018 at 10:33:44AM +0800, Anson Huang wrote:
> Some platforms like i.MX6UL/i.MX6SLL have L2
> page power control in GPC, it needs to be
> disabled if ARM is power gated and L2 is NOT
> flushed, add GPC interface to control it.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx53-qsb: Let the codec control MCLK pinctrl
From: Shawn Guo @ 2018-06-19 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528160209-2849-1-git-send-email-festevam@gmail.com>
On Mon, Jun 04, 2018 at 09:56:49PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> sgtl5000 codec needs MCLK clock to be present so that it can
> successfully read/write via I2C.
>
> In the case of imx53-qsb, MCLK is provided via
> MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK pad.
>
> Move the MCLK pinctrl from hog group to the codec group, so that the
> codec clock can be present prior to reading the codec ID.
Are you saying that pins in hog group hasn't been set up yet when codec
driver probes?
Shawn
>
> This avoids the following sgtl5000 probe error:
>
> sgtl5000 1-000a: Error reading chip id -6
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx53-qsb-common.dtsi | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi b/arch/arm/boot/dts/imx53-qsb-common.dtsi
> index ef7658a..7423d46 100644
> --- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
> +++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
> @@ -153,7 +153,6 @@
> imx53-qsb {
> pinctrl_hog: hoggrp {
> fsl,pins = <
> - MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x80000000
> MX53_PAD_GPIO_8__GPIO1_8 0x80000000
> MX53_PAD_PATA_DATA14__GPIO2_14 0x80000000
> MX53_PAD_PATA_DATA15__GPIO2_15 0x80000000
> @@ -180,6 +179,12 @@
> >;
> };
>
> + pinctrl_codec: codecgrp {
> + fsl,pins = <
> + MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x1c4
> + >;
> + };
> +
> pinctrl_esdhc1: esdhc1grp {
> fsl,pins = <
> MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
> @@ -310,6 +315,8 @@
> sgtl5000: codec at a {
> compatible = "fsl,sgtl5000";
> reg = <0x0a>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_codec>;
> #sound-dai-cells = <0>;
> VDDA-supply = <®_3p2v>;
> VDDIO-supply = <®_3p2v>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] mtd: atmel-quadspi: add suspend/resume hooks
From: Marek Vasut @ 2018-06-19 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0be344a2-9878-2b92-9436-bc2f4d4fd6e0@microchip.com>
On 06/18/2018 02:00 PM, Claudiu Beznea wrote:
>
>
> On 18.06.2018 12:53, Marek Vasut wrote:
>> On 06/18/2018 11:49 AM, Boris Brezillon wrote:
>>> Hi Claudiu,
>>>
>>> The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
>>> to send a new version just for that, I'll fix it when applying the
>>> patch.
>>>
> Hi Boris,
>
> Thank you!
>
>>> Looks good otherwise. Marek, any objection? If not, can you add your
>>> Acked-by?
>>
>> Will this work if you have ie. ubifs mounted on that QSPI NOR and you
>> suspect and resume during IO ? I think it would, but just curious if
>> there could be some problem.
>
> Hi Marek,
>
> I tested only with read/writes while suspending, simple scripts, but not
> having ubifs mounted on QSPI NOR. I will double check also with ubifs
> mounted on QSPI NOR and come back with the results.
Thanks. I think it's gonna be OK, but let's just be sure.
Make sure to disable 4K sector support when fiddling with UBI/UBIFS on
QSPI NOR.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 15/20] dts: arm: imx7{d,s}: Update coresight binding for hardware ports
From: Shawn Guo @ 2018-06-19 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528235011-30691-16-git-send-email-suzuki.poulose@arm.com>
Hi Stefan,
Can you take a look at the patch? Thanks.
Shawn
On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
> Switch to the updated coresight bindings.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> arch/arm/boot/dts/imx7d.dtsi | 5 ++++-
> arch/arm/boot/dts/imx7s.dtsi | 41 ++++++++++++++++++++++++++++++-----------
> 2 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 200714e..5faff17 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -87,7 +87,9 @@
>
> port {
> etm1_out_port: endpoint {
> + direction = <1>;
> remote-endpoint = <&ca_funnel_in_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -174,8 +176,9 @@
> port at 1 {
> reg = <1>;
> ca_funnel_in_port1: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&etm1_out_port>;
> + coresight,hwid = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 4d42335..8e90915 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -151,23 +151,28 @@
> port at 0 {
> reg = <0>;
> replicator_out_port0: endpoint {
> + direction = <1>;
> remote-endpoint = <&tpiu_in_port>;
> + coresight,hwid = <0>;
> };
> };
>
> port at 1 {
> reg = <1>;
> replicator_out_port1: endpoint {
> + direction = <1>;
> remote-endpoint = <&etr_in_port>;
> + coresight,hwid = <1>;
> };
> };
>
> /* replicator input port */
> port at 2 {
> - reg = <0>;
> + reg = <2>;
> replicator_in_port0: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&etf_out_port>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -203,16 +208,19 @@
> port at 0 {
> reg = <0>;
> ca_funnel_in_port0: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&etm0_out_port>;
> + coresight,hwid = <0>;
> };
> };
>
> /* funnel output port */
> port at 2 {
> - reg = <0>;
> + reg = <2>;
> ca_funnel_out_port0: endpoint {
> + direction = <1>;
> remote-endpoint = <&hugo_funnel_in_port0>;
> + coresight,hwid = <0>;
> };
> };
>
> @@ -229,7 +237,9 @@
>
> port {
> etm0_out_port: endpoint {
> + direction = <1>;
> remote-endpoint = <&ca_funnel_in_port0>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -248,22 +258,26 @@
> port at 0 {
> reg = <0>;
> hugo_funnel_in_port0: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&ca_funnel_out_port0>;
> + coresight,hwid = <0>;
> };
> };
>
> port at 1 {
> reg = <1>;
> hugo_funnel_in_port1: endpoint {
> - slave-mode; /* M4 input */
> + direction = <0>; /* M4 input */
> + coresight,hwid = <1>;
> };
> };
>
> port at 2 {
> - reg = <0>;
> + reg = <2>;
> hugo_funnel_out_port0: endpoint {
> + direction = <1>;
> remote-endpoint = <&etf_in_port>;
> + coresight,hwid = <0>;
> };
> };
>
> @@ -284,15 +298,18 @@
> port at 0 {
> reg = <0>;
> etf_in_port: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&hugo_funnel_out_port0>;
> + coresight,hwid = <0>;
> };
> };
>
> port at 1 {
> - reg = <0>;
> + reg = <1>;
> etf_out_port: endpoint {
> + direction = <1>;
> remote-endpoint = <&replicator_in_port0>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -306,8 +323,9 @@
>
> port {
> etr_in_port: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&replicator_out_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -320,8 +338,9 @@
>
> port {
> tpiu_in_port: endpoint {
> - slave-mode;
> + direction = <0>;
> remote-endpoint = <&replicator_out_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: RDU2: correct touchscreen axis inversion
From: Shawn Guo @ 2018-06-19 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606093045.9215-1-l.stach@pengutronix.de>
On Wed, Jun 06, 2018 at 11:30:45AM +0200, Lucas Stach wrote:
> The RMI4 touchscreen driver applied inversion and axis swap in the
> wrong order, violating the DT binding for those properties. This is
> fixed now, so correct the RDU2 DT to apply the inversion to the
> correct axis.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: i.MX6: imx6dl-mamoj: Add parallel display support
From: Shawn Guo @ 2018-06-19 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607134748.2970-1-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:17:46PM +0530, Jagan Teki wrote:
> This patch adds parallel display support for i.MX6DL Mamoj board
> along with relevant backlight through pwm.
>
> LCD power sequence is added by 'Michael Trimarchi'.
>
> Signed-off-by: Simone CIANNI <simone.cianni@bticino.it>
> Signed-off-by: Raffaele RECALCATI <raffaele.recalcati@bticino.it>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes for v2:
> - collect Fabio r-w-b tag
>
> arch/arm/boot/dts/imx6dl-mamoj.dts | 185 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 185 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-mamoj.dts b/arch/arm/boot/dts/imx6dl-mamoj.dts
> index 6b2d29138bed..ed9050c5dbcc 100644
> --- a/arch/arm/boot/dts/imx6dl-mamoj.dts
> +++ b/arch/arm/boot/dts/imx6dl-mamoj.dts
> @@ -6,11 +6,133 @@
>
> /dts-v1/;
>
> +#include <dt-bindings/gpio/gpio.h>
> #include "imx6dl.dtsi"
>
> / {
> model = "BTicino i.MX6DL Mamoj board";
> compatible = "bticino,imx6dl-mamoj", "fsl,imx6dl";
> +
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pwms = <&pwm3 0 25000>; /* 25000ns -> 40kHz */
> + brightness-levels = <0 4 8 16 32 64 128 160 192 224 255>;
> + default-brightness-level = <7>;
> + };
> +
> + lcd_display: disp0 {
'display' for node name.
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1_lcdif>;
> + status = "okay";
> +
> + port at 0 {
> + reg = <0>;
> +
> + lcd_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };
> +
> + panel-lcd {
> + compatible = "rocktech,rk070er9427";
> + backlight = <&backlight_lcd>;
> + power-supply = <®_lcd_lr>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcd_power>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +
> + reg_lcd_3v3: regulator-lcd-dvdd {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-dvdd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 1 0>;
> + enable-active-high;
> + startup-delay-us = <21000>;
> + };
> +
> + reg_lcd_power: regulator-lcd-power {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-enable";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 6 0>;
> + enable-active-high;
> + vin-supply = <®_lcd_3v3>;
> + };
> +
> + reg_lcd_vgl: regulator-lcd-vgl {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-vgl";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio2 20 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <6000>;
> + enable-active-high;
> + vin-supply = <®_lcd_power>;
> + };
> +
> + reg_lcd_vgh: regulator-lcd-vgh {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-vgh";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <6000>;
> + enable-active-high;
> + vin-supply = <®_lcd_avdd>;
> + };
> +
> + reg_lcd_vcom: regulator-lcd-vcom {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-vcom";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio4 14 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <11000>;
> + enable-active-high;
> + vin-supply = <®_lcd_vgh>;
> + };
> +
> + reg_lcd_lr: regulator-lcd-lr {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-lr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <®_lcd_vcom>;
> + };
> +
> + reg_lcd_avdd: regulator-lcd-avdd {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-avdd";
> + regulator-min-microvolt = <10280000>;
> + regulator-max-microvolt = <10280000>;
> + gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <6000>;
> + enable-active-high;
> + vin-supply = <®_lcd_vgl>;
> + };
> };
>
> &fec {
> @@ -147,6 +269,16 @@
> };
> };
>
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&lcd_display_in>;
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "okay";
> +};
> +
> &uart3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart3>;
> @@ -200,6 +332,59 @@
> >;
> };
>
> + pinctrl_ipu1_lcdif: pinctrlipu1lcdif { /* parallel port 24-bit */
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10 /* VDOUT_PCLK */
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x10
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10 /* VDOUT_HSYNC */
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10 /* VDOUT_VSYNC */
> + MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x80000000 /* VDOUT_RESET */
Use a proper configuration value rather than relying on what
firmware/reset gives.
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x10
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x10
> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x10
> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x10
> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x10
> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x10
> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x10
> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x10
> + >;
> + };
> +
> + pinctrl_lcd_power: lcd_power {
The node name and above pinctrlipu1lcdif is not consistent to other
pinctrl nodes.
Shawn
> + fsl,pins = <
> + MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x40013058 /* EN_LCD33V */
> + MX6QDL_PAD_SD4_DAT5__GPIO2_IO13 0x4001b0b0 /* EN_AVDD */
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x40013058 /* ENVGH */
> + MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x40013058 /* ENVGL */
> + MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x40013058 /* LCD_POWER */
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x40013058 /* EN_VCOM_LCD */
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x40013058 /* LCD_L_R */
> + MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x40013058 /* LCD_U_D */
> + >;
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + >;
> + };
> +
> pinctrl_uart3: uart3grp {
> fsl,pins = <
> MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: i.MX6: imx6dl-mamoj: Add Wifi support
From: Shawn Guo @ 2018-06-19 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607134748.2970-2-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:17:47PM +0530, Jagan Teki wrote:
> Add TI WL18XX Wifi for BTicino i.MX6DL board.
>
> Signed-off-by: Simone CIANNI <simone.cianni@bticino.it>
> Signed-off-by: Raffaele RECALCATI <raffaele.recalcati@bticino.it>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes for v2:
> - collect Fabio r-w-b tag
>
> arch/arm/boot/dts/imx6dl-mamoj.dts | 53 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-mamoj.dts b/arch/arm/boot/dts/imx6dl-mamoj.dts
> index ed9050c5dbcc..5034b086035f 100644
> --- a/arch/arm/boot/dts/imx6dl-mamoj.dts
> +++ b/arch/arm/boot/dts/imx6dl-mamoj.dts
> @@ -133,6 +133,18 @@
> enable-active-high;
> vin-supply = <®_lcd_vgl>;
> };
> +
> + reg_wl18xx_vmmc: regulator-wl18xx-vmcc {
> + compatible = "regulator-fixed";
> + regulator-name = "vwl1807";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wlan>;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&gpio6 21 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <70000>;
> + enable-active-high;
> + };
> };
>
> &fec {
> @@ -285,6 +297,30 @@
> status = "okay";
> };
>
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + bus-width = <4>;
> + vmmc-supply = <®_wl18xx_vmmc>;
> + no-1-8-v;
> + non-removable;
> + wakeup-source;
> + keep-power-in-suspend;
> + cap-power-off-card;
> + max-frequency = <25000000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + wlcore: wlcore at 2 {
> + compatible = "ti,wl1837";
> + reg = <2>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
> + tcxo-clock-frequency = <26000000>;
> + };
> +};
> +
> &usdhc3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc3>;
> @@ -392,6 +428,17 @@
> >;
> };
>
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17069
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10079
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17069
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17069
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17069
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17069
> + >;
> + };
> +
> pinctrl_usdhc3: usdhc3grp {
> fsl,pins = <
> MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> @@ -406,4 +453,10 @@
> MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> >;
> };
> +
> + pinctrl_wlan: wlan {
To be consistent on naming style, 'wlangrp' might be better.
Shawn
> + fsl,pins = <
> + MX6QDL_PAD_RGMII_TD1__GPIO6_IO21 0x4001b0b0
> + >;
> + };
> };
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: i.MX6: imx6dl-mamoj: Add usb host and device support
From: Shawn Guo @ 2018-06-19 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607134748.2970-3-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:17:48PM +0530, Jagan Teki wrote:
> From: Michael Trimarchi <michael@amarulasolutions.com>
>
> Add USB host and device support for BTicino i.MX6DL Mamoj board.
>
> Signed-off-by: Simone CIANNI <simone.cianni@bticino.it>
> Signed-off-by: Raffaele RECALCATI <raffaele.recalcati@bticino.it>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes for v2:
> - collect Fabio r-w-b tag
>
> arch/arm/boot/dts/imx6dl-mamoj.dts | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-mamoj.dts b/arch/arm/boot/dts/imx6dl-mamoj.dts
> index 5034b086035f..a727e1471006 100644
> --- a/arch/arm/boot/dts/imx6dl-mamoj.dts
> +++ b/arch/arm/boot/dts/imx6dl-mamoj.dts
> @@ -134,6 +134,17 @@
> vin-supply = <®_lcd_vgl>;
> };
>
> + reg_usb_host: regulator-usb-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usbhost-vbus";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbhost>;
> + regulator-min-microvolt = <50000000>;
> + regulator-max-microvolt = <50000000>;
> + gpio = <&gpio6 6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> reg_wl18xx_vmmc: regulator-wl18xx-vmcc {
> compatible = "regulator-fixed";
> regulator-name = "vwl1807";
> @@ -297,6 +308,16 @@
> status = "okay";
> };
>
> +&usbh1 {
> + vbus-supply = <®_usb_host>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + dr_mode = "peripheral";
> + status = "okay";
> +};
> +
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -428,6 +449,12 @@
> >;
> };
>
> + pinctrl_usbhost: usbhost {
usbhostgrp.
Shawn
> + fsl,pins = <
> + MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x4001b0b0
> + >;
> + };
> +
> pinctrl_usdhc1: usdhc1grp {
> fsl,pins = <
> MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17069
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support
From: Shawn Guo @ 2018-06-19 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607135133.3104-1-jagan@amarulasolutions.com>
On Thu, Jun 07, 2018 at 07:21:31PM +0530, Jagan Teki wrote:
> i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected
> to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for
> Android and video capture application.
>
> notable features:
> CPU NXP i.MX6 S/DL/D/Q, Up to 4 x Cortex-A9 at 800MHz
> Memory Up to 2 GB DDR3-1066
> Video Interfaces Up to 1 Parallel Up to 2 LVDS HDMI 1.4
> port 8 bit CSI INPUT MIPI-CSI INPUT
> 1 x 10/100 Ethernet interface, 2 x USB, 1 x PCIe, 1 x I2S etc
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Applied all, thanks.
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Shawn Guo @ 2018-06-19 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be8dc197f842d3be31a15315594a25c8ad8f298.1529309235.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 11:15:44AM +0300, Leonard Crestez wrote:
> The following sensors are on I2C3 on the baseboard:
> * isil,isl29023 light sensor
> * fsl,mag3110 magnetometer
> * fsl,mma8451 accelerometer
>
> Added under i2cmux/i2c at 1 because they're not otherwise accessible.
>
> These are all supported by iio with following configs:
> * CONFIG_SENSORS_ISL29018
> * CONFIG_MAG3110
> * CONFIG_MMA8452
>
> Tested with raw reads from iio sysfs.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-sdb: Remove duplicate regulator-can2-3v3
From: Shawn Guo @ 2018-06-19 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abacbb7485b0c9b908eae8ae87be9d8e0eab87b3.1529327283.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 04:11:09PM +0300, Leonard Crestez wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking at schematics it is indeed gpio2 14 connected to the STB pin of
> the CAN transceiver so remove the first definition.
>
> The second definition entirely overrides the first so this already
> worked and this patch results in no DTB change, just a cleanup.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Applied, thanks.
^ 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