* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-17 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-W5VpVrgA=FVZCCevksaRGOVvPdE+B8WkpZc6AE1jOPw@mail.gmail.com>
On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 15 December 2017 at 09:59, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
>> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>>> On 13 December 2017 at 12:16, AKASHI Takahiro
>>> <takahiro.akashi@linaro.org> wrote:
>>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
>>> >> <takahiro.akashi@linaro.org> wrote:
>>> >> > Bhupesh, Ard,
>>> >> >
>>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>>> >> >> Hi Ard, Akashi
>>> >> >>
>>> >> > (snip)
>>> >> >
>>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>>> >> >> identify its own usable memory and exclude, at its boot time, any
>>> >> >> other memory areas that are part of the panicked kernel's memory.
>>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>>> >> >> , for details)
>>> >> >
>>> >> > Right.
>>> >> >
>>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>>> >> >> with the crashkernel memory range:
>>> >> >>
>>> >> >> /* add linux,usable-memory-range */
>>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>>> >> >> address_cells, size_cells);
>>> >> >>
>>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>>> >> >> , for details)
>>> >> >>
>>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>>> >> >> they are marked as System RAM or as RESERVED. As,
>>> >> >> 'linux,usable-memory-range' dt node is patched up only with
>>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>>> >> >>
>>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
>>> >> >> ACPI memory and crashes while trying to access the same:
>>> >> >>
>>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>>> >> >> -r`.img --reuse-cmdline -d
>>> >> >>
>>> >> >> [snip..]
>>> >> >>
>>> >> >> Reserved memory range
>>> >> >> 000000000e800000-000000002e7fffff (0)
>>> >> >>
>>> >> >> Coredump memory ranges
>>> >> >> 0000000000000000-000000000e7fffff (0)
>>> >> >> 000000002e800000-000000003961ffff (0)
>>> >> >> 0000000039d40000-000000003ed2ffff (0)
>>> >> >> 000000003ed60000-000000003fbfffff (0)
>>> >> >> 0000001040000000-0000001ffbffffff (0)
>>> >> >> 0000002000000000-0000002ffbffffff (0)
>>> >> >> 0000009000000000-0000009ffbffffff (0)
>>> >> >> 000000a000000000-000000affbffffff (0)
>>> >> >>
>>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>>> >> >> memory cap'ing passed to the crash kernel inside
>>> >> >> 'arch/arm64/mm/init.c' (see below):
>>> >> >>
>>> >> >> static void __init fdt_enforce_memory_region(void)
>>> >> >> {
>>> >> >> struct memblock_region reg = {
>>> >> >> .size = 0,
>>> >> >> };
>>> >> >>
>>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> >> >>
>>> >> >> if (reg.size)
>>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>>> >> >> comment this out */
>>> >> >> }
>>> >> >
>>> >> > Please just don't do that. It can cause a fatal damage on
>>> >> > memory contents of the *crashed* kernel.
>>> >> >
>>> >> >> 5). Both the above temporary solutions fix the problem.
>>> >> >>
>>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
>>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>>> >> >> fail.
>>> >> >>
>>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>>> >> >> dt node 'linux,usable-memory-range'
>>> >> >
>>> >> > I still don't understand why we need to carry over the information
>>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>>> >> > such regions are free to be reused by the kernel after some point of
>>> >> > initialization. Why does crash dump kernel need to know about them?
>>> >> >
>>> >>
>>> >> Not really. According to the UEFI spec, they can be reclaimed after
>>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>>> >> no longer needs them. Of course, in order to be able to boot a kexec
>>> >> kernel, those regions needs to be preserved, which is why they are
>>> >> memblock_reserve()'d now.
>>> >
>>> > For my better understandings, who is actually accessing such regions
>>> > during boot time, uefi itself or efistub?
>>> >
>>>
>>> No, only the kernel. This is where the ACPI tables are stored. For
>>> instance, on QEMU we have
>>>
>>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>>> 01000013)
>>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>>> BXPC 00000001)
>>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>>> BXPC 00000001)
>>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>>> BXPC 00000001)
>>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>>> BXPC 00000001)
>>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>>> BXPC 00000001)
>>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>>> BXPC 00000001)
>>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>>> BXPC 00000001)
>>>
>>> covered by
>>>
>>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>>> ...
>>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>>
>> OK. I mistakenly understood those regions could be freed after exiting
>> UEFI boot services.
>>
>>>
>>> >> So it seems that kexec does not honour the memblock_reserve() table
>>> >> when booting the next kernel.
>>> >
>>> > not really.
>>> >
>>> >> > (In other words, can or should we skip some part of ACPI-related init code
>>> >> > on crash dump kernel?)
>>> >> >
>>> >>
>>> >> I don't think so. And the change to the handling of ACPI reclaim
>>> >> regions only revealed the bug, not created it (given that other
>>> >> memblock_reserve regions may be affected as well)
>>> >
>>> > As whether we should honor such reserved regions over kexec'ing
>>> > depends on each one's specific nature, we will have to take care one-by-one.
>>> > As a matter of fact, no information about "reserved" memblocks is
>>> > exposed to user space (via proc/iomem).
>>> >
>>>
>>> That is why I suggested (somewhere in this thread?) to not expose them
>>> as 'System RAM'. Do you think that could solve this?
>>
>> Memblock-reserv'ing them is necessary to prevent their corruption and
>> marking them under another name in /proc/iomem would also be good in order
>> not to allocate them as part of crash kernel's memory.
>>
>
> I agree. However, this may not be entirely trivial, since iterating
> over the memblock_reserved table and creating iomem entries may result
> in collisions.
I found a method (using the patch I shared earlier in this thread) to mark these
entries as 'ACPI reclaim memory' ranges rather than System RAM or
reserved regions.
>> But I'm not still convinced that we should export them in useable-
>> memory-range to crash dump kernel. They will be accessed through
>> acpi_os_map_memory() and so won't be required to be part of system ram
>> (or memblocks), I guess.
>
> Agreed. They will be covered by the linear mapping in the boot kernel,
> and be mapped explicitly via ioremap_cache() in the kexec kernel,
> which is exactly what we want in this case.
Now this is what is confusing me. I don't see the above happening.
I see that the primary kernel boots up and adds the ACPI regions via:
acpi_os_ioremap
-> ioremap_cache
But during the crashkernel boot, ''acpi_os_ioremap' calls
'ioremap' for the ACPI Reclaim Memory regions and not the _cache
variant.
And it fails while accessing the ACPI tables:
[ 0.039205] ACPI: Core revision 20170728
pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
[ 0.095098] Internal error: Oops: 96000021 [#1] SMP
[ 0.100022] Modules linked in:
[ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
[ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
[ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
[ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
[ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
pstate: 60000045
[ 0.132647] sp : ffff000008ccfb40
[ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
[ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
[ 0.146718] x25: 000000000000001b x24: 0000000000000001
[ 0.152083] x23: 0000000000000001 x22: ffff000009710027
[ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
[ 0.162812] x19: 000000000000001b x18: 0000000000000005
[ 0.168176] x17: 0000000000000000 x16: 0000000000000000
[ 0.173541] x15: 0000000000000000 x14: 000000000000038e
[ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
[ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
[ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
[ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
[ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
[ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
[ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
[ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
[ 0.223224] Call trace:
[ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
[ 0.232194] fa00: 0000000000000000 ffff000009710027
ffff0000095e3980 ffff000008ccfbe0
[ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
ffff000008ccfc50 0000000000000000
[ 0.248018] fa40: ffff8000126d0140 000000000000005f
00000000ffffff76 0000000000000006
[ 0.255931] fa60: ffffffffffffffff ffffffff00000000
000000000000038e 0000000000000000
[ 0.263843] fa80: 0000000000000000 0000000000000000
0000000000000005 000000000000001b
[ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
ffff000009710027 0000000000000001
[ 0.279667] fac0: 0000000000000001 000000000000001b
0000000000000000 ffff0000088be820
[ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
ffff00000849b4f8 ffff000008ccfb40
[ 0.295491] fb00: ffff0000084a6764 0000000060000045
ffff000008ccfb40 ffff000008260a18
[ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
ffff000008ccfb40 ffff0000084a6764
[ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
[ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
[ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
[ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
[ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
[ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
[ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
[ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
[ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
[ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
[ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
[ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
[ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
[ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
[ 0.394500] ---[ end trace c46ed37f9651c58e ]---
[ 0.399160] Kernel panic - not syncing: Fatal exception
[ 0.404437] Rebooting in 10 seconds.
So, I think the linear mapping done by the primary kernel does not
make these accessible in the crash kernel directly.
Any pointers?
Regards,
Bhupesh
>> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> via a kernel command line parameter, "memmap=".
>>
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the mvebu tree
From: Stephen Rothwell @ 2017-12-17 20:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Commit
a2e2a5860be3 ("arm64: dts: marvell: add NAND support on the 8040-DB board")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH v2 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
Add support for the Computer on Module Colibri iMX7D 1GB along
with the Colibri Evaluation Board device trees. Follow the usual
hierarchic include model, maintaining shared configuration in
imx7-colibri.dtsi and imx7-colibri-eval-v3.dtsi respectively.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Changes since v1:
- Use SPDX-License-Identifier: (GPL-2.0+ OR MIT)
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7-colibri.dtsi | 64 +++++++++++++++++++++++-
arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts | 20 ++++++++
arch/arm/boot/dts/imx7d-colibri-emmc.dtsi | 22 ++++++++
arch/arm/boot/dts/imx7d-colibri.dtsi | 4 ++
5 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
create mode 100644 arch/arm/boot/dts/imx7d-colibri-emmc.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b5ba7ad6ae30..9e4b4ecae572 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -519,6 +519,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ull-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-cl-som-imx7.dtb \
+ imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
imx7d-nitrogen7.dtb \
imx7d-pico.dtb \
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index c28a483b786d..895fbde4d433 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -121,7 +121,6 @@
fsl,use-minimum-ecc;
nand-on-flash-bbt;
nand-ecc-mode = "hw";
- status = "okay";
};
&i2c1 {
@@ -311,6 +310,21 @@
vqmmc-supply = <®_LDO2>;
};
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ assigned-clocks = <&clks IMX7D_USDHC3_ROOT_CLK>;
+ assigned-clock-rates = <400000000>;
+ bus-width = <8>;
+ fsl,tuning-step = <2>;
+ max-frequency = <100000000>;
+ vmmc-supply = <®_module_3v3>;
+ vqmmc-supply = <®_DCDC3>;
+ non-removable;
+};
+
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpio1 &pinctrl_gpio2 &pinctrl_gpio3 &pinctrl_gpio4>;
@@ -598,6 +612,54 @@
>;
};
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x59
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x19
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x59
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x59
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x59
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x59
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x59
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x59
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x59
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x59
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x19
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x5a
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x1a
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x5a
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x5a
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x5a
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x5a
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x5a
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x5a
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x5a
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x5a
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1a
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp_200mhz {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x5b
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x1b
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x5b
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x5b
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x5b
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x5b
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x5b
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x5b
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x5b
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x5b
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1b
+ >;
+ };
+
pinctrl_sai1: sai1-grp {
fsl,pins = <
MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK 0x1f
diff --git a/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
new file mode 100644
index 000000000000..403a864e30ad
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright 2017 Toradex AG
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+#include "imx7d-colibri-emmc.dtsi"
+#include "imx7-colibri-eval-v3.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3";
+ compatible = "toradex,colibri-imx7d-emmc-eval-v3",
+ "toradex,colibri-imx7d-emmc", "fsl,imx7d";
+};
+
+&usbotg2 {
+ vbus-supply = <®_usbh_vbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-colibri-emmc.dtsi b/arch/arm/boot/dts/imx7d-colibri-emmc.dtsi
new file mode 100644
index 000000000000..45b58ed57440
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-colibri-emmc.dtsi
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2017 Toradex AG
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include "imx7d.dtsi"
+#include "imx7-colibri.dtsi"
+
+/ {
+ memory {
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+&usbotg2 {
+ dr_mode = "host";
+};
+
+&usdhc3 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-colibri.dtsi b/arch/arm/boot/dts/imx7d-colibri.dtsi
index 3c2cb502b388..6f2bb70c1fbd 100644
--- a/arch/arm/boot/dts/imx7d-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7d-colibri.dtsi
@@ -49,6 +49,10 @@
};
};
+&gpmi {
+ status = "okay";
+};
+
&usbotg2 {
dr_mode = "host";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 8/9] ARM: dts: imx7-colibri: add MCP2515 CAN controller
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The Colibri Evaluation Carrier Board provides a MCP2515 CAN
controller connected via SPI. Note that the i.MX 7 provides
an internal CAN controller which is much better suited for CAN
operations. Using the MCP2515 with a Colibri iMX7 module is
mainly useful to test the SPI interface.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Changes since v1:
- Changed label and node name for MCP2515
- Drop num-cs from ecspi3
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 13 ++++++++++++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 87c23b769a08..e2b99bb48250 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -45,6 +45,13 @@
stdout-path = "serial0:115200n8";
};
+ /* fixed crystal dedicated to mpc258x */
+ clk16m: clk16m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ };
+
panel: panel {
compatible = "edt,et057090dhu";
backlight = <&bl>;
@@ -99,6 +106,24 @@
status = "okay";
};
+&ecspi3 {
+ status = "okay";
+
+ mcp2515: can at 0 {
+ compatible = "microchip,mcp2515";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can_int>;
+ reg = <0>;
+ clocks = <&clk16m>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <10000000>;
+ vdd-supply = <®_3v3>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+ };
+};
+
&fec1 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 689ff6822634..c28a483b786d 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -92,6 +92,12 @@
cpu-supply = <®_DCDC2>;
};
+&ecspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+ cs-gpios = <&gpio4 11 GPIO_ACTIVE_HIGH>;
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -313,7 +319,6 @@
fsl,pins = <
MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 55 */
MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 63 */
- MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0x14 /* SODIMM 77 */
MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 89 */
MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 91 */
@@ -400,6 +405,12 @@
>;
};
+ pinctrl_can_int: can-int-grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_ENET1_CRS__GPIO7_IO14 0x14
--
2.15.1
^ permalink raw reply related
* [PATCH v2 7/9] ARM: dts: imx7-colibri: specify backlight GPIO
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The Colibri standard defines SODIMM 71 as backlight enable
GPIO. Assign the GPIO to the backlight node in the module
level device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index d623ef0f6e3e..689ff6822634 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -43,7 +43,10 @@
/ {
bl: backlight {
compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
pwms = <&pwm1 0 5000000 0>;
+ enable-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
};
reg_module_3v3: regulator-module-3v3 {
@@ -360,7 +363,6 @@
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14 /* SODIMM 65 */
MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x74 /* SODIMM 69 */
- MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
MX7D_PAD_I2C4_SDA__GPIO4_IO15 0x14 /* SODIMM 75 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x14 /* SODIMM 79 */
MX7D_PAD_I2C3_SCL__GPIO4_IO12 0x14 /* SODIMM 81 */
@@ -436,6 +438,12 @@
>;
};
+ pinctrl_gpio_bl_on: gpio-bl-on {
+ fsl,pins = <
+ MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
+ >;
+ };
+
pinctrl_gpmi_nand: gpmi-nand-grp {
fsl,pins = <
MX7D_PAD_SD3_CLK__NAND_CLE 0x71
--
2.15.1
^ permalink raw reply related
* [PATCH v2 6/9] ARM: dts: imx7-colibri: specify usdhc1 supplies
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The usdhc1 controller instance is used to provide the default
SD/MMC capabilities of the Colibri standard. The IO pins are
supplied to the SoC on the module whereas the SD-card is powered
by the Carrier Board supply.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 1 +
arch/arm/boot/dts/imx7-colibri.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 5ecb3a858c5a..87c23b769a08 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -158,5 +158,6 @@
&usdhc1 {
keep-power-in-suspend;
wakeup-source;
+ vmmc-supply = <®_3v3>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 6498c1136ef1..d623ef0f6e3e 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -299,6 +299,7 @@
no-1-8-v;
cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
disable-wp;
+ vqmmc-supply = <®_LDO2>;
};
&iomuxc {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 5/9] ARM: dts: imx7-colibri: specify cpu-supply
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
Specify CPU supply using the "cpu-supply" property instead of
the invalid "arm-supply" property.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index f61041af026a..6498c1136ef1 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -86,7 +86,7 @@
};
&cpu0 {
- arm-supply = <®_DCDC2>;
+ cpu-supply = <®_DCDC2>;
};
&fec1 {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 4/9] ARM: dts: imx7-colibri: use NAND_CE1 as GPIO
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
All Colibri iMX7 SKUs use either single-die NAND or eMMC, hence
NAND_CE1 is not used on the module and can be used as a GPIO by
carrier boards.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index e4e32aa786f4..f61041af026a 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -329,6 +329,7 @@
MX7D_PAD_EPDC_SDCE2__GPIO2_IO22 0x14 /* SODIMM 127 */
MX7D_PAD_UART3_RTS_B__GPIO4_IO6 0x14 /* SODIMM 131 */
MX7D_PAD_EPDC_GDRL__GPIO2_IO26 0x14 /* SODIMM 133 */
+ MX7D_PAD_SAI1_RX_DATA__GPIO6_IO12 0x14 /* SODIMM 169 */
MX7D_PAD_SAI1_RX_BCLK__GPIO6_IO17 0x14 /* SODIMM 24 */
MX7D_PAD_SD2_DATA2__GPIO5_IO16 0x14 /* SODIMM 100 */
MX7D_PAD_SD2_DATA3__GPIO5_IO17 0x14 /* SODIMM 102 */
@@ -439,7 +440,6 @@
MX7D_PAD_SD3_CLK__NAND_CLE 0x71
MX7D_PAD_SD3_CMD__NAND_ALE 0x71
MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
- MX7D_PAD_SAI1_RX_DATA__NAND_CE1_B 0x71
MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/9] ARM: dts: imx7-colibri: mux pull-ups where appropriate
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
Use pull-ups instead of pull-downs for the pins which are already
pulled-up externally.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index dae6b561145b..e4e32aa786f4 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -307,17 +307,17 @@
pinctrl_gpio1: gpio1-grp {
fsl,pins = <
- MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x14 /* SODIMM 55 */
- MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x14 /* SODIMM 63 */
+ MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 55 */
+ MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 63 */
MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
- MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0X14 /* SODIMM 77 */
+ MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0x14 /* SODIMM 77 */
MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 89 */
- MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x14 /* SODIMM 91 */
+ MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 91 */
MX7D_PAD_LCD_RESET__GPIO3_IO4 0x14 /* SODIMM 93 */
MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x14 /* SODIMM 95 */
MX7D_PAD_ENET1_RGMII_TXC__GPIO7_IO11 0x14 /* SODIMM 99 */
- MX7D_PAD_EPDC_DATA10__GPIO2_IO10 0x14 /* SODIMM 105 */
- MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x14 /* SODIMM 107 */
+ MX7D_PAD_EPDC_DATA10__GPIO2_IO10 0x74 /* SODIMM 105 */
+ MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x74 /* SODIMM 107 */
MX7D_PAD_EPDC_DATA00__GPIO2_IO0 0x14 /* SODIMM 111 */
MX7D_PAD_EPDC_DATA01__GPIO2_IO1 0x14 /* SODIMM 113 */
MX7D_PAD_EPDC_DATA02__GPIO2_IO2 0x14 /* SODIMM 115 */
@@ -333,7 +333,7 @@
MX7D_PAD_SD2_DATA2__GPIO5_IO16 0x14 /* SODIMM 100 */
MX7D_PAD_SD2_DATA3__GPIO5_IO17 0x14 /* SODIMM 102 */
MX7D_PAD_EPDC_GDSP__GPIO2_IO27 0x14 /* SODIMM 104 */
- MX7D_PAD_EPDC_BDR0__GPIO2_IO28 0x14 /* SODIMM 106 */
+ MX7D_PAD_EPDC_BDR0__GPIO2_IO28 0x74 /* SODIMM 106 */
MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x14 /* SODIMM 110 */
MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30 0x14 /* SODIMM 112 */
MX7D_PAD_EPDC_SDCLK__GPIO2_IO16 0x14 /* SODIMM 114 */
@@ -357,7 +357,7 @@
pinctrl_gpio2: gpio2-grp { /* On X22 Camera interface */
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14 /* SODIMM 65 */
- MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x14 /* SODIMM 69 */
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x74 /* SODIMM 69 */
MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
MX7D_PAD_I2C4_SDA__GPIO4_IO15 0x14 /* SODIMM 75 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x14 /* SODIMM 79 */
@@ -378,8 +378,8 @@
MX7D_PAD_LCD_DATA19__GPIO3_IO24 0x14 /* SODIMM 138 */
MX7D_PAD_LCD_DATA20__GPIO3_IO25 0x14 /* SODIMM 140 */
MX7D_PAD_LCD_DATA21__GPIO3_IO26 0x14 /* SODIMM 142 */
- MX7D_PAD_LCD_DATA22__GPIO3_IO27 0x14 /* SODIMM 146 */
- MX7D_PAD_LCD_DATA23__GPIO3_IO28 0x14 /* SODIMM 148 */
+ MX7D_PAD_LCD_DATA22__GPIO3_IO27 0x74 /* SODIMM 144 */
+ MX7D_PAD_LCD_DATA23__GPIO3_IO28 0x74 /* SODIMM 146 */
>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/9] ARM: dts: imx7-colibri: make sure multiplexed pins are not active
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-1-stefan@agner.ch>
The Colibri pins PWM<A> and <D> are multiplexed on the module, make
sure the secondary SoC pin is not active.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 60ea7557d8c9..dae6b561145b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -507,6 +507,7 @@
pinctrl_pwm1: pwm1-grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO08__PWM1_OUT 0x79
+ MX7D_PAD_ECSPI2_MOSI__GPIO4_IO21 0x4
>;
};
@@ -525,6 +526,7 @@
pinctrl_pwm4: pwm4-grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO11__PWM4_OUT 0x79
+ MX7D_PAD_ECSPI2_SCLK__GPIO4_IO20 0x4
>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 1/9] ARM: dts: imx7-colibri: move and rename USB Host power regulator
From: Stefan Agner @ 2017-12-17 20:37 UTC (permalink / raw)
To: linux-arm-kernel
The Colibri default which enables USB Host power is not necessarily
tied to the OTG2 controller, some carrier board use the pin to
control USB power for both controllers. Hence name the pinctrl
group more generic.
Also move the regulator to the generic eval-v3 device tree since
the regulator is always on the carrier board. In the Colibri iMX7S
case the regulator is just not used. This allows to reuse the
regulator in a upcoming SKU Colibri iMX7D 1GB with eMMC.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 11 +++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
arch/arm/boot/dts/imx7d-colibri-eval-v3.dts | 13 +------------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 18bebd6d8d47..5ecb3a858c5a 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -70,6 +70,17 @@
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
+
+ reg_usbh_vbus: regulator-usbh-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh_reg>;
+ regulator-name = "VCC_USB[1-4]";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 7 GPIO_ACTIVE_LOW>;
+ vin-supply = <®_5v0>;
+ };
};
&bl {
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index bb5bf94f1a32..60ea7557d8c9 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -559,7 +559,7 @@
>;
};
- pinctrl_usbotg2_reg: gpio-usbotg2-vbus {
+ pinctrl_usbh_reg: gpio-usbh-vbus {
fsl,pins = <
MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14 /* SODIMM 129 USBH PEN */
>;
diff --git a/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
index a608a14d8c85..136e11ab4893 100644
--- a/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
@@ -48,20 +48,9 @@
model = "Toradex Colibri iMX7D on Colibri Evaluation Board V3";
compatible = "toradex,colibri-imx7d-eval-v3", "toradex,colibri-imx7d",
"fsl,imx7d";
-
- reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbotg2_reg>;
- regulator-name = "VCC_USB[1-4]";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio4 7 GPIO_ACTIVE_LOW>;
- vin-supply = <®_5v0>;
- };
};
&usbotg2 {
- vbus-supply = <®_usb_otg2_vbus>;
+ vbus-supply = <®_usbh_vbus>;
status = "okay";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-17 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217204122.0a10a5e1@jawa>
On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <lukma@denx.de> wrote:
>> >> We also need to think about upholding support in GCC for
>> >> ARMv4(t) for the foreseeable future if there is a big web of
>> >> random deeply embedded systems out there that will need
>> >> updates.
>> >
>> > But we should definitely preserve at least what we have.
>>
>> Plain ARMv4 (and earlier) support in gcc is already marked
>> 'deprecated' and will likely be gone in gcc-8 (it's still there as of
>> last week). ARMv4T is going to be around for a while, and you can
>> even keep building for ARMv4 using "-march=armv4t -marm" when linking
>> with 'ld --fix-v4bx'.
>
> I think that we shall start complaining on the gcc-devel mailing list
> now.
>
> I would be hard to wake up in 2 years time and realise that we don't
> have a modern compiler.
What distro or build system are you using? It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
Arnd
^ permalink raw reply
* [PATCH 2/9] ARM: dts: imx7-colibri: make sure multiplexed pins are not active
From: Stefan Agner @ 2017-12-17 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AD6bDEMStEWY8hRG_8gh0RAD_66zboTsKd-cFkPtiLKg@mail.gmail.com>
On 2017-12-16 15:01, Fabio Estevam wrote:
> On Wed, Dec 6, 2017 at 1:29 PM, Stefan Agner <stefan@agner.ch> wrote:
>> The Colibri pins PWM<A> and <D> are multiplexed on the module, make
>> sure the secondary SoC pin is not active.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>
> I haven't really understood the commit message, but this is probably
> because I don't have access to the schematics.
It means that the modules pins are connected to two SoC pads. It is also
mentioned in the Colibri iMX7 datasheet.
This allows to use the module pin for a different purpose, but we mux it
such that it is usable for the primary purpose (which is PWM).
>
> Anyway:
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Thanks!
--
Stefan
^ permalink raw reply
* [PATCH] ARM: pxa/lubbock: add GPIO driver for LUB_MISC_WR register
From: Robert Jarzmik @ 2017-12-17 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212232405.GG10595@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Tue, Dec 12, 2017 at 09:27:34PM +0100, Robert Jarzmik wrote:
>> Russell King <rmk+kernel@armlinux.org.uk> writes:
>>
>> > Add a gpio driver for the lubbock miscellaneous write IO register so we
>> > can take advantage of subsystems modelled around gpiolib, rather than
>> > having to provide platform specific callbacks.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>
>> Hi Russell and Linux,
>>
>> It looks certainly good to me. It's unfortunate in the current status of
>> linux-next I have, gpio-reg.c seems broken (that one is for Linus in [1] and
>> [2]), and therefore I can't test it live.
>
> It won't do much on its own without some patches to make use of the new
> GPIOs... but it will be used as the direct register write becomes a
> call to gpio-reg's ->set_multiple() method.
Applied to pxa/for-next, thanks.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Lukasz Majewski @ 2017-12-17 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2jEVQXKXJXp27ft5oaD8Jbo6g1fB-t_aduJWhC2dtJ0g@mail.gmail.com>
Hi Arnd,
> On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
> <alexander.sverdlin@gmail.com> wrote:
> > On Wed Dec 13 08:34:22 2017 Linus Walleij
> > <linus.walleij@linaro.org> wrote:
> >> Arnd has been nudging me to do DT conversion for EP93xx
> >> so if there are many active industrial users of these
> >> I should prioritize it, because these things have 20+ years
> >> support cycles.
> >
> > I'm not sure how important or necessary at all is to change
> > anything in these legacy platforms.
>
> I suspect that at several points in the next 5 to 10 years, we will
> remove additional platforms or CPU types, as we tend to do when a
> platform becomes a maintenance burden and is clearly not used by
> anyone.
I suppose that at least the last argument is not the case here :-).
>
> It's hard to predict in advance what triggers the removal, but as the
> number of platforms that are not using DT or ARCH_MULTIPLATFORM
> goes down to a small number, there will be increased interested in
> either removing or converting the remaining ones. This is not an
> immediate danger at the moment, since we still have 14 platforms that
> are not using ARCH_MULTIPLATFORM, and 23 that have remaining
> board files, but you don't want to be the last user of the last
> platform after the other ones are done ;-)
:-)
>
> >> We also need to think about upholding support in GCC for
> >> ARMv4(t) for the foreseeable future if there is a big web of
> >> random deeply embedded systems out there that will need
> >> updates.
> >
> > But we should definitely preserve at least what we have.
>
> Plain ARMv4 (and earlier) support in gcc is already marked
> 'deprecated' and will likely be gone in gcc-8 (it's still there as of
> last week). ARMv4T is going to be around for a while, and you can
> even keep building for ARMv4 using "-march=armv4t -marm" when linking
> with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing list
now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
>
> Debian recently did a survey to find out whether there were still
> users on ARMv4 or ARMv4T, and the result was that probably everyone is
> on ARMv5E or ARMv6 for the ARM port (which is separate from the
> ARMHF port that is ARMv7+). See also
> https://lists.debian.org/debian-user/2017/11/msg00379.html
> and let them know quickly if you use Debian stable releases and
> plan to update to Debian 10 (Buster) in the future.
>
> Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171217/56d4973a/attachment.sig>
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-17 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217190746.2a61232c@bbrezillon>
On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote:
> > > This would guarantee that devices with factory bad blocks,
> > > (and no BBT), would be OK with this patch.
> >
> > I see. I'm fine with trying provided I have reasonably good assurance
> > that I won't have to go through the kwboot pain again :-/
>
> There's a easy test you can do without scrubing the NAND:
> 1/ comment the nand-on-flash-bbt property in your DT (this will trigger
> a full scan)
> 2/ from u-boot (before booting the kernel), erase a block that you know
> contains nothing important
> 3/ during the kernel scan, make sure this block is not reported as bad
OK so I tried and never faced any error. Thus I also attempted to mark
a bad block in u-boot, it appeared in the bad blocks table, then I had
to scrub the whole table to get rid of it. Each time when I booted I
saw the message "Scanning device for bad blocks" but no error ever
happened. So I hope it's OK.
Please find a summary of my tests below.
Marvell>> nand erase 280000 1000
NAND erase: device 0 offset 0x280000, size 0x1000
Erasing at 0x280000 -- 100% complete.
OK
Marvell>> nand dump 280000
Page 00280000 dump:
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
...
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB:
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
Boot....
# nanddump -c --oob --bb=dumpbad /dev/mtd8 >/tmp/dump-mtd8.txt
=> only ff everywhere
# dmesg
...
pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
nand: AMD/Spansion S34ML01G2
nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
Scanning device for bad blocks
...
Marvell>> nand markbad 280000
Bad block table written to 0x000007fe0000, version 0x02
Bad block table written to 0x000007fc0000, version 0x02
>>> orion_nfc_wait_for_completion_timeout command timed out!, status (0x100)
command 19 execution timed out (CS -1, NDCR=0x8104bfff, NDSR=0x100).
block 0x00280000 successfully marked as bad
Marvell>>
Marvell>> nand bad
Device 0 bad blocks:
280000
7f00000
7f20000
7f40000
7f60000
7f80000
7fa0000
7fc0000
7fe0000
Boot...
# dmesg
...
[ 0.875117] pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
[ 0.881627] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[ 0.886697] nand: AMD/Spansion S34ML01G2
[ 0.889326] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.895628] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
[ 0.901316] Scanning device for bad blocks
...
Marvell>> nand scrub 7f00000 100000
Erasing at 0x7fe0000 -- 100% complete.
Bad block table not found for chip 0
Bad block table not found for chip 0
Bad block table written to 0x000007fe0000, version 0x01
Bad block table written to 0x000007fc0000, version 0x01
OK
Marvell>> nand bad
Device 0 bad blocks:
7f00000
7f20000
7f40000
7f60000
7f80000
7fa0000
7fc0000
7fe0000
Boot...
# dmesg
...
[ 0.875322] pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
[ 0.881834] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[ 0.886904] nand: AMD/Spansion S34ML01G2
[ 0.889533] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.895835] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
[ 0.901524] Scanning device for bad blocks
[ 1.202116] ata2: SATA link down (SStatus 0 SControl 300)
[ 1.206245] ata1: SATA link down (SStatus 0 SControl 300)
[ 1.244449] 10 ofpart partitions found on MTD device pxa3xx_nand-0
[ 1.249345] Creating 10 MTD partitions on "pxa3xx_nand-0":
[ 1.253551] 0x000000000000-0x000000200000 : "u-boot"
[ 1.257523] 0x000000200000-0x000000240000 : "u_env"
[ 1.261372] 0x000000240000-0x000000280000 : "s_env"
[ 1.265217] 0x000000900000-0x000000a00000 : "devinfo"
[ 1.269229] 0x000000a00000-0x000003200000 : "kernel1"
[ 1.273326] 0x000001000000-0x000003200000 : "rootfs1"
[ 1.277407] 0x000003200000-0x000005a00000 : "kernel2"
[ 1.281509] 0x000003800000-0x000005a00000 : "rootfs2"
[ 1.285591] 0x000005a00000-0x000008000000 : "syscfg"
[ 1.289596] 0x000000280000-0x000000900000 : "unused_area"
...
Willy
^ permalink raw reply
* [PATCH v4 3/4] cpufreq: Add DVFS support for Armada 37xx
From: Rafael J. Wysocki @ 2017-12-17 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2201504.Sp2n0UgIp2@aspire.rjw.lan>
On Sunday, December 17, 2017 7:08:53 PM CET Rafael J. Wysocki wrote:
> On Thursday, December 14, 2017 4:36:31 PM CET Viresh Kumar wrote:
> > On 14-12-17, 16:00, Gregory CLEMENT wrote:
> > > This patch adds DVFS support for the Armada 37xx SoCs
> > >
> > > There are up to four CPU frequency loads for Armada 37xx controlled by
> > > the hardware.
> > >
> > > This driver associates the CPU load level to a frequency, then the
> > > hardware will switch while selecting a load level.
> > >
> > > The hardware also can associate a voltage for each level (AVS support)
> > > but it is not yet supported
> > >
> > > Tested-by: Andre Heider <a.heider@gmail.com>
> > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > > ---
> > > drivers/cpufreq/Kconfig.arm | 7 +
> > > drivers/cpufreq/Makefile | 1 +
> > > drivers/cpufreq/armada-37xx-cpufreq.c | 241 ++++++++++++++++++++++++++++++++++
> > > 3 files changed, 249 insertions(+)
> > > create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
> >
> > Thanks for taking care of very minor review comments I had. All the
> > patches look good now to me :)
>
> All applied, thanks!
>
Actually, all except for the [4/4] as you applied it earlier.
Thanks!
^ permalink raw reply
* [PATCH 0/2] cpufreq: few fix on mvebu driver
From: Rafael J. Wysocki @ 2017-12-17 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213172914.6148-1-gregory.clement@free-electrons.com>
On Wednesday, December 13, 2017 6:29:12 PM CET Gregory CLEMENT wrote:
> Hi,
>
> The second patch of this series was originally part of the series "Add CPU
> Frequency scaling support on Armada 37xx" [1].
>
> As requested by Viresh Kumar, it is extracted in a independent series.
> In the meantime, Thomas Petazzoni pointed an issue on the first
> version that I fixed in this series.
>
> While I was on this driver I found an aother issue that I fixed with
> the first patch.
>
> Thanks,
>
> Gregory
>
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/547650.html
>
> Gregory CLEMENT (2):
> cpufreq: mvebu: Free the clock reference in the normal path
> cpufreq: mvebu: Free opp if registering failed
>
> drivers/cpufreq/mvebu-cpufreq.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
>
Both applied, thanks!
^ permalink raw reply
* [PATCH v2 0/2] cpufreq: Sort Kconfig and Makefile
From: Rafael J. Wysocki @ 2017-12-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213170536.28238-1-gregory.clement@free-electrons.com>
On Wednesday, December 13, 2017 6:05:34 PM CET Gregory CLEMENT wrote:
> Hi,
>
> The patch of this series was originally part of the series "Add CPU
> Frequency scaling support on Armada 37xx" [1].
>
> As requested by Rafael J. Wysocki, these 2 patches are extracted in a
> independent series, in the meantime, Viresh Kumar gave his acked-by
> that I added to the patches.
>
> In this second version only the 1st patch had been modified, see the
> changelog for the details.
>
> Thanks,
>
> Gregory
>
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/546709.html
>
> Changelog:
> v1 -> v2:
>
> - Fixed tab vs space issue in KConfig, suggested by Randy Dunlap
> - Removed unneeded "default n" in KConfig, suggested by Randy Dunlap
>
> Gregory CLEMENT (2):
> cpufreq: ARM: sort the Kconfig menu
> cpufreq: sort the drivers in ARM part
>
> drivers/cpufreq/Kconfig.arm | 81 ++++++++++++++++++++++-----------------------
> drivers/cpufreq/Makefile | 8 ++---
> 2 files changed, 44 insertions(+), 45 deletions(-)
>
>
Both applied, thanks!
^ permalink raw reply
* [PATCH v4 3/4] cpufreq: Add DVFS support for Armada 37xx
From: Rafael J. Wysocki @ 2017-12-17 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214153631.GZ3322@vireshk-i7>
On Thursday, December 14, 2017 4:36:31 PM CET Viresh Kumar wrote:
> On 14-12-17, 16:00, Gregory CLEMENT wrote:
> > This patch adds DVFS support for the Armada 37xx SoCs
> >
> > There are up to four CPU frequency loads for Armada 37xx controlled by
> > the hardware.
> >
> > This driver associates the CPU load level to a frequency, then the
> > hardware will switch while selecting a load level.
> >
> > The hardware also can associate a voltage for each level (AVS support)
> > but it is not yet supported
> >
> > Tested-by: Andre Heider <a.heider@gmail.com>
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > ---
> > drivers/cpufreq/Kconfig.arm | 7 +
> > drivers/cpufreq/Makefile | 1 +
> > drivers/cpufreq/armada-37xx-cpufreq.c | 241 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 249 insertions(+)
> > create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
>
> Thanks for taking care of very minor review comments I had. All the
> patches look good now to me :)
All applied, thanks!
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Boris Brezillon @ 2017-12-17 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217162342.GA1833@1wt.eu>
On Sun, 17 Dec 2017 17:23:42 +0100
Willy Tarreau <w@1wt.eu> wrote:
> On Sun, Dec 17, 2017 at 12:53:36PM -0300, Ezequiel Garcia wrote:
> > If not too much to ask, this is the test that I believe is needed.
> > You seem to have a setup ready, hence why I'm asking you, if
> > possible, to give it a shot.
> >
> > (1) Scrub the BBT from the NAND. Or scrub the whole NAND.
> > You cannot do this from the kernel, it needs to be done from the bootloader.
> >
> > (2) Mark a couple blocks as bad using the OOB -- AFAICR, there
> > was a command to do this in the bootloader.
> >
> > (3) Boot, let Linux create the BBT and see if it catches the bad blocks.
>
> Are the current boot loaders safe regarding the scrub operation ? I'm
> asking because that's how I bricked my mirabox a few years ago when
> trying to mark a bad block from u-boot :-/ If someone has a good
> knowledge of these commands to limit the risk and helps me only playing
> with a small part at the end of the flash (or in the unused area) I'd
> prefer it :-)
>
> > This would guarantee that devices with factory bad blocks,
> > (and no BBT), would be OK with this patch.
>
> I see. I'm fine with trying provided I have reasonably good assurance
> that I won't have to go through the kwboot pain again :-/
There's a easy test you can do without scrubing the NAND:
1/ comment the nand-on-flash-bbt property in your DT (this will trigger
a full scan)
2/ from u-boot (before booting the kernel), erase a block that you know
contains nothing important
3/ during the kernel scan, make sure this block is not reported as bad
^ permalink raw reply
* [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Rafael J. Wysocki @ 2017-12-17 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a68c5382-2a9c-6c3c-ea67-99db46bdff1a@gmail.com>
On Tuesday, December 12, 2017 10:34:42 AM CET Matthias Brugger wrote:
> Hi,
>
> On 12/12/2017 08:26 AM, Viresh Kumar wrote:
> > On 12-12-17, 02:17, Rafael J. Wysocki wrote:
> >> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
> >>> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
> >>>> Add opp v2 information,
> >>>> and also add clocks, regulators and opp information into cpu nodes
> >>>>
> >>>> Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
> >>>> ---
> >>>> arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
> >>>> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
> >>>> 2 files changed, 84 insertions(+)
> >>>
> >>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >>
> >> Of course, DT bindings require ACKs from DT maintainers to be applied.
> >
> > I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
> > its very much required while defining new bindings for sure.
> >
>
> I will take the dts parts through the Mediatek SoC tree, so you don't have to
> worry about them.
>
> Please let me know when you take patch 1 and 2.
Applied now, thanks!
Do you need the branch containing them to be exposed?
Thanks,
Rafael
^ permalink raw reply
* [PATCH] bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate
From: Rafael J. Wysocki @ 2017-12-17 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201070232.v4uilgo5cydaoyqa@verge.net.au>
On Friday, December 1, 2017 8:02:33 AM CET Simon Horman wrote:
> On Thu, Nov 30, 2017 at 12:57:00PM +0100, Geert Uytterhoeven wrote:
> > From: Paul Gortmaker <paul.gortmaker@windriver.com>
> >
> > The Kconfig currently controlling compilation of this code is:
> >
> > config SIMPLE_PM_BUS
> > bool "Simple Power-Managed Bus Driver"
> >
> > ...meaning that it currently is not being built as a module by anyone.
> >
> > In removing the orphaned modular support in a previous patch set,
> > Geert indicated he'd rather see this code converted to tristate.
> >
> > I normally don't do that because it extends functionality that I
> > can't easily run time test or even know if the use case makes sense,
> > but since in this case the author has nominated it as such, we do
> > the conversion here.
> >
> > Note that doesn't change the lack of run time testing ; this change
> > is only tested for sucessful compile and modpost.
> >
> > [geert: Ethernet is probed successfully on sh73a0/kzm9g after
> > insmodding simple-pm-bus.ko]
> >
> > Cc: Kevin Hilman <khilman@linaro.org>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
Applied, thanks!
^ permalink raw reply
* [PATCH v2] PM / Domains: Remove obsolete "samsung, power-domain" check
From: Rafael J. Wysocki @ 2017-12-17 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512042868-23017-1-git-send-email-geert+renesas@glider.be>
On Thursday, November 30, 2017 12:54:28 PM CET Geert Uytterhoeven wrote:
> Currently the generic PM Domain code code checks for the presence of
> both (generic) "power-domains" and (Samsung Exynos legacy)
> "samsung,power-domain" properties in all device tree nodes representing
> devices.
>
> There are two issues with this:
> 1. This imposes a small boot-time penalty on all platforms using DT,
> 2. Platform-specific checks do not really belong in core framework
> code.
>
> Remove the platform-specific check, as the last user of
> "samsung,power-domain" was removed in commit 46dcf0ff0de35da8 ("ARM:
> dts: exynos: Remove exynos4415.dtsi"). All other users were converted
> before in commit 0da6587041363033 ("ARM: dts: convert to generic power
> domain bindings for exynos DT").
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This is v2 of 'PM / Domains: Restrict "samsung,power-domain" checks to
> ARCH_EXYNOS'.
>
> "samsung,power-domain" was only ever used in:
> - arch/arm/boot/dts/exynos4415.dtsi: Removed
> - arch/arm/boot/dts/exynos3250.dtsi: CONFIG_ARCH_EXYNOS3
> - arch/arm/boot/dts/exynos4.dtsi: CONFIG_ARCH_EXYNOS4
> - arch/arm/boot/dts/exynos4x12.dtsi: CONFIG_ARCH_EXYNOS4
> - arch/arm/boot/dts/exynos5250.dtsi: CONFIG_ARCH_EXYNOS5
> - arch/arm/boot/dts/exynos5420.dtsi: CONFIG_ARCH_EXYNOS5
>
> v2:
> - Remove the check completely instead of restricting it to
> ARCH_EXYNOS, as suggested Javier Martinez Canillas one year ago
> ("Removing the support for the deprecated property sound sensible to me",
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/462868.html).
> ---
> drivers/base/power/domain.c | 16 ++--------------
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 0c80bea05bcb92be..f9dcc981b6b9328c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2199,20 +2199,8 @@ int genpd_dev_pm_attach(struct device *dev)
>
> ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
> "#power-domain-cells", 0, &pd_args);
> - if (ret < 0) {
> - if (ret != -ENOENT)
> - return ret;
> -
> - /*
> - * Try legacy Samsung-specific bindings
> - * (for backwards compatibility of DT ABI)
> - */
> - pd_args.args_count = 0;
> - pd_args.np = of_parse_phandle(dev->of_node,
> - "samsung,power-domain", 0);
> - if (!pd_args.np)
> - return -ENOENT;
> - }
> + if (ret < 0)
> + return ret;
>
> mutex_lock(&gpd_list_lock);
> pd = genpd_get_from_provider(&pd_args);
>
Applied, thanks!
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-17 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAEAJfD47bGTSppEqcRszjAgBUjiCevmdYLKfsQTPYMcVu8VDA@mail.gmail.com>
On Sun, Dec 17, 2017 at 12:53:36PM -0300, Ezequiel Garcia wrote:
> If not too much to ask, this is the test that I believe is needed.
> You seem to have a setup ready, hence why I'm asking you, if
> possible, to give it a shot.
>
> (1) Scrub the BBT from the NAND. Or scrub the whole NAND.
> You cannot do this from the kernel, it needs to be done from the bootloader.
>
> (2) Mark a couple blocks as bad using the OOB -- AFAICR, there
> was a command to do this in the bootloader.
>
> (3) Boot, let Linux create the BBT and see if it catches the bad blocks.
Are the current boot loaders safe regarding the scrub operation ? I'm
asking because that's how I bricked my mirabox a few years ago when
trying to mark a bad block from u-boot :-/ If someone has a good
knowledge of these commands to limit the risk and helps me only playing
with a small part at the end of the flash (or in the unused area) I'd
prefer it :-)
> This would guarantee that devices with factory bad blocks,
> (and no BBT), would be OK with this patch.
I see. I'm fine with trying provided I have reasonably good assurance
that I won't have to go through the kwboot pain again :-/
Cheers,
Willy
^ 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