* [PATCH v2 3/5] arm: decompressor: define a new zImage tag
From: Łukasz Stelmach @ 2020-06-02 16:17 UTC (permalink / raw)
To: Russell King, Masahiro Yamada, Nick Desaulniers, Thomas Gleixner,
Enrico Weigelt, Kees Cook, Ingo Molnar, Ben Dooks,
linux-arm-kernel, linux-kernel
Cc: AKASHI Takahiro, Marek Szyprowski, Łukasz Stelmach,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20200602161731.23033-1-l.stelmach@samsung.com>
Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
requirements of the decompressor code.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
---
arch/arm/boot/compressed/vmlinux.lds.S | 9 ++++++++-
arch/arm/include/asm/image.h | 3 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
index 308e9cd6a897..d15c1269eb5d 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -39,6 +39,11 @@ SECTIONS
LONG(ARM_ZIMAGE_MAGIC3)
LONG(ZIMAGE_MAGIC(__piggy_size_addr - _start))
LONG(ZIMAGE_MAGIC(_kernel_bss_size))
+ LONG(ZIMAGE_MAGIC(3))
+ LONG(ARM_ZIMAGE_MAGIC4)
+ LONG(ZIMAGE_MAGIC((_end - __bss_start) +
+ (_stack_end - _stack_start) +
+ MALLOC_SIZE))
LONG(0)
_table_end = .;
}
@@ -108,10 +113,12 @@ SECTIONS
. = BSS_START;
__bss_start = .;
.bss : { *(.bss) }
+ . = ALIGN(8); /* the stack must be 64-bit aligned and adjoin bss */
_end = .;
- . = ALIGN(8); /* the stack must be 64-bit aligned */
+ _stack_start = .;
.stack : { *(.stack) }
+ _stack_end = .;
PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));
PROVIDE(__pecoff_end = ALIGN(512));
diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
index d5c18a0f6a34..55b51faa6b7e 100644
--- a/arch/arm/include/asm/image.h
+++ b/arch/arm/include/asm/image.h
@@ -15,6 +15,7 @@
#define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
#define ARM_ZIMAGE_MAGIC2 (0x45454545)
#define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
+#define ARM_ZIMAGE_MAGIC4 ZIMAGE_MAGIC(0x5a534344)
#ifndef __ASSEMBLY__
@@ -40,6 +41,8 @@ struct arm_zimage_tag {
__le32 size_ptr;
__le32 bss_size;
} krnl_size;
+#define ZIMAGE_TAG_ZIMAGE_MEM ARM_ZIMAGE_MAGIC4
+ __le32 zimage_mem;
} u;
};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/5] arm: add image header definitions
From: Łukasz Stelmach @ 2020-06-02 16:17 UTC (permalink / raw)
To: Russell King, Masahiro Yamada, Nick Desaulniers, Thomas Gleixner,
Enrico Weigelt, Kees Cook, Ingo Molnar, Ben Dooks,
linux-arm-kernel, linux-kernel
Cc: AKASHI Takahiro, Marek Szyprowski, Łukasz Stelmach,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20200602161731.23033-1-l.stelmach@samsung.com>
This structure will be used later by kexec_file loader.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
---
arch/arm/boot/compressed/head.S | 3 +-
arch/arm/boot/compressed/vmlinux.lds.S | 13 ++-----
arch/arm/include/asm/image.h | 48 ++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 11 deletions(-)
create mode 100644 arch/arm/include/asm/image.h
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 55758264e776..005b172d504f 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -7,6 +7,7 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/image.h>
#include <asm/v7m.h>
#include "efi-header.S"
@@ -211,7 +212,7 @@ start:
.word _magic_start @ absolute load/run zImage address
.word _magic_end @ zImage end address
.word 0x04030201 @ endianness flag
- .word 0x45454545 @ another magic number to indicate
+ .word ARM_ZIMAGE_MAGIC2 @ another magic number to indicate
.word _magic_table @ additional data table
__EFI_HEADER
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
index f82b5962d97e..308e9cd6a897 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -3,14 +3,7 @@
* Copyright (C) 2000 Russell King
*/
-#ifdef CONFIG_CPU_ENDIAN_BE8
-#define ZIMAGE_MAGIC(x) ( (((x) >> 24) & 0x000000ff) | \
- (((x) >> 8) & 0x0000ff00) | \
- (((x) << 8) & 0x00ff0000) | \
- (((x) << 24) & 0xff000000) )
-#else
-#define ZIMAGE_MAGIC(x) (x)
-#endif
+#include <asm/image.h>
OUTPUT_ARCH(arm)
ENTRY(_start)
@@ -43,7 +36,7 @@ SECTIONS
.table : ALIGN(4) {
_table_start = .;
LONG(ZIMAGE_MAGIC(4))
- LONG(ZIMAGE_MAGIC(0x5a534c4b))
+ LONG(ARM_ZIMAGE_MAGIC3)
LONG(ZIMAGE_MAGIC(__piggy_size_addr - _start))
LONG(ZIMAGE_MAGIC(_kernel_bss_size))
LONG(0)
@@ -107,7 +100,7 @@ SECTIONS
_edata_real = .;
}
- _magic_sig = ZIMAGE_MAGIC(0x016f2818);
+ _magic_sig = ARM_ZIMAGE_MAGIC1;
_magic_start = ZIMAGE_MAGIC(_start);
_magic_end = ZIMAGE_MAGIC(_edata);
_magic_table = ZIMAGE_MAGIC(_table_start - _start);
diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
new file mode 100644
index 000000000000..d5c18a0f6a34
--- /dev/null
+++ b/arch/arm/include/asm/image.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_IMAGE_H
+#define __ASM_IMAGE_H
+
+#ifdef CONFIG_CPU_ENDIAN_BE8
+#define ZIMAGE_MAGIC(x) ((((x) >> 24) & 0x000000ff) | \
+ (((x) >> 8) & 0x0000ff00) | \
+ (((x) << 8) & 0x00ff0000) | \
+ (((x) << 24) & 0xff000000))
+#else
+#define ZIMAGE_MAGIC(x) (x)
+#endif
+
+#define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
+#define ARM_ZIMAGE_MAGIC2 (0x45454545)
+#define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
+
+#ifndef __ASSEMBLY__
+
+#include <linux/types.h>
+#include <asm/setup.h>
+
+/* ARM zImage header format */
+struct arm_zimage_header {
+ __le32 code[9];
+ __le32 magic;
+ __le32 start;
+ __le32 end;
+ __le32 endian;
+ __le32 magic2;
+ __le32 extension_tag_offset;
+};
+
+struct arm_zimage_tag {
+ struct tag_header hdr;
+ union {
+#define ZIMAGE_TAG_KRNL_SIZE ARM_ZIMAGE_MAGIC3
+ struct zimage_krnl_size {
+ __le32 size_ptr;
+ __le32 bss_size;
+ } krnl_size;
+ } u;
+};
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_IMAGE_H */
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/5] arm: decompressor: define a new zImage tag
From: Lukasz Stelmach @ 2020-06-02 16:17 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20200601204127.GS1551@shell.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 6059 bytes --]
It was <2020-06-01 pon 21:41>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 10:27:45PM +0200, Lukasz Stelmach wrote:
>> It was <2020-06-01 pon 19:25>, when Russell King - ARM Linux admin wrote:
>>> On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
>>>> It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
>>>>> On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
>>>>>> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
>>>>>> requirements of the decompressor code.
>>>>>
>>>>> Why do we need to know the stack and BSS size, when the userspace
>>>>> kexec tool doesn't need to know this to perform the same function.
>>>>
>>>>
>>>> kexec-tools load zImage as low in DRAM as possible and rely on two
>>>> assumptions:
>>>>
>>>> + the zImage will copy itself to make enough room for the kernel,
>>>> + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because
>>>> of compression.
>>>>
>>>> DRAM start
>>>> + 0x8000
>>>>
>>>> zImage |-----------|-----|-------|
>>>> text+data bss stack
>>>>
>>>> text+data bss
>>>> kernel |---------------------|-------------------|
>>>>
>>>>
>>>> initrd |-initrd-|-dtb-|
>>>
>>> This is actually incorrect, because the decompressor will self-
>>> relocate itself to avoid the area that it is going to decompress
>>> into.
>>
>> I described the state right after kexec(8) invocation.
>
> Actually, you haven't, because this is _not_ how kexec(8) lays it
> out, as I attempted to detail further down in my reply.
Let me try to describe how I understand the code in kexec-tools
(commit 74c7c369).
--8<---------------cut here---------------start------------->8---
int zImage_arm_load(…, const char *buf, off_t len, …)
// buf - zImage
// len - size of zImage
unsigned int extra_size = 0x8000; /* TEXT_OFFSET */
kernel_mem_size = len + 4;
// locate a hole to fit zImage + 32kB as low as possible,
base = locate_hole(info, len + extra_size, 0, 0, ULONG_MAX, INT_MAX);
kernel_base = base + extra_size;
add_segment(info, buf, len, kernel_base, kernel_mem_size);
--8<---------------cut here---------------end--------------->8---
Therefore, zImage is loaded low and always requires relocation.
ram |--------------------------------------------------------------
zImage |----k_m_s----|
^
|
kernel_base — TEXT_OFFSET or higher
Next goes initrd
--8<---------------cut here---------------start------------->8---
kexec_arm_image_size = len * 5; // or passed on command line
// if the tag exists
kexec_arm_image_size = max(edata_size + bss_size,
edata_size + len); // len - zImage size + 64 kB
initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, page_size);
add_segment(info, ramdisk_buf, initrd_size, initrd_base, initrd_size);
--8<---------------cut here---------------end--------------->8---
above whatever is bigger (kernel + kernel bss) OR (kernel + zImage + zImage mem).
ram |---------------------------------------------------------------
zImage |----k_m_s----| Where kexec loads zImage @kernel_base
|.............len * 5....................| Fallback
kernel |.....edata.....|...bss...| These are just calculations
zImage |.....len+....| zImage will copy itself here WHEN it runs
initrd |--initrd_size--|
dtb ^ |---|
|
initrd_base
DTB, of course, goes next
dtb_offset = initrd_base + initrd_size + page_size;
Stuff marked with "-" is actually loaded, "." are just calculations to
establish initrd_base.
>>> So, while the decompressor runs, in the above situation it
>>> ends up as:
>>>
>>>
>>> ram |------------------------------------------------------...
>>> text+data bss
>>> kernel |---------------------|-------------------|
>>> zImage |-----------|-----|-------|
>>> text+data bss stack+malloc
>
> Note here - if the initrd was placed as _you_ describe at the end
> of where the zImage ends up including its BSS, it would be
> corrupted by the stack and malloc space of the decompressor while
> running. Ergo, your description of how kexec(8) lays stuff out
> is incorrect.
Is my analysis above accurate now? Do I understand this?
As you noted, my intention is to load zImage after edata (dotted len+
above).
>>>>>> +struct arm_zimage_tag_dc {
>>>>>> + struct tag_header hdr;
>>>>>> + union {
>>>>>> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4
>>>>>> + struct zimage_decomp_size {
>>>>>> + __le32 bss_size;
>>>>>> + __le32 stack_size;
>>>>>> + __le32 malloc_size;
>>>>>> + } decomp_size;
>>>
>>> You certainly don't need to know all this. All you need to know is
>>> how much space the decompressor requires after the end of the image,
>>> encompassing the BSS size, stack size and malloc size, which is one
>>> value.
>>
>> I agree. However, since we are not fighting here for every single byte,
>> I'd rather add them as separate values and make the tag, even if only
>> slightly, more future-proof.
>
> It doesn't make it more future-proof. What happens if we add something
> else, do we need to list it separately, and then change the kernel to
> accept the new value and maybe also kexec(8)? Or do we just say "the
> decompressor needs X many bytes after the image" and be done with it?
> The latter sounds way more future-proof to me.
You are right. I changed it to a single value. Done.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] ARM: dts: NSP: Add support for Cisco Meraki MX65(W)
From: Matthew Hagan @ 2020-06-02 16:11 UTC (permalink / raw)
Cc: devicetree, Matthew Hagan, Florian Fainelli, Scott Branden,
Ray Jui, Rob Herring, bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <cover.1591114003.git.mnhagan88@gmail.com>
Hardware Info
-------------
Processor - Broadcom BCM58625 dual-core @ 1.2 GHz
DDR3 RAM - 2GB (4x SK Hynix H5TC4G83CFR)
Flash - 1GB (Micron MT29F8G08ABACA)
Switches - Broadcom BCM58625, 2x Qualcomm Atheros QCA8337
Ports - 12 Ports
Wireless(MX65W) - Broadcom BCM43520KMLG (2X)
Serial Port - 115200 8n1
USB - 1x 2.0
Tested with Kernel 5.4. PCIe is inactive on non-wireless MX65.
Note: The QCA8337 switches are connected to ports 4 and 5 of the BCM58625
SRAB, which need be set to SGMII mode.
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
---
arch/arm/boot/dts/bcm958625-mx65.dts | 15 ++
arch/arm/boot/dts/bcm958625-mx65w.dts | 23 ++
arch/arm/boot/dts/bcm958625-mx65x.dtsi | 321 +++++++++++++++++++++++++
3 files changed, 359 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm958625-mx65.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx65w.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx65x.dtsi
diff --git a/arch/arm/boot/dts/bcm958625-mx65.dts b/arch/arm/boot/dts/bcm958625-mx65.dts
new file mode 100644
index 000000000000..af161d268824
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx65.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree Bindings for Cisco Meraki MX65.
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm958625-mx65x.dtsi"
+
+/ {
+ model = "Cisco Meraki MX65";
+ compatible = "meraki,mx65", "brcm,bcm58625", "brcm,nsp";
+};
diff --git a/arch/arm/boot/dts/bcm958625-mx65w.dts b/arch/arm/boot/dts/bcm958625-mx65w.dts
new file mode 100644
index 000000000000..67933ca7b598
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx65w.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree Bindings for Cisco Meraki MX65W.
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm958625-mx65x.dtsi"
+
+/ {
+ model = "Cisco Meraki MX65W";
+ compatible = "meraki,mx65w", "brcm,bcm58625", "brcm,nsp";
+};
+
+&pcie0 {
+ status = "okay";
+};
+
+&pcie1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm958625-mx65x.dtsi b/arch/arm/boot/dts/bcm958625-mx65x.dtsi
new file mode 100644
index 000000000000..f69949be501e
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx65x.dtsi
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree Bindings for Cisco Meraki MX65 series (Alamo).
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm958625-mx6x-common.dtsi"
+
+#include <dt-bindings/input/input.h>
+
+/ {
+ aliases {
+ mdio-mux-mmio = &mdiomux0;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ power_orange {
+ label = "power:orange";
+ gpios = <&gpioa 3 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ lan_leds {
+ label = "lan:leds";
+ gpios = <&gpioa 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan1_right {
+ label = "wan1:right";
+ gpios = <&gpioa 24 GPIO_ACTIVE_LOW>;
+ };
+
+ wan1_left {
+ label = "wan1:left";
+ gpios = <&gpioa 25 GPIO_ACTIVE_LOW>;
+ };
+
+ wan2_right {
+ label = "wan2:right";
+ gpios = <&gpioa 26 GPIO_ACTIVE_LOW>;
+ };
+
+ wan2_left {
+ label = "wan2:left";
+ gpios = <&gpioa 27 GPIO_ACTIVE_LOW>;
+ };
+
+ power_white {
+ label = "power:white";
+ gpios = <&gpioa 31 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ gpio-buttons {
+ compatible = "gpio-keys-polled";
+ autorepeat;
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpioa 8 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ mdio: mdio@18032000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18032000 0x8>;
+ #size-cells = <0>;
+ #address-cells = <1>;
+ };
+
+ mdiomux0: mdio-mux {
+ compatible = "mdio-mux-mmioreg";
+ reg = <0x18032000 0x4>;
+ mux-mask = <0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio-parent-bus = <&mdio>;
+
+ mdio_int: mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ };
+ mdio_ext: mdio@200 {
+ reg = <0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ mdio-mii-mux {
+ compatible = "mdio-mux-mmioreg";
+ reg = <0x1803f1c0 0x4>;
+ mux-mask = <0x2000>;
+ mdio-parent-bus = <&mdio_ext>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy_port6: phy@0 {
+ reg = <0>;
+ };
+
+ phy_port7: phy@1 {
+ reg = <1>;
+ };
+
+ phy_port8: phy@2 {
+ reg = <2>;
+ };
+
+ phy_port9: phy@3 {
+ reg = <3>;
+ };
+
+ phy_port10: phy@4 {
+ reg = <4>;
+ };
+
+ switch@10 {
+ compatible = "qca,qca8337";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10>;
+ dsa,member = <1 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&sgmii1>;
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan8";
+ phy-handle = <&phy_port6>;
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan9";
+ phy-handle = <&phy_port7>;
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan10";
+ phy-handle = <&phy_port8>;
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan11";
+ phy-handle = <&phy_port9>;
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "lan12";
+ phy-handle = <&phy_port10>;
+ };
+ };
+ };
+ };
+
+ mdio-mii@2000 {
+ reg = <0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy_port1: phy@0 {
+ reg = <0>;
+ };
+
+ phy_port2: phy@1 {
+ reg = <1>;
+ };
+
+ phy_port3: phy@2 {
+ reg = <2>;
+ };
+
+ phy_port4: phy@3 {
+ reg = <3>;
+ };
+
+ phy_port5: phy@4 {
+ reg = <4>;
+ };
+
+ switch@10 {
+ compatible = "qca,qca8337";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10>;
+ dsa,member = <2 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&sgmii0>;
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan3";
+ phy-handle = <&phy_port1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan4";
+ phy-handle = <&phy_port2>;
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan5";
+ phy-handle = <&phy_port3>;
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan6";
+ phy-handle = <&phy_port4>;
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "lan7";
+ phy-handle = <&phy_port5>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&srab {
+ compatible = "brcm,bcm58625-srab", "brcm,nsp-srab";
+ status = "okay";
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ label = "wan1";
+ reg = <0>;
+ };
+
+ port@1 {
+ label = "wan2";
+ reg = <1>;
+ };
+
+ sgmii0: port@4 {
+ label = "sw0";
+ reg = <4>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ sgmii1: port@5 {
+ label = "sw1";
+ reg = <5>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@8 {
+ ethernet = <&amac2>;
+ label = "cpu";
+ reg = <8>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ mdio_sel: mdio {
+ function = "mdio";
+ groups = "mdio_grp";
+ };
+};
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: NSP: Add support for Cisco Meraki MX64(W)
From: Matthew Hagan @ 2020-06-02 16:11 UTC (permalink / raw)
Cc: devicetree, Matthew Hagan, Florian Fainelli, Scott Branden,
Ray Jui, Rob Herring, bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <cover.1591114003.git.mnhagan88@gmail.com>
Hardware Info
-------------
Processor - Broadcom BCM58625 dual-core @ 1.2 GHz
DDR3 RAM - 2GB (4x SK Hynix H5TC4G83CFR)
Flash - 1GB (Micron MT29F8G08ABACA)
Switch - Broadcom BCM58625
Wireless(MX64W) - Broadcom BCM43520KMLG (2x)
Ports - 5 Ports
Serial Port - 115200 8n1
USB - 1x 2.0
Tested with Kernel 5.4. PCIe is inactive on the non-wireless MX64.
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
---
arch/arm/boot/dts/bcm958625-mx64.dts | 15 +++
arch/arm/boot/dts/bcm958625-mx64w.dts | 23 +++++
arch/arm/boot/dts/bcm958625-mx64x.dtsi | 136 +++++++++++++++++++++++++
3 files changed, 174 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm958625-mx64.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx64w.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx64x.dtsi
diff --git a/arch/arm/boot/dts/bcm958625-mx64.dts b/arch/arm/boot/dts/bcm958625-mx64.dts
new file mode 100644
index 000000000000..ec1017b8bf68
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx64.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree Bindings for Cisco Meraki MX64.
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm958625-mx64x.dtsi"
+
+/ {
+ model = "Cisco Meraki MX64";
+ compatible = "meraki,mx64", "brcm,bcm58625", "brcm,nsp";
+};
diff --git a/arch/arm/boot/dts/bcm958625-mx64w.dts b/arch/arm/boot/dts/bcm958625-mx64w.dts
new file mode 100644
index 000000000000..a3fbf0fed218
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx64w.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree Bindings for Cisco Meraki MX64W.
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm958625-mx64x.dtsi"
+
+/ {
+ model = "Cisco Meraki MX64W";
+ compatible = "meraki,mx64w", "brcm,bcm58625", "brcm,nsp";
+};
+
+&pcie0 {
+ status = "okay";
+};
+
+&pcie1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm958625-mx64x.dtsi b/arch/arm/boot/dts/bcm958625-mx64x.dtsi
new file mode 100644
index 000000000000..4be3dd314beb
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx64x.dtsi
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree Bindings for Cisco Meraki MX64 series (Kingpin).
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm958625-mx6x-common.dtsi"
+
+#include <dt-bindings/input/input.h>
+
+/ {
+ leds {
+ compatible = "gpio-leds";
+
+ power_orange {
+ label = "power:orange";
+ gpios = <&gpioa 0 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ lan1_right {
+ label = "lan1:right";
+ gpios = <&gpioa 18 GPIO_ACTIVE_LOW>;
+ };
+
+ lan1_left {
+ label = "lan1:left";
+ gpios = <&gpioa 19 GPIO_ACTIVE_LOW>;
+ };
+
+ lan2_right {
+ label = "lan2:right";
+ gpios = <&gpioa 20 GPIO_ACTIVE_LOW>;
+ };
+
+ lan2_left {
+ label = "lan2:left";
+ gpios = <&gpioa 24 GPIO_ACTIVE_LOW>;
+ };
+
+ lan3_right {
+ label = "lan3:right";
+ gpios = <&gpioa 25 GPIO_ACTIVE_LOW>;
+ };
+
+ lan3_left {
+ label = "lan3:left";
+ gpios = <&gpioa 26 GPIO_ACTIVE_LOW>;
+ };
+
+ lan4_right {
+ label = "lan4:right";
+ gpios = <&gpioa 27 GPIO_ACTIVE_LOW>;
+ };
+
+ lan4_left {
+ label = "lan4:left";
+ gpios = <&gpioa 28 GPIO_ACTIVE_LOW>;
+ };
+
+ wan0_right {
+ label = "wan0:right";
+ gpios = <&gpioa 29 GPIO_ACTIVE_LOW>;
+ };
+
+ wan0_left {
+ label = "wan0:left";
+ gpios = <&gpioa 30 GPIO_ACTIVE_LOW>;
+ };
+
+ power_white {
+ label = "power:white";
+ gpios = <&gpioa 31 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ gpio-buttons {
+ compatible = "gpio-keys-polled";
+ autorepeat;
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpioa 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&srab {
+ compatible = "brcm,bcm58625-srab", "brcm,nsp-srab";
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ label = "lan1";
+ reg = <0>;
+ };
+
+ port@1 {
+ label = "lan2";
+ reg = <1>;
+ };
+
+ port@2 {
+ label = "lan3";
+ reg = <2>;
+ };
+
+ port@3 {
+ label = "lan4";
+ reg = <3>;
+ };
+
+ port@4 {
+ label = "wan0";
+ reg = <4>;
+ };
+
+ port@8 {
+ ethernet = <&amac2>;
+ label = "cpu";
+ reg = <8>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+};
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: NSP: Add common bindings for Meraki MX64/65
From: Matthew Hagan @ 2020-06-02 16:11 UTC (permalink / raw)
Cc: devicetree, Matthew Hagan, Florian Fainelli, Scott Branden,
Ray Jui, Rob Herring, bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <cover.1591114003.git.mnhagan88@gmail.com>
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
---
arch/arm/boot/dts/bcm958625-mx6x-common.dtsi | 172 +++++++++++++++++++
1 file changed, 172 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
diff --git a/arch/arm/boot/dts/bcm958625-mx6x-common.dtsi b/arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
new file mode 100644
index 000000000000..1e253dd0941a
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Common Bindings for Cisco Meraki MX64 (Kingpin) and MX65 (Alamo) devices.
+ *
+ * Copyright (C) 2020 Matthew Hagan <mnhagan88@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "bcm-nsp.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x60000000 0x80000000>;
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ red {
+ label = "pwm:led:red";
+ pwms = <&pwm 1 50000>;
+ };
+
+ green {
+ label = "pwm:led:green";
+ pwms = <&pwm 2 50000>;
+ };
+
+ blue {
+ label = "pwm:led:blue";
+ pwms = <&pwm 3 50000>;
+ };
+ };
+};
+
+&L2 {
+ arm,io-coherent;
+ prefetch-data = <1>;
+ prefetch-instr = <1>;
+};
+
+&uart0 {
+ clock-frequency = <62500000>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ eeprom: at24@50 {
+ compatible = "atmel,24c64";
+ pagesize = <32>;
+ reg = <0x50>;
+ };
+};
+
+&amac2 {
+ status = "okay";
+};
+
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ nand-ecc-strength = <24>;
+ nand-ecc-step-size = <1024>;
+
+ brcm,nand-oob-sector-size = <27>;
+
+ partition@0 {
+ label = "U-boot";
+ reg = <0x00 0x80000>;
+ read-only;
+ };
+
+ partition@80000 {
+ label = "Shmoo";
+ reg = <0x80000 0x80000>;
+ read-only;
+ };
+
+ partition@100000 {
+ label = "bootkernel1";
+ reg = <0x100000 0x300000>;
+ };
+
+ partition@400000 {
+ label = "senao_nvram";
+ reg = <0x400000 0x100000>;
+ };
+
+ partition@500000 {
+ label = "bootkernel2";
+ reg = <0x500000 0x300000>;
+ };
+
+ partition@800000 {
+ label = "ubi";
+ reg = <0x800000 0x3f700000>;
+ };
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&pwm {
+ status = "okay";
+ #pwm-cells = <2>;
+ chan0 {
+ channel = <1>;
+ active_low = <1>;
+ };
+ chan1 {
+ channel = <2>;
+ active_low = <1>;
+ };
+ chan2 {
+ channel = <3>;
+ active_low = <1>;
+ };
+};
+
+&ccbtimer1 {
+ status = "disabled";
+};
+
+&pinctrl {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_sel>, <&gpiobs>, <&pwmc>;
+
+ nand_sel: nand_sel {
+ function = "nand";
+ groups = "nand_grp";
+ };
+
+ gpiobs: gpiobs {
+ function = "gpio_b";
+ groups = "gpio_b_0_grp", "gpio_b_1_grp", "gpio_b_2_grp",
+ "gpio_b_3_grp";
+ };
+
+ pwmc: pwmc {
+ function = "pwm";
+ groups = "pwm0_grp", "pwm1_grp", "pwm2_grp", "pwm3_grp";
+ };
+
+ i2c_sel: i2c {
+ function = "i2c";
+ groups = "i2c_grp";
+ };
+};
+
+&sata_phy {
+ status = "disabled";
+};
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: NSP: Add support for Cisco Meraki NSP devices
From: Matthew Hagan @ 2020-06-02 16:11 UTC (permalink / raw)
Cc: devicetree, Matthew Hagan, Florian Fainelli, Scott Branden,
Ray Jui, Rob Herring, bcm-kernel-feedback-list, linux-arm-kernel
This patch set adds support for the Meraki MX64(W) and MX65(W) security
devices. There are four devices in total, all using the same basic hardware.
The MX64 series has five ethernet ports connected to the BCM SRAB. The MX65
series has two ports conected to the SRAB, and two QCA8337 switches connected
by SGMII to SRAB ports 4 and 5, each providing five additional ports.
The W variants of these devices have two BCM43520s on the PCIe bus. On the
non-wireless variants PCIe is inactive, hence separate dts files.
1/3 contains common bindings for both Meraki devices.
2/3 contains MX64 specific bindings.
3/3 contains MX65 specific bindings.
Note that Chris Packham's "[PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe
deferrals" is also necessary.
Thanks,
Matthew
Matthew Hagan (3):
ARM: dts: NSP: Add common bindings for Meraki MX64/65
ARM: dts: NSP: Add support for Cisco Meraki MX64(W)
ARM: dts: NSP: Add support for Cisco Meraki MX65(W)
arch/arm/boot/dts/bcm958625-mx64.dts | 15 +
arch/arm/boot/dts/bcm958625-mx64w.dts | 23 ++
arch/arm/boot/dts/bcm958625-mx64x.dtsi | 136 ++++++++
arch/arm/boot/dts/bcm958625-mx65.dts | 15 +
arch/arm/boot/dts/bcm958625-mx65w.dts | 23 ++
arch/arm/boot/dts/bcm958625-mx65x.dtsi | 321 +++++++++++++++++++
arch/arm/boot/dts/bcm958625-mx6x-common.dtsi | 172 ++++++++++
7 files changed, 705 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm958625-mx64.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx64w.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx64x.dtsi
create mode 100644 arch/arm/boot/dts/bcm958625-mx65.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx65w.dts
create mode 100644 arch/arm/boot/dts/bcm958625-mx65x.dtsi
create mode 100644 arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 6/9] mtd: rawnand: Hide the generic OOB layout objects behind helpers
From: Boris Brezillon @ 2020-06-02 16:05 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su, Richard Weinberger,
linux-mtd, Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200602143124.29553-7-miquel.raynal@bootlin.com>
On Tue, 2 Jun 2020 16:31:21 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Stop exposing these objects, create helpers to retrieve them instead.
>
> Also export an helper for the Hamming large page ops for later use.
I'd do that in a separate patch.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> drivers/mtd/nand/raw/arasan-nand-controller.c | 2 +-
> drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +-
> drivers/mtd/nand/raw/davinci_nand.c | 3 +-
> .../mtd/nand/raw/ingenic/ingenic_nand_drv.c | 6 ++--
> drivers/mtd/nand/raw/nand_base.c | 35 ++++++++++++++-----
> drivers/mtd/nand/raw/nand_toshiba.c | 2 +-
> drivers/mtd/nand/raw/vf610_nfc.c | 2 +-
> include/linux/mtd/rawnand.h | 5 +--
> 8 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/arasan-nand-controller.c b/drivers/mtd/nand/raw/arasan-nand-controller.c
> index a0b5c539ca73..6fe61393bd26 100644
> --- a/drivers/mtd/nand/raw/arasan-nand-controller.c
> +++ b/drivers/mtd/nand/raw/arasan-nand-controller.c
> @@ -980,7 +980,7 @@ static int anfc_init_hw_ecc_controller(struct arasan_nfc *nfc,
> return -EINVAL;
> }
>
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
>
> ecc->steps = mtd->writesize / ecc->size;
> ecc->algo = NAND_ECC_ALGO_BCH;
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index 3fba91d7991a..08df7f23b859 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -1108,7 +1108,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
>
> chip->options |= NAND_NO_SUBPAGE_WRITE;
>
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
>
> return 0;
> }
> diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
> index 58966a9706b1..427f320fb79b 100644
> --- a/drivers/mtd/nand/raw/davinci_nand.c
> +++ b/drivers/mtd/nand/raw/davinci_nand.c
> @@ -645,7 +645,8 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
> mtd_set_ooblayout(mtd,
> &hwecc4_small_ooblayout_ops);
> } else if (chunks == 4 || chunks == 8) {
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd,
> + nand_get_large_page_ooblayout());
> info->chip.ecc.read_page = nand_davinci_read_page_hwecc_oob_first;
> } else {
> return -EIO;
> diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
> index 70309f18124c..0e9d426fe4f2 100644
> --- a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
> +++ b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
> @@ -243,8 +243,10 @@ static int ingenic_nand_attach_chip(struct nand_chip *chip)
> /* For legacy reasons we use a different layout on the qi,lb60 board. */
> if (of_machine_is_compatible("qi,lb60"))
> mtd_set_ooblayout(mtd, &qi_lb60_ooblayout_ops);
> - else
> + else if (nfc->soc_info->oob_layout)
> mtd_set_ooblayout(mtd, nfc->soc_info->oob_layout);
> + else
> + mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
>
> return 0;
> }
> @@ -532,7 +534,6 @@ static const struct jz_soc_info jz4740_soc_info = {
> .data_offset = 0x00000000,
> .cmd_offset = 0x00008000,
> .addr_offset = 0x00010000,
> - .oob_layout = &nand_ooblayout_lp_ops,
> };
>
> static const struct jz_soc_info jz4725b_soc_info = {
> @@ -546,7 +547,6 @@ static const struct jz_soc_info jz4780_soc_info = {
> .data_offset = 0x00000000,
> .cmd_offset = 0x00400000,
> .addr_offset = 0x00800000,
> - .oob_layout = &nand_ooblayout_lp_ops,
> };
>
> static const struct of_device_id ingenic_nand_dt_match[] = {
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index ed0f642be993..f120b0b4f591 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -95,11 +95,16 @@ static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
> return 0;
> }
>
> -const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
> +static const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
> .ecc = nand_ooblayout_ecc_sp,
> .free = nand_ooblayout_free_sp,
> };
> -EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
> +
> +const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void)
> +{
> + return &nand_ooblayout_sp_ops;
> +}
> +EXPORT_SYMBOL_GPL(nand_get_small_page_ooblayout);
>
> static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> @@ -131,11 +136,16 @@ static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
> return 0;
> }
>
> -const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
> +static const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
> .ecc = nand_ooblayout_ecc_lp,
> .free = nand_ooblayout_free_lp,
> };
> -EXPORT_SYMBOL_GPL(nand_ooblayout_lp_ops);
> +
> +const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void)
> +{
> + return &nand_ooblayout_lp_ops;
> +}
> +EXPORT_SYMBOL_GPL(nand_get_large_page_ooblayout);
>
> /*
> * Support the old "large page" layout used for 1-bit Hamming ECC where ECC
> @@ -205,6 +215,12 @@ static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
> .free = nand_ooblayout_free_lp_hamming,
> };
>
> +const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
> +{
> + return &nand_ooblayout_lp_hamming_ops;
> +}
> +EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
> +
> static int nand_pairing_dist3_get_info(struct mtd_info *mtd, int page,
> struct mtd_pairing_info *info)
> {
> @@ -5382,7 +5398,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
> return -EINVAL;
> }
>
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
>
> }
>
> @@ -5391,7 +5407,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
> * used, otherwise we don't know how many bytes can really be
> * used.
> */
> - if (mtd->ooblayout == &nand_ooblayout_lp_ops &&
> + if (mtd->ooblayout == nand_get_large_page_ooblayout() &&
> ecc->options & NAND_ECC_MAXIMIZE) {
> int steps, bytes;
>
> @@ -5793,11 +5809,12 @@ static int nand_scan_tail(struct nand_chip *chip)
> switch (mtd->oobsize) {
> case 8:
> case 16:
> - mtd_set_ooblayout(mtd, &nand_ooblayout_sp_ops);
> + mtd_set_ooblayout(mtd, nand_get_small_page_ooblayout());
> break;
> case 64:
> case 128:
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_hamming_ops);
> + mtd_set_ooblayout(mtd,
> + nand_get_large_page_hamming_ooblayout());
> break;
> default:
> /*
> @@ -5809,7 +5826,7 @@ static int nand_scan_tail(struct nand_chip *chip)
> */
> if (ecc->engine_type == NAND_ECC_ENGINE_TYPE_NONE) {
> mtd_set_ooblayout(mtd,
> - &nand_ooblayout_lp_ops);
> + nand_get_large_page_ooblayout());
> break;
> }
>
> diff --git a/drivers/mtd/nand/raw/nand_toshiba.c b/drivers/mtd/nand/raw/nand_toshiba.c
> index 8fcf40d0ba0a..3174914e33e0 100644
> --- a/drivers/mtd/nand/raw/nand_toshiba.c
> +++ b/drivers/mtd/nand/raw/nand_toshiba.c
> @@ -140,7 +140,7 @@ static void toshiba_nand_benand_init(struct nand_chip *chip)
>
> chip->options |= NAND_SUBPAGE_READ;
>
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
> }
>
> static void toshiba_nand_decode_id(struct nand_chip *chip)
> diff --git a/drivers/mtd/nand/raw/vf610_nfc.c b/drivers/mtd/nand/raw/vf610_nfc.c
> index 8ee2c1f539c4..50dc0c93140c 100644
> --- a/drivers/mtd/nand/raw/vf610_nfc.c
> +++ b/drivers/mtd/nand/raw/vf610_nfc.c
> @@ -779,7 +779,7 @@ static int vf610_nfc_attach_chip(struct nand_chip *chip)
> mtd->oobsize = 64;
>
> /* Use default large page ECC layout defined in NAND core */
> - mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
> + mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
> if (chip->ecc.strength == 32) {
> nfc->ecc_mode = ECC_60_BYTE;
> chip->ecc.bytes = 60;
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index 8f7f1cce3b4b..f3eb47c09e57 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -1159,8 +1159,9 @@ struct nand_chip {
> int (*unlock_area)(struct nand_chip *chip, loff_t ofs, uint64_t len);
> };
>
> -extern const struct mtd_ooblayout_ops nand_ooblayout_sp_ops;
> -extern const struct mtd_ooblayout_ops nand_ooblayout_lp_ops;
> +const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void);
> +const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void);
> +const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void);
>
> static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
> {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 5/9] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Boris Brezillon @ 2020-06-02 16:03 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su, Richard Weinberger,
linux-mtd, Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200602143124.29553-6-miquel.raynal@bootlin.com>
On Tue, 2 Jun 2020 16:31:20 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Embed a generic NAND ECC high-level object in the nand_device
> structure to carry all the ECC engine configuration/data.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/raw/nand_base.c | 4 +++-
> include/linux/mtd/nand.h | 12 ++++++------
> 2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index e8e22d79f422..ed0f642be993 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5984,7 +5984,9 @@ static int nand_scan_tail(struct nand_chip *chip)
> /* ECC sanity check: warn if it's too weak */
> if (!nand_ecc_strength_good(chip))
> pr_warn("WARNING: %s: the ECC used on your system (%db/%dB) is too weak compared to the one required by the NAND chip (%db/%dB)\n",
> - mtd->name, chip->ecc.strength, chip->ecc.size,
> + mtd->name,
> + nanddev_get_ecc_conf(&chip->base)->strength,
> + nanddev_get_ecc_conf(&chip->base)->step_size,
Hm, are you sure all places using chip->ecc.{strength,size} have been
patched to use nanddev_get_ecc_conf()?
> nanddev_get_ecc_requirements(&chip->base)->strength,
> nanddev_get_ecc_requirements(&chip->base)->step_size);
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 0b89da54bef2..668c99c4aaa7 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -290,7 +290,7 @@ struct nand_ecc {
> * struct nand_device - NAND device
> * @mtd: MTD instance attached to the NAND device
> * @memorg: memory layout
> - * @eccreq: ECC requirements
> + * @ecc: NAND ECC object attached to the NAND device
> * @rowconv: position to row address converter
> * @bbt: bad block table info
> * @ops: NAND operations attached to the NAND device
> @@ -298,8 +298,8 @@ struct nand_ecc {
> * Generic NAND object. Specialized NAND layers (raw NAND, SPI NAND, OneNAND)
> * should declare their own NAND object embedding a nand_device struct (that's
> * how inheritance is done).
> - * struct_nand_device->memorg and struct_nand_device->eccreq should be filled
> - * at device detection time to reflect the NAND device
> + * struct_nand_device->memorg and struct_nand_device->ecc.requirements should
> + * be filled at device detection time to reflect the NAND device
> * capabilities/requirements. Once this is done nanddev_init() can be called.
> * It will take care of converting NAND information into MTD ones, which means
> * the specialized NAND layers should never manually tweak
> @@ -308,7 +308,7 @@ struct nand_ecc {
> struct nand_device {
> struct mtd_info mtd;
> struct nand_memory_organization memorg;
> - struct nand_ecc_props eccreq;
> + struct nand_ecc ecc;
> struct nand_row_converter rowconv;
> struct nand_bbt bbt;
> const struct nand_ops *ops;
> @@ -519,7 +519,7 @@ nanddev_get_memorg(struct nand_device *nand)
> static inline const struct nand_ecc_props *
> nanddev_get_ecc_conf(struct nand_device *nand)
> {
> - return &nand->eccreq;
> + return &nand->ecc.ctx.conf;
> }
>
> /**
> @@ -530,7 +530,7 @@ nanddev_get_ecc_conf(struct nand_device *nand)
> static inline const struct nand_ecc_props *
> nanddev_get_ecc_requirements(struct nand_device *nand)
> {
> - return &nand->eccreq;
> + return &nand->ecc.requirements;
> }
>
> int nanddev_init(struct nand_device *nand, const struct nand_ops *ops,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 4/9] mtd: rawnand: Use nanddev_get_ecc_requirements() when relevant
From: Boris Brezillon @ 2020-06-02 16:00 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su, Richard Weinberger,
linux-mtd, Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200602143124.29553-5-miquel.raynal@bootlin.com>
On Tue, 2 Jun 2020 16:31:19 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 1ce2cbe72e4c..e8e22d79f422 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4725,6 +4725,9 @@ static inline bool is_full_id_nand(struct nand_flash_dev *type)
> static bool find_full_id_nand(struct nand_chip *chip,
> struct nand_flash_dev *type)
> {
> + struct nand_device *base = &chip->base;
> + struct nand_ecc_props *requirements =
> + (struct nand_ecc_props *)nanddev_get_ecc_requirements(base);
Ouch, that sounds wrong. How about introducing a
nanddev_set_ecc_requirements() helper instead? The same applies to all
places where you have this cast.
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index e572d1600f63..0b89da54bef2 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -527,7 +527,7 @@ nanddev_get_ecc_conf(struct nand_device *nand)
> * device
> * @nand: NAND device
> */
> -const struct nand_ecc_props *
> +static inline const struct nand_ecc_props *
> nanddev_get_ecc_requirements(struct nand_device *nand)
Looks like this should be squashed in patch 2.
> {
> return &nand->eccreq;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
From: Maxime Ripard @ 2020-06-02 15:54 UTC (permalink / raw)
To: Eric Anholt
Cc: Tim Gover, Dave Stevenson, linux-kernel, DRI Development,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <CADaigPXJ0BnMUp=XN6G92Tx=H9j55pmsBAujO2mcpiiTs-RHnQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2755 bytes --]
On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > the vc4_hdmi driver has some custom structures to hold the data it needs to
> > associate with the drm_encoder and drm_connector structures.
> >
> > However, it allocates them separately from the vc4_hdmi structure which
> > makes it more complicated than it needs to be.
> >
> > Move those structures to be contained by vc4_hdmi and update the code
> > accordingly.
>
>
> > @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
> > struct drm_device *drm = dev_get_drvdata(master);
> > struct vc4_dev *vc4 = drm->dev_private;
> > struct vc4_hdmi *hdmi;
> > - struct vc4_hdmi_encoder *vc4_hdmi_encoder;
> > + struct drm_encoder *encoder;
> > struct device_node *ddc_node;
> > u32 value;
> > int ret;
> > @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
> > if (!hdmi)
> > return -ENOMEM;
> >
> > - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder),
> > - GFP_KERNEL);
> > - if (!vc4_hdmi_encoder)
> > - return -ENOMEM;
> > - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
> > - hdmi->encoder = &vc4_hdmi_encoder->base.base;
> > -
> > hdmi->pdev = pdev;
> > + encoder = &hdmi->encoder.base.base;
> > + encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
>
> Wait, does this patch build?
All those patches were build tested, so yep
> setting struct drm_encoder->base.type = VC4_* seems very wrong, when
> previously we were setting struct vc4_hdmi_encoder->base.type (struct
> vc4_encoder->type).
So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as
encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder.
vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and
vc4_encoder's base is a drm_encoder.
so encoder being a drm_encoder is correct there.
However, drm_encoder's base is drm_mode_object that does have a type
field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just
fine...
Now, drm_encoder_init will then kick in and call drm_mode_object_add
which will override it to a proper value and since the clock select bit
in the PV is the same for both HDMI0 and HDMI1, everything works just
fine...
Good catch, I'll fix it. And I guess it's a good indication we don't
need a separate HDMI0 and HDMI1 encoder type.
> Other than this, patch 68-78 r-b.
Thanks for your review!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/9] mtd: nand: Create a helper to extract the ECC configuration
From: Boris Brezillon @ 2020-06-02 15:51 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su, Richard Weinberger,
linux-mtd, Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200602143124.29553-2-miquel.raynal@bootlin.com>
On Tue, 2 Jun 2020 16:31:16 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Despite its current name "eccreq", this object first stores data that
> is meant to be the requirements, and then this data gets eventually
> updated and becomes the actual configuration.
Despite its current name, the eccreq field actually encodes both the
NAND requirements and the final ECC configuration. That works fine when
using on-die ECC since those 2 concepts match perfectly, but it starts
being a problem as soon as we use on-host ECC engines, where we're not
guaranteed to have a perfect match.
> Abstracting this
> indirection will help us clarify the structures in a future change.
Let's hide the ECC configuration access behind a helper so we can later
split those 2 concepts.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> include/linux/mtd/nand.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2f838394b5f7..7fd0d492073b 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -512,6 +512,16 @@ nanddev_get_memorg(struct nand_device *nand)
> return &nand->memorg;
> }
>
> +/**
> + * nanddev_get_ecc_conf() - Extract the ECC configuration from a NAND device
> + * @nand: NAND device
> + */
> +static inline const struct nand_ecc_props *
> +nanddev_get_ecc_conf(struct nand_device *nand)
> +{
> + return &nand->eccreq;
> +}
> +
> int nanddev_init(struct nand_device *nand, const struct nand_ops *ops,
> struct module *owner);
> void nanddev_cleanup(struct nand_device *nand);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
From: William Breathitt Gray @ 2020-06-02 15:46 UTC (permalink / raw)
To: David Lechner
Cc: kamel.bouhara, gwendal, alexandre.torgue, linux-iio,
patrick.havelange, alexandre.belloni, linux-kernel,
linux-arm-kernel, mcoquelin.stm32, fabrice.gasnier, syednwaris,
linux-stm32, Jonathan Cameron
In-Reply-To: <ac473c9a-f9cd-21ae-8f8f-d5181df2c134@lechnology.com>
[-- Attachment #1.1: Type: text/plain, Size: 2311 bytes --]
On Tue, Jun 02, 2020 at 10:18:07AM -0500, David Lechner wrote:
> On 5/31/20 12:14 PM, William Breathitt Gray wrote:
> > Yielding the following /dev/counter0 memory layout:
> >
> > +------------+-----------------+------------+-------------------+
> > | Byte 0 | Byte 1 - Byte 8 | Byte 9 | Byte 10 - Byte 17 |
> > +------------+-----------------+------------+-------------------+
> > | Boundary 0 | Count 0 | Boundary 1 | Count 1 |
> > +------------+-----------------+------------+-------------------+
>
> A potential pitfall with this sort of packing is that some platforms
> do not support unaligned access, so data would have to be "unpacked"
> before it could be used.
Since the user defines the format of this data, they could reorganize it
to a more streamline alignment; for example:
# echo "C0 C1 C0E0 C1E0" > counter0/chrdev_format
Yielding the following /dev/counter0 memory layout instead:
+-----------------+------------------+------------+------------+
| Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 |
+-----------------+------------------+------------+------------+
| Count 0 | Count 1 | Boundary 0 | Boundary 1 |
+-----------------+------------------+------------+------------+
In the future, we could also define a padding argument to give users
more control over the exact offsets:
# echo "C0E0 P7 C0 C1E0 P7 C1" > counter0/chrdev_format
Yielding the following /dev/counter0 memory layout instead:
+------------+-----------------+------------------+------------+
| Byte 0 | Byte 1 - Byte 7 | Byte 8 - Byte 15 | Byte 16 |
+------------+-----------------+------------------+------------+
| Boundary 0 | Padding | Count 0 | Boundary 1 |
+------------+-----------------+------------------+------------+
+-------------------+-------------------+
| Byte 17 - Byte 23 | Byte 24 - Byte 31 |
+-------------------+-------------------+
| Padding | Count 1 |
+-------------------+-------------------+
I not sure it's best to introduce padding support with this patchset
given how much is already changing, but I don't anticipate packing
alignment to be something difficult to support in the future with this
interface.
William Breathitt Gray
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-06-02 15:44 UTC (permalink / raw)
To: Marco Felsch
Cc: robh, kernel, Anson.Huang, devicetree, shawnguo, s.hauer, angus,
linux-kernel, linux-imx, kernel, mchehab, festevam, agx,
linux-arm-kernel
In-Reply-To: <20200527093538.xqtdoybl5hx27ccv@pengutronix.de>
Hi Marco,
On 27.05.20 11:35, Marco Felsch wrote:
> Hi Martin,
>
> On 20-05-14 17:57, Martin Kepplinger wrote:
>> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>>
>> Add a devicetree description for the Librem 5 phone. The early batches
>> that have been sold are supported as well as the mass-produced device
>> available later this year, see https://puri.sm/products/librem-5/
>>
>> This boots to a working console with working WWAN modem, wifi usdhc,
>> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>>
>> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
>> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
>> Signed-off-by: Guido Günther <agx@sigxcpu.org>
>> ---
>> arch/arm64/boot/dts/freescale/Makefile | 1 +
>> .../boot/dts/freescale/imx8mq-librem5.dts | 1174 +++++++++++++++++
>> 2 files changed, 1175 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>>
>> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
>> index cd38d04da5a7..342579121f98 100644
>> --- a/arch/arm64/boot/dts/freescale/Makefile
>> +++ b/arch/arm64/boot/dts/freescale/Makefile
>> @@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
>> +dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
>> dtb-$(CONFIG_ARCH_MXC) += imx8mq-phanbell.dtb
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>> new file mode 100644
>> index 000000000000..95c105b4c120
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>> @@ -0,0 +1,1174 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright 2018-2020 Purism SPC
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "dt-bindings/input/input.h"
>> +#include "dt-bindings/pwm/pwm.h"
>> +#include "dt-bindings/usb/pd.h"
>> +#include "imx8mq.dtsi"
>> +
>> +/ {
>> + model = "Purism Librem 5";
>> + compatible = "purism,librem5", "fsl,imx8mq";
>> +
>> + backlight_dsi: backlight-dsi {
>> + compatible = "led-backlight";
>> + leds = <&led_backlight>;
>> + brightness-levels = <255>;
>> + default-brightness-level = <100>;
>> + };
>> +
>> + bm818_codec: sound-wwan-codec {
>> + compatible = "broadmobi,bm818", "option,gtm601";
>> + #sound-dai-cells = <0>;
>> + };
>
> Please sort the node names alpabetical.
>
>> +
>> + chosen {
>> + stdout-path = &uart1;
>> + };
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_keys>, <&pinctrl_hp>;
>> +
>> + hp-det {
>> + label = "HP_DET";
>> + gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
>> + wakeup-source;
>> + linux,code = <KEY_HP>;
>
> Nit: I would add the wakeup-source behind the linux,code.
>
>> + };
>> +
>> + vol-down {
>> + label = "VOL_DOWN";
>> + gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
>> + linux,code = <KEY_VOLUMEDOWN>;
>> + };
>> +
>> + vol-up {
>> + label = "VOL_UP";
>> + gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
>> + linux,code = <KEY_VOLUMEUP>;
>> + };
>> + };
>> +
>> + pwmleds {
>> + compatible = "pwm-leds";
>> +
>> + blue {
>> + label = "phone:blue:front";
>> + max-brightness = <248>;
>> + pwms = <&pwm2 0 50000>;
>> + };
>> +
>> + green {
>> + label = "phone:green:front";
>> + max-brightness = <248>;
>> + pwms = <&pwm4 0 50000>;
>> + };
>> +
>> + red {
>> + label = "phone:red:front";
>> + max-brightness = <248>;
>> + pwms = <&pwm3 0 50000>;
>> + };
>> + };
>> +
>> + pmic_osc: clock-pmic {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <32768>;
>> + clock-output-names = "pmic_osc";
>> + };
>
> Please sort nodes alphabetical.
>
>> +
>> + reg_audio_pwr_en: regulator-audio-pwr-en {
>> + compatible = "regulator-fixed";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_audiopwr>;
>> + regulator-name = "AUDIO_PWR_EN";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + regulator-always-on;
>
> Why should this regulator be always on? The wm8962.c driver can handle
> the regualtor enable/disable.
It can indeed be handled by the driver here. We keep it always on
because of issues with the display stack that are not yet part of this
description.
>
>> + };
>> +
>> + reg_aud_1v8: regulator-audio-v1v8 {
> ^
> regulator-audio-1v8?
>
>> + compatible = "regulator-fixed";
>> + regulator-name = "aud_1v8";
>
> Is it intended to use capitalized and no-capitalized regulator-name's?
>
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + vin-supply = <®_audio_pwr_en>;
>> + };
>
> Can we squash regulator-audio-pwr-en and regulator-audio-v1v8?
I think we can.
>
>> +
>> + reg_gnss: regulator-gnss {
>> + compatible = "regulator-fixed";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gnsspwr>;
>> + regulator-name = "GNSS";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpio = <&gpio3 12 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + };
>> +
>> + reg_hub: regulator-hub {
>> + compatible = "regulator-fixed";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_hub_pwr>;
>> + regulator-name = "HUB";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + };
>> +
>> + reg_lcd_1v8: regulator-lcd-1v8 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "lcd_1v8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_dsien>;
>> + vin-supply = <®_vdd_1v8>;
>> + enable-active-high;
>> + gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
>> + };
>
> This regulator is never used.
>
>> +
>> + reg_lcd_3v4: regulator-lcd-3v4 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "lcd_3v4";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_dsibiasen>;
>> + vin-supply = <®_vsys_3v4>;
>> + enable-active-high;
>> + gpio = <&gpio1 20 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + reg_vdd_sen: regulator-vdd-sen {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vdd_sen";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> +
>> + reg_vdd_3v3: regulator-vdd-3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vdd_3v3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> +
>> + reg_vdd_1v8: regulator-vdd-1v8 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vdd_1v8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + };
>> +
>> + reg_vsys_3v4: regulator-vsys-3v4 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vsys_3v4";
>> + regulator-min-microvolt = <3400000>;
>> + regulator-max-microvolt = <3400000>;
>> + regulator-always-on;
>> + };
>> +
>> + reg_3v3_wifi: regulator-3v3-wifi {
> ^
> reg_wifi_3v3: regulator-wifi-3v3?
>
>> + compatible = "regulator-fixed";
>> + regulator-name = "3v3_wifi";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> +
>> + sound {
>> + compatible = "simple-audio-card";
>> + simple-audio-card,name = "wm8962";
>> + simple-audio-card,format = "i2s";
>> + simple-audio-card,widgets =
>> + "Headphone", "Headphone",
>> + "Microphone", "Headset Mic",
>> + "Microphone", "Digital Mic",
>> + "Speaker", "Speaker";
>> + simple-audio-card,routing =
>> + "Headphone", "HPOUTL",
>> + "Headphone", "HPOUTR",
>> + "Speaker", "SPKOUTL",
>> + "Speaker", "SPKOUTR",
>> + "Headset Mic", "MICBIAS",
>> + "IN3R", "Headset Mic",
>> + "DMICDAT", "Digital Mic";
>> + simple-audio-card,cpu {
>> + sound-dai = <&sai2>;
>> + };
>> + simple-audio-card,codec {
>> + sound-dai = <&codec>;
>> + clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
>> + frame-master;
>> + bitclock-master;
>> + };
>> + };
>> +
>> + sound-wwan {
>> + compatible = "simple-audio-card";
>> + simple-audio-card,name = "MODEM";
>> + simple-audio-card,format = "i2s";
>> +
>> + simple-audio-card,cpu {
>> + sound-dai = <&sai6>;
>> + frame-inversion;
>> + };
>> +
>> + telephony_link_master: simple-audio-card,codec {
> ^
> useless phandle?
>> + sound-dai = <&bm818_codec>;
>> + frame-master;
>> + bitclock-master;
>> + };
>> + };
>> +
>> + vibrator {
>> + compatible = "pwm-vibrator";
>> + pwms = <&pwm1 0 1000000000 0>;
>> + pwm-names = "enable";
>> + vcc-supply = <®_vdd_3v3>;
>> + };
>> +};
>> +
>> +&A53_0 {
>> + cpu-supply = <&buck2_reg>;
>> +};
>> +
>> +&A53_1 {
>> + cpu-supply = <&buck2_reg>;
>> +};
>> +
>> +&A53_2 {
>> + cpu-supply = <&buck2_reg>;
>> +};
>> +
>> +&A53_3 {
>> + cpu-supply = <&buck2_reg>;
>> +};
>> +
>> +&clk {
>> + assigned-clocks = <&clk IMX8MQ_AUDIO_PLL1>, <&clk IMX8MQ_AUDIO_PLL2>;
>> + assigned-clock-rates = <786432000>, <722534400>;
>> +};
>
> Either I would bundle all clock settings here or within the sai nodes.
You're right, I'll try to move them.
>
>> +
>> +&ddrc {
>> + operating-points-v2 = <&ddrc_opp_table>;
>> +
>> + ddrc_opp_table: ddrc-opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-25M {
>> + opp-hz = /bits/ 64 <25000000>;
>> + };
>> + opp-100M {
>> + opp-hz = /bits/ 64 <100000000>;
>> + };
>> + opp-800M {
>> + opp-hz = /bits/ 64 <800000000>;
>> + };
>> + };
>> +};
>> +
>> +&dphy {
>> + status = "okay";
>> +};
>> +
>> +&ecspi1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ecspi1>;
>> + cs-gpios = <&gpio5 9 GPIO_ACTIVE_HIGH>;
>
> Missmatch with the pinctrl_ecspi1?
>
>> + status = "okay";
>
> Status is always the last property.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + nor_flash: flash@0 {
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <1000000>;
>> + reg = <0>;
>> + };
>> +};
>> +
>> +&gpio1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pmic_5v>;
>> +
>> + pmic-5v {
>> + gpio-hog;
>> + gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
>> + input;
>> + };
>> +};
>> +
>> +&iomuxc {
>> + pinctrl_audiopwr: audiopwrgrp {
>> + fsl,pins = <
>> + /* AUDIO_POWER_EN_3V3 */
>> + MX8MQ_IOMUXC_GPIO1_IO04_GPIO1_IO4 0x83
>> + >;
>> + };
>> +
>> + pinctrl_bl: blgrp {
>> + fsl,pins = <
>> + /* BACKLINGE_EN */
>> + MX8MQ_IOMUXC_NAND_DQS_GPIO3_IO14 0x83
>> + >;
>> + };
>> +
>> + pinctrl_charger_in: chargeringrp {
>> + fsl,pins = <
>> + /* CHRG_INT */
>> + MX8MQ_IOMUXC_NAND_CE2_B_GPIO3_IO3 0x80
>> + /* CHG_STATUS_B */
>> + MX8MQ_IOMUXC_NAND_ALE_GPIO3_IO0 0x80
>> + >;
>> + };
>> +
>> + pinctrl_dsibiasen: dsibiasengrp {
>> + fsl,pins = <
>> + /* DSI_BIAS_EN */
>> + MX8MQ_IOMUXC_ENET_TD1_GPIO1_IO20 0x83
>> + >;
>> + };
>> +
>> + pinctrl_dsien: dsiengrp {
>> + fsl,pins = <
>> + /* DSI_EN_3V3 */
>> + MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x83
>> + >;
>> + };
>> +
>> + pinctrl_ecspi1: spi1grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x83
>> + MX8MQ_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x83
>> + MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x19
>> + MX8MQ_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x83
>> + /* SPI_SS1 */
>> + MX8MQ_IOMUXC_UART4_RXD_GPIO5_IO28 0x19
>> + >;
>> + };
>> +
>> + pinctrl_gauge: gaugegrp {
>> + fsl,pins = <
>> + /* BAT_LOW */
>> + MX8MQ_IOMUXC_SAI5_RXC_GPIO3_IO20 0x80
>> + >;
>> + };
>> +
>> + pinctrl_gnsspwr: gnsspwrgrp {
>> + fsl,pins = <
>> + /* GPS3V3_EN */
>> + MX8MQ_IOMUXC_NAND_DATA06_GPIO3_IO12 0x83
>> + >;
>> + };
>> +
>> + pinctrl_haptic: hapticgrp {
>> + fsl,pins = <
>> + /* MOTO */
>> + MX8MQ_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT 0x83
>> + >;
>> + };
>> +
>> + pinctrl_hp: hpgrp {
>> + fsl,pins = <
>> + /* HEADPHONE_DET_1V8 */
>> + MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x180
>> + >;
>> + };
>> +
>> + pinctrl_hub_pwr: hubpwrgrp {
>> + fsl,pins = <
>> + /* HUB_PWR_3V3_EN */
>> + MX8MQ_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x83
>> + >;
>> + };
>> +
>> + pinctrl_i2c1: i2c1grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x40000026
>> + MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x40000026
>> + >;
>> + };
>> +
>> + pinctrl_i2c2: i2c2grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x40000026
>> + MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x40000026
>> + >;
>> + };
>> +
>> + pinctrl_i2c3: i2c3grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_I2C3_SCL_I2C3_SCL 0x40000026
>> + MX8MQ_IOMUXC_I2C3_SDA_I2C3_SDA 0x40000026
>> + >;
>> + };
>> +
>> + pinctrl_i2c4: i2c4grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_I2C4_SCL_I2C4_SCL 0x40000026
>> + MX8MQ_IOMUXC_I2C4_SDA_I2C4_SDA 0x40000026
>> + >;
>> + };
>> +
>> + pinctrl_keys: keysgrp {
>> + fsl,pins = <
>> + /* 4G_WAKE */
>> + MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x80
>> + /* PWR_KEY */
>> + MX8MQ_IOMUXC_NAND_CLE_GPIO3_IO5 0x01C0
>
> gpio3 5/15 are never used was this intended?
>
>> + /* VOL- */
>> + MX8MQ_IOMUXC_ENET_MDIO_GPIO1_IO17 0x01C0
>> + /* VOL+ */
>> + MX8MQ_IOMUXC_ENET_MDC_GPIO1_IO16 0x01C0
>> + >;
>> + };
>> +
>> + pinctrl_led_b: ledbgrp {
>> + fsl,pins = <
>> + /* LED_B */
>> + MX8MQ_IOMUXC_GPIO1_IO13_PWM2_OUT 0x06
>> + >;
>> + };
>> +
>> + pinctrl_led_g: ledggrp {
>> + fsl,pins = <
>> + /* LED_G */
>> + MX8MQ_IOMUXC_SAI3_MCLK_PWM4_OUT 0x06
>> + >;
>> + };
>> +
>> + pinctrl_led_r: ledrgrp {
>> + fsl,pins = <
>> + /* LED_R */
>> + MX8MQ_IOMUXC_SPDIF_TX_PWM3_OUT 0x06
>> + >;
>> + };
>> +
>> + pinctrl_mag: maggrp {
>> + fsl,pins = <
>> + /* INT_MAG */
>> + MX8MQ_IOMUXC_SAI5_RXD1_GPIO3_IO22 0x80
>> + >;
>> + };
>> +
>> + pinctrl_pmic: pmicgrp {
>> + fsl,pins = <
>> + /* PMIC_NINT */
>> + MX8MQ_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x80
>> + >;
>> + };
>> +
>> + pinctrl_pmic_5v: pmic5vgrp {
>> + fsl,pins = <
>> + /* PMIC_5V */
>> + MX8MQ_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x80
>> + >;
>> + };
>> +
>> + pinctrl_prox: proxgrp {
>> + fsl,pins = <
>> + /* INT_LIGHT */
>> + MX8MQ_IOMUXC_NAND_DATA01_GPIO3_IO7 0x80
>> + >;
>> + };
>> +
>> + pinctrl_rtc: rtcgrp {
>> + fsl,pins = <
>> + /* RTC_INT */
>> + MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x80
>> + >;
>> + };
>> +
>> + pinctrl_sai2: sai2grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SAI2_TXD0_SAI2_TX_DATA0 0xd6
>> + MX8MQ_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0xd6
>> + MX8MQ_IOMUXC_SAI2_MCLK_SAI2_MCLK 0xd6
>> + MX8MQ_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0xd6
>> + MX8MQ_IOMUXC_SAI2_TXC_SAI2_TX_BCLK 0xd6
>> + >;
>> + };
>> +
>> + pinctrl_sai6: sai6grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SAI1_RXD5_SAI6_RX_DATA0 0xd6
>> + MX8MQ_IOMUXC_SAI1_RXD6_SAI6_RX_SYNC 0xd6
>> + MX8MQ_IOMUXC_SAI1_TXD4_SAI6_RX_BCLK 0xd6
>> + MX8MQ_IOMUXC_SAI1_TXD5_SAI6_TX_DATA0 0xd6
>> + >;
>> + };
>> +
>> + pinctrl_tcpc: tcpcgrp {
>> + fsl,pins = <
>> + /* TCPC_INT */
>> + MX8MQ_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x01C0
>> + >;
>> + };
>> +
>> + pinctrl_typec: typecgrp {
>> + fsl,pins = <
>> + /* TYPEC_MUX_EN */
>> + MX8MQ_IOMUXC_GPIO1_IO11_GPIO1_IO11 0x83
>> + >;
>> + };
>> +
>> + pinctrl_uart1: uart1grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49
>> + MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
>> + >;
>> + };
>> +
>> + pinctrl_uart2: uart2grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
>> + MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
>> + >;
>> + };
>> +
>> + pinctrl_uart3: uart3grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
>> + MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
>> + >;
>> + };
>> +
>> + pinctrl_uart4: uart4grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x49
>> + MX8MQ_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x49
>> + MX8MQ_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x49
>> + MX8MQ_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x49
>> + >;
>> + };
>> +
>> + pinctrl_usdhc1: usdhc1grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
>> + MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
>> + MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
>> + MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x83
>> + MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
>> + >;
>> + };
>> +
>> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
>> + MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
>> + MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
>> + MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x8d
>> + MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
>> + >;
>> + };
>> +
>> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
>> + MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
>> + MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
>> + MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x9f
>> + MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2: usdhc2grp {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
>> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x83
>> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc3
>> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc3
>> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc3
>> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc3
>> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc3
>> + MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
>> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
>> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
>> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
>> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
>> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
>> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
>> + MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
>> + >;
>> + };
>> +
>> + pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
>> + fsl,pins = <
>> + MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
>> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
>> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcf
>> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcf
>> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcf
>> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcf
>> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcf
>> + MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
>> + >;
>> + };
>> +
>> + pinctrl_wdog: wdoggrp {
>> + fsl,pins = <
>> + /* nWDOG */
>> + MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x1f
>> + >;
>> + };
>> +};
>> +
>> +&i2c1 {
>> + clock-frequency = <387000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c1>;
>> + status = "okay";
>> +
>> + typec_pd: usb-pd@3f {
>> + compatible = "ti,tps6598x";
>> + reg = <0x3f>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_typec>, <&pinctrl_tcpc>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
>> +
>> + connector {
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + usb_con_hs: endpoint {
>> + remote-endpoint = <&typec_hs>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + usb_con_ss: endpoint {
>> + remote-endpoint = <&typec_ss>;
>> + };
>> + };
>> + };
>> + };
>> + };
>> +
>> + pmic: pmic@4b {
>> + compatible = "rohm,bd71837";
>> + reg = <0x4b>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pmic>;
>> + clocks = <&pmic_osc>;
>> + clock-names = "osc";
>> + clock-output-names = "pmic_clk";
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <7 GPIO_ACTIVE_LOW>;
>> + interrupt-names = "irq";
>> + rohm,reset-snvs-powered;
>> +
>> + regulators {
>> + buck1_reg: BUCK1 {
>> + regulator-name = "buck1";
>> + regulator-min-microvolt = <700000>;
>> + regulator-max-microvolt = <1300000>;
>> + regulator-ramp-delay = <1250>;
>> + rohm,dvs-run-voltage = <900000>;
>> + rohm,dvs-idle-voltage = <850000>;
>> + rohm,dvs-suspend-voltage = <800000>;
>> + regulator-always-on;
>> + };
>> +
>> + buck2_reg: BUCK2 {
>> + regulator-name = "buck2";
>> + regulator-min-microvolt = <700000>;
>> + regulator-max-microvolt = <1300000>;
>> + regulator-ramp-delay = <1250>;
>> + rohm,dvs-run-voltage = <1000000>;
>> + rohm,dvs-idle-voltage = <900000>;
>> + regulator-always-on;
>> + };
>> +
>> + buck3_reg: BUCK3 {
>> + regulator-name = "buck3";
>> + regulator-min-microvolt = <700000>;
>> + regulator-max-microvolt = <1300000>;
>> + rohm,dvs-run-voltage = <900000>;
>> + regulator-always-on;
>> + };
>> +
>> + buck4_reg: BUCK4 {
>> + regulator-name = "buck4";
>> + regulator-min-microvolt = <700000>;
>> + regulator-max-microvolt = <1300000>;
>> + rohm,dvs-run-voltage = <1000000>;
>> + };
>> +
>> + buck5_reg: BUCK5 {
>> + regulator-name = "buck5";
>> + regulator-min-microvolt = <700000>;
>> + regulator-max-microvolt = <1350000>;
>> + regulator-always-on;
>> + };
>> +
>> + buck6_reg: BUCK6 {
>> + regulator-name = "buck6";
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + };
>> +
>> + buck7_reg: BUCK7 {
>> + regulator-name = "buck7";
>> + regulator-min-microvolt = <1605000>;
>> + regulator-max-microvolt = <1995000>;
>> + regulator-always-on;
>> + };
>> +
>> + buck8_reg: BUCK8 {
>> + regulator-name = "buck8";
>> + regulator-min-microvolt = <800000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-always-on;
>> + };
>> +
>> + ldo1_reg: LDO1 {
>> + regulator-name = "ldo1";
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3300000>;
>> + /* leave on for snvs power button */
>> + regulator-always-on;
>> + };
>> +
>> + ldo2_reg: LDO2 {
>> + regulator-name = "ldo2";
>> + regulator-min-microvolt = <900000>;
>> + regulator-max-microvolt = <900000>;
>> + /* leave on for snvs power button */
>> + regulator-always-on;
>> + };
>> +
>> + ldo3_reg: LDO3 {
>> + regulator-name = "ldo3";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + };
>> +
>> + ldo4_reg: LDO4 {
>> + regulator-name = "ldo4";
>> + regulator-min-microvolt = <900000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-always-on;
>> + };
>> +
>> + ldo5_reg: LDO5 {
>> + /* VDD_PHY_0V9 - MIPI and HDMI domains */
>> + regulator-name = "ldo5";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + };
>> +
>> + ldo6_reg: LDO6 {
>> + /* VDD_PHY_0V9 - MIPI, HDMI and USB domains */
>> + regulator-name = "ldo6";
>> + regulator-min-microvolt = <900000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-always-on;
>> + };
>> +
>> + ldo7_reg: LDO7 {
>> + /* VDD_PHY_3V3 - USB domain */
>> + regulator-name = "ldo7";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + };
>
> Out of curiosity, why did you marked all regulators as
> regulator-always-on? I thought the librem5 is a smartphone.
It is. But we just currently see an unstable system in case we allow
turning most of them off. We do for the VPU, and should (afaik already)
be able to do so for the GPU. After more work in the drivers the mipi
regulator(s) should be able to be turned off. So we'll look at more and
more of these over time.
>
>> + };
>> + };
>> +
>> + rtc@68 {
>> + compatible = "microcrystal,rv4162";
>> + reg = <0x68>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_rtc>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> +
>> +&i2c2 {
>> + clock-frequency = <387000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c2>;
>> + status = "okay";
>> +
>> + magnetometer@1e {
>> + compatible = "st,lsm9ds1-magn";
>> + reg = <0x1e>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_mag>;
>> + interrupt-parent = <&gpio3>;
>> + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
>> + vdd-supply = <®_vdd_sen>;
>> + vddio-supply = <®_vdd_1v8>;
>> + };
>> +
>> + regulator@3e {
>> + compatible = "tps65132";
>> + reg = <0x3e>;
>> + reg_lcd_avdd: outp {
>> + regulator-name = "lcd_avdd";
>> + vin-supply = <®_lcd_3v4>;
>> + };
>> +
>> + reg_lcd_avee: outn {
>> + regulator-name = "lcd_avee";
>> + vin-supply = <®_lcd_3v4>;
>> + };
> both phandles are not used.
>> + };
>> +
>> + flash@53 {
>> + compatible = "lm3560";
>> + reg = <0x53>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + flash@0 {
>> + reg = <0x0>;
>> + flash-timeout-us = <150000>;
>> + flash-max-microamp = <320000>;
>> + led-max-microamp = <60000>;
>> + label = "lm3560:flash";
>> + };
>> +
>> + torch@1 {
>> + reg = <0x1>;
>> + led-max-microamp = <10000>;
>> + label = "lm3560:torch";
>> + };
>> +
>> + };
>> +
>> + prox@60 {
>> + compatible = "vishay,vcnl4040";
>> + reg = <0x60>;
>> + pinctrl-0 = <&pinctrl_prox>;
>> + interrupt-parent = <&gpio3>;
>> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +
>> + accel-gyro@6a {
>> + compatible = "st,lsm9ds1-imu";
>> + reg = <0x6a>;
>> + vdd-supply = <®_vdd_sen>;
>> + vddio-supply = <®_vdd_1v8>;
>> + mount-matrix = "1", "0", "0",
>> + "0", "1", "0",
>> + "0", "0", "-1";
>> + };
>> +};
>> +
>> +&i2c3 {
>> + clock-frequency = <387000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c3>;
>> + status = "okay";
>> +
>> + codec: wm8962@1a {
>
> Please use generic names.
>
>> + compatible = "wlf,wm8962";
>> + reg = <0x1a>; // 0x4a is the test address
>> + clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
>> + assigned-clocks = <&clk IMX8MQ_CLK_SAI2>;
>> + assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
>> + assigned-clock-rates = <24576000>;
>> + #sound-dai-cells = <0>;
>> + mic-cfg = <0x200>;
>> + DCVDD-supply = <®_aud_1v8>;
>> + DBVDD-supply = <®_aud_1v8>;
>> + AVDD-supply = <®_aud_1v8>;
>> + CPVDD-supply = <®_aud_1v8>;
>> + MICVDD-supply = <®_aud_1v8>;
>> + PLLVDD-supply = <®_aud_1v8>;
>> + SPKVDD1-supply = <®_vsys_3v4>;
>> + SPKVDD2-supply = <®_vsys_3v4>;
>> + gpio-cfg = <
>> + 0x0000 /* n/c */
>> + 0x0001 /* gpio2, 1: default */
>> + 0x0013 /* gpio3, 2: dmicclk */
>> + 0x0000 /* n/c, 3: default */
>> + 0x8014 /* gpio5, 4: dmic_dat */
>> + 0x0000 /* gpio6, 5: default */
>> + >;
>> + status = "okay";
>
> status can be dropped
>
>> + };
>> +
>> + backlight@36 {
>> + compatible = "ti,lm36922";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_bl>;
>> + reg = <0x36>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + enable-gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
>> + vled-supply = <®_vsys_3v4>;
>> + ti,ovp-microvolt = <25000000>;
>> +
>> + led_backlight: led@0 {
>> + reg = <0>;
>> + label = "white:backlight_cluster";
>> + linux,default-trigger = "backlight";
>> + led-max-microamp = <20000>;
>> + };
>> + };
>> +
>> + touchscreen@38 {
>> + compatible = "edt,edt-ft5506";
>> + reg = <0x38>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
>
> You need to mux the irq gpio.
>
>> + irq-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
>
> irq-gpios is not supported by the driver. We only have a
> wake/reset-gpio.
>
>> + touchscreen-size-x = <720>;
>> + touchscreen-size-y = <1440>;
>> + };
>> +};
>> +
>> +&i2c4 {
>> + clock-frequency = <387000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c4>;
>> + status = "okay";
>> +
>> + bat: fuel-gauge@36 {
>> + compatible = "maxim,max17055";
>> + interrupt-parent = <&gpio3>;
>> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gauge>;
>> + reg = <0x36>;
>
> Please check that "reg" is always the 2nd property after the
> "compatible".
>
>> + maxim,over-heat-temp = <700>;
>> + maxim,over-volt = <4500>;
>> + maxim,rsns-microohm = <5000>;
>> + };
>> +
>> + charger@6a { /* bq25895 */
>> + compatible = "ti,bq25890";
>
> The compatible should be "ti,bq25895" if it is a bq25895. So we can drop
> the comment too.
>
>> + reg = <0x6a>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_charger_in>;
>> + interrupt-parent = <&gpio3>;
>> + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
>> + phys = <&usb3_phy0>;
>> + ti,battery-regulation-voltage = <4192000>; /* 4.192V */
>> + ti,charge-current = <1600000>; /* 1.6A */
>> + ti,termination-current = <66000>; /* 66mA */
>> + ti,precharge-current = <130000>; /* 130mA */
>> + ti,minimum-sys-voltage = <3700000>; /* 3.7V */
>> + ti,boost-voltage = <5000000>; /* 5V */
>> + ti,boost-max-current = <50000>; /* 50mA */
>> + ti,use-vinmin-threshold = <1>; /* enable VINDPM */
>> + ti,vinmin-threshold = <3900000>; /* 3.9V */
>
> I would only mention the units within a comment because comments like
> this begin to divergence after you fix something.
>
> Regards,
> Marco
>
Basically I try to follow all your suggestions that I haven't commented
here, too.
thank you very much for this in-depth review. That helps a lot and I try
to put together a second revision soon.
martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
From: David Lechner @ 2020-06-02 15:18 UTC (permalink / raw)
To: William Breathitt Gray, Jonathan Cameron
Cc: kamel.bouhara, gwendal, alexandre.torgue, linux-iio,
patrick.havelange, alexandre.belloni, linux-kernel,
mcoquelin.stm32, fabrice.gasnier, syednwaris, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200531171351.GA10597@shinobu>
On 5/31/20 12:14 PM, William Breathitt Gray wrote:
> Yielding the following /dev/counter0 memory layout:
>
> +------------+-----------------+------------+-------------------+
> | Byte 0 | Byte 1 - Byte 8 | Byte 9 | Byte 10 - Byte 17 |
> +------------+-----------------+------------+-------------------+
> | Boundary 0 | Count 0 | Boundary 1 | Count 1 |
> +------------+-----------------+------------+-------------------+
A potential pitfall with this sort of packing is that some platforms
do not support unaligned access, so data would have to be "unpacked"
before it could be used.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support
From: santosh.shilimkar @ 2020-06-02 15:18 UTC (permalink / raw)
To: Tomi Valkeinen, Jyri Sarha, dri-devel, ssantosh, linux-arm-kernel,
devicetree
Cc: mark.rutland, praneeth, robh+dt, laurent.pinchart, peter.ujfalusi
In-Reply-To: <973b69f2-bbe1-3c1b-615f-751bb8d5d83e@ti.com>
On 6/2/20 1:13 AM, Tomi Valkeinen wrote:
> Hi Santosh,
>
> On 14/02/2020 19:40, santosh.shilimkar@oracle.com wrote:
>> On 2/14/20 1:22 AM, Jyri Sarha wrote:
>>> Resend because the earlier recipient list was wrong.
>>>
>>> Now that drm/tidss is queued for mainline, lets add display support for
>>> k2g-evm. There is no hurry since tidss is out only in v5.7, but it
>>> should not harm to have the dts changes in place before that.
>>>
>>> Jyri Sarha (2):
>>> ARM: dts: keystone-k2g: Add DSS node
>>> ARM: dts: keystone-k2g-evm: add HDMI video support
>>>
>>> arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++
>>> arch/arm/boot/dts/keystone-k2g.dtsi | 22 ++++++
>>> 2 files changed, 123 insertions(+)
>>>
>> Ok. Will add this to the next queue.
>
> What happened with this one? It used to be in linux-next, but now I
> don't see it anymore.
>
Pull request [1] was sent during last merge window. Thought it was
picked up but doesn't seems to be. Have sent question to arm-soc
maintainers.
Regards,
Santosh
[1] https://www.spinics.net/lists/arm-kernel/msg791224.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: Keystone DTS updates for 5.7
From: santosh.shilimkar @ 2020-06-02 15:13 UTC (permalink / raw)
To: arm, linux-arm-kernel, arnd, olof; +Cc: linux-kernel, khilman
In-Reply-To: <1583603819-9651-1-git-send-email-santosh.shilimkar@oracle.com>
Hi Arnd, Olof,
On 3/7/20 9:56 AM, Santosh Shilimkar wrote:
> The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
>
> Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_5.7
>
> for you to fetch changes up to 7856488bd83b0182548a84d05c07326321ae6138:
>
> ARM: dts: keystone-k2g-evm: add HDMI video support (2020-03-07 09:47:24 -0800)
>
> ----------------------------------------------------------------
> ARM: Keystone DTS updates for 5.7
>
> Add display support for K2G EVM Board
>
> ----------------------------------------------------------------
> Jyri Sarha (2):
> ARM: dts: keystone-k2g: Add DSS node
> ARM: dts: keystone-k2g-evm: add HDMI video support
>
> arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/keystone-k2g.dtsi | 22 +++++++
> 2 files changed, 123 insertions(+)
>
Looks like this pull request wasn't picked. Can you please check
in case am missing something.
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: s5p-mfc: set V4L2_BUF_FLAG_LAST flag on final buffer
From: Nicolas Dufresne @ 2020-06-02 15:09 UTC (permalink / raw)
To: Andriy Gelman
Cc: Andrzej Hajda, Kamil Debski, linux-kernel, Jeongtae Park,
Kyungmin Park, Mauro Carvalho Chehab, linux-arm-kernel,
linux-media
In-Reply-To: <20200502194052.485-1-andriy.gelman@gmail.com>
Hi Andriy,
thanks for you patch.
Le samedi 02 mai 2020 à 15:40 -0400, Andriy Gelman a écrit :
> From: Andriy Gelman <andriy.gelman@gmail.com>
>
> As per V4L2 api, the final buffer should set V4L2_BUF_FLAG_LAST flag.
>
> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 5c2a23b953a4..b3d9b3a523fe 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -614,6 +614,7 @@ static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx)
> list_del(&mb_entry->list);
> ctx->dst_queue_cnt--;
> vb2_set_plane_payload(&mb_entry->b->vb2_buf, 0, 0);
> + mb_entry->b->flags |= V4L2_BUF_FLAG_LAST;
> vb2_buffer_done(&mb_entry->b->vb2_buf, VB2_BUF_STATE_DONE);
The empty buffer is only there for backward compatibility. As the spec
says, userspace should completely ignore this buffer. I bet it will
still have the effect to set last_buffer_dequeued = true in vb2,
unblocking poll() operations and allowing for the queue to unblock and
return EPIPE on further DQBUF.
Perhaps you should make sure the if both the src and dst queues are
empty/done by the time cmd_stop is called it will still work. Other
drivers seems to handle this, but this one does not seems to have a
special case for that, which may hang userspace in a different way.
What you should do to verify this patch is correct, and that your
userpace does not rely on legacy path is that it should always be able
to detect the end of the drain with a EPIPE on DQBUF. LAST_BUF is just
an early signalling, but may not occur if there was nothing left to
produce (except for MFC which maybe be crafting a buffer in all cases,
but that's going a roundtrip through the HW, which is not clear will
work if the dst queue was empty).
As shared on IRC, you have sent these patch to FFMPEG:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200429212942.28797-2-andriy.gelman@gmail.com/
This should have been clarified as supporting legacy drivers / older
kernel with Samsung driver. Seems like a fair patch. And you added:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200429212942.28797-1-andriy.gelman@gmail.com/
This one should maybe add the clarification that this is an
optimization to skip an extra poll/dqbuf dance, but that end of
draining will ultimately be catched by EPIPE on dqbuf for the described
cases. Remains valid enhancement to ffmpeg imho.
> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Maxime Ripard @ 2020-06-02 15:08 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Tim Gover, Dave Stevenson, linux-kernel, dri-devel,
Eric Anholt, bcm-kernel-feedback-list, Nicolas Saenz Julienne,
Phil Elwell, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20200529181833.GA2685451@bogus>
[-- Attachment #1.1: Type: text/plain, Size: 3676 bytes --]
Hi Rob,
On Fri, May 29, 2020 at 12:18:33PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> > The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> > bindings, especially since the registers have been shuffled around in more
> > register ranges.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 109 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > new file mode 100644
> > index 000000000000..6091fe3d315b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > @@ -0,0 +1,109 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Dual license...
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Eric Anholt <eric@anholt.net>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - brcm,bcm2711-hdmi0
> > + - brcm,bcm2711-hdmi1
>
> What's the difference between the 2 blocks?
The register layout and the lane mapping in the PHY change a bit.
> > +
> > + reg:
> > + items:
> > + - description: HDMI controller register range
> > + - description: DVP register range
> > + - description: HDMI PHY register range
> > + - description: Rate Manager register range
> > + - description: Packet RAM register range
> > + - description: Metadata RAM register range
> > + - description: CSC register range
> > + - description: CEC register range
> > + - description: HD register range
> > +
> > + reg-names:
> > + items:
> > + - const: hdmi
> > + - const: dvp
> > + - const: phy
> > + - const: rm
> > + - const: packet
> > + - const: metadata
> > + - const: csc
> > + - const: cec
> > + - const: hd
> > +
> > + clocks:
> > + description: The HDMI state machine clock
> > +
> > + clock-names:
> > + const: hdmi
> > +
> > + ddc:
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/phandle
> > + description: >
> > + Phandle of the I2C controller used for DDC EDID probing
>
> Goes in the connector.
>
> And isn't the standard name ddc-i2c-bus?
>
> > +
> > + hpd-gpios:
> > + description: >
> > + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> > + as an interrupt/status bit in the HDMI controller itself)
>
> Goes in the connector.
If this was an entirely new binding, I would agree, but this is not
really the case here.
We discussed it already for the v2, and this binding is essentially the
same one than the bcm2835 HDMI controller.
I initially sent a patch adding conditionnals for the clocks and regs
differences too, and you asked to split the binding into a separate file
to simplify it a bit.
Supporting both the old binding, and the new one based on the connector
is going to make the code significantly more complicated, and I'm not
really sure why we would here.
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
From: Dave Stevenson @ 2020-06-02 15:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, LKML, DRI Development, Eric Anholt,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20200602141228.7zbkob7bw3owajsq@gilmour>
Hi Maxime and Eric
On Tue, 2 Jun 2020 at 15:12, Maxime Ripard <maxime@cerno.tech> wrote:
>
> Hi Eric
>
> On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
> > On Wed, May 27, 2020 at 8:50 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > >
> > > The VIDEN bit in the pixelvalve currently being used to enable or disable
> > > the pixelvalve seems to not be enough in some situations, which whill end
> > > up with the pixelvalve stalling.
> > >
> > > In such a case, even re-enabling VIDEN doesn't bring it back and we need to
> > > clear the FIFO. This can only be done if the pixelvalve is disabled though.
> > >
> > > In order to overcome this, we can configure the pixelvalve during
> > > mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO
> > > there, and in atomic_disable disable the pixelvalve again.
> >
> > What displays has this been tested with? Getting this sequencing
> > right is so painful, and things like DSI are tricky to get to light
> > up.
>
> That FIFO is between the HVS and the HDMI PVs, so this was obviously
> tested against that. Dave also tested the DSI output IIRC, so we should
> be covered here.
DSI wasn't working on the first patch set that Maxime sent - I haven't
tested this one as yet but will do so.
DPI was working early on to both an Adafruit 800x480 DPI panel, and
via a VGA666 as VGA.
HDMI is obviously working.
VEC is being ignored now. The clock structure is more restricted than
earlier chips, so to get the required clocks for the VEC without using
fractional divides it compromises the clock that other parts of the
system can run at (IIRC including the ARM). That's why the VEC has to
be explicitly enabled for the firmware to enable it as the only
output. It's annoying, but that's just a restriction of the chip.
Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 006/105] dt-bindings: display: Convert VC4 bindings to schemas
From: Maxime Ripard @ 2020-06-02 15:00 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Tim Gover, Dave Stevenson, linux-kernel, dri-devel,
Eric Anholt, bcm-kernel-feedback-list, Nicolas Saenz Julienne,
Phil Elwell, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20200527191211.GA2559189@bogus>
[-- Attachment #1.1: Type: text/plain, Size: 4929 bytes --]
Hi Rob,
On Wed, May 27, 2020 at 01:12:11PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 05:47:36PM +0200, Maxime Ripard wrote:
> > The BCM283x SoCs have a display pipeline composed of several controllers
> > with device tree bindings that are supported by Linux.
> >
> > Now that we have the DT validation in place, let's split into separate
> > files and convert the device tree bindings for those controllers to
> > schemas.
> >
> > This is just a 1:1 conversion though, and some bindings were incomplete so
> > it results in example validation warnings that are going to be addressed in
> > the following patches.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 174 +------------------------------------------------------------------------
> > Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 66 +++++++++++++++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml | 73 ++++++++++++++++++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml | 75 +++++++++++++++++++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 37 +++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 40 +++++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml | 37 +++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml | 42 +++++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 34 ++++++++++++++-
> > Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 44 ++++++++++++++++++-
> > MAINTAINERS | 2 +-
> > 11 files changed, 449 insertions(+), 175 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml
>
>
> > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> > new file mode 100644
> > index 000000000000..3887675f844e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> > @@ -0,0 +1,73 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/brcm,bcm2835-dsi0.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Broadcom VC4 (VideoCore4) DSI Controller
> > +
> > +maintainers:
> > + - Eric Anholt <eric@anholt.net>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - brcm,bcm2835-dsi0
> > + - brcm,bcm2835-dsi1
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: The DSI PLL clock feeding the DSI analog PHY
> > + - description: The DSI ESC clock
> > + - description: The DSI pixel clock
> > +
> > + clock-output-names: true
> > + # FIXME: The meta-schemas don't seem to allow it for now
> > + # items:
> > + # - description: The DSI byte clock for the PHY
> > + # - description: The DSI DDR2 clock
> > + # - description: The DSI DDR clock
>
> Doesn't pattern work for you?
>
> pattern: '^dsi[0-1]_byte$'
That's not really what I was trying to achieve. I don't think
clock-output-names should hardcode the values it expect, since the whole
point is to let the "user" (ie the DT) control the clock names. If these
were to be fixed, it wouldn't even be here in the first place.
I just wanted to have a description of the clocks to provide a name for,
but it looks like clock-output-names can't have an items below. I looked
at why, couldn't really find a reason, and forgot to tell you about it,
sorry
> Either way,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/4] Introduce TEE based Trusted Keys support
From: James Bottomley @ 2020-06-02 14:43 UTC (permalink / raw)
To: Sumit Garg, jarkko.sakkinen, zohar
Cc: tee-dev, daniel.thompson, op-tee, corbet, janne.karhunen,
linux-doc, jmorris, linux-kernel, dhowells, linux-security-module,
keyrings, Markus.Wamser, casey, linux-integrity, jens.wiklander,
linux-arm-kernel, serge
In-Reply-To: <1591107505-6030-1-git-send-email-sumit.garg@linaro.org>
On Tue, 2020-06-02 at 19:48 +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the
> functionality to seal and unseal trusted keys using hardware unique
> key. Also, this is an alternative in case platform doesn't possess a
> TPM device.
So here's a meta problem: in the case when the platform possesses both
TEE and TPM what should it do? Things like this:
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -25,6 +25,8 @@
>
> #if defined(CONFIG_TRUSTED_TPM)
> static struct trusted_key_ops *trusted_key_ops =
> &tpm_trusted_key_ops;
> +#elif defined(CONFIG_TRUSTED_TEE)
> +static struct trusted_key_ops *trusted_key_ops =
> &tee_trusted_key_ops;
> #else
Say it's either/or at a Kconfig level: so if you select both TEE and
TPM based trusted keys at compile time, we intall the TPM ops and
ignore the TEE ops, is that right? Surely this should be runtime
selectable based on what the platform has ... perhaps it should even be
selectable per key?
Once it is runtime selectable, what should be selected in the both
case? Or should we allow the user to decide, if so, how?
when you pipe a trusted key, I think the subtype (TEE or TPM) should be
part of the piped information, so it loads again seamlessly. This
would actually be fixed by something like the ASN.1 scheme I'm trying
to upstream, at least for TPM keys, but do TEE keys have a recognized
ASN.1 format?
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-02 14:41 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, Chen Zhou, Catalin Marinas,
Bhupesh Sharma, RuiRui Yang, kexec mailing list,
Linux Kernel Mailing List, Rob Herring, Simon Horman, James Morse,
guohanjun, Thomas Gleixner, Prabhakar Kushwaha, Will Deacon,
Ingo Molnar, linux-arm-kernel
In-Reply-To: <CAJ2QiJJE-jeRL1HPUZCwi1LtV9CBMmYrsOaS6vX1R1sJ6Z1t8g@mail.gmail.com>
> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <prabhakar.pkin@gmail.com> wrote:
>
> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <john.p.donnelly@oracle.com> wrote:
>>
>> Hi . See below !
>>
>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>>
>>> Hi John,
>>>
>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>>>> Hi Chen,
>>>>>
>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>>>> This patch series enable reserving crashkernel above 4G in arm64.
>>>>>>
>>>>>> There are following issues in arm64 kdump:
>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>>>>> when there is no enough low memory.
>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
>>>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
>>>>>> will boot failure because there is no low memory available for allocation.
>>>>>>
>>>>>> To solve these issues, introduce crashkernel=X,low to reserve specified
>>>>>> size low memory.
>>>>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
>>>>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
>>>>>> size low memory for crash kdump kernel devices firstly and then reserve
>>>>>> memory above 4G.
>>>>>>
>>>>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
>>>>>> is specified simultaneously, kernel should reserve specified size low memory
>>>>>> for crash dump kernel devices. So there may be two crash kernel regions, one
>>>>>> is below 4G, the other is above 4G.
>>>>>> In order to distinct from the high region and make no effect to the use of
>>>>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
>>>>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
>>>>>>
>>>>>> Besides, we need to modify kexec-tools:
>>>>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
>>>>>>
>>>>>> The previous changes and discussions can be retrieved from:
>>>>>>
>>>>>> Changes since [v7]
>>>>>> - Move x86 CRASH_ALIGN to 2M
>>>>>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
>>>>>> - Update Documentation/devicetree/bindings/chosen.txt
>>>>>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
>>>>>> - Add Tested-by from Jhon and pk
>>>>>>
>>>>>> Changes since [v6]
>>>>>> - Fix build errors reported by kbuild test robot.
>>>>>>
>>>>>> Changes since [v5]
>>>>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
>>>>>> - Delete crashkernel=X,high.
>>>>>> - Modify crashkernel=X,low.
>>>>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
>>>>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
>>>>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
>>>>>> pass to crash dump kernel by DT property "linux,low-memory-range".
>>>>>> - Update Documentation/admin-guide/kdump/kdump.rst.
>>>>>>
>>>>>> Changes since [v4]
>>>>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
>>>>>>
>>>>>> Changes since [v3]
>>>>>> - Add memblock_cap_memory_ranges back for multiple ranges.
>>>>>> - Fix some compiling warnings.
>>>>>>
>>>>>> Changes since [v2]
>>>>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
>>>>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
>>>>>> patch.
>>>>>>
>>>>>> Changes since [v1]:
>>>>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
>>>>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
>>>>>> in fdt_enforce_memory_region().
>>>>>> There are at most two crash kernel regions, for two crash kernel regions
>>>>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
>>>>>> and then remove the memory range in the middle.
>>>>>>
>>>>>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
>>>>>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
>>>>>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
>>>>>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
>>>>>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
>>>>>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
>>>>>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
>>>>>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
>>>>>>
>>>>>> Chen Zhou (5):
>>>>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
>>>>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
>>>>>> arm64: kdump: add memory for devices by DT property, low-memory-range
>>>>>> kdump: update Documentation about crashkernel on arm64
>>>>>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
>>>>>>
>>>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
>>>>> with bootargs as [2] of primary kernel.
>>>>> This error observed on ThunderX2 ARM64 platform.
>>>>>
>>>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
>>>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>>>> Also **without** this patch-set
>>>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
>>>>>
>>>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
>>>>> More details discussed earlier in
>>>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
>>>>> solution
>>>>>
>>>>> This patch-set is expected to solve similar kind of issue.
>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
>>>>> observation should be considered/fixed. .
>>>>>
>>>>> --pk
>>>>>
>>>>> [1]
>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>> [ 30.367696] NET: Registered protocol family 16
>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>> [ 30.369984] Call trace:
>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>>>> [ 30.369991] show_stack+0x20/0x30
>>>>> [ 30.369997] dump_stack+0xc0/0x10c
>>>>> [ 30.370001] warn_alloc+0x10c/0x178
>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>>>> [ 30.370020] do_one_initcall+0x54/0x228
>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>>>> [ 30.370031] kernel_init+0x1c/0x110
>>>>> [ 30.370034] ret_from_fork+0x10/0x18
>>>>> [ 30.370036] Mem-Info:
>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>>>> unstable:0kB all_unreclaimable? no
>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
>>>>> unstable:0kB all_unreclaimable? no
>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
>>>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>>>> hugepages_surp=0 hugepages_size=1048576kB
>>>>> [ 30.370130] 0 total pagecache pages
>>>>> [ 30.370132] 0 pages in swap cache
>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>>>> [ 30.370135] Free swap = 0kB
>>>>> [ 30.370136] Total swap = 0kB
>>>>> [ 30.370137] 2164609 pages RAM
>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>>>> [ 30.370140] 612331 pages reserved
>>>>> [ 30.370141] 0 pages hwpoisoned
>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
>>>>> coherent allocation
>>>>
>>>>
>>>> During my testing I saw the same error and Chen's solution corrected it .
>>>
>>> Which combination you are using on your side? I am using Prabhakar's
>>> suggested environment and can reproduce the issue
>>> with or without Chen's crashkernel support above 4G patchset.
>>>
>>> I am also using a ThunderX2 platform with latest makedumpfile code and
>>> kexec-tools (with the suggested patch
>>> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
>>>
>>> Thanks,
>>> Bhupesh
>>
>>
>> I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
>>
>>
>>
>> For this failure ,
>>
>>>>> DMA: failed to allocate 256 KiB pool for atomic
>>>>> coherent allocation
>>
>>
>> Is due to :
>>
>>
>> 3618082c
>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
>>
>> With the introduction of ZONE_DMA to support the Raspberry DMA
>> region below 1G, the crashkernel is placed in the upper 4G
>> ZONE_DMA_32 region. Since the crashkernel does not have access
>> to the ZONE_DMA region, it prints out call trace during bootup.
>>
>> It is due to having this CONFIG item ON :
>>
>>
>> CONFIG_ZONE_DMA=y
>>
>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
>> use the device tree to specify memory below 1G.
>>
>>
>
> Disabling ZONE_DMA is temporary solution. We may need proper solution
Perhaps the Raspberry platform configuration dependencies need separated from “server class” Arm equipment ? Or auto-configured on boot ? Consult an expert ;-)
>
>> I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
>
> I will also like this patch to be added in Linux as early as possible.
>
> Issue mentioned by me happens with or without this patch.
>
> This patch-set can consider fixing because it uses low memory for DMA
> & swiotlb only.
> We can consider restricting crashkernel within the required range like below
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 7f9e5a6dc48c..bd67b90d35bd 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
> return 0;
> }
>
> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> + low_base = memblock_find_in_range(0,0xc0000000, low_size, CRASH_ALIGN);
> if (!low_base) {
> pr_err("Cannot reserve %ldMB crashkernel low memory,
> please try smaller size.\n",
> (unsigned long)(low_size >> 20));
>
>
I suspect 0xc0000000 would need to be a CONFIG item and not hard-coded.
> Similar change can be considered for scenario "without" this patch.
> But it will decrease memory availability for crashkernel.
> Hence increase the failure probability of crashkernel reservation.
>
> --pk
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 9/9] mtd: rawnand: Move the user input parsing bits to the ECC framework
From: Miquel Raynal @ 2020-06-02 14:31 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, Boris Brezillon, Thomas Petazzoni, Miquel Raynal,
Mason Yang, linux-arm-kernel
In-Reply-To: <20200602143124.29553-1-miquel.raynal@bootlin.com>
Many helpers are generic to all NAND chips, they should not be
restricted to be only used by raw NAND controller drivers. They might
later be used by generic ECC engines and SPI-NAND devices as well so
move them into a more generic place.
To avoid moving all the raw NAND core "history" into the generic NAND
layer, we already moved certain bits into legacy helpers in the raw
NAND core to ensure backward compatibility.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc.c | 138 +++++++++++++++++
drivers/mtd/nand/raw/atmel/nand-controller.c | 3 +-
drivers/mtd/nand/raw/denali.c | 3 +
drivers/mtd/nand/raw/nand_base.c | 150 ++-----------------
drivers/mtd/nand/raw/sunxi_nand.c | 3 +-
drivers/mtd/nand/raw/tegra_nand.c | 5 +-
include/linux/mtd/nand.h | 7 +
include/linux/mtd/rawnand.h | 1 -
8 files changed, 166 insertions(+), 144 deletions(-)
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index ad08a047dfc5..1ac7aaa6c6c2 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -328,6 +328,144 @@ const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
}
EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
+static enum nand_ecc_engine_type
+of_get_nand_ecc_engine_type(struct device_node *np)
+{
+ return NAND_ECC_ENGINE_TYPE_INVALID;
+}
+
+static const char * const nand_ecc_placement[] = {
+ [NAND_ECC_PLACEMENT_OOB] = "oob",
+ [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved",
+};
+
+enum nand_ecc_placement of_get_nand_ecc_placement(struct device_node *np)
+{
+ enum nand_ecc_placement placement;
+ const char *pm;
+ int err;
+
+ err = of_property_read_string(np, "nand-ecc-placement", &pm);
+ if (!err) {
+ for (placement = NAND_ECC_PLACEMENT_OOB;
+ placement < ARRAY_SIZE(nand_ecc_placement); placement++) {
+ if (!strcasecmp(pm, nand_ecc_placement[placement]))
+ return placement;
+ }
+ }
+
+ return NAND_ECC_PLACEMENT_UNKNOWN;
+}
+
+static const char * const nand_ecc_algos[] = {
+ [NAND_ECC_ALGO_HAMMING] = "hamming",
+ [NAND_ECC_ALGO_BCH] = "bch",
+ [NAND_ECC_ALGO_RS] = "rs",
+};
+
+static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
+{
+ enum nand_ecc_algo ecc_algo;
+ const char *pm;
+ int err;
+
+ err = of_property_read_string(np, "nand-ecc-algo", &pm);
+ if (!err) {
+ for (ecc_algo = NAND_ECC_ALGO_HAMMING;
+ ecc_algo < ARRAY_SIZE(nand_ecc_algos);
+ ecc_algo++) {
+ if (!strcasecmp(pm, nand_ecc_algos[ecc_algo]))
+ return ecc_algo;
+ }
+ }
+
+ return NAND_ECC_ALGO_UNKNOWN;
+}
+
+static int of_get_nand_ecc_step_size(struct device_node *np)
+{
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32(np, "nand-ecc-step-size", &val);
+ return ret ? ret : val;
+}
+
+static int of_get_nand_ecc_strength(struct device_node *np)
+{
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32(np, "nand-ecc-strength", &val);
+ return ret ? ret : val;
+}
+
+static inline bool of_get_nand_ecc_maximize(struct device_node *np)
+{
+ return of_property_read_bool(np, "nand-ecc-maximize");
+}
+
+void nand_ecc_read_user_conf(struct nand_device *nand)
+{
+ struct device_node *dn = nanddev_get_of_node(nand);
+ int strength, size;
+
+ nand->ecc.user_conf.engine_type = of_get_nand_ecc_engine_type(dn);
+ nand->ecc.user_conf.algo = of_get_nand_ecc_algo(dn);
+ nand->ecc.user_conf.placement = of_get_nand_ecc_placement(dn);
+
+ strength = of_get_nand_ecc_strength(dn);
+ if (strength >= 0)
+ nand->ecc.user_conf.strength = strength;
+
+ size = of_get_nand_ecc_step_size(dn);
+ if (size >= 0)
+ nand->ecc.user_conf.step_size = size;
+
+ if (of_get_nand_ecc_maximize(dn))
+ nand->ecc.user_conf.flags |= NAND_ECC_MAXIMIZE;
+}
+EXPORT_SYMBOL(nand_ecc_read_user_conf);
+
+/**
+ * nand_ecc_correction_is_enough - Check if the chip configuration meets the
+ * datasheet requirements.
+ *
+ * @nand: Device to check
+ *
+ * If our configuration corrects A bits per B bytes and the minimum
+ * required correction level is X bits per Y bytes, then we must ensure
+ * both of the following are true:
+ *
+ * (1) A / B >= X / Y
+ * (2) A >= X
+ *
+ * Requirement (1) ensures we can correct for the required bitflip density.
+ * Requirement (2) ensures we can correct even when all bitflips are clumped
+ * in the same sector.
+ */
+bool nand_ecc_correction_is_enough(struct nand_device *nand)
+{
+ const struct nand_ecc_props *reqs = nanddev_get_ecc_requirements(nand);
+ const struct nand_ecc_props *conf = nanddev_get_ecc_conf(nand);
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int corr, ds_corr;
+
+ if (conf->step_size == 0 || reqs->step_size == 0)
+ /* Not enough information */
+ return true;
+
+ /*
+ * We get the number of corrected bits per page to compare
+ * the correction density.
+ */
+ corr = (mtd->writesize * conf->strength) / conf->step_size;
+ ds_corr = (mtd->writesize * reqs->strength) / reqs->step_size;
+
+ return corr >= ds_corr && conf->strength >= reqs->strength;
+}
+EXPORT_SYMBOL(nand_ecc_correction_is_enough);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index 08df7f23b859..39d8fe15b8ab 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1046,6 +1046,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
const struct nand_ecc_props *requirements =
nanddev_get_ecc_requirements(&chip->base);
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct atmel_nand *nand = to_atmel_nand(chip);
struct atmel_nand_controller *nc;
struct atmel_pmecc_user_req req;
@@ -1070,7 +1071,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
chip->ecc.size = val;
}
- if (chip->ecc.options & NAND_ECC_MAXIMIZE)
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE)
req.ecc.strength = ATMEL_PMECC_MAXIMIZE_ECC_STRENGTH;
else if (chip->ecc.strength)
req.ecc.strength = chip->ecc.strength;
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index a6a6464974ec..51bc014ebc0a 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1181,6 +1181,7 @@ int denali_chip_init(struct denali_controller *denali,
{
struct nand_chip *chip = &dchip->chip;
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct denali_chip *dchip2;
int i, j, ret;
@@ -1248,6 +1249,8 @@ int denali_chip_init(struct denali_controller *denali,
mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
+ nanddev->ecc.user_conf.flags |= NAND_ECC_MAXIMIZE;
+
ret = nand_scan(chip, dchip->nsels);
if (ret)
return ret;
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index afc3506468ba..036e88cb52a1 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4854,17 +4854,6 @@ static int nand_detect(struct nand_chip *chip, struct nand_flash_dev *type)
return ret;
}
-static const char * const nand_ecc_placement[] = {
- [NAND_ECC_PLACEMENT_OOB] = "oob",
- [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved",
-};
-
-static enum nand_ecc_engine_type
-of_get_nand_ecc_engine_type(struct device_node *np)
-{
- return NAND_ECC_ENGINE_TYPE_INVALID;
-}
-
static enum nand_ecc_engine_type
of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
{
@@ -4916,24 +4905,6 @@ of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
return NAND_ECC_ENGINE_TYPE_INVALID;
}
-enum nand_ecc_placement of_get_nand_ecc_placement(struct device_node *np)
-{
- enum nand_ecc_placement placement;
- const char *pm;
- int err;
-
- err = of_property_read_string(np, "nand-ecc-placement", &pm);
- if (!err) {
- for (placement = NAND_ECC_PLACEMENT_OOB;
- placement < ARRAY_SIZE(nand_ecc_placement); placement++) {
- if (!strcasecmp(pm, nand_ecc_placement[placement]))
- return placement;
- }
- }
-
- return NAND_ECC_PLACEMENT_UNKNOWN;
-}
-
enum nand_ecc_placement
of_get_rawnand_ecc_placement_legacy(struct device_node *np)
{
@@ -4949,31 +4920,6 @@ of_get_rawnand_ecc_placement_legacy(struct device_node *np)
return NAND_ECC_PLACEMENT_UNKNOWN;
}
-static const char * const nand_ecc_algos[] = {
- [NAND_ECC_ALGO_HAMMING] = "hamming",
- [NAND_ECC_ALGO_BCH] = "bch",
- [NAND_ECC_ALGO_RS] = "rs",
-};
-
-static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
-{
- enum nand_ecc_algo ecc_algo;
- const char *pm;
- int err;
-
- err = of_property_read_string(np, "nand-ecc-algo", &pm);
- if (!err) {
- for (ecc_algo = NAND_ECC_ALGO_HAMMING;
- ecc_algo < ARRAY_SIZE(nand_ecc_algos);
- ecc_algo++) {
- if (!strcasecmp(pm, nand_ecc_algos[ecc_algo]))
- return ecc_algo;
- }
- }
-
- return NAND_ECC_ALGO_UNKNOWN;
-}
-
static enum nand_ecc_algo of_get_rawnand_ecc_algo_legacy(struct device_node *np)
{
const char *pm;
@@ -4990,48 +4936,10 @@ static enum nand_ecc_algo of_get_rawnand_ecc_algo_legacy(struct device_node *np)
return NAND_ECC_ALGO_UNKNOWN;
}
-static int of_get_nand_ecc_step_size(struct device_node *np)
-{
- int ret;
- u32 val;
-
- ret = of_property_read_u32(np, "nand-ecc-step-size", &val);
- return ret ? ret : val;
-}
-
-static int of_get_nand_ecc_strength(struct device_node *np)
-{
- int ret;
- u32 val;
-
- ret = of_property_read_u32(np, "nand-ecc-strength", &val);
- return ret ? ret : val;
-}
-
-static void nand_ecc_read_user_conf(struct nand_chip *chip)
-{
- struct device_node *dn = nand_get_flash_node(chip);
- struct nand_device *nand = &chip->base;
- int strength, size;
-
- nand->ecc.user_conf.engine_type = of_get_nand_ecc_engine_type(dn);
- nand->ecc.user_conf.algo = of_get_nand_ecc_algo(dn);
- nand->ecc.user_conf.placement = of_get_nand_ecc_placement(dn);
-
- strength = of_get_nand_ecc_strength(dn);
- if (strength >= 0)
- nand->ecc.user_conf.strength = strength;
-
- size = of_get_nand_ecc_step_size(dn);
- if (size >= 0)
- nand->ecc.user_conf.step_size = size;
-}
-
static void rawnand_ecc_read_legacy_user_conf(struct nand_chip *chip)
{
struct device_node *dn = nand_get_flash_node(chip);
- struct nand_device *nand = &chip->base;
- struct nand_ecc_props *user_conf = &nand->ecc.user_conf;
+ struct nand_ecc_props *user_conf = &chip->base.ecc.user_conf;
if (user_conf->engine_type != NAND_ECC_ENGINE_TYPE_INVALID)
user_conf->engine_type = of_get_rawnand_ecc_engine_type_legacy(dn);
@@ -5081,10 +4989,7 @@ static int rawnand_dt_init(struct nand_chip *chip)
if (of_get_nand_on_flash_bbt(dn))
chip->bbt_options |= NAND_BBT_USE_FLASH;
- if (of_property_read_bool(dn, "nand-ecc-maximize"))
- chip->ecc.options |= NAND_ECC_MAXIMIZE;
-
- nand_ecc_read_user_conf(chip);
+ nand_ecc_read_user_conf(nand);
rawnand_ecc_read_legacy_user_conf(chip);
/*
@@ -5214,6 +5119,7 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
static int nand_set_ecc_soft_ops(struct nand_chip *chip)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct nand_ecc_ctrl *ecc = &chip->ecc;
if (WARN_ON(ecc->engine_type != NAND_ECC_ENGINE_TYPE_SOFT))
@@ -5289,7 +5195,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
* used.
*/
if (mtd->ooblayout == nand_get_large_page_ooblayout() &&
- ecc->options & NAND_ECC_MAXIMIZE) {
+ nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE) {
int steps, bytes;
/* Always prefer 1k blocks over 512bytes ones */
@@ -5529,11 +5435,12 @@ nand_maximize_ecc(struct nand_chip *chip,
* @caps: ECC engine caps info structure
* @oobavail: OOB size that the ECC engine can use
*
- * Choose the ECC configuration according to following logic
+ * Choose the ECC configuration according to following logic.
*
* 1. If both ECC step size and ECC strength are already set (usually by DT)
* then check if it is supported by this controller.
- * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
+ * 2. If the user provided the nand-ecc-maximize property, then select maximum
+ * ECC strength.
* 3. Otherwise, try to match the ECC step size and ECC strength closest
* to the chip's requirement. If available OOB size can't fit the chip
* requirement then fallback to the maximum ECC step size and ECC strength.
@@ -5544,6 +5451,7 @@ int nand_ecc_choose_conf(struct nand_chip *chip,
const struct nand_ecc_caps *caps, int oobavail)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
if (WARN_ON(oobavail < 0 || oobavail > mtd->oobsize))
return -EINVAL;
@@ -5551,7 +5459,7 @@ int nand_ecc_choose_conf(struct nand_chip *chip,
if (chip->ecc.size && chip->ecc.strength)
return nand_check_ecc_caps(chip, caps, oobavail);
- if (chip->ecc.options & NAND_ECC_MAXIMIZE)
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE)
return nand_maximize_ecc(chip, caps, oobavail);
if (!nand_match_ecc_req(chip, caps, oobavail))
@@ -5561,43 +5469,6 @@ int nand_ecc_choose_conf(struct nand_chip *chip,
}
EXPORT_SYMBOL_GPL(nand_ecc_choose_conf);
-/*
- * Check if the chip configuration meet the datasheet requirements.
-
- * If our configuration corrects A bits per B bytes and the minimum
- * required correction level is X bits per Y bytes, then we must ensure
- * both of the following are true:
- *
- * (1) A / B >= X / Y
- * (2) A >= X
- *
- * Requirement (1) ensures we can correct for the required bitflip density.
- * Requirement (2) ensures we can correct even when all bitflips are clumped
- * in the same sector.
- */
-static bool nand_ecc_strength_good(struct nand_chip *chip)
-{
- struct mtd_info *mtd = nand_to_mtd(chip);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
- const struct nand_ecc_props *requirements =
- nanddev_get_ecc_requirements(&chip->base);
- int corr, ds_corr;
-
- if (ecc->size == 0 || requirements->step_size == 0)
- /* Not enough information */
- return true;
-
- /*
- * We get the number of corrected bits per page to compare
- * the correction density.
- */
- corr = (mtd->writesize * ecc->strength) / ecc->size;
- ds_corr = (mtd->writesize * requirements->strength) /
- requirements->step_size;
-
- return corr >= ds_corr && ecc->strength >= requirements->strength;
-}
-
static int rawnand_erase(struct nand_device *nand, const struct nand_pos *pos)
{
struct nand_chip *chip = container_of(nand, struct nand_chip,
@@ -5653,6 +5524,7 @@ static const struct nand_ops rawnand_ops = {
static int nand_scan_tail(struct nand_chip *chip)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct nand_ecc_ctrl *ecc = &chip->ecc;
int ret, i;
@@ -5880,7 +5752,7 @@ static int nand_scan_tail(struct nand_chip *chip)
mtd->oobavail = ret;
/* ECC sanity check: warn if it's too weak */
- if (!nand_ecc_strength_good(chip))
+ if (!nand_ecc_correction_is_enough(nanddev))
pr_warn("WARNING: %s: the ECC used on your system (%db/%dB) is too weak compared to the one required by the NAND chip (%db/%dB)\n",
mtd->name,
nanddev_get_ecc_conf(&chip->base)->strength,
diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
index 490ba485e939..f863fabb8610 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -1609,12 +1609,13 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
struct mtd_info *mtd = nand_to_mtd(nand);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct sunxi_nand_hw_ecc *data;
int nsectors;
int ret;
int i;
- if (ecc->options & NAND_ECC_MAXIMIZE) {
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE) {
int bytes;
ecc->size = 1024;
diff --git a/drivers/mtd/nand/raw/tegra_nand.c b/drivers/mtd/nand/raw/tegra_nand.c
index fecdb7e8f9e8..1267e7529ca2 100644
--- a/drivers/mtd/nand/raw/tegra_nand.c
+++ b/drivers/mtd/nand/raw/tegra_nand.c
@@ -840,9 +840,10 @@ static int tegra_nand_get_strength(struct nand_chip *chip, const int *strength,
int strength_len, int bits_per_step,
int oobsize)
{
+ struct nand_device *base = mtd_to_nanddev(nand_to_mtd(chip));
const struct nand_ecc_props *requirements =
- nanddev_get_ecc_requirements(&chip->base);
- bool maximize = chip->ecc.options & NAND_ECC_MAXIMIZE;
+ nanddev_get_ecc_requirements(base);
+ bool maximize = base->ecc.user_conf.flags & NAND_ECC_MAXIMIZE;
int i;
/*
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 817969a8a230..343bb9bcd56c 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -182,6 +182,7 @@ enum nand_ecc_algo {
* @algo: ECC algorithm (if relevant)
* @strength: ECC strength
* @step_size: Number of bytes per step
+ * @flags: Misc properties
*/
struct nand_ecc_props {
enum nand_ecc_engine_type engine_type;
@@ -189,10 +190,14 @@ struct nand_ecc_props {
enum nand_ecc_algo algo;
unsigned int strength;
unsigned int step_size;
+ unsigned int flags;
};
#define NAND_ECCREQ(str, stp) { .strength = (str), .step_size = (stp) }
+/* NAND ECC misc flags */
+#define NAND_ECC_MAXIMIZE BIT(0)
+
/**
* struct nand_bbt - bad block table object
* @cache: in memory BBT cache
@@ -264,12 +269,14 @@ struct nand_ecc_engine {
struct nand_ecc_engine_ops *ops;
};
+void nand_ecc_read_user_conf(struct nand_device *nand);
int nand_ecc_init_ctx(struct nand_device *nand);
void nand_ecc_cleanup_ctx(struct nand_device *nand);
int nand_ecc_prepare_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
int nand_ecc_finish_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
+bool nand_ecc_correction_is_enough(struct nand_device *nand);
/**
* struct nand_ecc - Information relative to the ECC
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 66f69a1d27a5..9d69fa6608ae 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -98,7 +98,6 @@ struct nand_chip;
* pages and you want to rely on the default implementation.
*/
#define NAND_ECC_GENERIC_ERASED_CHECK BIT(0)
-#define NAND_ECC_MAXIMIZE BIT(1)
/*
* Option constants for bizarre disfunctionality and real
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 8/9] mtd: rawnand: Move generic OOB layouts to the ECC framework
From: Miquel Raynal @ 2020-06-02 14:31 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, Boris Brezillon, Thomas Petazzoni, Miquel Raynal,
Mason Yang, linux-arm-kernel
In-Reply-To: <20200602143124.29553-1-miquel.raynal@bootlin.com>
These layouts can be used by any driver, move them to the ECC core.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc.c | 176 ++++++++++++++++++++++++++++++
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/nand_base.c | 177 +------------------------------
include/linux/mtd/nand.h | 4 +
include/linux/mtd/rawnand.h | 5 +-
5 files changed, 183 insertions(+), 180 deletions(-)
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index f7300ba37167..ad08a047dfc5 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -152,6 +152,182 @@ int nand_ecc_finish_io_req(struct nand_device *nand,
}
EXPORT_SYMBOL(nand_ecc_finish_io_req);
+/* Define default oob placement schemes for large and small page devices */
+static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section > 1)
+ return -ERANGE;
+
+ if (!section) {
+ oobregion->offset = 0;
+ if (mtd->oobsize == 16)
+ oobregion->length = 4;
+ else
+ oobregion->length = 3;
+ } else {
+ if (mtd->oobsize == 8)
+ return -ERANGE;
+
+ oobregion->offset = 6;
+ oobregion->length = total_ecc_bytes - 4;
+ }
+
+ return 0;
+}
+
+static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ if (section > 1)
+ return -ERANGE;
+
+ if (mtd->oobsize == 16) {
+ if (section)
+ return -ERANGE;
+
+ oobregion->length = 8;
+ oobregion->offset = 8;
+ } else {
+ oobregion->length = 2;
+ if (!section)
+ oobregion->offset = 3;
+ else
+ oobregion->offset = 6;
+ }
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
+ .ecc = nand_ooblayout_ecc_sp,
+ .free = nand_ooblayout_free_sp,
+};
+
+const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void)
+{
+ return &nand_ooblayout_sp_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_small_page_ooblayout);
+
+static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section || !total_ecc_bytes)
+ return -ERANGE;
+
+ oobregion->length = total_ecc_bytes;
+ oobregion->offset = mtd->oobsize - oobregion->length;
+
+ return 0;
+}
+
+static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section)
+ return -ERANGE;
+
+ oobregion->length = mtd->oobsize - total_ecc_bytes - 2;
+ oobregion->offset = 2;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
+ .ecc = nand_ooblayout_ecc_lp,
+ .free = nand_ooblayout_free_lp,
+};
+
+const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void)
+{
+ return &nand_ooblayout_lp_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_large_page_ooblayout);
+
+/*
+ * Support the old "large page" layout used for 1-bit Hamming ECC where ECC
+ * are placed at a fixed offset.
+ */
+static int nand_ooblayout_ecc_lp_hamming(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section)
+ return -ERANGE;
+
+ switch (mtd->oobsize) {
+ case 64:
+ oobregion->offset = 40;
+ break;
+ case 128:
+ oobregion->offset = 80;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ oobregion->length = total_ecc_bytes;
+ if (oobregion->offset + oobregion->length > mtd->oobsize)
+ return -ERANGE;
+
+ return 0;
+}
+
+static int nand_ooblayout_free_lp_hamming(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+ int ecc_offset = 0;
+
+ if (section < 0 || section > 1)
+ return -ERANGE;
+
+ switch (mtd->oobsize) {
+ case 64:
+ ecc_offset = 40;
+ break;
+ case 128:
+ ecc_offset = 80;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (section == 0) {
+ oobregion->offset = 2;
+ oobregion->length = ecc_offset - 2;
+ } else {
+ oobregion->offset = ecc_offset + total_ecc_bytes;
+ oobregion->length = mtd->oobsize - oobregion->offset;
+ }
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
+ .ecc = nand_ooblayout_ecc_lp_hamming,
+ .free = nand_ooblayout_free_lp_hamming,
+};
+
+const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
+{
+ return &nand_ooblayout_lp_hamming_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 85280e327bfe..6ab3184ca8eb 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -13,6 +13,7 @@ config MTD_NAND_ECC_SW_HAMMING_SMC
menuconfig MTD_RAW_NAND
tristate "Raw/Parallel NAND Device Support"
select MTD_NAND_CORE
+ select MTD_NAND_ECC
select MTD_NAND_ECC_SW_HAMMING
help
This enables support for accessing all type of raw/parallel
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 8dc230892b90..afc3506468ba 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -34,6 +34,7 @@
#include <linux/mm.h>
#include <linux/types.h>
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
#include <linux/mtd/nand_ecc.h>
#include <linux/mtd/nand_bch.h>
#include <linux/interrupt.h>
@@ -45,182 +46,6 @@
#include "internals.h"
-/* Define default oob placement schemes for large and small page devices */
-static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section > 1)
- return -ERANGE;
-
- if (!section) {
- oobregion->offset = 0;
- if (mtd->oobsize == 16)
- oobregion->length = 4;
- else
- oobregion->length = 3;
- } else {
- if (mtd->oobsize == 8)
- return -ERANGE;
-
- oobregion->offset = 6;
- oobregion->length = ecc->total - 4;
- }
-
- return 0;
-}
-
-static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- if (section > 1)
- return -ERANGE;
-
- if (mtd->oobsize == 16) {
- if (section)
- return -ERANGE;
-
- oobregion->length = 8;
- oobregion->offset = 8;
- } else {
- oobregion->length = 2;
- if (!section)
- oobregion->offset = 3;
- else
- oobregion->offset = 6;
- }
-
- return 0;
-}
-
-static const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
- .ecc = nand_ooblayout_ecc_sp,
- .free = nand_ooblayout_free_sp,
-};
-
-const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void)
-{
- return &nand_ooblayout_sp_ops;
-}
-EXPORT_SYMBOL_GPL(nand_get_small_page_ooblayout);
-
-static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section || !ecc->total)
- return -ERANGE;
-
- oobregion->length = ecc->total;
- oobregion->offset = mtd->oobsize - oobregion->length;
-
- return 0;
-}
-
-static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section)
- return -ERANGE;
-
- oobregion->length = mtd->oobsize - ecc->total - 2;
- oobregion->offset = 2;
-
- return 0;
-}
-
-static const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
- .ecc = nand_ooblayout_ecc_lp,
- .free = nand_ooblayout_free_lp,
-};
-
-const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void)
-{
- return &nand_ooblayout_lp_ops;
-}
-EXPORT_SYMBOL_GPL(nand_get_large_page_ooblayout);
-
-/*
- * Support the old "large page" layout used for 1-bit Hamming ECC where ECC
- * are placed at a fixed offset.
- */
-static int nand_ooblayout_ecc_lp_hamming(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section)
- return -ERANGE;
-
- switch (mtd->oobsize) {
- case 64:
- oobregion->offset = 40;
- break;
- case 128:
- oobregion->offset = 80;
- break;
- default:
- return -EINVAL;
- }
-
- oobregion->length = ecc->total;
- if (oobregion->offset + oobregion->length > mtd->oobsize)
- return -ERANGE;
-
- return 0;
-}
-
-static int nand_ooblayout_free_lp_hamming(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
- int ecc_offset = 0;
-
- if (section < 0 || section > 1)
- return -ERANGE;
-
- switch (mtd->oobsize) {
- case 64:
- ecc_offset = 40;
- break;
- case 128:
- ecc_offset = 80;
- break;
- default:
- return -EINVAL;
- }
-
- if (section == 0) {
- oobregion->offset = 2;
- oobregion->length = ecc_offset - 2;
- } else {
- oobregion->offset = ecc_offset + ecc->total;
- oobregion->length = mtd->oobsize - oobregion->offset;
- }
-
- return 0;
-}
-
-static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
- .ecc = nand_ooblayout_ecc_lp_hamming,
- .free = nand_ooblayout_free_lp_hamming,
-};
-
-const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
-{
- return &nand_ooblayout_lp_hamming_ops;
-}
-EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
-
static int nand_pairing_dist3_get_info(struct mtd_info *mtd, int page,
struct mtd_pairing_info *info)
{
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 668c99c4aaa7..817969a8a230 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -127,6 +127,10 @@ struct nand_page_io_req {
int mode;
};
+const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void);
+const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void);
+const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void);
+
/**
* enum nand_ecc_engine_type - NAND ECC engine type
* @NAND_ECC_ENGINE_TYPE_INVALID: Invalid value
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index b455cb22168f..66f69a1d27a5 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -14,6 +14,7 @@
#define __LINUX_MTD_RAWNAND_H
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
#include <linux/mtd/flashchip.h>
#include <linux/mtd/bbm.h>
#include <linux/mtd/jedec.h>
@@ -1147,10 +1148,6 @@ struct nand_chip {
int (*unlock_area)(struct nand_chip *chip, loff_t ofs, uint64_t len);
};
-const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void);
-const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void);
-const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void);
-
static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
{
return container_of(mtd, struct nand_chip, base.mtd);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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