* 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: tglx, mingo, catalin.marinas, will, dyoung, robh+dt, arnd,
devicetree, linux-doc, kexec, linux-kernel, horms, guohanjun,
pkushwaha, 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.
^ permalink raw reply
* [PATCH v4 02/11] dt-bindings: dma: dw: Add max burst transaction length property
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Rob Herring
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Andy Shevchenko, linux-mips, dmaengine, devicetree,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
This array property is used to indicate the maximum burst transaction
length supported by each DMA channel.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do with the
constraints.
- Set default max-burst-len to 256 TR-WIDTH words.
Changelog v3:
- Add more details into the property description about what limitations
snps,max-burst-len defines.
---
.../bindings/dma/snps,dma-spear1340.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index e7611840a7cf..20870f5c14dd 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -120,6 +120,21 @@ properties:
enum: [0, 1]
default: 1
+ snps,max-burst-len:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Maximum length of the burst transactions supported by the controller.
+ This property defines the upper limit of the run-time burst setting
+ (CTLx.SRC_MSIZE/CTLx.DST_MSIZE fields) so the allowed burst length
+ will be from 1 to max-burst-len words. It's an array property with one
+ cell per channel in the units determined by the value set in the
+ CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width).
+ items:
+ maxItems: 8
+ items:
+ enum: [4, 8, 16, 32, 64, 128, 256]
+ default: 256
+
snps,dma-protection-control:
$ref: /schemas/types.yaml#definitions/uint32
description: |
--
2.26.2
^ permalink raw reply related
* [PATCH v4 03/11] dmaengine: Introduce min burst length capability
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Andy Shevchenko, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Some hardware aside from default 0/1 may have greater minimum burst
transactions length constraints. Here we introduce the DMA device
and slave capability, which if required can be initialized by the DMA
engine driver with the device-specific value.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index d31076d9ef25..b332ffe52780 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -590,6 +590,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->src_addr_widths = device->src_addr_widths;
caps->dst_addr_widths = device->dst_addr_widths;
caps->directions = device->directions;
+ caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index e1c03339918f..0c7403b27133 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -465,6 +465,7 @@ enum dma_residue_granularity {
* Since the enum dma_transfer_direction is not defined as bit flag for
* each type, the dma controller should set BIT(<TYPE>) and same
* should be checked by controller as well
+ * @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
* for resume later)
@@ -478,6 +479,7 @@ struct dma_slave_caps {
u32 src_addr_widths;
u32 dst_addr_widths;
u32 directions;
+ u32 min_burst;
u32 max_burst;
bool cmd_pause;
bool cmd_resume;
@@ -769,6 +771,7 @@ struct dma_filter {
* Since the enum dma_transfer_direction is not defined as bit flag for
* each type, the dma controller should set BIT(<TYPE>) and same
* should be checked by controller as well
+ * @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
@@ -839,6 +842,7 @@ struct dma_device {
u32 src_addr_widths;
u32 dst_addr_widths;
u32 directions;
+ u32 min_burst;
u32 max_burst;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
^ permalink raw reply related
* [PATCH v4 01/11] dt-bindings: dma: dw: Convert DW DMAC to DT binding
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Rob Herring, Andy Shevchenko
Cc: Serge Semin, Serge Semin, Rob Herring, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, linux-mips, dmaengine,
devicetree, linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces the Synopsis
Designware DMA controller legacy bare text bindings with YAML file.
The only required prorties are "compatible", "reg", "#dma-cells" and
"interrupts", which will be used by the driver to correctly find the
controller memory region and handle its events. The rest of the properties
are optional, since in case if either "dma-channels" or "dma-masters" isn't
specified, the driver will attempt to auto-detect the IP core
configuration.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do do with the
constraints.
- Discard default settings defined out of the property enum constraint.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property.
- Remove a label definition from the binding example.
---
.../bindings/dma/snps,dma-spear1340.yaml | 161 ++++++++++++++++++
.../devicetree/bindings/dma/snps-dma.txt | 69 --------
2 files changed, 161 insertions(+), 69 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
new file mode 100644
index 000000000000..e7611840a7cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/snps,dma-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys Designware DMA Controller
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+ - Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ const: snps,dma-spear1340
+
+ "#dma-cells":
+ const: 3
+ description: |
+ First cell is a phandle pointing to the DMA controller. Second one is
+ the DMA request line number. Third cell is the memory master identifier
+ for transfers on dynamically allocated channel. Fourth cell is the
+ peripheral master identifier for transfers on an allocated channel.
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: AHB interface reference clock.
+ const: hclk
+
+ dma-channels:
+ description: |
+ Number of DMA channels supported by the controller. In case if
+ not specified the driver will try to auto-detect this and
+ the rest of the optional parameters.
+ minimum: 1
+ maximum: 8
+
+ dma-requests:
+ minimum: 1
+ maximum: 16
+
+ dma-masters:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Number of DMA masters supported by the controller. In case if
+ not specified the driver will try to auto-detect this and
+ the rest of the optional parameters.
+ minimum: 1
+ maximum: 4
+
+ chan_allocation_order:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ DMA channels allocation order specifier. Zero means ascending order
+ (first free allocated), while one - descending (last free allocated).
+ default: 0
+ enum: [0, 1]
+
+ chan_priority:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ DMA channels priority order. Zero means ascending channels priority
+ so the very first channel has the highest priority. While 1 means
+ descending priority (the last channel has the highest priority).
+ default: 0
+ enum: [0, 1]
+
+ block_size:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: Maximum block size supported by the DMA controller.
+ enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095]
+
+ data-width:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Data bus width per each DMA master in bytes.
+ items:
+ maxItems: 4
+ items:
+ enum: [4, 8, 16, 32]
+
+ data_width:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
+ description: |
+ Data bus width per each DMA master in (2^n * 8) bits. This property is
+ deprecated. It' usage is discouraged in favor of data-width one. Moreover
+ the property incorrectly permits to define data-bus width of 8 and 16
+ bits, which is impossible in accordance with DW DMAC IP-core data book.
+ items:
+ maxItems: 4
+ items:
+ enum:
+ - 0 # 8 bits
+ - 1 # 16 bits
+ - 2 # 32 bits
+ - 3 # 64 bits
+ - 4 # 128 bits
+ - 5 # 256 bits
+ default: 0
+
+ multi-block:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ LLP-based multi-block transfer supported by hardware per
+ each DMA channel.
+ items:
+ maxItems: 8
+ items:
+ enum: [0, 1]
+ default: 1
+
+ snps,dma-protection-control:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting
+ indicates the following features: bit 0 - privileged mode,
+ bit 1 - DMA is bufferable, bit 2 - DMA is cacheable.
+ default: 0
+ minimum: 0
+ maximum: 7
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - "#dma-cells"
+ - reg
+ - interrupts
+
+examples:
+ - |
+ dma-controller@fc000000 {
+ compatible = "snps,dma-spear1340";
+ reg = <0xfc000000 0x1000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <12>;
+
+ dma-channels = <8>;
+ dma-requests = <16>;
+ dma-masters = <4>;
+ #dma-cells = <3>;
+
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+ block_size = <0xfff>;
+ data-width = <8 8>;
+ multi-block = <0 0 0 0 0 0 0 0>;
+ snps,max-burst-len = <16 16 4 4 4 4 4 4>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
deleted file mode 100644
index 0bedceed1963..000000000000
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-* Synopsys Designware DMA Controller
-
-Required properties:
-- compatible: "snps,dma-spear1340"
-- reg: Address range of the DMAC registers
-- interrupt: Should contain the DMAC interrupt number
-- dma-channels: Number of channels supported by hardware
-- dma-requests: Number of DMA request lines supported, up to 16
-- dma-masters: Number of AHB masters supported by the controller
-- #dma-cells: must be <3>
-- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
- 1: descending
-- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
- increase from chan n->0
-- block_size: Maximum block size supported by the controller
-- data-width: Maximum data width supported by hardware per AHB master
- (in bytes, power of 2)
-
-
-Deprecated properties:
-- data_width: Maximum data width supported by hardware per AHB master
- (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-
-
-Optional properties:
-- multi-block: Multi block transfers supported by hardware. Array property with
- one cell per channel. 0: not supported, 1 (default): supported.
-- snps,dma-protection-control: AHB HPROT[3:1] protection setting.
- The default value is 0 (for non-cacheable, non-buffered,
- unprivileged data access).
- Refer to include/dt-bindings/dma/dw-dmac.h for possible values.
-
-Example:
-
- dmahost: dma@fc000000 {
- compatible = "snps,dma-spear1340";
- reg = <0xfc000000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <12>;
-
- dma-channels = <8>;
- dma-requests = <16>;
- dma-masters = <2>;
- #dma-cells = <3>;
- chan_allocation_order = <1>;
- chan_priority = <1>;
- block_size = <0xfff>;
- data-width = <8 8>;
- };
-
-DMA clients connected to the Designware DMA controller must use the format
-described in the dma.txt file, using a four-cell specifier for each channel.
-The four cells in order are:
-
-1. A phandle pointing to the DMA controller
-2. The DMA request line number
-3. Memory master for transfers on allocated channel
-4. Peripheral master for transfers on allocated channel
-
-Example:
-
- serial@e0000000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0xe0000000 0x1000>;
- interrupts = <0 35 0x4>;
- dmas = <&dmahost 12 0 1>,
- <&dmahost 13 1 0>;
- dma-names = "rx", "rx";
- };
--
2.26.2
^ permalink raw reply related
* [PATCH v4 10/11] dmaengine: dw: Introduce max burst length hw config
From: Serge Semin @ 2020-05-28 22:24 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
IP core of the DW DMA controller may be synthesized with different
max burst length of the transfers per each channel. According to Synopsis
having the fixed maximum burst transactions length may provide some
performance gain. At the same time setting up the source and destination
multi size exceeding the max burst length limitation may cause a serious
problems. In our case the DMA transaction just hangs up. In order to fix
this lets introduce the max burst length platform config of the DW DMA
controller device and don't let the DMA channels configuration code
exceed the burst length hardware limitation.
Note the maximum burst length parameter can be detected either in runtime
from the DWC parameter registers or from the dedicated DT property.
Depending on the IP core configuration the maximum value can vary from
channel to channel so by overriding the channel slave max_burst capability
we make sure a DMA consumer will get the channel-specific max burst
length.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Discard dwc_get_maxburst() accessor. It's enough to have a clamping
guard against exceeding the hardware max burst limitation.
Changelog v3:
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
Changelog v4:
- Clamp the dst and src burst lengths in the generic dwc_config() method
instead of doing that in the encode_maxburst() callback.
- Define max_burst with u32 type in struct dw_dma_platform_data.
- Perform of_property_read_u32_array() directly into the platform data
max_burst member.
---
drivers/dma/dw/core.c | 10 ++++++++++
drivers/dma/dw/of.c | 5 +++++
drivers/dma/dw/regs.h | 2 ++
include/linux/platform_data/dma-dw.h | 4 ++++
4 files changed, 21 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index a8cebb1dbb68..60ef779fc5e0 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -791,6 +791,11 @@ static int dwc_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
memcpy(&dwc->dma_sconfig, sconfig, sizeof(*sconfig));
+ dwc->dma_sconfig.src_maxburst =
+ clamp(dwc->dma_sconfig.src_maxburst, 0U, dwc->max_burst);
+ dwc->dma_sconfig.dst_maxburst =
+ clamp(dwc->dma_sconfig.dst_maxburst, 0U, dwc->max_burst);
+
dw->encode_maxburst(dwc, &dwc->dma_sconfig.src_maxburst);
dw->encode_maxburst(dwc, &dwc->dma_sconfig.dst_maxburst);
@@ -1051,7 +1056,9 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
{
+ struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
+ caps->max_burst = dwc->max_burst;
}
int do_dma_probe(struct dw_dma_chip *chip)
@@ -1194,9 +1201,12 @@ int do_dma_probe(struct dw_dma_chip *chip)
dwc->nollp =
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
(dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
+ dwc->max_burst =
+ (0x4 << (dwc_params >> DWC_PARAMS_MSIZE & 0x7));
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
+ dwc->max_burst = pdata->max_burst[i] ?: DW_DMA_MAX_BURST;
}
}
diff --git a/drivers/dma/dw/of.c b/drivers/dma/dw/of.c
index 9e27831dee32..1474b3817ef4 100644
--- a/drivers/dma/dw/of.c
+++ b/drivers/dma/dw/of.c
@@ -98,6 +98,11 @@ struct dw_dma_platform_data *dw_dma_parse_dt(struct platform_device *pdev)
pdata->multi_block[tmp] = 1;
}
+ if (of_property_read_u32_array(np, "snps,max-burst-len", pdata->max_burst,
+ nr_channels)) {
+ memset32(pdata->max_burst, DW_DMA_MAX_BURST, nr_channels);
+ }
+
if (!of_property_read_u32(np, "snps,dma-protection-control", &tmp)) {
if (tmp > CHAN_PROTCTL_MASK)
return NULL;
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 1ab840b06e79..76654bd13c1a 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -126,6 +126,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
+#define DWC_PARAMS_MSIZE 16 /* max group transaction size */
/* bursts size */
enum dw_dma_msize {
@@ -284,6 +285,7 @@ struct dw_dma_chan {
/* hardware configuration */
unsigned int block_size;
bool nollp;
+ u32 max_burst;
/* custom slave configuration */
struct dw_dma_slave dws;
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index f3eaf9ec00a1..29c484da2979 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -12,6 +12,7 @@
#define DW_DMA_MAX_NR_MASTERS 4
#define DW_DMA_MAX_NR_CHANNELS 8
+#define DW_DMA_MAX_BURST 256
/**
* struct dw_dma_slave - Controller-specific information about a slave
@@ -42,6 +43,8 @@ struct dw_dma_slave {
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
* @multi_block: Multi block transfers supported by hardware per channel.
+ * @max_burst: Maximum value of burst transaction size supported by hardware
+ * per channel (in units of CTL.SRC_TR_WIDTH/CTL.DST_TR_WIDTH).
* @protctl: Protection control signals setting per channel.
*/
struct dw_dma_platform_data {
@@ -56,6 +59,7 @@ struct dw_dma_platform_data {
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
+ u32 max_burst[DW_DMA_MAX_NR_CHANNELS];
#define CHAN_PROTCTL_PRIVILEGED BIT(0)
#define CHAN_PROTCTL_BUFFERABLE BIT(1)
#define CHAN_PROTCTL_CACHEABLE BIT(2)
--
2.26.2
^ permalink raw reply related
* [PATCH v4 08/11] dmaengine: dw: Add dummy device_caps callback
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may
have non-uniform DMA capabilities per device channels, let's add
the DW DMA specific device_caps callback to expose that specifics up to
the DMA consumer. It's a dummy function for now. We'll fill it in with
capabilities overrides in the next commits.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dw/core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index fb95920c429e..ceded21537e2 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1049,6 +1049,11 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
}
+static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
+{
+
+}
+
int do_dma_probe(struct dw_dma_chip *chip)
{
struct dw_dma *dw = chip->dw;
@@ -1214,6 +1219,7 @@ int do_dma_probe(struct dw_dma_chip *chip)
dw->dma.device_prep_dma_memcpy = dwc_prep_dma_memcpy;
dw->dma.device_prep_slave_sg = dwc_prep_slave_sg;
+ dw->dma.device_caps = dwc_caps;
dw->dma.device_config = dwc_config;
dw->dma.device_pause = dwc_pause;
dw->dma.device_resume = dwc_resume;
--
2.26.2
^ permalink raw reply related
* [PATCH v4 11/11] dmaengine: dw: Initialize max_sg_nents capability
From: Serge Semin @ 2020-05-28 22:24 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Multi-block support provides a way to map the kernel-specific SG-table so
the DW DMA device would handle it as a whole instead of handling the
SG-list items or so called LLP block items one by one. So if true LLP
list isn't supported by the DW DMA engine, then soft-LLP mode will be
utilized to load and execute each LLP-block one by one. The soft-LLP mode
of the DMA transactions execution might not work well for some DMA
consumers like SPI due to its Tx and Rx buffers inter-dependency. Let's
initialize the max_sg_nents DMA channels capability based on the nollp
flag state. If it's true, no hardware accelerated LLP is available and
max_sg_nents should be set with 1, which means that the DMA engine
can handle only a single SG list entry at a time. If noLLP is set to
false, then hardware accelerated LLP is supported and the DMA engine
can handle infinite number of SG entries in a single DMA transaction.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
Changelog v4:
- Use explicit if-else statement when assigning the max_sg_nents field.
---
drivers/dma/dw/core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 60ef779fc5e0..b76eee75fde8 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1059,6 +1059,18 @@ static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
caps->max_burst = dwc->max_burst;
+
+ /*
+ * It might be crucial for some devices to have the hardware
+ * accelerated multi-block transfers supported, aka LLPs in DW DMAC
+ * notation. So if LLPs are supported then max_sg_nents is set to
+ * zero which means unlimited number of SG entries can be handled in a
+ * single DMA transaction, otherwise it's just one SG entry.
+ */
+ if (dwc->nollp)
+ caps->max_sg_nents = 1;
+ else
+ caps->max_sg_nents = 0;
}
int do_dma_probe(struct dw_dma_chip *chip)
--
2.26.2
^ permalink raw reply related
* [PATCH v4 07/11] dmaengine: dw: Set DMA device max segment size parameter
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Maximum block size DW DMAC configuration corresponds to the max segment
size DMA parameter in the DMA core subsystem notation. Lets set it with a
value specific to the probed DW DMA controller. It shall help the DMA
clients to create size-optimized SG-list items for the controller. This in
turn will cause less dw_desc allocations, less LLP reinitializations,
better DMA device performance.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- This is a new patch created in place of the dropped one:
"dmaengine: dw: Add LLP and block size config accessors".
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
---
drivers/dma/dw/core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 33e99d95b3d3..fb95920c429e 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1229,6 +1229,13 @@ int do_dma_probe(struct dw_dma_chip *chip)
BIT(DMA_MEM_TO_MEM);
dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ /*
+ * For now there is no hardware with non uniform maximum block size
+ * across all of the device channels, so we set the maximum segment
+ * size as the block size found for the very first channel.
+ */
+ dma_set_max_seg_size(dw->dma.dev, dw->chan[0].block_size);
+
err = dma_async_device_register(&dw->dma);
if (err)
goto err_dma_register;
--
2.26.2
^ permalink raw reply related
* [PATCH v4 05/11] dmaengine: Introduce DMA-device device_caps callback
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Andy Shevchenko, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
There are DMA devices (like ours version of Synopsys DW DMAC) which have
DMA capabilities non-uniformly redistributed amongst the device channels.
In order to provide a way of exposing the channel-specific parameters to
the DMA engine consumers, we introduce a new DMA-device callback. In case
if provided it gets called from the dma_get_slave_caps() method and is
able to override the generic DMA-device capabilities.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinod and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 3 +++
include/linux/dmaengine.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ad56ad58932c..edbb11d56cde 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -599,6 +599,9 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->cmd_resume = !!device->device_resume;
caps->cmd_terminate = !!device->device_terminate_all;
+ if (device->device_caps)
+ device->device_caps(chan, caps);
+
return 0;
}
EXPORT_SYMBOL_GPL(dma_get_slave_caps);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index a7e4d8dfdd19..b303e59929e5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -899,6 +899,8 @@ struct dma_device {
struct dma_chan *chan, dma_addr_t dst, u64 data,
unsigned long flags);
+ void (*device_caps)(struct dma_chan *chan,
+ struct dma_slave_caps *caps);
int (*device_config)(struct dma_chan *chan,
struct dma_slave_config *config);
int (*device_pause)(struct dma_chan *chan);
--
2.26.2
^ permalink raw reply related
* [PATCH v4 06/11] dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Full multi-block transfers functionality is enabled in DW DMA
controller only if CHx_MULTI_BLK_EN is set. But LLP-based transfers
can be executed only if hardcode channel x LLP register feature isn't
enabled, which can be switched on at the IP core synthesis for
optimization. If it's enabled then the LLP register is hardcoded to
zero, so the blocks chaining based on the LLPs is unsupported.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator.
Changelog v3:
- Move the patch to the head of the series.
---
drivers/dma/dw/core.c | 11 ++++++++++-
drivers/dma/dw/regs.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 21cb2a58dbd2..33e99d95b3d3 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1178,8 +1178,17 @@ int do_dma_probe(struct dw_dma_chip *chip)
*/
dwc->block_size =
(4 << ((pdata->block_size >> 4 * i) & 0xf)) - 1;
+
+ /*
+ * According to the DW DMA databook the true scatter-
+ * gether LLPs aren't available if either multi-block
+ * config is disabled (CHx_MULTI_BLK_EN == 0) or the
+ * LLP register is hard-coded to zeros
+ * (CHx_HC_LLP == 1).
+ */
dwc->nollp =
- (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
+ (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
+ (dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 3fce66ecee7a..1ab840b06e79 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -125,6 +125,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
+#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
/* bursts size */
enum dw_dma_msize {
--
2.26.2
^ permalink raw reply related
* [PATCH v4 04/11] dmaengine: Introduce max SG list entries capability
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Some devices may lack the support of the hardware accelerated SG list
entries automatic walking through and execution. In this case a burden of
the SG list traversal and DMA engine re-initialization lies on the
DMA engine driver (normally implemented by using a DMA transfer completion
IRQ to recharge the DMA device with a next SG list entry). But such
solution may not be suitable for some DMA consumers. In particular SPI
devices need both Tx and Rx DMA channels work synchronously in order
to avoid the Rx FIFO overflow. In case if Rx DMA channel is paused for
some time while the Tx DMA channel works implicitly pulling data into the
Rx FIFO, the later will be eventually overflown, which will cause the data
loss. So if SG list entries aren't automatically fetched by the DMA
engine, but are one-by-one manually selected for execution in the
ISRs/deferred work/etc., such problem will eventually happen due to the
non-deterministic latencies of the service execution.
In order to let the DMA consumer know about the DMA device capabilities
regarding the hardware accelerated SG list traversal we introduce the
max_sg_list capability. It is supposed to be initialized by the DMA engine
driver with 0 if there is no limitation for the number of SG entries
atomically executed and with non-zero value if there is such constraints,
so the upper limit is determined by the number set to the property.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
Changelog v4:
- Fix of->if typo. It should be definitely of.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index b332ffe52780..ad56ad58932c 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -592,6 +592,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->directions = device->directions;
caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
+ caps->max_sg_nents = device->max_sg_nents;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
caps->cmd_pause = !!device->device_pause;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0c7403b27133..a7e4d8dfdd19 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -467,6 +467,9 @@ enum dma_residue_granularity {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number of entries.
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
* for resume later)
* @cmd_resume: true, if resume is supported
@@ -481,6 +484,7 @@ struct dma_slave_caps {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool cmd_pause;
bool cmd_resume;
bool cmd_terminate;
@@ -773,6 +777,9 @@ struct dma_filter {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number of entries.
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
@@ -844,6 +851,7 @@ struct dma_device {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
^ permalink raw reply related
* [PATCH v4 09/11] dmaengine: dw: Initialize min_burst capability
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
According to the DW APB DMAC data book the minimum burst transaction
length is 1 and it's true for any version of the controller since
isn't parametrised in the coreAssembler so can't be changed at the
IP-core synthesis stage. Let's initialise the min_burst member of the
DMA controller descriptor so the DMA clients could use it to properly
optimize the DMA requests.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v4:
- This is a new patch suggested by Andy.
---
drivers/dma/dw/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index ceded21537e2..a8cebb1dbb68 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1229,6 +1229,7 @@ int do_dma_probe(struct dw_dma_chip *chip)
dw->dma.device_issue_pending = dwc_issue_pending;
/* DMA capabilities */
+ dw->dma.min_burst = 1;
dw->dma.src_addr_widths = DW_DMA_BUSWIDTHS;
dw->dma.dst_addr_widths = DW_DMA_BUSWIDTHS;
dw->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
--
2.26.2
^ permalink raw reply related
* [PATCH v4 00/11] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar
Cc: Serge Semin, Serge Semin, Alexey Malahov, Maxim Kaurkin,
Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
Alexey Kolotnikov, Thomas Bogendoerfer, Arnd Bergmann,
Andy Shevchenko, Rob Herring, linux-mips, dmaengine, devicetree,
linux-kernel
Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
with currently implemented in the kernel DW DMAC driver, but there are some
peculiarities which must be taken into account in order to have the device
fully supported.
First of all traditionally we replaced the legacy plain text-based dt-binding
file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
channels, which alas have different max burst length configuration.
In particular first two channels may burst up to 128 bits (16 bytes) at a time
while the rest of them just up to 32 bits. We must make sure that the DMA
subsystem doesn't set values exceeding these limitations otherwise the
controller will hang up. In third currently we discovered the problem in using
the DW APB SPI driver together with DW DMAC. The problem happens if there is no
natively implemented multi-block LLP transfers support and the SPI-transfer
length exceeds the max lock size. In this case due to asynchronous handling of
Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
the DMAC to asynchronously execute the transfers we'd have to at least warn
the user of the possible errors. In forth it's worth to set the DMA device max
segment size with max block size config specific to the DW DMA controller. It
shall help the DMA clients to create size-optimized SG-list items for the
controller. This in turn will cause less dw_desc allocations, less LLP
reinitializations, better DMA device performance.
Finally there is a bug in the algorithm of the nollp flag detection.
In particular even if DW DMAC parameters state the multi-block transfers
support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
by the driver true multi-block LLP functionality unusable. This happens cause'
if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
contiguous multi-block transfers will be only supported. We must take the
flag into account when detecting the LLP support otherwise the driver just
won't work correctly.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do do with the
constraints in the DT binding.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property in the DT binding file.
- Discard default settings defined out of property enum constraint.
- Set default max-burst-len to 256 TR-WIDTH words in the DT binding.
- Discard noLLP and block_size accessors.
- Set max segment size of the DMA device structure with the DW DMA block size
config.
- Print warning if noLLP flag is set.
- Discard max burst length accessor.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator in noLLP flag setting.
Link: https://lore.kernel.org/dmaengine/20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru/
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
- Add more details into the property description about what limitations
snps,max-burst-len defines.
- Move commit fb7e3bbfc830 ("dmaengine: dw: Take HC_LLP flag into account for
noLLP auto-config") to the head of the series.
- Add a new patch "dmaengine: Introduce min burst length capability" as a
result of the discussion with Vinod and Andy regarding the burst length
capability.
- Add a new patch "dmaengine: Introduce max SG list entries capability"
suggested by Andy.
- Add a new patch "dmaengine: Introduce DMA-device device_caps callback" as
a result of the discussion with Vinud and Andy in the framework of DW DMA
burst and LLP capabilities.
- Add a new patch "dmaengine: dw: Add dummy device_caps callback" as a
preparation commit before setting the max_burst and max_sg_nents
DW DMA capabilities.
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
- Add a new patch "dmaengine: dw: Initialize max_sg_nents with nollp flag".
This is required to fix the DW APB SSI issue of the Tx and Rx DMA
channels de-synchronization.
Link: https://lore.kernel.org/dmaengine/20200526225022.20405-1-Sergey.Semin@baikalelectronics.ru/
Changelog v4:
- Use explicit if-else statement when assigning the max_sg_nents field.
- Clamp the dst and src burst lengths in the generic dwc_config() method
instead of doing that in the encode_maxburst() callback.
- Define max_burst with u32 type in struct dw_dma_platform_data.
- Perform of_property_read_u32_array() with the platform data
max_burst member passed directly.
- Add a new patch "dmaengine: dw: Initialize min_burst capability",
which initializes the min_burst capability with 1.
- Fix of->if typo. It should be definitely "of" in the max_sg_list
capability description.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (11):
dt-bindings: dma: dw: Convert DW DMAC to DT binding
dt-bindings: dma: dw: Add max burst transaction length property
dmaengine: Introduce min burst length capability
dmaengine: Introduce max SG list entries capability
dmaengine: Introduce DMA-device device_caps callback
dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
dmaengine: dw: Set DMA device max segment size parameter
dmaengine: dw: Add dummy device_caps callback
dmaengine: dw: Initialize min_burst capability
dmaengine: dw: Introduce max burst length hw config
dmaengine: dw: Initialize max_sg_nents capability
.../bindings/dma/snps,dma-spear1340.yaml | 176 ++++++++++++++++++
.../devicetree/bindings/dma/snps-dma.txt | 69 -------
drivers/dma/dmaengine.c | 5 +
drivers/dma/dw/core.c | 47 ++++-
drivers/dma/dw/of.c | 5 +
drivers/dma/dw/regs.h | 3 +
include/linux/dmaengine.h | 14 ++
include/linux/platform_data/dma-dw.h | 4 +
8 files changed, 253 insertions(+), 70 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
--
2.26.2
^ 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: Bjorn Andersson, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-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
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy-qcom-usb-hs-phy: Add qcom,enable-vbus-pullup
From: Rob Herring @ 2020-05-28 22:34 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: devicetree, vkoul, bjorn.andersson, linux-kernel, linux-arm-msm,
Stephen Boyd, agross, robh+dt, kishon
In-Reply-To: <20200521005031.747162-2-bryan.odonoghue@linaro.org>
On Thu, 21 May 2020 01:50:30 +0100, Bryan O'Donoghue wrote:
> This patch adds a dt-binding for qcom,enable-vbus-pullup. The binding
> qcom,enable-vbus-pullup tells the HS USB PHY driver whether it should set
> and unset the internal VBUS pullup bits when starting/stopping the USB PHY.
>
> Setting the pullup bits is something you want to do if you have not routed
> VBUS to a GPIO on the SoC and thus cannot use extcon with the current
> switching logic in the PHY.
>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: simple-card: care missing address #address-cells
From: Rob Herring @ 2020-05-28 22:39 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Liam Girdwood, Mark Brown, Mark Rutland, devicetree, alsa-devel,
linux-kernel
In-Reply-To: <87pnay3ptb.wl-kuninori.morimoto.gx@renesas.com>
On Thu, May 21, 2020 at 12:54:56PM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current simple-card will get below error,
> because it doesn't care about #address-cells at some part.
>
> DTC Documentation/devicetree/bindings/sound/simple-card.example.dt.yaml
> Documentation/devicetree/bindings/sound/simple-card.example.dts:171.46-173.15: \
> Warning (unit_address_vs_reg): /example-4/sound/simple-audio-card,cpu@0: \
> node has a unit name, but no reg or ranges property
> Documentation/devicetree/bindings/sound/simple-card.example.dts:175.37-177.15: \
> Warning (unit_address_vs_reg): /example-4/sound/simple-audio-card,cpu@1: \
> node has a unit name, but no reg or ranges property
> ...
>
> This patch fixup this issue.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> .../bindings/sound/simple-card.yaml | 25 ++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml
> index cb2bb5fac0e1..6c4c2c6d6d3c 100644
> --- a/Documentation/devicetree/bindings/sound/simple-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
> @@ -208,6 +208,11 @@ patternProperties:
> reg:
> maxItems: 1
>
> + "#address-cells":
> + const: 1
> + "#size-cells":
> + const: 0
> +
> # common properties
> frame-master:
> $ref: "#/definitions/frame-master"
> @@ -288,7 +293,6 @@ examples:
>
> #address-cells = <1>;
> #size-cells = <0>;
> -
> simple-audio-card,dai-link@0 { /* I2S - HDMI */
> reg = <0>;
> format = "i2s";
> @@ -392,11 +396,15 @@ examples:
> simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback",
> "ak4642 Playback", "DAI1 Playback";
>
> + #address-cells = <1>;
> + #size-cells = <0>;
> dpcmcpu: simple-audio-card,cpu@0 {
> + reg = <0>;
You need to add 'reg' to the schema. This isn't flagged because
'additionalProperties: false' is missing there too.
> sound-dai = <&rcar_sound 0>;
> };
>
> simple-audio-card,cpu@1 {
> + reg = <1>;
> sound-dai = <&rcar_sound 1>;
> };
>
> @@ -427,7 +435,12 @@ examples:
> "pcm3168a Playback", "DAI3 Playback",
> "pcm3168a Playback", "DAI4 Playback";
>
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> simple-audio-card,dai-link@0 {
> + reg = <0>;
> +
> format = "left_j";
> bitclock-master = <&sndcpu0>;
> frame-master = <&sndcpu0>;
> @@ -441,22 +454,30 @@ examples:
> };
>
> simple-audio-card,dai-link@1 {
> + reg = <1>;
> +
> format = "i2s";
> bitclock-master = <&sndcpu1>;
> frame-master = <&sndcpu1>;
>
> convert-channels = <8>; /* TDM Split */
>
> + #address-cells = <1>;
> + #size-cells = <0>;
> sndcpu1: cpu@0 {
> + reg = <0>;
> sound-dai = <&rcar_sound 1>;
> };
> cpu@1 {
> + reg = <1>;
> sound-dai = <&rcar_sound 2>;
> };
> cpu@2 {
> + reg = <2>;
> sound-dai = <&rcar_sound 3>;
> };
> cpu@3 {
> + reg = <3>;
> sound-dai = <&rcar_sound 4>;
> };
> codec {
> @@ -468,6 +489,8 @@ examples:
> };
>
> simple-audio-card,dai-link@2 {
> + reg = <2>;
> +
> format = "i2s";
> bitclock-master = <&sndcpu2>;
> frame-master = <&sndcpu2>;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v11 1/4] power_supply: Add additional health properties to the header
From: Ricardo Rivera-Matos @ 2020-05-28 22:42 UTC (permalink / raw)
To: Andrew F. Davis, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil,
Guru Das Srinagesh
In-Reply-To: <66823f18-dc74-107f-39ae-aade2d3738c0@ti.com>
On 5/28/20 9:16 AM, Andrew F. Davis wrote:
> On 5/28/20 10:05 AM, Ricardo Rivera-Matos wrote:
>> From: Dan Murphy <dmurphy@ti.com>
>>
>> Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
>>
>> HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken from the JEITA spec.
>
> Wouldn't hurt to list the specific version of the spec these are from,
> but not super important,
>
> Acked-by: Andrew F. Davis <afd@ti.com>
ACK. This originates from JISC8712:2015, but is more succinctly
explained in "A Guide to the Safe Use of Secondary Lithium Ion Batteries
in Notebook-type Personal Computer"
>
>
>> Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> Documentation/ABI/testing/sysfs-class-power | 2 +-
>> drivers/power/supply/power_supply_sysfs.c | 2 +-
>> include/linux/power_supply.h | 3 +++
>> 3 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
>> index bf3b48f022dc..9f3fd01a9373 100644
>> --- a/Documentation/ABI/testing/sysfs-class-power
>> +++ b/Documentation/ABI/testing/sysfs-class-power
>> @@ -190,7 +190,7 @@ Description:
>> Valid values: "Unknown", "Good", "Overheat", "Dead",
>> "Over voltage", "Unspecified failure", "Cold",
>> "Watchdog timer expire", "Safety timer expire",
>> - "Over current"
>> + "Over current", "Warm", "Cool", "Hot"
>>
>> What: /sys/class/power_supply/<supply_name>/precharge_current
>> Date: June 2017
>> diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
>> index f37ad4eae60b..d0d549611794 100644
>> --- a/drivers/power/supply/power_supply_sysfs.c
>> +++ b/drivers/power/supply/power_supply_sysfs.c
>> @@ -61,7 +61,7 @@ static const char * const power_supply_charge_type_text[] = {
>> static const char * const power_supply_health_text[] = {
>> "Unknown", "Good", "Overheat", "Dead", "Over voltage",
>> "Unspecified failure", "Cold", "Watchdog timer expire",
>> - "Safety timer expire", "Over current"
>> + "Safety timer expire", "Over current", "Warm", "Cool", "Hot"
>> };
>>
>> static const char * const power_supply_technology_text[] = {
>> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
>> index dcd5a71e6c67..8670e90c1d51 100644
>> --- a/include/linux/power_supply.h
>> +++ b/include/linux/power_supply.h
>> @@ -61,6 +61,9 @@ enum {
>> POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
>> POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
>> POWER_SUPPLY_HEALTH_OVERCURRENT,
>> + POWER_SUPPLY_HEALTH_WARM,
>> + POWER_SUPPLY_HEALTH_COOL,
>> + POWER_SUPPLY_HEALTH_HOT,
>> };
>>
>> enum {
>>
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: sc16is7xx: Add flag to activate IrDA mode
From: Rob Herring @ 2020-05-28 22:42 UTC (permalink / raw)
To: Daniel Mack
Cc: devicetree, linux-serial, gregkh, jslaby, jringle, m.brock,
pascal.huerst
In-Reply-To: <20200521091152.404404-2-daniel@zonque.org>
On Thu, May 21, 2020 at 11:11:47AM +0200, Daniel Mack wrote:
> From: Pascal Huerst <pascal.huerst@gmail.com>
>
> This series of uart controllers is able to work in IrDA mode.
> This adds a property to the device tree to enable that feature on
> selected ports if needed.
>
> Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
> Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
> index c1091a923a89..4d1f55abe876 100644
> --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
> +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
> @@ -21,6 +21,8 @@ Optional properties:
> the second cell is used to specify the GPIO polarity:
> 0 = active high,
> 1 = active low.
> +- linux,irda-mode-ports: An array that lists the indices of the port that
> + should operate in IrDA mode.
Sorry, should have mentioned to drop 'linux,' too. With that,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Sebastian Reichel @ 2020-05-28 22:44 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-kernel, kernel
In-Reply-To: <20200513185615.508236-1-sebastian.reichel@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 4042 bytes --]
Hi,
I queued this series to power-supply's for-next branch.
-- Sebastian
On Wed, May 13, 2020 at 08:55:56PM +0200, Sebastian Reichel wrote:
> This patchset improves support for SBS compliant batteries. Due to
> the changes, the battery now exposes 32 power supply properties and
> (un)plugging it generates a backtrace containing the following message
> without the first patch in this series:
>
> ---------------------------
> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> add_uevent_var: too many keys
> ---------------------------
>
> For references this is what an SBS battery status looks like after
> the patch series has been applied:
>
> cat /sys/class/power_supply/sbs-0-000b/uevent
> POWER_SUPPLY_NAME=sbs-0-000b
> POWER_SUPPLY_TYPE=Battery
> POWER_SUPPLY_STATUS=Discharging
> POWER_SUPPLY_CAPACITY_LEVEL=Normal
> POWER_SUPPLY_HEALTH=Good
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_TECHNOLOGY=Li-ion
> POWER_SUPPLY_CYCLE_COUNT=12
> POWER_SUPPLY_VOLTAGE_NOW=11441000
> POWER_SUPPLY_CURRENT_NOW=-26000
> POWER_SUPPLY_CURRENT_AVG=-24000
> POWER_SUPPLY_CAPACITY=76
> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1
> POWER_SUPPLY_TEMP=198
> POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600
> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
> POWER_SUPPLY_SERIAL_NUMBER=0000
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
> POWER_SUPPLY_ENERGY_NOW=31090000
> POWER_SUPPLY_ENERGY_FULL=42450000
> POWER_SUPPLY_ENERGY_FULL_DESIGN=41040000
> POWER_SUPPLY_CHARGE_NOW=2924000
> POWER_SUPPLY_CHARGE_FULL=3898000
> POWER_SUPPLY_CHARGE_FULL_DESIGN=3800000
> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=3000000
> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=12300000
> POWER_SUPPLY_MANUFACTURE_YEAR=2017
> POWER_SUPPLY_MANUFACTURE_MONTH=7
> POWER_SUPPLY_MANUFACTURE_DAY=3
> POWER_SUPPLY_MANUFACTURER=UR18650A
> POWER_SUPPLY_MODEL_NAME=GEHC
>
> -- Sebastian
>
> Jean-Francois Dagenais (1):
> power: supply: sbs-battery: add ability to disable charger broadcasts
>
> Sebastian Reichel (18):
> kobject: increase allowed number of uevent variables
> power: supply: core: add capacity error margin property
> power: supply: core: add manufacture date properties
> power: supply: core: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED
> power: supply: sbs-battery: Add TI BQ20Z65 support
> power: supply: sbs-battery: add
> POWER_SUPPLY_PROP_CAPACITY_ERROR_MARGIN support
> power: supply: sbs-battery: simplify read_read_string_data
> power: supply: sbs-battery: add PEC support
> power: supply: sbs-battery: add POWER_SUPPLY_PROP_CURRENT_AVG support
> power: supply: sbs-battery: Improve POWER_SUPPLY_PROP_TECHNOLOGY
> support
> power: supply: sbs-battery: add
> POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT/VOLTAGE_MAX support
> power: supply: sbs-battery: add MANUFACTURE_DATE support
> power: supply: sbs-battery: add
> POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED support
> power: supply: sbs-battery: fix idle battery status
> power: supply: sbs-battery: switch from of_property_* to
> device_property_*
> power: supply: sbs-battery: switch to i2c's probe_new
> power: supply: sbs-battery: constify power-supply property array
> dt-bindings: power: sbs-battery: Convert to yaml
>
> Documentation/ABI/testing/sysfs-class-power | 45 ++-
> .../power/supply/sbs,sbs-battery.yaml | 83 +++++
> .../bindings/power/supply/sbs_sbs-battery.txt | 27 --
> drivers/power/supply/power_supply_sysfs.c | 5 +
> drivers/power/supply/sbs-battery.c | 348 +++++++++++++-----
> include/linux/kobject.h | 2 +-
> include/linux/power_supply.h | 5 +
> 7 files changed, 404 insertions(+), 111 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
> delete mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
>
> --
> 2.26.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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: Bjorn Andersson, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-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
>>
^ 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: Guido Günther, David Airlie, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
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
^ permalink raw reply
* Re: [PATCH 0/9] DT: Improve validation for Marvell SoCs
From: Rob Herring @ 2020-05-28 22:52 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Alessandro Zummo, Alexandre Belloni, Bartosz Golaszewski,
Daniel Lezcano, Jason Cooper, Linus Walleij, Marc Zyngier,
Thomas Gleixner, Ulf Hansson, devicetree, linux-kernel
In-Reply-To: <20200521091356.2211020-1-lkundrak@v3.sk>
On Thu, May 21, 2020 at 11:13:47AM +0200, Lubomir Rintel wrote:
> Hi,
>
> chained to this message is a second version of remaining patches from the
> first spin of the "DT: Improve validation for Marvell SoCs" [1] patch set.
>
> [1] https://lore.kernel.org/lkml/20200317093922.20785-1-lkundrak@v3.sk/
>
> I've attempted to address the review of the v1, each patch includes a
> detailed change log.
>
> Compared to v1, wherever the license or maintainer information was
> missing, I've filled in GPL-2.0-only and people listed in MAINTAINERS
> file. As I've indicated in v1 cover letter, am not sure whether this is
> the optimal course of action. However I've included the relevant people
> in v1 Cc list and asked for clarifications, but didn't really get any
> feedback to that.
Find someone that would care if the bindings are deleted. I'm fine
if you put yourself. Maybe subsystem maintainers are willing to take
orphans. I really only want my name on common things.
Rob
^ permalink raw reply
* [PATCH v12 1/4] power_supply: Add additional health properties to the header
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil, Guru Das Srinagesh
In-Reply-To: <20200528225350.661-1-r-rivera-matos@ti.com>
From: Dan Murphy <dmurphy@ti.com>
Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken
from JEITA specification JISC8712:2015
Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
Documentation/ABI/testing/sysfs-class-power | 2 +-
drivers/power/supply/power_supply_sysfs.c | 2 +-
include/linux/power_supply.h | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
index bf3b48f022dc..9f3fd01a9373 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -190,7 +190,7 @@ Description:
Valid values: "Unknown", "Good", "Overheat", "Dead",
"Over voltage", "Unspecified failure", "Cold",
"Watchdog timer expire", "Safety timer expire",
- "Over current"
+ "Over current", "Warm", "Cool", "Hot"
What: /sys/class/power_supply/<supply_name>/precharge_current
Date: June 2017
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index f37ad4eae60b..d0d549611794 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -61,7 +61,7 @@ static const char * const power_supply_charge_type_text[] = {
static const char * const power_supply_health_text[] = {
"Unknown", "Good", "Overheat", "Dead", "Over voltage",
"Unspecified failure", "Cold", "Watchdog timer expire",
- "Safety timer expire", "Over current"
+ "Safety timer expire", "Over current", "Warm", "Cool", "Hot"
};
static const char * const power_supply_technology_text[] = {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index dcd5a71e6c67..8670e90c1d51 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -61,6 +61,9 @@ enum {
POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
POWER_SUPPLY_HEALTH_OVERCURRENT,
+ POWER_SUPPLY_HEALTH_WARM,
+ POWER_SUPPLY_HEALTH_COOL,
+ POWER_SUPPLY_HEALTH_HOT,
};
enum {
--
2.26.2
^ permalink raw reply related
* [PATCH v12 2/4] dt-bindings: power: Convert battery.txt to battery.yaml
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
In-Reply-To: <20200528225350.661-1-r-rivera-matos@ti.com>
From: Dan Murphy <dmurphy@ti.com>
Convert the battery.txt file to yaml and fix up the examples.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../bindings/power/supply/battery.txt | 82 +---------
.../bindings/power/supply/battery.yaml | 143 ++++++++++++++++++
2 files changed, 144 insertions(+), 81 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/supply/battery.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
index 3049cf88bdcf..b9a81621ce59 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -1,81 +1 @@
-Battery Characteristics
-
-The devicetree battery node provides static battery characteristics.
-In smart batteries, these are typically stored in non-volatile memory
-on a fuel gauge chip. The battery node should be used where there is
-no appropriate non-volatile memory, or it is unprogrammed/incorrect.
-
-Upstream dts files should not include battery nodes, unless the battery
-represented cannot easily be replaced in the system by one of a
-different type. This prevents unpredictable, potentially harmful,
-behavior should a replacement that changes the battery type occur
-without a corresponding update to the dtb.
-
-Required Properties:
- - compatible: Must be "simple-battery"
-
-Optional Properties:
- - voltage-min-design-microvolt: drained battery voltage
- - voltage-max-design-microvolt: fully charged battery voltage
- - energy-full-design-microwatt-hours: battery design energy
- - charge-full-design-microamp-hours: battery design capacity
- - precharge-current-microamp: current for pre-charge phase
- - charge-term-current-microamp: current for charge termination phase
- - constant-charge-current-max-microamp: maximum constant input current
- - constant-charge-voltage-max-microvolt: maximum constant input voltage
- - factory-internal-resistance-micro-ohms: battery factory internal resistance
- - ocv-capacity-table-0: An array providing the open circuit voltage (OCV)
- of the battery and corresponding battery capacity percent, which is used
- to look up battery capacity according to current OCV value. And the open
- circuit voltage unit is microvolt.
- - ocv-capacity-table-1: Same as ocv-capacity-table-0
- ......
- - ocv-capacity-table-n: Same as ocv-capacity-table-0
- - ocv-capacity-celsius: An array containing the temperature in degree Celsius,
- for each of the battery capacity lookup table. The first temperature value
- specifies the OCV table 0, and the second temperature value specifies the
- OCV table 1, and so on.
- - resistance-temp-table: An array providing the temperature in degree Celsius
- and corresponding battery internal resistance percent, which is used to look
- up the resistance percent according to current temperature to get a accurate
- batterty internal resistance in different temperatures.
-
-Battery properties are named, where possible, for the corresponding
-elements in enum power_supply_property, defined in
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h
-
-Batteries must be referenced by chargers and/or fuel-gauges
-using a phandle. The phandle's property should be named
-"monitored-battery".
-
-Example:
-
- bat: battery {
- compatible = "simple-battery";
- voltage-min-design-microvolt = <3200000>;
- voltage-max-design-microvolt = <4200000>;
- energy-full-design-microwatt-hours = <5290000>;
- charge-full-design-microamp-hours = <1430000>;
- precharge-current-microamp = <256000>;
- charge-term-current-microamp = <128000>;
- constant-charge-current-max-microamp = <900000>;
- constant-charge-voltage-max-microvolt = <4200000>;
- factory-internal-resistance-micro-ohms = <250000>;
- ocv-capacity-celsius = <(-10) 0 10>;
- ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;
- ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>, ...;
- ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>, ...;
- resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
- };
-
- charger: charger@11 {
- ....
- monitored-battery = <&bat>;
- ...
- };
-
- fuel_gauge: fuel-gauge@22 {
- ....
- monitored-battery = <&bat>;
- ...
- };
+The contents of this file has been moved to battery.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml
new file mode 100644
index 000000000000..f0b544a22219
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/battery.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/battery.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Battery Characteristics
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description: |
+ The devicetree battery node provides static battery characteristics.
+ In smart batteries, these are typically stored in non-volatile memory
+ on a fuel gauge chip. The battery node should be used where there is
+ no appropriate non-volatile memory, or it is unprogrammed/incorrect.
+
+ Upstream dts files should not include battery nodes, unless the battery
+ represented cannot easily be replaced in the system by one of a
+ different type. This prevents unpredictable, potentially harmful,
+ behavior should a replacement that changes the battery type occur
+ without a corresponding update to the dtb.
+
+ Battery properties are named, where possible, for the corresponding elements
+ in enum power_supply_property, defined in include/linux/power_supply.h
+
+ Batteries must be referenced by chargers and/or fuel-gauges using a phandle.
+ The phandle's property should be named "monitored-battery".
+
+properties:
+ compatible:
+ const: simple-battery
+
+ voltage-min-design-microvolt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: drained battery voltage
+
+ voltage-max-design-microvolt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: fully charged battery voltage
+
+ energy-full-design-microwatt-hours:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: battery design energy
+
+ charge-full-design-microamp-hours:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: battery design capacity
+
+ precharge-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: current for pre-charge phase
+
+ charge-term-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: current for charge termination phase
+
+ constant-charge-current-max-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: maximum constant input current
+
+ constant-charge-voltage-max-microvolt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: maximum constant input voltage
+
+ factory-internal-resistance-micro-ohms:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: battery factory internal resistance
+
+ ocv-capacity-table-0:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ An array providing the open circuit voltage (OCV)
+ of the battery and corresponding battery capacity percent, which is used
+ to look up battery capacity according to current OCV value. And the open
+ circuit voltage unit is microvolt.
+
+ ocv-capacity-table-1:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: Same as ocv-capacity-table-0
+
+ ocv-capacity-table-n:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: Same as ocv-capacity-table-0
+
+ ocv-capacity-celsius:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array containing the temperature in degree Celsius,
+ for each of the battery capacity lookup table. The first temperature value
+ specifies the OCV table 0, and the second temperature value specifies the
+ OCV table 1, and so on.
+
+ resistance-temp-table:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ An array providing the temperature in degree Celsius
+ and corresponding battery internal resistance percent, which is used to
+ look up the resistance percent according to current temperature to get an
+ accurate batterty internal resistance in different temperatures.
+
+ monitored-battery:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the battery node being monitored
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ power {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ battery:battery {
+ compatible = "simple-battery";
+ voltage-min-design-microvolt = <3200000>;
+ voltage-max-design-microvolt = <4200000>;
+ energy-full-design-microwatt-hours = <5290000>;
+ charge-full-design-microamp-hours = <1430000>;
+ precharge-current-microamp = <256000>;
+ charge-term-current-microamp = <128000>;
+ constant-charge-current-max-microamp = <900000>;
+ constant-charge-voltage-max-microvolt = <4200000>;
+ factory-internal-resistance-micro-ohms = <250000>;
+ ocv-capacity-celsius = <(-10) 0 10>;
+ ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>;
+ ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>;
+ resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
+ };
+
+ charger:charger@11 {
+ reg = <0x11>;
+ monitored-battery = <&battery>;
+ };
+
+ fuel_gauge:fuel-gauge@22 {
+ reg = <0x22>;
+ monitored-battery = <&battery>;
+ };
+ };
--
2.26.2
^ permalink raw reply related
* [PATCH v12 0/4] Add JEITA properties and introduce the bq2515x charger
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
Hello,
This patchset adds additional health properties to the power_supply header.
These additional properties are taken from the JEITA specification. This
patchset also introduces the bq2515x family of charging ICs.
Dan Murphy (2):
power_supply: Add additional health properties to the header
dt-bindings: power: Convert battery.txt to battery.yaml
Ricardo Rivera-Matos (2):
dt-bindings: power: Add the bindings for the bq2515x family of
chargers.
power: supply: bq25150 introduce the bq25150
Documentation/ABI/testing/sysfs-class-power | 2 +-
.../bindings/power/supply/battery.txt | 82 +-
.../bindings/power/supply/battery.yaml | 143 ++
.../bindings/power/supply/bq2515x.yaml | 91 ++
drivers/power/supply/Kconfig | 13 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/bq2515x_charger.c | 1158 +++++++++++++++++
drivers/power/supply/power_supply_sysfs.c | 2 +-
include/linux/power_supply.h | 3 +
9 files changed, 1412 insertions(+), 83 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/supply/battery.yaml
create mode 100644 Documentation/devicetree/bindings/power/supply/bq2515x.yaml
create mode 100644 drivers/power/supply/bq2515x_charger.c
--
2.26.2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox