* Re: [PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd
From: Rob Herring @ 2020-05-28 22:20 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree, linux-omap, linux-kernel, Andrew F . Davis,
Tero Kristo, Santosh Shilimkar, Suman Anna, linux-arm-kernel
In-Reply-To: <20200520211334.61814-2-tony@atomide.com>
On Wed, May 20, 2020 at 02:13:29PM -0700, Tony Lindgren wrote:
> The PRM (Power and Reset Module) has registers to enable and disable
> power domains, so let's update the binding for that.
multiple domains? Then why 0 cells?
>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> --- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -18,6 +18,7 @@ Required properties:
> (base address and length)
>
> Optional properties:
> +- #power-domain-cells: Should be 0 if the PRM instance is a power domain.
...power domain provider.
> - #reset-cells: Should be 1 if the PRM instance in question supports resets.
>
> Example:
> @@ -25,5 +26,6 @@ Example:
> prm_dsp2: prm@1b00 {
> compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
> reg = <0x1b00 0x40>;
> + #power-domain-cells = <0>;
> #reset-cells = <1>;
> };
> --
> 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
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-05-28 22:20 UTC (permalink / raw)
To: Baoquan He, Chen Zhou
Cc: horms, devicetree, arnd, will, linux-doc, catalin.marinas, kexec,
linux-kernel, robh+dt, mingo, guohanjun, tglx, pkushwaha, dyoung,
linux-arm-kernel
In-Reply-To: <20200526014242.GF20045@MiWiFi-R3L-srv>
On 5/25/20 8:42 PM, Baoquan He wrote:
> On 05/21/20 at 05:38pm, Chen Zhou 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.
> OK, moving x86 CRASH_ALIGN to 2M is suggested by Dave. Because
> CONFIG_PHYSICAL_ALIGN can be selected from 2M to 16M. So 2M seems good.
> But, anyway, we should tell the reason why it need be changed in commit
> log.
>
>
> arch/x86/Kconfig:
> config PHYSICAL_ALIGN
> hex "Alignment value to which kernel should be aligned"
> default "0x200000"
> range 0x2000 0x1000000 if X86_32
> range 0x200000 0x1000000 if X86_64
>
>> - 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.
> And the crashkernel=X,high being deleted need be told too. Otherwise
> people reading the commit have to check why themselves. I didn't follow
> the old version, can't see why ,high can't be specified explicitly.
>
>> - 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!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwQs3C4x$
>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6e-mIEp$
>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJyUVjUta$
>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ3CXBRdT$
>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ7SxW1Vj$
>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ2wyJ9tj$
>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJzvGhWBh$
>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6pAg6tX$
>>
>> 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
>>
>> Documentation/admin-guide/kdump/kdump.rst | 13 ++-
>> .../admin-guide/kernel-parameters.txt | 12 ++-
>> Documentation/devicetree/bindings/chosen.txt | 25 ++++++
>> arch/arm64/kernel/setup.c | 8 +-
>> arch/arm64/mm/init.c | 61 ++++++++++++-
>> arch/x86/kernel/setup.c | 66 ++------------
>> include/linux/crash_core.h | 3 +
>> include/linux/kexec.h | 2 -
>> kernel/crash_core.c | 85 +++++++++++++++++++
>> kernel/kexec_core.c | 17 ----
>> 10 files changed, 208 insertions(+), 84 deletions(-)
>>
>> --
>> 2.20.1
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/kexec__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwwX8HSl$
>>
Hi,
This proposal to improve vmcore creation on Arm has been going on for
almost a year now.
Who is the final maintainer that needs to approve and except these ?
What are the lingering issues that are remaining so we get these
accepted into a upstream commit ?
Thank you.
John.
_______________________________________________
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 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Rob Herring @ 2020-05-28 22:32 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
linux-kernel, Bjorn Andersson, linux-arm-kernel
In-Reply-To: <20200521001006.2725-3-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
> Processor (DSP) subsystems that are comprised of either a TMS320C66x
> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
> Add the device tree bindings document for the C66x DSP devices on these
> SoCs. The added example illustrates the DT nodes for the first C66x DSP
> device present on the K3 J721E family of SoCs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - Updated the example to include the root-node to fix the bot errors from v1
Pretty sure that was not why you had errors.
> - Added maxItems to resets, mboxes, memory-region, sram properties
> - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
> - Addressed the minor review comments from Mathieu
> v1: https://patchwork.kernel.org/patch/11458571/
>
> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
> 1 file changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> new file mode 100644
> index 000000000000..cdf649655838
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> @@ -0,0 +1,190 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI K3 DSP devices
> +
> +maintainers:
> + - Suman Anna <s-anna@ti.com>
> +
> +description: |
> + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
> + that are used to offload some of the processor-intensive tasks or algorithms,
> + for achieving various system level goals.
> +
> + These processor sub-systems usually contain additional sub-modules like
> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
> + controller, a dedicated local power/sleep controller etc. The DSP processor
> + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
> + TMS320C71x CorePac processor.
> +
> + Each DSP Core sub-system is represented as a single DT node. Each node has a
> + number of required or optional properties that enable the OS running on the
> + host processor (Arm CorePac) to perform the device management of the remote
> + processor and to communicate with the remote processor.
> +
> +properties:
> + compatible:
> + const: ti,j721e-c66-dsp
> + description:
> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
What else are you going to use? There's only one compatible string. Drop
description.
> +
> + reg:
> + description: |
> + Should contain an entry for each value in 'reg-names'.
> + Each entry should have the memory region's start address
> + and the size of the region, the representation matching
> + the parent node's '#address-cells' and '#size-cells' values.
Don't need generic descriptions. That's every 'reg'.
What you can do is an 'items' list describing what each region is.
> + minItems: 3
> + maxItems: 3
> +
> + reg-names:
> + description: |
> + Should contain strings with the names of the specific internal
> + memory regions, and should be defined in this order
Again, drop.
> + maxItems: 3
> + items:
> + - const: l2sram
> + - const: l1pram
> + - const: l1dram
> +
> + ti,sci:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Should be a phandle to the TI-SCI System Controller node
> +
> + ti,sci-dev-id:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + Should contain the TI-SCI device id corresponding to the DSP core.
> + Please refer to the corresponding System Controller documentation
> + for valid values for the DSP cores.
> +
> + ti,sci-proc-ids:
> + description: Should contain a single tuple of <proc_id host_id>.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - maxItems: 1
> + items:
> + items:
> + - description: TI-SCI processor id for the DSP core device
> + - description: TI-SCI host id to which processor control
> + ownership should be transferred to
I assume these properties appear in multiple TI nodes? We don't need
them defined multiple times. Create a schema for them that you can
include here.
> +
> + resets:
> + description: |
> + Should contain the phandle to the reset controller node
> + managing the local resets for this device, and a reset
> + specifier. Please refer to the following reset bindings
> + for the reset argument specifier,
> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
Drop.
> + maxItems: 1
> +
> + firmware-name:
> + description: |
> + Should contain the name of the default firmware image
> + file located on the firmware search path
> +
> + mboxes:
> + description: |
> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> + communication with the remote processor. This property should match
> + with the sub-mailbox node used in the firmware image. The specifier
> + format is as per the bindings,
> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
Drop. What mailbox provider is used is outside the scope of this
binding.
> + maxItems: 1
> +
> + memory-region:
> + minItems: 2
> + maxItems: 8
> + description: |
> + phandle to the reserved memory nodes to be associated with the remoteproc
> + device. There should be at least two reserved memory nodes defined - the
> + first one would be used for dynamic DMA allocations like vrings and vring
> + buffers, and the remaining ones used for the firmware image sections. The
> + reserved memory nodes should be carveout nodes, and should be defined as
> + per the bindings in
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
items:
- description: dynamic DMA allocations like vrings and vring buffers
- description: firmware image section ???
- description: firmware image section ???
> +
> +# Optional properties:
> +# --------------------
> +
> + sram:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + minItems: 1
> + maxItems: 4
> + description: |
> + phandles to one or more reserved on-chip SRAM regions. The regions
> + should be defined as child nodes of the respective SRAM node, and
> + should be defined as per the generic bindings in,
> + Documentation/devicetree/bindings/sram/sram.yaml
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - ti,sci
> + - ti,sci-dev-id
> + - ti,sci-proc-ids
> + - resets
> + - firmware-name
> + - mboxes
> + - memory-region
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + / {
> + model = "Texas Instruments K3 J721E SoC";
> + compatible = "ti,j721e";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + /* DSP Carveout reserved memory nodes */
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa6000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + c66_0_memory_region: c66-memory@a6100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa6100000 0x00 0xf00000>;
> + no-map;
> + };
> + };
Drop all of this. Outside the scope of this binding. And will likely
start failing validation as schemas become more complete.
> +
> + cbass_main: bus@100000 {
Drop unused labels.
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
> + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
> + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
> +
> + /* J721E C66_0 DSP node */
> + c66_0: dsp@4d80800000 {
> + compatible = "ti,j721e-c66-dsp";
> + reg = <0x4d 0x80800000 0x00 0x00048000>,
> + <0x4d 0x80e00000 0x00 0x00008000>,
> + <0x4d 0x80f00000 0x00 0x00008000>;
> + reg-names = "l2sram", "l1pram", "l1dram";
> + ti,sci = <&dmsc>;
> + ti,sci-dev-id = <142>;
> + ti,sci-proc-ids = <0x03 0xFF>;
> + resets = <&k3_reset 142 1>;
> + firmware-name = "j7-c66_0-fw";
> + memory-region = <&c66_0_dma_memory_region>,
> + <&c66_0_memory_region>;
> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
> + };
> + };
> + };
> --
> 2.26.0
>
_______________________________________________
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 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Suman Anna @ 2020-05-28 22:47 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
linux-kernel, Bjorn Andersson, linux-arm-kernel
In-Reply-To: <20200528223228.GA785633@bogus>
Hi Rob,
On 5/28/20 5:32 PM, Rob Herring wrote:
> On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
>> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
>> Processor (DSP) subsystems that are comprised of either a TMS320C66x
>> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
>> Add the device tree bindings document for the C66x DSP devices on these
>> SoCs. The added example illustrates the DT nodes for the first C66x DSP
>> device present on the K3 J721E family of SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> v2:
>> - Updated the example to include the root-node to fix the bot errors from v1
>
> Pretty sure that was not why you had errors.
It is because of the default values used for #address-cells and
#size-cells in the example_template and example_start variables used in
the dt-extract-example script. They are 1 by default, so the generated
template ended up with the root-node using 1, and the actual example
using 2 resulting in the mismatch.
When I updated the script to use 2 for both #address-cells and
#size-cells, then the warnings go away. This is the reason, dtbs_check
on my actual dts files goes through fine.
>
>> - Added maxItems to resets, mboxes, memory-region, sram properties
>> - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
>> - Addressed the minor review comments from Mathieu
>> v1: https://patchwork.kernel.org/patch/11458571/
>>
>> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
>> 1 file changed, 190 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>> new file mode 100644
>> index 000000000000..cdf649655838
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>> @@ -0,0 +1,190 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI K3 DSP devices
>> +
>> +maintainers:
>> + - Suman Anna <s-anna@ti.com>
>> +
>> +description: |
>> + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
>> + that are used to offload some of the processor-intensive tasks or algorithms,
>> + for achieving various system level goals.
>> +
>> + These processor sub-systems usually contain additional sub-modules like
>> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
>> + controller, a dedicated local power/sleep controller etc. The DSP processor
>> + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
>> + TMS320C71x CorePac processor.
>> +
>> + Each DSP Core sub-system is represented as a single DT node. Each node has a
>> + number of required or optional properties that enable the OS running on the
>> + host processor (Arm CorePac) to perform the device management of the remote
>> + processor and to communicate with the remote processor.
>> +
>> +properties:
>> + compatible:
>> + const: ti,j721e-c66-dsp
>> + description:
>> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
>
> What else are you going to use? There's only one compatible string. Drop
> description.
Is updated in a subsequent binding update where I added the C71 support.
>
>> +
>> + reg:
>> + description: |
>> + Should contain an entry for each value in 'reg-names'.
>> + Each entry should have the memory region's start address
>> + and the size of the region, the representation matching
>> + the parent node's '#address-cells' and '#size-cells' values.
>
> Don't need generic descriptions. That's every 'reg'.
>
> What you can do is an 'items' list describing what each region is.
OK, I am bit confused here. I have listed the items under the reg-names,
while using just the minItems or maxItems here. What is the convention,
aren't reg and reg-names associative.
>
>> + minItems: 3
>> + maxItems: 3
>> +
>> + reg-names:
>> + description: |
>> + Should contain strings with the names of the specific internal
>> + memory regions, and should be defined in this order
>
> Again, drop.
OK
>
>> + maxItems: 3
>> + items:
>> + - const: l2sram
>> + - const: l1pram
>> + - const: l1dram
>> +
>> + ti,sci:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Should be a phandle to the TI-SCI System Controller node
>> +
>> + ti,sci-dev-id:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + Should contain the TI-SCI device id corresponding to the DSP core.
>> + Please refer to the corresponding System Controller documentation
>> + for valid values for the DSP cores.
>> +
>> + ti,sci-proc-ids:
>> + description: Should contain a single tuple of <proc_id host_id>.
>> + allOf:
>> + - $ref: /schemas/types.yaml#/definitions/uint32-array
>> + - maxItems: 1
>> + items:
>> + items:
>> + - description: TI-SCI processor id for the DSP core device
>> + - description: TI-SCI host id to which processor control
>> + ownership should be transferred to
>
> I assume these properties appear in multiple TI nodes? We don't need
> them defined multiple times. Create a schema for them that you can
> include here.
Only the remoteprocs, so they are limited to this binding and one more
R5F remoteproc binding.
>
>> +
>> + resets:
>> + description: |
>> + Should contain the phandle to the reset controller node
>> + managing the local resets for this device, and a reset
>> + specifier. Please refer to the following reset bindings
>> + for the reset argument specifier,
>> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>
> Drop.
Entire description or just the reference to the reset bindings file?
>
>> + maxItems: 1
>> +
>> + firmware-name:
>> + description: |
>> + Should contain the name of the default firmware image
>> + file located on the firmware search path
>> +
>> + mboxes:
>> + description: |
>> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
>> + communication with the remote processor. This property should match
>> + with the sub-mailbox node used in the firmware image. The specifier
>> + format is as per the bindings,
>> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>
> Drop. What mailbox provider is used is outside the scope of this
> binding.
OK.
>
>> + maxItems: 1
>> +
>> + memory-region:
>> + minItems: 2
>> + maxItems: 8
>> + description: |
>> + phandle to the reserved memory nodes to be associated with the remoteproc
>> + device. There should be at least two reserved memory nodes defined - the
>> + first one would be used for dynamic DMA allocations like vrings and vring
>> + buffers, and the remaining ones used for the firmware image sections. The
>> + reserved memory nodes should be carveout nodes, and should be defined as
>> + per the bindings in
>> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> items:
> - description: dynamic DMA allocations like vrings and vring buffers
> - description: firmware image section ???
> - description: firmware image section ???
Yeah, this is scalable if we will have multiple separate DDR regions. I
had to choose a decent maxItems value, so I chose 8. Wouldn't listing
the individual items override the number of minItems/maxItems?
>
>> +
>> +# Optional properties:
>> +# --------------------
>> +
>> + sram:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + minItems: 1
>> + maxItems: 4
>> + description: |
>> + phandles to one or more reserved on-chip SRAM regions. The regions
>> + should be defined as child nodes of the respective SRAM node, and
>> + should be defined as per the generic bindings in,
>> + Documentation/devicetree/bindings/sram/sram.yaml
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - ti,sci
>> + - ti,sci-dev-id
>> + - ti,sci-proc-ids
>> + - resets
>> + - firmware-name
>> + - mboxes
>> + - memory-region
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + / {
>> + model = "Texas Instruments K3 J721E SoC";
>> + compatible = "ti,j721e";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + /* DSP Carveout reserved memory nodes */
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa6000000 0x00 0x100000>;
>> + no-map;
>> + };
>> +
>> + c66_0_memory_region: c66-memory@a6100000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa6100000 0x00 0xf00000>;
>> + no-map;
>> + };
>> + };
>
> Drop all of this. Outside the scope of this binding. And will likely
> start failing validation as schemas become more complete.
This is a complete example because of the memory-region references below.
>
>> +
>> + cbass_main: bus@100000 {
>
> Drop unused labels.
OK.
regards
Suman
>
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
>> + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
>> + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
>> +
>> + /* J721E C66_0 DSP node */
>> + c66_0: dsp@4d80800000 {
>> + compatible = "ti,j721e-c66-dsp";
>> + reg = <0x4d 0x80800000 0x00 0x00048000>,
>> + <0x4d 0x80e00000 0x00 0x00008000>,
>> + <0x4d 0x80f00000 0x00 0x00008000>;
>> + reg-names = "l2sram", "l1pram", "l1dram";
>> + ti,sci = <&dmsc>;
>> + ti,sci-dev-id = <142>;
>> + ti,sci-proc-ids = <0x03 0xFF>;
>> + resets = <&k3_reset 142 1>;
>> + firmware-name = "j7-c66_0-fw";
>> + memory-region = <&c66_0_dma_memory_region>,
>> + <&c66_0_memory_region>;
>> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
>> + };
>> + };
>> + };
>> --
>> 2.26.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge
From: Laurent Pinchart @ 2020-05-28 22:48 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Peng Fan, Daniel Vetter, Sam Ravnborg, Anson Huang,
David Airlie, Shawn Guo, Guido Günther, linux-kernel,
dri-devel, Andrzej Hajda, NXP Linux Team, Pengutronix Kernel Team,
Robert Chiras, Leonard Crestez, Fabio Estevam, linux-arm-kernel,
Lucas Stach
In-Reply-To: <20200528194804.GA541078@bogus>
Hi Rob,
On Thu, May 28, 2020 at 01:48:04PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:12:10PM +0200, Guido Günther wrote:
> > The bridge allows to select the input source via a mux controller.
> >
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > .../display/bridge/mux-input-bridge.yaml | 123 ++++++++++++++++++
> > 1 file changed, 123 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> > new file mode 100644
> > index 000000000000..4029cf63ee5c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> > @@ -0,0 +1,123 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: DRM input source selection via multiplexer
>
> DRM is not a hardware thing.
>
> The graph binding is already designed to support muxing. Generally,
> multiple endpoints on an input node is a mux. So either the device with
> the input ports knows how to select the input, or you just need a
> mux-control property for the port to have some other device implement
> the control.
The mux modelled by this binding is used by Guido with the NWL DSI
bridge integrated in the i.MX8. The NWL DSI is an IP core that has a
single input. The i.MX8 has an additional mux in front of the NWL DSI,
to select between the two display controllers in the SoC (eLCDIF and
DCSS). The mux doesn't belong to any of the display controller, it's
really glue logic between the display controllers and the NWL DSI
bridge.
I agree that the bindings shouldn't mention DRM. I would however prefer
not adding a mux-control property and multiple input ports to the NWL
DSI binding, as the mux isn't internal to that IP core (if we go that
route, we would need to add mux control to any IP core that would be
integrated in an SoC with a mux in front). As DT should describe the
hardware, I think describing the standalone mux between the display
controllers and the NWL DSI bridge makex sense.
We already have a DT binding for a video mux
(Documentation/devicetree/bindings/media/video-mux.txt). From a DT point
of view, I see no reason not to reuse that. From a driver point of view
that will be messy, as the driver that binds to the video-mux compatible
string is part of V4L2. That's a driver issue however (and not a new
one, we already have devices that can be part of a video capture
pipeline or a video display pipeline), and should be solved on the
software side, not the DT side. It will however not be easy work, which
explains why, so far, everybody has ignored the issue hoping that
someone else would be hit by it first. We may have reached that day.
> You could do it like you have below. That would be appropriate if
> there's a separate h/w device controlling the muxing. Say for example
> some board level device controlled by i2c.
--
Regards,
Laurent Pinchart
_______________________________________________
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 RFCv2 9/9] arm64: Support async page fault
From: Gavin Shan @ 2020-05-28 23:02 UTC (permalink / raw)
To: Paolo Bonzini, kvmarm
Cc: maz, linux-kernel, shan.gavin, catalin.marinas, will,
linux-arm-kernel
In-Reply-To: <8ab64c6a-582b-691d-79ab-21cdc0455cd3@redhat.com>
Hi Paolo,
On 5/28/20 8:48 PM, Paolo Bonzini wrote:
> On 28/05/20 08:14, Gavin Shan wrote:
>>> - for x86 we're also thinking of initiating the page fault from the
>>> exception handler, rather than doing so from the hypervisor before
>>> injecting the exception. If ARM leads the way here, we would do our
>>> best to share code when x86 does the same.
>>
>> Sorry, Paolo, I don't follow your idea here. Could you please provide
>> more details?
>
> The idea is to inject stage2 page faults into the guest even before the
> host starts populates the page. The guest then invokes a hypercall,
> telling the host to populate the page table and inject the 'page ready'
> event (interrupt) when it's done.
>
> For x86 the advantage is that the processor can take care of raising the
> stage2 page fault in the guest, so it's faster.
>
I think there might be too much overhead if the page can be populated
quickly by host. For example, it's fast to populate the pages if swapin
isn't involved.
If I'm correct enough, it seems arm64 doesn't have similar mechanism,
routing stage2 page fault to guest.
Thanks,
Gavin
_______________________________________________
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 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags
From: Stephen Boyd @ 2020-05-28 23:12 UTC (permalink / raw)
To: Jolly Shah, arm, linux-clk, michal.simek, mturquette, olof
Cc: Tejas Patel, Rajan Vaja, rajanv, linux-kernel, linux-arm-kernel
In-Reply-To: <2c8cd31a-46ba-ec6a-67a7-f3d9abe561ff@xilinx.com>
Quoting Jolly Shah (2020-05-28 10:44:01)
> Hi Stephan,
>
> Thanks for the review.
>
> > ------Original Message------
> > From: Stephen Boyd <sboyd@kernel.org>
> > Sent: Tuesday, May 26, 2020 6:08PM
> > To: Jolly Shah <jolly.shah@xilinx.com>, Arm <arm@kernel.org>,
> Linux-clk <linux-clk@vger.kernel.org>, Michal Simek
> <michal.simek@xilinx.com>, Mturquette <mturquette@baylibre.com>, Olof
> <olof@lixom.net>
> > Cc: Rajan Vaja <rajanv@xilinx.com>,
> Linux-arm-kernel@lists.infradead.org
> <linux-arm-kernel@lists.infradead.org>, Linux-kernel@vger.kernel.org
> <linux-kernel@vger.kernel.org>, Tejas Patel <tejas.patel@xilinx.com>,
> Rajan Vaja <rajan.vaja@xilinx.com>, Jolly Shah <jolly.shah@xilinx.com>
> > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction
> clock check from custom type flags
> >
> > Quoting Jolly Shah (2020-03-12 14:31:39)
> >> From: Tejas Patel <tejas.patel@xilinx.com>
> >>
> >> Older firmware version sets BIT(13) in clkflag to mark a
> >> divider as fractional divider. Updated firmware version sets BIT(4)
> >> in type flags to mark a divider as fractional divider since
> >> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
> >> framework flags.
> >>
> >> To support both old and new firmware version, consider BIT(13) from
> >> clkflag and BIT(4) from type_flag to check if divider is fractional
> >> or not.
> >>
> >> To maintain compatibility BIT(13) of clkflag in firmware will not be
> >> used in future for any purpose and will be marked as unused.
> >
> > Why are we mixing the firmware flags with the ccf flags? They shouldn't
> > be the same. The firmware should have its own 'flag numberspace' that is
> > distinct from the common clk framework's 'flag numberspace'. Please fix
> > the code.
> >
>
> Yes firmware flags are using separate numberspace now. Firmware
> maintains CCF and firmware specific flags separately but earlier
> CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here
> for backward compatibility. Driver takes care of not registering same
> with CCF. Let me know if I misunderstood.
Why is the firmware maintaining CCF specific flags? The firmware
shouldn't know about the CCF flag numbering at all. We can change the
numbers that the CCF flags are assigned to randomly and that shouldn't
mean that the firmware needs to change. Maybe I should apply this patch?
---8<----
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index bd1ee9039558..c1f36bca85b0 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -16,22 +16,22 @@
*
* Please update clk_flags[] in drivers/clk/clk.c when making changes here!
*/
-#define CLK_SET_RATE_GATE BIT(0) /* must be gated across rate change */
-#define CLK_SET_PARENT_GATE BIT(1) /* must be gated across re-parent */
-#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one level */
-#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */
+#define CLK_SET_RATE_GATE BIT(13) /* must be gated across rate change */
+#define CLK_SET_PARENT_GATE BIT(2) /* must be gated across re-parent */
+#define CLK_SET_RATE_PARENT BIT(3) /* propagate rate change up one level */
+#define CLK_IGNORE_UNUSED BIT(4) /* do not gate even if unused */
/* unused */
/* unused */
-#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */
-#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
-#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */
-#define CLK_RECALC_NEW_RATES BIT(9) /* recalc rates after notifications */
-#define CLK_SET_RATE_UNGATE BIT(10) /* clock needs to run to set rate */
-#define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
+#define CLK_GET_RATE_NOCACHE BIT(5) /* do not use the cached clk rate */
+#define CLK_SET_RATE_NO_REPARENT BIT(6) /* don't re-parent on rate change */
+#define CLK_GET_ACCURACY_NOCACHE BIT(7) /* do not use the cached clk accuracy */
+#define CLK_RECALC_NEW_RATES BIT(8) /* recalc rates after notifications */
+#define CLK_SET_RATE_UNGATE BIT(9) /* clock needs to run to set rate */
+#define CLK_IS_CRITICAL BIT(10) /* do not gate, ever */
/* parents need enable during gate/ungate, set rate and re-parent */
-#define CLK_OPS_PARENT_ENABLE BIT(12)
+#define CLK_OPS_PARENT_ENABLE BIT(11)
/* duty cycle call may be forwarded to the parent clock */
-#define CLK_DUTY_CYCLE_PARENT BIT(13)
+#define CLK_DUTY_CYCLE_PARENT BIT(12)
struct clk;
struct clk_hw;
_______________________________________________
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/RFC] arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
From: nobuhiro1.iwamatsu @ 2020-05-28 23:31 UTC (permalink / raw)
To: will; +Cc: mark.rutland, catalin.marinas, gshan, yuji2.ishikawa,
linux-arm-kernel
In-Reply-To: <20200528081204.GC22156@willie-the-truck>
Hi,
Thanks for your review.
The patch has already been applied...
> -----Original Message-----
> From: Will Deacon [mailto:will@kernel.org]
> Sent: Thursday, May 28, 2020 5:12 PM
> To: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@toshiba.co.jp>
> Cc: linux-arm-kernel@lists.infradead.org; Mark Rutland <mark.rutland@arm.com>; catalin.marinas@arm.com;
> Signed-off-by : Gavin Shan <gshan@redhat.com>; ishikawa yuji(石川 悠司 ＴＤＳＣ ○ＤＳＲＣ□ＥＴ開○ＥＴ３)
> <yuji2.ishikawa@toshiba.co.jp>
> Subject: Re: [PATCH/RFC] arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
>
> On Thu, May 28, 2020 at 08:34:57AM +0900, Nobuhiro Iwamatsu wrote:
> > If boot_secondary() was successful, and cpu_online() was an error in
> > __cpu_up(), -EIO was returned, but 0 is returned by commit d22b115cbfbb7
> > ("arm64/kernel: Simplify __cpu_up() by bailing out early").
> > Therefore, bringup_wait_for_ap() causes the primary core to wait for a
> > long time, which may cause boot failure.
> > This commit sets -EIO to return code under the same conditions.
> >
> > Fixes: d22b115cbfbb7 ("arm64/kernel: Simplify __cpu_up() by bailing out early")
> > CC: Signed-off-by: Gavin Shan <gshan@redhat.com>
> > CC: Catalin Marinas <catalin.marinas@arm.com>
> > CC: Mark Rutland <mark.rutland@arm.com>
> > Tested-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
> > ---
> > arch/arm64/kernel/smp.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 061f60fe452f7..ea677680e4277 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -137,6 +137,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > if (cpu_online(cpu))
> > return 0;
> >
> > + ret = -EIO;
> > pr_crit("CPU%u: failed to come online\n", cpu);
> > secondary_data.task = NULL;
> > secondary_data.stack = NULL;
>
> This appears to restore the old behaviour, so looks good to me. I'd probably
> just replace the final 'return ret' with 'return -EIO' since it's never
> going to be anything else.
Yeah, your suggestion is better.
>
> Also -- aren't you in a pretty serious mess if the CPU starts but doesn't
> come online? I think the patch is fine, but this really shouldn't happen,
> right? Could you share your dmesg?
>
I paste the dmesg below. It stops with "printk: bootconsole [pl11] disabled" in my environment.
After checking the bisect and the code, I realized that there was a problem with the target commit.
And SoC enable-method that causes the problem uses spin-table instead of PCSI.
----
Starting kernel ...
Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Linux version 5.7.0-rc7-00032-g565e4e976d6e (iwamatsu@ryzen7) (gcc version 8.3.0 (Debian 8.3.0-21), GNU ld (GNU Binutils for Debian) 2.34) #8 SMP PREEMPT Thu May 28 20:48:58 JST 2020
Machine model: Toshiba TMPV7700 EVB
earlycon: pl11 at MMIO 0x0000000028200000 (options '')
printk: bootconsole [pl11] enabled
cma: Reserved 16 MiB at 0x00000000b7000000
NUMA: No NUMA configuration found
NUMA: Faking a node at [mem 0x0000000080000000-0x00000000b7ffffff]
NUMA: NODE_DATA [mem 0xb6e34100-0xb6e35fff]
Zone ranges:
DMA [mem 0x0000000080000000-0x00000000b7ffffff]
DMA32 empty
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000080000000-0x00000000b7ffffff]
Initmem setup node 0 [mem 0x0000000080000000-0x00000000b7ffffff]
percpu: Embedded 21 pages/cpu s46168 r8192 d31656 u86016
Detected VIPT I-cache on CPU0
CPU features: detected: ARM erratum 845719
Built 1 zonelists, mobility grouping on. Total pages: 225792
Policy zone: DMA
Kernel command line: earlycon=pl011,0x28200000
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 765600K/917504K available (4670K kernel code, 318K rwdata, 1236K rodata, 320K init, 327K bss, 135520K reserved, 16384K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
rcu: Preemptible hierarchical RCU implementation.
rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
GIC: Using split EOI/Deactivate mode
random: get_random_bytes called from start_kernel팝ﴱ with crng_init=0
arch_timer: cp15 timer(s) running at 150.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x2298375bd0, max_idle_ns: 440795208267 ns
sched_clock: 56 bits at 150MHz, resolution 6ns, wraps every 2199023255551ns
Console: colour dummy device 80x25
printk: console [tty0] enabled
printk: bootconsole [pl11] disabled
---
> Either way:
>
> Acked-by: Will Deacon <will@kernel.org>
>
Thanks!
> Catalin -- do you want to take this (the problematic change was introduced
> during the last merge window afaict)?
>
> Will
Best regards,
Nobuhiro
_______________________________________________
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] dt-bindings: dma: uart: mtk: fix example
From: Rob Herring @ 2020-05-28 23:40 UTC (permalink / raw)
To: matthias.bgg
Cc: devicetree, Matthias Brugger, sean.wang, linux-kernel, dmaengine,
vkoul, robh+dt, linux-mediatek, matthias.bgg, linux-arm-kernel
In-Reply-To: <20200523201530.18225-1-matthias.bgg@kernel.org>
On Sat, 23 May 2020 22:15:30 +0200, matthias.bgg@kernel.org wrote:
> From: Matthias Brugger <mbrugger@suse.com>
>
> The binding example is missing the fallback compatible.
> This is needed as the driver only matches against mt6577.
>
> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> ---
> Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
_______________________________________________
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 v6 15/18] mtd: nand: Introduce the ECC engine abstraction
From: Miquel Raynal @ 2020-05-28 23:46 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528205251.5e8abdd1@collabora.com>
Hi Boris,
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 20:52:51 +0200:
> On Thu, 28 May 2020 13:31:10 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Create a generic ECC engine object.
> >
> > Later the ecc.c file will receive more generic code coming from
> > the raw NAND specific part. This is a base to instantiate ECC engine
> > objects.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > drivers/mtd/nand/Kconfig | 7 ++
> > drivers/mtd/nand/Makefile | 2 +
> > drivers/mtd/nand/ecc.c | 138 ++++++++++++++++++++++++++++++++++++++
> > include/linux/mtd/nand.h | 67 ++++++++++++++++++
> > 4 files changed, 214 insertions(+)
> > create mode 100644 drivers/mtd/nand/ecc.c
> >
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index c1a45b071165..a4478ffa279d 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
> > source "drivers/mtd/nand/raw/Kconfig"
> > source "drivers/mtd/nand/spi/Kconfig"
> >
> > +menu "ECC engine support"
> > +
> > +config MTD_NAND_ECC
> > + bool
> > +
> > +endmenu
> > +
> > endmenu
> > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> > index 7ecd80c0a66e..981372953b56 100644
> > --- a/drivers/mtd/nand/Makefile
> > +++ b/drivers/mtd/nand/Makefile
> > @@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> > obj-y += onenand/
> > obj-y += raw/
> > obj-y += spi/
> > +
> > +nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
> > diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
> > new file mode 100644
> > index 000000000000..e4f2b6fcbb12
> > --- /dev/null
> > +++ b/drivers/mtd/nand/ecc.c
> > @@ -0,0 +1,138 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Generic Error-Correcting Code (ECC) engine
> > + *
> > + * Copyright (C) 2019 Macronix
> > + * Author:
> > + * Miquèl RAYNAL <miquel.raynal@bootlin.com>
> > + *
> > + *
> > + * This file describes the abstraction of any NAND ECC engine. It has been
> > + * designed to fit most cases, including parallel NANDs and SPI-NANDs.
> > + *
> > + * There are three main situations where instantiating this ECC engine makes
> > + * sense:
> > + * - "external": The ECC engine is outside the NAND pipeline, typically this
>
> I'm not sure why you put quotes around those names.
>
> > + * is a software ECC engine. One can also imagine a generic
>
> ^ or an hardware
> engine that's outside the NAND controller pipeline.
>
> You can the drop the "One can also imagine ..." since it's more than a
> theoretical use case, we already have a few engines that fall in this
> category.
>
> > + * hardware ECC engine which would be an IP itself. Interacting
> > + * with a SPI-NAND device without on-die ECC could be achieved
>
> ^can
>
> > + * thanks to the use of such external engine.
>
> But I think I would simply drop this last sentence.
>
> > + * - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
> > + * controller's side. This is the case of most of the raw NAND
> > + * controllers. These controllers usually embed an hardware ECC
> > + * engine which is managed thanks to the same register set as
> > + * the controller's.
>
> Again, I would drop the last sentence here. I think saying the ECC
> bytes are generated/data corrected on the fly when a page is
> written/read would be more useful.
>
> > + * - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
> > + * Some NAND chips can correct themselves the data. The on-die
> > + * correction can be enabled, disabled and the status of the
> > + * correction after a read may be retrieved with a NAND command
> > + * (may be vendor specific).
>
> "The on-die correction can be enabled, disabled" -> this is true for
> any kind of ECC engine :P.
>
> > + *
> > + * Besides the initial setup and final cleanups, the interfaces are rather
> > + * simple:
> > + * - "prepare": Prepare an I/O request, check the ECC engine is enabled or
>
> ^if/whether
>
> > + * disabled as requested before the I/O. In case of software
>
> How about "Enable/disable the ECC engine based on the I/O request type."
>
> > + * correction, this step may involve to derive the ECC bytes and
> > + * place them in the OOB area before a write.
>
> This is also true for external hardware ECC engines.
>
> > + * - "finish": Finish an I/O request, check the status of the operation ie.
> > + * the data validity in case of a read (report to the upper layer
> > + * any bitflip/errors).
>
> It's all about correcting/reporting errors, right. Let's try to put
> that into simple words: "Correct the data in case of a read request and
> report the number of corrected bits/uncorrectable errors. Most likely
> empty for write operations, unless you have hardware specific stuff to
> do, like shutting down the engine to save some power"
>
> > + *
> > + * Both prepare/finish callbacks are supposed to enclose I/O request and will
>
> "The I/O request should be enclosed in a prepare()/finish() pair of
> calls" or "The prepare/finish call should surround the I/O request".
>
> > + * behave differently depending on the desired correction:
>
> ^requested I/O type
>
> > + * - "raw": Correction disabled
> > + * - "ecc": Correction enabled
> > + *
> > + * The request direction is impacting the logic as well:
> > + * - "read": Load data from the NAND chip
> > + * - "write": Store data in the NAND chip
> > + *
> > + * Mixing all this combinations together gives the following behavior.
>
> Mention that those are just examples, and drivers are free to add
> custom steps in their prepare/finish hooks.
>
> > + *
> > + * ["external" ECC engine]
> > + * - external + prepare + raw + read: do nothing
> > + * - external + finish + raw + read: do nothing
> > + * - external + prepare + raw + write: do nothing
> > + * - external + finish + raw + write: do nothing
> > + * - external + prepare + ecc + read: do nothing
> > + * - external + finish + ecc + read: calculate expected ECC bytes, extract
> > + * ECC bytes from OOB buffer, correct
> > + * and report any bitflip/error
> > + * - external + prepare + ecc + write: calculate ECC bytes and store them at
> > + * the right place in the OOB buffer based
> > + * on the OOB layout
> > + * - external + finish + ecc + write: do nothing
> > + *
> > + * ["pipelined" ECC engine]
> > + * - pipelined + prepare + raw + read: disable the controller's ECC engine if
> > + * activated
> > + * - pipelined + finish + raw + read: do nothing
> > + * - pipelined + prepare + raw + write: disable the controller's ECC engine if
> > + * activated
> > + * - pipelined + finish + raw + write: do nothing
> > + * - pipelined + prepare + ecc + read: enable the controller's ECC engine if
> > + * deactivated
> > + * - pipelined + finish + ecc + read: check the status, report any
> > + * error/bitflip
> > + * - pipelined + prepare + ecc + write: enable the controller's ECC engine if
> > + * deactivated
> > + * - pipelined + finish + ecc + write: do nothing
> > + *
> > + * ["ondie" ECC engine]
> > + * - ondie + prepare + raw + read: send commands to disable the on-chip ECC
> > + * engine if activated
> > + * - ondie + finish + raw + read: do nothing
> > + * - ondie + prepare + raw + write: send commands to disable the on-chip ECC
> > + * engine if activated
> > + * - ondie + finish + raw + write: do nothing
> > + * - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
> > + * engine if deactivated
> > + * - ondie + finish + ecc + read: send commands to check the status, report
> > + * any error/bitflip
> > + * - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
> > + * engine if deactivated
> > + * - ondie + finish + ecc + write: do nothing
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/mtd/nand.h>
> > +
>
> Shouldn't we have kernel-docs for those functions?
>
> > +int nand_ecc_init_ctx(struct nand_device *nand)
> > +{
> > + if (!nand->ecc.engine->ops->init_ctx)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->init_ctx(nand);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_init_ctx);
> > +
> > +void nand_ecc_cleanup_ctx(struct nand_device *nand)
> > +{
> > + if (nand->ecc.engine->ops->cleanup_ctx)
> > + nand->ecc.engine->ops->cleanup_ctx(nand);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
> > +
> > +int nand_ecc_prepare_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req)
> > +{
> > + if (!nand->ecc.engine->ops->prepare_io_req)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->prepare_io_req(nand, req);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_prepare_io_req);
> > +
> > +int nand_ecc_finish_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req)
> > +{
> > + if (!nand->ecc.engine->ops->finish_io_req)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->finish_io_req(nand, req);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_finish_io_req);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
> > +MODULE_DESCRIPTION("Generic ECC engine");
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index 2e9af24936cd..0be260fd2f86 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -221,6 +221,73 @@ struct nand_ops {
> > bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
> > };
> >
> > +/**
> > + * struct nand_ecc_context - Context for the ECC engine
> > + * @conf: basic ECC engine parameters
> > + * @total: Total number of bytes used for storing ECC codes, this is used by
>
> Sometimes you start your description with an uppercase, sometimes not.
>
> > + * generic OOB layouts
> > + * @priv: ECC engine driver private data
> > + */
> > +struct nand_ecc_context {
> > + struct nand_ecc_props conf;
> > + unsigned int total;
> > + void *priv;
> > +};
> > +
> > +/**
> > + * struct nand_ecc_engine_ops - Generic ECC engine operations
>
> ^s/Generic//
>
> > + * @init_ctx: given a desired user configuration for the pointed NAND device,
> > + * requests the ECC engine driver to setup a configuration with
> > + * values it supports.
> > + * @cleanup_ctx: clean the context initialized by @init_ctx.
> > + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> > + * request to be performed with ECC correction.
> > + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> > + * request and ensure proper ECC correction.
> > + */
> > +struct nand_ecc_engine_ops {
> > + int (*init_ctx)(struct nand_device *nand);
> > + void (*cleanup_ctx)(struct nand_device *nand);
> > + int (*prepare_io_req)(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > + int (*finish_io_req)(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +};
> > +
> > +/**
> > + * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
>
> ^s/Generic//
>
> > + * @ops: ECC engine operations
> > + */
> > +struct nand_ecc_engine {
> > + struct nand_ecc_engine_ops *ops;
> > +};
> > +
> > +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);
> > +
> > +/**
> > + * struct nand_ecc - High-level ECC object
>
> I think you can drop the "High-level" and just say "Information
> relative to the ECC"
>
> > + * @defaults: Default values, depend on the underlying subsystem
> > + * @requirements: ECC requirements from the NAND chip perspective
> > + * @user_conf: User desires in terms of ECC parameters
> > + * @ctx: ECC context for the ECC engine, derived from the device @requirements
> > + * the @user_conf and the @defaults
> > + * @ondie_engine: On-die ECC engine reference, if any
> > + * @engine: ECC engine actually bound
> > + */
> > +struct nand_ecc {
> > + struct nand_ecc_props defaults;
> > + struct nand_ecc_props requirements;
> > + struct nand_ecc_props user_conf;
> > + struct nand_ecc_context ctx;
> > + struct nand_ecc_engine *ondie_engine;
> > + struct nand_ecc_engine *engine;
> > +};
> > +
> > /**
> > * struct nand_device - NAND device
> > * @mtd: MTD instance attached to the NAND device
>
All comments applied.
Thanks,
Miquèl
_______________________________________________
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 v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-28 23:48 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528180003.0f682e6f@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 18:00:03 +0200:
> On Thu, 28 May 2020 13:31:11 +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. Adapt the
> > raw NAND and SPI-NAND cores to fit the change.
>
> I would also split that one:
>
> 1/ s/nand_ecc_props/nand_ecc/ in the core + change the spi nand
> framework accordingly
>
> 2/ update rawnand to use the generic layer
This one I honestly don't understand how to split it. As long as I
change the NAND device object content, I have to update all
raw/spi-NAND devices in the same patch, or I would break the build. As
it there are already many many changes, I did not split this patch.
_______________________________________________
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 3/9] dt-bindings: irq: Add a compatible for the H3 R_INTC
From: Rob Herring @ 2020-05-28 23:50 UTC (permalink / raw)
To: Samuel Holland
Cc: devicetree, Jason Cooper, Marc Zyngier, linux-sunxi, Russell King,
Maxime Ripard, linux-kernel, Chen-Yu Tsai, Rob Herring,
Catalin Marinas, Thomas Gleixner, Will Deacon, linux-arm-kernel
In-Reply-To: <20200525041302.51213-4-samuel@sholland.org>
On Sun, 24 May 2020 23:12:56 -0500, Samuel Holland wrote:
> The Allwinner H3 SoC contains an R_INTC that is, as far as we know,
> compatible with the R_INTC present in other sun8i/sun50i SoCs starting
> with the A31. Since the R_INTC hardware is undocumented, introduce a new
> compatible for the R_INTC variant in this SoC, in case there turns out
> to be some difference.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> .../allwinner,sun7i-a20-sc-nmi.yaml | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* ✅ PASS: Test report for kernel 5.7.0-rc7-4690997.cki (arm-next)
From: CKI Project @ 2020-05-28 23:50 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Commit: 46909976c59d - Merge branch 'for-next/core' into for-kernelci
The results of these automated tests are provided below.
Overall result: PASSED
Merge: OK
Compile: OK
Tests: OK
All kernel binaries, config files, and logs are available for download here:
https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=datawarehouse/2020/05/28/584927
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 1 architecture:
aarch64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ Podman system integration test - as root
✅ Podman system integration test - as user
✅ LTP
✅ Loopdev Sanity
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Networking bridge: sanity
✅ Ethernet drivers sanity
✅ Networking socket: fuzz
✅ Networking: igmp conformance test
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test
✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport
✅ Networking ipsec: basic netns - tunnel
✅ Libkcapi AF_ALG test
✅ pciutils: update pci ids test
✅ ALSA PCM loopback test
✅ ALSA Control (mixer) Userspace Element test
✅ storage: SCSI VPD
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ jvm - DaCapo Benchmark Suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ Networking firewall: basic netfilter test
🚧 ✅ audit: audit testsuite test
🚧 ✅ trace: ftrace/tracer
🚧 ✅ kdump - kexec_boot
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ selinux-policy: serge-testsuite
✅ storage: software RAID testing
🚧 ✅ IPMI driver test
🚧 ✅ IPMItool loop stress test
🚧 ✅ Storage blktests
Test sources: https://github.com/CKI-project/tests-beaker
💚 Pull requests are welcome for new tests or improvements to existing tests!
Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.
Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ⏱.
_______________________________________________
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 v6 18/18] mtd: rawnand: Move generic bits to the ECC framework
From: Miquel Raynal @ 2020-05-28 23:55 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528175656.0a32dd7c@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 17:56:56 +0200:
> On Thu, 28 May 2020 13:31:13 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > +/**
> > + * nanddev_get_flash_node() - Get the device node attached to a NAND device
> > + * @nand: NAND device
> > + *
> > + * Return: the device node linked to @nand.
> > + */
> > +static inline struct device_node *nanddev_get_flash_node(struct nand_device *nand)
> > +{
> > + return mtd_get_of_node(nanddev_to_mtd(nand));
> > +}
> > +
>
> Can we name that one nanddev_get_of_node(). We'll probably want to
> expose fwnode at some point, and get_flash_node() is a bit too generic
> IMO.
I just spot that there is a nanddev_get_of_node() function already,
which does exactly the same as nanddev_get_flash_node(), so I just
dropped it.
_______________________________________________
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 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Suman Anna @ 2020-05-29 0:23 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
linux-kernel, Bjorn Andersson, linux-arm-kernel
In-Reply-To: <594b649d-eca6-1cd4-3621-c8297a6a9492@ti.com>
Hi Rob,
On 5/28/20 5:47 PM, Suman Anna wrote:
> Hi Rob,
>
> On 5/28/20 5:32 PM, Rob Herring wrote:
>> On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
>>> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
>>> Processor (DSP) subsystems that are comprised of either a TMS320C66x
>>> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
>>> Add the device tree bindings document for the C66x DSP devices on these
>>> SoCs. The added example illustrates the DT nodes for the first C66x DSP
>>> device present on the K3 J721E family of SoCs.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>> v2:
>>> - Updated the example to include the root-node to fix the bot
>>> errors from v1
>>
>> Pretty sure that was not why you had errors.
>
> It is because of the default values used for #address-cells and
> #size-cells in the example_template and example_start variables used in
> the dt-extract-example script. They are 1 by default, so the generated
> template ended up with the root-node using 1, and the actual example
> using 2 resulting in the mismatch.
>
> When I updated the script to use 2 for both #address-cells and
> #size-cells, then the warnings go away. This is the reason, dtbs_check
> on my actual dts files goes through fine.
Just to clarify, the warnings were only because of the mismatched
'ranges'. If I limit the example to just the dsp node, eliminating all
ranges usage, then it passes fine.
So, you would see this with any example that uses ranges with
#address-cells and #size-cells as 2 without explicitly using the
appropriate top-level #address-cells and #size-cells.
>
>>
>>> - Added maxItems to resets, mboxes, memory-region, sram properties
>>> - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
>>> - Addressed the minor review comments from Mathieu
>>> v1: https://patchwork.kernel.org/patch/11458571/
>>>
>>> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
>>> 1 file changed, 190 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>> b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>> new file mode 100644
>>> index 000000000000..cdf649655838
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>> @@ -0,0 +1,190 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: TI K3 DSP devices
>>> +
>>> +maintainers:
>>> + - Suman Anna <s-anna@ti.com>
>>> +
>>> +description: |
>>> + The TI K3 family of SoCs usually have one or more TI DSP Core
>>> sub-systems
>>> + that are used to offload some of the processor-intensive tasks or
>>> algorithms,
>>> + for achieving various system level goals.
>>> +
>>> + These processor sub-systems usually contain additional sub-modules
>>> like
>>> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external
>>> memory
>>> + controller, a dedicated local power/sleep controller etc. The DSP
>>> processor
>>> + cores in the K3 SoCs are usually either a TMS320C66x CorePac
>>> processor or a
>>> + TMS320C71x CorePac processor.
>>> +
>>> + Each DSP Core sub-system is represented as a single DT node. Each
>>> node has a
>>> + number of required or optional properties that enable the OS
>>> running on the
>>> + host processor (Arm CorePac) to perform the device management of
>>> the remote
>>> + processor and to communicate with the remote processor.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: ti,j721e-c66-dsp
>>> + description:
>>> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
>>
>> What else are you going to use? There's only one compatible string. Drop
>> description.
>
> Is updated in a subsequent binding update where I added the C71 support.
See https://patchwork.kernel.org/patch/11563231/.
Let me know if you prefer that I combine both of them. Any changes to
this patch will also affect the other.
>
>>
>>> +
>>> + reg:
>>> + description: |
>>> + Should contain an entry for each value in 'reg-names'.
>>> + Each entry should have the memory region's start address
>>> + and the size of the region, the representation matching
>>> + the parent node's '#address-cells' and '#size-cells' values.
>>
>> Don't need generic descriptions. That's every 'reg'.
>>
>> What you can do is an 'items' list describing what each region is.
>
> OK, I am bit confused here. I have listed the items under the reg-names,
> while using just the minItems or maxItems here. What is the convention,
> aren't reg and reg-names associative.
>
>>
>>> + minItems: 3
>>> + maxItems: 3
>>> +
>>> + reg-names:
>>> + description: |
>>> + Should contain strings with the names of the specific internal
>>> + memory regions, and should be defined in this order
>>
>> Again, drop.
>
> OK
>
>>
>>> + maxItems: 3
>>> + items:
>>> + - const: l2sram
>>> + - const: l1pram
>>> + - const: l1dram
>>> +
>>> + ti,sci:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description:
>>> + Should be a phandle to the TI-SCI System Controller node
>>> +
>>> + ti,sci-dev-id:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + description: |
>>> + Should contain the TI-SCI device id corresponding to the DSP
>>> core.
>>> + Please refer to the corresponding System Controller documentation
>>> + for valid values for the DSP cores.
>>> +
>>> + ti,sci-proc-ids:
>>> + description: Should contain a single tuple of <proc_id host_id>.
>>> + allOf:
>>> + - $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + - maxItems: 1
>>> + items:
>>> + items:
>>> + - description: TI-SCI processor id for the DSP core device
>>> + - description: TI-SCI host id to which processor control
>>> + ownership should be transferred to
>>
>> I assume these properties appear in multiple TI nodes? We don't need
>> them defined multiple times. Create a schema for them that you can
>> include here.
>
> Only the remoteprocs, so they are limited to this binding and one more
> R5F remoteproc binding.
Can you confirm if these are the properties you want moved - ti,sci,
ti,sci-dev-id and ti,sci-proc-ids? Any recommended path I should be
using, is remoteproc folder still fine for this?
regards
Suman
>
>>
>>> +
>>> + resets:
>>> + description: |
>>> + Should contain the phandle to the reset controller node
>>> + managing the local resets for this device, and a reset
>>> + specifier. Please refer to the following reset bindings
>>> + for the reset argument specifier,
>>> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>>
>> Drop.
>
> Entire description or just the reference to the reset bindings file?
>
>>
>>> + maxItems: 1
>>> +
>>> + firmware-name:
>>> + description: |
>>> + Should contain the name of the default firmware image
>>> + file located on the firmware search path
>>> +
>>> + mboxes:
>>> + description: |
>>> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
>>> + communication with the remote processor. This property should
>>> match
>>> + with the sub-mailbox node used in the firmware image. The
>>> specifier
>>> + format is as per the bindings,
>>> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>>
>> Drop. What mailbox provider is used is outside the scope of this
>> binding.
>
> OK.
>
>>
>>> + maxItems: 1
>>> +
>>> + memory-region:
>>> + minItems: 2
>>> + maxItems: 8
>>> + description: |
>>> + phandle to the reserved memory nodes to be associated with the
>>> remoteproc
>>> + device. There should be at least two reserved memory nodes
>>> defined - the
>>> + first one would be used for dynamic DMA allocations like
>>> vrings and vring
>>> + buffers, and the remaining ones used for the firmware image
>>> sections. The
>>> + reserved memory nodes should be carveout nodes, and should be
>>> defined as
>>> + per the bindings in
>>> +
>>> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>>
>> items:
>> - description: dynamic DMA allocations like vrings and vring buffers
>> - description: firmware image section ???
>> - description: firmware image section ???
>
> Yeah, this is scalable if we will have multiple separate DDR regions. I
> had to choose a decent maxItems value, so I chose 8. Wouldn't listing
> the individual items override the number of minItems/maxItems?
>
>>
>>> +
>>> +# Optional properties:
>>> +# --------------------
>>> +
>>> + sram:
>>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>>> + minItems: 1
>>> + maxItems: 4
>>> + description: |
>>> + phandles to one or more reserved on-chip SRAM regions. The
>>> regions
>>> + should be defined as child nodes of the respective SRAM node, and
>>> + should be defined as per the generic bindings in,
>>> + Documentation/devicetree/bindings/sram/sram.yaml
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - reg-names
>>> + - ti,sci
>>> + - ti,sci-dev-id
>>> + - ti,sci-proc-ids
>>> + - resets
>>> + - firmware-name
>>> + - mboxes
>>> + - memory-region
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + / {
>>> + model = "Texas Instruments K3 J721E SoC";
>>> + compatible = "ti,j721e";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + /* DSP Carveout reserved memory nodes */
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
>>> + compatible = "shared-dma-pool";
>>> + reg = <0x00 0xa6000000 0x00 0x100000>;
>>> + no-map;
>>> + };
>>> +
>>> + c66_0_memory_region: c66-memory@a6100000 {
>>> + compatible = "shared-dma-pool";
>>> + reg = <0x00 0xa6100000 0x00 0xf00000>;
>>> + no-map;
>>> + };
>>> + };
>>
>> Drop all of this. Outside the scope of this binding. And will likely
>> start failing validation as schemas become more complete.
>
> This is a complete example because of the memory-region references below.
>
>>
>>> +
>>> + cbass_main: bus@100000 {
>>
>> Drop unused labels.
>
> OK.
>
> regards
> Suman
>
>>
>>> + compatible = "simple-bus";
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges = <0x00 0x00100000 0x00 0x00100000 0x00
>>> 0x00020000>, /* ctrl mmr */
>>> + <0x4d 0x80800000 0x4d 0x80800000 0x00
>>> 0x00800000>, /* C66_0 */
>>> + <0x4d 0x81800000 0x4d 0x81800000 0x00
>>> 0x00800000>; /* C66_1 */
>>> +
>>> + /* J721E C66_0 DSP node */
>>> + c66_0: dsp@4d80800000 {
>>> + compatible = "ti,j721e-c66-dsp";
>>> + reg = <0x4d 0x80800000 0x00 0x00048000>,
>>> + <0x4d 0x80e00000 0x00 0x00008000>,
>>> + <0x4d 0x80f00000 0x00 0x00008000>;
>>> + reg-names = "l2sram", "l1pram", "l1dram";
>>> + ti,sci = <&dmsc>;
>>> + ti,sci-dev-id = <142>;
>>> + ti,sci-proc-ids = <0x03 0xFF>;
>>> + resets = <&k3_reset 142 1>;
>>> + firmware-name = "j7-c66_0-fw";
>>> + memory-region = <&c66_0_dma_memory_region>,
>>> + <&c66_0_memory_region>;
>>> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
>>> + };
>>> + };
>>> + };
>>> --
>>> 2.26.0
>>>
>
_______________________________________________
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 0/8] Convert the intel iommu driver to the dma-iommu api
From: Logan Gunthorpe @ 2020-05-29 0:00 UTC (permalink / raw)
To: Tom Murphy, iommu
Cc: kvm, David Airlie, dri-devel, Bjorn Andersson, Matthias Brugger,
Julien Grall, Thierry Reding, Will Deacon, Marek Szyprowski,
Jean-Philippe Brucker, linux-samsung-soc, Marc Zyngier,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Andy Gross,
Gerald Schaefer, linux-s390, linux-arm-msm, intel-gfx, Eric Auger,
Alex Williamson, linux-mediatek, Rodrigo Vivi, linux-tegra,
Thomas Gleixner, virtualization, linux-arm-kernel, Robin Murphy,
Cornelia Huck, linux-kernel, Kukjin Kim, David Woodhouse,
Lu Baolu
In-Reply-To: <20191221150402.13868-1-murphyt7@tcd.ie>
Hi Tom,
On 2019-12-21 8:03 a.m., Tom Murphy wrote:
> This patchset converts the intel iommu driver to the dma-iommu api.
Just wanted to note that I've rebased your series on recent kernels and
have done some testing on my old Sandybridge machine (without the DO NOT
MERGE patch) and have found no issues. I hope this can make progress
soon and get merged soon. If you like you can add:
Tested-By: Logan Gunthorpe <logang@deltatee.com>
> While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here:
> https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg
>
> This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here:
> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51
>
> Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately.
I did some digging into this myself and while I don't have full patch, I
think I traced it closer to the problem.
Sadly, ignoring the number of nents returned by map_sg() is endemic to
dma-buf users, but AMD's GPU driver seems to do the same thing,
presumably without issues.
Digging a bit further, I found that the i915 has an "innovative" way of
iterating through SGLs, see [1]. I suspect if __sgt_iter is changed to
increment with sg_dma_len() and return NULL when there is no length
left, it may fix the issue.
But, sorry, I don't really have the means or time to fix and test this
myself.
Thanks,
Logan
[1]
https://elixir.bootlin.com/linux/v5.7-rc7/source/drivers/gpu/drm/i915/i915_scatterlist.h#L76
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 00/20] Introduce the generic ECC engine abstraction
From: Miquel Raynal @ 2020-05-29 0:24 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
As of today, only raw NAND controllers used to feature an integrated
ECC engine and so controller drivers always embedded some code to
enable/disable the correction.
This statement is no longer correct as SPI-NAND devices might not
embed an on-die ECC engine and must make use of an external ECC
engine. We figured there are three possible situations for (generic)
NAND devices: either the engine is 'on-die' (most of the SPI-NANDs, a
few raw NANDs), or the engine is part of the host controller (most raw
NANDs), or the engine may be external (SPI controllers might feature
an hardware ECC engine, otherwise software correction can also be
used).
To solve this situation, I already proposed the creation of an ECC
engine abstraction (still work in progress) and this is the first step
for that.
The logic in this series is:
1/ Use the generic NAND core for all NAND devices (raw and SPI).
2/ Create the ECC engine interface in drivers/mtd/nand/ecc.c
3/ Move code in driver/mtd/nand/ecc.c
Later, I will repost:
4/ Make both software engines (Hamming and BCH) generic, move them in
the ecc/ directory, clean them a bit and instantiate ECC
engines. Write raw NAND helpers to use these two new engines.
5/ Isolate SPI-NAND on-die ECC engine in its own driver.
6/ Make use from the SPI-NAND layer of all the ECC engines listed
above (on user request, people can now make use of soft BCH if they
don't have an ECC-engine).
7/ Extend the logic to hardware external engines. A proposal of a
driver for Macronix external ECC engine will follow in another
series.
This work is now almost ready, the next steps will be:
1/ Migrate the raw NAND core to make a proper use of these ECC
engines.
2/ Deprecate in the raw NAND subsystem the interfaces used until now
(I expect we should get rid of a lot of boilerplate).
Thanks,
Miquèl
Changes in v7
=============
* Collected tags.
* Fixed subjects s/OOB placement/ECC bytes placement/.
* Moved a tab change into space to the appropriate patch.
* Moved the removal of the nand_ecc_mode public enumumeration to the
right patch.
* Created helpers to retrieve the OOB layouts.
* Moved the "flags" entry of nand_ecc_props to the commit using it.
* Changed the select MTD_NAND_CORE into a depends on and moved it to
the right patch too.
* Split the patch moving raw NAND bits into the ECC framework.
* Dropped an extra helper: nanddev_get_flash_node().
* Updated all the ECC framework introductory comment, following Boris'
suggestions.
Changes in v6
=============
* Rebased on top of nand/next.
* Dropped the new nand-ecc-provider property. Instead, we will use
nand-ecc-engine and boolean properties like nand-no-ecc-engine /
nand-use-soft-ecc-engine (will be added in another series).
* Moved most of the bindings to the next series.
* Used platform_dev_put() instead of of_dev_put() on Rob's advice.
* Renamed objects: ondie -> on_die_hw.
* Renamed objects: hw -> on_host_hw.
* Used engine_type everywhere instead of provider.
* Created a rawnand compatibility layer to avoid moving deprecated
code due to the rawnand core history in the generic (and clean) NAND
layer.
* Enhanced the nand_ecc_algo enumeration.
Changes in v5
=============
* Rebased on top of nand/next
* Avoided a fallthrough situation in commit:
mtd: rawnand: Separate the ECC engine type and the OOB placement
* Fixed an of_dev_put() build issue due to a missing dummy helper.
* Extracted a patch that deserved to be merged quickly.
* Fixed a few issues reported by robots.
Changes in v4
=============
* Rebased on top of a recent kernel version.
* Added Boris' reviewed-by.
* Added Maxime's Acked-by tag.
* Added the missing of_device.h header to ecc.c.
* Corrected a 'minimum' comparison by using min_t.
* Updated the new Macronix raw NAND controller driver by using the new
(ECC related) function names.
* Fixed a function call in ndfc.c.
* Update brcmnand.c file to fit new enumerations and structures (due
to recent Kamal's changes).
* Force sm_ftl to depends on the Hamming engine, because by just
selecting it the ECC code would be embedded in the NAND core and the
NAND core might not be compiled in with sm_ftl.
* Fixed a structure field name that I previously added in davinci
platform data.
* Moved the oob_first placement scheme to Davinci driver. Removed any
occurence of it out of the driver (unused).
* Simplify structure names as proposed by Boris.
* Change enumeration/string names about ECC engine
providers/placements.
* Change the logic in the of_get_nand_ecc_* helpers to ensure backward
compatibility.
* Use enums intead of unsigned integers in the core when referring to
ECC engine type, placement and algorithm.
* Add nand-ecc-placement DT property.
* Deprecate hw_syndrome.
* Deprecate nand-ecc-mode in favor of nand-ecc-provider.
* Fixed a typo in the Macronix ECC driver, where I made a copy/paste
error which I haven't spotted because it is located in a macro only
compiled when building the driver as a module (name of the of_ids
was prefixed marvell_nfc instead of mxic_ecc).
* Simplified the ECC engine API by dropping the useless oobbuf
parameter. Instead, ECC engine drivers are supposed to provide a
spare OOB buffer if none is provided. Updated the three existing
engines.
* Fixed BCH software engine with the help of Mason from Macronix.
* Added a mechanism called "tweaking req" to change the SPI-NAND
requests and ensure they always contain the right amount of data/OOB
needed for the ECC engine to work properly.
Changes in v3
=============
* Added Boris' Reviewed-by tags.
* Added a kernel doc header on the nand_page_io_req enumeration.
* Added support for HW engines.
* Droped the patch clarifying the value of the first entry in
enumerations (which is always 0).
* Rename the nand_ecc_conf structure as nand_ecc_props because the
_conf suffix implies that it is possible to edit it, while in some
cases (eg. on-die ECC) there is nothing to tweak.
* Smoother introduction of the ECC engine abstraction.
* Renamed the ECC engine module nand_ecc_engine.ko.
* Moved all the ECC files into drivers/mtd/nand/. Forgot the ecc/
subdirectory.
* Added a new series to drop the ECC mode enumeration wich mixes the
provider (none, hw, sw, on-die) and the OOB placement (first,
syndrome).
* Various typos fixed.
* Added a few patches to fix bugs found in SPI-NAND/mtdchar.c.
* Introduced the external hardware ECC engine boilerplate.
Changes in v2
=============
* SPDX license identifiers for soft BCH and Hamming: the license macro
was right, "GPL" means "GPLv2 or higher", so do not change this
portion. Also update the commit messages to fit the actual change.
* Do not compile-in the NAND core by default, do it only for raw
NAND. Remove the dependencies on CONFIG_MTD in a different
patch. Also, keep an extra level of hierarchy in Kconfig for the
NAND bits by adding a menu instead of a config.
* Moved the standard OOB layouts in the ecc/engine.c driver instead of
in the NAND core.
* Used the nand_ecc_ prefix in most of the engines functions instead
of just ecc_, which is now reserved for bare helpers. Get rid of the
__ecc prefix.
* In the sunxi NAND controller driver: moved the ECC structure from
sunxi_nfc to sunxi_nand_chip as the ECC engine is per-chip and not
per controller.
* Software Hamming ECC engine is only enabled by default if raw NAND
is also enabled. NDFC now selects the software Hamming ECC engine
(instead of depending on it).
* Mention in software BCH and Hamming Kconfig entries that booting
from NAND is very likely to fail if the user selects these symbols
as modules.
* Added Boris Reviewed-by tag on the SPI-NAND typo fixing patch.
* Renamed the "mode" into a "provider" entry in the ECC configuration
structures.
* Moved the "total" entry of the ECC configuration directly in the
context structure (should probably not be public but let's keep it
as is for now).
* Split the generic ECC engine introduction into smaller patches to do
some renaming aside.
* Drop the "maximize" entry in the ECC engine configuration structure,
keep using a flag like before.
* Canceled the move of the SPI-NAND specific ECC engine out of the
core file.
* Amended the root ECC structures to have three nand_ecc_conf
structures: one for the defaults, one for the chip requirements, one
for the user desires.
* Created a *ondie_engine pointer in the nand_ecc structure to save
the on-die ECC engine, if any. For instance, saving a reference to
this engine is done by the SPI-NAND core.
* Dropped the SPI-NAND flag that was used to distinguish between NAND
flavors from the NAND core, it should not be needed anymore.
* Added an helper in the NAND core to put a reference on an ECC
engine. This will be used by the hardware engines only.
* Renamed the files ecc/sw-{bch,hamming}.c and their headers
include/linux/mtd/nand-ecc-sw-{bch,hamming}-engine.h.
* Created a MTD_NAND_ECC invisible Kconfig symbol.
* Added plenty of missing EXPORT_SYMBOL{,_GPL}().
* Minor modifications so that everything still compiles even when
modules and built-in drivers are mixed in Kconfig in the whole NAND
directory.
Miquel Raynal (20):
dt-bindings: mtd: Document nand-ecc-placement
mtd: rawnand: Create a new enumeration to describe ECC bytes placement
mtd: rawnand: Separate the ECC engine type and the ECC byte placement
mtd: rawnand: Create a helper to retrieve the ECC placement
mtd: rawnand: Add a kernel doc to the ECC algorithm enumeration
mtd: rawnand: Rename the ECC algorithm enumeration items
mtd: rawnand: Create a new enumeration to describe properly ECC types
mtd: rawnand: Use the new ECC engine type enumeration
mtd: nand: Move nand_device forward declaration to the top
mtd: nand: Add an extra level in the Kconfig hierarchy
mtd: nand: Drop useless 'depends on' in Kconfig
mtd: nand: Add a NAND page I/O request type
mtd: nand: Rename a core structure
mtd: nand: Add more parameters to the nand_ecc_props structure
mtd: nand: Introduce the ECC engine abstraction
mtd: nand: Convert generic NAND bits to use the ECC framework
mtd: rawnand: Hide the generic OOB layout objects behind helpers
mtd: rawnand: Write a compatibility layer
mtd: rawnand: Move generic OOB layouts to the ECC framework
mtd: rawnand: Move the user input parsing bits to the ECC framework
.../bindings/mtd/nand-controller.yaml | 10 +
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-da850-evm.c | 2 +-
arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
arch/arm/mach-davinci/board-dm355-leopard.c | 3 +-
arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/board-mityomapl138.c | 2 +-
arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
arch/arm/mach-s3c24xx/common-smdk.c | 2 +-
arch/arm/mach-s3c24xx/mach-anubis.c | 2 +-
arch/arm/mach-s3c24xx/mach-at2440evb.c | 2 +-
arch/arm/mach-s3c24xx/mach-bast.c | 2 +-
arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
arch/arm/mach-s3c24xx/mach-mini2440.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
arch/arm/mach-s3c24xx/mach-qt2410.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx1950.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx3715.c | 2 +-
arch/arm/mach-s3c24xx/mach-vstms.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-real6410.c | 2 +-
drivers/mtd/nand/Kconfig | 13 +
drivers/mtd/nand/Makefile | 2 +
drivers/mtd/nand/ecc.c | 471 +++++++++++++++
drivers/mtd/nand/onenand/Kconfig | 1 -
drivers/mtd/nand/raw/Kconfig | 2 +-
drivers/mtd/nand/raw/ams-delta.c | 4 +-
drivers/mtd/nand/raw/arasan-nand-controller.c | 16 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 30 +-
drivers/mtd/nand/raw/au1550nd.c | 4 +-
.../mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c | 3 +-
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 27 +-
.../mtd/nand/raw/cadence-nand-controller.c | 4 +-
drivers/mtd/nand/raw/cafe_nand.c | 3 +-
drivers/mtd/nand/raw/cs553x_nand.c | 2 +-
drivers/mtd/nand/raw/davinci_nand.c | 38 +-
drivers/mtd/nand/raw/denali.c | 6 +-
drivers/mtd/nand/raw/diskonchip.c | 3 +-
drivers/mtd/nand/raw/fsl_elbc_nand.c | 20 +-
drivers/mtd/nand/raw/fsl_ifc_nand.c | 12 +-
drivers/mtd/nand/raw/fsl_upm.c | 4 +-
drivers/mtd/nand/raw/fsmc_nand.c | 14 +-
drivers/mtd/nand/raw/gpio.c | 4 +-
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 14 +-
drivers/mtd/nand/raw/hisi504_nand.c | 6 +-
.../mtd/nand/raw/ingenic/ingenic_nand_drv.c | 20 +-
drivers/mtd/nand/raw/lpc32xx_mlc.c | 2 +-
drivers/mtd/nand/raw/lpc32xx_slc.c | 3 +-
drivers/mtd/nand/raw/marvell_nand.c | 34 +-
drivers/mtd/nand/raw/meson_nand.c | 2 +-
drivers/mtd/nand/raw/mpc5121_nfc.c | 4 +-
drivers/mtd/nand/raw/mtk_nand.c | 10 +-
drivers/mtd/nand/raw/mxc_nand.c | 25 +-
drivers/mtd/nand/raw/nand_base.c | 565 +++++++-----------
drivers/mtd/nand/raw/nand_esmt.c | 11 +-
drivers/mtd/nand/raw/nand_hynix.c | 41 +-
drivers/mtd/nand/raw/nand_jedec.c | 4 +-
drivers/mtd/nand/raw/nand_micron.c | 20 +-
drivers/mtd/nand/raw/nand_onfi.c | 8 +-
drivers/mtd/nand/raw/nand_samsung.c | 19 +-
drivers/mtd/nand/raw/nand_toshiba.c | 16 +-
drivers/mtd/nand/raw/nandsim.c | 8 +-
drivers/mtd/nand/raw/ndfc.c | 2 +-
drivers/mtd/nand/raw/omap2.c | 22 +-
drivers/mtd/nand/raw/orion_nand.c | 4 +-
drivers/mtd/nand/raw/pasemi_nand.c | 4 +-
drivers/mtd/nand/raw/plat_nand.c | 4 +-
drivers/mtd/nand/raw/qcom_nandc.c | 2 +-
drivers/mtd/nand/raw/r852.c | 3 +-
drivers/mtd/nand/raw/s3c2410.c | 20 +-
drivers/mtd/nand/raw/sh_flctl.c | 6 +-
drivers/mtd/nand/raw/sharpsl.c | 2 +-
drivers/mtd/nand/raw/socrates_nand.c | 5 +-
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 9 +-
drivers/mtd/nand/raw/sunxi_nand.c | 26 +-
drivers/mtd/nand/raw/tango_nand.c | 4 +-
drivers/mtd/nand/raw/tegra_nand.c | 34 +-
drivers/mtd/nand/raw/tmio_nand.c | 2 +-
drivers/mtd/nand/raw/txx9ndfmc.c | 2 +-
drivers/mtd/nand/raw/vf610_nfc.c | 6 +-
drivers/mtd/nand/raw/xway_nand.c | 4 +-
drivers/mtd/nand/spi/core.c | 12 +-
drivers/mtd/nand/spi/macronix.c | 6 +-
drivers/mtd/nand/spi/toshiba.c | 6 +-
include/linux/mtd/nand.h | 164 ++++-
include/linux/mtd/rawnand.h | 34 +-
include/linux/mtd/spinand.h | 2 +-
include/linux/platform_data/mtd-davinci.h | 9 +-
.../linux/platform_data/mtd-nand-s3c2410.h | 2 +-
94 files changed, 1221 insertions(+), 731 deletions(-)
create mode 100644 drivers/mtd/nand/ecc.c
--
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
* [PATCH v7 01/20] dt-bindings: mtd: Document nand-ecc-placement
From: Miquel Raynal @ 2020-05-29 0:24 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
This optional property defines where the ECC bytes are expected to be
stored. No value defaults to an unknown location, while these
locations can be explicitly set to OOB or interleaved depending if
the ECC bytes are entirely stored in the OOB area or mixed with
regular data in the main area (also sometimes referred as
"syndrome").
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
.../devicetree/bindings/mtd/nand-controller.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index d261b7096c69..4a0798247d2d 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -56,6 +56,16 @@ patternProperties:
(Linux will handle the calculations). soft_bch is deprecated
and should be replaced by soft and nand-ecc-algo.
+ nand-ecc-placement:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ - enum: [ oob, interleaved ]
+ description:
+ Location of the ECC bytes. This location is unknown by default
+ but can be explicitly set to "oob", if all ECC bytes are
+ known to be stored in the OOB area, or "interleaved" if ECC
+ bytes will be interleaved with regular data in the main area.
+
nand-ecc-algo:
allOf:
- $ref: /schemas/types.yaml#/definitions/string
--
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 v7 02/20] mtd: rawnand: Create a new enumeration to describe ECC bytes placement
From: Miquel Raynal @ 2020-05-29 0:24 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
There is currently a confusion between the ECC type/mode/provider
(eg. on-host, software, on-die or none) and the ECC bytes placement.
Create a new enumeration to describe this placement.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/nand/raw/nand_base.c | 5 +++++
include/linux/mtd/rawnand.h | 14 ++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index bd3f5a875e39..4d2d444f9db9 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5018,6 +5018,11 @@ static const char * const nand_ecc_modes[] = {
[NAND_ECC_ON_DIE] = "on-die",
};
+static const char * const nand_ecc_placement[] = {
+ [NAND_ECC_PLACEMENT_OOB] = "oob",
+ [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved",
+};
+
static int of_get_nand_ecc_mode(struct device_node *np)
{
const char *pm;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 65b1c1c18b41..5e014807e050 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -92,6 +92,20 @@ enum nand_ecc_mode {
NAND_ECC_ON_DIE,
};
+/**
+ * enum nand_ecc_placement - NAND ECC bytes placement
+ * @NAND_ECC_PLACEMENT_UNKNOWN: The actual position of the ECC bytes is unknown
+ * @NAND_ECC_PLACEMENT_OOB: The ECC bytes are located in the OOB area
+ * @NAND_ECC_PLACEMENT_INTERLEAVED: Syndrome layout, there are ECC bytes
+ * interleaved with regular data in the main
+ * area
+ */
+enum nand_ecc_placement {
+ NAND_ECC_PLACEMENT_UNKNOWN,
+ NAND_ECC_PLACEMENT_OOB,
+ NAND_ECC_PLACEMENT_INTERLEAVED,
+};
+
enum nand_ecc_algo {
NAND_ECC_UNKNOWN,
NAND_ECC_HAMMING,
--
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 v7 03/20] mtd: rawnand: Separate the ECC engine type and the ECC byte placement
From: Miquel Raynal @ 2020-05-29 0:25 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
The use of "syndrome" placement should not be encoded in the ECC
engine mode/type.
Create a "placement" field in NAND chip and change all occurrences of
the NAND_ECC_HW_SYNDROME enumeration to be just NAND_ECC_HW and
possibly a placement entry like NAND_ECC_PLACEMENT_INTERLEAVED.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
arch/arm/mach-davinci/board-dm355-leopard.c | 3 +-
drivers/mtd/nand/raw/cafe_nand.c | 3 +-
drivers/mtd/nand/raw/davinci_nand.c | 5 +-
drivers/mtd/nand/raw/denali.c | 3 +-
drivers/mtd/nand/raw/diskonchip.c | 3 +-
drivers/mtd/nand/raw/lpc32xx_slc.c | 3 +-
drivers/mtd/nand/raw/nand_base.c | 109 +++++++++++---------
drivers/mtd/nand/raw/r852.c | 3 +-
include/linux/mtd/rawnand.h | 6 +-
include/linux/platform_data/mtd-davinci.h | 1 +
10 files changed, 81 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
index b9e9950dd300..4c8a592754ac 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -76,7 +76,8 @@ static struct davinci_nand_pdata davinci_nand_data = {
.mask_chipsel = BIT(14),
.parts = davinci_nand_partitions,
.nr_parts = ARRAY_SIZE(davinci_nand_partitions),
- .ecc_mode = NAND_ECC_HW_SYNDROME,
+ .ecc_mode = NAND_HW_ECC_ENGINE,
+ .ecc_placement = NAND_ECC_PLACEMENT_INTERLEAVED,
.ecc_bits = 4,
.bbt_options = NAND_BBT_USE_FLASH,
};
diff --git a/drivers/mtd/nand/raw/cafe_nand.c b/drivers/mtd/nand/raw/cafe_nand.c
index 92173790f20b..2bf8ab542e38 100644
--- a/drivers/mtd/nand/raw/cafe_nand.c
+++ b/drivers/mtd/nand/raw/cafe_nand.c
@@ -629,7 +629,8 @@ static int cafe_nand_attach_chip(struct nand_chip *chip)
goto out_free_dma;
}
- cafe->nand.ecc.mode = NAND_ECC_HW_SYNDROME;
+ cafe->nand.ecc.mode = NAND_ECC_HW;
+ cafe->nand.ecc.placement = NAND_ECC_PLACEMENT_INTERLEAVED;
cafe->nand.ecc.size = mtd->writesize;
cafe->nand.ecc.bytes = 14;
cafe->nand.ecc.strength = 4;
diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
index d975a62caaa5..2e5d6c113b56 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -168,7 +168,7 @@ static int nand_davinci_correct_1bit(struct nand_chip *chip, u_char *dat,
/*
* 4-bit hardware ECC ... context maintained over entire AEMIF
*
- * This is a syndrome engine, but we avoid NAND_ECC_HW_SYNDROME
+ * This is a syndrome engine, but we avoid NAND_ECC_PLACEMENT_INTERLEAVED
* since that forces use of a problematic "infix OOB" layout.
* Among other things, it trashes manufacturer bad block markers.
* Also, and specific to this hardware, it ECC-protects the "prepad"
@@ -851,6 +851,7 @@ static int nand_davinci_probe(struct platform_device *pdev)
/* Use board-specific ECC config */
info->chip.ecc.mode = pdata->ecc_mode;
+ info->chip.ecc.placement = pdata->ecc_placement;
spin_lock_irq(&davinci_nand_lock);
@@ -897,7 +898,7 @@ static int nand_davinci_remove(struct platform_device *pdev)
int ret;
spin_lock_irq(&davinci_nand_lock);
- if (info->chip.ecc.mode == NAND_ECC_HW_SYNDROME)
+ if (info->chip.ecc.placement == NAND_ECC_PLACEMENT_INTERLEAVED)
ecc4_busy = false;
spin_unlock_irq(&davinci_nand_lock);
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 4e6e1578aa2d..514a97ea4450 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1237,7 +1237,8 @@ int denali_chip_init(struct denali_controller *denali,
chip->bbt_options |= NAND_BBT_USE_FLASH;
chip->bbt_options |= NAND_BBT_NO_OOB;
chip->options |= NAND_NO_SUBPAGE_WRITE;
- chip->ecc.mode = NAND_ECC_HW_SYNDROME;
+ chip->ecc.mode = NAND_ECC_HW;
+ chip->ecc.placement = NAND_ECC_PLACEMENT_INTERLEAVED;
chip->ecc.read_page = denali_read_page;
chip->ecc.write_page = denali_write_page;
chip->ecc.read_page_raw = denali_read_page_raw;
diff --git a/drivers/mtd/nand/raw/diskonchip.c b/drivers/mtd/nand/raw/diskonchip.c
index 43721863a0d8..40360352136b 100644
--- a/drivers/mtd/nand/raw/diskonchip.c
+++ b/drivers/mtd/nand/raw/diskonchip.c
@@ -1456,7 +1456,8 @@ static int __init doc_probe(unsigned long physadr)
nand->ecc.calculate = doc200x_calculate_ecc;
nand->ecc.correct = doc200x_correct_data;
- nand->ecc.mode = NAND_ECC_HW_SYNDROME;
+ nand->ecc.mode = NAND_ECC_HW;
+ nand->ecc.placement = NAND_ECC_PLACEMENT_INTERLEAVED;
nand->ecc.size = 512;
nand->ecc.bytes = 6;
nand->ecc.strength = 2;
diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
index b151fd000815..ccb189c8e343 100644
--- a/drivers/mtd/nand/raw/lpc32xx_slc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
@@ -881,7 +881,8 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, host);
/* NAND callbacks for LPC32xx SLC hardware */
- chip->ecc.mode = NAND_ECC_HW_SYNDROME;
+ chip->ecc.mode = NAND_ECC_HW;
+ chip->ecc.placement = NAND_ECC_PLACEMENT_INTERLEAVED;
chip->legacy.read_byte = lpc32xx_nand_read_byte;
chip->legacy.read_buf = lpc32xx_nand_read_buf;
chip->legacy.write_buf = lpc32xx_nand_write_buf;
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 4d2d444f9db9..9fbd2a474b62 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5772,61 +5772,74 @@ static int nand_scan_tail(struct nand_chip *chip)
switch (ecc->mode) {
case NAND_ECC_HW:
- /* Use standard hwecc read page function? */
- if (!ecc->read_page)
- ecc->read_page = nand_read_page_hwecc;
- if (!ecc->write_page)
- ecc->write_page = nand_write_page_hwecc;
- if (!ecc->read_page_raw)
- ecc->read_page_raw = nand_read_page_raw;
- if (!ecc->write_page_raw)
- ecc->write_page_raw = nand_write_page_raw;
- if (!ecc->read_oob)
- ecc->read_oob = nand_read_oob_std;
- if (!ecc->write_oob)
- ecc->write_oob = nand_write_oob_std;
- if (!ecc->read_subpage)
- ecc->read_subpage = nand_read_subpage;
- if (!ecc->write_subpage && ecc->hwctl && ecc->calculate)
- ecc->write_subpage = nand_write_subpage_hwecc;
- fallthrough;
- case NAND_ECC_HW_SYNDROME:
- if ((!ecc->calculate || !ecc->correct || !ecc->hwctl) &&
- (!ecc->read_page ||
- ecc->read_page == nand_read_page_hwecc ||
- !ecc->write_page ||
- ecc->write_page == nand_write_page_hwecc)) {
- WARN(1, "No ECC functions supplied; hardware ECC not possible\n");
- ret = -EINVAL;
- goto err_nand_manuf_cleanup;
- }
- /* Use standard syndrome read/write page function? */
- if (!ecc->read_page)
- ecc->read_page = nand_read_page_syndrome;
- if (!ecc->write_page)
- ecc->write_page = nand_write_page_syndrome;
- if (!ecc->read_page_raw)
- ecc->read_page_raw = nand_read_page_raw_syndrome;
- if (!ecc->write_page_raw)
- ecc->write_page_raw = nand_write_page_raw_syndrome;
- if (!ecc->read_oob)
- ecc->read_oob = nand_read_oob_syndrome;
- if (!ecc->write_oob)
- ecc->write_oob = nand_write_oob_syndrome;
+ switch (ecc->placement) {
+ case NAND_ECC_PLACEMENT_UNKNOWN:
+ case NAND_ECC_PLACEMENT_OOB:
+ /* Use standard hwecc read page function? */
+ if (!ecc->read_page)
+ ecc->read_page = nand_read_page_hwecc;
+ if (!ecc->write_page)
+ ecc->write_page = nand_write_page_hwecc;
+ if (!ecc->read_page_raw)
+ ecc->read_page_raw = nand_read_page_raw;
+ if (!ecc->write_page_raw)
+ ecc->write_page_raw = nand_write_page_raw;
+ if (!ecc->read_oob)
+ ecc->read_oob = nand_read_oob_std;
+ if (!ecc->write_oob)
+ ecc->write_oob = nand_write_oob_std;
+ if (!ecc->read_subpage)
+ ecc->read_subpage = nand_read_subpage;
+ if (!ecc->write_subpage && ecc->hwctl && ecc->calculate)
+ ecc->write_subpage = nand_write_subpage_hwecc;
+ fallthrough;
- if (mtd->writesize >= ecc->size) {
- if (!ecc->strength) {
- WARN(1, "Driver must set ecc.strength when using hardware ECC\n");
+ case NAND_ECC_PLACEMENT_INTERLEAVED:
+ if ((!ecc->calculate || !ecc->correct || !ecc->hwctl) &&
+ (!ecc->read_page ||
+ ecc->read_page == nand_read_page_hwecc ||
+ !ecc->write_page ||
+ ecc->write_page == nand_write_page_hwecc)) {
+ WARN(1, "No ECC functions supplied; hardware ECC not possible\n");
ret = -EINVAL;
goto err_nand_manuf_cleanup;
}
+ /* Use standard syndrome read/write page function? */
+ if (!ecc->read_page)
+ ecc->read_page = nand_read_page_syndrome;
+ if (!ecc->write_page)
+ ecc->write_page = nand_write_page_syndrome;
+ if (!ecc->read_page_raw)
+ ecc->read_page_raw = nand_read_page_raw_syndrome;
+ if (!ecc->write_page_raw)
+ ecc->write_page_raw = nand_write_page_raw_syndrome;
+ if (!ecc->read_oob)
+ ecc->read_oob = nand_read_oob_syndrome;
+ if (!ecc->write_oob)
+ ecc->write_oob = nand_write_oob_syndrome;
+
+ if (mtd->writesize >= ecc->size) {
+ if (!ecc->strength) {
+ WARN(1, "Driver must set ecc.strength when using hardware ECC\n");
+ ret = -EINVAL;
+ goto err_nand_manuf_cleanup;
+ }
+ break;
+ }
+ pr_warn("%d byte HW ECC not possible on %d byte page size, fallback to SW ECC\n",
+ ecc->size, mtd->writesize);
+ ecc->mode = NAND_ECC_SOFT;
+ ecc->algo = NAND_ECC_HAMMING;
break;
+
+ default:
+ pr_warn("Invalid NAND_ECC_PLACEMENT %d\n",
+ ecc->placement);
+ ret = -EINVAL;
+ goto err_nand_manuf_cleanup;
}
- pr_warn("%d byte HW ECC not possible on %d byte page size, fallback to SW ECC\n",
- ecc->size, mtd->writesize);
- ecc->mode = NAND_ECC_SOFT;
- ecc->algo = NAND_ECC_HAMMING;
fallthrough;
+
case NAND_ECC_SOFT:
ret = nand_set_ecc_soft_ops(chip);
if (ret) {
diff --git a/drivers/mtd/nand/raw/r852.c b/drivers/mtd/nand/raw/r852.c
index f865e3a47b01..f0988cda4479 100644
--- a/drivers/mtd/nand/raw/r852.c
+++ b/drivers/mtd/nand/raw/r852.c
@@ -859,7 +859,8 @@ static int r852_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
chip->legacy.write_buf = r852_write_buf;
/* ecc */
- chip->ecc.mode = NAND_ECC_HW_SYNDROME;
+ chip->ecc.mode = NAND_ECC_HW;
+ chip->ecc.placement = NAND_ECC_PLACEMENT_INTERLEAVED;
chip->ecc.size = R852_DMA_LEN;
chip->ecc.bytes = SM_OOB_SIZE;
chip->ecc.strength = 2;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 5e014807e050..f6ffd174abb7 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -325,6 +325,7 @@ static const struct nand_ecc_caps __name = { \
/**
* struct nand_ecc_ctrl - Control structure for ECC
* @mode: ECC mode
+ * @placement: OOB bytes placement
* @algo: ECC algorithm
* @steps: number of ECC steps per page
* @size: data bytes per ECC step
@@ -352,7 +353,7 @@ static const struct nand_ecc_caps __name = { \
* controller and always return contiguous in-band and
* out-of-band data even if they're not stored
* contiguously on the NAND chip (e.g.
- * NAND_ECC_HW_SYNDROME interleaves in-band and
+ * NAND_ECC_PLACEMENT_INTERLEAVED interleaves in-band and
* out-of-band data).
* @write_page_raw: function to write a raw page without ECC. This function
* should hide the specific layout used by the ECC
@@ -360,7 +361,7 @@ static const struct nand_ecc_caps __name = { \
* in-band and out-of-band data. ECC controller is
* responsible for doing the appropriate transformations
* to adapt to its specific layout (e.g.
- * NAND_ECC_HW_SYNDROME interleaves in-band and
+ * NAND_ECC_PLACEMENT_INTERLEAVED interleaves in-band and
* out-of-band data).
* @read_page: function to read a page according to the ECC generator
* requirements; returns maximum number of bitflips corrected in
@@ -377,6 +378,7 @@ static const struct nand_ecc_caps __name = { \
*/
struct nand_ecc_ctrl {
enum nand_ecc_mode mode;
+ enum nand_ecc_placement placement;
enum nand_ecc_algo algo;
int steps;
int size;
diff --git a/include/linux/platform_data/mtd-davinci.h b/include/linux/platform_data/mtd-davinci.h
index 03e92c71b3fa..6e2b252a4ce6 100644
--- a/include/linux/platform_data/mtd-davinci.h
+++ b/include/linux/platform_data/mtd-davinci.h
@@ -69,6 +69,7 @@ struct davinci_nand_pdata { /* platform_data */
* using it with large page chips.
*/
enum nand_ecc_mode ecc_mode;
+ enum nand_ecc_placement ecc_placement;
u8 ecc_bits;
/* e.g. NAND_BUSWIDTH_16 */
--
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 v7 04/20] mtd: rawnand: Create a helper to retrieve the ECC placement
From: Miquel Raynal @ 2020-05-29 0:25 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
Use it from nand_dt_init() to initialize the ECC structure.
This allows the deprecation of the hw_syndrome ECC mode.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/nand/raw/nand_base.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 9fbd2a474b62..fd0bfe9bf7ae 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5047,6 +5047,34 @@ static int of_get_nand_ecc_mode(struct device_node *np)
return -ENODEV;
}
+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_INTERLEAVED;
+ placement < ARRAY_SIZE(nand_ecc_placement); placement++) {
+ if (!strcasecmp(pm, nand_ecc_placement[placement]))
+ return placement;
+ }
+ }
+
+ /*
+ * For backward compatibility we support few obsoleted values that don't
+ * have their mappings into the nand_ecc_placement enum anymore.
+ */
+ err = of_property_read_string(np, "nand-ecc-mode", &pm);
+ if (!err) {
+ if (!strcasecmp(pm, "hw_syndrome"))
+ return NAND_ECC_PLACEMENT_INTERLEAVED;
+ }
+
+ return NAND_ECC_PLACEMENT_UNKNOWN;
+}
+
static const char * const nand_ecc_algos[] = {
[NAND_ECC_HAMMING] = "hamming",
[NAND_ECC_BCH] = "bch",
@@ -5143,6 +5171,7 @@ static int nand_dt_init(struct nand_chip *chip)
ecc_mode = of_get_nand_ecc_mode(dn);
ecc_algo = of_get_nand_ecc_algo(dn);
+ chip->ecc.placement = of_get_nand_ecc_placement(dn);
ecc_strength = of_get_nand_ecc_strength(dn);
ecc_step = of_get_nand_ecc_step_size(dn);
--
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 v7 05/20] mtd: rawnand: Add a kernel doc to the ECC algorithm enumeration
From: Miquel Raynal @ 2020-05-29 0:25 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
Before moving it to the generic raw NAND core, ensure the enumeration
is properly described.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
include/linux/mtd/rawnand.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index f6ffd174abb7..6699ec7f4d40 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -106,6 +106,13 @@ enum nand_ecc_placement {
NAND_ECC_PLACEMENT_INTERLEAVED,
};
+/**
+ * enum nand_ecc_algo - NAND ECC algorithm
+ * @NAND_ECC_UNKNOWN: Unknown algorithm
+ * @NAND_ECC_HAMMING: Hamming algorithm
+ * @NAND_ECC_BCH: Bose-Chaudhuri-Hocquenghem algorithm
+ * @NAND_ECC_RS: Reed-Solomon algorithm
+ */
enum nand_ecc_algo {
NAND_ECC_UNKNOWN,
NAND_ECC_HAMMING,
--
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 v7 06/20] mtd: rawnand: Rename the ECC algorithm enumeration items
From: Miquel Raynal @ 2020-05-29 0:25 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
NAND_ECC_ is not a meaningful prefix, use NAND_ECC_ALGO_ instead.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/nand/raw/ams-delta.c | 2 +-
drivers/mtd/nand/raw/arasan-nand-controller.c | 2 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +-
drivers/mtd/nand/raw/au1550nd.c | 2 +-
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 12 ++++-----
drivers/mtd/nand/raw/davinci_nand.c | 8 +++---
drivers/mtd/nand/raw/fsl_elbc_nand.c | 2 +-
drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +-
drivers/mtd/nand/raw/fsl_upm.c | 2 +-
drivers/mtd/nand/raw/fsmc_nand.c | 2 +-
drivers/mtd/nand/raw/gpio.c | 2 +-
drivers/mtd/nand/raw/marvell_nand.c | 10 +++----
drivers/mtd/nand/raw/mpc5121_nfc.c | 2 +-
drivers/mtd/nand/raw/mxc_nand.c | 2 +-
drivers/mtd/nand/raw/nand_base.c | 26 +++++++++----------
drivers/mtd/nand/raw/nand_micron.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 4 +--
drivers/mtd/nand/raw/omap2.c | 2 +-
drivers/mtd/nand/raw/orion_nand.c | 2 +-
drivers/mtd/nand/raw/pasemi_nand.c | 2 +-
drivers/mtd/nand/raw/plat_nand.c | 2 +-
drivers/mtd/nand/raw/s3c2410.c | 4 +--
drivers/mtd/nand/raw/sh_flctl.c | 2 +-
drivers/mtd/nand/raw/socrates_nand.c | 2 +-
drivers/mtd/nand/raw/tango_nand.c | 2 +-
drivers/mtd/nand/raw/tegra_nand.c | 20 +++++++-------
drivers/mtd/nand/raw/xway_nand.c | 2 +-
include/linux/mtd/rawnand.h | 16 ++++++------
28 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 3711e7a0436c..72a44b2411c1 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -261,7 +261,7 @@ static int gpio_nand_probe(struct platform_device *pdev)
}
this->ecc.mode = NAND_ECC_SOFT;
- this->ecc.algo = NAND_ECC_HAMMING;
+ this->ecc.algo = NAND_ECC_ALGO_HAMMING;
platform_set_drvdata(pdev, priv);
diff --git a/drivers/mtd/nand/raw/arasan-nand-controller.c b/drivers/mtd/nand/raw/arasan-nand-controller.c
index 7141dcccba3c..076736351bc6 100644
--- a/drivers/mtd/nand/raw/arasan-nand-controller.c
+++ b/drivers/mtd/nand/raw/arasan-nand-controller.c
@@ -983,7 +983,7 @@ static int anfc_init_hw_ecc_controller(struct arasan_nfc *nfc,
mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
ecc->steps = mtd->writesize / ecc->size;
- ecc->algo = NAND_ECC_BCH;
+ ecc->algo = NAND_ECC_ALGO_BCH;
anand->ecc_bits = bch_gf_mag * ecc->strength;
ecc->bytes = DIV_ROUND_UP(anand->ecc_bits, 8);
anand->ecc_total = DIV_ROUND_UP(anand->ecc_bits * ecc->steps, 8);
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index 46a3724a788e..d9839461e460 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1099,7 +1099,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
if (IS_ERR(nand->pmecc))
return PTR_ERR(nand->pmecc);
- chip->ecc.algo = NAND_ECC_BCH;
+ chip->ecc.algo = NAND_ECC_ALGO_BCH;
chip->ecc.size = req.ecc.sectorsize;
chip->ecc.bytes = req.ecc.bytes / req.ecc.nsectors;
chip->ecc.strength = req.ecc.strength;
diff --git a/drivers/mtd/nand/raw/au1550nd.c b/drivers/mtd/nand/raw/au1550nd.c
index f7b4f421b2b0..e9140bf5cbac 100644
--- a/drivers/mtd/nand/raw/au1550nd.c
+++ b/drivers/mtd/nand/raw/au1550nd.c
@@ -295,7 +295,7 @@ static int au1550nd_probe(struct platform_device *pdev)
ctx->controller.ops = &au1550nd_ops;
this->controller = &ctx->controller;
this->ecc.mode = NAND_ECC_SOFT;
- this->ecc.algo = NAND_ECC_HAMMING;
+ this->ecc.algo = NAND_ECC_ALGO_HAMMING;
if (pd->devwidth)
this->options |= NAND_BUSWIDTH_16;
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 4a0a7053fb7a..2a9f2ff89fe7 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -2545,17 +2545,17 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
return -EINVAL;
}
- if (chip->ecc.algo == NAND_ECC_UNKNOWN) {
+ if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) {
if (chip->ecc.strength == 1 && chip->ecc.size == 512)
/* Default to Hamming for 1-bit ECC, if unspecified */
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
else
/* Otherwise, BCH */
- chip->ecc.algo = NAND_ECC_BCH;
+ chip->ecc.algo = NAND_ECC_ALGO_BCH;
}
- if (chip->ecc.algo == NAND_ECC_HAMMING && (chip->ecc.strength != 1 ||
- chip->ecc.size != 512)) {
+ if (chip->ecc.algo == NAND_ECC_ALGO_HAMMING &&
+ (chip->ecc.strength != 1 || chip->ecc.size != 512)) {
dev_err(ctrl->dev, "invalid Hamming params: %d bits per %d bytes\n",
chip->ecc.strength, chip->ecc.size);
return -EINVAL;
@@ -2574,7 +2574,7 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
switch (chip->ecc.size) {
case 512:
- if (chip->ecc.algo == NAND_ECC_HAMMING)
+ if (chip->ecc.algo == NAND_ECC_ALGO_HAMMING)
cfg->ecc_level = 15;
else
cfg->ecc_level = chip->ecc.strength;
diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
index 2e5d6c113b56..3640c7e45e15 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -593,11 +593,11 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
pdata->ecc_bits = 0;
/*
* This driver expects Hamming based ECC when ecc_mode is set
- * to NAND_ECC_SOFT. Force ecc.algo to NAND_ECC_HAMMING to
+ * to NAND_ECC_SOFT. Force ecc.algo to NAND_ECC_ALGO_HAMMING to
* avoid adding an extra ->ecc_algo field to
* davinci_nand_pdata.
*/
- info->chip.ecc.algo = NAND_ECC_HAMMING;
+ info->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
break;
case NAND_ECC_HW:
if (pdata->ecc_bits == 4) {
@@ -629,7 +629,7 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
info->chip.ecc.hwctl = nand_davinci_hwctl_4bit;
info->chip.ecc.bytes = 10;
info->chip.ecc.options = NAND_ECC_GENERIC_ERASED_CHECK;
- info->chip.ecc.algo = NAND_ECC_BCH;
+ info->chip.ecc.algo = NAND_ECC_ALGO_BCH;
/*
* Update ECC layout if needed ... for 1-bit HW ECC, the
@@ -656,7 +656,7 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
info->chip.ecc.correct = nand_davinci_correct_1bit;
info->chip.ecc.hwctl = nand_davinci_hwctl_1bit;
info->chip.ecc.bytes = 3;
- info->chip.ecc.algo = NAND_ECC_HAMMING;
+ info->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
}
info->chip.ecc.size = 512;
info->chip.ecc.strength = pdata->ecc_bits;
diff --git a/drivers/mtd/nand/raw/fsl_elbc_nand.c b/drivers/mtd/nand/raw/fsl_elbc_nand.c
index 088692b2e27a..da89389faaae 100644
--- a/drivers/mtd/nand/raw/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_elbc_nand.c
@@ -748,7 +748,7 @@ static int fsl_elbc_attach_chip(struct nand_chip *chip)
} else {
/* otherwise fall back to default software ECC */
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
}
break;
diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c
index 00ae7a910b03..b2ae759dd14e 100644
--- a/drivers/mtd/nand/raw/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c
@@ -926,7 +926,7 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
}
} else {
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
}
ret = fsl_ifc_sram_init(priv);
diff --git a/drivers/mtd/nand/raw/fsl_upm.c b/drivers/mtd/nand/raw/fsl_upm.c
index 627deb26db51..49592b7e03a3 100644
--- a/drivers/mtd/nand/raw/fsl_upm.c
+++ b/drivers/mtd/nand/raw/fsl_upm.c
@@ -164,7 +164,7 @@ static int fun_chip_init(struct fsl_upm_nand *fun,
fun->chip.legacy.read_buf = fun_read_buf;
fun->chip.legacy.write_buf = fun_write_buf;
fun->chip.ecc.mode = NAND_ECC_SOFT;
- fun->chip.ecc.algo = NAND_ECC_HAMMING;
+ fun->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
if (fun->mchip_count > 1)
fun->chip.legacy.select_chip = fun_select_chip;
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index 3909752b14c5..ced570987e85 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -911,7 +911,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
break;
case NAND_ECC_SOFT:
- if (nand->ecc.algo == NAND_ECC_BCH) {
+ if (nand->ecc.algo == NAND_ECC_ALGO_BCH) {
dev_info(host->dev,
"Using 4-bit SW BCH ECC scheme\n");
break;
diff --git a/drivers/mtd/nand/raw/gpio.c b/drivers/mtd/nand/raw/gpio.c
index 938077e5c6a9..667807c7100b 100644
--- a/drivers/mtd/nand/raw/gpio.c
+++ b/drivers/mtd/nand/raw/gpio.c
@@ -276,7 +276,7 @@ static int gpio_nand_probe(struct platform_device *pdev)
nand_set_flash_node(chip, pdev->dev.of_node);
chip->legacy.IO_ADDR_W = chip->legacy.IO_ADDR_R;
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
chip->options = gpiomtd->plat.options;
chip->legacy.chip_delay = gpiomtd->plat.chip_delay;
chip->legacy.cmd_ctrl = gpio_nand_cmd_ctrl;
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c
index 260a0430313e..3969cca7d925 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -780,7 +780,7 @@ static void marvell_nfc_enable_hw_ecc(struct nand_chip *chip)
* When enabling BCH, set threshold to 0 to always know the
* number of corrected bitflips.
*/
- if (chip->ecc.algo == NAND_ECC_BCH)
+ if (chip->ecc.algo == NAND_ECC_ALGO_BCH)
writel_relaxed(NDECCCTRL_BCH_EN, nfc->regs + NDECCCTRL);
}
}
@@ -792,7 +792,7 @@ static void marvell_nfc_disable_hw_ecc(struct nand_chip *chip)
if (ndcr & NDCR_ECC_EN) {
writel_relaxed(ndcr & ~NDCR_ECC_EN, nfc->regs + NDCR);
- if (chip->ecc.algo == NAND_ECC_BCH)
+ if (chip->ecc.algo == NAND_ECC_ALGO_BCH)
writel_relaxed(0, nfc->regs + NDECCCTRL);
}
}
@@ -966,7 +966,7 @@ static int marvell_nfc_hw_ecc_check_bitflips(struct nand_chip *chip,
if (ndsr & NDSR_CORERR) {
writel_relaxed(ndsr, nfc->regs + NDSR);
- if (chip->ecc.algo == NAND_ECC_BCH)
+ if (chip->ecc.algo == NAND_ECC_ALGO_BCH)
bf = NDSR_ERRCNT(ndsr);
else
bf = 1;
@@ -2215,7 +2215,7 @@ static int marvell_nand_hw_ecc_controller_init(struct mtd_info *mtd,
ecc->size = l->data_bytes;
if (ecc->strength == 1) {
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
ecc->read_page_raw = marvell_nfc_hw_ecc_hmg_read_page_raw;
ecc->read_page = marvell_nfc_hw_ecc_hmg_read_page;
ecc->read_oob_raw = marvell_nfc_hw_ecc_hmg_read_oob_raw;
@@ -2225,7 +2225,7 @@ static int marvell_nand_hw_ecc_controller_init(struct mtd_info *mtd,
ecc->write_oob_raw = marvell_nfc_hw_ecc_hmg_write_oob_raw;
ecc->write_oob = ecc->write_oob_raw;
} else {
- chip->ecc.algo = NAND_ECC_BCH;
+ chip->ecc.algo = NAND_ECC_ALGO_BCH;
ecc->strength = 16;
ecc->read_page_raw = marvell_nfc_hw_ecc_bch_read_page_raw;
ecc->read_page = marvell_nfc_hw_ecc_bch_read_page;
diff --git a/drivers/mtd/nand/raw/mpc5121_nfc.c b/drivers/mtd/nand/raw/mpc5121_nfc.c
index 18ecb096a32d..a67eded226db 100644
--- a/drivers/mtd/nand/raw/mpc5121_nfc.c
+++ b/drivers/mtd/nand/raw/mpc5121_nfc.c
@@ -689,7 +689,7 @@ static int mpc5121_nfc_probe(struct platform_device *op)
chip->legacy.get_features = nand_get_set_features_notsupp;
chip->bbt_options = NAND_BBT_USE_FLASH;
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
/* Support external chip-select logic on ADS5121 board */
if (of_machine_is_compatible("fsl,mpc5121ads")) {
diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c
index 09dacb83cb5a..c2e9759cfba8 100644
--- a/drivers/mtd/nand/raw/mxc_nand.c
+++ b/drivers/mtd/nand/raw/mxc_nand.c
@@ -1846,7 +1846,7 @@ static int mxcnd_probe(struct platform_device *pdev)
this->ecc.mode = NAND_ECC_HW;
} else {
this->ecc.mode = NAND_ECC_SOFT;
- this->ecc.algo = NAND_ECC_HAMMING;
+ this->ecc.algo = NAND_ECC_ALGO_HAMMING;
}
/* NAND bus width determines access functions used by upper layer */
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index fd0bfe9bf7ae..4cf53b9dddee 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5076,9 +5076,9 @@ enum nand_ecc_placement of_get_nand_ecc_placement(struct device_node *np)
}
static const char * const nand_ecc_algos[] = {
- [NAND_ECC_HAMMING] = "hamming",
- [NAND_ECC_BCH] = "bch",
- [NAND_ECC_RS] = "rs",
+ [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)
@@ -5089,7 +5089,7 @@ static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
err = of_property_read_string(np, "nand-ecc-algo", &pm);
if (!err) {
- for (ecc_algo = NAND_ECC_HAMMING;
+ for (ecc_algo = NAND_ECC_ALGO_HAMMING;
ecc_algo < ARRAY_SIZE(nand_ecc_algos);
ecc_algo++) {
if (!strcasecmp(pm, nand_ecc_algos[ecc_algo]))
@@ -5104,12 +5104,12 @@ static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
err = of_property_read_string(np, "nand-ecc-mode", &pm);
if (!err) {
if (!strcasecmp(pm, "soft"))
- return NAND_ECC_HAMMING;
+ return NAND_ECC_ALGO_HAMMING;
else if (!strcasecmp(pm, "soft_bch"))
- return NAND_ECC_BCH;
+ return NAND_ECC_ALGO_BCH;
}
- return NAND_ECC_UNKNOWN;
+ return NAND_ECC_ALGO_UNKNOWN;
}
static int of_get_nand_ecc_step_size(struct device_node *np)
@@ -5178,7 +5178,7 @@ static int nand_dt_init(struct nand_chip *chip)
if (ecc_mode >= 0)
chip->ecc.mode = ecc_mode;
- if (ecc_algo != NAND_ECC_UNKNOWN)
+ if (ecc_algo != NAND_ECC_ALGO_UNKNOWN)
chip->ecc.algo = ecc_algo;
if (ecc_strength >= 0)
@@ -5302,7 +5302,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
return -EINVAL;
switch (ecc->algo) {
- case NAND_ECC_HAMMING:
+ case NAND_ECC_ALGO_HAMMING:
ecc->calculate = nand_calculate_ecc;
ecc->correct = nand_correct_data;
ecc->read_page = nand_read_page_swecc;
@@ -5323,7 +5323,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
ecc->options |= NAND_ECC_SOFT_HAMMING_SM_ORDER;
return 0;
- case NAND_ECC_BCH:
+ case NAND_ECC_ALGO_BCH:
if (!mtd_nand_has_bch()) {
WARN(1, "CONFIG_MTD_NAND_ECC_SW_BCH not enabled\n");
return -EINVAL;
@@ -5763,7 +5763,7 @@ static int nand_scan_tail(struct nand_chip *chip)
* If no default placement scheme is given, select an appropriate one.
*/
if (!mtd->ooblayout &&
- !(ecc->mode == NAND_ECC_SOFT && ecc->algo == NAND_ECC_BCH)) {
+ !(ecc->mode == NAND_ECC_SOFT && ecc->algo == NAND_ECC_ALGO_BCH)) {
switch (mtd->oobsize) {
case 8:
case 16:
@@ -5858,7 +5858,7 @@ static int nand_scan_tail(struct nand_chip *chip)
pr_warn("%d byte HW ECC not possible on %d byte page size, fallback to SW ECC\n",
ecc->size, mtd->writesize);
ecc->mode = NAND_ECC_SOFT;
- ecc->algo = NAND_ECC_HAMMING;
+ ecc->algo = NAND_ECC_ALGO_HAMMING;
break;
default:
@@ -6124,7 +6124,7 @@ EXPORT_SYMBOL(nand_scan_with_ids);
void nand_cleanup(struct nand_chip *chip)
{
if (chip->ecc.mode == NAND_ECC_SOFT &&
- chip->ecc.algo == NAND_ECC_BCH)
+ chip->ecc.algo == NAND_ECC_ALGO_BCH)
nand_bch_free((struct nand_bch_control *)chip->ecc.priv);
nanddev_cleanup(&chip->base);
diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
index 3589b4fce0d4..a43b4d17bc69 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -543,7 +543,7 @@ static int micron_nand_init(struct nand_chip *chip)
chip->ecc.bytes = chip->base.eccreq.strength * 2;
chip->ecc.size = 512;
chip->ecc.strength = chip->base.eccreq.strength;
- chip->ecc.algo = NAND_ECC_BCH;
+ chip->ecc.algo = NAND_ECC_ALGO_BCH;
chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
chip->ecc.write_page = micron_nand_write_page_on_die_ecc;
diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
index 0a5cb77966cc..9bcf1b9d4987 100644
--- a/drivers/mtd/nand/raw/nandsim.c
+++ b/drivers/mtd/nand/raw/nandsim.c
@@ -2235,7 +2235,7 @@ static int ns_attach_chip(struct nand_chip *chip)
}
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_BCH;
+ chip->ecc.algo = NAND_ECC_ALGO_BCH;
chip->ecc.size = 512;
chip->ecc.strength = bch;
chip->ecc.bytes = eccbytes;
@@ -2275,7 +2275,7 @@ static int __init ns_init_module(void)
nand_set_controller_data(chip, (void *)ns);
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
/* The NAND_SKIP_BBTSCAN option is necessary for 'overridesize' */
/* and 'badblocks' parameters to work */
chip->options |= NAND_SKIP_BBTSCAN;
diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
index eb7fcfd9276b..967ddbda1c48 100644
--- a/drivers/mtd/nand/raw/omap2.c
+++ b/drivers/mtd/nand/raw/omap2.c
@@ -2011,7 +2011,7 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
*/
if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW) {
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
return 0;
}
diff --git a/drivers/mtd/nand/raw/orion_nand.c b/drivers/mtd/nand/raw/orion_nand.c
index 880b54ca1b41..7a5cfa3d883f 100644
--- a/drivers/mtd/nand/raw/orion_nand.c
+++ b/drivers/mtd/nand/raw/orion_nand.c
@@ -140,7 +140,7 @@ static int __init orion_nand_probe(struct platform_device *pdev)
nc->legacy.cmd_ctrl = orion_nand_cmd_ctrl;
nc->legacy.read_buf = orion_nand_read_buf;
nc->ecc.mode = NAND_ECC_SOFT;
- nc->ecc.algo = NAND_ECC_HAMMING;
+ nc->ecc.algo = NAND_ECC_ALGO_HAMMING;
if (board->chip_delay)
nc->legacy.chip_delay = board->chip_delay;
diff --git a/drivers/mtd/nand/raw/pasemi_nand.c b/drivers/mtd/nand/raw/pasemi_nand.c
index d8eca8c3fdcd..3eddc284614d 100644
--- a/drivers/mtd/nand/raw/pasemi_nand.c
+++ b/drivers/mtd/nand/raw/pasemi_nand.c
@@ -133,7 +133,7 @@ static int pasemi_nand_probe(struct platform_device *ofdev)
chip->legacy.write_buf = pasemi_write_buf;
chip->legacy.chip_delay = 0;
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
/* Enable the following for a flash based bad block table */
chip->bbt_options = NAND_BBT_USE_FLASH;
diff --git a/drivers/mtd/nand/raw/plat_nand.c b/drivers/mtd/nand/raw/plat_nand.c
index 556182f26057..dbc089c8872f 100644
--- a/drivers/mtd/nand/raw/plat_nand.c
+++ b/drivers/mtd/nand/raw/plat_nand.c
@@ -67,7 +67,7 @@ static int plat_nand_probe(struct platform_device *pdev)
data->chip.bbt_options |= pdata->chip.bbt_options;
data->chip.ecc.mode = NAND_ECC_SOFT;
- data->chip.ecc.algo = NAND_ECC_HAMMING;
+ data->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
platform_set_drvdata(pdev, data);
diff --git a/drivers/mtd/nand/raw/s3c2410.c b/drivers/mtd/nand/raw/s3c2410.c
index f86dff311464..dfe5a0f07385 100644
--- a/drivers/mtd/nand/raw/s3c2410.c
+++ b/drivers/mtd/nand/raw/s3c2410.c
@@ -938,11 +938,11 @@ static int s3c2410_nand_attach_chip(struct nand_chip *chip)
case NAND_ECC_SOFT:
/*
* This driver expects Hamming based ECC when ecc_mode is set
- * to NAND_ECC_SOFT. Force ecc.algo to NAND_ECC_HAMMING to
+ * to NAND_ECC_SOFT. Force ecc.algo to NAND_ECC_ALGO_HAMMING to
* avoid adding an extra ecc_algo field to
* s3c2410_platform_nand.
*/
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
dev_info(info->device, "soft ECC\n");
break;
diff --git a/drivers/mtd/nand/raw/sh_flctl.c b/drivers/mtd/nand/raw/sh_flctl.c
index a661b8bb2dd5..9dbd6fdbe264 100644
--- a/drivers/mtd/nand/raw/sh_flctl.c
+++ b/drivers/mtd/nand/raw/sh_flctl.c
@@ -1045,7 +1045,7 @@ static int flctl_chip_attach_chip(struct nand_chip *chip)
flctl->flcmncr_base |= _4ECCEN;
} else {
chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
+ chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
}
return 0;
diff --git a/drivers/mtd/nand/raw/socrates_nand.c b/drivers/mtd/nand/raw/socrates_nand.c
index 243b34cfbc1b..72a3a7f98282 100644
--- a/drivers/mtd/nand/raw/socrates_nand.c
+++ b/drivers/mtd/nand/raw/socrates_nand.c
@@ -154,7 +154,7 @@ static int socrates_nand_probe(struct platform_device *ofdev)
nand_chip->legacy.dev_ready = socrates_nand_device_ready;
nand_chip->ecc.mode = NAND_ECC_SOFT; /* enable ECC */
- nand_chip->ecc.algo = NAND_ECC_HAMMING;
+ nand_chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
/* TODO: I have no idea what real delay is. */
nand_chip->legacy.chip_delay = 20; /* 20us command delay time */
diff --git a/drivers/mtd/nand/raw/tango_nand.c b/drivers/mtd/nand/raw/tango_nand.c
index 246871e01027..2154b6f860dd 100644
--- a/drivers/mtd/nand/raw/tango_nand.c
+++ b/drivers/mtd/nand/raw/tango_nand.c
@@ -512,7 +512,7 @@ static int tango_attach_chip(struct nand_chip *chip)
struct nand_ecc_ctrl *ecc = &chip->ecc;
ecc->mode = NAND_ECC_HW;
- ecc->algo = NAND_ECC_BCH;
+ ecc->algo = NAND_ECC_ALGO_BCH;
ecc->bytes = DIV_ROUND_UP(ecc->strength * FIELD_ORDER, BITS_PER_BYTE);
ecc->read_page_raw = tango_read_page_raw;
diff --git a/drivers/mtd/nand/raw/tegra_nand.c b/drivers/mtd/nand/raw/tegra_nand.c
index f9d046b2cd3b..e2e13effc8a6 100644
--- a/drivers/mtd/nand/raw/tegra_nand.c
+++ b/drivers/mtd/nand/raw/tegra_nand.c
@@ -479,7 +479,7 @@ static void tegra_nand_hw_ecc(struct tegra_nand_controller *ctrl,
{
struct tegra_nand_chip *nand = to_tegra_chip(chip);
- if (chip->ecc.algo == NAND_ECC_BCH && enable)
+ if (chip->ecc.algo == NAND_ECC_ALGO_BCH && enable)
writel_relaxed(nand->bch_config, ctrl->regs + BCH_CONFIG);
else
writel_relaxed(0, ctrl->regs + BCH_CONFIG);
@@ -877,7 +877,7 @@ static int tegra_nand_select_strength(struct nand_chip *chip, int oobsize)
int strength_len, bits_per_step;
switch (chip->ecc.algo) {
- case NAND_ECC_RS:
+ case NAND_ECC_ALGO_RS:
bits_per_step = BITS_PER_STEP_RS;
if (chip->options & NAND_IS_BOOT_MEDIUM) {
strength = rs_strength_bootable;
@@ -887,7 +887,7 @@ static int tegra_nand_select_strength(struct nand_chip *chip, int oobsize)
strength_len = ARRAY_SIZE(rs_strength);
}
break;
- case NAND_ECC_BCH:
+ case NAND_ECC_ALGO_BCH:
bits_per_step = BITS_PER_STEP_BCH;
if (chip->options & NAND_IS_BOOT_MEDIUM) {
strength = bch_strength_bootable;
@@ -935,14 +935,14 @@ static int tegra_nand_attach_chip(struct nand_chip *chip)
if (chip->options & NAND_BUSWIDTH_16)
nand->config |= CONFIG_BUS_WIDTH_16;
- if (chip->ecc.algo == NAND_ECC_UNKNOWN) {
+ if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) {
if (mtd->writesize < 2048)
- chip->ecc.algo = NAND_ECC_RS;
+ chip->ecc.algo = NAND_ECC_ALGO_RS;
else
- chip->ecc.algo = NAND_ECC_BCH;
+ chip->ecc.algo = NAND_ECC_ALGO_BCH;
}
- if (chip->ecc.algo == NAND_ECC_BCH && mtd->writesize < 2048) {
+ if (chip->ecc.algo == NAND_ECC_ALGO_BCH && mtd->writesize < 2048) {
dev_err(ctrl->dev, "BCH supports 2K or 4K page size only\n");
return -EINVAL;
}
@@ -963,7 +963,7 @@ static int tegra_nand_attach_chip(struct nand_chip *chip)
CONFIG_SKIP_SPARE_SIZE_4;
switch (chip->ecc.algo) {
- case NAND_ECC_RS:
+ case NAND_ECC_ALGO_RS:
bits_per_step = BITS_PER_STEP_RS * chip->ecc.strength;
mtd_set_ooblayout(mtd, &tegra_nand_oob_rs_ops);
nand->config_ecc |= CONFIG_HW_ECC | CONFIG_ECC_SEL |
@@ -984,7 +984,7 @@ static int tegra_nand_attach_chip(struct nand_chip *chip)
return -EINVAL;
}
break;
- case NAND_ECC_BCH:
+ case NAND_ECC_ALGO_BCH:
bits_per_step = BITS_PER_STEP_BCH * chip->ecc.strength;
mtd_set_ooblayout(mtd, &tegra_nand_oob_bch_ops);
nand->bch_config = BCH_ENABLE;
@@ -1013,7 +1013,7 @@ static int tegra_nand_attach_chip(struct nand_chip *chip)
}
dev_info(ctrl->dev, "Using %s with strength %d per 512 byte step\n",
- chip->ecc.algo == NAND_ECC_BCH ? "BCH" : "RS",
+ chip->ecc.algo == NAND_ECC_ALGO_BCH ? "BCH" : "RS",
chip->ecc.strength);
chip->ecc.bytes = DIV_ROUND_UP(bits_per_step, BITS_PER_BYTE);
diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
index 94bfba994326..909072e82a68 100644
--- a/drivers/mtd/nand/raw/xway_nand.c
+++ b/drivers/mtd/nand/raw/xway_nand.c
@@ -181,7 +181,7 @@ static int xway_nand_probe(struct platform_device *pdev)
data->chip.legacy.chip_delay = 30;
data->chip.ecc.mode = NAND_ECC_SOFT;
- data->chip.ecc.algo = NAND_ECC_HAMMING;
+ data->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
platform_set_drvdata(pdev, data);
nand_set_controller_data(&data->chip, data);
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 6699ec7f4d40..8d040312c301 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -108,16 +108,16 @@ enum nand_ecc_placement {
/**
* enum nand_ecc_algo - NAND ECC algorithm
- * @NAND_ECC_UNKNOWN: Unknown algorithm
- * @NAND_ECC_HAMMING: Hamming algorithm
- * @NAND_ECC_BCH: Bose-Chaudhuri-Hocquenghem algorithm
- * @NAND_ECC_RS: Reed-Solomon algorithm
+ * @NAND_ECC_ALGO_UNKNOWN: Unknown algorithm
+ * @NAND_ECC_ALGO_HAMMING: Hamming algorithm
+ * @NAND_ECC_ALGO_BCH: Bose-Chaudhuri-Hocquenghem algorithm
+ * @NAND_ECC_ALGO_RS: Reed-Solomon algorithm
*/
enum nand_ecc_algo {
- NAND_ECC_UNKNOWN,
- NAND_ECC_HAMMING,
- NAND_ECC_BCH,
- NAND_ECC_RS,
+ NAND_ECC_ALGO_UNKNOWN,
+ NAND_ECC_ALGO_HAMMING,
+ NAND_ECC_ALGO_BCH,
+ NAND_ECC_ALGO_RS,
};
/*
--
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 v7 10/20] mtd: nand: Add an extra level in the Kconfig hierarchy
From: Miquel Raynal @ 2020-05-29 0:25 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
Use an extra level in Kconfig for all NAND related entries.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/nand/Kconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index a5d8a211cb8a..c1a45b071165 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -1,7 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+menu "NAND"
+
config MTD_NAND_CORE
tristate
source "drivers/mtd/nand/onenand/Kconfig"
source "drivers/mtd/nand/raw/Kconfig"
source "drivers/mtd/nand/spi/Kconfig"
+
+endmenu
--
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 v7 07/20] mtd: rawnand: Create a new enumeration to describe properly ECC types
From: Miquel Raynal @ 2020-05-29 0:25 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Julien Su, Weijie Gao, Paul Cercueil, Boris Brezillon,
Thomas Petazzoni, Miquel Raynal, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200529002517.3546-1-miquel.raynal@bootlin.com>
Now that the misleading mix between ECC engine type and ECC placement
has been addressed, add a new enumeration to properly define ECC
engine types.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
include/linux/mtd/rawnand.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 8d040312c301..c66cf1f28707 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -92,6 +92,22 @@ enum nand_ecc_mode {
NAND_ECC_ON_DIE,
};
+/**
+ * enum nand_ecc_engine_type - NAND ECC engine type
+ * @NAND_ECC_ENGINE_TYPE_INVALID: Invalid value
+ * @NAND_ECC_ENGINE_TYPE_NONE: No ECC correction
+ * @NAND_ECC_ENGINE_TYPE_SOFT: Software ECC correction
+ * @NAND_ECC_ENGINE_TYPE_ON_HOST: On host hardware ECC correction
+ * @NAND_ECC_ENGINE_TYPE_ON_DIE: On chip hardware ECC correction
+ */
+enum nand_ecc_engine_type {
+ NAND_ECC_ENGINE_TYPE_INVALID,
+ NAND_ECC_ENGINE_TYPE_NONE,
+ NAND_ECC_ENGINE_TYPE_SOFT,
+ NAND_ECC_ENGINE_TYPE_ON_HOST,
+ NAND_ECC_ENGINE_TYPE_ON_DIE,
+};
+
/**
* enum nand_ecc_placement - NAND ECC bytes placement
* @NAND_ECC_PLACEMENT_UNKNOWN: The actual position of the ECC bytes is unknown
--
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