* [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 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 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 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 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 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 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
* 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
* Re: [PATCH v11 4/4] power: supply: bq25150 introduce the bq25150
From: Ricardo Rivera-Matos @ 2020-05-28 22:20 UTC (permalink / raw)
To: Andrew F. Davis, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil
In-Reply-To: <95fcf5ae-cf49-4618-08cc-da7487450e53@ti.com>
On 5/28/20 9:43 AM, Andrew F. Davis wrote:
> On 5/28/20 10:05 AM, Ricardo Rivera-Matos wrote:
>> +static int bq2515x_set_precharge_current(struct bq2515x_device *bq2515x,
>> + int val)
>> +{
>> + int ret;
>> + unsigned int pchrgctrl;
>> + unsigned int icharge_range;
>> + unsigned int precharge_reg_code;
>> + u16 precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
>> + u16 precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
>
> Why u16? looks like it gets promoted everywhere it's used anyway.
ACK
>
>
>> +
>> + ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
>> + if (ret)
>> + return ret;
>> +
>> + icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
>> +
>> + if (icharge_range) {
>> + precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
>> + precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
> This is a little hard to read when we have a default value overwritten
> in an if, it basically hides the else logic, suggest:
>
>
> if (icharge_range) {
> precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
> precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
> } else {
> precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
> precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
> }
ACK. I originally had it as an if/else deal, but I got feedback it was
too verbose. It will stay verbose.
>
>
>> + }
>> + if (val > precharge_max_ua || val < BQ2515X_ICHG_MIN_UA)
>> + return -EINVAL;
>> +
>> + precharge_reg_code = val / precharge_multiplier;
>> +
>> + ret = bq2515x_set_charge_disable(bq2515x, 1);
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_update_bits(bq2515x->regmap, BQ2515X_PCHRGCTRL,
>> + BQ2515X_PRECHARGE_MASK, precharge_reg_code);
>> + if (ret)
>> + return ret;
>> +
>> + return bq2515x_set_charge_disable(bq2515x, 0);
>> +}
> [snip]
>
>> +
>> +static int bq2515x_set_ilim_lvl(struct bq2515x_device *bq2515x, int val)
>> +{
>> + int i = 0;
>> + unsigned int array_size = ARRAY_SIZE(bq2515x_ilim_lvl_values);
>> +
>> + if (val >= bq2515x_ilim_lvl_values[array_size - 1]) {
>
> Isn't this check the same as is done in first iteration of the below loop?
>
> Andrew
ACK
>
>
>> + i = array_size - 1;
>> + } else {
>> + for (i = array_size - 1; i > 0; i--) {
>> + if (val >= bq2515x_ilim_lvl_values[i])
>> + break;
>> + }
>> + }
>> + return regmap_write(bq2515x->regmap, BQ2515X_ILIMCTRL, i);
>> +}
>> +
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd
From: Rob Herring @ 2020-05-28 22:20 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Andrew F . Davis, Santosh Shilimkar, Suman Anna,
Tero Kristo, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20200520211334.61814-2-tony@atomide.com>
On Wed, May 20, 2020 at 02:13:29PM -0700, Tony Lindgren wrote:
> The PRM (Power and Reset Module) has registers to enable and disable
> power domains, so let's update the binding for that.
multiple domains? Then why 0 cells?
>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> --- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -18,6 +18,7 @@ Required properties:
> (base address and length)
>
> Optional properties:
> +- #power-domain-cells: Should be 0 if the PRM instance is a power domain.
...power domain provider.
> - #reset-cells: Should be 1 if the PRM instance in question supports resets.
>
> Example:
> @@ -25,5 +26,6 @@ Example:
> prm_dsp2: prm@1b00 {
> compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
> reg = <0x1b00 0x40>;
> + #power-domain-cells = <0>;
> #reset-cells = <1>;
> };
> --
> 2.26.2
^ permalink raw reply
* Re: [v1] drm/msm: add shutdown support for display platform_driver
From: Stephen Boyd @ 2020-05-28 22:20 UTC (permalink / raw)
To: Krishna Manikandan, devicetree, dri-devel, freedreno,
linux-arm-msm
Cc: Krishna Manikandan, linux-kernel, robdclark, seanpaul, hoegsberg,
kalyan_t, nganji, mka
In-Reply-To: <1590655103-21568-1-git-send-email-mkrishn@codeaurora.org>
Quoting Krishna Manikandan (2020-05-28 01:38:23)
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index e4b750b..7a8953f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1322,6 +1322,18 @@ static int msm_pdev_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static void msm_pdev_shutdown(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> +
> + if (!drm) {
> + DRM_ERROR("Invalid drm device node\n");
> + return;
> + }
When would this ever happen? Please drop this useless check.
> +
> + drm_atomic_helper_shutdown(drm);
> +}
> +
> static const struct of_device_id dt_match[] = {
> { .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
> { .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
^ permalink raw reply
* Re: [PATCH 04/12] dt-bindings: irqchip: ti,sci-intr: Update bindings to drop the usage of gic as parent
From: Rob Herring @ 2020-05-28 22:14 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Marc Zyngier, Thomas Gleixner, Nishanth Menon, Tero Kristo,
Santosh Shilimkar, Linux ARM Mailing List, Sekhar Nori,
Grygorii Strashko, Peter Ujfalusi, Device Tree Mailing List
In-Reply-To: <20200520124454.10532-5-lokeshvutla@ti.com>
On Wed, May 20, 2020 at 06:14:46PM +0530, Lokesh Vutla wrote:
> Drop the firmware related dt-bindings and use the hardware specified
> interrupt numbers within Interrupt Router. This ensures interrupt router
> DT node need not assume any interrupt parent type.
I didn't like this binding to begin with, but now you're breaking
compatibility.
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> .../interrupt-controller/ti,sci-intr.txt | 31 ++++++++++---------
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> index 1a8718f8855d..8b56b2de1c73 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> @@ -44,15 +44,17 @@ Required Properties:
> 4: If intr supports level triggered interrupts.
> - interrupt-controller: Identifies the node as an interrupt controller
> - #interrupt-cells: Specifies the number of cells needed to encode an
> - interrupt source. The value should be 2.
> - First cell should contain the TISCI device ID of source
> - Second cell should contain the interrupt source offset
> - within the device.
> + interrupt source. The value should be 1.
> + First cell should contain interrupt router input number
> + as specified by hardware.
> - ti,sci: Phandle to TI-SCI compatible System controller node.
> -- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
> -- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
> - assigned to this interrupt router. Each subtype id
> - corresponds to a range of host irqs.
> +- ti,sci-dev-id: TISCI device id of interrupt controller.
> +- ti,interrupt-ranges: Set of triplets containing ranges that convert
> + the INTR output interrupt numbers to parent's
> + interrupt number. Each triplet has following entries:
> + - First entry specifies the base for intr output irq
> + - Second entry specifies the base for parent irqs
> + - Third entry specifies the limit
Humm, sounds like what interrupt-map does.
>
> For more details on TISCI IRQ resource management refer:
> http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
> @@ -62,21 +64,20 @@ Example:
> The following example demonstrates both interrupt router node and the consumer
> node(main gpio) on the AM654 SoC:
>
> -main_intr: interrupt-controller0 {
> +main_gpio_intr: interrupt-controller0 {
> compatible = "ti,sci-intr";
> ti,intr-trigger-type = <1>;
> interrupt-controller;
> interrupt-parent = <&gic500>;
> - #interrupt-cells = <2>;
> + #interrupt-cells = <1>;
> ti,sci = <&dmsc>;
> - ti,sci-dst-id = <56>;
> - ti,sci-rm-range-girq = <0x1>;
> + ti,sci-dev-id = <131>;
> + ti,interrupt-ranges = <0 360 32>;
> };
>
> main_gpio0: gpio@600000 {
> ...
> - interrupt-parent = <&main_intr>;
> - interrupts = <57 256>, <57 257>, <57 258>,
> - <57 259>, <57 260>, <57 261>;
> + interrupt-parent = <&main_gpio_intr>;
> + interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
> ...
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH V4] dt-bindings: thermal: Convert i.MX to json-schema
From: Rob Herring @ 2020-05-28 22:05 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, robh+dt, shawnguo, s.hauer, daniel.lezcano, kernel,
Linux-imx, linux-kernel, linux-arm-kernel, rui.zhang,
amit.kucheria, linux-pm, festevam
In-Reply-To: <1589967737-1128-1-git-send-email-Anson.Huang@nxp.com>
On Wed, 20 May 2020 17:42:17 +0800, Anson Huang wrote:
> Convert the i.MX thermal binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> Changes since V3:
> - improve "fsl,tempmon" description.
> ---
> .../devicetree/bindings/thermal/imx-thermal.txt | 61 ------------
> .../devicetree/bindings/thermal/imx-thermal.yaml | 102 +++++++++++++++++++++
> 2 files changed, 102 insertions(+), 61 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: mailbox: Add devicetree binding for Qcom IPCC
From: Rob Herring @ 2020-05-28 22:03 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-kernel, linux-arm-msm, bjorn.andersson, robh+dt, devicetree,
jassisinghbrar
In-Reply-To: <20200520084854.19729-2-manivannan.sadhasivam@linaro.org>
On Wed, 20 May 2020 14:18:52 +0530, Manivannan Sadhasivam wrote:
> Add devicetree YAML binding for Qualcomm Inter-Processor Communication
> Controller (IPCC) block.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/mailbox/qcom-ipcc.yaml | 80 +++++++++++++++++++
> include/dt-bindings/mailbox/qcom-ipcc.h | 33 ++++++++
> 2 files changed, 113 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> create mode 100644 include/dt-bindings/mailbox/qcom-ipcc.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Heiko Stübner @ 2020-05-28 22:02 UTC (permalink / raw)
To: Rob Herring
Cc: Dmitry Torokhov, Johan Jonker, linux-input, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20200528220136.GA748777@bogus>
Am Freitag, 29. Mai 2020, 00:01:36 CEST schrieb Rob Herring:
> On Wed, May 20, 2020 at 08:41:59PM +0200, Heiko Stübner wrote:
> > Hi Dmitry,
> >
> > Am Mittwoch, 20. Mai 2020, 19:13:24 CEST schrieb Dmitry Torokhov:
> > > Hi Johan,
> > >
> > > On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> > > > A test with the command below gives this error:
> > > >
> > > > arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> > > > touchscreen@3e: reg:0:0: 56 was expected
> > > >
> > > > The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> > > > was shipped with different addresses then the binding currently allows.
> > > > Change the reg property that any address will pass.
> > > >
> > > > make ARCH=arm dtbs_check
> > > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> > > > edt-ft5x06.yaml
> > > >
> > > > Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> > > > ---
> > > > Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > index 383d64a91..baa8e8f7e 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > @@ -42,7 +42,7 @@ properties:
> > > > - focaltech,ft6236
> > > >
> > > > reg:
> > > > - const: 0x38
> > > > + maxItems: 1
> > >
> > > Should we have a list of valid addresses instead of allowing any
> > > address? Controllers usually have only a couple of addresses that they
> > > support.
> >
> > from what I've read, the fdt touchscreen controllers are just a generic
> > cpu with device-specific (or better panel-specific) firmware, which seems
> > to include the address as well - so it looks to be variable.
> >
> > But of course that is only 2nd hand knowledge for me ;-)
> >
> >
> > But also, the i2c address is something you cannot really mess up,
> > either it is correct and your touchscreen works, or it isn't and and
> > adding entries to this list every time a new address variant pops up
> > feels clumsy.
>
> Is that an Ack?
for the patch itself:
Acked-by: Heiko Stuebner <heiko@sntech.de>
> I'm fine either way. It's really only useful if there's a single
> address because with a list it could still be wrong just as any other
> data like an interrupt number could be wrong.
>
> Rob
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Rob Herring @ 2020-05-28 22:01 UTC (permalink / raw)
To: Heiko Stübner
Cc: Dmitry Torokhov, Johan Jonker, linux-input, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <4727344.YYj2SkWT1V@diego>
On Wed, May 20, 2020 at 08:41:59PM +0200, Heiko Stübner wrote:
> Hi Dmitry,
>
> Am Mittwoch, 20. Mai 2020, 19:13:24 CEST schrieb Dmitry Torokhov:
> > Hi Johan,
> >
> > On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> > > A test with the command below gives this error:
> > >
> > > arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> > > touchscreen@3e: reg:0:0: 56 was expected
> > >
> > > The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> > > was shipped with different addresses then the binding currently allows.
> > > Change the reg property that any address will pass.
> > >
> > > make ARCH=arm dtbs_check
> > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> > > edt-ft5x06.yaml
> > >
> > > Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> > > ---
> > > Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > index 383d64a91..baa8e8f7e 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > @@ -42,7 +42,7 @@ properties:
> > > - focaltech,ft6236
> > >
> > > reg:
> > > - const: 0x38
> > > + maxItems: 1
> >
> > Should we have a list of valid addresses instead of allowing any
> > address? Controllers usually have only a couple of addresses that they
> > support.
>
> from what I've read, the fdt touchscreen controllers are just a generic
> cpu with device-specific (or better panel-specific) firmware, which seems
> to include the address as well - so it looks to be variable.
>
> But of course that is only 2nd hand knowledge for me ;-)
>
>
> But also, the i2c address is something you cannot really mess up,
> either it is correct and your touchscreen works, or it isn't and and
> adding entries to this list every time a new address variant pops up
> feels clumsy.
Is that an Ack?
I'm fine either way. It's really only useful if there's a single
address because with a list it could still be wrong just as any other
data like an interrupt number could be wrong.
Rob
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/bridge: tfp410: Fix setup and hold time calculation
From: Laurent Pinchart @ 2020-05-28 21:46 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-5-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Thu, May 14, 2020 at 04:36:12PM +0200, Ricardo Cañuelo wrote:
> The tfp410 has a data de-skew feature that allows the user to compensate
> the skew between IDCK and the pixel data and control signals.
>
> In the driver, the setup and hold times are calculated from the de-skew
> value. This retrieves the deskew value from the DT using the proper
> datatype and range check as described by the binding (u32 from 0 to 7)
> and fixes the calculation of the setup and hold times.
How about mentioning that the fix results from a change in the DT
bindings ? Otherwise it sounds it was a bug in the driver.
I would also mention that the patch fixes the min() calculation, which
was clearly wrong. I think I would have split this in two patches.
With this addressed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
> index e3eb6364c0f7..21d99b4ea0c9 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -220,7 +220,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
> struct device_node *ep;
> u32 pclk_sample = 0;
> u32 bus_width = 24;
> - s32 deskew = 0;
> + u32 deskew = 0;
>
> /* Start with defaults. */
> *timings = tfp410_default_timings;
> @@ -274,12 +274,12 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
> }
>
> /* Get the setup and hold time from vendor-specific properties. */
> - of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *)&deskew);
> - if (deskew < -4 || deskew > 3)
> + of_property_read_u32(dvi->dev->of_node, "ti,deskew", &deskew);
> + if (deskew > 7)
> return -EINVAL;
>
> - timings->setup_time_ps = min(0, 1200 - 350 * deskew);
> - timings->hold_time_ps = min(0, 1300 + 350 * deskew);
> + timings->setup_time_ps = 1200 - 350 * ((s32)deskew - 4);
> + timings->hold_time_ps = max(0, 1300 + 350 * ((s32)deskew - 4));
>
> return 0;
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: mtd: Convert ingenic,jz4780-nand.txt to YAML
From: Rob Herring @ 2020-05-28 21:45 UTC (permalink / raw)
To: Paul Cercueil
Cc: Boris Brezillon, od, Rob Herring, devicetree, linux-mtd,
linux-kernel, linux-gpio
In-Reply-To: <20200520002234.418025-3-paul@crapouillou.net>
On Wed, 20 May 2020 02:22:34 +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nand.txt doc file to ingenic,nand.yaml.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: - Don't include ingenic,nemc-client.yaml which is gone
> - Use 'partitions' property instead of '^partitions$' pattern
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 92 ------------
> .../devicetree/bindings/mtd/ingenic,nand.yaml | 132 ++++++++++++++++++
> 2 files changed, 132 insertions(+), 92 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: memory: Convert ingenic,jz4780-nemc.txt to YAML
From: Rob Herring @ 2020-05-28 21:45 UTC (permalink / raw)
To: Paul Cercueil
Cc: od, linux-gpio, devicetree, linux-kernel, Boris Brezillon,
Rob Herring, linux-mtd
In-Reply-To: <20200520002234.418025-2-paul@crapouillou.net>
On Wed, 20 May 2020 02:22:33 +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nemc.txt doc file to ingenic,nemc.yaml.
>
> The ingenic,jz4725b-nemc compatible string was added in the process,
> with a fallback to ingenic,jz4740-nemc.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: - Inline content of ingenic,nemc-client.yaml inside ingenic,nemc.yaml
> - Add missing 'reg' property to sub-nodes and mark it as required
> - Use a more generic wildcard to match all sub-nodes.
>
> .../ingenic,jz4780-nemc.txt | 76 -----------
> .../memory-controllers/ingenic,nemc.yaml | 126 ++++++++++++++++++
> 2 files changed, 126 insertions(+), 76 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: ti,tfp410.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-28 21:43 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-4-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Thu, May 14, 2020 at 04:36:11PM +0200, Ricardo Cañuelo wrote:
> Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
> encoder to json-schema.
>
> The 'ti,deskew' is now an unsigned value from 0 to 7 instead of a signed
> value from -4 to 3. The rest of the binding is a direct translation from
> the old one.
I would have modified this in a separate patch.
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 66 ----------
> .../bindings/display/bridge/ti,tfp410.yaml | 124 ++++++++++++++++++
> 2 files changed, 124 insertions(+), 66 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> deleted file mode 100644
> index 5ff4f64ef8e8..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -TFP410 DPI to DVI encoder
> -=========================
> -
> -Required properties:
> -- compatible: "ti,tfp410"
> -
> -Optional properties:
> -- powerdown-gpios: power-down gpio
> -- reg: I2C address. If and only if present the device node should be placed
> - into the I2C controller node where the TFP410 I2C is connected to.
> -- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
> - through th DK[3:1] pins. This property shall be present only if the TFP410
> - is not connected through I2C.
> -
> -Required nodes:
> -
> -This device has two video ports. Their connections are modeled using the OF
> -graph bindings specified in [1]. Each port node shall have a single endpoint.
> -
> -- Port 0 is the DPI input port. Its endpoint subnode shall contain a
> - pclk-sample and bus-width property and a remote-endpoint property as specified
> - in [1].
> - - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
> - backward compatibility.
> - - If bus-width is not defined then bus-width = 24 should be assumed for
> - backward compatibility.
> - bus-width = 24: 24 data lines are connected and single-edge mode
> - bus-width = 12: 12 data lines are connected and dual-edge mode
> -
> -- Port 1 is the DVI output port. Its endpoint subnode shall contain a
> - remote-endpoint property is specified in [1].
> -
> -[1] Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -
> -Example
> --------
> -
> -tfp410: encoder@0 {
> - compatible = "ti,tfp410";
> - powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> - ti,deskew = <4>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> -
> - tfp410_in: endpoint@0 {
> - pclk-sample = <1>;
> - bus-width = <24>;
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> -
> - tfp410_out: endpoint@0 {
> - remote-endpoint = <&dvi_connector_in>;
> - };
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> new file mode 100644
> index 000000000000..a9f4fd8ea621
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TFP410 DPI to DVI encoder
> +
> +maintainers:
> + - Tomi Valkeinen <tomi.valkeinen@ti.com>
> + - Jyri Sarha <jsarha@ti.com>
> +
> +properties:
> + compatible:
> + const: ti,tfp410
> +
> + reg:
> + description: I2C address of the device.
> + maxItems: 1
> +
> + powerdown-gpios:
> + maxItems: 1
> +
> + ti,deskew:
> + description:
> + Data de-skew value in 350ps increments, from 0 to 7, as configured
> + through the DK[3:1] pins. The de-skew multiplier is computed as
> + (DK[3:1] - 4), so it ranges from -4 to 3. This property shall be
> + present only if the TFP410 is not connected through I2C.
I'd replace the last sentence with
if:
required:
- reg
then:
properties:
ti,deskew: false
else:
required:
- ti,deskew
(between the required: and additionalProperties: objects below)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 7
> +
> + ports:
> + description:
> + A node containing input and output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + type: object
> +
> + properties:
> + port@0:
> + description: DPI input port.
> + type: object
> +
> + properties:
> + reg:
> + const: 0
> +
> + endpoint:
> + type: object
> +
> + properties:
> + pclk-sample:
> + description:
> + Endpoint sampling edge. If not defined, pclk-sample =
> + 0 should be assumed for backwards compatibility.
Should the second sentence be dropped, as it's expressed with default: 0
?
> + enum:
> + - 0 # Falling edge
> + - 1 # Rising edge
> + default: 0
> +
> + bus-width:
> + description:
> + Endpoint bus width. If not defined, bus-width = 24
> + should be assumed for backwards compatibility.
Same here for the second sentence.
With these small issues fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + enum:
> + - 12 # 12 data lines connected and dual-edge mode
> + - 24 # 24 data lines connected and single-edge mode
> + default: 24
> +
> + port@1:
> + description: DVI output port.
> + type: object
> +
> + properties:
> + reg:
> + const: 1
> +
> + endpoint:
> + type: object
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + tfp410: encoder {
> + compatible = "ti,tfp410";
> + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> + ti,deskew = <3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + tfp410_in: endpoint {
> + pclk-sample = <1>;
> + bus-width = <24>;
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + tfp410_out: endpoint {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: pinctrl: Convert ingenic,pinctrl.txt to YAML
From: Rob Herring @ 2020-05-28 21:42 UTC (permalink / raw)
To: Paul Cercueil
Cc: Boris Brezillon, od, devicetree, linux-kernel, linux-mtd,
linux-gpio
In-Reply-To: <20200520002234.418025-1-paul@crapouillou.net>
On Wed, May 20, 2020 at 02:22:32AM +0200, Paul Cercueil wrote:
> Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
>
> In the process, some compatible strings now require a fallback, as the
> corresponding SoCs are pin-compatible with their fallback variant.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: - Use 'pinctrl' instead of 'pin-controller' as the node name
> - remove 'additionalProperties: false' since we will have pin conf nodes
You need to describe those nodes and not just allow anything.
>
> .../bindings/pinctrl/ingenic,pinctrl.txt | 81 -----------
> .../bindings/pinctrl/ingenic,pinctrl.yaml | 136 ++++++++++++++++++
> 2 files changed, 136 insertions(+), 81 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> new file mode 100644
> index 000000000000..5be2b1e95b36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/ingenic,pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ingenic SoCs pin controller devicetree bindings
> +
> +description: >
> + Please refer to pinctrl-bindings.txt in this directory for details of the
> + common pinctrl bindings used by client devices, including the meaning of the
> + phrase "pin configuration node".
> +
> + For the Ingenic SoCs, pin control is tightly bound with GPIO ports. All pins
> + may be used as GPIOs, multiplexed device functions are configured within the
> + GPIO port configuration registers and it is typical to refer to pins using the
> + naming scheme "PxN" where x is a character identifying the GPIO port with
> + which the pin is associated and N is an integer from 0 to 31 identifying the
> + pin within that GPIO port. For example PA0 is the first pin in GPIO port A,
> + and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830
> + contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the
> + JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192
> + pins.
> +
> +maintainers:
> + - Paul Cercueil <paul@crapouillou.net>
> +
> +properties:
> + nodename:
It's $nodename as that's not a real property. And that will expose the
error in the example for you.
> + pattern: "^pinctrl@[0-9a-f]+$"
> +
> + compatible:
> + oneOf:
> + - enum:
> + - ingenic,jz4740-pinctrl
> + - ingenic,jz4725b-pinctrl
> + - ingenic,jz4760-pinctrl
> + - ingenic,jz4770-pinctrl
> + - ingenic,jz4780-pinctrl
> + - ingenic,x1000-pinctrl
> + - ingenic,x1500-pinctrl
> + - ingenic,x1830-pinctrl
> + - items:
> + - const: ingenic,jz4760b-pinctrl
> + - const: ingenic,jz4760-pinctrl
> + - items:
> + - const: ingenic,x1000e-pinctrl
> + - const: ingenic,x1000-pinctrl
> +
> + reg:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^gpio@[0-9]$":
> + type: object
> + properties:
> + compatible:
> + enum:
> + - ingenic,jz4740-gpio
> + - ingenic,jz4725b-gpio
> + - ingenic,jz4760-gpio
> + - ingenic,jz4770-gpio
> + - ingenic,jz4780-gpio
> + - ingenic,x1000-gpio
> + - ingenic,x1500-gpio
> + - ingenic,x1830-gpio
> +
> + reg:
> + items:
> + - description: The GPIO bank number
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> + gpio-ranges:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> + description:
> + Refer to ../interrupt-controller/interrupts.txt for more details.
> +
> + interrupts:
> + maxItems: 1
> +
> + required:
> + - compatible
> + - reg
> + - gpio-controller
> + - "#gpio-cells"
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> +
> +examples:
> + - |
> + pin-controller@10010000 {
> + compatible = "ingenic,jz4770-pinctrl";
> + reg = <0x10010000 0x600>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@0 {
> + compatible = "ingenic,jz4770-gpio";
> + reg = <0>;
> +
> + gpio-controller;
> + gpio-ranges = <&pinctrl 0 0 32>;
> + #gpio-cells = <2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <17>;
> + };
> + };
> --
> 2.26.2
>
^ permalink raw reply
* Re: [v1] drm/bridge: ensure bridge suspend happens during PM sleep
From: Doug Anderson @ 2020-05-28 21:37 UTC (permalink / raw)
To: Stephen Boyd
Cc: Harigovindan P,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
dri-devel, freedreno, linux-arm-msm, LKML, Rob Clark, Sean Paul,
Kristian H. Kristensen, Kalyan Thota, nganji, Sam Ravnborg
In-Reply-To: <158931520588.215346.14524550377627605126@swboyd.mtv.corp.google.com>
Hi,
On Tue, May 12, 2020 at 1:26 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> The subject is not specific enough. I'd expect it to be something like:
>
> drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
>
> Quoting Harigovindan P (2020-04-22 02:04:43)
> > ti-sn65dsi86 bridge is enumerated as a runtime device.
> >
> > Adding sleep ops to force runtime_suspend when PM suspend is
> > requested on the device.
> >
> > This change needs to be taken along with the series:
> > https://patchwork.kernel.org/patch/11494309/
>
> Why? It doesn't seem like it should be required to go along with a qcom
> specific driver patch.
>
> >
> > Signed-off-by: Harigovindan P <harigovi@codeaurora.org>
> > ---
>
> Besides the subject:
>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Are you planning to re-post with the changes Stephen requested? Maybe
CC Sam too who was nice enough to help land some of my recent changes
to this driver.
-Doug
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: Convert mxs to json-schema
From: Rob Herring @ 2020-05-28 21:24 UTC (permalink / raw)
To: Anson Huang
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel,
bgolaszewski, s.hauer, festevam, linux-gpio, shawnguo,
linus.walleij, kernel, robh+dt
In-Reply-To: <1589934035-5309-1-git-send-email-Anson.Huang@nxp.com>
On Wed, 20 May 2020 08:20:35 +0800, Anson Huang wrote:
> Convert the MXS GPIO binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/gpio/gpio-mxs.txt | 88 -------------
> .../devicetree/bindings/gpio/gpio-mxs.yaml | 136 +++++++++++++++++++++
> 2 files changed, 136 insertions(+), 88 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.txt
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: mtd: nand: Document the generic rb-gpios property
From: Rob Herring @ 2020-05-28 21:22 UTC (permalink / raw)
To: Boris Brezillon
Cc: devicetree, Richard Weinberger, Tudor Ambarus, Mark Rutland,
linux-mtd, Miquel Raynal, Vignesh Raghavendra, Rob Herring,
Harvey Hunt, Paul Cercueil
In-Reply-To: <20200519232454.374081-2-boris.brezillon@collabora.com>
On Wed, 20 May 2020 01:24:52 +0200, Boris Brezillon wrote:
> A few drivers use this property to describe GPIO pins used to sample
> the NAND Ready/Busy state. Let's make it part of the generic binding
> doc.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> Changes in v2:
> * New patch
> ---
> Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 2/4] dt-bindings: regulator: add pca9450 regulator yaml
From: Rob Herring @ 2020-05-28 21:20 UTC (permalink / raw)
To: Robin Gong
Cc: broonie, kernel, john.lee, anson.huang, linux-imx,
catalin.marinas, s.hauer, linux-arm-kernel, robh+dt, linux-kernel,
devicetree, will, lgirdwood, festevam, shawnguo
In-Reply-To: <1589925907-9195-3-git-send-email-yibin.gong@nxp.com>
On Wed, 20 May 2020 06:05:05 +0800, Robin Gong wrote:
> Add device binding doc for pca9450 pmic driver.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> .../bindings/regulator/nxp,pca9450-regulator.yaml | 190 +++++++++++++++++++++
> 1 file changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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